Федеральное государственное бюджетное образовательное учреждение

высшего профессионального образования

«Пермская государственная сельскохозяйственная академия

имени академика Д.Н. Прянишникова»

ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННЫХ СИСТЕМ

направление 230700 «Прикладная информатика»

Лабораторное занятие № 8

Тема: МОДЕЛЬ ПРОЕКТИРОВАНИЯ: ДИАГРАММЫ КЛАССОВ

Учебные вопросы:

1. Модель проектирования: создание диаграммы классов.

Вопрос 1. Модель проектирования: создание диаграммы классов

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

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

Диаграмма классов, представленная на рис. 1.1, иллюстрирует фрагмент про­граммного решения для классов Register и Sale.

Рисунок 1.1 – Пример диаграммы программных классов

Диаграмма классов (design class diagram) иллюстрирует спецификации про­граммных классов и интерфейсов (например, интерфейсов Java, С# и т.д.) в приложении. Обычно на такую диаграмму выносится следующая информация:

• Классы, ассоциации и атрибуты;

• Интерфейсы со своими операциями и константами;

• Методы;

• Информация о типах атрибутов;

• Способы навигации;

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

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

В RUP не определен отдельный артефакт под названием "диаграмма классов про­ектирования". Там определена лишь модель проектирования, которая может вклю­чать несколько типов диаграмм, в том числе диаграммы классов, взаимодействия и пакетов. Диаграммы классов из модели проектирования RUP иллюстрируют "классы проектирования" в терминах RUP. Поэтому зачастую диаграммы классов из модели проектирования называют просто диаграммами классов проектирования.

Классы из модели предметной области и модели проектирования

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

Рисунок 1.2 – Классы модели предметной области и модели проектирования

Создание диаграммы классов для POS-системы ТТ

Алгоритм построения диаграмм классов

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

Для POS-приложения к числу таких классов относятся следующие:

Register	Sale
ProductCatalog	Product Specification
Store	SalesLineItem
Payment

2. Нанесение этих классов на диаграмму и добав­ление атрибутов, определенных с использованием модели предметной области (рис. 1.3).

Рисунок 1.3 – Программные классы приложения

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

Добавление имен методов

Методы каждого класса можно определить путем анализа диаграмм взаимодей­ствия. Например, если сообщение makeLineItem передается экземпляру класса Sale, то в классе Sale должен быть определен метод makeLineItem (рис. 1.4).

Рисунок 1.4 – Имена методов из диаграмм взаимодействия

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

Изучив все диаграммы взаимодействия для POS-приложения, получим име­на методов, представленные на рис. 1.5.

Рисунок 1.5 – Методы приложения

Выбор имен методов

При выборе имен методов необходимо руководствоваться следующими сооб­ражениями:

1. Интерпретировать сообщение create ( ).

2. Описывать методы доступа.

3. Интерпретировать сообщения сложным объектам.

4. Использовать синтаксис языка программирования.

Имена методов: create

Сообщение create на языке UML представляет собой абстрактную форму ини­циализации или инстанцирования. При переходе к реализации системы на объектно-ориентированном языке программирования процесс передачи сообщения необходимо выразить средствами языка программирования с использованием его идиом для инстанцирования и инициализации. В языке C++, Java или Smalltalk не существует реального метода create. Например, на языке C++ память выделяется с помощью оператора new, после которого следует имя конструктора.

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

Имена методов: методы доступа

Методы доступа (accessing methods) – это методы получения или уста­новки значений атрибутов. В некоторых языках программирования для каждого атрибута принято создавать свои методы получения и установки значений, а сами атрибуты объявлять в закрытой области доступа (для обеспечения инкапсу­ляции). Эти методы обычно не отображаются на диаграмме классов, чтобы не загромождать ее лишней информацией, поскольку при наличии N атрибутов у класса появляется 2N стандартных метода. Например, метод getPrice (или price) класса ProductSpecification не показан на диаграмме классов, по­скольку это простой метод доступа.

Имена методов: сложные объекты

Сообщения сложному объекту интерпретируются как сообщения контейнеру или объекту-коллекции. Например, следующее сообщение find сложному объ­екту можно интерпретировать как сообщение объекту-контейнеру, такому как Map в Java, map в C++ или Dictionary в Smalltalk (рис. 1.6).

Рисунок 1.6 – Сообщение сложному объекту

Таким образом, метод find не является частью класса ProductSpecification, а относится к интерфейсу сложного объекта. Поэтому некорректно добавлять метод find в спецификацию класса ProductSpecification.

Классы или интерфейсы-контейнеры (такие как java.util.Map) – это элемен­ты предопределенной библиотеки, которые не отображаются на диаграмме классов, поскольку они лишь загромождают диаграмму и не несут новой информации.

Имена методов: синтаксис с учетом языка

В некоторых языках, таких как Smalltalk, синтаксическая форма описания ме­тода отличается от базового формата UML вида имяМетода (списокПараметров). На диаграммах классов рекомендуется использовать базовый формат языка UML, даже если планируется реализовывать систему на языке с другим синтаксисом. Пе­реход к синтаксису конкретного языка целесообразно выполнять на этапе генерации кода, а не в процессе создания диаграмм классов. Однако UML допускает примене­ние различных синтаксисов для спецификации методов.

Добавление дополнительной информации о типах

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

Диаграмма классов создается для ее пользователей:

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

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

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

На диаграмме классов, представленной на рис. 1.7, показана дополнительная информация о типах параметров.

Рисунок 1.7 – Добавление информации о типах

Добавление ассоциаций и информации о навигации

Каждый конец линии ассоциации называется ролью (role). На диаграмме классов роль может отмечаться стрелкой (стрелкой навигации), указываю Щей направление связи. Информация о навигации (navigability) – это свойство роли, указывающее возможное направление передачи информации от объекта-источника к целевому классу. Информация о навигации связана с видимостью объектов, обычно – с видимостью, обеспечиваемой посредство» атрибутов (рис. 1.8).

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

Большинство (если не все) ассоциаций на диаграммах классов должно быть снабжено необходимыми стрелками навигации.

Рисунок 1.8 – Информация о навигации или видимости, обеспечиваемой

посредством атрибутов

На диаграммах классов ассоциации выбираются по жесткому программно-ориентированному критерию: отображаются те ассоциации, которые необходимы для удовлетворения требований видимости и памяти, вытекающих из диаграмм взаимодействий. Такой подход отличается от подхода к отображению ассоциа­ций в модели предметной области, где ассоциации отображают зависимости объ­ектов предметной области. Здесь снова проявляются различия между моделями проектирования и предметной области: первая описывает программные компо­ненты, а вторая – результаты анализа предметной области.

Требуемые свойства видимости и ассоциации между классами определяются на основе диаграмм взаимодействия. Вот типичные ситуации, требующие опре­деления ассоциаций с указанием направления связи от объекта А к объекту В:

• Объект А отправляет сообщение объекту В

• Объект А создает экземпляр объекта В

• Объект А должен поддерживать связь с объектом В

Например, из диаграммы взаимодействия, представленной на рис. 1.9, вид­но, что объект Store должен быть связан с создаваемыми им экземплярами объ­ектов Register и ProductCatalog, причем эта связь должна быть направлена от объекта Store. Целесообразно также установить связь объекта ProductCatalog с создаваемой им коллекцией объектов ProductSpecification. На самом деле практически всегда направление связи соответствует направлению от объекта-создателя к создаваемым им объектам. На диаграмме классов такие связи пред­ставляются в виде ассоциаций.

Рисунок 1.9 – Направление связи определяется из диаграмм взаимодействия

Пользуясь приведенными выше критериями для определения ассоциаций и направления связей на основе анализа всех диаграмм взаимодействия, для POS-приложения ТТ можно построить диаграмму классов, представленную на рис. 1.10. (Для большей ясности дополнительная информация о типах на этой диаграмме не отображается.)

Рисунок 1.10 – Ассоциации с указанием направления связи

Заметим, что эти ассоциации не совпадают с набором ассоциаций, сгенери­рованным для диаграммы классов из модели предметной области. Например, в модели предметной области между классами Register и ProductCatalog отсут­ствует ассоциация «Находит в», поскольку на этапе создания модели предметной области эта взаимосвязь не казалась важной. Однако в процессе создания диа­грамм взаимодействия было решено, что программный объект Register должен быть связан с программным объектом ProductCatalog с целью нахождения спецификации ProductSpecification.

Добавление зависимостей

В языке UML существует обозначение для отношения зависимости (dependency relationship), указывающего, что один элемент (любого типа, вклю­чая классы, прецеденты и т.д.) знает о другом элементе. Такое отношение ото­бражается пунктирной линией со стрелкой.

На диаграмме классов отношение зависимости отображает видимость между классами, отличную от обеспечивае­мой посредством атрибутов, т.е. глобальную, локальную видимость или види­мость, обеспечиваемую с помощью параметров. Видимость, обеспечиваемая по­средством атрибутов, отображается сплошной линией ассоциации со стрелкой, которая указывает направление связи. Например, программный объект Regis­ter получает возвращаемый объект типа ProductSpecification из сообщения, отправляемого им объекту ProductCatalog.

Таким образом, для объекта Reg­ister обеспечивается кратковременная локальная видимость объекта ProductSpecification. Объект Sale получает ProductSpecification в каче­стве параметра метода makeLineItem (видимость, обеспечиваемая посредством параметров).

Такие способы обеспечения видимости отображаются пунктирными линия­ми со стрелками, определяющими отношение зависимости (рис. 1.11). Линии зависимости не обязательно должны быть изогнутыми; просто так было удобно графически отобразить их в данном примере.

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

Задание на самостоятельную работу (для выбранной темы индивидуального проекта):

1. Построить диаграмму (программных) классов для модели проектирования (для основного успешного сценария прецедента).