Уважаемые коллеги!

Вы, наверно, уже знаете, что вышел Enterprise Architect 8.0. Ключевой фишкой новой версии стала возможность построения структурированых вариантов использования - т.е. появилась возможность строить сценарии по Коберну.
см. Построение основного сценария  http://al-kot.livejournal.com/1256.html
      Построение альтернативного сценария и создания диаграммы по струтурированному сценарию http://al-kot.livejournal.com/1474.html
      Генерация rtf-документа для структурированного UseCase. http://al-kot.livejournal.com/1586.html.


Приглашаю обсудить новые фишки ЕА и выработать методологию разработки требований с помощью вариантов использования.

Конечно подкупает возможность построения Д Действий и Д Последовательности на основании потоков ВИ

Отлично, Александр. Спасибо за работу. Действительно новая фишка очень и очень интересна, а справка по ней слишком бедная.

Ты молодец, что начал эту работу. Надеюсь, ты ее продолжишь с развитием и усложнением.

Избегай только логических и семантических ошибок!

Еще один пост про генерацию rtf-документа для структурированного UseCase. http://al-kot.livejournal.com/1586.html.

У нас вообще есть инструкция по rtf-генератору ЕА?

Еще один пост про генерацию rtf-документа для структурированного UseCase. http://al-kot.livejournal.com/1586.html.

У нас вообще есть инструкция по rtf-генератору ЕА?

Нет на русском нет. Я думаю нам следует делать не просто инструкцию, но с элементами своего практического опыта и возможно с шалонами и решениями.

Кстати у нас Саша уже работает wiki и блог. Так что я призываю тебя использовать его для размещения своих статей

Основные проблемы с этой фичей в том, что структурированные сценарии не позволяют сделать alternate or exception flow на шаге другого альтернативного потока. Сейчас все эксепшны и альт. потоки могут случиться только на шагах basic path. Вторая проблема - что из сгенеренной диаграмы можно получить сгенеренный сценарий только если диаграмма почти не менялась. Если менялась как следует - добавлены новые элементы например, генерация перестает работать.

Фича хороша для примитивного очень высокоуровнего описания юскейсов, не больше.

Если встретите решение какой-нибудь из этих 2х проблем - дай знать пожалуйста

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

Все это очень интересно. И полезно. Только не нужно искать очередную "серебряную пулю". И, к сожалению, это не UML.

У Коберна очень хорошие и полезные описания последовательностей взаимодействий (выполнения use case, варианта использования, я использую термин "прецедент" уже много лет, еще с UML версии 0.9). Но Коберн принципиально не использует UML. Он ему для его профессиональной деятельности не нужен.

А что такое "поток вариантов использования"? Для поклонников Коберна такое понятие вообще недопустимо (как и для поклонников UML). Это что, детерминированная последовательность выполнения прецедентов?

В первой ссылке этой темы есть диаграмма прецедентов, на которой из одного прецедента выходят стрелочки (сплошная с треугольной стрелкой) к нескольким другим. Это что за стрелочки. В спецификации UML это генерализация. А здесь что?

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

Технология простая, отработана давно. Я ее распространяю, когда меня приглашают внедрять IBM Rational или на курсах в моковском Интерфейсе.

>>А что такое "поток вариантов использования"?
>>Это что за стрелочки.
я думаю что стрелочки у автора топика означают либо "use" либо "include".
А вот это уже вполне нормально. Разбить сложный use case на несколько простых с возможностью переиспользовать в других use case.