Проектирование классов

Проектирование классов включает следующие действия:

· детализация проектных классов;

· уточнение операций и атрибутов;

· моделирование состояний для классов;

· уточнение связей между классами.

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

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

Рис. 4.29. Кооперативная диаграмма «Зарегистрироваться на курсы» — основной поток событий

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

Полученные в результате уточнения классы подлежат непос­редственной реализации в коде системы.

Рис. 4.30. Кооперативная диаграмма «Зарегистрироваться на курсы» -подчиненный поток «Создать график»

Уточнение операций и атрибутов. Обязанности классов, опре­деленные в процессе анализа и документированные в виде опера­ций «анализа», преобразуются в операции, которые будут реали­зованы в коде. При этом:

· каждой операции присваивается краткое имя, характеризу­ющее ее результат;

· определяется полная сигнатура операции (в соответствии с нотацией, принятой в языке UML;

· создается краткое описание операции, включая смысл всех ее параметров;

· определяется видимость операции: public, private или protected;

· определяется область действия операции: экземпляр (опе­рация объекта) или классификатор (операция класса);

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

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

· кроме имени атрибута, задается его тип и значение по умол­чанию (необязательное);

· учитываются соглашения по именованию атрибутов, при­нятые в проекте и языке реализации;

· задается видимость атрибутов: public, private или protected;

· при необходимости определяются производные (вычисляе­мые) атрибуты.

Пример уточнения операций и атрибутов приведен на рис. 4.31.

Моделирование состояний для классов. Если некоторый объект всегда одинаково реагирует на событие, то он считается независи­мым от состояния по отношению к этому событию. В отличие от него зависимые от состояния объекты по-разному реагируют на одно и то же событие в зависимости от своего состояния. Обыч­но в экономических ИС содержится очень мало объектов, зави­симых от состояния, а системы управления технологическими процессами (системы реального времени) зачастую содержат множество таких объектов.

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

В качестве примера, связанного с системой регистрации, рас­смотрим поведение объекта класса CourseOffering. Диаграмма состояний строится в несколько этапов:

1. Идентификация состояний. Признаками для выявления сос­тояний являются изменение значений атрибутов объекта или соз­дание и уничтожение связей с другими объектами. Так, объект CourseOffering может находиться в состоянии Open (прием на курс открыт) до тех пор, пока количество зарегистрировавшихся на не­го студентов не превышает 10, а как только оно станет равным 10, объект переходит в состояние Closed (прием на курс закрыт). Кро­ме того, объект CourseOffering может находиться в состоянии Unassigned (его никто не ведет, т.е. отсутствует связь с каким-либо объектом Professor) или Assigned (такая связь существует).

Рис. 4.31. Класс Student с полностью определенными операциями

и атрибутами

2. Идентификация событий. События связаны, как правило, с выполнением некоторых операций. Так, в классе CourseOffering в результате распределения обязанностей при анализе варианта ис­пользования «Выбрать курсы для преподавания» определены две операции — addProfessor и removeProfessor, связанные с выбором курса некоторым профессором (созданием новой связи) и отказом от выбранного курса (разрывом связи). Этим операциям ста­вятся в соответствие два события - addProfessor и removeProfessor.

3. Идентификация переходов между состояниями. Переходы вызываются событиями. Таким образом, состояния Unassigned и Assigned соединяются двумя переходами (рис. 4.32).

Рис. 4.32. Переходы между состояниями

Дальнейшая детализация поведения объекта CourseOffering приведет к построению диаграммы состояний, показанной на рис. 4.33. На данной диаграмме использованы такие возможнос­ти моделирования состояний, как композитные состояния (composite state) и историческое состояние (history state). В данном случае композитными состояниями являются Open и Closed, а вложенными состояниями — Unassigned, Assigned, Cancelled (курс отменен), Full (курс заполнен) и Committed (курс включен в расписание). Композитные состояния позволяют упростить ди­аграмму уменьшая количество переходов, поскольку вложенные состояния наследуют все свойства и переходы композитного сос­тояния.

Историческое состояние (обозначенное на диаграмме ок­ружностью с буквой «Н») — это псевдосостояние, которое восста­навливает предыдущее активное состояние в композитном состоянии. Оно позволяет композитному состоянию Open запоми­нать, какое из вложенных состояний (Unassigned или Assigned) было текущим в момент выхода из Open, для того, чтобы любой из переходов в Open (add student или remove student) возвращался именно в это вложенное состояние, а не в начальное состояние.

Рис. 4.33. Диаграммы состояний с композитными состояниями

Построение диаграмм состояний может оказать следующее воздействие на описание классов:

· события могут отображаться в операции класса (например, события, связанные с изменением количества студентов, за­писавшихся на курс, могут быть отображены в операции addstudent и removestudent класса CourseOffering);

· особенности конкретных состояний могут повлиять на де­тали выполнения операций;

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

Уточнение связей между классами. В процессе проектирова­ния связи между классами (ассоциации, агрегации и обобщения) подлежат уточнению.

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

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

· Агрегации, обладающие свойствами композиции (см. подразд. 2.4.2), преобразуются в связи композиции.

Рис. 4.34. Пример преобразования ассоциаций и агрегаций

Пример преобразования связей в соответствии с данными ре­комендациями для классов варианта использования «Зарегист­рироваться на курсы», приведен на рис. 4.34. Ассоциация между управляющим и граничным классами преобразована в зависи­мость. Агрегация между классами Student и Schedule обладает свойствами композиции. Направления навигации на ассоциаци­ях между классами Schedule и CourseOffering введены по следую­щим соображениям: нет необходимости в получении списка гра­фиков, в которых присутствует какой-либо курс, и количество графиков относительно мало по сравнению с количеством кон­кретных курсов.

Рис. 4.35. Преобразование обобщения

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