Форум Сообщества Аналитиков
Общий раздел => Теория моделирования и нотации => UML SysML и пр. => Тема начата: Анастасия от 24 Сентября 2013, 19:08:07
-
Добрый день, уважаемые коллеги!
Возник такой вопрос по диаграмме вариантов использования (или use case diagram): если ВИ получается очень много и показывать их на одной диаграмме неинформативно, то по какому принципу/критерию ее лучше разбить на несколько?
Мои варианты:
1. по актерам (т.е. на одной диаграмме показывать ВИ доступные только одному актеру, на второй - другому и т.д.);
2. по функциональным модулям (т.е. на одной диаграмме показыать ВИ, относящиеся к одному модулю; на второй - к другому и т.д.).
Преимущества вариантов:
- при разбивке по актерам можно понять и получить общее представление о том, какие задачи планирует выполнять тот или иной пользователь (актер) с помощью системы;
- при разбивке по модулям можно получить общее представление о конкретном модуле системы.
Таким образом, как мне кажется оба варианта имеют преимущества и выбор одного из двух лишь дело вкуса, но может у вас будут альтернатиыные мнения.
Образец неразбитой диаграммы можно посмотреть во вложении к моими сообщению :)
-
Лучше всего разбивать по функциональным областям, т.к. сразу можно понять контекст. Если необходимо понять какие ВИ может выполнять Актер, то это можно понять из матрицы трассировки.
-
Критерии нужно выяснять у тех, кто эту диаграмму будет использовать. Если доступа к ним нет, то попробовать поставить себя на их место.
Разработчикам обычно удобнее смотреть по функциональным модулям. Проектировщикам интерфейсов, возможно, по ролям.
Если диаграмма рисуется для преподавателя, то можно ещё что-нибудь придумать. :)
Эта диаграмма, кстати, не такая уж большая: её можно охватить одним взглядом и понять контекст. Только непонятны связи между ролями, и человечков лучше расположить вокруг системы, а не внутри.
extend и include использовать в реальной жизни вообще не рекомендуется: резко возрастает вероятность, что потребители диаграммы поймут её неправильно.
Ну и у вас там, кажется, CRUD (http://ijsce.org/attachments/File/v2i2/B0535042212.pdf) внизу притаился.
-
Спасибо за комментарии!
Я тоже думала о том, что следует прежде всего исходить из того, кто пользователи диаграммы. В моем случае это разработчики, поэтому, вероятнее всего, удобнее будет разбить по функциональным модулям.
А что касается CRUD, то прежде всего спасибо за заметку, но на самом деле диаграмма неполная и еще дорабатывается. Так что Вы абсолютно правы, и все что касается CRUD мы добавим позже! :)
-
extend и include использовать в реальной жизни вообще не рекомендуется: резко возрастает вероятность, что потребители диаграммы поймут её неправильно.
CRUD (http://ijsce.org/attachments/File/v2i2/B0535042212.pdf) внизу притаился.
Да, наверное, Вы правы. Чаще Extend лишь путает пользователя. Но совсем без extend как-то у меня не полчилось, т.к:
1. все-таки некоторые из ВИ являются дополнительными к основным (т.е. расширяют их);
2. если все ВИ напрямую соединять с актером, то, имхо, диаграмма будет перегружена.
Но может у Вас будут альтернативные мнения.
Только непонятны связи между ролями, и человечков лучше расположить вокруг системы, а не внутри.CRUD (http://ijsce.org/attachments/File/v2i2/B0535042212.pdf) внизу притаился.
Не совсем поняла комментарий, но слегка изменила диаграмму в целом. Так что может сейчас она будет выглядеть лучше и понятнее.
Диаграмму я прикрепила :)
[вложение удалено администратором] - слишком большой размер, изменил на уменьшенное
-
Анастасия,
Согласен с Гришей, экстенд и инклуд нужно использовать в крайнем случае. В вашем случае:
Просмотр списка и просмотр элемента лучше всего объединить в один ВИ, а уже детали просмотра списка и элемента описать в виде отдельных основных сценариев.
Не забывайте про основные принципы ООП, в частности про инкапсуляцию.
-
Почему-то во всех схожих темах предлагается рассматривать диаграмму вариантов использования и способы её "улучшения" в отрыве от описаний use case'ов.
-
CRUD внизу притаился
Ну имеется в виду объединить эти ВИ в один, как в приведенной greesha статье показано.
Не Edit Student, Add Student, Delete Student (+ еще подразумеваем View Student), а один ВИ - CRUD Student. Вообще так не всегда можно делать, потому что может быть какое-нибудь разграничение прав доступа (скажем, создать объект данному действующему лицу разрешено, а удалить нельзя), но у Вас вроде нет таких условий.
-
прав доступа (скажем, создать объект данному действующему лицу разрешено, а удалить нельзя), но у Вас вроде нет таких условий.
Это все равно изображается в виде CRUD, только в бизнес-правилах в спеке ВИ пишутся такие ограничения.
-
Это все равно изображается в виде CRUD, только в бизнес-правилах в спеке ВИ пишутся такие ограничения
Ага, спасибо за пояснение. Да, так удобнее.
bas, скажите пожалуйста, а это просто применяемая Вами практика, или такой подход рекомендуется какими-нибудь документами (стандартами, best practicies, etc.)?
-
Почему-то во всех схожих темах предлагается рассматривать диаграмму вариантов использования и способы её "улучшения" в отрыве от описаний use case'ов.
Виктор, вы не были услышаны :)
-
Почему-то во всех схожих темах предлагается рассматривать диаграмму вариантов использования и способы её "улучшения" в отрыве от описаний use case'ов.
Хм, почему бы это?
-
Совет про CRUD можно дополнить вторым приёмом, описанным в книге Алистера Коберна "Современные методы описания функциональных требований к системам" -- "Параметризованный вариант использования". Коберн описывает как набор ВИ "Найти клиента", "Найти продукт" и т. п. заменяется одним параметризованным ВИ "Найти что-либо". Соответственно, ориентируясь на названия ВИ, можно предложить группирующий ВИ "Посмотреть список чего-либо".
-
Ага, спасибо за пояснение. Да, так удобнее.
bas, скажите пожалуйста, а это просто применяемая Вами практика, или такой подход рекомендуется какими-нибудь документами (стандартами, best practicies, etc.)?
Это мое ноу хау :) Если серьезно, то я не помню, что где-то про это читал...
Мой подход про БПр и доп требования в ВИ можно посмотреть здесь:
http://www.req-labs.ru/conf2012/agenda/525/
-
Это мое ноу хау :) Если серьезно, то я не помню, что где-то про это читал...
2008-й год, Э.Галиаскаров цитирует Г.Увергарда: http://www.uml2.ru/forum/index.php?topic=628.msg7315#msg7315
-
Трактовка ассоциации, соединяющей актора и ВИ, как пути доступа -- это огрубление и переделывание стандартного смысла.
Если ДВИ рисуется при взгляде на систему как на "чёрный ящик", то о каких "конкретных модулях системы" может идти речь.
Чудесатое обсуждение.