1351

Примеры / Re: Модель прецедентов использования - практический вопрос

« : 12 Апреля 2012, 14:36:34 »

Мне понравилась книга Use Case Modeling by Bittner K., Spence I.

1352

Примеры / Re: Модель прецедентов использования - практический вопрос

« : 11 Апреля 2012, 09:08:00 »

Неплохо, только изобразить все-таки следует иначе - ВИ внутри прямоугольника системы, который собственно имеет название и определяет контекст рассмотрения.

Пользователя = Зарегистрированный пользователь (посетитель), т.е. усилить факт самой регистрации. Поскольку посетитель он тоже пользователь "большого и вечного"

ВИ "Управлять трансляцией" безлично. Имхо лучше  "Изменить настройки своей трансляции или удалить свою трансляцию". Либо вообще два отдельных ВИ - объединить можно потом, когда будет ясно, что объединять.

ВИ "Изменить права доступа посетителя" - что тут имеется в виду?

По поводу зрителя - руководствуйтесь принципом Оккамы

1353

Примеры / Re: Модель прецедентов использования - практический вопрос

« : 09 Апреля 2012, 20:06:59 »

Конкретный пользователь получает нужные роли (группы доступа) при настройке прав доступа.
Тогда роль Автор позволяет только CRUD Tрансляцию, а роль Модератор - только Модерировать Трансляцию (модерирование не имеет ничего общего с CRUD. В противном случае у вас получится, что Модератор может создавать и править трансляции от имени других пользвателей, что вряд ли приведет их в восторг.)

Полностью согласен.

Если надо показать, что любой пользователь может получить обе эти роли независимо, то нарисуйте слева от человечков Автор и Модератор еще человечка Пользователь, и проведите к Пользователю от двух других  стрелочки Генерализация.

Да именно об этом я и пытался сказать ниже

Если уж нужно, тогда следует выделять промежуточное обобщение от которого наследуются и автор и модератор.

1354

Примеры / Re: Модель прецедентов использования - практический вопрос

« : 09 Апреля 2012, 20:01:14 »

А я вот с Эдуардом не соглашусь...

1 вариант я вообще не стал обсуждать. он не верен изначально, также как и второй. И первый и второй ошибочен. Впрочем я высказал свое мнение, холивары устраивать не буду. Просто нужно следовать логике языка, его синтаксису, семантике и прагматике.

1355

Примеры / Re: Модель прецедентов использования - практический вопрос

« : 09 Апреля 2012, 17:24:26 »

Я бы все-таки избегал обощения модератором свойств автора. Это суть реализации, разделение полномочий на исполняемые действия, а не суть задач. Автор  - это не модератор, это однозначно. Потому не надо нарушать логику предметной области в угоду изобразительного искусства. Если уж нужно, тогда следует выделять промежуточное обощение от которого наследуются и автор и модератор.

Кроме того модератор хотя и активный пользователь системы, но он все-таки ближе к понятию системного персонала. Потому спрашивается, если есть модератор, наверное, есть и администратор? Почему бы его не изобразить?

Потому ориентируемся на самое главное и основное в первую очередь:
1. автор - размещает трансялцию в эфире (возможно ждет разрешения модератора) (если хочет удаляет ее)
2. модератор - разрешает трансляцию в эфире (если надо удаляет оную)
3. там Вы говорили что-то по комментирование - а кто коментит, ну уж явно не автор а кто-то другой, этот другой кто он? явно пропущен ВИ Оставить комментарий к трансляции

По поводу CRUD см. книгу usecasespatternsblueprints.chm. Правда мне этот CRUD честно не нравится.

Но

Код: [Выделить]

Use Case: CRUD Task
Brief Description

The use case registers, modifies, or cancels the information about a task to be performed as stated in information received from the Task Definer.

Basic Flow

The use case has four different basic flows:

Register Task

Modify Existing Task

Cancel Task

View Tasks That Failed

REGISTER TASK

The use case starts when the Task Definer chooses to register a new task. The use case presents a list of possible kinds of tasks to the Task Definer, and asks what kind of task is to be registered, what name it is to be assigned, and when it is to be performed.

The Task Definer enters the required information. The use case checks whether the specified time is in the future and whether the name of the task is unique.

The use case registers a new task in the system and marks the task as enabled.

The use case ends.

MODIFY EXISTING TASK

The use case starts when the Task Definer chooses to modify an already registered task. The use case retrieves the names of all the tasks not marked as active and presents them to the Task Definer.

The Task Definer selects one of the tasks. The use case retrieves the information about the task and presents it to the Task Definer.

The Task Definer modifies any of the presented information except the name of the task.

The Task Definer accepts the information. The use case checks whether the specified time is in the future and, if so, stores the modified information.

The use case ends.

CANCEL TASK

The use case starts when the Task Definer chooses to cancel a task. The use case retrieves all the tasks not marked as active.

The Task Definer selects one of the tasks. The use case retrieves the information about the task and presents it to the Task Definer.

If the Task Definer confirms the cancellation, the use case removes the task; otherwise, no modifications are made.

The use case ends.

VIEW TASKS THAT FAILED

The use case starts when the Task Definer chooses to view a list of all the tasks that have failed. The use case collects all the tasks with the status failed and presents their names to the Task Definer.

The use case ends.

Alternative Flows

CANCEL OPERATION

The Task Definer may choose to cancel the operation at any time during the use case, in which case any gathered information is discarded, and the use case ends.

INCORRECT NAME OR TIME

If the name of the task is performed not unique or the time is not in the future, the Task Definer is notified that the information is incorrect and is requested to re-enter the incorrect information.

The Task Definer re-enters the information. The flow resumes where the check of the information is performed.

1356

Примеры / Re: Модель прецедентов использования - практический вопрос

« : 09 Апреля 2012, 09:12:41 »

Я отвечу по существу вопроса. Реально тут можно серьезно подискутировать, однако.

Включение тут явно не катит никак.
1. Налицо - предусловие. Ясно, чтобы что-то сделать с трансляцией, ее нужно создать - опубликовать.
2. Включение моделирует ситуацию, когда ВИ Трансляция не моежт быть НИКОГДА звершен, пока не будет ВКЛЮЧЕН и ЗАВЕРШЕН ВИ Управление трансляцией
3. Названия ВИ неудачные. ВИ  - это цель использования системы. ВИ всегда имеет ОДНУ роль характеризующую ВИ, по сути и отражающую самую цель использования. У нас их типа две: создатель (я бы назвал его автором) и модератор. И так автор - ПУБЛИКУЕТ трансляцию (размещает, добавляет и т.п.), далее автор как я понимаю может редактировать и удалять свою трансляцию? (Создание трансялции - акт творческий и видимо осуществляется вне рамок рассматриваемой системы). Кстати а что за система? Модератор - модерирует трансляцию. Т.е. получаем группу Автор - Разместить/изменить трансляцию и Модератор - Модерировать трансляцию. Очевидно, автор может что-то делать только со СВОЕЙ трансляцией, модератор может делать РАЗРЕШЕНИЯ по любой из трансляций. Ясно, что никакого обощения уточнения тут нет, т.е. мы не можем сделать генерализацию, т.к. ни при каких обстоятельствах нельзя сказать:
модератор - это автор, но частично можно было бы сказать - автор - это модератор (но только своих трансляций), однако это все-таки не полное наследование (а выброчное), тоже нельзя применить явно.

Можно было бы попытатсья осуществить обобщение вариантов использования  Обобщение вариантов использования. Но здесь оно тоже не подходит.

Резюме. Ваша модель использования небольшая, начните не с обощения всего в 1-2 варианта использования, а напишите столько сколько типичных вариантов использования обнаруживается, их у вас ну не много, потом уже и соедините, коли потребуется.

1357

Книги, статьи и ресурсы / Re: Коберн Современные методы описания функциональных требований к системам

« : 07 Апреля 2012, 16:49:03 »

а есть такая в электронном виде, желательно pdf или rtf?

google, но только первое издание

1358

Книги, статьи и ресурсы / Re: Коберн Современные методы описания функциональных требований к системам

« : 07 Апреля 2012, 16:48:32 »

В интернет-магазине http://my-shop.ru/shop/books/653522.html?partner=00519 появилась новое издание 2011 года. Заказал его. По цене намного дешевле, чем в Озоне.

Павел, когда получишь книгу, можешь написать, чем второе издание отличается от первого?

1359

Примеры / Re: Моделирование кадровых процессов

« : 05 Апреля 2012, 17:23:43 »

Прошу прощения, а тема еще обсуждается или уже все забыли? а то почти 5 лет прошло, а у меня вопросик...

Конечно, не акутальна, но задавайте, может отвечу. Кадрами все равно занимаюсь

1360

Книги, статьи и ресурсы / Re: К Вигерс, Разработка требований к программному обеспечению--пропущенные страницы

« : 31 Марта 2012, 22:06:48 »

Мне кажется было бы интереснее силами форума подредактировать текст да издать книгу.

Спасибо еще раз, но издавать и даже распространять в том виде как есть к сожалению нельзя. Права на книгу ни вам, ни нам не принадлежат. Т.е. для ее издания нужно их приобретать у автора или у издательства. Вообще не знаю как в этих случаях поступают

1361

ПО Аналитика / Re: BPMN: Какой инструмент выбрать?

« : 31 Марта 2012, 22:03:32 »

Уважаемый 899480, чтобы не скрывалось под ним:)

Можете рассказать кратко, чем ELMA лучше других инструментов, ну хотя бы того же BIZAGI или Unify?

1362

ПО Аналитика / Re: UML-редактор Astah

« : 22 Марта 2012, 20:03:14 »

Если у Вас есть опыт в RR, правда такого продукта уже нет давно, то Вам и карты в руки. Попробуйте Astah и расскажите.

1363

Бизнес-анализ и Целеполагание / Re: NGOSS\Frameworx

« : 21 Марта 2012, 16:01:49 »

ух, какая тут оживленная дискуссия.. =D

Видимо не туда попали с вопросом

1364

Для всех / Требуется помощь специалиста C# и ADO.NET (Visual Studio)

« : 16 Марта 2012, 21:32:19 »

Делаю учебный проект, связанный с разработкой приложения к базам данных. Для обучения в рамках программы MSDN AA (практически бесплатное использования многих программ от Microsoft) используется связка MS SQL и Visual Studio 2010. Разработка приложения производится на C#. Хотя язык не очень важен в данном контексте.

Стояла следующая задача:
 - подготовить образцовые (с точки зрения меня) методические указания по проектированию и созданию базы данных, а затем приложения к ней в среде VS
 - при разработке приложения максимально использовать стандартные компоненты, технологии, приемы и способы, ручное кодирование по возможности избегать или свести к необходимому минимуму
 - использовать ADO.NET
 - приложение типа MDI должно содержать:
 - - общую (главную) форму с меню, единым гридом = журналом записей отображаемых таблиц, сервисом, возможностью добавления новых и работы со старыми, поиска
 - - простые формы для ввода и редактирования единичных записей
 - - более сложные формы с использованием подчинения (в виде комбиков или связки мастер-деталь)
 - - формы реализующие основные бизнес-задачи (у нас продажа и покупка картин)
 - - простой отчет (выгрузка в html)
 - - сложный сводный отчет с визуализацией результатов в табличном и графическом виде

К сожалению пока достаточно слабо разбираюсь в VS и C#, потому нуждаюсь в помощи, человека (людей), для получения рекомендаций, совета, может быть аудита моих решений. Если таковые имеются и не считают для себя слишком обременительным это, прошу связаться со мной через личные сообщения (дабы не тревожить общественность форума)

1365

Бизнес-анализ и Целеполагание / Re: Цель разработки\приобритения ПО и АС. Какова она как правило ?

« : 16 Марта 2012, 11:50:32 »

Имхо, список ответов некорректен