Форум Сообщества Аналитиков
Дисциплины => Системный Анализ и Требования => Варианты Использования (Use Case) => Тема начата: nvb от 25 Сентября 2009, 16:52:43
-
Здравствуйте
Я сейчас проектирую систему примерно с 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 ВИ подкладываются под листовую функцию (шаг БП). Таким образом получается достаточно естественная структура «пакетов».
Данный подход в наибольшей степени подходит для класса т.н. корпоративных систем. Для описания функциональности маршрутизатора или игрушки для мобильного телефона он подходит в меньшей степени.
-
2 leinsoo:
Два вопроса:
во-первых, я бы хотел-таки послушать начальника транспортного цеха топикстартера
во-вторых, я не понял, Вам тоже совет нужен или нет? Для совета мало данных, впрочем, Вы, похоже, сами справляетесь со своими переделками.
по остальным вопросам не вижу предмета для обсуждения
-
Для описания системы нами используется «структурно-объектный» (SADT+ООА) подход.
Сначала контекст, основные бизнес-области, основные БП, их декомпозиция. 1-3 ВИ подкладываются под листовую функцию (шаг БП). Таким образом получается достаточно естественная структура «пакетов».
Данный подход в наибольшей степени подходит для класса т.н. корпоративных систем. Для описания функциональности маршрутизатора или игрушки для мобильного телефона он подходит в меньшей степени.
А чего собственно Вам не хватает в ООA ?
Зачем вы берете на себя такие риски ?
-
А чего собственно Вам не хватает в ООA ?
Зачем вы берете на себя такие риски ?
Могу ошибаться, но что-то подобное мелькало в работах Маклакова. Но я тоже не понимаю зачем нужен SADT, есть более продвинутые методологии и нотации
-
Могу ошибаться, но что-то подобное мелькало в работах Маклакова. Но я тоже не понимаю зачем нужен SADT, есть более продвинутые методологии и нотации
Когда да то в Открытом Университете MIT я познакомился с лекциями по проектированию (6-8 лет назад). В них утверждается что подход к проектированию сложных систем методом функциональной декомпозиции сверху вниз себя изжил.
Ключевая проблема подход сверху вниз порождает крайне высокую связанность системы, что неизбежно сказывается на возможности стабилизировать и развивать систему. С учетом неизбежности изменений в ходе самого проекта чаще всего масштабные проекты основанные на SADT просто обречены.
Все необходимое для структурирования решения в ООП на самом деле есть.
Но к сожалению, пояснительная сила, багаж и некомптентность тащат это "барохло" из методологии в методологию ..
p.s. Это не значит что такой подход не применим , это значит что он не применим там где могут быть ИЗМЕНЕНИЯ
-
Это топикстартер. Прошу прощения за задержку - был сильно занят другим.
Действительно, когда я начал рисовать диаграмму, чтобы создать структуру, все стало гораздо яснее. Так много ВИ (300) оказалось не нужным размещать на диаграмме. Но это я выяснил, только когда многие из них нарисовал и обнаружил, что эктор у них один - система :) После чего попросту вставил их в диаграммы активности как действие. Даже детализировать их поддиаграммами не стал - нет смысла. Всего оказалось 13 ВИ на одной диаграмме и 10 - на другой.
В общем, я понял, что реинжиниринг системы не сильно проще, чем разработка :) Спасибо всем за ответы.