Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Unified Modeling Language.doc
Скачиваний:
0
Добавлен:
01.04.2025
Размер:
2.55 Mб
Скачать

2.4. Диаграмма классов (Class Diagram)

Элементы диаграммы классов

Диаграмма классов (class diagram) — диаграмма, на которой представлена совокупность декларативных или статических элементов модели, таких как классы с атрибутами и операциями, а также связывающие их отношения.

На диаграмме классов не указывается информация о временных аспектах функционирования системы.

Классы

Класс (class) — абстрактное описание множества однородных объектов, имеющих одинаковые атрибуты, операции и отношения с объектами других классов.

Графически класс изображается в виде прямоугольника, который дополнительно может быть разделен горизонтальными линиями на разделы или секции (рис. 2.17). В этих секциях могут указываться имя класса, атрибуты, операции класса, дополнительная информация.

Рис. 2.18. Варианты графического изображения класса на диаграмме классов

На начальных этапах разработки диаграммы классы могут обозначаться простым прямоугольником, в котором должно быть указано имя соответствующего класса. По мере проработки отдельных компонентов диаграммы описание классов дополняется атрибутами, операциями и дополнительной информацией. Предполагается, что окончательный вариант диаграммы содержит наиболее полное описание классов.

Даже если секции атрибутов и операций пусты, в обозначении класса они должны быть выделены горизонтальной линией. Примеры графического изображения конкретных классов приведены на рис. 2.18. В первом случае для класса Окружность (рис. 2.18, а) указаны только его атрибуты. Для класса Окно (рис. 2.18, б) указаны только его операции. Для класса Счет (рис. 2.18, в) дополнительно изображена четвертая секция, в которой указано требование – реализовать резервное копирование объектов этого класса.

Рис. 2.19. Примеры графического изображения конкретных классов

Класс может иметь или не иметь экземпляров или объектов. В зависимости от этого в языке UML различают конкретные и абстрактные классы:

  • Конкретный класс (concrete class) — класс, на основе которого могут быть непосредственно созданы экземпляры или объекты.

  • Абстрактный класс (abstract class) — класс, который не имеет экземпляров или объектов. В языке UML принято общее соглашение о том, что любой текст, относящийся к абстрактному элементу, записывается курсивом.

Имя класса

Имя класса:

  • должно быть уникальным в пределах пакета, который может содержать одну или несколько диаграмм классов.

  • указывается в самой верхней секции прямоугольника – секции имени.

  • записывается по центру полужирным шрифтом и должно начинаться с заглавной буквы.

  • Имя абстрактного класса записывается наклонным шрифтом (курсивом).

  • Рекомендуется в качестве имен классов использовать существительные, записанные по практическим соображениям без пробелов.

  • можно явно указать, к какому пакету относится тот или иной класс. Синтаксис строки имени класса в этом случае будет следующий: <Имя пакета>::<Имя класса>. Например, Банк::Счет.

В секции имени класса могут также находиться:

  • стереотипы или ссылки на стандартные шаблоны, от которых образован данный класс и, соответственно, от которых он наследует атрибуты и операции;

  • информация о разработчике данного класса;

  • статус состояния разработки;

  • другие общие свойства этого класса, имеющие отношение к другим классам диаграммы или стандартным элементам языка UML.

Атрибуты класса

Атрибут (attribute) — содержательная характеристика класса, описывающая множество значений, которые могут принимать отдельные объекты этого класса.

Атрибут класса служит для представления отдельного свойства или признака, который является общим для всех объектов данного класса.

Атрибуты класса записываются во второй сверху секции прямоугольника класса. Эту секцию называют секцией атрибутов.

Каждому атрибуту класса соответствует отдельная строка текста, имеющая определенный формат.

Общий формат записи атрибута класса имеет вид:

<видимость> <имя атрибута> [кратность] :

<тип атрибута> = <начальное значение> {характеристики}

Единственным обязательным элементом является <имя атрибута>.

Видимость (visibility) — качественная характеристика описания элементов класса, характеризующая потенциальную возможность других объектов модели оказывать влияние на отдельные аспекты поведения данного класса.

Уровни видимости:

+

public

общедоступный – элемент доступен или виден из любого другого класса пакета, в котором определена диаграмма.

#

protected

защищенный – элемент недоступен или невиден для всех классов, за исключением подклассов данного класса.

private

закрытый – элемент недоступен или невиден для всех классов без исключения.

~

package

пакетный – элемент недоступен или невиден для всех классов за пределами пакета, в котором определен класс-владелец данного атрибута.

Часть <видимость> может быть опущена.

Вместо условных графических обозначений можно записывать соответствующее ключевое слово: public, protected, private, package.

Имя атрибута – идентификатор соответствующего атрибута.

  • должно быть уникальным в пределах данного класса.

  • является обязательным элементом.

  • должно начинаться со строчной буквы и не должно содержать пробелов.

Кратность (multiplicity) — спецификация области значений допустимой мощности, которой могут обладать соответствующие множества.

Кратность характеризует общее количество конкретных атрибутов данного типа, входящих в состав отдельного класса.

В общем случае кратность записывается в виде:

[нижняя граница .. верхняя граница],

где нижняя граница и верхняя граница – положительные целые числа.

В качестве значения верхняя граница может быть указан символ "*", который означает произвольное положительное целое число, т.е. неограниченное сверху значение кратности соответствующего атрибута.

Интервалов кратности для отдельного атрибута может быть несколько.

Соответствующие нижние и верхние границы интервалов включаются в значение кратности.

Если в качестве кратности указывается единственное число, то кратность атрибута принимается равной данному числу.

Если в качестве значения кратности указывается единственный символ "*", то это означает, что кратность атрибута может быть произвольным положительным целым числом или нулем.

Если кратность атрибута не указана, то по умолчанию в языке UML принимается ее значение равное [1..1], т. е. в точности 1.

Тип атрибута представляет собой выражение, семантика которого определяется некоторым типом данных, определенным в пакете Типы данных языка UML или самим разработчиком.

Тип атрибута иногда определяется в зависимости от языка программирования, который предполагается использовать для реализации данной модели.

Начальное значение служит для задания значения соответствующего атрибута в момент создания отдельного экземпляра класса.

Необходимо придерживаться правила принадлежности значения типу конкретного атрибута.

Если начальное значение не указано, то значение соответствующего атрибута не определено на момент создания нового экземпляра класса.

Конструктор объекта при необходимости может переопределять начальное значение в процессе выполнения программы.

При задании атрибутов могут быть использованы дополнительные синтаксические конструкции:

  • подчеркивание строки атрибута – означает, что соответствующий атрибут общий для всех объектов данного класса, т.е. его значение у всех создаваемых объектов одинаковое (аналогично ключевому слову static в некоторых языках программирования).

  • пояснительный текст в фигурных скобках {характеристики} – может означать две различные конструкции:

    • если в этой строке имеется знак равенства, то вся запись {характеристики} служит для указания дополнительных свойств атрибута, которые могут характеризовать особенности изменения значений атрибута в ходе выполнения программы. Фигурные скобки обозначают фиксированное значение соответствующего атрибута для класса в целом, которое должны принимать все вновь создаваемые экземпляры класса без исключения. Это значение принимается за начальное значение атрибута, которое не может быть переопределено в последующем.

    • отсутствие части {характеристики} по умолчанию трактуется так, что значение соответствующего атрибута может быть изменено в программе.

  • символ «/» перед именем атрибута указывает на то, что данный атрибут является производным от некоторого другого атрибута этого же класса.

Производный атрибут (derived element) — атрибут класса, значение которого для отдельных объектов может быть вычислено посредством значений других атрибутов этого же объекта.

Операции класса

Операция (operation) – это сервис, предоставляемый каждым экземпляром или объектом класса по требованию клиентов, в качестве которых могут выступать другие объекты, в том числе и экземпляры данного класса.

Операции класса записываются в третьей сверху секции прямоугольника класса – секции операций.

Совокупность операций характеризует функциональный аспект поведения всех объектов данного класса.

Каждой операции класса соответствует отдельная строка, которая имеет фиксированный синтаксис.

Общий формат записи операции класса имеет вид:

<видимость> <имя операции>(список параметров) :

<тип_возвращаемого_значения> {характеристики}

Видимость, как и в случае атрибутов класса, может принимать одно из четырех возможных значений (public, protected, private, package) и, соответственно, отображается при помощи специального символа либо ключевого слова.

Значение видимости для операции может быть опущено.

Имя операции – строка текста, используемая в качестве идентификатора соответствующей операции.

  • должно быть уникальным в пределах данного класса.

  • является обязательным элементом синтаксического обозначения операции.

  • должно начинаться со строчной (малой) буквы, и, как правило, записываться без пробелов.

Тип возвращаемого значения является необязательным. Типы параметров записываются с заглавной (большой) буквы.

Характеристики – данная часть описания операции служит для указания значений свойств, которые могут быть применены к данной операции. Она может отсутствовать, если свойства не специфицированы.

Список параметров представляет собой перечень разделенных запятой формальных параметров, каждый из которых, в свою очередь, может быть представлен в следующем виде:

<направление параметра> <имя параметра> :

<тип параметра> = <значение параметра по умолчанию>

Список параметров может быть пустым, в этом случае наличие пустых скобок все равно обязательно.

Параметр (parameter) – спецификация переменной операции, которая может быть изменена, передана или возвращена.

<направление параметра> – одно из ключевых слов in, out или inout. Если вид параметра не указывается, то по умолчанию предполагается значение in.

<имя параметра> – идентификатор соответствующего формального параметра.

<тип параметра> является спецификацией типа данных для допустимых значений соответствующего формального параметра. Если операция не возвращает никакого значения, то часть :<тип параметра> может быть опущена.

<значение по умолчанию> – конкретное значение для этого формального параметра.

Операция, определяемая для всех объектов этого класса, показывается подчеркиванием всей строки записи операции.

Обязательной частью строки записи операции является наличие имени операции и круглых скобок.

Пример описания класса на языке программирования Java приведен ниже.

class Account

{

private float balance=0;

public float limit;

protected int id;

int databaseId;

public void deposit(float amount){...}

private void withdraw(float amount) {...}

protected int getId(){...}

int getDatabaseId(){...}

}

Расширение языка UML для построения моделей ПО и бизнес-систем

UML имеет механизмы расширения, которые позволяют ввести в рассмотрение дополнительные графические обозначения, ориентированные для решения задач из определенной предметной области.

Язык UML содержит два специальных расширения:

  • профиль для процесса разработки программного обеспечения (The UML Profile for Software Development Processes);

  • профиль для бизнес-моделирования (The UML Profile for Business Modelling).

В рамках первого профиля предложено три специальных графических примитива, которые могут быть использованы для уточнения семантики отдельных классов при построении различных диаграмм:

  • Управляющий класс (control class) — класс, отвечающий за координацию действий других классов. На каждой диаграмме классов должен быть хотя бы один управляющий класс, контролирующий последовательность выполнения действий. Данный класс является активным и инициирует рассылку множества сообщений другим классам модели. (рис. 2.19, а).

  • Класс-сущность (entity class) — пассивный класс, содержащий информацию, которая должна храниться постоянно и не уничтожается с уничтожением объектов данного класса или прекращением работы моделируемой системы, связанные с выключением системы или завершением программы. Как правило, этот класс соответствует отдельной таблице базы данных. В этом случае его атрибуты являются полями таблицы, а операции – присоединенными или хранимыми процедурами. Этот класс лишь принимает сообщения от других классов модели. (рис. 2.19, б).

  • Граничный класс (boundary class) — класс, который располагается на границе системы с внешней средой и непосредственно взаимодействует с актерами, но является составной частью системы. (рис. 2.19, в).

Рис. 2.20. Изображение классов для моделирования программного обеспечения

В рамках второго профиля предложено три специальных графических примитива, которые могут быть использованы для уточнения семантики отдельных классов при построении моделей бизнес-систем:

  • Сотрудник (business worker) — класс, служащий на диаграмме классов для представления любого сотрудника, который является элементом бизнес-системы и взаимодействует с другими сотрудниками при реализации бизнес-процесса. (рис. 2.20, а).

  • Сотрудник для связи с окружением (caseworker) – класс, служащий для представления в бизнес-системе такого сотрудника, который, являясь элементом бизнес-системы, непосредственно взаимодействует с актерами (бизнес-актерами) при реализации бизнес-процесса. (рис. 2.20, б).

  • Бизнес-сущность (business entity) — специальный случай класса-сущности, который также не инициирует никаких сообщений. Этот класс служит для сохранения информации о результатах выполнения бизнес-процесса в моделируемой бизнес-системе или организации. (рис. 2.20, в).

Рис. 2.21. Графическое изображение классов для моделирования бизнес-систем

Интерфейс

Интерфейс (interface) — именованное множество операций, которые характеризуют поведение отдельного элемента модели.

  • Является специальным случаем класса, у которого имеются операции, но отсутствуют атрибуты.

  • Графически изображается в виде окружности или прямоугольника класса со стереотипом <<interface>> (рис. 2.21).

Имя интерфейса, как и имена других классов, рекомендуется записывать на английском и начинать с заглавной буквы I, например, ITemperatureSensor, IsecureInformation (рис. 2.21, в).

Рис. 2.22. Примеры изображения интерфейсов на диаграммах классов

  • на диаграмме служит для спецификации таких элементов модели, которые видимы извне, но их внутренняя структура остается скрытой от клиентов.

  • не может содержать ни атрибутов, ни состояний, ни направленных ассоциаций. Он содержит только операции без указания особенностей их реализации.

  • Формально не только отделяет спецификацию операций системы от их реализации, но и определяет общие границы проектируемой системы.

  • может быть уточнен явным указанием тех операций, которые специфицируют отдельный аспект поведения системы. Графическое изображение интерфейсов в форме окружности могут использоваться и на других типах канонических диаграмм.

Отношения на диаграмме классов

Базовые отношения, изображаемые на диаграммах классов:

  • Отношение ассоциации (association relationship);

  • Отношение обобщения (generalization relationship);

  • Отношение зависимости (dependency relationship);

  • Отношение реализации (realization relationship);

  • Отношение агрегации (aggregation relationship);

  • Отношение композиции (composition relationship).

Отношение ассоциации

Ассоциация (association) – произвольное семантическое отношение (взаимосвязь) между двумя и более классами.

Данное отношение обозначается сплошной линией со стрелкой или без нее и может содержать необязательные дополнительные символы:

  • имя ассоциации;

  • символ навигации;

  • имена и кратность классов-ролей ассоциации.

Если задано имя ассоциации, то оно записывается с заглавной буквы рядом с линией ассоциации. Отдельные классы ассоциации могут играть определенную роль в соответствующем отношении, на что явно указывает имя концевых точек ассоциации на диаграмме.

Бинарная ассоциация (binary association) служит для представления произвольного отношения между двумя классами.

Бинарная ассоциация может быть:

  • ненаправленная (симметричная) – изображается линией без стрелки. Для нее на диаграмме может быть указан порядок чтения классов с использованием значка в форме треугольника рядом с именем данной ассоциации (рис. 2.22).

  • направленная – изображается сплошной линией с простой стрелкой на одной из ее концевых точек. Направление этой стрелки указывает на то, какой класс является первым, а какой – вторым (рис. 2.23). Эти объекты классов образуют кортеж элементов, например, <клиент, счет_1, счет_2,…, счет_n>.

Рис. 2.23. Ненаправленная бинарная ассоциация между классами

Рис. 2.24. Направленная бинарная ассоциация между классами

Фрагменты программного кода на языке Java для ненаправленной и направленной ассоциаций приведены ниже.

Ненаправленная ассоциация

Направленная ассоциация

House.java:

public class House {

public Person m_Person;

House(){

}

}

Person.java:

public class Person {

public House m_House;

Person(){

}

}

House.java:

public class House {

House(){

}

}

Person.java:

public class Person {

public House m_House;

Person(){

}

}

Рефлексивная ассоциациячастный случай бинарной, связывает класс с самим собой.

Исключающая ассоциация (XOR-association) – частный случай ассоциации. Семантика данной ассоциации указывает на то, что из нескольких потенциально возможных вариантов данной ассоциации в каждый момент времени может использоваться только один. На диаграмме изображается пунктирной линией, соединяющей две и более ассоциации (рис. 2.24), рядом с которой записывается ограничение {XOR}.

Рис. 2.25. Исключающая ассоциация между тремя классами

n-арная ассоциация (n-ary association) – ассоциация между тремя и большим числом классов. Графически обозначается ромбом, от которого ведут сплошные линии к символам классов данной ассоциации.

Каждый экземпляр n-арной ассоциации представляет собой упорядоченный набор (кортеж), содержащий n экземпляров из соответствующих классов. Имя ассоциации записывается рядом с ромбом.

Пример тернарной ассоциации представлен на рис. 2.25. Отношения между этими тремя классами, может представлять информацию о проектах, реализуемых в компании, и о сотрудниках, участвующих в выполнении отдельных проектов.

Рис. 2.26. Изображение тернарной ассоциации между тремя классами

Ассоциация класс (association class) – элемент, который одновременно является ассоциацией и классом. Он может рассматриваться как ассоциация, которая обладает свойствами класса, или как класс, имеющий также свойства ассоциации.

На диаграмме такой класс присоединяется к линии ассоциации пунктирной линией. Это означает, что данный класс обеспечивает поддержку свойств соответствующей n-арной ассоциации, а сама n-арная ассоциация имеет атрибуты, операции и/или ассоциации.

Отдельный класс в ассоциации может играть определенную роль в данной ассоциации. Эта роль может быть явно специфицирована на диаграмме классов.

Конец ассоциации (association end) – концевая точка ассоциации, которая связывает ассоциацию с классификатором, графически соответствует точке соединения линии ассоциации с отдельным классом.

Конец ассоциации – часть ассоциации, но не класса. Каждая ассоциация может иметь два или больше концов ассоциации.

Роль (role) – имеющее имя специфическое поведение некоторой сущности, рассматриваемой в определенном контексте. Роль может быть статической или динамической.

Имя роли может дополнительно указываться рядом с концом ассоциации для соответствующего класса. Она указывает на специфическую роль, которую играет класс, являющийся концом рассматриваемой ассоциации.

Кратность ассоциации

Кратность ассоциации относится к концам ассоциации и обозначается в виде интервала целых чисел, аналогично кратности атрибутов и операций классов, но без прямых скобок. Этот интервал записывается рядом с концом соответствующей ассоциации и означает потенциальное число отдельных экземпляров класса, которые могут иметь место, когда остальные экземпляры или объекты классов фиксированы.

Так, для примера, приведенного на рис. 2.25 кратность "1" для класса Компания означает, что каждый сотрудник может работать только в одной компании. Кратность "1..*" для класса Сотрудник означает, что в каждой компании могут работать несколько сотрудников, общее число которых заранее неизвестно и ничем не ограничено, но не менее 1.

Имя ассоциации рассматривается в качестве отдельного атрибута у соответствующих классов ассоциаций и может быть указано на диаграмме явным способом в определенной секции прямоугольника класса.

Ассоциация – наиболее общая форма отношения в языке UML. Все другие типы рассматриваемых отношений можно считать частным случаем данного отношения.

Отношение обобщения

Обобщение (generalization) – отношение между более общим элементом (родителем или предком) и более частным или специальным элементом (дочерним или потомком), образующими иерархию. Применительно к диаграмме классов данное отношение описывает иерархическое строение классов и наследование их свойств и поведения.

Класс-потомок обладает всеми свойствами и поведением класса-предка, а также имеет собственные свойства и поведение, которые могут отсутствовать у класса-предка.

На диаграммах отношение обобщения обозначается сплошной линией с треугольной стрелкой на одном из концов (рис. 2.26). Стрелка указывает на более общий класс (класс-предок или суперкласс).

Рис. 2.27. Графическое изображение отношения обобщения в языке UML

От одного класса-предка одновременно могут наследовать несколько классов-потомков. Например, абстрактный класс Транспортное средство (курсив обозначает абстрактный класс) может выступать в качестве суперкласса для подклассов, соответствующих конкретным транспортным средствам, таким как: Автомобиль, Автобус, Трактор и другим (рис. 2.27 и 2.28).

Рис. 2.28. Пример графического изображения отношения обобщения для нескольких классов-потомков

Рис. 2.29. Альтернативный вариант графического изображения отношения обобщения классов

Для указания специальных свойств, касающиеся всех подклассов отношения, можно использовать следующие ограничения:

  • {complete} – означает, что в данном отношении обобщения специфицированы все классы-потомки, и других классов-потомков у данного класса-предка быть не может.

  • {incomplete} – означает, что на диаграмме указаны не все классы-потомки, которые возможно будут добавлены позже.

  • {disjoint} – означает, что классы-потомки не могут содержать объектов, одновременно являющихся экземплярами двух или более классов.

  • {overlapping} – означает, что отдельные экземпляры классов-потомков могут принадлежать одновременно нескольким классам.

Пример использования ограничений приведен на рис. 2.29.

Рис. 2.30. Вариант уточненного графического изображения отношения обобщения классов с использованием строки-ограничения

Фрагмент программного кода на языке Java для отношения обобщения приведен ниже.

MySuperClass.java:

public class MySuperClass

{...}

MySubClass.java:

public class MySubClass

extends MySuperClass

{...}

Отношение зависимости

Отношение зависимости (dependency) служит для представления факта наличия специальной формы связи между двумя классами, когда изменение одного оказывает влияние или приводит к изменению другого. Обычно операции зависимого класса либо вызывают операции независимого класса, либо имеют сигнатуры, в которых возвращаемое значение или аргументы принадлежат независимому классу.

Отношение зависимости, в отличие от отношения ассоциации, всегда являются направленными.

Зависимость изображается пунктирной линией со стрелкой, направленной от зависимого элемента к независимому элементу (рис. 2.30).

Рис. 2.31. Графическое изображения отношения зависимости

Отношения зависимости могут быть помечены стереотипами, наиболее часто используемые:

  • «use» – класс А использует класс В любым образом. Является значением по умолчанию, если стереотип не указан явно.

  • «call» – операция зависимого класса вызывает операцию независимого.

  • «parameter» – передается параметр или возвращается значение от независимого класса к зависимому

  • «instantiate» – зависимый класс является разновидностью независимого.

  • «friend» – зависимый элемент имеет доступ к ссылкам независимого.

Фрагмент программного кода на языке Java для отношения зависимости приведен ниже.

Person.java:

public class Person {

public void BuyHouse(House theHouse) {...}

}

House.java:

public class House

{...}

Отношение реализации (realization relationship)

Реализация (realization) – семантическое отношение между классами, в котором один класс (приемник) должен реализовать поведение, определенное в другом (источник).

Реализация изображается пунктирной линией со стрелкой, имеющей полый наконечник, направленной от приемника к источнику (рис. 2.31).

Рис. 2.32. Графическое изображения отношения реализации

Фрагмент программного кода на языке Java для отношения реализации приведен ниже.

MyInterface.java:

public interface MyInterface {

public void charge(int x);

...}

AbstractClassF.java:

public class AbstractClassF

implements MyInterface {

public void charge(int x) {

...};

}

Отношение агрегации

Агрегация (aggregation) – специальная форма ассоциации, которая служит для представления отношения типа "часть-целое" между агрегатом (целое) и его составной частью.

Отношение агрегации имеет место между несколькими классами в том случае, если один из классов представляет собой сущность, которая включает в себя в качестве составных частей другие сущности.

Отличие от отношения обобщения заключается в том, что части системы никак не обязаны наследовать ее свойства и поведение, поскольку являются самостоятельными сущностями.

Графически отношение агрегации изображается сплошной линией, один из концов которой представляет собой не закрашенный внутри ромб. Этот ромб указывает на тот класс, который представляет собой "целое" или класс-контейнер (рис. 2.32).

Рис. 2.33. Графическое изображение отношения агрегации в языке UML

Пример отношения агрегации приведен на рис. 2.33.

Рис. 2.34. Диаграмма классов для иллюстрации отношения агрегации на примере системного блока ПК

Отношение композиции

Композиция (composition) – разновидность отношения агрегации, при которой составные части целого имеют такое же время жизни, что и само целое.

Это отношение служит для спецификации более сильной формы отношения "часть-целое", при которой составляющие части тесно взаимосвязаны с целым. Особенность этой взаимосвязи заключается в том, что части не могут выступать в отрыве от целого, т.е. с уничтожением целого уничтожаются и все его составные части.

Композит (composite) – класс, который связан отношением композиции с одним или большим числом классов.

Графически отношение композиции изображается сплошной линией, один из концов которой представляет собой закрашенный внутри ромб. Этот ромб указывает на тот класс, который представляет собой класс-композит (рис. 2.34).

Рис. 2.35. Графическое изображение отношения композиции в языке UML

Для отношений композиции и агрегации дополнительно можно указывать кратность отдельных классов, которые в общем случае не обязательны. На рис. 2.35. приведен пример использования отношения композиции.

Рис. 2.36. Диаграмма классов для иллюстрации отношения композиции на примере класса-композита Окно программы

Рекомендации по построению диаграмм классов

При определении ассоциаций необходимо сосредотачиваться на тех, для которых данные о связи должны сохраняться в течение некоторого времени (важные ассоциации), хотя иногда необходимо учесть и второстепенные.

Необходимо избегать использования избыточных ассоциаций.

Диаграмма классов должна содержать все без исключения классы, их атрибуты и операции, а также все ассоциации и другие структурные отношения между элементами модели.

Применение инструментальных средств для реализации модели в абсолютном большинстве случаев требует использования англоязычных терминов.

После разработки диаграммы классов процесс ООАП может быть продолжен в двух направлениях:

  • если поведение системы тривиально, то можно приступить к разработке диаграмм кооперации и последовательности.

  • для сложных динамических систем, например, для параллельных систем и систем реального времени, важнейшим аспектом их функционирования является поведение. Специфика поведения таких систем может быть представлена на диаграммах состояний и деятельности, разработка которых в общем случае не обязательна, а определяется конкретным проектом.

Контрольные вопросы

  1. Для представления какой информации предназначена диаграмма классов?

  2. Что такое класс? Из каких секций состоит графическое представление класса?

  3. Какой класс называется абстрактным?

  4. Какая информация может располагаться в секции имени класса?

  5. Что такое атрибут класса?

  6. Какой формат имеет запись атрибута класса?

  7. Какие уровни видимости определены в UML? Дайте определение каждому из них.

  8. Что такое кратность?

  9. Что такое операция класса?

  10. Какой формат имеет запись операции класса?

  11. Что такое интерфейс?

  12. Какие отношения могут быть использованы на диаграммах классов? Приведите примеры отношений между классами.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]