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

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

· утверждение общих стандартов (соглашений) моделирова­ния и документирования системы;

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

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

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

Соглашения моделирования определяют:

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

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

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

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

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

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

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

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

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

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

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

· Диаграммы классов, реализующих вариант использования, и диаграммы взаимодействия, отражающие взаимодействие объектов в процессе реализации сценариев варианта ис­пользования, помещаются в кооперацию (см. подразд. 2.6) с именем данного варианта использования и стереотипом «use-case realization». Все кооперации помещаются в пакет с именем Use Case Realizations. Связь между вариантом ис­пользования и его реализацией изображается на специаль­ной диаграмме трассировки (рис. 4.4).

Рис. 4.4. Фрагмент диаграммы трассировки

Архитектурные механизмы отражают нефункциональные требования к системе (надежность, безопасность, хранение дан­ных в конкретной среде, интерфейсы с внешними системами и т.д.) и их реализацию в архитектуре системы. В процессе анализа они только обозначаются, отвлекаясь от особенностей среды ре­ализации, а все детали их реализации определяются в процессе проектирования.

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

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

Так, для системы регистрации идентифицировано пять клас­сов анализа:

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

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

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

· Course (Курс);

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

Классы анализа показаны на рис. 4.5.

Рис. 4.5. Классы анализа системы регистрации

Архитектурные уровни образуют иерархию уровней представ­ления любой крупномасштабной системы. В практике разработ­ки таких систем существует ряд типовых решений — архитектур­ных образцов, среди которых наиболее распространенным явля­ется образец «Уровни» (Layers). Этот образец можно описать сле­дующим образом:

Наименование образца:

«Уровни».

Контекст:

Крупномасштабные системы, нуждающиеся в декомпозиции.

Проблема:

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

· компоненты системы должны иметь возможность замены;

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

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

· размер компонентов не должен быть слишком большим.

Решение:

Предлагается базовый вариант, включающий следующие уровни (сверху вниз):

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

· бизнес-уровень (Business-specific) — набор компонентов, специфичных для конкретной предметной области;

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

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

Архитектурные уровни представляются в модели в виде паке­тов со стереотипом «1ауег». Количество и структура уровней зависят от сложности предметной области и среды реализации. В рамках архитектурного анализа определяется начальная структу­ра модели (набор пакетов и их зависимостей) и рассматриваются только верхние уровни (прикладной и бизнес-уровень).

4.3.2.

АНАЛИЗ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ

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

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

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

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

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

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

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

Граничные классы (Boundary) — служат посредниками при вза­имодействии внешних объектов с системой. Как правило, для каждой пары «действующее лицо — вариант использования» оп­ределяется один граничный класс. Типы граничных классов: пользовательский интерфейс (обмен информацией с пользовате­лем без деталей интерфейса — кнопок, списков, окон), систем­ный интерфейс и аппаратный интерфейс (используемые прото­колы без деталей их реализации).

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

Управляющие классы (Control) — обеспечивают координацию поведения объектов в системе. Они могут отсутствовать в некото­рых вариантах использования, ограничивающихся простыми ма­нипуляциями с хранимыми данными. Как правило, для каждого варианта использования определяется один управляющий класс. Примеры управляющих классов: менеджер транзакций, коорди­натор ресурсов, обработчик ошибок.

Классы анализа отражают функциональные требования к системе и моделируют объекты предметной области. Совокуп­ность классов анализа представляет собой начальную концепту­альную модель системы.

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

Рис. 4.6. Классы, участвующие в реализации варианта использования «Зарегистрироваться на курсы»

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

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

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

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

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

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

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

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

На рис. 4.7—4.11 приведены диаграммы последовательности и кооперативные диаграммы для основного потока событий вари­анта использования «Зарегистрироваться на курсы».

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

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

На последней диаграмме (см. рис. 4.11) присутствует объект дополнительного класса-сущности PrimaryScheduleOfferinglnfo. Его назначение будет описано ниже, при рассмотрении связей между классами.

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

Рис. 4.10. Кооперативная диаграмма «Зарегистрироваться на курсы» — подчиненный поток «Удалить график»

Рис. 4.11. Кооперативная диаграмма «Зарегистрироваться на курсы» — под­чиненный поток «Принять график»

Каждая операция «анализа» класса со­ответствует некоторому сообщению, принимаемому объектами данного класса. В процессе проектирования каждая операция «анализа» преобразуется в одну или более операций класса, кото­рые в дальнейшем будут реализованы в коде системы.

Так, диаграмма классов варианта использования «Зарегист­рироваться на курсы» (см. рис. 4.6) после построения диаграмм взаимодействия должна принять следующий вид (рис. 4.12).

Рис. 4.12. Диаграмма классов с операциями «анализа»

При построении диаграмм взаимодействия возникают проб­лемы правильного распределения обязанностей между классами. Для их решения существует ряд образцов[26], некоторые из них при­ведены ниже.