Основные теоретические сведения
В UML, так же, как и в объектно-ориентированном программировании [ 1 ], класс (class) – описание множества объектов, обладающих общими атрибутами, операциями, отношениями и поведением. Класс является результатом операции обобщения.
Поэтому класс – всегда абстрактное понятие. Задание конкретных значений атрибутов и определяет экземпляр класса - объект, обладающий конкретным поведением. Объект может появляться во всех отношениях класса и всех его предков.
Для некоторых классов создание прямых экземпляров невозможно, такие классы используются только для описания общей структуры потомков и называются абстрактными. Класс, имеющий конкретные экземпляры, условно называется конкретным (хотя на самом деле он абстрактен).
Класс имеет имя, списки атрибутов, операций или методов.
Операция (operation) – спецификация (описание) результата преобразования или запроса, которые должен выполнить вызываемый объект. Имеет имя и список параметров.
Метод (method) – процедура, непосредственно реализующая операцию; у нее есть алгоритм и описание процедуры. Обычно метод задаётся на физическом уровне представления класса в модели проектирования, когда уже выбран алгоритм и способ его реализации.
Другой способ реализации операций: событие вызова, переводящее активный объект в другое состояние. Более подробно этот способ реализации
рассмотрим позже, когда будет изучаться диаграмма состояний.
|
|
|
В отличие от метода операция может быть абстрактной, т.е. не иметь определенного способа реализации, для нее нельзя определить ни метод, ни событие вызова. Графически класс изображается прямоугольником, который дополнительно делится горизонтальными линиями на разделы или секции. В них указываются имя класса, его атрибуты и операции. Различные варианты обозначений классов представлены на рисунке 2. В разделе имени в двойных угловых кавычках дополнительно может быть указан стереотип класса – группа, к которой принадлежит класс.
Атрибуты класса (class attributes) (свойства, properties) – свойства или характеристики данного класса, которые могут принимать только одно значение из некоторого множества значений определенного типа.
Совокупность значений атрибутов определяет экземпляр класса – объект или абстрактный класс – потомок.
 |
Рисунок 2 – Варианты обозначений класса в UML
Операции могут быть сигналами. Сигнал является фундаментальным видом коммуникации, имеет характер одностороннего сообщения, идущего от одного объекта к другому. Поэтому операция по сигналу не имеет возвращаемого значения. Перед ней ставится стереотип «signal».
|
|
|
Классы могут находиться между собой в различных отношениях (связях). Базовыми отношениями являются:
· отношения зависимости (dependency relationship);
· отношения ассоциации (association relationship);
· отношения обобщения (generalization relationship);
· отношения реализации (realization relationship).
Отношение зависимости, зависимость – отношение между двумя классами, при котором изменение одного класса (поставщика) может затронуть другой класс (клиент) или предоставить ему необходимую информацию.
В зависимость включаются все виды связей, кроме ассоциаций, обобщений и реализаций. Зависимость может иметь имя, но часто его не ставят, учитывая, что из контекста ясна семантика отношения. Зависимость изображается пунктирной строкой от клиента (зависимого класса) к поставщику (независимому классу) (рисунок 3). На рисунке 3 класс А вызывает операции классов В и С; класс С создаёт экземпляры класса В, пользуясь его конструктором; операция класса D может иметь доступ в порядке исключения к содержимому класса В.
 |
Рисунок 3 – Зависимости между классами
Отношение ассоциации (ассоциация, association) – описывает связи между экземплярами классов (объектами) - в отличие от зависимости, которая относится к классу в целом. В ассоциации проставляется множественность участия экземпляров в связи (один или много).
|
|
|
Наиболее проста бинарная ассоциация, в которой участвуют в точности 2 класса или, как исключение, один класс, связанный сам с собой. В бинарной ассоциации может быть указано направление связи – зачернённым треугольником.
На рисунке 4 экземпляром отношения является, например, пара «Иванов – ООО «Ракурс»».
 |
Рисунок 4 – Бинарная ассоциация
Важной характеристикой ассоциации является кратность (множественность и обязательность связи). Обозначение “*” обозначает “0..*”, т.е. необязательность связи «много».
Важным частным случаем отношения ассоциации, выделяемым в отдельную группу, является отношение агрегации.
Отношение агрегации (агрегация, aggregation) (рисунок 5) – один из классов (агрегат) состоит из других классов или его характеристиками являются другие классы (отношение часть/ целое, part of). Это отношение является фундаментальным при моделировании системы, позволяет декомпозировать систему на составные части. В агрегации принцип наследования не соблюдается. Каждая часть или характеристика обладает своими атрибутами и поведением. Агрегация в UML обозначается ромбом, примыкающим к агрегату.
|
|
|
 |
Рисунок 5 - Агрегат и его части
У полюсов связей может быть указана множественность. Любая часть может входить в несколько различных агрегатов.
Частным случаем агрегации является композиция.
Композиция (composition) – усиленная форма агрегации, в которой агрегат, называемый композитом, несёт полную ответственность за создание и уничтожение своих частей, т.е. самостоятельно классы - части композита существовать не могут. Таким образом, время жизни частей не превышает времени жизни агрегата – композита (она может быть меньше). Композиция обозначается закрашенным ромбом.
 |
Рисунок 6 – Отношение композиции
В композиции, представленной на рисунке 6, отдельные части окна (заголовок и др.) не могут существовать самостоятельно и удаляются вместе с удалением экземпляра окна. Единственное ограничение, которое вносит агрегация в ассоциацию – отсутствие цикличности связи, так как класс не может содержаться сам в себе.
Отношение обобщения (обобщение, generalization) – обычное таксономическое отношение между родителем (предком) и частными примерами (дочерьми, детьми, сыновьями, потомками). Экземпляр потомка можно использовать всюду, где объявлен более общий элемент, при этом в потомке сохраняются все свойства и операции (методы), т.е. соблюдается принцип наследования. Обобщение используется в качестве связи между классами, пакетами, вариантами использования, актантами (рисунок 7).
 |
Рисунок 7 - Пример обозначения обобщения
Обозначается оно прямой линией с треугольной незакрашенной стрелкой, направленной к обобщению (родителю). Многоточие означает, что все возможные потомки пока не перечислены и могут появиться другие потомки (свойство «неполный», incomplete). Отсутствие многоточия говорит о полном перечислении потомков (свойство «полный», complete).
Как правило, предполагается, что подклассы имеют единственное обобщение (суперкласс). В этом случае граф обобщений представляется в виде иерархического дерева, в котором различают прямые и непрямые потомки. Цикличность в графе не допускается. UML, в принципе, допускает и множественное обобщение (несколько предков), т.е. множественное наследование.
Отношение реализации (реализация, realization) возникает между классами в том случае, когда один класс задает требования к поведению системы (функциональную спецификацию), а другой является полной или частичной программной или аппаратной реализацией этого поведения. Примерами классов, задающих спецификации поведения, являются варианты использования. Кроме того, в UML определены специальные классы - интерфейсы, предназначенные для отдельного перечисления множества видимых операций одного или совокупности других классов без указания деталей реализации. Поскольку одна и та же спецификация может быть реализована многими способами, а реализация может относиться к нескольким спецификациям, то множественность этой связи М:N («многие ко многим»). Тот, кто реализует, называется клиентом, а носитель спецификации называется источником (поставщиком). Клиент не наследует операции источника, он их определяет вновь или наследует от своего предка, однако для полноты должны быть объявлены все операции источника. Отношение реализации изображается пунктирной стрелкой с незакрашенным треугольным наконечником, идущей от реализации к спецификации (от клиента к поставщику). В реализацию могут быть добавлены дополнительные операции (по сравнению со спецификацией), если они способствуют выполнению основных операций.
Классы по своей роли в системе делятся на группы. Сам по себе язык UML жестко не оговаривает эти группы, оставляя группировку на усмотре-
ние разработчиков. На основе опыта, накопленного при создании автоматизированных систем [ 1 ], целесообразно выделить следующие группы (категории, стереотипы) классов:
1) граничные (boundary) классы: объекты этих классов реализуют интерфейсы системы с внешней средой и различными пользователями (не следует их путать с внутренними интерфейсами взаимодействия классов, упоминавшихся ранее);
2) сущностные (entity) классы: объекты этих классов представляют собой блоки длительно хранимой информации, используемые для организации баз данных и знаний, файловых систем хранения данных различной логической структуры; в основном в этих классах развит атрибутный раздел, однако имеется небольшое число операций контроля ограничений целостности, как стандартных, так и специфичных для данной предметной области;
3) классы управления (control): объекты этих классов являются активными, берущими на себя управление и организацию вычислительных процессов; чаще всего это стандартные компоненты операционных систем и систем управления базами данных (СУБД), таймеры, координаторы и т.п.;
4) классы прикладной логики (logic): объекты этих классов реализуют основную логику решения задач приложения; обычно это отдельные программные или аппаратные модули, осуществляющие сложные расчеты, решение оптимизационных задач и т.п.
Для группировок элементов и диаграмм в UML используется механизм пакетов. Пакет (package) – это контейнер с именем, в котором могут содержаться элементы, диаграммы или другие пакеты, обладающие какой-либо степенью общности, определяемой разработчиком системы. Пакет задаёт пространство имён, выделяющих содержащиеся в пакете сущности из общего множества. Особыми видами пакетов являются модель, подсистема и система.
Система (стереотип «system») – это корневая подсистема в иерархии пакетов. Она является единственной сущностью, которая не может содержаться в других пакетах. В пакете система содержатся все остальные подсистемы и модели.
Подсистема (стереотип «subsystem») – это часть системы, которая может быть выделена разработчиком по тому или иному признаку (обычно функциональному или территориальному). Представляется отдельным пакетом. У подсистемы есть собственная спецификация и программная реализация. Разбиение на подсистемы производится для сложных систем, реализация которых основана на использовании большого количества классов. Практически все подсистемы любого уровня детализации взаимозависимы. Количество уровней иерархии в декомпозиции подсистем на подсистемы языком UML не ограничивается.
Модель (стереотип «model») – некоторое абстрактное представление
системы, использующее ту или иную точку зрения разработчика (определённые свойства системы). Моделей может быть множество, они могут быть взаимозависимы, а также вкладываться друг в друга. Каждая модель представляется отдельным пакетом. Все они содержатся в пакете система, могут также содержаться в пакетах подсистема и модель более высокого уровня.
Между пакетами могут существовать отношения зависимости и обобщения. Чтобы возникло отношение зависимости, достаточно, чтобы хотя бы один элемент внутри пакета зависел от какого-либо элемента внутри другого пакета, например, вызывал его операции или использовал его каким-либо другим способом.
Перед именем элемента, например, класса, может ставиться имя пакета. Оно отделяется двойным двоеточием. Пример: displayWindow: WindowingSystem:: GraphicWindows:: Window (указаны два пакета перед именем класса Window, причем пакет GraphicWindows входит в состав пакета Window). Так отображается иерархия пакетов.
Пакет изображается в виде большого прямоугольника, к левому углу которого прикреплён другой прямоугольник вида «закладки» (подобно изображению папки в операционной системе Windows). Если содержимое пакета не раскрывается, то внутри большого прямоугольника ставится имя пакета. Иначе имя пакета помещается в закладку. Над именем пакета может располагаться строка стереотипа в угловых кавычках. Пример диаграммы пакетов представлен на рисунке 8.
Рисунок 8 – Пример диаграммы пакетов
На рисунке изображена в виде пакета со стереотипом «подсистема» часть системы, формирующая отчёты по продажам по запросам пользователей. Этот пакет содержит несколько пакетов, связанных отношением зависимости (пунктирная стрелка) с внешними пакетами.
Дата добавления: 2016-01-05; просмотров: 16; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!