Диаграммы последовательностей позволяют передавать информацию (например, данные синхронизации событий), которую нельзя выразить в диаграммах сотрудничества. Также диаграммы сотрудничества чрезмерно усложняются с увеличением количества объектов, тогда как диаграммы последовательностей остаются понятными и при обработке сценариев со многими объектами.
Несмотря на эти предостережения, для практических целей можно выбрать любую разновидность диаграммы. Относительно просто получить диаграмму последовательностей из диаграммы сотрудничества и наоборот.
На рис. 8.8 показана диаграмма сотрудничества, соответствующая диаграмме последовательностей для прецедента "Перевод денег", приведенной на рис. 8.7.
Диаграммы классов
Выше мы попытались идентифицировать классы анализа, которые участвуют в прецеденте, и распределить между ними обязанности прецедента. Это было сделано с привлечением диаграмм взаимодействий, которые выражают прежде всего динамическое поведение прецедента.
Часто классы участвуют в нескольких прецедентах, и поэтому важно изучить и их статические отношения* чтобы обеспечить работоспособность любого участка системы.
Теперь мы обратимся к этому аспекту и попробуем более точно определить классы и их отношения на базе уже проделанной работы по анализу прецедентов. Эти статические отношения будут проиллюстрированы на примере прецедента "Перевод денег".
Диаграмма классов UML помогает выразить статические отношения между различными структурными элементами. Для каждого прецедента создается одна диаграмма классов, называемая представлением участвующих классов (View Of Participating Classes — VOPC). Ее назначение — показать на одной диаграмме все аспекты системной архитектуры, которые проявляются в определенном прецеденте.
При создании VOPC анализируются все диаграммы взаимодействий, созданные для реализации прецедента, и в них выявляются классы, операции, отношения и т.д. для включения в VOPC.
Вначале идентифицируются и помещаются в диаграмму все классы, которые участвуют в прецеденте. Так как мы уже разделили поведение прецедента по классам, довольно просто создать для обязанностей, присвоенных классу, операции анализа. Каждая операция анализа соответствует одной из обязанностей системы, выполняемой классом анализа. Иными словами, существует взаимно-однозначное соответствие между каждым отдельным сообщением в диаграмме взаимодействий на уровне анализа и операцией анализа.
Важно отметить, что это операции анализа, т.е. они, вероятнее всего, подвергнутся дальнейшей разработке в ходе анализа и проектирования.
На рис. 8.9 показан класс управления TransferFunds с операциями анализа, представляющими обязанности, присвоенные классу.
Также для конкретизации классов следует определить их атрибуты. Атрибуты представляют информацию, которая может потребоваться от класса другими классами или самим этим классом для выполнения своих обязанностей.
Чтобы определить атрибуты, чаще всего надо знать специфику предметной области и понимать, какая информация действительно требуется для выполнения обязанностей.
На этой стадии анализа целесообразно присвоить атрибутам обобщенные типы, такие как численный, строковый и т.д. Конкретный тип можно будет задать позднее в зависимости от параметров реализации. На рис. 8.10 показаны атрибуты для класса анализа Profile (профиль пользователя).
Следует иметь в виду, что информация, моделируемая в атрибутах, может иметь лишь относительное простое поведение, выражаемое, например, операциями прочитать и установить. Если это не так или если эта информация используется совместно двумя или более классами, лучше смоделировать ее как отдельный класс.
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.