2. Язык UML. Руководство пользователя. Буч_ Рамбо_ Якобсон (2-е издание) (2006) (1185732), страница 75
Текст из файла (страница 75)
Все хорошо структурированныеобъектноFориентированные системы состоят из регулярного (то естьпостроенного в соответствии с четкими правилами) множества коопераций относительно небольшого размера, поэтому очень важнонаучиться их организовывать. Существует два вида относящихсяк кооперациям связей, которые следует принимать во внимание.ВоFпервых, это связь между кооперацией и тем, что она реалиВариантызует. Кооперация может реализовывать либо классификатор, либоиспольоперацию.
Это означает, что кооперация описывает структурнуюзованияили поведенческую реализацию соответствующего классификаторассматра или операции. Например, вариант использования, который имериваютсянует набор сценариев, выполняемых системой, может быть реалив главе 17,зован в виде кооперации. Этот вариант использования вместе с егооперации –действующими лицами и окружающими вариантами использовав главах 4и 9, связи ре- ния представляет контекст кооперации. Аналогично кооперациейможет быть реализована и операция (которая именует реализациюализации –некоторой системной услуги).
В таком случае контекст формирув главе 10,ет данная операция вместе со своими параметрами и возможнымклассифивозвращаемым значением. Такая связь между вариантом использокаторы –вания или операцией и реализующей кооперацией моделируетсяв главе 9.с помощью связи реализации.Классификаторы обсуждаютсяв главе 9.Рис.
28.3. Поведенческие аспекты кооперации393На заметку. Кооперация может реализовывать любой видклассификатора, включая классы, варианты использования,интерфейсы, компоненты и узлы. Кооперация, которая моделирует механизм системы, может быть и автономной; в такомслучае ее контекстом является вся система в целом.Кооперации394ВоFвторых, существуют связи между самими кооперациями.Одни из них могут уточнять описания других; это может быть смоделировано в виде связи уточнения.
Подобные связи между кооперациями обычно отражают связи уточнения между вариантамииспользования, которые они представляют.Оба вида связей иллюстрирует рис. 28.4.вариантиспользованияТипичные приемы моделированияВзаимодействия обсуждаютсяв главах 16и 19. Внутренняяструктурарассматриваетсяв главе 15.«уточняет»Рис.
28.4. Организация кооперацийПакетыобсуждаютсяв главе 12.На заметку. Кооперации, как и любые другие элементы моделей UML, могут группироваться в пакеты. Как правило, в этомвозникает необходимость только при моделировании оченьбольших систем.Типичные приемы моделированияМоделирование ролейОбъекты представляют отдельные сущности в статическом положении или в динамике. Вместе с тем мы нередко хотим показатьнекоторые общие части в определенном контексте.
Часть в пределах контекста называется ролью (role). Вероятно, наиболее важноеназначение ролей заключается в моделировании динамическихвзаимодействий. Обычно в таких случаях не приходится моделировать конкретные экземпляры, существующие в реальном мире.Диаграммывзаимодействия обсуждаютсяв главе 19,диаграммыдеятельности –в главе 20.395Вместо этого вы моделируете роли в некоем повторно используемом образце, в пределах которого они, по сути, замещают объекты,появляющиеся в индивидуальных экземплярах образца. Например,если вы хотите смоделировать варианты реакции окон в операционной системе на движения и щелчки мыши, вы должны нарисовать диаграмму взаимодействий, содержащую роли, типы которыхвключают окна, события и обработчики.Чтобы смоделировать роли, необходимо: Определить контекст, в котором взаимодействуют объекты.
Идентифицировать необходимые и достаточные роли, с помощью которых можно визуализировать, специфицировать,конструировать или документировать моделируемый контекст. Изобразить их как роли в структурированном контексте.По возможности присвоить каждой роли имя. Если длякакойFлибо из них нельзя подобрать осмысленное имя, изобразить ее как безымянную. Раскрыть свойства каждой роли, которые необходимы и достаточны для моделирования контекста.
Представить роли и их связи на диаграмме взаимодействияили диаграмме классов.На заметку. Семантическая разница между конкретнымиобъектами и ролями достаточно тонка, но не сложна дляпонимания. Уточняя сказанное выше, следует отметить, чтороль UML – это предопределенная часть структурированного классификатора, такого как структурированный классили кооперация. Роль – это не объект, но описание; она привязана к значению внутри каждого экземпляра структурированного классификатора. Таким образом, роль, как и атрибут,соответствует многим возможным значениям.
Конкретныеобъекты появляются в специфических примерах, в частностина диаграммах объектов, компонентов и размещения. Ролипоявляются в обобщенных описаниях – на диаграммах взаимодействия и деятельности.На рис. 28.5 вы видите диаграмму взаимодействия, описывающую частичный сценарий осуществления телефонного вызовав контексте коммутатора. Здесь налицо четыре роли: a (CallingAgent –ВызывающийАбонент), c (Connection – Подключение), а также t1 и t2(экземпляры Terminal – Терминал).
Все они, по своей сути, являются концептуальными «заместителями» конкретных объектов из реального мира.Кооперации3962.1 : startBilling1: createa : CallingAgentc : Connection2 : enableConnection1.2 : add1.1 : addt1 : Terminalt2 : TerminalРис. 28.5. Моделирование ролейНа заметку. На рис. 28.5 представлен пример кооперации,которая представляет сообщество объектов и других элементов, работающих совместно для обеспечения определенного поведения, представляющего собой нечто большее,чем поведение суммы тех же элементов. Кооперации имеютдве составляющие: структурную (описывающую роли классификаторов и их связи) и динамическую, или поведенческую (описывающую взаимодействия между этими прототипными экземплярами).Моделирование реализации вариантаиспользованияВариантыиспользования обсуждаютсяв главе 17.Одно из назначений коопераций состоит в моделировании реализации варианта использования.
Как правило, анализ системыдиктуется теми вариантами использования, которые вы идентифицировали. Переходя же к этапу реализации, вы должны материализовать их в виде конкретных структур и поведений. В общем случаекаждый вариант использования должен быть реализован одной илинесколькими кооперациями. Если рассматривать систему в целом,то классификаторы, участвующие в кооперации, которая связанас некоторым вариантом использования, будут принимать участиеи в других кооперациях.
Таким образом, структурное содержимоекоопераций имеет тенденцию перекрываться.Чтобы смоделировать реализацию варианта использования, следует: Идентифицировать структурные элементы, необходимые и достаточные для выражения семантики варианта использования.Типичные приемы моделирования397 Организовать эти структурные элементы в диаграммы классов. Рассмотреть отдельные сценарии, представляющие данныйвариант использования.
Каждый сценарий описывает конкретный путь выполнения варианта использования. Отобразить динамику этих сценариев на диаграммах взаимодействия. Использовать диаграммы последовательности,если нужно подчеркнуть временной порядок сообщений,или диаграммы коммуникации, если важнее структурныесвязи между объектами, участвующими в кооперации. Организовать эти структурные и поведенческие элементыкак кооперацию, которую можно соединить с вариантом использования при помощи связи реализации.Например, на рис. 28.6 изображены варианты использования,относящиеся к системе контроля кредитных карточек, включаяосновные: Place order (Разместить заказ) и Generate bill (Выдать счет),а также подчиненные: Detect card fraud (Обнаружить мошенничество)и Validate transaction (Проверить транзакцию).
Хотя в большинстве случаев не возникает необходимости в явном моделированииэтой связи – такую задачу можно возложить на инструментальные средства, – на данном рисунке показана явная модель реализации Place order с помощью кооперации Order management (Управлениезаказами). В свою очередь, эта кооперация может быть разложена«включает»«включает»Рис. 28.6. Моделирование реализации варианта использования398Кооперациина структурный и поведенческий аспекты, что в итоге дает диаграммы классов и диаграммы взаимодействия. Таким образом, черезсвязь реализации вариант использования связывается с его сценариями.В большинстве случаев нет необходимости моделировать явносвязь между вариантом использования и реализующей его кооперацией.
Можно оставить это соединение на заднем плане модели,а затем позволить инструментальным средствам использовать его,чтобы упростить навигацию между вариантом использования и егореализацией.Типичные приемы моделированияАктивныеклассыобсуждаютсяв главе 23.399(обработка) достаточно проста и может быть реализована сразув коде, приведенном в примечании. А вот операция render (визуализировать) намного сложнее, поэтому ее реализация возложенана кооперацию Ray trace (Трассировка лучей).
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
