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

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

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

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

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

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

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

• Архитектура системы — Архитектура системы разработана на основе контекста системы в соответствии с принципами архитектурного проектирования, а также с учетом предметной области. Как правило, система разбивается на слои, и каждый слой разлагается для формирования подсистем.

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

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

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

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

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

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

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

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

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

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

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

Выявление параллелизма

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

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

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

Идентификация шаблонов

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

Некоторые часто используемые шаблоны дизайна —

• Фасадный рисунок
• Модель разделения вида модели
• Образец наблюдателя
• Модель контроллера вида модели
• Опубликовать шаблон подписки
• Прокси шаблон

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

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

Событие — это спецификация значимого события, имеющего местоположение во времени и пространстве.

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

• Сигнальное событие — именованный объект, брошенный одним объектом и захваченный другим объектом.

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

• Событие времени — событие, представляющее течение времени.

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

Сигнальное событие — именованный объект, брошенный одним объектом и захваченный другим объектом.

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

Событие времени — событие, представляющее течение времени.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Проектирование объекта включает в себя следующие этапы —

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

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

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

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

• Выявление и уточнение классов в каждой подсистеме или пакете

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

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

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

Выявление и уточнение классов в каждой подсистеме или пакете

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

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

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

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

Как только классы идентифицированы, они должны быть представлены с использованием методов объектного моделирования. Этот этап в основном включает в себя построение UML-диаграмм.

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

• Статические модели — Для описания статической структуры системы используются диаграммы классов и диаграммы объектов.

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

Статические модели — Для описания статической структуры системы используются диаграммы классов и диаграммы объектов.

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

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

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

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

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

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

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

• Подоперации в действиях определены.

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

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

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

Идентифицированы случаи, когда одно событие вызывает другие события в том же или в другом объекте.

Подоперации в действиях определены.

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

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

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

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

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

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

• Понятность — это определяет, является ли выбранный алгоритм простым для понимания и реализации.

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

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

Понятность — это определяет, является ли выбранный алгоритм простым для понимания и реализации.

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

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

Дизайнер должен сделать следующее относительно ассоциаций —

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Управление как параллельные задачи — при таком подходе объект реализуется как задача на языке программирования или в операционной системе. Здесь событие реализовано как межзадачный вызов. Сохраняет присущий параллелизм реальных объектов.

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

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

Управление как параллельные задачи — при таком подходе объект реализуется как задача на языке программирования или в операционной системе. Здесь событие реализовано как межзадачный вызов. Сохраняет присущий параллелизм реальных объектов.

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

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

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

• Скрытие внутренней информации от внешнего вида. Это позволяет рассматривать класс как «черный ящик» и позволяет изменять реализацию класса, не требуя, чтобы какие-либо клиенты этого класса модифицировали код.

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

• Построение физических модулей . Следующие рекомендации помогут при создании физических модулей.

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

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

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

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

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

Скрытие внутренней информации от внешнего вида. Это позволяет рассматривать класс как «черный ящик» и позволяет изменять реализацию класса, не требуя, чтобы какие-либо клиенты этого класса модифицировали код.

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

Построение физических модулей . Следующие рекомендации помогут при создании физических модулей.

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

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

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

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

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

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

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

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

Различные вещи, которые можно сделать для оптимизации дизайна:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

содержание

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

• Архитектура системы высокого уровня. Диаграммы процессов и диаграммы модулей

• Ключевые абстракции и механизмы — Диаграммы классов и диаграммы объектов.

• Сценарии, иллюстрирующие поведение основных аспектов — поведенческие диаграммы

Архитектура системы высокого уровня. Диаграммы процессов и диаграммы модулей

Ключевые абстракции и механизмы — Диаграммы классов и диаграммы объектов.

Сценарии, иллюстрирующие поведение основных аспектов — поведенческие диаграммы

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

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

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

Прослеживается в соответствии с требованиями системы

Хорошо структурированная

Схематическое, а не описательное