UML2 и унифицированный процесс. Джим арлоуайла нейштадтпрактический объектно ориентированныйанализ и проектированиеu
 Скачать 6.08 Mb.
|
|
• связь между bookClub и ila; • связь между bookClub и erica; • связь между bookClub и naomi. Для задания направления движения сообщений по связи используется возможность навигации. На рис. 9.2 связи двунаправленные, поэтому можно сказать, что связь соединяет ila с bookClub или что связь соединяет bookClub с ila. chairperson secretary member BookClub naomi:Person erica:Person ila:Person bookClub:Club имя роли двунаправленная связь Рис. 9.2. Двунаправленные связи между объектами 9.3. Что такое связь? 203 Если связь однонаправленная, для задания направления движения со общений по связи используется возможность навигации. Если навигация возможна, на конце связи помещают стрелку; в про тивном случае связь завершают крестом (навигация не допускается). Возможность навигации немного похожа на улицу с односторонним движением. Сообщения могут проходить только в том направлении, куда указывает стрелка. Спецификация UML 2 допускает три разных способа отображения воз можности навигации, которые подробно обсуждаются в разделе 9.4.3. В данной книге используется самое распространенное обозначение: • все кресты опускаются; • двунаправленные ассоциации изображаются без стрелок; • однонаправленные ассоциации изображаются с одной стрелкой. Единственным настоящим недостатком этого способа отображения яв ляется отсутствие возможности показать, что решение о навигации еще не принято, потому что отсутствие символов навигации подразу мевает, что связь «не допускает навигации». Например, на рис. 9.3 показано, что связь между :PersonDetails и :Address однонаправленная. Это значит, что у объекта :PersonDetails есть объект ная ссылка на объект :Address, но не наоборот. Сообщения могут пере сылаться только от :PersonDetails к :Address. 9.3.2. Пути Обозначения UML, такие как пиктограмма объекта, пиктограмма пре цедента и пиктограмма класса, соединяются с другими обозначения ми путями. Путь – это «связанные последовательности графических сегментов» (другими словами, линия!), объединяющие два или более обозначений. Существует три стиля представления путей: • прямоугольный – путь состоит из ряда горизонтальных и верти кальных сегментов; • наклонный – путь является последовательностью одной или более наклонных линий; • кривой – путь является кривой линией. Какой стиль пути использовать, вопрос личных предпочтений. Стили могут даже смешиваться на одной диаграмме, если это делает ее более :Address :PersonDetails исходный объект целевой объект однонаправленная связь Рис. 9.3. Однонаправленная связь между объектами 204 Глава 9. Отношения ясной и понятной. Мы, как и многие разработчики моделей, обычно используем прямоугольный стиль. На рис. 9.4 использован прямоугольный стиль, и пути объединены в дерево. Объединять можно только пути, имеющие одинаковые свой ства. В данном случае все пути представляют связи, поэтому вполне законно могут быть объединены. Визуальная четкость, легкость прочтения и общая привлекательность диаграмм имеют огромное значение. Необходимо всегда помнить, что основная масса диаграмм создается для кого то. Таким образом, не важно, какой стиль используется, важны четкость и ясность. 9.4. Что такое ассоциация? Ассоциации – это отношения между классами. Аналогично связям, соединяющим объекты, ассоциации соединяют классы. Самое глав ное: для того чтобы между двумя объектами была связь, между клас сами этих объектов должна существовать ассоциация. Потому что связь – это экземпляр ассоциации. Так же как объект – экземпляр класса. Ассоциации – это соединения между классами. На рис. 9.5 показаны отношения между классами и объектами и меж ду связями и ассоциациями. Поскольку не может быть связи без ассо циации, очевидно, что связи зависят от ассоциаций. Это можно смоде лировать как отношение зависимости (пунктирная стрелка), которое более подробно рассматривается в разделе 9.5. Чтобы явно обозначить семантику зависимости между ассоциациями и связями, зависимость помечается стереотипом «instantiate». Объекты – это экземпляры классов, а связи – экземпляры ассоциаций. chairperson secretary member BookClub bookClub:Club erica:Person ila:Person naomi:Person Рис. 9.4. Прямоугольный стиль отображения путей 9.4. Что такое ассоциация? 205 Семантика базовой, неуточненной ассоциации чрезвычайно проста: ас социация между классами указывает на то, что между объектами этих классов могут устанавливаться связи. Существуют другие, более кон кретные формы ассоциаций (агрегация и композиция), которые рас сматриваются в разделе 18.3 при обсуждении процесса проектирования. 9.4.1. Синтаксис ассоциации Ассоциации могут иметь: • имя ассоциации • имена ролей • кратность • возможность навигации Поскольку ассоциации обозначают действие, производимое исходным объектом над целевым объектом, в качестве их имен должны исполь зоваться глагольные группы. Перед именем или после него может при меняться маленькая черная стрелка, указывающая направление, в ко тором должно читаться имя ассоциации. Имя ассоциации записывает ся в стиле lowerCamelCase. В примере на рис. 9.6 ассоциация читается следующим образом: «Компания ( Company) нанимает много Человек (Persons)». Хотя стрелка указывает направление чтения ассоциации, всегда можно прочитать ее в обратном направлении. Таким образом, в примере на рис. 9.6 мож chairperson Club ассоциация cвязь «instantiate» «instantiate» «instantiate» ila:Person bookClub:Club Person Рис. 9.5. Отношения между классами и объектами и между связями и ассоциациями Company Person employs 1 возможность навигации имя ассоциации кратность * Рис. 9.6. Отображение ассоциации с использованием ее имени 206 Глава 9. Отношения но сказать, что в любой момент времени «каждый Человек ( Person) на нят только одной Компанией ( Company)». Имена ассоциаций – это глагольные группы, указывающие на семантику ассоциации. Альтернативный вариант – классам на обоих концах ассоциации мо гут быть присвоены имена ролей. Эти имена указывают на роли, ис полняемые объектами классов, когда они связаны экземплярами дан ной ассоциации. На рис. 9.7 можно видеть, что объект Company будет играть роль employer (работодатель), а объекты Person – роль employee (служащие), если они связаны экземплярами этой ассоциации. Имена ролей называют роль, которую могут играть объекты, поэтому они должны быть существительными или именными группами. Ассоциация может иметь или имя ассоциации, или имя роли. Указа ние и имени роли, и имени ассоциации для одной и той же ассоциации теоретически допустимо, но считается очень плохим стилем. Это уже перебор! Признак хороших имен ассоциаций и ролей – они должны легко чи таться. На рис. 9.6 ассоциация « Company employs many Persons» (Компа ния нанимает много Человек) звучит на самом деле замечательно. Ес ли прочитать ассоциацию в обратном направлении, получается « Person is employed by exactly one Company at any point in time» (Человек нанят только одной Компанией в любой момент времени). Тоже звучит не плохо. Аналогичным образом имена на рис. 9.7 ясно указывают роли, которые будут играть объекты этих классов, связанные именно таким образом. Имена ролей – это именные группы, указывающие на роли, исполняе мые объектами, связанными экземплярами этой ассоциации. 9.4.2. Кратность Ограничения – один из трех механизмов расширения UML, и крат ность – первый из рассматриваемых нами типов ограничений. Это так же самый распространенный тип ограничений. Кратность ограничи вает число объектов класса, которые могут быть вовлечены в конкрет Company Person employer 1 возможность навигации имя роли кратность employee * Рис. 9.7. Отображение ассоциации с использованием имен ролей 9.4. Что такое ассоциация? 207 ное отношение в любой момент времени. Фраза «в любой момент вре мени» – решающая для понимания кратностей. На рис. 9.8 можно увидеть, что в любой момент времени объект Person нанят только од ним объектом Company. Однако с течением времени объект Person мо жет быть нанят несколькими объектами Company. На рис. 9.8 можно найти еще кое какие любопытные вещи. Объект Person не может быть безработным, он всегда нанят только одним объ ектом Company. Таким образом, ограничение включает в себя два биз нес правила данной модели: • объекты Person в данный момент времени могут быть наняты только одним объектом Company; • объекты Person не могут быть безработными. Не важно, зависят или нет эти допустимые ограничения всецело от требований, предъявляемых к моделируемой системе, но это именно то, что выражает модель. Как видим, ограничения кратности имеют большое значение, в них могут быть закодированы ключевые бизнес правила модели. Однако эти правила «скрыты» в деталях модели. Грамотные разработчики мо делей называют такое сокрытие ключевых бизнес правил и требова ний «тривиализацией» (trivialization). Намного более глубокое обсуж дение этого феномена можно найти в книге [Arlow 1]. Кратность задается в виде разделенного запятыми списка интервалов, в котором каждый интервал представлен в форме: минимум..максимум где минимум и максимум – целые числа или любое выражение, возвраща ющее целое число. Если кратность не задана явно, значит, решение о ней еще не принято. Если кратность не задана явно, значит, решение о ней еще не принято. В UML нет «применяемой по умолчанию» кратности. В моделирова нии широко распространена ошибка, состоящая в том, что незаданная Company Person employer employee Компания нанимает много Человек Каждый Человек работает на одну Компанию 1 * Рис. 9.8. Отображение кратности на диаграмме 208 Глава 9. Отношения кратность по умолчанию предполагается равной 1. Некоторые приме ры синтаксиса кратности приведены в табл. 9.1. Кратность задает число объектов, которые могут принимать участие в отношении в любой момент времени. Таблица 9.1 Модель всегда необходимо читать так, как написано. Пример на рис. 9.9 иллюстрирует, что кратность действительно явля ется мощным ограничением, которое часто имеет огромное влияние на бизнес семантику модели. Если прочитать пример внимательно, можно увидеть, что: • у Company может быть ровно семь employee; • Person может быть нанят только одной Company (т. е. в данной модели P erson не может одновременно иметь больше одной должности); • у BankAccount может быть только один owner (владелец); • у BankAccount может быть один или много operator (операторов); • у Person может быть от нуля до множества BankAccount; • Person может управлять от нуля до множества BankAccount. При прочтении UML модели крайне важно понять, что именно выра жает модель, а не прибегать к предположениям или догадкам. Мы на зываем это «прочтением модели как есть». Например, рис. 9.9 утверждает, что у Company может быть именно семь e mployee, не больше и не меньше. Большинству такая семантика пока жется странной или даже неверной (если только это не очень странная компания), но именно так гласит модель. Об этом никогда нельзя за бывать. Существуют некоторые разногласия по поводу того, нужно ли показы вать кратность в аналитических моделях. Мы думаем, да, потому что Дополнение Семантика 0..1 Нуль или 1 1 Ровно 1 0..* Нуль или более * Нуль или более 1..* 1 или более 1..6 От 1 до 6 1..3, 7..10, 15, 19..* От 1 до 3, или от 7 до 10, или ровно 15, или от 19 до множества 9.4. Что такое ассоциация? 209 кратность описывает бизнес правила, требования и ограничения и мо жет вскрыть необоснованные предположения относительно предмет ной области. Очевидно, что такие предположения необходимо выяв лять и устранять как можно раньше. 9.4.2.1. Рефлексивные ассоциации Если класс имеет ассоциацию с самим собой, это рефлексивная ассо циация. Очень распространено явление, когда класс имеет ассоциацию с самим собой. Это называется рефлексивной ассоциацией и означает, что объ екты данного класса имеют связи с другими объектами этого же клас са. Замечательный пример рефлексивной ассоциации приведен на рис. 9.10. Каждый объект Directory (каталог) может иметь связи с объ ектами Directory, выступающими в роли subdirectory (подкаталог), число Company Person employer 1 employee BankAccount 1 1..* 0..* 0..* owner operator 7 Рис. 9.9. Кратность – мощное ограничение Directory File 0..* 1 0..* 0..1 C:Directory Windows:Directory My Documents:Directory Corel:Directory Command:Directory autoexec:File config:File To John:File каталоги файлы parent subdirectory рефлексивная ассоциация Рис. 9.10. Пример рефлексивной ассоциации: вверху – диаграмма классов, внизу – диаграмма объектов 210 Глава 9. Отношения которых может меняться от нуля до некоторой величины ( 0..*), а так же с нулем или одним ( 0..1) объектом Directory, выступающим в роли parent (родитель). Кроме того, каждый объект Directory ассоциирован с нулем или более объектов File (файл). В этом примере рефлексивные ассоциации превосходно моделируют универсальную структуру ката логов, хотя следует заметить, что у конкретных файловых систем (на пример, Windows) могут быть другие ограничения кратности. Верхняя половина рис. 9.10 представляет диаграмму классов. В ниж ней половине приведен пример диаграммы объектов, соответствую щей этой диаграмме классов. 9.4.2.2. Иерархии и сети В процессе моделирования вы обнаружите, что часто объекты органи зуются в иерархии или сети. Иерархия имеет один корневой объект. У каждого последующего узла иерархии только один прямой предше ственник. Деревья каталогов обычно формируют иерархии. То же са мое можно сказать о классификации в машиностроении и о элементах XML и HTML документов. Иерархия – это очень упорядоченный, структурированный и довольно негибкий способ организации объек тов. Пример иерархии показан на рис. 9.11. В иерархии объект может иметь один прямой объект предок или не иметь ни одного. Однако в сети обычно нет корневого объекта, хотя это не исключено. В сетях каждый объект может быть непосредственно соединен с мно гими объектами. В сети нет строгого представления «над» или «под». Это намного более гибкая структура, в которой возможно равенство между узлами. World Wide Web образует сложную сеть узлов, упро щенное представление которой показано на рис. 9.12. В сети объект может быть непосредственно соединен с многими объек тами или вообще не иметь соединения. a1: A c1: A d1: A b1: A e1: A f1: A g1: A A 0..* 0..1 Диаграмма классов Пример диаграммы объектов иерархия ассоциаций Рис. 9.11. Пример иерархии 9.4. Что такое ассоциация? 211 Давайте рассмотрим товары в качестве примера, иллюстрирующего иерархии и сети. Существует две фундаментальные абстракции: • ProductType (тип товара) – тип продукта, например «Струйный прин тер»; • ProductItem (товарная позиция) – конкретный струйный принтер с се рийным номером 0001123430. ProductType и ProductItem очень подробно рассматриваются в книге [Ar low 1]. Типы товаров обычно образуют сети. Таким образом, Product Type, например комплект вычислительного оборудования, может со стоять из ЦП, монитора, клавиатуры, мыши, видеокарты и других ти пов товаров ( ProductType). Каждый из этих ProductType описывает тип товара, а не конкретную товарную позицию, и эти типы товаров могут входить в другие составные ProductType, например в разные комплекты вычислительного оборудования. Если же рассматриваются товарные позиции ( ProductItem), которые яв ляются конкретными экземплярами ProductType, любая позиция Pro ductItem (например, конкретный ЦП) может быть продана и поставле на как часть одного комплекта товаров только один раз. Следователь но, товарные позиции образуют иерархии. 9.4.3. Возможность навигации Возможность навигации (navigability) указывает на возможность про хода от объекта исходного класса к одному или более объектам в зави симости от кратности целевого класса. Смысл навигации в том, что «сообщения могут посылаться только в направлении, в котором ука зывает стрелка». На рис. 9.13 объекты Order могут посылать сообще ния объектам Product, но не наоборот. Возможность навигации показывает, что объекты исходного класса «знают об» объектах целевого класса. Одна из целей хорошего ОО анализа и проектирования – минимизиро вать количество взаимосвязей между классами. И применение возмож Диаграмма классов A 0..* 0..* сеть ассоциаций Пример диаграммы объектов f1: A a1: A c1: A d1: A e1: A b1: A g1: A Рис. 9.12. Упрощенное представление сети WWW 212 Глава 9. Отношения ности навигации – верное средство достижения этой цели. Сделав ассо циацию между Order и Product однонаправленной, можно обеспечить воз можность свободной навигации от объектов Order к объектам Product, но не в обратном направлении – от объектов Product к объектам Order. Та ким образом, объекты Product не знают о своем возможном участии в конкретном Order и, следовательно, не имеют связанности с Order. Возможность навигации обозначается крестом или стрелкой на кон цах отношения, как показано на рис. 9.13. Спецификация UML 2.0 [UML2S] предлагает три стиля обозначения возможности навигации на диаграммах модели. 1. Сделать возможность навигации абсолютно явной. Должны быть обозначены все стрелки и кресты. 2. Сделать возможность навигации абсолютно скрытой. Стрелки и кре сты не обозначаются. 3. Опускать все кресты. Двунаправленная ассоциация обозначается без стрелок. Однонаправленная ассоциация обозначается с одной стрелкой. Эти три стиля представлены на рис. 9.14. Стиль 1 делает возможность навигации полностью видимой, что, одна ко, может сделать диаграмму слишком громоздкой. Стиля 2 следует избегать, потому что он скрывает слишком много зна чимой информации. Стиль 3 – разумный компромисс. На практике чаще всего используется стиль 3. И поскольку он представляет лучший на данный момент вари ант, именно он применяется в этой книге. Основные преимущества сти ля 3: при его использовании диаграммы не загромождаются слишком большим количеством стрелок и крестов; он обратно совместим с пре дыдущими версиями UML. Однако у этого стиля есть и недостатки. Order Product * * допускает навигацию не допускает навигации возможность навигации возможность навигации объект Order хранит список объектов Product объект Product не хранит списка объектов Order |