Одной из типичных ошибок является стремление отобразить на одной диаграмме все свои знания об исследуемой области. Диаграмма прецедентов на рис. 2.1 - наглядный пример.
С точки зрения эргономики, диаграмма нечитабельна.
Некоторые из прецедентов включения являются, скорее, элементарными действиями внутри включающего прецедента, и эти действия не являются существенными (достоиными выделения в самостоятельный модуль).
Критерий для выделения: основной (расширяемый) прецедент является работоспособным, полезным и может ограниченно использоваться без этой функциональности.
С другой стороны, некоторые прецеденты такие расплывшиеся, что они не будут выполняться целиком в одном сеансе взаимодействия субъекта (актера) с системой.
Совет (из RUPа):
- В модели прецедентов создайте пакеты UML для помещения прецедентов одной функциональной области, и назовите их как прецеденты верхнего уровня. У Вас будет три таких пакета. В описании пакетов коротко опишите их назначение (фактически - повторение ваших длинных названий прецедентов). Перетащите в эти пакеты прецеденты, расширяющие соответствующие прецеденты верхнего уроня. Сами прецеденты верхнего уровня удалите из модели: это не use case!
- Удалите все прецеденты расширения, которые не являются таковыми. Сохраните только те, которые Вы действительно будете реализовывать как отдельные модули, т.е действительно будете расширять функциональности расширяемых прецедентов. Проверьте, xто в описании каждого прецедента кратко описана его функциональность. Например: "Формирование справочника "Тип литературы" должно включать следующие возможности: добавление нового типа, изменение типа, удаление типа)".
- В каждом пакете функциональной области нарисуйте свою маленькую диаграмму прецедентов "Прецеденты функциональной области..."
- Пересмотрите свое отношение к субъектам. Вместо одного появятся много, выполняющих прецеденты, соответствующие их ролям в библиотеке.
Диаграмма деятельности должна описывать последовательность взаимодействий для каждого прецедента в отдельност!
При этом Вы сможете обнаружить общие действия, полностью совпадающие в различных диаграммах деятельности, а значит - в прецедентах. Эти фрагменты - кандидаты в прецеденты включения. Если хватит духу - создайте в модели пакет "Прецеденты включения" и опишите там соответствующие фрагменты как абстрактные прецеденты включения (с диаграммами деятельности).
После этого:
- перетащите каждый включаемый прецедент на диаграммы, в которых есть прецеденты, которые его включают и установите соответствующую связь
- соответствующие фрагменты в диаграммах деятельности основных прецедентов могут быть заменены узлами "вызываемая операция".
На диаграмме классов:
- укажите множественности
- подумайте о типах ассоциаций
- название класса "Экземпляр" плохое, наталкивает на мысль, что Вы не знаете, что такое в UML спецификация экземпляра.
По диаграммам компонентов - без комментариев (см. замечание № 1)
Л. Новиков
http://lnew.ucoz.rulnew@yandex.ru