Виды диаграмм uml
Разработка модели любой
системы (не только программной) всегда предшествует ее созданию или обновлению.
Это необходимо хотя бы для того, чтобы яснее представить себе решаемую задачу.
Продуманные модели очень важны и для взаимодействия внутри команды
разработчиков, и для взаимопонимания с заказчиком. В конце концов, это
позволяет убедиться в "архитектурной согласованности" проекта до
того, как он будет реализован в коде.
Мы строим модели
сложных систем, потому что не можем описать их полностью, "окинуть одним
взглядом". Поэтому мы выделяем лишь существенные для конкретной задачи
свойства системы и строим ее модель, отображающую эти свойства. Метод
объектно-ориентированного анализа позволяет описывать реальные сложные системы
наиболее адекватным образом. Но с увеличением сложности систем возникает
потребность в хорошей технологии моделирования. В качестве такой "стандартной"
технологии используется унифицированный язык моделирования (Unified
Modeling Language, UML), который является
графическим языком для спецификации, визуализации, проектирования и
документирования систем. С помощью UML можно разработать
подробную модель создаваемой системы, отображающую не только ее концепцию, но и
конкретные особенности реализации. В рамках UML-модели все
представления о системе фиксируются в виде специальных графических конструкций,
получивших название диаграмм.
Графические изображения
моделей системы в UML
называются
диаграммами. В терминах языка UML определены следующие их виды:
·
диаграмма вариантов использования (use
case diagram)
·
диаграмма классов (class
diagram)
·
диаграммы поведения (behavior
diagrams)
·
диаграмма состояний (statechart
diagram)
·
диаграмма деятельности (activity
diagram)
·
диаграммы взаимодействия (interaction
diagrams)
·
диаграмма последовательности (sequence
diagram)
·
диаграмма кооперации (collaboration
diagram)
·
диаграммы реализации (implementation
diagrams)
·
диаграмма компонентов (component
diagram)
·
даграмма развертывания (deployment
diagram)
Диаграмма пакетов UML
Диаграмма
пакетов служит, в первую очередь, для организации элементов в группы по
какому-либо признаку с целью упрощения структуры и организации работы с моделью
системы.
Классы составляют
структурный костяк объектно-ориентированной системы. Хотя они исключительно
полезны, но нужно нечто большее для структурирования больших систем, которые
могут состоять из сотен классов.
Пакет (package) –
это инструмент группирования, который позволяет взять любую конструкцию UML и
объединить ее элементы в единицы высокого уровня. В основном пакеты служат для
объединения классов в группы, и именно этот способ их применения здесь
описывается, но помните, что пакеты могут применяться для любой другой
конструкции языка UML.
В модели UML каждый
класс может включаться только в один пакет. Пакеты могут также входить в состав
других пакетов, поэтому мы остаемся в иерархической структуре, в которой пакеты
верхнего уровня распадаются на подпакеты со своими собственными подпакетами, и
так далее, до самого низа иерархии классов. Пакет может содержать и подпакеты,
и классы.
Каждый пакет
представляет пространство имен (namespace), а это означает, что
каждый класс внутри собственного пакета должен иметь уникальное имя. Если я
хочу создать пакет с именем Date, а класс Date уже существует в пакете System,
то я обязан поместить его в отдельный пакет. Чтобы отличить один класс от
другого, я могу использовать полностью определенное имя (fully
qualified name), то есть имя, которое указывает на структуру, владеющую
пакетом. В языке UML в именах пакетов используются двойные двоеточия, поэтому
классы дат могут иметь имена System::Date и MartinFowler::Util::Date.
На диаграммах пакеты
изображаются в виде папок с закладками . Можно показывать только имя пакета или
имя вместе с его содержимым. В любом случае можно использовать либо полностью
определенные имена, либо обычные имена. Изображение содержимого с помощью
значков классов позволяет показать все особенности класса, вплоть до
изображения диаграммы классов внутри пакета. Простое перечисление имен имеет
смысл, если вы хотите лишь показать, какие классы входят в той или иной пакет.
Вполне можно встретить
класс, например, с именем Date (как в java.util), а не с полностью определенным
именем. Этот стиль является соглашением, в основном принятым в Rational Rose,
которое не входит в стандарт языка.
UML разрешает классам в
пакетах быть открытыми (public) или закрытыми (private). Открытые
классы представляют часть интерфейса пакета и могут быть использованы классами
из других пакетов; закрытые классы недоступны извне. В различных средах
программирования действуют различные правила в отношении видимости их
группирующими конструкциями; необходимо придерживаться правил своего
программного окружения, даже если это идет вразрез с правилами UML.
В таких случаях полезно
сократить интерфейс пакета, экспортируя только небольшое подмножество операций,
связанных с открытыми классами пакета. Можно сделать это, присвоив всем классам
модификатор видимости private (закрытый), так чтобы они были доступны только
классам данного пакета, а также создав дополнительные открытые классы для
внешнего использования. Эти дополнительные классы, называемые Facades (Фасады),
делегируют открытые операции своим более застенчивым соратникам по пакету.
Как распределить классы
по пакетам? Это действительно сложный вопрос, на который может ответить только
специалист с большим опытом работы в области проектирования. В этом деле могут
помочь два правила: общий принцип замыкания (Common Closure Principle) и общий
принцип повторного использования (Common Reuse Principle). Общий принцип
замыкания гласит, что причины изменения классов пакета должны быть одинаковые.
Общий принцип повторного использования утверждает, что классы должны
использоваться повторно все вместе. Большинство причин, по которым классы
должны объединяться в пакет, проистекают из зависимостей между классами.
Пакеты
и зависимости в диаграмме пакетов
Диаграмма пакетов
(package diagram) показывает пакеты и зависимости между ними. При наличии
пакетов для классов представления и пакетов для классов предметной области
пакет представления зависит от пакета предметной области, если любой класс
пакета представления зависит от какого-либо класса пакета предметной области.
Таким образом, межпакетная зависимость обобщает зависимости между их
содержимым.
В языке UML имеются
разнообразные виды зависимостей, каждая из которых обладает самостоятельной
семантикой и стереотипом. Намного проще начинать с зависимости без стереотипа и
использовать более конкретные виды зависимостей только по мере необходимости. В
средних и больших по размеру системах рисование диаграммы пакетов может быть
одним из самых ценных приемов, позволяющих управлять их многомерной структурой.
В идеале такая диаграмма должна быть сгенерирована на основании собственно
исходного кода, так чтобы она реально отражала происходящее в системе.
Многие авторы
утверждают, что в зависимостях не должно быть циклов (Acyclic Dependency Principle–
принцип ацикличности зависимостей,). Мы не считаем это правило абсолютным, но
циклы необходимо локализовать, в частности не должно быть циклов, пересекающих
уровни.
Чем больше зависимостей
входит в пакет, тем более стабильным должен быть его интерфейс, поскольку любые
изменения интерфейса отразятся на всех пакетах, зависящих от него. Поэтому на
рисунке пакету asset domain (предметная область собственности)
требуется более стабильный интерфейс, чем пакету leasing data mapper
(преобразователь данных аренды). Вы увидите, что зачастую более стабильные
пакеты содержат относительно больше интерфейсов и абстрактных классов (Stable
Abstractions Principle – принцип стабильных абстракций).
Отношения зависимостей
не транзитивны. Чтобы убедиться в важности этого свойства для зависимостей,
взгляните снова на рис. 7.2. Если изменяется класс пакета предметной области
собственности, то может измениться и класс из пакета предметной области
аренды (leasing domain).
Но эти изменения не
обязательно пройдут через представление аренды (leasing presentation). (Они
проходят, только если предметная область аренды изменяет свой интерфейс.)
Некоторые пакеты используются в таком количестве мест, что можно запутаться в
линиях зависимостей, идущих к ним. В таком случае действует соглашение, в
соответствии с которым на пакете указывается ключевое слово «global»
(глобальный).
В пакетах UML
определены также конструкции, позволяющие пакетам импортировать классы из
одного пакета в другой и объединять их, используя зависимости с ключевыми
словами для их обозначения. Однако правила для такого типа элементов
существенно отличаются в различных языках программирования. В целом, на
практике значительно более полезна основная нотация зависимостей.
Аспекты
пакетов
Рассматривая рисунок,
вы понимаете, что на диаграмме присутствуют структуры двух видов. Одна –
структура уровня приложения: представление (presentation), предметная
область (domain), преобразователь данных (data mapper) и база
данных (database). Другая – структура предметных областей: аренда (leasing)
и собственность (asset).
Это можно сделать более
прозрачным, если разделить два данных аспекта так, как это сделано на рис. 7.3.
На представленной диаграмме можно ясно увидеть каждый аспект. Однако эти два
аспекта не являются истинными пакетами, поскольку рассматриваемые классы можно
объединить в один пакет. (Возможно, вам придется извлечь по одному классу из
каждого аспекта.) Эта проблема является отражением проблемы иерархических
пространств имен в языках программирования. Хотя диаграммы, подобные
представленным на рис 7.3, не входят в стандарт языка UML, они зачастую очень
удобны для объяснения структуры сложных приложений.
Реализация
пакетов в диаграмме пакетов
Часто встречается
ситуация, когда один пакет определяет интерфейс, который может быть реализован
многими другими пакетами, как это показано на рисунок. В данном случае
отношение реализации означает, что шлюз базы данных (Database Gateway)
определяет интерфейс, а другие классы шлюзов обеспечивают реализацию. На
практике это может означать, что пакет шлюза базы данных (Database Gateway)
содержит интерфейсы и абстрактные классы, которые полностью реализуются в
других пакетах.
Общепринято размещать
интерфейс и его реализацию в разных пакетах. Действительно, клиентский пакет часто
содержит интерфейс, который должен быть реализован другим пакетом.
Допустим, что вы хотите
предоставить некоторый пользовательский интерфейс (UI) выключателей (controls)
для включения и выключения некоторого объекта. Мы хотим, чтобы он работал с
различными устройствами, такими как обогреватели (heaters) или лампы (lights).
Выключатели UI должны
вызывать методы обогревателя, но мы не хотим, чтобы выключатели зависели от
обогревателя. Мы можем избежать этой зависимости, определяя в пакете
выключателей интерфейс, который затем реализуется каждым классом, работающим с
этими выключателями, как показано на рисунок внизу. Здесь представлен пример
шаблона Separated Interface(Разделенный интерфейс) .
Официальный сайт
EmoticonEmoticon