Рекомендации по написанию спецификаций вариантов использования(Прочитано 61768 раз)
Автор статья я.

То что нет вывода автора - это вопрос настройки вывода контента, в FAQ я не хотел бы говорить от своего имени. Тем более рекомендации выполнены согласно книги UML2 и унифицированный процесс Арлоу и Нейштадта
Так и пиши:
Рекомендации взяты от сюда и отсюда
Добавил данную статью в ФАК я и ссылку на страничку из Сообщества.
Статья не случайно помещена в FAQ

Насчет ссылок на шаблоны (кто может помочь?)
Я помогу ...
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



посмотрел-таки статью, уж больно активная дискуссия развернулась
вот у Вас там написано:
Основное действующее лицо:
Время (Таймер)
Второстепенные действующие лица:
Налоговое управление
Предусловия:
1. Конец налогового периода
Основной поток:
1. ВИ начинается в конце налогового периода

<конец цитаты>

Позволю себе внести поправку по основному потоку.
Несмотря на то, что в общем-то нет препятствий в использовании таймера как основного действующего лица, в данном конкретном случае его использование неудачно. Можно спросить у любого (!) бухгалтера (и гендиректора :о)), как он отнесся бы к автоматическому переводу денег по таймеру по какому-либо адресу, пусть даже по адресу Налогового управления. Наверняка бы обрадовался :о))
По-моему, правильнее было бы выполнять действия связанные с построением какой-нибудь отчетности.
И главное, в данном случае ДЕЙСТВИЕ ВЫПОЛНЯЕТ НЕ ТАЙМЕР (!), а система! Таймер лишь инициирует действие (!), более близким к делу было бы: пользователь выполняет действие путем выбора соответствующего пункта меню.

К тому же вызывает некоторое сомнение участие в выполнении прецедента пользователя "Налоговое управление", причем по двум причинам: а) реально оно в переводе денег все-таки не участвует (т.к. не запускает вариант использования), б) Налоговое управление не является "лицом" (оно многолико :о)))

Далее, очень размыто определено предусловие, если всё-таки говорить о некоей системе, пусть и довольно абстрактной. Думаю, этот пункт стоит дополнить каким-то конкретным комментарием, например: концом налоговых периодов являются полночь 31 марта, полночь 30 июня, полночь 30 сентября, полночь 31 декабря.
Кстати, несмотря на то, что налоговый период соответствует кварталу, тем не менее концом ОТЧЕТНОГО периода является другая дата (если память мне не изменяет +1 месяц, в течение которого должны быть осуществлены все налоговые платежи и подана соответствующая отчетность)

Мелочевку типа "платеж приходит в банк на счет налогового управления" я уже не учитываю.
Чуть ранее тоже хотел внести поправку "система посылает налоговое управление" :о))

...читаю дальше...

P.S. IMHO изначально неудачная задача взята для примера. Пусть даже он демонстрирует всего лишь структуру описания прецедента. Ведь читатели будут воспринимать и содержание описания тоже и будут делать из прочитанного неправильные выводы.
Поэтому гораздо лучше и читабельнее было бы привести все примеры из связанных кусков одной задачи.

Лью воду...



Так как данная статья залочена и видимо Эдом, пишу сюда:
1. Шаблон Коберна:
http://www.cs.colorado.edu/~kena/classes/6448/s01/examples/edmonb3.pdf
2. Шаблон Вигерса:
http://www.processimpact.com/process_assets/use_case_template.doc
3. Шаблон RUP
http://www.ts.mah.se/RUP/RationalUnifiedProcess/process/artifact/ar_uc.htm
4. Шаблон OpenUP
http://epf.eclipse.org/wikis/openup/core.tech.common.extend_supp/workproducts/use_case_22BE66E2.html?nodeId=9389783b
5. По ICONIX не нашел шаблона
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



Водолей,

Ты конечно прав, но (1) это учебный пример и (2) на западе немного легче с БУ чем у нас ...
Лучше, если бы ты предложил свои идеальные примеры.
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



Так как данная статья залочена и видимо Эдом, пишу сюда:
У меня из универа отвратительная связь именно с uml2.ru, потому произошло отключение в момент правки.
Исправил. Спасибо Саша.

Пока я не увидел конструктивной критики от Водолея (простите Водолей). Обсуждать мелочи можно бесконечно. Здесь представлены на мой взгляд хорошие примеры того, как следует писать ВИ. У нас часто и много задают вопросы по этому поводу. Теперь можно отослать их к FAQ.

Добавлю, что FAQ можно развивать дополняя примерами описания ВИ, которые мы можем считать эталонами.

В примерах, предложенных Арлоу и Нейштадтом, я не увидел серьезных противоречий. Да обсуждаемое, да может несколько не соответствует российским реалиями. Кстати вчера президент Медведев тоже посетовал на отсутствие в России нормального безбумажного электронного документооборота :)



Лучше, если бы ты предложил свои идеальные примеры.
Саша, обрати внимание, что стремление к идеалу - это последнее на что следует обращать внимания. Следует стремиться к простоте и ясности для окружающих. Тот факт, что оспариваемый ВИ несовершенен только и говорит, что он может быть будет нуждаться в доработке и уточнении. Это нормально



Цитата: bas
(1) это учебный пример и (2) на западе немного легче с БУ чем у нас ...
Лучше, если бы ты предложил свои идеальные примеры.

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

В идеальность чего бы то ни было я, признаться, не верю. От себя добавлю, что возможно было бы удобнее, если бы действия пользователя (пардон, основного действующего лица) были отделены от действий системы, в свое время мы писали их в два столбика - у пользователей это, кстати, идет на ура. Очень легко сопровождать скриншотами раскадровок.
К тому же в этом случае более очевидны точки ветвления, причем непосредственно в структуре описания прецедента указывая ссылку на альтернативный поток. Причем нумерацию пунктов альтернативных потоков лучше продолжать с точки ветвления. Это конечно требует определенных мыслительных усилий, но если вспомнить "здесь жирное пятно - рыбу заворачивали", вполне работает.

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

Цитата: Galogen
Здесь представлены на мой взгляд хорошие примеры того, как следует писать ВИ. У нас часто и много задают вопросы по этому поводу. Теперь можно отослать их к FAQ.

При всем уважении я бы позволил себе уточнить. С точки зрения структуры она один в один повторяет зарубежные примеры, так что тут нет предмета обсуждения ибо нет никакой новизны (кроме русскоязычного текста). С точки зрения содержания есть ряд вопросов, на что и обратил внимание. Обычный вопрос ведь заключается в том "ЧТО писать?" в простые и понятные пункты структуры.
Цитата: Galogen
Кстати вчера президент Медведев тоже посетовал на отсутствие в России нормального безбумажного электронного документооборота :)

это к чему? электронный документооборот в явном виде запрещен для государственных органов, только сегодня в очередной раз изучал первоисточники.  сложно поверить, что юрист этого не знает.
« Последнее редактирование: 09 Июня 2009, 00:35:37 от Водолей »
Лью воду...



При всем уважении я бы позволил себе уточнить. С точки зрения структуры она один в один повторяет зарубежные примеры, так что тут нет предмета обсуждения ибо нет никакой новизны (кроме русскоязычного текста). С точки зрения содержания есть ряд вопросов, на что и обратил внимание. Обычный вопрос ведь заключается в том "ЧТО писать?" в простые и понятные пункты структуры.
Нет точных и однозначных правил, о чем я сразу оговорился. И привел те примеры, которые на мой взгляд показывают досточно ясно общий принцип. Ни о какой новизне речь не идет. Какая новизна, побойтесь бога.

А вот что писать - вопрос другой - тема рекомендации по написанию спецификации. Что писать - можно понять только опытным путем



посмотрел-таки статью, уж больно активная дискуссия развернулась
вот у Вас там написано:
Основное действующее лицо:
Время (Таймер)
Второстепенные действующие лица:
Налоговое управление
Предусловия:
1. Конец налогового периода
Основной поток:
1. ВИ начинается в конце налогового периода

<конец цитаты>

Мне совершенно не нравится таймер в качестве действующего лица.
Каков для таймера значимый результат от уплаты налога с оборота?



Мне совершенно не нравится таймер в качестве действующего лица.
Каков для таймера значимый результат от уплаты налога с оборота?
Вне всякого сомнения, у таймера нет никакого интереса в уплате налога. Таймер действует от лица, естественно, заинтересованного, но в данном случае закулисного игрока. Я специально не стал подыскивать другой пример и отставил его как предложил автор (без его доп комментариев). Мне как раз хотелось отразить тот аспект, то инициирование ВИ может происходить и без участия человека, и что ДЛ может быть другая система (т.е. система обладающая поведением, но не имеющая осознаваемой цели).



Я правильно понимаю, что если система периодически выполняет какое-то действие, то у нас автоматом появляется Таймер?

Странно (неправильно) все это.
Таймер - деталь реализации. Он может появиться в сценарии, но не в качестве действующего лица.

ДЛ получает значимый результат от ВИ. Для таймера результата такого результата нет. Вывод: таймер не может быть ДЛ.

Предлагаю заменить Таймер на Бухгалтера (как вариант)



Я правильно понимаю, что если система периодически выполняет какое-то действие, то у нас автоматом появляется Таймер?
Нет, не так. В данном случае таймер - это событие, которое тоже может быть действующим лицом

Цитировать
Странно (неправильно) все это.
Таймер - деталь реализации. Он может появиться в сценарии, но не в качестве действующего лица.
В такой интерпретации - действительно странно

Читаем Коберна:
Цитировать
Обычно вариант использования стартует вследствие Toro, что основное действу-
ющее лицо посылает сообщение, нажимает на кнопку, на клавишу или инициирует
работу варианта использования каким-либо дрyrим способом. Однако существуют
две распространенные ситуации, коrда инициатором варианта использования явля-
ется не основное действующее лицо. В первом случае служащий компании или опе-
ратор на телефоне инициирует вариант использования от имени Koro-To еще, во
втором  вариант использования запускается по таймеру.
Наличие служащеrо компании или телефонноrо оператора часто удобно с TeXHO-
лоrической точки зрения для конечноrо OCHoBHoro действующеrо лица, которое дей-
ствительно имеет свой интерес. По мере развития технолоrии становится более
вероятным, что конечное основное действующее лицо будет инициировать или запус-
кать вариант использования непосредственно с помощью Интернета или автомати-
ческой телефонной системы. Примером служит клиент, который прямо сейчас
звонит и выдает запрос. С системой, переделанной д.пя работы в Интернете, клиент
сможет вводить свой запрос напрямую (как в Amazoп.com).
Подобным же образом подразделение маркетинrа или аудита может настаивать
на вариантах использования, с которыми работал бы служащий. Вариант использо-
вания как таковой служащему не нужен, просто он технолоrически удобен для MeHeд-
жеров по продажам. При несколько иных условиях менеджеры сами работали бы с
вариантами использования.
Сеrодня я пишу "торrовый представитель для клиента" или "служащий для OTдe-
ла маркетинrа", чтобы зафиксировать, чТО пользователь системы действует в инте-
ресах Koro-To еще. Разработать интерфейс пользователя и определить уровень
защиты необходимо д.пя служащеrо, а в результатах заинтересованы клиент или OT-
дел продаж.
Таймер - друrой пример запуска без оператора. Вариант использования запус-
кается каждую полночь или в конце месяца. В этом случае основное действующее
лицо - это какой-либо участник, заинтересованный в том, чтобы вариант использо-
вания работал в это самое время.
Можно вступить в продолжительную дискуссию и сравнивать пользователей с
конечными основными действующими лицами. Пред.паrаю вам не тратить слишком
MHoro времени на это. Если rруппа начинает исследовать вопросы проектирования
интерфейса пользователя, она затрачивает MHoro усилий на изучение реальных xa-
рактеристик пользователя (или ей следует это делать). Коrда разработчики paCCMOT-
рят требования, они поймут, что д.пя каждоrо варианта использования полезно знать
конечное основное действующее лицо, Т.е. Toro, кто действительно заинтересован в
результате. 

Цитировать
ДЛ получает значимый результат от ВИ. Для таймера результата такого результата нет. Вывод: таймер не может быть ДЛ.

Предлагаю заменить Таймер на Бухгалтера (как вариант)

Мои причины смотри ранее



Выполнил коррекцию статьи с учетом требования Дениса Иванова



IMHO нет одного важнейшего случая - пользовательской истории, а-ля:

"Бухгалтер может настроить систему так, чтобы по окончанию налогового периода она генерировала все документы,
нужные его фирме, чтобы оплатить налог с оборота, и присылала ему по электронной почте".



IMHO нет одного важнейшего случая - пользовательской истории, а-ля:

"Бухгалтер может настроить систему так, чтобы по окончанию налогового периода она генерировала все документы,
нужные его фирме, чтобы оплатить налог с оборота, и присылала ему по электронной почте".

Ребята - это не учебник как писать идеальные ВИ, это некоторые рекомендации по структуре и фразеологии при написании ВИ. Связях ВИ с альтернативными потоками, упрощения ВИ путем использования простых структур ветвления и циклов

Не смотрите на семантику, не заставляйте меня писать контекст и прочее. Это не цель рекомендаций. Я отталкиваюсь от того что человек знает, что ему писать. Я лишь  предлагаю форму. Не согласны - пишите статью в ответ :)




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19