OOAD - объектно-ориентированный дизайн

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

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

• Определение контекста системы
• Проектирование системной архитектуры
• Идентификация объектов в системе
• Построение дизайнерских макетов
• Спецификация объектных интерфейсов

Системный дизайн

Объектно-ориентированное проектирование системы включает определение контекста системы с последующим проектированием архитектуры системы.

• Context- Контекст системы имеет статическую и динамическую части. Статический контекст системы разработан с использованием простой блок-схемы всей системы, которая расширяется до иерархии подсистем. Модель подсистемы представлена ​​пакетами UML. Динамический контекст описывает, как система взаимодействует с окружающей средой. Он моделируется с использованиемuse case diagrams.

• System Architecture- Архитектура системы разработана на основе контекста системы в соответствии с принципами архитектурного дизайна, а также знаниями предметной области. Обычно система разбивается на уровни, и каждый уровень разбивается на подсистемы.

Объектно-ориентированная декомпозиция

Декомпозиция означает разделение большой сложной системы на иерархию более мелких компонентов с меньшей сложностью на принципах «разделяй и властвуй». Каждый основной компонент системы называется подсистемой. Объектно-ориентированная декомпозиция идентифицирует отдельные автономные объекты в системе и связь между этими объектами.

Преимущества разложения:

• Отдельные компоненты менее сложны, поэтому более понятны и управляемы.

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

• Это позволяет заменять или изменять подсистемы, не затрагивая другие подсистемы.

Определение параллелизма

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

Чтобы включить параллелизм, каждому параллельному элементу назначается отдельный поток управления. Если параллелизм находится на уровне объекта, то двум параллельным объектам назначаются два разных потока управления. Если две операции над одним объектом являются параллельными по своей природе, этот объект разделяется между разными потоками.

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

Выявление паттернов

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

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

• Образец фасада
• Схема разделения вида модели
• Образец наблюдателя
• Шаблон контроллера представления модели
• Опубликовать шаблон подписки
• Шаблон прокси

Управление событиями

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

Событие - это спецификация важного события, которое имеет место во времени и пространстве.

Можно смоделировать четыре типа событий, а именно:

• Signal Event - Именованный объект, брошенный одним объектом и пойманный другим объектом.

• Call Event - Синхронное событие, представляющее отправку операции.

• Time Event - Событие, отображающее течение времени.

• Change Event - Событие, представляющее изменение состояния.

Обработка граничных условий

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

• Запуск системы, то есть переход системы из неинициализированного состояния в устойчивое состояние.

• Завершение работы системы, т.е. закрытие всех запущенных потоков, очистка ресурсов и отправляемых сообщений.

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

• Предвидение сбоев или нежелательного завершения работы системы.

Граничные условия моделируются с использованием граничных вариантов использования.

Объектный дизайн

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

Дизайн объекта включает следующие этапы -

• Идентификация объекта
• Представление объекта, т.е. построение проектных моделей.
• Классификация операций
• Разработка алгоритма
• Дизайн отношений
• Осуществление контроля внешних взаимодействий
• Пакетные классы и ассоциации в модули

Идентификация объекта

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

Функции этого этапа:

• Определение и уточнение классов в каждой подсистеме или пакете

• Определение связей и ассоциаций между классами

• Создание иерархических ассоциаций между классами, т. Е. Обобщение / специализация и наследования

• Проектирование агрегатов

Представление объекта

После того, как классы идентифицированы, их необходимо представить с помощью методов объектного моделирования. Этот этап по сути включает построение диаграмм UML.

Есть два типа дизайнерских моделей, которые необходимо создать:

• Static Models - Для описания статической структуры системы с помощью диаграмм классов и диаграмм объектов.

• Dynamic Models - Чтобы описать динамическую структуру системы и показать взаимодействие между классами, используя диаграммы взаимодействия и диаграммы состояний.

Классификация операций

На этом этапе операция, которая должна выполняться над объектами, определяется путем объединения трех моделей, разработанных на этапе OOA, а именно объектной модели, динамической модели и функциональной модели. Операция определяет, что должно быть сделано, а не то, как это должно быть сделано.

Следующие задачи выполняются в отношении операций -

• Разработана диаграмма переходов состояний каждого объекта в системе.

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

• Выявлены случаи, когда одно событие запускает другие события в том же или разных объектах.

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

• Основные действия расширены до диаграмм потоков данных.

Разработка алгоритма

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

Одной операции может соответствовать несколько алгоритмов. После определения альтернативных алгоритмов выбирается оптимальный алгоритм для данной проблемной области. Метрики для выбора оптимального алгоритма:

• Computational Complexity - Сложность определяет эффективность алгоритма с точки зрения времени вычислений и требований к памяти.

• Flexibility - Гибкость определяет, может ли выбранный алгоритм быть реализован надлежащим образом без потери пригодности в различных средах.

• Understandability - Это определяет, насколько легко понять и реализовать выбранный алгоритм.

Дизайн отношений

Стратегия реализации взаимосвязей должна быть определена на этапе проектирования объекта. Основные рассматриваемые отношения включают ассоциации, агрегаты и наследования.

В отношении ассоциаций дизайнер должен сделать следующее:

• Определите, является ли ассоциация однонаправленной или двунаправленной.

• Проанализируйте путь ассоциаций и при необходимости обновите их.

• Реализуйте ассоциации как отдельный объект в случае отношений «многие-ко-многим»; или как ссылка на другой объект в случае отношений один-к-одному или один-ко-многим.

Что касается наследования, дизайнер должен сделать следующее:

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

• Определите абстрактные классы.

• Сделайте условия, чтобы при необходимости можно было поделиться своим поведением.

Осуществление контроля

Разработчик объекта может внести уточнения в стратегию модели диаграммы состояний. При проектировании системы делается основная стратегия реализации динамической модели. Во время объектного проектирования эта стратегия удачно приукрашивается для соответствующей реализации.

Подходы к реализации динамической модели:

• Represent State as a Location within a Program- Это традиционный подход, основанный на процедурах, при котором местоположение управления определяет состояние программы. Конечный автомат может быть реализован в виде программы. Переход формирует оператор ввода, основной путь управления формирует последовательность инструкций, ветви формируют условия, а обратные пути формируют циклы или итерации.

• State Machine Engine- Этот подход напрямую представляет конечный автомат через класс механизма конечного автомата. Этот класс выполняет конечный автомат посредством набора переходов и действий, предоставляемых приложением.

• Control as Concurrent Tasks- При таком подходе объект реализуется как задача на языке программирования или в операционной системе. Здесь событие реализовано как межзадачный вызов. Он сохраняет присущий параллелизм реальных объектов.

Классы упаковки

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

Различные аспекты упаковки:

• Hiding Internal Information from Outside View - Он позволяет рассматривать класс как «черный ящик» и позволяет изменять реализацию класса, не требуя от клиентов этого класса изменения кода.

• Coherence of Elements - Элемент, такой как класс, операция или модуль, является согласованным, если он организован по согласованному плану и все его части внутренне связаны между собой так, что служат общей цели.

• Construction of Physical Modules - Следующие рекомендации помогают при создании физических модулей -

  • Классы в модуле должны представлять похожие вещи или компоненты в одном и том же составном объекте.

  • Тесно связанные классы должны находиться в одном модуле.

  • Несвязанные или слабосвязанные классы следует размещать в отдельных модулях.

  • Модули должны иметь хорошее сцепление, т. Е. Высокую степень взаимодействия между его компонентами.

  • Модуль должен иметь низкую связь с другими модулями, т. Е. Взаимодействие или взаимозависимость между модулями должны быть минимальными.

Оптимизация дизайна

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

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

Для оптимизации дизайна можно сделать следующее:

• Добавить повторяющиеся ассоциации
• Пропустить неиспользуемые ассоциации
• Оптимизация алгоритмов
• Сохраняйте производные атрибуты, чтобы избежать повторного вычисления сложных выражений

Добавление избыточных ассоциаций

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

Исключение неиспользуемых ассоциаций

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

Оптимизация алгоритмов

В объектно-ориентированных системах оптимизация структуры данных и алгоритмов выполняется совместно. После того, как структура класса создана, необходимо оптимизировать операции и алгоритмы.

Оптимизация алгоритмов достигается за счет -

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

Сохранение и хранение производных атрибутов

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

Однако это может привести к аномалиям обновления, т. Е. К изменению значений базовых атрибутов без соответствующего изменения значений производных атрибутов. Чтобы избежать этого, предпринимаются следующие шаги -

• При каждом обновлении значения базового атрибута производный атрибут также повторно вычисляется.

• Все производные атрибуты повторно вычисляются и обновляются периодически в группе, а не после каждого обновления.

Проектная документация

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

Области использования

Хотя это вторичный продукт, необходима хорошая документация, особенно в следующих областях:

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

Содержание

Полезная документация должна по существу включать следующее содержание:

• High–level system architecture - Технологические схемы и схемы модулей

• Key abstractions and mechanisms - Диаграммы классов и диаграммы объектов.

• Scenarios that illustrate the behavior of the main aspects - Диаграммы поведения

Особенности

Особенности хорошей документации:

• Лаконично и в то же время однозначно, последовательно и полно

• Отслеживание требований к системе

• Well-structured

• Схематический вместо описательного