UML2 и унифицированный процесс. Джим арлоуайла нейштадтпрактический объектно ориентированныйанализ и проектированиеu
 Скачать 6.08 Mb.
|
|
Символ Видимость Семантика + открытая ( public) Элементы с открытой видимостью видимы вне пакета – они экспортируются пакетом. – закрытая ( private) Элементы с закрытой видимостью полностью скрыты внутри пакета. Стереотип Семантика «framework» (каркас) Пакет, содержащий элементы модели, которые опре деляют многократно используемую архитектуру. «modelLibrary» (библиотека модели) Пакет, содержащий элементы, которые предназначе ны для повторного использования другими пакетами. 252 Глава 11. Пакеты анализа Полное имя образуется именем элемента и именами пакетов, в которых он находится, перечисленными через двойные двоеточия. Первым ука зывается имя самого внешнего пакета, далее перечисляются все осталь ные пакеты в порядке вложенности вплоть до самого элемента. Полные имена очень похожи на составные имена в структурах каталогов. Например, полное имя класса Librarian (библиотекарь) с рис. 11.3 будет таким: Library::Users::Librarian 11.4. Вложенные пакеты Пакеты могут быть вложены в другие пакеты с любой глубиной вложен ности. Однако обычно достаточно всего двух или трех уровней. В про тивном случае модель может стать трудной для понимания и в ней бу дет сложно ориентироваться. UML предлагает два способа представления вложенности. Первый очень нагляден, поскольку в нем элементы модели показаны физиче ски вложенными в пакет. Пример представлен на рис. 11.3. Альтернативный синтаксис вложения показан на рис. 11.4. Он удо бен, когда необходимо представить глубокое или сложное вложение, которое может быть непонятным в случае отображения с помощью встраивания. Вложенные пакеты имеют доступ к пространству имен своего пакета владельца. Таким образом, элементы пакета Users (пользователи) на рис. 11.4 могут организовывать доступ ко всем элементам пакета Library (библиотека) через неполныеимена. Однако обратное невозможно. Па кет владелец для доступа к содержимому пакетов, которыми он владе ет, должен использовать полные имена. Таким образом, в рассматри ваемом примере элементы пакета Library для доступа к двум элементам пакета Users должны использовать полные имена: Users::Librarian и Us ers::Borrower. В следующем разделе будет показано, как можно использовать зависи мости для объединения пространств имен пакетов. Library Users Librarian Borrower Рис. 11.3. Синтаксис вложения путем встраивания 11.5. Зависимости пакетов 253 11.5. Зависимости пакетов Между пакетами может быть установлено отношение зависимости. Отношение зависимости показывает, что один пакет некоторым обра зом зависит от другого. Рассмотрим пример на рис. 11.5. Любой пакет, имеющий отношение зависимости с пакетом Membership (членство), сможет видеть открытые Library Users Librarian Borrower пиктограмма якоря отношение включения Рис. 11.4. Синтаксис сложного вложения Membership MemberDetails «import» видимость private отношение зависимости пакета JoiningRules +ClubMembership +Benefits +MembershipRules +Member видимость public Рис. 11.5. Структура пакета Membership 254 Глава 11. Пакеты анализа элементы этого пакета ( ClubMembership (членство в клубе), Benefits (льго ты) и т. д.), но не будет видеть закрытый элемент JoiningRules (правила вступления). Существует пять разных типов зависимостей между пакетами, каж дый из которых имеет собственную семантику. Их обзор представлен в табл. 11.3. Таблица 11.3 Зависимость «use» означает, что зависимости установлены скорее меж ду элементами пакетов, а не между самими пакетами. Зависимости «import» и «access» объединяют пространства имен клиен та и поставщика. Это позволяет элементам клиента организовывать Отношение зависимости пакетов Семантика Элемент клиентского пакета некоторым образом использует открытый элемент пакета поставщика – клиент зависит от поставщика. Если зависимость пакета показана без стереотипа, необходимо предполагать зависимость «use». Открытые элементы пространства имен поставщика добавляются как открытые элементы в пространство имен клиента. Элементы клиента могут организовы вать доступ ко всем открытым элемен там поставщика через неполные имена. Открытые элементы пространства имен поставщика добавляются как закрытые элементы в пространство имен клиента Элементы клиента могут организовы вать доступ ко всем открытым элемен там поставщика с помощью неполных имен. «trace», как правило, представляет исто рическое развитие одного элемента в дру гую более развитую версию; обычно это отношение между моделями, а не эле ментами (межмодельное отношение). Открытые элементы пакета поставщика объединяются с элементами клиентско го пакета. Эта зависимость используется только при создании метамодели; в обычном ОО анализе и проектировании она не долж на встречаться. Supplier Client «use» Supplier Client «import» Supplier Client «access» Design Model «trace» Analysis Model Supplier Client «merge» 11.5. Зависимости пакетов 255 доступ к элементам поставщика с помощью неполных имен. Разница между этими двумя зависимостями в том, что «import» осуществляет открытое объединение, т. е. объединенные элементы поставщика ста новятся открытыми в клиенте. Тогда как «access» проводит закрытое объединение, т. е. объединенные элементы становятся в клиенте за крытыми. «trace» – «останется только один». Тогда как другие зависимости паке тов устанавливаются между сущностями одной модели, «trace» обычно представляет некоторое историческое развитие одного пакета в другой. Поэтому «trace» часто отражает отношения между разными моделями. Полная UML модель может быть представлена в виде пакета с малень ким треугольником в верхнем правом углу. В табл. 11.3 показана межмодельная зависимость «trace» между аналитической моделью и проектной моделью. Очевидно, что такая диаграмма является метамо делью, в которой моделируются отношения между моделями! Как та ковая она используется не очень часто. «merge» – сложное отношение, которое обозначает ряд трансформаций между элементами пакета поставщика и пакета клиента. Элементы пакета поставщика объединяются с элементами клиента для создания новых, расширенных клиентских элементов. Эта зависимость исполь зуется только при создании метамоделей (например, она широко при меняется в метамодели UML) и не должна применяться в обычном ОО анализе и проектировании. Далее в книге она нигде не обсуждается. Дополнительную информацию можно найти в книге [Rumbaugh 1]. 11.5.1. Транзитивность Транзитивность (transitivity) – термин, применяемый к отношениям. Он означает, что если существует отношение между сущностями A и B и отношение между сущностями B и C, то существует неявное отноше ние между сущностями A и C. «import» – транзитивное отношение, «access» – нет. Важно отметить, что зависимость «import» – транзитивная, а зависи мость «access» – нет. Как было показано выше, это объясняется тем, что при наличии зависимости «import» между клиентом и поставщиком открытые элементы пакета поставщика становятся открытыми эле ментами клиента. Эти импортированные открытые элементы доступ ны вне клиентского пакета. С другой стороны, когда между клиентом и поставщиком установлена зависимость « access», открытые элементы пакета поставщика становятся закрытыми элементами клиента. Эти закрытые элементы не доступны вне клиентского пакета. Рассмотрим пример, приведенный на рис. 11.6. Пакет A обеспечивает доступ к пакету B, а пакет B – к пакету C. 256 Глава 11. Пакеты анализа Отсутствие транзитивности в «access» означает следующее: • открытые элементы пакета C становятся закрытыми элементами пакета B; • открытые элементы пакета B становятся закрытыми элементами пакета A; • следовательно, элементы пакета A не имеют доступа к элементам пакета C. Эта нетранзитивность «access» позволяет активно управлять и контро лировать внутреннюю связность и целостность модели. Доступно толь ко то, что указано явно. 11.6. Обобщение пакетов Обобщение пакетов во многом подобно обобщению классов. В обобще нии пакетов более специализированные дочерние пакеты наследуют открытые элементы родительского пакета. Дочерние пакеты могут вводить новые элементы и переопределять элементы родительского пакета, предоставляя альтернативный элемент с тем же именем. В примере на рис. 11.7 пакеты Hotels (гостиницы) и CarHire (прокат ав томобилей) наследуют все открытые элементы своего родительского A B C «access» «access» Рис. 11.6. «access» – нетранзитивная зависимость CarHire Hotels +Product::Price +Product::Market +Item +Car Product +Price +Market +Item –MicroMarket +Product::Price +Product::Market +Item +Hotel +RoomType дети родитель Рис. 11.7. Дочерние элементы наследуют элементы родителя 11.7. Архитектурный анализ 257 пакета Product (продукт). Но пакеты Hotels и CarHire переопределяют класс Item (элемент), унаследованный от родителя, предоставляя аль тернативный класс с тем же именем. Дочерние пакеты также могут до бавлять новые элементы. Пакет Hotels вводит классы Hotel и RoomType (тип комнаты), а пакет CarHire вводит класс Car (автомобиль). Дочерние пакеты наследуют элементы от своих родителей. Они могут переопределять родительские элементы. Они могут вводить новые эле менты. Как и при наследовании классов, должен применяться принцип заме щаемости: везде, где может использоваться пакет Product, должна су ществовать возможность применять или Hotels, или CarHire. 11.7. Архитектурный анализ В архитектурном анализе взаимосвязанные классы анализа объединя ются в ряд пакетов анализа. Затем организуются разделы и уровни, как показано на рис. 11.8. Каждый пакет анализа на определенном уровне – это раздел. Архитектурный анализ группирует взаимосвязанные классы в пакеты анализа, а затем распределяет пакеты по уровням. Одна из целей архитектурного анализа – попытаться минимизировать число взаимосвязей в системе. Сделать это можно тремя способами: • сократить до минимума зависимости между пакетами анализа; • сократить до минимума число открытых элементов в каждом паке те анализа; • максимально увеличить число закрытых элементов в каждом паке те анализа. InventoryManagement Products AccountManagement Sales уровень, специфичный для приложения уровень, общий для приложений раздел раздел Рис. 11.8. Пакеты распределяются по уровням 258 Глава 11. Пакеты анализа Всегда сокращайте до минимума количество взаимосвязей. Сокращение количества взаимосвязей – одна из наиболее важных задач архитектурного анализа, потому что системы с высокой степенью свя занности обычно сложны для построения и обслуживания. Всегда необ ходимо пытаться обеспечить минимально необходимую связанность. По мере углубления и превращения модели в проектную количество уровней будет расти. Но на этапе анализа пакеты можно просто распре делить по двум уровням: специфичному и общему для приложений. Специфичный уровень содержит функциональность, абсолютно специ фичную для конкретного приложения. Общий уровень содержит более широко используемые функциональные возможности. На рис. 11.8 AccountManagement (ведение счетов) и InventoryManagement (управление материально техническими ресурсами) могут использоваться в не скольких разных приложениях, поэтому эти пакеты, как и следовало ожидать, находятся в общем уровне. 11.7.1. Выявление пакетов анализа Ищите группы классов, образующие связный элемент. Выявление пакетов анализа осуществляется путем идентификации групп элементов модели, имеющих прочные семантические связи. Па кеты анализа часто обнаруживаются со временем в ходе развития и со вершенствования модели. Пакеты анализа обязательно должны отра жать реальные семантические группы элементов, а не просто некото рое идеализированное (но выдуманное) представление логической ар хитектуры. Где начинать поиск таких групп? Статическая модель – самый полез ный источник пакетов. Необходимо искать следующее: • связные группы классов на диаграммах классов; • иерархии наследования. В качестве источника пакетов можно также рассматривать модель прецедентов. Важно попытаться сделать пакеты максимально связан ными с точки зрения бизнес процесса. Обычно прецеденты пересека ют несколько пакетов анализа: один прецедент может реализовывать ся классами из нескольких разных пакетов. Тем не менее один или бо лее прецедентов, поддерживающих определенный бизнес процесс, или актера, или ряд взаимосвязанных прецедентов, могут указывать на потенциальный пакет. После идентификации ряда предполагаемых пакетов необходимо по пытаться сократить до минимума количество открытых членов и зави симостей между пакетами. Это осуществляется путем: 11.7. Архитектурный анализ 259 • перемещения классов из пакета в пакет, • добавления пакетов, • удаления пакетов. Основой хорошей структуры пакетов является высокая связность в рамках пакета и низкая связанность между пакетами. Пакет должен содержать группу тесно взаимосвязанных классов. Самую тесную взаи мосвязь классов образует наследование (глава 10), далее композиция (глава 18), агрегирование (глава 18) и наконец зависимости (глава 9). Классы, образующие иерархии наследования или композиции, явля ются основными кандидатами на размещение в одном пакете. Это обе спечит высокую связность в рамках пакета и, вероятно, более низкую связанность с другими пакетами. И как всегда, при создании аналитической модели пакетов необходи мо придерживаться простоты. Важнее получить правильный набор па кетов, чем широко применять такие возможности, как обобщение па кетов и стереотипы зависимостей. Все это можно добавить позже и только в том случае, если это сделает модель более понятной. Отсутст вие вложенных пакетов – один из гарантов простоты модели. Чем глубже что то помещено в структуру вложенных пакетов, тем более непонятным оно становится. Нам встречались модели с очень глубоко вложенными пакетами, содержащими лишь один два класса. Такие модели больше похожи на стандартную функциональную декомпози цию, чем на объектную модель. В пакете должно быть от четырех до десяти классов анализа. Но могут быть и исключения из правил. Если нарушение этого правила делает модель более ясной, нарушайте его! Иногда в модель пакетов необхо димо ввести пакеты с одним двумя классами, чтобы избавиться от циклической зависимости. В таких случаях это вполне обоснованно. На рис. 11.9 показан пример аналитической модели пакетов для про стой системы электронной коммерции. Эта система представлена как учебный пример на нашем веб сайте www.umlandtheunifiedprocess.com. Security Product Order Customer Shop ShoppingBasket ShopAssistant SecurityGuard SecurityProfile CustomerSecurityProfile UserSecurityProfile ProductCatalog Product Category Book CD Order OrderManager ShippingDetails Item CustomerDetails CustomerManager CreditCardDetails Рис. 11.9. Модель пакетов анализа для системы е коммерции 260 Глава 11. Пакеты анализа 11.7.2. Циклические зависимости пакетов В аналитической модели пакетов необходимо избегать циклических зависимостей. Если пакет А некоторым образом зависит от пакета В, и наоборот, то это очень сильный аргумент в пользу объединения этих двух пакетов. Объединение пакетов (merging) является хорошим спо собом устранения циклических зависимостей. Но лучше, и это очень часто срабатывает, попытаться вынести общие элементы в третий па кет С и удалить цикл, перестроив отношения зависимостей. Это ото бражено на рис. 11.10. Избегайте циклических зависимостей между пакетами. Многие инструментальные средства моделирования позволяют авто матически проверять зависимости между пакетами. Такой инстру мент создает список нарушений прав доступа, если элемент одного па кета организовывает доступ к элементу другого пакета, но между эти ми двумя пакетами не установлена видимость или зависимость. В аналитической модели порой невозможно создать диаграмму паке тов без нарушения прав доступа, поскольку в анализе часто использу ются двунаправленные отношения между классами. Предположим, имеется очень простая модель: один класс находится в пакете А, другой класс – в пакете В. Если класс пакета А имеет двунаправленное отноше ние с классом пакета В, тогда пакет А зависит от пакета В, но и пакет В зависит от пакета А. Имеем циклическую зависимость между двумя па Возможны более сложные циклы, в которых принимают участие три или более пакетов! A B A B C разделение A объединение Рис. 11.10. Два способа устранения циклических зависимостей 11.8. Что мы узнали 261 кетами. Единственная возможность избавиться от этого нарушения – уточнить отношение между А и В, сделав его однонаправленным, либо поместить оба класса в один пакет. Таким образом, зависимости паке тов являются превосходным аргументом в пользу применения воз можности навигации в аналитических моделях! С другой стороны, классы, действительно имеющие взаимные зависимости (а не зависи мости, являющиеся результатом несовершенства модели), должны на ходиться в одном пакете. 11.8. Что мы узнали В этой главе были рассмотрены пакеты анализа. В частности, было по казано, как можно максимально увеличить связность пакета анализа и свести до минимума количество связей между пакетами анализа. Это помогает создавать более надежные и удобные в обслуживании системы. Мы узнали следующее: |