Лекция 7. Анализ и проектирование программного обеспечения. Анализ ПО

Сначала охарактеризуем в целом технологический процесс анализа и проектирования (один из процессов в рамках RUP). Его цели:

• преобразование требований в системный проект;

• создание стабильной архитектуры системы;

• адаптация системного проекта к среде реализации.

На входе анализа и проектирования находятся модель вариантов использования, глоссарий и дополнительная спецификация, на выходе – проектная модель системы, модель базы данных, описание архитектуры.

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

Эскизная архитектура включает:

• Набор ключевых абстракций.

• Набор классов анализа.

• Механизмы анализа.

• Иерархию уровней.

• Структуру системы.

• Реализации вариантов использования.

Уточнение архитектуры состоит в переходе от классов анализа к проектным классам. Определяются: проектные классы; механизмы проектирования; представление размещения.

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

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

• определение элементов проекта;

• рецензирование проекта.

Проектирование элементов включает:

• выявление пакетов и подсистем;

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

• проектирование подсистем.

Проектирование БД включает:

• выделение устойчивых классов;

• разработку структуры БД;

• определение механизмов хранения (таких как ODBC или OODBMS).

Анализ характеризуется тем, что:

• в центре внимания – проблема;

• не придается значения деталям;

• описывается структура и поведение системы;

• реализуются функциональные требования в архитектуре системы;

• модель анализа имеет относительно небольшой размер.

Характеристики проектирования:

• в центре внимания – решение;

• придается значение деталям – операциям и атрибутам;

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

• модель приближена к реальному коду;

• реализуются нефункциональные требования;

• проектная модель значительно больше модели анализа.

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

Исполнителями процесса анализа являются архитектор, разработчик (или проектировщик), разработчик БД, разработчик пользовательского интерфейса, рецензент. Обязанности архитектора:

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

• определение структуры каждого архитектурного представления;

• осуществление архитектурного анализа.

Обязанности разработчика:

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

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

• анализ одного или нескольких пакетов или подсистем.

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

Объектно-ориентированный анализ включает два вида деятельности выполняемые друг за другом:

1. архитектурный анализ;

2. анализ вариантов использования.

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

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

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

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

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

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

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

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

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

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

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

• Механизмы анализа: обеспечивают взаимодействие классов и компонентов предметной области, без деталей реализации.

• Проектные механизмы: учитывают некоторые детали среды реализации, без привязки к конкретной среде (например, выбор между РСУБД и ООСУБД).

• Механизмы реализации: зависят от конкретной технологии, языка программирования, поставщика (Oracle, Sun или Microsoft) и т.д.

Примеры механизмов анализа:

• Устойчивость (persistency): элементы модели, которые должны сохранять свое состояние в течение длительного времени должны быть определены как устойчивые (для каждого устойчивого элемента определяются его размер и количество хранимых объектов, сроки хранения, механизмы и частотные характеристики доступа).

• Интерфейс с унаследованными системами (legacy interface) – к этому механизму относят все элементы модели, ответственные за интерфейс с унаследованной системой.

• Безопасность (уровни, правила, привилегии) – элементы, обеспечивающие контроль доступа к системе.

• Распределение – элементы, которые должны быть распределены по узлам сети.

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

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

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

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

• промежуточный (middleware), куда входят платформо-независимые сервисы;

• системный, содержащий компоненты вычислительной и сетевой инфраструктуры.

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

• Уровни (Layers) – способ декомпозиции приложения на набор слоев, соответствующих различным уровням абстракции.

• Модель-представление-управление (Model-view-controller, M-V-C) – разделение приложения на три части: данные и бизнес-правила; пользовательское представление; обработку данных.

• Каналы и фильтры (Pipes and filters) – шаблон архитектуры системы для потоковой обработки данных.

Архитектурный образец «Layers»:

Прикладной уровень (Application subsystems) – реализация функциональности вариантов использования.

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

Уровень промежуточного ПО (Middleware) – платформо-независимые сервисы (GUI, ORB, …)

Уровень базового ПО (System software) – обеспечение вычислительной и сетевой инфраструктуры (ОС, сетевые протоколы и др.).

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

Образец «Каналы и фильтры» разбивает большую сложную задачу по обработке данных на упорядоченную совокупность небольших независимых этапов обработки (каждый такой этап – «фильтр»), соединенных «каналами» – потоками данных. При этом для некоторых задач удается добиться эффективного решения за счет конвейера.

Образец «Model-view-controller». Проблема: Изменения во внешнем представлении достаточно вероятны, одна и та же информация представляется по-разному в нескольких местах, система должна быстро реагировать на изменения данных. Решение: выделить набор компонентов 3-х типов: компонентов хранения данных, компонентов представления для пользователей, и компонентов обработки (воспринимающих команды, преобразующих данные и обновляющих представления).

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

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

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

• определение обязанностей классов, их атрибутов и ассоциаций;

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

• квалификацию механизмов анализа.

Анализ вариантов использования является итерационным процессом – делится на несколько итераций, в ходе которых работа ведется над одним или несколькими (но не всеми сразу) вариантами использования. Как правило, распределение вариантов использования по итерациям осуществляется на основе их приоритета (высокоприоритетные раньше, низкоприоритетные позже).

Шаги анализа вариантов использования:

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

2. Для каждой реализации варианта использования:

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

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

3. Для каждого выявленного класса анализа:

   1. Определение обязанностей класса.

   2. Определение атрибутов и ассоциаций.

   3. Квалификация механизмов анализа.

4. Унификация классов анализа.

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

• граничные классы, являющиеся посредниками при взаимодействии с внешними объектами;

• классы-сущности, представляющие собой основные абстракции (понятия) разрабатываемой системы;

• управляющие классы, обеспечивающие координацию поведения объектов в системе.

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

• пользовательский интерфейс (обмен информацией с пользователем, без деталей UI – кнопок, списков, окон);

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

Способы выделения классов-сущностей:

• Перевод бизнес-сущностей из бизнес-модели в классы-сущности.

• Анализ глоссария (некоторые термины являются именами искомых классов-сущностей).

• Анализ описаний вариантов использования.

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

Все созданные при анализе данного варианта использования классы анализа помещаются на диаграмму VOPC (View Of Participating Classes).

Распределение поведения, реализуемого вариантом использования, между классами реализуется с помощью диаграмм взаимодействия (диаграмм последовательности и кооперативных диаграмм). Диаграммы последовательности и кооперативные диаграммы являются как бы двумя ортогональными проекциями, описывающими взаимодействие (проекция на вертикальную плоскость – диаграмма последовательности, на горизонтальную – диаграмма кооперации):

Виды обязанностей классов:

• Знание:

  • наличие информации о данных или вычисляемых величинах;

  • наличие информации о связанных объектах.

• Действие:

  • выполнение некоторых действий самим объектом (прием и обработка входящих сообщений);

  • инициация действий других объектов (отправка исходящих сообщений);

  • координация действий других объектов (посредничество).

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

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

При построении диаграмм взаимодействия возникают проблемы правильного распределения обязанностей между классами. Для их решения существует ряд образцов: Information Expert, Creator, Low Coupling, High Cohesion.

Образец “Information Expert”. Проблема: Нужно определить наиболее общий принцип распределения обязанностей между классами. Решение: Следует назначить обязанность информационному эксперту – классу, у которого имеется информация, требуемая для выполнения обязанности.