Дж. Арлоу, А. Нейштадт - UML 2 и Унифицированный процесс - Практический объектно-ориентированный анализ и проектирование, страница 72
Описание файла
PDF-файл из архива "Дж. Арлоу, А. Нейштадт - UML 2 и Унифицированный процесс - Практический объектно-ориентированный анализ и проектирование", который расположен в категории "". Всё это находится в предмете "объектно-ориентированный анализ и проектирование" из 7 семестр, которые можно найти в файловом архиве МГУ им. Ломоносова. Не смотря на прямую связь этого архива с МГУ им. Ломоносова, его также можно найти и в других разделах. .
Просмотр PDF-файла онлайн
Текст 72 страницы из PDF
Проектные классы••Неявное связывание:• фактические значения задаются в угловых скобках (< >)прямо в классе;• экземплярам шаблона имена присвоить нельзя – имена образуются именем шаблона и списком аргументов.Вложенные классы:• класс определяется внутри другого класса;• вложенный класс существует в пространстве имен внешнегокласса – только внешний класс может создавать и использоватьэкземпляры вложенного класса;• в Java вложенные классы называются внутренними классами;их активно используют для обработки событий в классах GUI.18Уточнение отношений,выявленных при анализе18.1. План главыВ этой главе обсуждаются методы уточнения (детализации) отношений, выявленных при анализе, в отношения уровня проектирования.Эти методы используются во всех деятельностях рабочего потока проектирования (рис. 16.6).В первой части данной главы обсуждается преобразование отношенийуровня анализа в одно из отношений целоечасть – агрегацию (раздел 18.4) или композицию (раздел 18.5).Вторая часть посвящена работе с кратностью аналитических ассоциаций.
Мы предлагаем конкретные методы уточнения аналитическихассоциаций с кратностью одинкодному (раздел 18.7), многиекодному (раздел 18.8), одинкомногим (раздел 18.9) и многиекомногим(раздел 18.11.1). Также рассматриваются двунаправленные ассоциации (раздел 18.11.2) и классыассоциации (раздел 18.11.3).В завершение мы увидим, как с помощью UML 2 можно устанавливатьотношение между составным классификатором и его частями.18.2. Отношения уровня проектированияАналитические ассоциации должны быть уточнены до отношений уровня проектирования, непосредственно реализуемых целевым ОО языкомпрограммирования.При переходе к проектированию необходимо уточнить отношения между классами анализа и превратить их в отношения между проектнымиклассами. Многие из выявленных при анализе отношений не могут392Глава 18.
Уточнение отношений, выявленных при анализе18.2. Отношения уровня проекта18.3. Агрегация и композицияизучаем агрегациюизучаем композицию18.4. Семантика агрегации18.5. Семантика композиции18.5.1. Композиция и атрибуты18.6. Как уточнять отношения уровня анализауточнение ассоциацийодин!к!одномууточнение ассоциациймногие!к!одномууточнение ассоциацийодин!ко!многимконкретизацияотношений18.7. АссоциацииодинQкQодному18.8.
АссоциациимногиеQкQодному18.9. АссоциацииодинQкоQмногим18.11. Конкретизированныеотношения18.10. Коллекции18.11.1. Ассоциации многиеQкоQмногим18.10.1. Карта18.11.2. Двунаправленные ассоциации18.11.3. КлассыQассоциации18.12. Изучение композиции с использованием структурированных классов18.12.1. Структурированные классификаторы18.12.2. Структурированные классы18.13. Что мы узналиРис. 18.1. План главы18.3. Агрегация и композиция393быть реализованы как есть, их надо сделать таковыми. Например, ниодин из широко распространенных ОО языков программирования неподдерживает двунаправленные ассоциации, классыассоциации илиассоциации многиекомногим. Чтобы создать проектную модель, необходимо определить, как должны быть реализованы эти ассоциации.Уточнение аналитических ассоциаций до ассоциаций уровня проектирования включает несколько процедур:• уточнение ассоциаций до отношений агрегации или композициив соответствующих случаях;• реализацию ассоциаций одинкомногим;• реализацию ассоциаций многиекодному;• реализацию ассоциаций многиекомногим;• реализацию двунаправленных ассоциаций;• реализацию классовассоциаций.Все ассоциации уровня проектирования должны обладать:• возможностью навигации;• кратностью на обоих концах.У всех ассоциаций уровня проектирования должно быть указано имяассоциации или имя роли, по крайней мере, на целевом конце.18.3.
Агрегация и композицияПри проектировании отношение ассоциация можно уточнить до агрегации или более строгой формы агрегации – композитной агрегации,если ассоциация имеет соответствующую семантику. Обычно композитную агрегацию называют просто композицией.Получить представление о семантических отличиях между двумя типами агрегации можно из обсуждения примеров, взятых из окружающего нас мира.• Агрегация – это свободный тип отношения между объектами – какмежду компьютером и его периферийным оборудованием.• Композиция – это очень строгий тип отношения между объектами –как между деревом и его листьями.Из примера, приведенного на рис. 18.2, можно сделать вывод, чтокомпьютер очень слабо взаимосвязан со своим периферийным оборудованием.
Периферийные устройства могут появляться и исчезать,могут совместно использоваться с другими компьютерами. Они не«принадлежат» конкретному компьютеру. Это пример агрегации. Напротив, дерево тесно взаимосвязано со своими листьями. Листья принадлежат только одному дереву, ими нельзя поделиться с другими деревьями, и когда дерево умирает, листья умирают вместе с ним. Этопример композиции.394Глава 18. Уточнение отношений, выявленных при анализеUML определяет два типа ассоциацииКомпозицияАгрегацияНекоторые объекты слабо взаимосвязаныдруг с другом, как компьютери его периферийное оборудованиеНекоторые объекты тесно взаимосвязаны,как дерево и его листьяРис. 18.2. Два типа ассоциации в UMLОчень полезно помнить об этих простых аналогиях при дальнейшемболее подробном рассмотрении семантики агрегации и композиции.18.4. Семантика агрегацииАгрегация – это тип отношения целоечасть, в котором агрегат образуется многими частями.
В отношении целоечасть один объект (целое)использует сервисы другого объекта (части). По существу, целое является доминантной и управляющей стороной отношения, тогда какчасть просто обслуживает запросы целого и, следовательно, играет более пассивную роль. Действительно, если навигацию можно осуществлять только от целого к части, последняя даже не знает, что являетсячастью целого.Рассмотрим конкретный пример агрегации (рис.
18.3). Мы видим следующее:• компьютер (класс Computer) может быть присоединен к 0 или болеепринтерам (класс Printer);• в любой момент времени принтер соединен с 0 или 1 компьютером;• в ходе времени конкретный принтер может использоваться многими компьютерами;• принтер может существовать, даже если не подключен ни к одномукомпьютеру;• принтер фактически не зависит от компьютера.0..10..*Computerцелое, или агрегатPrinterагрегацияРис. 18.3. Пример агрегациичасть39518.4. Семантика агрегацииАгрегация – это отношение целоечасть.Семантику агрегации можно подытожить следующим образом:• агрегат может существовать как независимо от частей, так и вместес ними;• части могут существовать независимо от агрегата;• агрегат является в некотором смысле неполным в случае отсутствия некоторых частей;• части могут принадлежать одновременно нескольким агрегатам.ABCАгрегация транзитивна: если C является частью B, и B является частью A, тогда C также является частью AРис.
18.4. Агрегация транзитивнаАгрегация транзитивна. Рассмотрим пример на рис. 18.4. Транзитивность означает, что если C является частью B, и B является частью A,тогда C также является частью A.Агрегация транзитивна.Агрегация асимметрична. Это означает, что объект никогда – ни прямо, ни косвенно – не может быть частью самого себя. Это ограничиваетспособы использования агрегации в моделях. В примере на рис. 18.5 показано, что объекты Product могут состоять из других объектов Product.В данном случае ошибки нет, потому что это разные объекты, и ограничение асимметрии не нарушено.рефлексивная агрегацияa:Product*Productb:Productc:ProductциклыНЕдопустимы*d:ProductРис.
18.5. Ограничение асимметрии для агрегации не нарушено, т. к. здесьпредставлены разные объекты Product396Глава 18. Уточнение отношений, выявленных при анализеАгрегация асимметрична. Объект никогда не может быть частью самогосебя.Продолжим рассмотрение рис. 18.5. Иногда может понадобиться смоделировать ситуацию, когда между объектами d и a существует связь,как показано на рисунке.
Такое может случиться, если объекту d необходимо осуществить обратный вызов и использовать некоторые сервисы объектаагрегата a. Но как это смоделировать на диаграмме классов? Рефлексивная агрегация (reflexive aggregation) с классом Productне подходит, потому что согласно ограничению асимметрии для агрегации объект a не может быть частью самого себя ни прямо, ни косвенно. Поэтому для обработки связи между объектами d и a необходимоиспользовать рефлексивную неуточненную ассоциацию класса Productс самим собой, как показано на рис.
18.6.рефлексивная агрегацияa:Product*b:ProductProductc:Product*d:ProductРис. 18.6. Связь между объектами a и d реализована посредствомрефлексивной неуточненной ассоциацииАссоциация симметрична. Объект может быть ассоциирован с самимсобой.На рис. 18.7 показан другой типичный пример агрегации. Домашнийкомпьютер (целое) может быть смоделирован как набор частей. Этичасти довольно слабо взаимосвязаны с целым.
Их можно переноситьс компьютера на компьютер или использовать совместно с другимикомпьютерами, поэтому в этой модели применима семантика агрегации. Согласно этой модели домашний компьютер можно рассматривать как совокупность следующих частей: Mouse (мышь), Keyboard (клавиатура), CPU (центральный процессор), Monitor (монитор) и два объекта Speaker (колонка). CPU, в свою очередь, может быть смоделированкак совокупность различных аппаратных компонентов, таких как RAM(ОЗУ), HardDrive (жесткий диск) и т. д.39718.5. Семантика композицииHomeComputer11Mouse1KeyboardCPU12MonitorSpeaker1*1RAM1..*FloppyDrive1HardDriveCDRom2connectedTo11SoundCardGraphicsCard11connectedToРис.
18.7. Типичный пример агрегации: компьютер как совокупность его частей18.5. Семантика композицииКомпозиция – более строгая форма агрегации. Она имеет сходную(но более ограниченную) семантику. Как и агрегация, это отношение целоечасть, являющееся как транзитивным, так и асимметричным.Ключевое различие между агрегацией и композицией в том, что в композиции у частей нет независимой жизни вне целого. Более того, в композиции каждая часть принадлежит максимум одному и только одному целому, тогда как при агрегации часть может совместно использоваться несколькими целыми.Композиция – это строгая форма агрегации.В примере на рис. 18.8 объекты Button (кнопка) не могут существоватьнезависимо от владеющего ими объекта Mouse.
Если уничтожаетсяобъект Mouse, уничтожаются и принадлежащие ему объекты Button,потому что они являются его неотъемлемой частью. Каждый объектButton может принадлежать только одному объекту Mouse. Так же и листья на деревьях – жизнь листа определяется жизнью дерева, и листможет принадлежать только одному дереву.всегда 0..1 или 111..4MouseкомпозитButtonкомпозицияРис. 18.8. Пример композициичасть398Глава 18. Уточнение отношений, выявленных при анализеКомпозит имеет исключительное право владения и ответственностиза свои части.Резюмировать семантику композиции можно следующим образом:•одновременно части могут принадлежать только одному композиту –совместное владение частями невозможно;•композит обладает исключительной ответственностью за все своичасти; это означает, что он отвечает за их создание и уничтожение;•композит может высвобождать части, передавая ответственностьза них другому объекту;•в случае уничтожения композита он должен или уничтожить всесвои части, или передать ответственность за них другому объекту.Поскольку композит обладает исключительной ответственностью зажизненный цикл и управление своими частями, то при создании объект композита часто создает и свои части.