Идентификация атрибутов

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

Создание диаграммы классов

Диаграммы классов

Стереотип класса

Стереотип представляет категорию класса.

В UML определены три основных стереотипа:

1. Граница (Boundary).

2. Управление (Control).

3. Сущность (Entity).

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

2.9.2.1 Пограничные классы – boundary classes

Классы, расположенные на границе системы со всем остальным миром, называют пограничными.

К пограничным классам относятся:

1. формы;

2. отчёты;

3. интерфейсы с аппаратурой (с принтерами, сканерами, датчиками);

4. интерфейсы с другими системами.

Обозначаются пограничные классы следующим образом:

Для выявления пограничных классов необходимо исследовать диаграмму вариантов использования (Use case diagram). Для каждого взаимодействия между актёром и вариантом использования должен существовать хотя бы один пограничный класс. Именно он позволяет актёру взаимодействовать с системой.

Необязательно создавать уникальные пограничные классы для каждой пары “актёр – вариант использования”. Если два актёра инициируют один и тот же вариант использования, то они могут применять общий пограничный класс для взаимодействия с системой.

2.9.2.2 Управляющие классы – control classes

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

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

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

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

2.9.2.3 Классы-сущности – entity classes

Классы-сущности содержат атрибуты, которые хранятся постоянно.

Классы-сущности обозначаются следующим символом:

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

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

- Требования определяют поток событий.

- Поток событий определяет объекты, классы и атрибуты классов.

- Каждый атрибут класса-сущности становится полем в базе данных.

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

2.9.3 Видимость класса – Visibility

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

Для установки видимости в окне спецификации класса необходимо установить значение параметра Export control (Контроль экспорта) в одно из возможных значений:

1. Открытый (Public) – этот класс виден всем классам системы.

2. Защищённый, закрытый (Protected, Private) – может быть виден во вложенных в него классах, друзьям этого класса или из самого класса.

3. Реализация (Implementation) – класс может быть виден только из классов того же пакета.

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

2.9.4 Пакеты – packages

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

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

Существует три основных подхода для группирования классов в пакеты:

1. По стереотипу классов (boundary, entity, control). В этом случае получается три пакета: с пограничными классами, с классами-сущностями, с управляющими классами. В общем случае количество пакетов будет зависеть от количества определённых в системе стереотипов классов.

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

2. По функциональности (например, в пакете Безопасность будут содержаться все классы, отвечающие за безопасность приложения; в пакете Заказы – классы обработки заказов; в пакете Отчёты – классы подготовки отчётов; в пакете Ошибки – классы обработки ошибок).

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

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

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

Диаграмма классов – некоторый граф, вершинами которого являются классы, связанные различными типами структурных отношений.

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

Обычно для описания системы создаются несколько диаграмм классов. Диаграммы классов следует создавать для вариантов использования (use cases). Количество диаграмм для каждой системной функции будет зависеть от числа уровней детализации. В свою очередь количество уровней зависит от сложности функции.

Диаграммы классов уточняются по мере проектирования:

1. В начале логического проектирования диаграмма показывает некоторое подмножество программных классов (в отличие от классов предметной области) и отношения между классами этого подмножества.

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

3. На этапе конструирования диаграмма показывает только пакеты классов и отношения между ними.

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

Для построения диаграммы классов следует:

1. Определить все классы, необходимые для варианта использования. Для этого анализируются диаграммы взаимодействия.

2. Определить пакеты классов в соответствии с категориями классов (или по стереотипу, или по функциональности, или по комбинации функциональности и стереотипов).

3. Отобразить выделенные классы на диаграммах классов пакетов.

4. Добавить стереотипы к классам.

5. Добавить на диаграмму атрибуты соответствующих понятий.

6. Добавить имена операций на основе диаграмм взаимодействия.

7. Добавить информацию о типах и видимости атрибутов и операций.

8. Добавить необходимые ассоциации.

9. Добавить стрелки, определяющие направление навигации для ассоциаций.

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

11. Добавить мощность отношений.

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

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

Имя класса	Комментарий
POST	Управляющий класс
ProductCatalog	Каталог товаров
ProductSpecification	Спецификация товара
Store	Место, где происходит покупка товаров
Sale	Продажа
SaleLineItem	Элемент для определённого товара, приобретённого в рамках продажи
Payment	Оплата товара наличными

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

Как правило, атрибуты непосредственно следуют из следующих данных:

1. Требования к системе.

2. Принятые варианты использования.

3. Поясняющие документы, допущения.

Атрибуты в спецификации сопровождаются коротким текстовым описанием.

С атрибутами связывают три основных фрагмента информации:

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

2. Тип данных атрибута. Типы атрибутов зачастую рассматриваются как примитивные типы данных. К стандартным типам простых атрибутов относятся: Boolean, Date, Integer, Double, String, Time. В качестве типов данных можно использовать либо встроенные типы языка программирования, либо определённые в модели имена классов.

3. Первоначальное значение атрибута. Атрибуты могут иметь значение по умолчанию. Например, ставка налога с продаж может иметь неизменное значение 5%, следовательно, можно определить значение по умолчанию, равное 0.05.

Кроме имени, типа и значения в спецификации атрибута задают:

1. Видимость атрибута – attribute visibility. Допустимые значения:

- Public – общий, открытый (знак +). Атрибут виден всем остальным классам. Любой класс может изменить значение атрибута.

- Private – закрытый, секретный (знак –). Атрибут не виден никаким другим классам.

- Protected – защищённый (знак #). Атрибут доступен только самому классу и его потомкам.

- Implementation – реализационный (знака нет). Атрибут является общим только в пределах пакета классов.

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

2. Метод локализации атрибута – containment. Возможные значения:

- By value – по значению. Атрибут содержится внутри класса. Например, если атрибут относится к типу String, то эта строка будет содержаться внутри определения класса.

- By reference – по ссылке. Атрибут локализован вне класса, но класс содержит указатель на него.

- Unspecified – не определён. Метод локализации атрибута ещё не определён. При генерации кода применяется значение By value этого параметра.

3. Static – определение статичного атрибута (знак $). Под статичным атрибутом понимается атрибут, который используется всеми объектами класса.

4. Derived – определение производного атрибута (знак /). К производным атрибутам относятся такие, значения которых могут быть получены на основании других атрибутов класса (подобные атрибуты лучше не указывать в качестве атрибутов класса), а также такие, значения которых определяются из реального значения кратности ассоциации. Например, для Элемента продажи найдено 10 товаров, следовательно, значение атрибута Количество будет равно 10.

Атрибуты для варианта использования Покупка товара системы POST:

Имя атрибута	Тип атрибута	Комментарий	Имя класса
description	String	Описание элемента продажи	ProductSpecification
price	Double	Цена элемента продажи
$ UPC	String	Универсальный код товара
address	String	Адрес места продажи товаров	Store
name	String	Название места продажи товаров
date	Date	Дата продажи	Sale
time	Time	Время продажи
isComplete	Boolean	Завершённость продажи
/ quantity	Integer	Количество приобретённых товаров	SaleLineItem
amount	Double	Количество денег, предоставленных покупателем для оплаты	Payment
total	Double	Итоговая сумма продажи

Рекомендации по идентификации атрибутов

1. Класс с 10-15 атрибутами может быть вполне приемлемым. Следует только убедиться, что все его атрибуты нужны и действительно могут принадлежать этому классу. Если у класса слишком много атрибутов, то, возможно, этот класс следует разделить на два меньших. Точно так же необходимо внимательно относиться к классам, у которых слишком мало атрибутов. Может быть, стоит объединить два класса в один.

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

Например:

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

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

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

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

Дата добавления: 2014-01-07