Проектирование информационных систем. Раздел 5. Индустриальное проектирование информационных систем. Объектно-ориентированная Case-технология проектир

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

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

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

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

Рисунок 17 – Графическое представление отношения агрегации на диаграмме классов

В качестве примера отношения агрегации может служить представление персонального компьютера в виде следующих составных частей: системного блока, монитора, клавиатуры, манипулятора типа «мышь». Используя обозначения языка UML, компонентный состав ПК можно представить в видесоответствующейдиаграммы классов, какпоказанонарисунке18.

Рисунок 18 – Отношения агрегации между ПК и его элементами

31

Частным случаем отношения агрегации является отношение композиции. Специфика такого отношения заключается в том, что части не могут выступать в отрыве от целого, т. е. с уничтожением целого уничтожаются и все его составные части. Графически отношение композиции изображается сплошной линией, один из концов которой представляет собой закрашенный внутри ромб (рисунок 19). Этот ромб указывает на тот из классов, который представляет собой класс-композицию или «целое».

Рисунок 19 – Графическое представление отношения композиции на диаграмме классов

Примериспользованияотношениякомпозициипредставленнарисунке20.

Рисунок 20 – Пример использования отношения композиции с указанием кратности

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

32

ся сплошной линией с треугольной стрелкой на одном из концов – от класса-потомка к классу-предку (рисунок 21).

Рисунок 21 – Графическое представление отношения обобщения на диаграмме классов

Например, класс «Автоматизированная информационная система» может служить обобщением для классов, соответствующих конкретным информационных продуктам, таким, как база данных, электронное издание, сайт (рисунок 22).

Автоматизированная информационная система

Рисунок 22 – Пример использования отношения обобщения на диаграмме классов

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

33

2.3. Диаграммы пакетов

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

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

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

Пакетная технология группировки классов объектов позволяет упростить:

•разработку и эксплуатацию ИС;

•гибкую адаптацию типовых компонентов с позиции их повторного использования;

•оптимизацию клиент-серверной архитектуры ИС.

Таким образом, диаграммы пакетов можно считать основным сред-

ством управления общей структурой системы.

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

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

34

ные пакеты. В одном пакете, как правило, определяется не более 20 компонентов (обычно 5–15).

Выделяют 5 основных пакетов:

•«Интерфейс», объекты которого реализуют функции взаимодействия пользователей с ИС по вводу-выводу информации и обмена сообщениями между подсистемами;

•«База данных», объекты которого выполняют доступ к данным во внешней памяти;

•«Управление задачами», объекты которого осуществляют функции диспетчеризации и маршрутизации обработки объектов (например, в системе управления рабочими потоками);

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

•Обеспечивающие пакеты, работающие по принципу «клиентсерверной» архитектуры, выполняющие серверные функции для функциональных объектов-клиентов. Таким образом обеспечивающие пакеты освобождают пользователя от знания деталей программно-технической реализации ИС.

Рисунок 23 – Графическое представление пакета

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

Одним из типов отношений между пакетами является отношение вложенности или включения пакетов друг в друга. В языке UML это отношение может быть изображено размещением одного пакетапрямоугольника внутри другого пакета-прямоугольника (рисунок 24).

35

Рисунок 24 – Графическое представление отношения вложенности пакетов друг в друга на диаграмме пакетов

Диаграммы пакетов способствуют более глубокому пониманию других диаграмм. Диаграммы пакетов получили настоящий статус лишь в UML 2. 0.

36

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

1.Поясните назначение статических моделей в объектно-ориентированном подходеприпроектированииинформационныхсистем.

2.Для чего применяются диаграммы прецедентов использования?

3.Какие группы актеров выделяют в диаграммах прецедентов использования?

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

5.Приведите примеры абстрактных прецедентов использования.

6.Какие типы отношений бывают в диаграммах прецедентов использования?

7.Чем отличаются друг от друга отношения включения и расширения с точки зрения управления?

8.Приведите примеры использования отношения расширения между прецедентами использования.

9.Какие секции входят в графическое обозначение класса?

10.Какой элемент обозначения класса является обязательным?

11.Сформулируйте рекомендации при использовании имен классов.

12.Что такое абстрактный класс и как он отображается?

13.Поясните общий синтаксис представления атрибута класса.

14.Приведите примеры переменных атрибутов класса «Человек».

15.Что такое квантор видимости атрибута и какие значения он может принимать?

16.Поясните общий синтаксис представления операции.

17.Приведите примеры операций для класса «Файл».

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

19.Приведите примеры бинарной однонаправленной ассоциации между двумя классами.

20.Охарактеризуйте направленность отношения зависимости?

21.Чем отличается агрегация от композиции?

22.Приведите примеры использования отношения композиции.

23.Какой смысл в UML имеет отношение обобщения?

24.Определите основные понятия и конструктивные элементы диаграммы пакетов.

25.Зачем создаются диаграммы пакетов?

37

Глава 3. ДИНАМИЧЕСКИЕ МОДЕЛИ ОБЪЕКТНООРИЕНТИРОВАННЫХ ИНФОРМАЦИОННЫХ СИСТЕМ

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

3. 1. Диаграммы состояний

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

•какие типичные состояния проходит объект;

•какие события ведут к изменению состояния объекта;

•какие действия объект выполняет, когда он получает сообщение об изменении состояния;

•как объекты создаются и уничтожаются (входные и выходные состояния диаграммы).

Следует отметить, что по своему назначению диаграмма состояний не должна быть обязательно представлена в модели.

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

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

Состояние на диаграмме изображается прямоугольником со скругленными вершинами. Этот прямоугольник может быть разделен на две части горизонтальной линией. Если указана лишь одна часть, то в ней записывается только имя состояния. В противном случае в первой из них записывается имя состояния, а во второй – список внутренних действий (рисунок 25). Имя состояния всегда записывается с заглавной буквы. В качестве имени рекомендуется использовать глаголы в настоящем времени или соответствующие причастия (занят, свободен, передано, получено).

38

Рисунок 25 – Графическое изображение состояния на диаграмме состояний

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

<метка действия> / <выражение действия> Метка действия указывает на условия, при которых будет выпол-

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

•entry – указывает на действие, которое выполняется в момент входа в данное состояние (входное действие);

•exit – указывает на действие, которое выполняется в момент выхода из данного состояния (выходное действие);

•do – указывает на деятельность, которая выполняется в течение всего времени, пока объект находится в данном состоянии.

Начальное состояние представляет собой частный случай состояния, которое не содержит никаких внутренних действий. В этом состоянии находится объект по умолчанию в начальный момент времени. Графически начальное состояние в языке UML обозначается в виде залитой окружности, как показано на рисунке 26. В начальное состояние нельзя перейти из любого другого состояния объекта.

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

39

Рисунок 26 – Графическое изображение начального и конечного состояний

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

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

Переход состояний описывается следующими атрибутами: назначение, вызов, условие перехода, действие.

Назначение – состояние объекта, в которое перейдет объект после перехода состояния.

Вызов – имя события, которое вызывает переход состояний. Вызываемые события могут быть:

1)внешними, осуществляемыми актерами;

2)внутренними, связанными с поведением других объектов;

3)временными, связанными с истечением заданного интервала времени. Условие перехода – это логическое выражение, связанное с атрибу-

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

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

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

40