17

Лабораторная работа №3

«Создание логического представления проектируемой системы. Диаграммы классов. Диаграммы состояний и деятельности»

Цели работы:

9.Научиться работать с логическим представлением системы при помощи CASE-

средства Rational Rose.

10.Изучить основные сведения о диаграммах классов UML.

11.Выполнить следующий этап учебного проекта.

Краткие теоретические сведения:

7.Элементы нотации UML для создания диаграмм классов

a.Механизм пакетов. Диаграмма пакетов – форма диаграммы классов

Вцелом механизм пакетов (Packages) применим к любым элементам модели UML. В отношении классов пакеты применяются для того, чтобы сгруппировать классы, обладающие определённой общностью. Наиболее распространённые подходы к группировке:

– по стереотипу – такой подход полезен с точки зрения размещения компонентов системы, в этом случае выделяют пакеты с классами-сущностями (Entities), граничными классами (Boundaries) и управляющими классами (Controls);

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

Диаграмма пакетов в UML (рис.1) представляет собой диаграмму, содержащую пакеты классов и зависимости между ними.

18

Рис. 1. Пример диаграммы пакетов

b. Общие сведения о диаграммах классов

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

Диаграмма классов определяет типы классов системы, а также различного рода связи, существующие между ними.

Графическое изображение класса в UML показано на рис.2.

NewClass

attr1 attr2

op1()

op2()

op3()

Рис. 2. Пример изображения класса NewClass с атрибутами attr1, attr2 и операциями op1, op2

На диаграмме UML класс отображается в виде прямоугольника. Имя класса – текстовая строка. Имя абстрактного класса выделяется курсивом. В составном имени класса может присутствовать имя пакета, в который он входит (PackageName :: ClassName).

c. Атрибуты

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

Общий формат описания атрибута в UML следующий.

19

ExportControl Name : Type = InitialValue

Свойства атрибутов в Rational Rose устанавливаются в спецификации (Specification) атрибута. Видимость атрибута (в Rational Rose – Export Control) может принимать четыре значения:

–public – атрибут виден и может быть изменён всеми остальными классами (в Rational Rose этот параметр отображается в виде голубого прямоугольника перед именем атрибута, а вообще в UML знаком «+»);

–protected – доступен только самому классу и его потомкам (в Rational Rose – ключ возле прямоугольника, в UML – знак «#»);

–private – не виден другим классам (в Rational Rose – замок перед прямоугольни-

ком, в UML – знак «–»);

–implementation – является общим в пределах пакета (в Rational Rose – винтик перед прямоугольником).

Некоторые свойства в описании атрибута могут отсутствовать.

d.Операции

Операции реализуют связанное с классом поведение, иными словами, это абстракция того, что позволено делать с объектом. Формат описания операции:

ExportControl Name (Argument1 : Type = InitialValue, Argument2: Type = InitialValue): Type

Можно выделить четыре типа операций:

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

–операции управления – управляют созданием и уничтожением объектов (конструкторы и деструкторы);

–операции доступа – так называемые getter’s и setter’s;

–вспомогательные операции – закрытые и защищённые операции класса.

Таким образом, общие принципы добавления операций:

1.Большая часть сообщений на диаграммах взаимодействия – это операции реализации.

2.Рефлексивные сообщения на диаграммах взаимодействия – вспомогательные.

3.Управляющие операции – конструкторы и деструкторы добавляются там, где это необходимо.

4.Для каждого атрибута класса, с которым будут работать объекты других классов, надо создать операции get и set.

e.Связи

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

–ассоциации;

–зависимости;

–агрегации;

–обобщения.

20

1.5.1. Ассоциации

Ассоциация (Association) – это семантическая связь между классами. На диаграмме классов ассоциация представляется следующим образом (рис. 3).

Рис. 3. Изображение ассоциации

Ассоциации могут быть однонаправленными (без стрелок) или однонаправленными – Navigable (стрелка с одной стороны). Направление ассоциации определяется по диаграмме взаимодействия – если сообщения на диаграмме отправляются только одним классом, а принимаются только другим – имеет место однонаправленная ассоциация, в противном случае – двунаправленная.

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

1.5.2. Зависимости

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

Рис. 4. Пример зависимости

Зависимости описывают существующие между классами отношения использования (включая отношения трассировки, уточнения и связывания).

1.5.3. Агрегации

Агрегация (Aggregation) – представляет собой более тесную форму ассоциации – связь между частью и целым (рис. 5).

Рис. 5. Пример агрегации

В дополнение к простой агрегации в UML вводится более сильная её разновидность – композиция (рис. 6). Согласно композиции, объект-часть может принадлежать только единственному объекту-целому, кроме того, жизненный цикл их как правило совпадает. Любое удаление целого распространяется на его части.

21

Рис. 6. Пример композиции

Подразумевается также, что множественность роли в этом случае 1..1.

1.5.4. Обобщения

Обобщение (Generalization) – есть ни что иное, как связь наследования между двумя классами. Пример обобщения представлен на рис. 7.

Person

Рис. 7. Пример наследования

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

Множественность (Multiplicity) показывает, сколько экземпляров класса взаимодействует с помощью данной связи с одним (или несколькими) экземплярами другого. Индикаторы множественности устанавливаются на обоих концах линии связи (см. табл. 1).

Таблица 1.

Обозначение множественности в UML

Если причина создания связи неочевидна, связь уточняется с помощью имени (рис. 8). Как правило, это глагол или глагольная фраза, описывающая назначение связи.

Рис. 8. Имя связи

Вместо имени связи на диаграмме могут указываться ролевые имена классов (рис. 9) – существительные или основанные на существительных фразы, которые указываются рядом с классом, играющим соответствующую роль.

Company +Employer +Employee Person

Рис. 9. Ролевые имена

Ролевые имена применяются в связях ассоциации или агрегации.

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

22

Диаграммы состояний (State Machine Diagrams) отражают все возможные состояния, в которых может находиться конкретный объект, а также процесс смены состояний объекта в результате наступления некоторых событий.

Пример диаграммы состояний для банковского счёта представлен на рис.10.

Рис. 10. Пример диаграммы состояний

На диаграмме видно, что счёт может находиться в состоянии «Открыт», «Закрыт» и «Заморожен» (Open, Close, Overdraft).

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

Процессы, происходящие с объектом в каком-либо состоянии, называются действиями (Actions). С каждым состоянием связываются данные пяти типов:

–деятельность;

–входное действие;

–выходное действие;

–событие;

–история состояния.

Деятельность – поведение, реализуемое объектом в данном состоянии. Это поведение прерываемо, и может выполняться либо до своего завершения, либо может быть прервано переходом объекта в другое состояние. Изображается внутри состояния, с предшествующим словом do.

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

Выходное действие аналогично выходному, и ему предшествует слово exit.

Если поведение объекта включает отсылку сообщения, описанию деятельности предшествует значок «^».

23

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

–события;

–аргументы;

–ограждающие условия;

–действия;

–посылаемые события.

Событие (Event) – это то, что вызывает переход. На диаграмме событие размещается вдоль линии перехода. Кроме того, у события могут быть аргументы (Arguments). Для отображения события можно использовать как имя операции, так и обычную фразу.

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

Ограждающие условия (Guard Conditions) определяют возможность перехода. На диаграмме размещаются вдоль линии перехода после события в квадратных скобках. Ограждающие условия необязательны, однако, если существует несколько автоматических переходов из состояния, необходимо определить взаимоисключающие ограждающие условия.

При переходе также может указываться действие – вдоль линии перехода, после значка «/». Если действие представляет собой событие, посылаемое другому объекту, на диаграмме ему предшествует значок «^».

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

Практическая часть:

4. Определение обязанностей, атрибутов и ассоциаций классов

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

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

Связи между классами (ассоциации) определяются на основе диаграмм взаимодействия: Если два объекта взаимодействуют (обмениваются сообщениями), между ними должна существовать связь (путь взаимодействия). Для ассоциаций могут также задаваться множественность и направление навигации. Могут также использоваться агрегации, композиции и т.д. (см. 1.5).

5.Проектирование архитектуры системы

Входе дальнейшего проектирования системы необходимо произвести:

–анализ взаимодействия между классами анализа, выявление подсистем и интер-

фейсов;

–уточнение архитектуры с учётом возможностей повторного использования;

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

Вводятся глобальные пакеты: базисные классы (списки, очереди), обработчики ошибок, математические библиотеки, утилиты и т.п.

24

Определяются проектные классы:

–класс анализа отображается в проектный класс, если он простой и представляет собой единственную логическую абстракцию;

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

2.1. Проектирование подсистем

Примеры возможных подсистем:

1.Классы, обеспечивающие сложный комплекс услуг (например, обеспечение безопасности, защита).

2.Граничные классы, реализующие сложный пользовательский интерфейс или интерфейс с внешними системами.

3.Различные продукты: коммуникационное ПО, доступ к базам данных, общие утилиты (математические библиотеки), и различные другие про-

дукты.

Проектирование интерфейсов для подсистем (основные соглашения):

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

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

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

Класс <<subsystem proxy>> непосредственно реализует интерфейс и управляет реализацией его операций.

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

a. Выделение архитектурных уровней

Можно выделить следующие уровни:

–Application Layer, содержащий элементы прикладного уровня (пользовательский интерфейс);

–Business Layer, содержащий бизнес-логику приложения;

–Middleware Layer, обеспечивающий сервисы, независимые от платформы. b. Проектирование классов

Классы анализа преобразуются в проектные классы при этом:

–проектирование граничных классов зависит от возможностей среды разработки пользовательского интерфейса;

–проектирование классов-сущностей производится с учётом соображений производительности (выделение в отдельные классы атрибутов с различной частотой использования);

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

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

25

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

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

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

Для описания объектов с высоким уровнем динамического поведения создаются диаграммы состояний.

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

ЗАДАНИЕ

1.Выполнить все действия описанные в практической части.

2.Получить диаграмму пакетов.

3.Получить уточнённые диаграммы классов.

4.Построить диаграммы состояний для классов с наиболее сложным поведением.

В отчёте приводятся построенные диаграммы:1. Пакетов, 2. Классов, 3. Состояний.

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

1.Поясните применение пакетов в проектировании систем. Какие основные подходы к распределению классов по пакетов Вы можете назвать?

2.Назовите основные элементы диаграммы классов UML. Каков общий формат описания атрибута? Операции?

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

4.Какие виды связей между классами могут устанавливаться? Поясните смысл каждой и обозначение.

5.Каковы основные элементы диаграмм состояний UML?

6.Какие элементы включает спецификация перехода?