Пример структурного проектирования по

Здесь продолжено рассмотрение примера из подразд. 3.2.5.

Построение диаграмм системных процессов и диаграмм последовательностей экранных форм

Результаты перехода от модели бизнес-процессов к модели системных процессов представлены на рис. 4.1—4.2. На диаграм­ме системных процессов первого уровня вместо отдельных про­цессов введены процессоры — компьютеры, на которых выпол­няются соответствующие процессы.

Рис. 4.1. Диаграмма системных процессов нулевого уровня

Рис. 4.2. Диаграмма системных процессов первого уровня

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

Рис. 4.3. Диаграмма последовательности экранных форм

4.3.

Объектно-ориентированный анализ

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

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

4.3.1.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Student (Студент);

2. Professor (Профессор);

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

4. Course (Курс);

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

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

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

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

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

«Уровни».

Контекст:

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

Проблема:

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

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

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

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

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

Решение:

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

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

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

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

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

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

4.3.2.