Ключевые понятия системы выражаются в модели как объекты-сущности. Например, в электронной банковской системе целесообразно моделировать информацию о клиенте, о счетах и т.д. как объекты-сущности.
Объекты-сущности обозначаются стереотипом <<entity>> или изображаются кружком с касающейся его внизу черточкой. Объекты-сущности обычно охватывают несколько прецедентов и могут существовать даже за пределами самой системы. В разных системах потребность в информации меняется радикально, и это определяет количество объектов-сущностей в прецеденте или системе.
На рис>8.4 показан пример соответствия между прецедентом и объектом-сущностью.
Объекты управления
Объекты управления (control objects) служат для моделирования поведения в системе. Объекты управления не обязательно сами реализуют поведение прецедента, но могут для этого взаимодействовать с другими объектами.
Смысл объектов управления заключается в том, чтобы разделить в модели поведение и существенную информацию для более удобного оперирования каждым из этих элементов в отдельности.
Объекты управления обычно являются переходными по своему характеру и прекращают существовать, как только заканчивается прецедент. Они обозначаются стереотипом <<control>> или кружком со стрелкой.
Объектом управления в электронной банковской системе может быть объект, который координирует безопасный доступ к системе. В прецеденте может быть один или несколько объектов управления. Соответствие между прецедентом и объектом управления показано на рис. 8.5.
На рис. 8.6 изображен прецедент "Перевод денег" и все определенные для него объекты анализа (TransferPage — интерфейс страницы* перевода, TransferFunds — само действие перевода, Account — информация счета, Profile — информация профиля пользователя и TransactionsRegister — информация реестра транзакций). Обратите внимание на графическое представление граничных объектов, объектов управления и объектов-сущностей.
Обновленный вариант диаграммы последовательностей для этого прецедента при системе, расчлененной на объекты анализа, показан на рис. 8.7. Нужно заметить, что здесь участвуют два объекта счета — Accountl, с которого снимаются деньги, и Account2, на который они переводятся.
На этой диаграмме можно заметить несколько новых деталей. Если сравнить ее с диаграммой на рис. 8.2 в начале главы, окажется, что общее содержание действий в диаграмме последовательностей не изменилось. Однако теперь общий набор обязанностей распределен между разными частями системы. Например, взаимодействие с клиентом стало обязанностью граничного объекта TransferPage. В свою очередь, граничный объект взаимодействует с объектом управления, который координирует все действия в прецеденте. В выполнении прецедента участвует несколько объектов. Следует заметить, что для каждого существенного полного пути (потока событий), по которому можно пройти через прецедент, должна быть создана отдельная диаграмма последовательностей, возможно, содержащая взаимодействия с иным, неповторяющимся набором объектов. Эти пути, или сценарии, могут возникать, когда поведение исполнителей отклоняется от наиболее вероятного, или когда в системе возникают исключительные состояния. Все эти диаграммы могут входить в одну реализацию прецедента. В совокупности они показывают возможные внутренние взаимодействия, которые могут иметь место в ходе выполнения прецедента.
Диаграммы сотрудничества
Диаграммы сотрудничества — еще одна разновидность диаграмм взаимодействий объектов в языке моделирования UML. В отличие от диаграмм последовательностей, которые изображают в первую очередь порядок взаимодействий во времени, диаграммы сотрудничества показывают отношения и связи между их участниками. Диаграммы сотрудничества лучше выражают общую картину взаимодействий для данного класса.
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.