### 8. Объектно-ориентированный анализ систем

Стандарты UML

Идентификация основных абстракций

Архитектурный анализ

Идентификация классов

Контрольные вопросы и упражнения

### Стандарты UML

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

Архитектурный анализ выполняется архитектором системы и включает:

утверждение общих стандартов моделирования и документирования системы;

предварительное выявление архитектурных механизмов (механизмов анализа);

формирование набора основных абстракций предметной области (классов анализа);

формирование начального представления архитектурных уровней.

Анализ вариантов использования включает:

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

определение обязанностей классов — распределение поведения, реализуемого вариантом использования, между классами;

определение атрибутов и ассоциаций классов;

унификацию классов анализа.

Стандарты объектно-ориентированного моделирования определяют:

используемые диаграммы и элементы модели;

правила их применения;

соглашения по именованию элементов модели;

организацию модели (пакеты).

Пример набора соглашений именования:

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

имена классов должны быть существительными, соответствующими по возможности понятиям предметной области;

имена классов должны писаться с прописной буквы;

имена атрибутов и операций должны писаться со строчной буквы;

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

Пример набора соглашений моделирования:

Все классы и диаграммы, описывающие предварительный системный проект, помещаются в пакет с именем Analysis Model.

Диаграммы классов, реализующие вариант использования, и диаграммы взаимодействия, отражающие взаимодействие объектов в процессе реализации сценариев варианта использования, помещаются в кооперацию с именем данного варианта использования и стереотипом <<use case realization>>.

Все кооперации помещаются в пакет с именем Use Case Realizations.

Связь между вариантом использования и его реализацией изображается на специальной диаграмме трассировки (рис. 8.1).

Рисунок 8.1 – Связь между вариантом использования и его реализацией

### Идентификация основных абстракций

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

Следуя этим рекомендациям, определим для системы регистрации пять классов анализа (рис. 8.2.):

• Student (Студент);

• Professor (Профессор);

• Schedule (Учебный график);

• Course (Курс);

• CourseOffering (Предлагаемый курс).

Рисунок. 8.2 – Общая структура классов анализа

### Архитектурный анализ

Архитектурный анализ предполагает выделение архитектурных уровней системы, которые образуют иерархию уровней представления системы. В практике разработки клиент-серверных систем существует ряд типовых решений — архитектурных образцов, среди которых наиболее распространен образец "Уровни" (Layers). В соответствии с ним базовый вариант системы включает следующие уровни (сверху вниз):

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

• уровень управления — набор компонентов, специфичных для конкретной предметной области;

• промежуточный — различные платформо-независимые сервисы (библиотеки пользовательского интерфейса, брокеры запросов и др.);

• системный — ПО для вычислительной и сетевой инфраструктур (ОС, сетевые протоколы и др.).

Архитектурные уровни представляются в модели в виде пакетов со стереотипом <<lауеr>>. В рамках архитектурного анализа определяется начальная структура модели и рассматриваются только верхние уровни (прикладной и уровень управления).

### Идентификация классов

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

1. Управляющий класс (control class) — класс, отвечающий за координацию действий других классов. На каждой диаграмме классов должен быть хотя бы один управляющий класс. Он отвечает за координацию действий других классов, контролирует последовательность выполнения действий данного варианта использования. Как правило, данный класс является активным и инициирует рассылку множества сообщений другим классам модели. Кроме специального обозначения управляющий класс может быть изображен в форме прямоугольника класса со стереотипом <<control>> (рис. 8.3, а). Примеры управляющих классов: менеджер транзакций, координатор ресурсов, обработчик событий, обработчик ошибок, и т.п.

2. Класс-сущность (entity class) — пассивный класс, информация о котором должна храниться постоянно и не уничтожаться с выключением системы или завершением программы. Как правило, этот класс соответствует отдельной таблице базы данных. В этом случае его атрибуты являются полями таблицы, а операции – присоединенными или хранимыми процедурами. Этот класс пассивный и лишь принимает сообщения от других классов модели.

Источники выявления классов-сущностей:

ключевые абстракции, созданные в процессе архитектурного анализа,

глоссарий проекта,

описание потоков событий вариантов использования.

Класс-сущность может быть изображен также стандартным образом в форме прямоугольника класса со стереотипом <<entity>> (рис. 8.3, б).

3. Граничный класс (boundary class) — класс, который располагается на границе системы с внешней средой и непосредственно взаимодействует с актерами, но является составной частью системы.

Как правило, для каждой пары "действующее лицо — вариант использования" определяется один граничный класс. Типы граничных классов:

пользовательский интерфейс, выражающий обмен информацией с пользователем без деталей интерфейса: кнопок, списков, окон, и т.п.

системный интерфейс с надсистемой или другой системой (используемые протоколы обмена без деталей их реализации);

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

Граничный класс может быть изображен также стандартным образом в форме прямоугольника класса со стереотипом <<boundary>> (рис. 8.3, в).

Рисунок 8.3 – Графическое изображение классов для моделирования программного обеспечения

Исходя из назначения трех выделенных типов классов, можно кратко охарактеризовать распределение обязанностей между ними:

• граничные классы отвечают за взаимодействие с внешней средой системы (действующими лицами);

• классы-сущности отвечают за хранение данных и манипулирование ими;

• управляющие классы координируют потоки событий варианта использования.

Пример набора классов, участвующих в реализации варианта использования "Зарегистрироваться на курсы", приведен на рис. 8.4.

Рисунок 8.4 – Классификация классов анализа

Более детальное распределение обязанностей (в виде операций классов) выполняется с помощью диаграмм взаимодействия.

### Контрольные вопросы и упражнения

1. Перечислите основные стандарты UML.

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

3. Какие бывают виды классов анализа?

4. В чем заключается архитектурный анализ?

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