Объектно-ориентированное проектирование: определение, принципы и примеры

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

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

Вам будет интересно:Сводничество - это противоправные действия

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

Темы дизайна

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

Некоторые типичные предметы

Рассмотрим самые важные.

1. Концептуальная модель.

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

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

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

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

Исполнителями прецедентов могут быть конечные пользователи или другие системы. Во многих случаях варианты применения данного метода дополнительно разрабатываются в виде диаграмм. Схемы прецедентов используются для определения действующего лица и процессов, которые они выполняют. Подробнее можно прочитать в книге Гради Буча «Объектно-ориентированное проектирование».

3. Диаграмма последовательности системы.

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

4. Документация по пользовательскому интерфейсу.

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

Реляционная модель данных

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

Вам будет интересно:Толкование закона: виды, значение и применение

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

Концепции

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

1. Класс объекта.

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

2. Сокрытие объектно-ориентированного проектирования информационных систем, это способность защищать некоторые компоненты от внешних воздействий.

3. Наследование.

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

4. Интерфейс (Среди приемов объектно-ориентированного проектирования существуют так называемые паттерны. Интерфейс abstract factory - один из них).

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

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

Разработка концепций

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

Идентификация атрибутов.

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

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

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

Вывод (результаты) объектно-ориентированного проектирования

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

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

Некоторые принципы и стратегии дизайна

Вам будет интересно:Допрос с пристрастием - это форма следственных мероприятий

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

Рассмотрим принципы объектно-ориентированного проектирования ациклических зависимостей. Отметим, что граф компонентов (степень детализации зависит от объема работ) не должен иметь циклов. Это также называется направленным ациклическим графом. Пример объектно-ориентированного анализа и проектирования: допустим, C зависит от B, который подчиняется предмету A. Если последний также имеет отношение к C, то будет цикл.

Какой принцип составного повторного использования? Предпочтение отдается полиморфной композиции наследования. После фазы анализа концептуальная модель в дальнейшем развивается в объектно-ориентированное проектирование ИС. Здесь технологически независимые концепции анализа отображаются на реализующие классы, идентифицируются ограничения и разрабатываются интерфейсы, в результате чего получается модель для области решения.

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

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

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

Первое понятие

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

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

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

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

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

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

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

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

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

Приемы объектно-ориентированного проектирования, паттерны проектирования

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

Некоторые частые приемы объектно-ориентированного проектирования (паттерны проектирования) можно найти в шаблонах дизайна:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вам будет интересно:Срок хранения писем на "Почте России". Судебные письма. Заказные письма

В данном отношении должны быть выполнены следующие задачи:

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

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

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

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

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

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

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

Относительно объединений дизайнер должен сделать следующее:

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

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

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

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

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

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

1. Представлять состояние как местоположение в программе.

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

2. Механизм конечного автомата.

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

3. Управление - параллельные задачи.

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

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

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

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

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

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

Основы построения физических модулей:

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

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

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

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

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

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

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

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

Рассмотрим некоторые пункты подробнее.

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

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

Исключение неиспользуемых объединений.

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

Улучшение алгоритмов.

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

Оптимизация достигается путем:

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

Источник