Форум Сообщества Аналитиков
Обсуждения => Обсуждение статей => Тема начата: uml2.ru от 07 Июня 2009, 13:16:41
-
UML-стандарта для спецификации вариантов использования или прецедентов (кому, что нравиться) не существует. Однако существует ряд шаблонов, которыми Вы можете воспользоваться. Шаблон от Алистера Коберна. Шаблон от Карла Вигерса. Шаблон от RUP. Шаблон от ICONIX. Шаблон от OpenUP. И т.п. В конце концов Вы можете изобрести свой собственный шаблон. Нужно лишь придерживаться максимальной простоты. Ниже будут представлены рекомендации и примеры вариантов использования на базе следующего шаблона: Оригинал: Рекомендации по написанию спецификаций вариантов использования
-
Хорошая статейка. НО ИМХО хорошо бы вставить ссылки на шаблоны, про которые пишете:
Шаблон от Алистера Коберна. Шаблон от Карла Вигерса. Шаблон от RUP. Шаблон от ICONIX. Шаблон от OpenUP. И т.п
-
И еще, лучше ставить галочку - "публиковать на главной", чтобы данная статья появлялась в разделе "Что нового на сайте" на гл. странице ...
И указывать источник откуда это появилось ...
-
И еще, лучше ставить галочку - "публиковать на главной", чтобы данная статья появлялась в разделе "Что нового на сайте" на гл. странице ...
И указывать источник откуда это появилось ...
Публикация добавлена в раздел FAQ, а блок "Что нового на сайте" ограничен разделом "Статьи".
Я бы снял ограничение по разделам - пусть там отображаются ссылки вообще на все новые материалы.
-
Я бы снял ограничение по разделам - пусть там отображаются ссылки вообще на все новые материалы.
Ну можно и так ...
-
Вопрос по статье.
Чем отличается запуск ВИ от инициирования ВИ?
Цитата из статьи
>> Стоит отметить, что спецификация UML не определяет способа представления ветвления и повторения в потоке.
Все есть.
Цитата из статьи
>>UML-стандарта для спецификации вариантов использования или прецедентов (кому, что нравиться) не существует.
1) UML-стандарта нет и быть не может. UML - это язык. Точно также нет стандарта для написания рассказов на русском языке или программ на C++.
2) Все, что написано в статье может быть нарисовано диаграммами UML (и будет выглядеть кстати понятнее, чем просто форматированный текст)
3) По поводу прецедента - сюда (http://blog.it-konsulting.spb.ru/?p=243)
4) В слове "нравится" мягкий знак не нужен:)
Bas, если статьи печатаются от имени членов сообщества (я именно так расцениваю логин - uml2.ru), то я бы минимум проводил review.
-
А автор у статьи есть?
А то я заголовок вижу, статью вижу, а фамилии автора не вижу. Не там смотрю?
-
2) Все, что написано в статье может быть нарисовано диаграммами UML (и будет выглядеть кстати понятнее, чем просто форматированный текст)
Может, но на это нет явного указания в спецификации, что и имел в виду автор.
3) По поводу прецедента - сюда (http://blog.it-konsulting.spb.ru/?p=243)
Если не возражаешь, я опубликую это в ФАКе, со ссылкой на тебя
Bas, если статьи печатаются от имени членов сообщества (я именно так расцениваю логин - uml2.ru), то я бы минимум проводил review.
Для этого и было создано обсуждение этого вопроса. Но ИМХО твои замечания рабочие, которые исправит автор если сочтет нужным...
-
Может, но на это нет явного указания в спецификации, что и имел в виду автор.
Это все равно, что утвержать, что на C++ нельзя написать программу вычисления площади треугольника, потому что в спеке этого нет.
"Лютер и Кальвин категорически не признавали открытий Коперника, потому что об этом ничего не было сказано в Библии"
Л.Н. Гумилев
Если не возражаешь, я опубликую это в ФАКе, со ссылкой на тебя
Давай. Я сам скоро займусь теми FAQs, о которых мы говорили.
Для этого и было создано обсуждение этого вопроса. Но ИМХО твои замечания рабочие, которые исправит автор если сочтет нужным...
Тогда пусть автор подпишется.
-
Денис,
Зная твое трепетное отношение к спецификации ЮМЛ, спорить не буду ;)
Хорошо, публикуй сам. Но ИМХО вопросы по ВИ нужно публиковать именно в раздел про ВИ (у тебя права есть), со ссылкой на тебя. Также желательно публиковать полный текст ответа на юмл2.ру и в конце ставить ссылку на твой Блог.
-
Тогда пусть автор подпишется.
Автор - Galogen, он скорее всего, на сайте если появится, то только к вечеру. Но на то и форум, чтобы обсуждать.
2) Все, что написано в статье может быть нарисовано диаграммами UML (и будет выглядеть кстати понятнее, чем просто форматированный текст)
А почему понятнее?
Bas, если статьи печатаются от имени членов сообщества (я именно так расцениваю логин - uml2.ru), то я бы минимум проводил review.
Это имя подставляет компонент обсуждения автоматически при создании темы. Но его легко можно изменить. Принимаются любые предложения.
-
А почему понятнее?
Потому что картинка нагляднее текста
-
Потому что картинка нагляднее текста
А можешь нарисовать картинку по тому примеру, который приведён в статье, со всеми потоками?
-
Как-нибудь сделаю. Если есть конкретный вопрос - задавай.
-
Автор статьи - я.
То, что нет вывода автора - это вопрос настройки вывода контента, в FAQ я не хотел бы говорить от своего имени. Тем более рекомендации выполнены согласно книги UML2 и унифицированный процесс Арлоу и Нейштадта
Статья не случайно помещена в FAQ
Ошибки стилистические и грамматические исправлю. Насчет ссылок на шаблоны (кто может помочь?)
-
Автор статья я.
То что нет вывода автора - это вопрос настройки вывода контента, в 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 можно развивать дополняя примерами описания ВИ, которые мы можем считать эталонами.
В примерах, предложенных Арлоу и Нейштадтом, я не увидел серьезных противоречий. Да обсуждаемое, да может несколько не соответствует российским реалиями. Кстати вчера президент Медведев тоже посетовал на отсутствие в России нормального безбумажного электронного документооборота :)
-
Лучше, если бы ты предложил свои идеальные примеры.
Саша, обрати внимание, что стремление к идеалу - это последнее на что следует обращать внимания. Следует стремиться к простоте и ясности для окружающих. Тот факт, что оспариваемый ВИ несовершенен только и говорит, что он может быть будет нуждаться в доработке и уточнении. Это нормально
-
(1) это учебный пример и (2) на западе немного легче с БУ чем у нас ...
Лучше, если бы ты предложил свои идеальные примеры.
по первому: нисколько не сомневаюсь, именно поэтому считаю, что примеры в подобных случаях должны быть тщательно вылизаны несмотря на их надуманность. иначе неопытный человек не сможет отличить правильные характерные особенности (в данном случае некоей предметной области) от наведенных ошибок.
по второму: есть некоторые сомнения :о)) планы счетов конечно отличаются, но основные отличия кроются совсем не в бухучете. прародитель ведь один - двойная запись флорентийских купцов.
В идеальность чего бы то ни было я, признаться, не верю. От себя добавлю, что возможно было бы удобнее, если бы действия пользователя (пардон, основного действующего лица) были отделены от действий системы, в свое время мы писали их в два столбика - у пользователей это, кстати, идет на ура. Очень легко сопровождать скриншотами раскадровок.
К тому же в этом случае более очевидны точки ветвления, причем непосредственно в структуре описания прецедента указывая ссылку на альтернативный поток. Причем нумерацию пунктов альтернативных потоков лучше продолжать с точки ветвления. Это конечно требует определенных мыслительных усилий, но если вспомнить "здесь жирное пятно - рыбу заворачивали", вполне работает.
Если речь про тематику примеров, можно взять любую, от набившего оскомину банкомата или заказа билетов, до чего-нибудь более экзотического, типа удаленного тестирования, или, как по одной из ссылок, где описывается пожарная сигнализация. Ну а вообще попроще надо бы, пообщеизвестней, например, в какой-то соседней теме (уже не вспомню какой) предлагалось описать прецеденты при посещении столовой во время обеденного перерыва.
Здесь представлены на мой взгляд хорошие примеры того, как следует писать ВИ. У нас часто и много задают вопросы по этому поводу. Теперь можно отослать их к FAQ.
При всем уважении я бы позволил себе уточнить. С точки зрения структуры она один в один повторяет зарубежные примеры, так что тут нет предмета обсуждения ибо нет никакой новизны (кроме русскоязычного текста). С точки зрения содержания есть ряд вопросов, на что и обратил внимание. Обычный вопрос ведь заключается в том "ЧТО писать?" в простые и понятные пункты структуры.
Кстати вчера президент Медведев тоже посетовал на отсутствие в России нормального безбумажного электронного документооборота :)
это к чему? электронный документооборот в явном виде запрещен для государственных органов, только сегодня в очередной раз изучал первоисточники. сложно поверить, что юрист этого не знает.
-
При всем уважении я бы позволил себе уточнить. С точки зрения структуры она один в один повторяет зарубежные примеры, так что тут нет предмета обсуждения ибо нет никакой новизны (кроме русскоязычного текста). С точки зрения содержания есть ряд вопросов, на что и обратил внимание. Обычный вопрос ведь заключается в том "ЧТО писать?" в простые и понятные пункты структуры.
Нет точных и однозначных правил, о чем я сразу оговорился. И привел те примеры, которые на мой взгляд показывают досточно ясно общий принцип. Ни о какой новизне речь не идет. Какая новизна, побойтесь бога.
А вот что писать - вопрос другой - тема рекомендации по написанию спецификации. Что писать - можно понять только опытным путем
-
посмотрел-таки статью, уж больно активная дискуссия развернулась
вот у Вас там написано:
Основное действующее лицо:
Время (Таймер)
Второстепенные действующие лица:
Налоговое управление
Предусловия:
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 нет одного важнейшего случая - пользовательской истории, а-ля:
"Бухгалтер может настроить систему так, чтобы по окончанию налогового периода она генерировала все документы,
нужные его фирме, чтобы оплатить налог с оборота, и присылала ему по электронной почте".
Ребята - это не учебник как писать идеальные ВИ, это некоторые рекомендации по структуре и фразеологии при написании ВИ. Связях ВИ с альтернативными потоками, упрощения ВИ путем использования простых структур ветвления и циклов
Не смотрите на семантику, не заставляйте меня писать контекст и прочее. Это не цель рекомендаций. Я отталкиваюсь от того что человек знает, что ему писать. Я лишь предлагаю форму. Не согласны - пишите статью в ответ :)
-
Согласен, не учебник, а справочник :) .
Эдуард, мой пост ни в коем случае не критика. Просто сейчас распространяются всевозможные гибкие методологии, в которых вместо UC и требований в обычном виде зачастую применяются "пользовательские истории". Простые, конкретные, понятные всем (от программиста до инвестора), проверяемые за полчаса-час демонстрации результатов итерации.
IMHO взялся писать (уже респект!), попал в ЧаВо - кому как не тебе поддерживать и дополнять :) ?
-
Почему в статье ничего не написано про исключения (Exception)?
-
Почему в статье ничего не написано про исключения (Exception)?
Exeption - это частный случай альтернативного потока событий, который приводит к завершению варианта использования. Можно оформлять как альтернативные потоки, можно как исключения. Кому как удобней. Я предпочитаю исключения писать отдельно, так как их можно связывать с сообщениями об ошибке, храня их где-нибудь отдельно
-
Exeption - это частный случай альтернативного потока событий, который приводит к завершению варианта использования. Можно оформлять как альтернативные потоки, можно как исключения. Кому как удобней. Я предпочитаю исключения писать отдельно, так как их можно связывать с сообщениями об ошибке, храня их где-нибудь отдельно
На мой взгляд, выделение исключений в отдельную часть описания UC является необходимым шагом, который позволит значительно снизить количество ошибок при составлении очередного среза версии системы. Exceptions и Alternative courses - это разные типы сценариев, не все альтернативные направления нужно реализовывать в каждой версии системы, но необходимо предусмотреть обработку всех (выявленных) исключений в любой версии, иначе возникнет сбой системы.
Позволю себе процитировать Карла Вигерса ("Разработка требований к программному обеспечению"):
"Если в процессе сбора информации вы не укажете, как обрабатывать исключение, то возможны два пути:
1. разработчики предложат лучший по их мнению способ обработки исключений;
2. при генерации пользователем неверного условия произойдет сбой системы, так как никто не предусмотрел такой ситуации.
Бьюсь об заклад, что сбои системы не входят в список требований пользователей."
"Иногда исключения рассматриваются как тип альтернативного направления (Cockburn, 2001), однако эти понятия следует разделять. Не обязательно реализовывать каждое альтернативное направление, которое вы определили для варианта использования; кроме того, вы можете отложить его реализацию до следующего выпуска. Однако вы обязаны реализовать исключения, из-за которых завершение сценариев может оказаться неуспешным. Любой, кто когда-либо занимался программированием, знает, что часто именно на работу над исключениями приходится большая часть программирования. Многие недостатки конечного продукта присущи именно обработчикам исключений (или происходят из-за их отсутствия!)".
-
IMHO взялся писать (уже респект!), попал в ЧаВо - кому как не тебе поддерживать и дополнять :) ?
Саша, спасибо. Спасибо и за критику. Я вовсе не обижаюсь или негативно реагирую на критику. Просто как бы статья о другом, за что меня критикуют :)
Насчет пользовательских историй - наверное нужно помещать в ЧАВО, типа как писать требования :)
-
Почему в статье ничего не написано про исключения (Exception)?
А почему там должно что-то быть написано?
-
Exeption - это частный случай альтернативного потока событий, который приводит к завершению варианта использования.
Виталий - ты не прав. Базовый вариант использования может прекрасно обходится без расширений. Он ничего о них может и не знать. Ну и естественно прекрасно завершаться.
Описания правил по структуризации ВИ несколько позже
-
А почему там должно что-то быть написано?
1. Потому что исключения имеют непосредственное отношение к спецификации варианта использования.
2. Потому что исключения даже более важны, чем альтернативные потоки, про которые вы не преминули написать (если конечно, вы не подразумеваете исключения как частный случай альтернативного направления).
3. В конце концов потому, что статья называется "Рекомендации по написанию спецификаций вариантов использования".
P.S.
Расширения = альтернативные потоки?
Вы вообще это пишете для последующего практического применения специалистами или для чего?
-
Виталий - ты не прав. Базовый вариант использования может прекрасно обходится без расширений. Он ничего о них может и не знать. Ну и естественно прекрасно завершаться.
Описания правил по структуризации ВИ несколько позже
Прекрасно завершаться? Интересно как, только на бумаге?
-
Вы вообще это пишете для последующего практического применения специалистами или для чего?
Velarix, напишите свою статью. Я уверен, что на uml2.ru её с удовольствием опубликуют.
-
Velarix, напишите свою статью. Я уверен, что на uml2.ru её с удовольствием опубликуют.
Ничуть не сомневаюсь =) Возможно, месяца через три.
-
Вы вообще это пишете для последующего практического применения специалистами или для чего?
Причины разные. В том числе получить удовольствие. И возможно научиться. Обучая - учимся.
-
Интересно как, только на бумаге?
Не очень понял вопроса
-
Не очень понял вопроса
Как может реальный (не идеальный) прецедент реального (не идеального) пользователя прекрасно завершаться без расширений, в которые, насколько я понимаю, вы включаете и исключения (в статье вы их назвали ошибками)?
-
Как может реальный (не идеальный) прецедент реального (не идеального) пользователя прекрасно завершаться без расширений, в которые, насколько я понимаю, вы включаете и исключения (в статье вы их назвали ошибками)?
Давайте немного подождем до момента, когда я подойду к включениям и расширениям.
Пока у меня есть впечатление, что вы путаете эти два понятия: включение и расширение.
Разница в следующем.
Базовый ВИ, ВКЛЮЧАЮЩИЙ другой фрагмент, не может быть завершен без включения последнего. Это как require в рнр или Си
Базовый ВИ, расширяемый другим фрагментом, прекрасно обойдется без последнего, если не возникнет условий, определенных в точке расширения.
Если же условия возникли и расширяющий фрагмент включается в поток, то он самом деле не включается в основной поток - а порождает альтернативный поток, в отличии от случая ВКЛЮЧЕНИЯ
-
Давайте немного подождем до момента, когда я подойду к включениям и расширениям.
Пока у меня есть впечатление, что вы путаете эти два понятия: включение и расширение.
Разница в следующем.
Базовый ВИ, ВКЛЮЧАЮЩИЙ другой фрагмент, не может быть завершен без включения последнего. Это как require в рнр или Си
Базовый ВИ, расширяемый другим фрагментом, прекрасно обойдется без последнего, если не возникнет условий, определенных в точке расширения.
Если же условия возникли и расширяющий фрагмент включается в поток, то он самом деле не включается в основной поток - а порождает альтернативный поток, в отличии от случая ВКЛЮЧЕНИЯ
Прошу обратить внимание на тот факт, что до вашего ответа на комментарий Виталия, речь совсем не шла о расширениях. Заданный мной вопрос не касается отношений включения и расширения, он касается только альтернативных потоков и исключений.
Для вас Расширения = Альтернативные потоки? Иначе зачем вы ответили про расширения, когда Виталий писал про альтернативные потоки?
И что вы подразумеваете под "фрагментом"?
-
Velarix, что вы тут устроили рубилово на пустом месте.
Вигерс выделяет альтернативы и исключения, Коберн не выделяет. Это 2 разных школы по сути со своей мотивацией.
У нас в анализе действует правило постепенности и итеративности описания требований.
Сначала выделяем способы применения как таковые, потом расписываем базовый сценарий в краткой форме, затем, по мере наличия смысла/ресурсов — расписываем основной поток пошагово, затем, по мере наличия смысла/ресурсов — расписываем альтернативные потоки.
Делить альтернативные потоки на успешные и неуспешные — это уже детализация, до которой на уровне вводной статьи доходить не стоит.
-
Думаю, такой "перекрёстный обстрел" может сильно понизить желание писать какие-либо статьи.
Писать бы статьи в виде публикаций wiki, с поддержкой версий, просмотра отличий и лентой новостей на изменённые статьи. Так, что если автор разрешил - любой может дописать статью, а принимать или не принимать изменения в осовную, показываемую версию - решать либо автору, либо людям, которым он это делегировал.
Мы в компании именно с помощью wiki это решаем. Хочешь поспорить - пиши/дописывай. Если же писать не хочешь или не можешь - значит, несогласие несущественно.
----
Моё личное мнение по поводу "исключений", и вообще по поводу сверхдетального описания всего и вся в UC: сложно, не работает. Не читают. Всё равно делают по-своему.
Если есть какой-то важный, но простой альтернативный поток - можно написать в UC. Ну а сколь-нибудь сложную логику я обычно описываю в activity, statechart, иногда даже sequence, прикреплённых к этому UC.
Если что-то опустил/упустил - при нормально налаженных рабочих и человеческих отношениях, программисты всегда переспросят "а как нужно-то"? А при отсутствии таких отношений даже сверхдетальный документ тоже слабо помогает. Разве что потом, при "разборе полётов", чтобы стало понятно, кого наказывать... Но ведь цель не наказать за то, что неправильно сделали, а сделать правильно.
-
Velarix, что вы тут устроили рубилово на пустом месте.
Вигерс выделяет альтернативы и исключения, Коберн не выделяет. Это 2 разных школы по сути со своей мотивацией.
У нас в анализе действует правило постепенности и итеративности описания требований.
Сначала выделяем способы применения как таковые, потом расписываем базовый сценарий в краткой форме, затем, по мере наличия смысла/ресурсов — расписываем основной поток пошагово, затем, по мере наличия смысла/ресурсов — расписываем альтернативные потоки.
Делить альтернативные потоки на успешные и неуспешные — это уже детализация, до которой на уровне вводной статьи доходить не стоит.
Денис, ни о каком "рубилове" и речи нет! Я считаю, что подобное обсуждение - это нормальный процесс, и профессионал никогда не будет уклоняться от дискуссий на тему того, что он пишет/утверждает.
Прошу перечитать мои сообщения выше, потому что повторяться не хочется... Альтернативные потоки и исключения - разные артефакты, причём последний на порядок важнее. Исходя из вышесказанного, я полагаю, что раз уж затронули альтернативные потоки, то необходимо заострить внимание и на исключениях.
Безусловно, за каждым остаётся право писать всё, что ему взбредёт в голову, и не считаться ни с чьим мнением. К тому же автор уже сказал, что он пишет для того, чтобы самому учиться и для удовольствия, хотя изначально (исходя из наименования статьи) я предположил, что она адресована практикам.
В общем желаю, чтобы практикам в настоящем виде эта статья на глаза не попадалась.
-
Думаю, такой "перекрёстный обстрел" может сильно понизить желание писать какие-либо статьи.
Писать бы статьи в виде публикаций wiki, с поддержкой версий, просмотра отличий и лентой новостей на изменённые статьи. Так, что если автор разрешил - любой может дописать статью, а принимать или не принимать изменения в осовную, показываемую версию - решать либо автору, либо людям, которым он это делегировал.
Мы в компании именно с помощью wiki это решаем. Хочешь поспорить - пиши/дописывай. Если же писать не хочешь или не можешь - значит, несогласие несущественно.
----
Моё личное мнение по поводу "исключений", и вообще по поводу сверхдетального описания всего и вся в UC: сложно, не работает. Не читают. Всё равно делают по-своему.
Если есть какой-то важный, но простой альтернативный поток - можно написать в UC. Ну а сколь-нибудь сложную логику я обычно описываю в activity, statechart, иногда даже sequence, прикреплённых к этому UC.
Если что-то опустил/упустил - при нормально налаженных рабочих и человеческих отношениях, программисты всегда переспросят "а как нужно-то"? А при отсутствии таких отношений даже сверхдетальный документ тоже слабо помогает. Разве что потом, при "разборе полётов", чтобы стало понятно, кого наказывать... Но ведь цель не наказать за то, что неправильно сделали, а сделать правильно.
Как это не работает? По моему, от аналитика зависит, работает или не работает. Кто "не читают"? Кто эти спецификации должен читать и что делать на их основании?
-
Денис, советую перечитать мои сообщения выше, потому что повторяться не хочется... Альтернативные потоки и исключения - разные артефакты. Причём последний на порядок важнее. Исходя из вышесказанного, я полагаю, что раз уж затронули альтернативные потоки, то необходимо заострить внимание и на исключениях.
Почему "на порядок важнее"? Обоснуйте. А то у нас на форуме не принято верить на слово. ;)
В общем желаю, чтобы практикам в настоящем виде эта статья на глаза не попадалась.
И будут бедные практики, как и прежде, блуждать в потёмках. :)
-
Писать бы статьи в виде публикаций wiki
Саша, читаешь мысли. За то время, что мы тут потратили на перепалку, вполне можно было написать уже всё в вики.
-
профессионал никогда не будет уклонятся
мягкий знак?
Денис, советую перечитать мои сообщения выше, потому что повторяться не хочется... Альтернативные потоки и исключения - разные артефакты.
С каких пор потоки стали артефактами?
Причём последний на порядок важнее. Исходя из вышесказанного, я полагаю, что раз уж затронули альтернативные потоки, то необходимо заострить внимание и на исключениях.
С какой стати неуспешные завершения важнее успешных?
…автор уже сказал, что он пишет для того, чтобы самому учится.
мягкий знак?
В общем желаю, чтобы практикам в настоящем виде эта статья на глаза не попадалась.
Практики на то и практики, что статей не читают, а всё на своём опыте изучают — методом проб и ошибок.
А вообще вот так хорошо сидеть и желать. Если вам настолько интересна эта тема — напишите про важность исключений (терминальных потоков) хотя бы заметку.
-
Почему "на порядок важнее"? Обоснуйте. А то у нас на форуме не принято верить на слово. ;)
Написал выше, даже цитаты привёл =)
И будут бедные практики, как и прежде, блуждать в потёмках. :)
Зачем же блуждать в потёмках, когда можно прочитать того же Вигерса или Коберна.
-
Почему в статье ничего не написано про исключения (Exception)?
Exeption - это частный случай альтернативного потока событий, который приводит к завершению варианта использования. Можно оформлять как альтернативные потоки, можно как исключения. Кому как удобней. Я предпочитаю исключения писать отдельно, так как их можно связывать с сообщениями об ошибке, храня их где-нибудь отдельно
1. Потому что исключения имеют непосредственное отношение к спецификации варианта использования.
2. Потому что исключения даже более важны, чем альтернативные потоки, про которые вы не преминули написать (если конечно, вы не подразумеваете исключения как частный случай альтернативного направления).
3. В конце концов потому, что статья называется "Рекомендации по написанию спецификаций вариантов использования".
P.S.
Расширения = альтернативные потоки?
Вы вообще это пишете для последующего практического применения специалистами или для чего?
Где, какие противоречия, Velarix? Я заметил неточность (на мой взгляд) в сообщении Виталия и ему ответил. Вы тоже вступили в дискуссию. А потом стали утверждать, что Вас проигнорировали и перевели разговор на иную тему. Ну Вы можете иметь такую точку зрения...
Я сказал, что буду еще писать дальше...
Далее я отталкиваюсь от материалов книги, которую указываю в тексте статьи. Отталкиваюсь и потому, что сведения, которые даны в этой книге, не противоречат никаким сведениям других авторов и представлены, по моему мнению, в такой форме, которую можно рекомендовать для изучения.
При этом читатель может получить дополнительные знания из первоисточника, сам прочитав книгу, в английской или русской редакции.
Я не разделяю Вашего взгляда, что следует разделять понятие альтернативного потока, исключения и т.п. Исключение - это нарушение основного потока, следовательно, альтернативный путь, возникший в результате возникновения исключения. Я согласен с Коберном, что альтернативные потоки (исключения или перехватывания ошибок, например), зачастую важнее, чем основной поток.
Объяснить это можно тем, что основной поток часто лежит на поверхности, а вот извлечение "подводных" потоков, не очевидных и сразу не распознаваемых, довольно сложно и показывает профессионализм аналитика.
-
Саша, читаешь мысли. За то время, что мы тут потратили на перепалку, вполне можно было написать уже всё в вики.
Григорий, может изучить возможность прикручивания wiki к Joomla (есть разные пути) и продумать предложения?
Вообще обсуждения статьей через форум, как я вижу, имеют большой положительный резонанс, несмотря на "жестокую" критику :)
-
мягкий знак?
Да, это вы правильно заметили. Торопился, отвечал уже перед уходом, и случайно пропустил мягкие знаки. Уже исправил, приношу извинения.
С каких пор потоки стали артефактами?
Глоссарий.ru:
Артефакт исследования - процесс, явление, образование, не свойственные изучаемому объекту как таковому и возникающие в ходе его исследования вследствие применения теорий, методов, инструментов, организационных приемов.
Г Буч, Д Рамбо, А Джекобсон ("Язык UML Руководство пользователя" второе издание):
Артефакт - элемент информации, используемый или порождаемый в процессе разработки программного обеспечения.
Моделирование взаимодействия пользователя с системой является порождением новых элементов информации. Приведите своё определение.
С какой стати неуспешные завершения важнее успешных?
Повторюсь, что я пишу об альтернативных потоках и исключениях, почему последние важнее, написал выше.
Что вы понимаете под неуспешными и успешными завершениями?
Практики на то и практики, что статей не читают, а всё на своём опыте изучают — методом проб и ошибок.
Греч. praktike, от praktikós - деятельный, активный. Соответственно под словом "практик" я подразумеваю человека, который практически использует обсуждаемые знания.
А вообще вот так хорошо сидеть и желать. Если вам настолько интересна эта тема — напишите про важность исключений (терминальных потоков) хотя бы заметку.
Обязательно напишу, когда буду достаточно уверен в своих знаниях, а также в том, что смогу сообщить читателям нечто большее, чем то, что написано в общедоступных книгах.
-
Где, какие противоречия, Velarix? Я заметил неточность (на мой взгляд) в сообщении Виталия и ему ответил. Вы тоже вступили в дискуссию. А потом стали утверждать, что Вас проигнорировали и перевели разговор на иную тему. Ну Вы можете иметь такую точку зрения...
Виталий написал:
Exeption - это частный случай альтернативного потока событий, который приводит к завершению варианта использования.
Вы ответили:
Виталий - ты не прав. Базовый вариант использования может прекрасно обходится без расширений. Он ничего о них может и не знать. Ну и естественно прекрасно завершаться.
Вопрос: почему, когда Виталий говорил об альтернативных потоках, вы ответили про расширения?
Исключение - это нарушение основного потока, следовательно, альтернативный путь, возникший в результате возникновения исключения.
Исключения касаются не только основного потока, но и альтернативных. Или вы считаете, что в альтернативных потоках не может быть исключений?
-
:) Вот такие дискуссии и приводят к реальным результатам.
Кто-то выше спрашивал про удачное и неудачное завершение вариантов использования.
Вариант использования всегда имеет цель - цель пользователя.
1. Если пользователь достиг свою цель полностью (или частично) такой сценарий называется удачным.
2. Если пользователь не достиг своей цели - сценарий считается неудачным и ВИ завершается "отрицательно".
Основной поток событий - это наиболее простой и часто встречаемый (используемый) на практике сценарий достижения полного успеха. Описание всегда начинаем с него и в кратком описании тоже пишем основные его куски.
Далее спускаемся с небес на землю и понимаем, что чудес не бывает. Начинаем описывать исключения к основному потоку событий для того, что реализовать его корректно и в продакшине сценарий "не слетел" с сообщением типа "Fatal error! java.exeption... :)"
После того, как мы уверены в описанных шагах начинаем задумываться об альтернативных потоках событий, подразумевая под ними альтернативные способы достижения успеха. К каждому алтернативному потоку также описываем исключения, чтобы при отработке сценария в системе не вывалился exception и программист знал как его отработать.
О том как их записывать и разделять или нет - это дело вкуса. ИМХО, даже спорить не нужно.
Я лишь советую помечать исключения или писать отдельно только для того, что так удобней работать программистам - проверено на практике. Они сразу видят как надо реализовать exceptions.
А Эду отдельный респект за статью. Осталось дописать сюда как вклинивать в описание вариантов использования включения и расширения и возможность стартовать и заканчивать в нескольких точках. Я себя отношу к данной школе описания ВИ :). Старая школа считает, что точка входа может быть всего одна.
PS ВИ представляют собой описание алгоритма работы системы на более высоком уровне абстракции. Проще и практичнее накидать сценарий, чем рисовать диаграммы (опять же проверено опытом). Поэтому введение таких понятий как цикличность и условия в поток событий сильно расширяют возможности системных вариантов использования.
Velarix, посмотрите топик про описание системных вариантов использования здесь (http://www.uml2.ru/forum/index.php?topic=1083.0) и про сценарии здесь (http://www.uml2.ru/forum/index.php?action=dlattach;topic=976.0;attach=915)
Связанные вещи.
-
Исключения касаются не только основного потока, но и альтернативных. Или вы считаете, что в альтернативных потоках не может быть исключений?
Это возможно, если альтернативный путь не является исключительной ситуацией.
-
Отвечу немного в другом порядке.
Кто "не читают"? Кто эти спецификации должен читать и что делать на их основании?
Читать нужно:
1) тем, кто проектирует артефакт (архитекторы) - на выходе проект и/или прототипы
2) тем, кто формирует, распределяет и оценивает задачи (менеджеры проекта) - на выходе план
3) [часто, но не всегда] тем, кто реализует артефакт, выполняющий требования (программисты, технические писатели, инженеры) - на выходе артефакт
4) тем, кто проверяет выполнение требований (тестировщики) - на выходе последовательности, программы и методики тестирования, затем дефекты артефакта
5) [иногда] тем, кто заказывает и оплачивает разработку артефакта - на выходе решение о дальнейшей судьбе проекта.
И конечно, у каждого на выходе могут быть дополнения и корректировки спецификации поведения артефакта. Часть из которых может быть по форме и по сути, часть - связана с процессом изучения и человеческим фактором (желанием поучаствовать).
О том, что кто-то кому-то должен - я бы не стал говорить. Если участники понимают, что чтение приносит им пользу - они будут читать. Если не понимают - не будут.
Как это не работает?
Участники (1) - (5) тратят слишком много времени на то, чтобы прочитать и понять требуемое поведение артефакта (в т.ч. нужно множество итераций согласования и коррекции) и/или в результате получается не то, что написано в спецификации.
По моему, от аналитика зависит, работает или не работает.
И да, и нет. Можно предоставить спецификации - но нельзя заставить хорошо работать в соответствии с ними.
С одной стороны, это действительно зависит от того, насколько хорошо (качественно по содержанию, доступно по форме) аналитик спроектировал поведение артефакта.
С другой стороны - насколько это описание соответствует ожиданиям и мнению других участников.
С третьей - есть ещё человеческий фактор: не все могут читать подробные спецификации в силу своего склада ума и темперамента (см., например, Rainwater "Herding Cats" и типологую Майерса-Бриггса), не у всех для этого есть мотивация.
----
Опять же, это всё - по моему мнению и на основании моей практики. Может статься, что Ваша команда действительно не испытывает проблем при чтении объёмных и сложных по форме спецификаций, и что программисты не рассматривают детальное описание поведения системы как вмешательство в творческую часть своей работы.
-
Виталий написал:
Exeption - это частный случай альтернативного потока событий, который приводит к завершению варианта использования.
Тут моя ошибка. Пример пропуска-фильтрации, искажения и обощения. Слово Exeption, под влиянием момента, вопринималось мною как Extention, поскольку я в тот момент активно обдумывал вопросы с включениями и расширениями
-
Вот читаю и думаю, что нам всем нужен авторитетный, корректный и полный русский словарь терминов, которыми можно оперировать, понимая друг друга. Он должен быть выложен в интернете, и принят как стандарт (как uml, например). Ну и естественно, он должен инкрементально расширяться и дополняться, быть живым.
Вопрос к участникам обсуждения: вы на какой (какие?) словарь опираетесь?