Здравствуйте

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

Собственно, вопрос вот в чем - предположим, пользователь нажимает одну из кнопок в окне веб-формы, и в зависимости от этого могут выполняться различные потоки действий. Понятно, что по-нормальному надо из этих юскейсов сделать линки на Sequence Diagram и радоваться жизни. Но! После всего придется, на каждое более-менее объемное действие в этой диаграмме, писать SRS, в которой придется генерить более мелкие юскейсы, вытекающие из этой Sequence Diagram, и вот их-то уже не знаю, куда и приткнуть на UML диаграмме. В свою очередь, эти юскейсы будут указывать на свои диаграммы последовательности и так далее.

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

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

Вы знаете про уровни ВИ от Коберна или о ВИ реализации в РУП?

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

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

что такого необычного и уникального в вашей системе, что ей понадобилось более 300 (!) кнопок (как вы пишете), за каждой из которых "следует" уникальный во всём use case? это система управления ядерным реактором?

Уровни вариантов использования существуют. Начните с того,что причешите модель - обычно 300 вариантов использования это ОЧЕНЬ не маленькая система с разработкой на несколько лет. Возможно они у вас представлены на уровне функций. Если в описании у вас 1-3 действия то скорее всего вы описываете операции в виде ВИ. В таком случае можно объединить их вместе.
Далее разложите по пакетам сгруппировав например по смыслу. После того, как увидите структуру системы можно бить на компоненты. Я советую для каждого пакета рисовать отдельную диаграмму и разделять так, чтобы в пакетах было до 10 ВИ.
Почитайте приложенные материалы, надеюсь все поймете.

Виталий, что за книга?

Виталий, что за книга?

Use Cases Patterns and Blueprints
By Gunnar Övergaard, Karin Palmkvist
   
Publisher : Addison Wesley Professional
Pub Date : November 12, 2004
ISBN : 0-13-145134-0
Pages : 464

спасибо

что такого необычного и уникального в вашей системе, что ей понадобилось более 300 (!) кнопок (как вы пишете), за каждой из которых "следует" уникальный во всём use case? это система управления ядерным реактором?

Странное у Вас представление о сложной системе.

На днях пришлось воспользоваться лет 5 назад разработанным редактором символов для ГИС.

Время прошло много, все уже забылось, и когда я туда заглянул, то мое настроение резко ухудшилось (работа была срочная и критическая).  Боюсь обмануть в количестве, но 200 вариантов использования есть только в редакторе символов, а сколькое еще реализовано собственно в клиентской части ГИС (автономная работа) + при отображении реальной информации из базы + взаимодействие с сервером приложений.

Для пояснения. Книжка с кратким перечнем символов и описанием основных правил их отображения занимает 520стр (в новой редакции). Почти половина символов имеет особенности в отображении, формировании подписи, при наложениях, при групповом и одиночном применении, изменение масштаба, полилинии, сплайны и тд. и т.п. Вариант использования с названием "создание символа для отображения объекта на картфоне" явная профанация.

Разрабатывали 2 человека 2 года (не только редактор, его они из-за лени написали). А. Шемис - передай им привет, их систему вчера Медведеву показывали.

Есть хорошее ёмкое, хотя и неформальное определение того, что такое способ применения — это то, ради чего человек подходит к компьютеру. В то, что у системы может быть 300 принципиально отличных КАТЕГОРИЙ результатов, ради каждой из которых человек может устроить отдельную рабочую сессию — верится с большим трудом.

И вообще, судя по тому, что вы способы применения ВАЛИТЕ на 1 страницу, вы под ними понимаете исключительно овальчики (а не сценарии), а это значит, что вы устроили бардак функциональной декомпозиции.

Я напоминаю, что содержательное название Use Case Diagram — это User Goal Diagram — просто карта результатов, которые хочет извлекать пользователь от одной рабочей сессии.

Для пояснения. Книжка с кратким перечнем символов и описанием основных правил их отображения занимает 520стр (в новой редакции). Почти половина символов имеет особенности в отображении, формировании подписи, при наложениях, при групповом и одиночном применении, изменение масштаба, полилинии, сплайны и тд. и т.п..

Вся эта фигня относится к бизнес-правилам, а не собственно к разнообразным способам применения.

Вариант использования с названием "создание символа для отображения объекта на картфоне" явная профанация.

Что значит профанация? Вы какую задачу решаете? Сформулировать требования? Если сценариев множество, но все они отличаются лишь параметрами и результатом (как, например, в отчётах), то зачем писать множество повторяющихся сценариев вместо того, чтобы описать 1, а вариации раскрыть отдельным блоком, не относящимся к технике способов применения?

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

Собственно, вопрос вот в чем - предположим, пользователь нажимает одну из кнопок в окне веб-формы, и в зависимости от этого могут выполняться различные потоки действий. Понятно, что по-нормальному надо из этих юскейсов сделать линки на Sequence Diagram и радоваться жизни. Но! После всего придется, на каждое более-менее объемное действие в этой диаграмме, писать SRS, в которой придется генерить более мелкие юскейсы, вытекающие из этой Sequence Diagram, и вот их-то уже не знаю, куда и приткнуть на UML диаграмме. В свою очередь, эти юскейсы будут указывать на свои диаграммы последовательности и так далее.

1. формально UC могут наследоваться , и выделение Generic UC наиболее оптимальная практика когда существует огромное кол-во типовых сценариев
2.  между UC существуют отношения типа "include" "extend" которые позволяют упорядочить контекстную диаграмму
3. Абсолютно согласен с коллегами по поводу разбиения UC на группы по пакетам
4. С помощью UC, как правило, описывается только взаимодействие внешнего по отношению к системе актера . Внутренние сценарии лучше описывать как алгоритмы , и ссылаться на них из UC/

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

На счет символов ГИС и тп....
Андо, я когда-то вам говорил, что ВИ там совсем не много, но меня никто не слушал ...
А вот бизнес-правил там очень-очень много. Для проектирования таких случаев каждый символ описывается отдельным набором правил:
- ограничения,
- отображения,
- логика...
В результате верхнеуровневое описание будет структурировано и логично, а детали вырождаются в огромное количество функций и алгоритмов. + появляется гибкость при добавлении новых символов.

На днях пришлось воспользоваться лет 5 назад разработанным редактором символов для ГИС.

Время прошло много, все уже забылось, и когда я туда заглянул, то мое настроение резко ухудшилось (работа была срочная и критическая).  Боюсь обмануть в количестве, но 200 вариантов использования есть только в редакторе символов, а сколькое еще реализовано собственно в клиентской части ГИС (автономная работа) + при отображении реальной информации из базы + взаимодействие с сервером приложений.

Для пояснения. Книжка с кратким перечнем символов и описанием основных правил их отображения занимает 520стр (в новой редакции). Почти половина символов имеет особенности в отображении, формировании подписи, при наложениях, при групповом и одиночном применении, изменение масштаба, полилинии, сплайны и тд. и т.п. Вариант использования с названием "создание символа для отображения объекта на картфоне" явная профанация.

Разрабатывали 2 человека 2 года (не только редактор, его они из-за лени написали). А. Шемис - передай им привет, их систему вчера Медведеву показывали.

1. я не очень большой специалист по ГИС, и пока не планирую развиваться в этом направлении, поэтому ничего об этом сказать не могу, даже если Медведеву она понравилась. (в сторону: интересно, что он в ней понял?)
2. с таким же успехом можно привести в качестве примера сложности интерфейса CAD-системы, Photoshop, Corel, Word, наконец, или что-нибудь подобное. но тем не менее сложный интерфейс не мешает работать и полезно использовать (!), т.е. получать нужный результат, даже не суперквалифицированному специалисту.
3. несмотря на то, что я видел неплохие системы разработанные нашими (отечественными) специалистами в подобном режиме, осмелюсь утверждать, что большинство доморощенных систем, созданных таким образом, обладают массой архитектурных проблем (а уж книги на 520 страниц, тем более в новой редакции, вообще в руки брать нельзя). возможно, Вы как раз пытаетесь их унаследовать. еще раз сошлюсь на пианино (пока еще ни одна система не приблизилась к нему) - клавиш всего ничего по большому счету, а сыграть специалист может бесконечно много... это один из примеров хорошей архитектуры.
4. отвлекитесь и посмотрите на свою систему не с точки зрения операций, а с точки зрения целей, что она по большому счету делает. Вот это и будет первым шагом для правильного разбиения на группы и формулирование use case.

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

На счет символов ГИС и тп....
Андо, я когда-то вам говорил, что ВИ там совсем не много, но меня никто не слушал ...

И правильно сделали. ...
Если говорить про Word, то в нем тоже мало ВИ, создать документ да распечатать документ. Все заморочки со шрифтами, стилями, шаблонами и еще черте знает с чем - все ограничения, отображение и логика. Интересно было бы посмотреть постановку задачи на разработку конкурента Word.

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

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

Действительно, архитектурные проблемы есть. Сменили архитектуру - их стало еще больше. Почему сменили - отдельный разговор.
520 страниц - это " настольная книжка" заказчика. Это не результат работы аналитиков. Мы ее наследуем, т.к. переучивать тысячи специалистов под наши идеи заказчик не будет. Требования заказчика - закон.
Зачем заказчику нужна карта и что на ней отображать - ясно. Какое место ГИС занимает в структуре системы - яcно. Остается маленький вопросик - нужно чуть чуть кода написать, для чего написать дискретные спецификации и передать их в отдел разработки. С моей точки зрения, такой точкой дискретизации и является прецедент. Конечно же, в большей степени он ориентирован на точку зрения пользователя, но эту точку зрения надо сделать «осязаемой», «понятной», «выровненной».

Теперь по теме.

Структурировать по пакетам – однозначно.
Кроме того, естественным способом группировки является диаграмма. Если следовать рекомендациям, что на одно диаграмме – от 5 до 9 элементов, то на 300 ВИ получится около 50 диаграмм, что все одно много и они так же должны быть разнесены по пакетам. Составить хорошую диаграмму  - это, к сожалению, искусство.

Для описания системы нами используется «структурно-объектный» (SADT+ООА) подход.
Сначала контекст, основные бизнес-области, основные БП, их декомпозиция. 1-3 ВИ подкладываются под листовую функцию (шаг БП). Таким образом получается достаточно естественная структура «пакетов».
Данный подход в наибольшей степени подходит для класса т.н. корпоративных систем. Для описания функциональности маршрутизатора или игрушки для мобильного телефона он подходит в меньшей степени.