Конспект по курсу. Объектно ориентированный анализ и проектирование (1133667), страница 12

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 12)

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

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

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

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

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

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

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

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

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

Разработчик БД отвечает за модель данных (схему БД).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Соглашения фиксируются в документе «Руководящие указания по проектированию» (Design Guidelines). Пример соглашений:

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

2. Для каждого варианта использования должен быть создан пакет Use-Case Realization, включающий:

   1. по крайней мере одну реализацию варианта использования;

   2. диаграмму “View Of Participating Classes” (VOPC).

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

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

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

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

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

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

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

• Механизмы реализации: зависят от конкретной технологии, языка программирования, поставщика (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» родом из языка Smalltalk. Проблема: Изменения во внешнем представлении достаточно вероятны, одна и та же информация представляется по-разному в нескольких местах, система должна быстро реагировать на изменения данных. Решение: выделить набор компонентов 3-х типов: компонентов хранения данных, компонентов представления для пользователей, и компонентов обработки (воспринимающих команды, преобразующих данные и обновляющих представления).

Р
ис. Один из вариантов организации взаимодействия, предписываемый образцом MVC.

Надо заметить, что при указанном взаимодействии объекты модели отвечают не только за хранение данных как таковое, но и за оповещение всех подписчиков об изменениях данных. Такая дополнительная нагрузка неоднозначно оценивается разными экспертами, например, Мартин Фаулер считает это решение неудачным и предлагает другое, в котором оповещение возлагается на объекты управления:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Знание:

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

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

• Действие:

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

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

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

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

Характеристики

Список файлов лекций