2. Язык UML. Руководство пользователя. Буч_ Рамбо_ Якобсон (2-е издание) (2006) (1185732), страница 36
Текст из файла (страница 36)
Допустим также, чтообсуждают- А и В объявлены открытыми частями в своих пакетах. Эта ситуацияся в главе 5,коренным образом отличается от двух предыдущих. Хотя оба класмеханизмыса объявлены открытыми, свободный доступ одного из них к друрасширениягому невозможен, ибо границы пакетов непрозрачны. Однако еслиUML – в гла- пакет, содержащий класс А, импортирует пакетFвладелец класса В,ве 6.то А сможет «видеть» В, хотя В поFпрежнему не будет «видеть» А.Импорт дает элементам одного пакета односторонний доступ к элементам другого. На языке UML связь импорта моделируют как зависимость, дополненную стереотипом import. Упаковывая абстракции в семантически осмысленные блоки и контролируя доступ кним с помощью импорта, вы можете управлять сложностью систем,насчитывающих множество абстракций.На заметку.
Фактически в рассмотренной ситуации применяются два стереотипа – import и access, и оба они показывают, чтоисходный пакет имеет доступ к элементам целевого. Стереотипimport добавляет содержимое целевого пакета в открытоепространство имен исходного, поэтому нет необходимостив квалификации их имен.
Таким образом, возникает вероятность конфликта имен, которого необходимо избегать, если выПакеты184Типичные приемы моделирования185Зависимости импорта и доступа являются транзитивными.В данном примере пакет Client импортирует Policies, а Policies – GUI,так что можно сказать, что Client транзитивно импортирует GUI. ЕслиPolicies имеет доступ в GUI, не импортируя его, то Client не добавляет элементы GUI к своему пространству имен, но может обращатьсяк ним, используя квалифицированные имена (такие как, например,GUI::Window).хотите, чтобы модель была хорошо согласована. Стереотипaccess добавляет содержимое целевого пакета в закрытое пространство имен исходного. Единственное различие заключается в том, что нельзя повторно экспортировать импортированные элементы, если какойQлибо третий пакет импортируетпервоначальный исходный пакет.
Чаще используют стереотип import.На заметку. Элемент, видимый внутри пакета, будет видимтакже и внутри всех вложенных в него пакетов. Вообще, вложенные пакеты могут «видеть» все, что «видят» включающиеих пакеты. Имя во вложенном пакете может скрывать имяво включающем пакете; в этом случае для ссылки требуетсяквалифицированное имя.Открытые элементы пакета называют экспортируемыми. Так,Интерфейсыобсуждают- на рис.
12.4 пакет GUI экспортирует два класса – Window (Окно) и Formся в главе 11. (Форма). Класс EventHandler (ОбработчикСобытий) является защищенной частью пакета. Довольно часто экспортируемыми элементами пакета являются интерфейсы.-Типичные приемы моделированияМоделирование групп элементов«import»«import»Рис. 12.4.
Импорт и экспортЭкспортируемые элементы будут видимы для содержимого техпакетов, для которых видим данный пакет. В примере на рис. 12.4пакет Policies (Политики) явно импортирует пакет GUI. Таким образом, классы GUI::Window и GUI::Form будут видимы для содержимого пакета Policies как классы с простыми именами Window и Form.Но класс GUI::EventHandler будет скрыт, так как является защищенным. С другой стороны, пакет Server не импортирует GUI, поэтому элементы Server имеют доступ к открытым элементам GUI,но для этого им понадобятся квалифицированные имена, например GUI::Window.
Аналогично у GUI нет доступа к содержимому пакета Server даже с использованием квалифицированных имен, поскольку оно закрыто.Пять представленийархитектуры обсуждаютсяв главе 2.Чаще всего пакеты применяют для организации элементов моделирования в именованные группы, с которыми потом можно будет работать как с единым целым. Создавая простое приложение,можно вообще обойтись без пакетов, поскольку все ваши абстракции прекрасно разместятся в единственном пакете. В более сложных системах вы скорее обнаружите, что многие классы, компоненты, узлы, интерфейсы и даже диаграммы естественным образомразделяются на группы.
Эти группы и моделируют в виде пакетов.Между классами и пакетами есть одно значительное различие:классы являются абстракцией сущности из предметной областиили из области решения, а пакеты – это механизмы организациитаких сущностей в модели. Пакеты не видны в работающей системе,они служат исключительно механизмом организации разработки.Чаще всего с помощью пакетов элементы одинаковых базовыхтипов организуют в группы. Например, классы и их связи в представлении системы с точки зрения проектирования можно разбитьна несколько пакетов и контролировать доступ к ним с помощьюзависимостей импорта.
Компоненты представления реализации допустимо организовать таким же образом.Пакеты также применяются для группирования элементовразличных типов. Например, если система создается несколькимиколлективами разработчиков, расположенными в разных местах,то пакеты можно использовать для управления конфигурацией,размещая в них все классы и диаграммы, так чтобы члены разныхПакеты186коллективов могли независимо извлекать их из хранилища и помещать обратно. На практике пакеты часто применяют для группирования элементов модели и ассоциированных с ними диаграмм.Чтобы смоделировать группы элементов, необходимо: Просмотреть элементы модели в некотором представленииархитектуры системы с целью поиска групп элементов, близких семантически или концептуально.
Поместить каждую такую группу в пакет. Для каждого пакета определить, какие элементы должны бытьдоступны извне. Пометить их как открытые, а остальные –как защищенные или закрытые. В сомнительных случаяхскрыть элемент. Явно соединить пакеты зависимостями импорта с теми пакетами, от которых они зависят. При наличии семейств пакетов соединить специализированные пакеты с более общими связями обобщения.В качестве примера на рис. 12.5 показаны пакеты, которые организуют в классическую трехуровневую архитектуру классы, являющиеся частями представления информационной системы с точки зренияпроектирования. Элементы пакета User Services (ПользовательскиеСервисы) предоставляют визуальный интерфейс для ввода и выводаинформации.
Элементы пакета Data Services (Сервисы Данных) обеспечивают доступ к данным и их обновление. Пакет Business Services(БизнесFсервисы) является связующим звеном между элементамипервых двух пакетов; он охватывает все классы и другие элементы, отвечающие за выполнение бизнесFзадачи, в том числе бизнесFправила,которые диктуют стратегию манипулирования данными.«import»«import»Рис. 12.5. Моделирование групп элементовТипичные приемы моделированияДокументирующеепомеченноезначениеобсуждаетсяв главе 6.187Все абстракции простой системы можно поместить в один пакет. Однако, организуя классы и другие элементы представлениясистемы с точки зрения проектирования в три пакета, вы не толькосделаете модель более понятной, но и сможете контролировать доступ к ее элементам, скрывая одни и экспортируя другие.На заметку. Изображая подобные модели, обычно показывают элементы, центральные для каждого пакета.
Чтобы прояснить назначение пакетов, можно также использовать документирующее помеченное значение для каждого из них.Моделирование архитектурных представленийИспользование пакетов для группирования родственных элементов весьма важно – без него нельзя разработать сложную модель. Данный подход применим к организации таких элементов,как классы, интерфейсы, компоненты, узлы и диаграммы. Но прирассмотрении архитектурных представлений программных системвозникает потребность в еще более крупных блоках. Архитектурные представления тоже можно моделировать с помощью пакетов.Связь предНапомним, что представлением (view) называется проекцияставленийорганизации и структуры системы, в которой внимание акцентирус моделямиется на одном из конкретных ее аспектов.
Из этого определения выобсуждает- текают два следствия. ВоFпервых, систему можно разложить на почся в главе 32. ти ортогональные пакеты, каждый из которых имеет дело с наборомархитектурно значимых решений (например, можно создать представления с точки зрения проектирования, взаимодействий, реализации, размещения и вариантов использования). ВоFвторых, этимпакетам будут принадлежать все абстракции, относящиеся к данному представлению. Так, все компоненты модели принадлежат пакету, который моделирует представление реализации. В то же времяпакеты могут содержать ссылки на элементы других пакетов.Для моделирования архитектурных представлений необходимо:Пять представленийархитектуры описываютсяв главе 2.
Идентифицировать набор архитектурных представлений,значимых в контексте вашей проблемы. На практике этот набор обычно включает представления проектирования, взаимодействия, реализации, размещения и вариантов использования. Разместить те элементы и диаграммы, которые необходимыи достаточны для визуализации, специфицирования, конструирования и документирования семантики каждого представления, в соответствующем пакете.Пакеты188 При необходимости выполнить дальнейшую группировкуэтих элементов в пакеты.Между элементами различных представлений обычно возникают зависимости. Таким образом, каждое представление на верхнемуровне системы должно быть открыто для всех остальных представлений этого уровня.МоделироваВ качестве примера на рис.
12.6 показана каноническая декомпоние системзиция верхнего уровня, типичная для большинства сложных систем.обсуждается в главе 32.вид с точки зрениявариантовиспользованияРис. 12.6. Моделирование архитектурных представленийСоветы и подсказкиМоделируя пакеты в UML, помните, что они нужны толькодля организации элементов вашей модели. Если имеются абстракции, непосредственно материализуемые как объекты в системе, непользуйтесь пакетами. Вместо них применяйте такие элементы моделирования, как классы или компоненты.Хорошо структурированный пакет характеризуется следующими свойствами: он внутренне согласован и очерчивает четкую границу вокруг группы родственных элементов; он слабо связан и экспортирует в другие пакеты толькоте элементы, которые они действительно должны «видеть»,а импортирует лишь те, которые принципиально важны дляработы его собственных элементов; глубина вложенности пакета невелика, поскольку человекне способен воспринимать слишком глубоко вложенныеструктуры; владея сбалансированным набором элементов, пакет по отношению к другим пакетам в системе не должен быть ни слишком большим (если надо, расщепляйте его на более мелкие),Советы и подсказки189ни слишком маленьким (объединяйте элементы, которымиможно манипулировать как единым целым).Изображая пакет в UML, руководствуйтесь следующими принципами: применяйте простую форму пиктограммы пакета, если не требуется явно раскрыть его содержимое; раскрывая содержимое пакета, показывайте только те элементы, которые принципиально необходимы для пониманияего назначения в данном контексте; моделируя с помощью пакета сущности, относящиеся к управлению конфигурацией, раскрывайте значение меток, связанных с номерами версий.Базовые понятияГлава 13.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
