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

Проектирование элементов системы выполняется проекти­ровщиками и включает в себя:

• уточнение описания вариантов использования;

• проектирование классов;

• проектирование баз данных.

Уточнение описания вариантов использования

Уточнение описания вариантов использования заключается в модификации их диаграмм взаимодействия и диаграмм классов с учетом вновь появившихся на шаге проектирования классов и подсистем, а также проектных механизмов. Так, например, диаг­раммы взаимодействия варианта использования «Зарегистриро­ваться на курсы», изображенные на рис. 4.7 и 4.8, примут вид, по­казанный на рис. 4.29 и 4.30.

Объект класса CourseRegBDManager на рис. 4.29 играет роль интерфейса с объектной базой данных системы регистрации (предполагается, что данные о студентах, графиках и профессо­рах будут храниться в объектной БД).

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

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

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

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

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

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

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

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

Рис. 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.

Проектирование баз данных

Проектирование БД зависит от типа используемой для хране­ния данных СУБД - объектной или реляционной. Для объектных БД никакого проектирования не требуется, поскольку классы-сущности непосредственно отображаются в БД. Для реляцион­ных БД классы-сущности объектной модели должны быть отоб­ражены в таблицы реляционной БД. Совокупность таблиц и свя­зей между ними может быть представлена, в виде диаграммы классов, которая по существу является ER-диаграммой. Набор правил, применяемых при отображении классов в таблицы БД, фактически совпадает с правилами преобразования сущностей и связей, описанными в подразд. 4.1. В технологии RUP, в частнос­ти, для такого отображения используется специальный инстру­мент — Data Modeler. Он выполняет преобразование классов-сущностей в классы-таблицы с последующей генерацией описа­ния БД на SQL.

Для описания схемы БД применяется следующий набор элементов языка UML со своими стереотипами (профиль UML):

1. таблица представляется в виде класса со стереотипом «Table»;

2. представление изображается в виде класса со стереотипом «View»;

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

4. обычная ассоциация и агрегация представляются в виде ас­социации со стереотипом «Non-Identifying» (в терминоло­гии IDEF1X — неидентифицирующей связи);

5. композиция представляется в виде ассоциации со стереоти­пом «Identifying» (в терминологии IDEF1X — идентифици­рующей связи);

6. схема БД представляется в виде пакета со стереотипом «Schema», содержащего классы-таблицы;

7. контейнер хранимых процедур представляется в виде класса со стереотипом «SP Container»;

8. ограничения целостности, индексы и триггеры представля­ются в виде операций классов-таблиц со стереотипами «РК» (Primary key), «FK» (Foreign key), «Unique», «Check», «Index» и «Trigger»;

9. физическая база данных представляется в виде компонента со стереотипом «Database».

Рис. 4.36. Пример неидентифицирующих связей

Примеры преобразования, выполненного для классов вари­анта использования «Зарегистрироваться на курсы» средствами Data Modeler, приведены на рис. 4.36 - 4.38.

На рис. 4.36 ассоциации-классы, представляющие свойства связей между классами Schedule и CourseOffering (см. рис. 4.16), преобразованы в таблицы в соответствии с правилом преобразо­вания бинарных связей типа «многие-ко-многим».

Идентифицирующая связь между таблицами T_Student и T_Schedule на рис. 4.37 соответствует связи композиции между классами Student и Schedule на рис. 4.34.

На рис. 4.38 показано преобразование связи обобщения, изображенной на рис. 4.35. Здесь используется отдельная табли­ца для каждого подтипа (в соответствии с правилом из подразд. 4.1). Достоинства и недостатки различных способов преобразо­вания обсуждались в подразд. 4.1). Преимуществом способа, применяемого в данном случае, является простота алгоритма ав­томатического преобразования, выполняемого средствами Data Modeler.

Рис. 4.37. Пример идентифицирующей связи

Рис. 4.38. Пример преобразования обобщения

! Следует запомнить

Целью объектно-ориентированного анализа является транс­формация функциональных требований к ПО в предваритель­ный системный проект и создание стабильной основы архитекту­ры системы. В процессе проектирования системный проект «погружается» в среду реализации с учетом всех нефункциональных требований.

Основные понятия

Архитектурные механизмы, архитектурные уровни, классы анализа, проектные классы, процесс, поток.

? Вопросы для самоконтроля

1. Перечислите правила формирования схемы базы данных из ERM.

2. К каким последствиям для системы может привести отсут­ствие архитектурного анализа?

3. Что дает использование образцов распределения обязан­ностей?

4. Какие классы нуждаются в моделировании состояний?

5. Охарактеризуйте достоинства и область применения мето­дики анализа и проектирования Rational Unified Process.