Форум Сообщества Аналитиков

Дисциплины => Системный Анализ и Требования => Варианты Использования (Use Case) => Тема начата: nvb от 25 Сентября 2009, 16:52:43

Название: Многозвенная архитектура - как рисовать много Use-cases?
Отправлено: nvb от 25 Сентября 2009, 16:52:43
Здравствуйте

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

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

Как рекомендуется поступать в таких случаях? Плюнуть на идеологию и делать иерархическую Use-case диаграмму, или выход давно найден?
Название: Re: Многозвенная архитектура - как рисовать много Use-cases?
Отправлено: bas от 25 Сентября 2009, 17:34:20
Выложите несколько проблемных ВИ с их описанием. Думается, что у Вас это не ВИ, а просто сценарии пользователя написаны.

Вы знаете про уровни ВИ от Коберна или о ВИ реализации в РУП?
Название: Re: Многозвенная архитектура - как рисовать много Use-cases?
Отправлено: Galogen от 25 Сентября 2009, 18:12:45
ВИ вполне можно размещать по пакетам. В ОО как раз средство борьбы со сложностью и массовостью размещение по пакетам. Вряд ли существует монолитная система с таким гигантским количеством ВИ
Название: Re: Многозвенная архитектура - как рисовать много Use-cases?
Отправлено: Водолей от 25 Сентября 2009, 20:57:37
думаю, что описанная проблема не имеет отношения к многозвенной архитектуре.
может действительно система большая, но скорее всего речь идет о некорректно спроектированной системе. в самом деле у обычного пианино порядка 80 с чем-то клавиш, а у обычной компьютерной клавиатуры чуть более 100.

что такого необычного и уникального в вашей системе, что ей понадобилось более 300 (!) кнопок (как вы пишете), за каждой из которых "следует" уникальный во всём use case? это система управления ядерным реактором?
Название: Re: Многозвенная архитектура - как рисовать много Use-cases?
Отправлено: Виталий Григораш от 29 Сентября 2009, 10:14:24
Уровни вариантов использования существуют. Начните с того,что причешите модель - обычно 300 вариантов использования это ОЧЕНЬ не маленькая система с разработкой на несколько лет. Возможно они у вас представлены на уровне функций. Если в описании у вас 1-3 действия то скорее всего вы описываете операции в виде ВИ. В таком случае можно объединить их вместе.
Далее разложите по пакетам сгруппировав например по смыслу. После того, как увидите структуру системы можно бить на компоненты. Я советую для каждого пакета рисовать отдельную диаграмму и разделять так, чтобы в пакетах было до 10 ВИ.
Почитайте приложенные материалы, надеюсь все поймете.
Название: Re: Многозвенная архитектура - как рисовать много Use-cases?
Отправлено: Денис Иванов от 29 Сентября 2009, 11:38:16
Виталий, что за книга?
Название: Re: Многозвенная архитектура - как рисовать много Use-cases?
Отправлено: Galogen от 29 Сентября 2009, 12:21:07
Виталий, что за книга?
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
Название: Re: Многозвенная архитектура - как рисовать много Use-cases?
Отправлено: Денис Иванов от 29 Сентября 2009, 12:37:01
спасибо
Название: Re: Многозвенная архитектура - как рисовать много Use-cases?
Отправлено: leinsoo от 30 Сентября 2009, 00:27:41
что такого необычного и уникального в вашей системе, что ей понадобилось более 300 (!) кнопок (как вы пишете), за каждой из которых "следует" уникальный во всём use case? это система управления ядерным реактором?

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

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

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

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

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

Название: Re: Многозвенная архитектура - как рисовать много Use-cases?
Отправлено: Denis Beskov от 30 Сентября 2009, 01:57:12
Есть хорошее ёмкое, хотя и неформальное определение того, что такое способ применения — это то, ради чего человек подходит к компьютеру. В то, что у системы может быть 300 принципиально отличных КАТЕГОРИЙ результатов, ради каждой из которых человек может устроить отдельную рабочую сессию — верится с большим трудом.

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

Я напоминаю, что содержательное название Use Case Diagram — это User Goal Diagram — просто карта результатов, которые хочет извлекать пользователь от одной рабочей сессии.
Название: Re: Многозвенная архитектура - как рисовать много Use-cases?
Отправлено: Denis Beskov от 30 Сентября 2009, 02:04:56
Для пояснения. Книжка с кратким перечнем символов и описанием основных правил их отображения занимает 520стр (в новой редакции). Почти половина символов имеет особенности в отображении, формировании подписи, при наложениях, при групповом и одиночном применении, изменение масштаба, полилинии, сплайны и тд. и т.п..
Вся эта фигня относится к бизнес-правилам, а не собственно к разнообразным способам применения.

Цитировать
Вариант использования с названием "создание символа для отображения объекта на картфоне" явная профанация.
Что значит профанация? Вы какую задачу решаете? Сформулировать требования? Если сценариев множество, но все они отличаются лишь параметрами и результатом (как, например, в отчётах), то зачем писать множество повторяющихся сценариев вместо того, чтобы описать 1, а вариации раскрыть отдельным блоком, не относящимся к технике способов применения?
Название: Re: Многозвенная архитектура - как рисовать много Use-cases?
Отправлено: Сless от 30 Сентября 2009, 02:56:24
Я сейчас проектирую систему примерно с 300 юскейсами. Как следует из прочитанных мной книг, юскейсы не могут быть вложены друг в друга. А валить 300 штук на одну страницу - запутаюсь.

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

Представьте себе насколько вы замучаетесь их описывать и реализовывать если даже отображение на UML диаграмме вызывает проблемы. Рекомендую Вам попытаться выделить небольшой кусочек системы для первого релиза.
Название: Re: Многозвенная архитектура - как рисовать много Use-cases?
Отправлено: Виталий Григораш от 30 Сентября 2009, 11:20:22
На счет символов ГИС и тп....
Андо, я когда-то вам говорил, что ВИ там совсем не много, но меня никто не слушал :)...
А вот бизнес-правил там очень-очень много. Для проектирования таких случаев каждый символ описывается отдельным набором правил:
- ограничения,
- отображения,
- логика...
В результате верхнеуровневое описание будет структурировано и логично, а детали вырождаются в огромное количество функций и алгоритмов. + появляется гибкость при добавлении новых символов.
Название: Re: Многозвенная архитектура - как рисовать много Use-cases?
Отправлено: Водолей от 30 Сентября 2009, 11:21:08
Цитата: leinsoo
На днях пришлось воспользоваться лет 5 назад разработанным редактором символов для ГИС.

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

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

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

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

P.S. а система управления ядерным реактором сложна по нескольким причинам: режим реального времени, множество параметров, требующих одновременного контроля и регулировки, высокая точность и надежность регулировки, требования безопасности, большое количество принципиально разных, но взаимосвязанных подсистем разного масштаба. правда документация на эту байду занимает далеко за 520 страниц :о))
Название: Re: Многозвенная архитектура - как рисовать много Use-cases?
Отправлено: leinsoo от 01 Октября 2009, 09:25:18
На счет символов ГИС и тп....
Андо, я когда-то вам говорил, что ВИ там совсем не много, но меня никто не слушал :)...
И правильно сделали. :)...
Если говорить про Word, то в нем тоже мало ВИ, создать документ да распечатать документ. Все заморочки со шрифтами, стилями, шаблонами и еще черте знает с чем - все ограничения, отображение и логика. Интересно было бы посмотреть постановку задачи на разработку конкурента Word.

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

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

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

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

Для описания системы нами используется «структурно-объектный» (SADT+ООА) подход.
Сначала контекст, основные бизнес-области, основные БП, их декомпозиция. 1-3 ВИ подкладываются под листовую функцию (шаг БП). Таким образом получается достаточно естественная структура «пакетов».
Данный подход в наибольшей степени подходит для класса т.н. корпоративных систем. Для описания функциональности маршрутизатора или игрушки для мобильного телефона он подходит в меньшей степени.
Название: Re: Многозвенная архитектура - как рисовать много Use-cases?
Отправлено: Водолей от 01 Октября 2009, 11:08:55
2 leinsoo:
Два вопроса:
во-первых, я бы хотел-таки послушать начальника транспортного цеха топикстартера
во-вторых, я не понял, Вам тоже совет нужен или нет? Для совета мало данных, впрочем, Вы, похоже, сами справляетесь со своими переделками.

по остальным вопросам не вижу предмета для обсуждения
Название: Re: Многозвенная архитектура - как рисовать много Use-cases?
Отправлено: Сless от 01 Октября 2009, 12:25:43
Для описания системы нами используется «структурно-объектный» (SADT+ООА) подход.
Сначала контекст, основные бизнес-области, основные БП, их декомпозиция. 1-3 ВИ подкладываются под листовую функцию (шаг БП). Таким образом получается достаточно естественная структура «пакетов».
Данный подход в наибольшей степени подходит для класса т.н. корпоративных систем. Для описания функциональности маршрутизатора или игрушки для мобильного телефона он подходит в меньшей степени.

А чего собственно Вам не хватает в ООA ?
Зачем вы берете на себя такие риски ?

Название: Re: Многозвенная архитектура - как рисовать много Use-cases?
Отправлено: Galogen от 01 Октября 2009, 13:42:52
А чего собственно Вам не хватает в ООA ?
Зачем вы берете на себя такие риски ?
Могу ошибаться, но что-то подобное мелькало в работах Маклакова. Но я тоже не понимаю зачем нужен SADT, есть более продвинутые методологии и нотации
Название: Re: Многозвенная архитектура - как рисовать много Use-cases?
Отправлено: Сless от 01 Октября 2009, 16:05:17
Могу ошибаться, но что-то подобное мелькало в работах Маклакова. Но я тоже не понимаю зачем нужен SADT, есть более продвинутые методологии и нотации

Когда да то в Открытом Университете MIT я познакомился с лекциями по проектированию (6-8 лет назад). В них утверждается что подход к проектированию сложных систем методом функциональной декомпозиции  сверху вниз себя изжил. 
Ключевая проблема подход сверху вниз  порождает крайне высокую связанность системы, что неизбежно сказывается на возможности стабилизировать и развивать систему. С учетом неизбежности изменений в ходе самого проекта чаще всего масштабные  проекты основанные на SADT просто обречены.

Все необходимое для структурирования решения в ООП на самом деле есть.

Но к сожалению, пояснительная сила, багаж и некомптентность тащат это "барохло" из методологии в методологию ..

p.s. Это не значит что такой подход не применим , это значит что он не применим там где могут быть ИЗМЕНЕНИЯ
Название: Re: Многозвенная архитектура - как рисовать много Use-cases?
Отправлено: nvb от 01 Октября 2009, 16:11:06
Это топикстартер. Прошу прощения за задержку - был сильно занят другим.

Действительно, когда я начал рисовать диаграмму, чтобы создать структуру, все стало гораздо яснее. Так много ВИ (300) оказалось не нужным размещать на диаграмме. Но это я выяснил, только когда многие из них нарисовал и обнаружил, что эктор у них один - система :) После чего попросту вставил их в диаграммы активности как действие. Даже детализировать их поддиаграммами не стал - нет смысла. Всего оказалось 13 ВИ на одной диаграмме и 10 - на другой.

В общем, я понял, что реинжиниринг системы не сильно проще, чем разработка :) Спасибо всем за ответы.