Объектно-ориентированный анализ и проектирование ( OOAD ) — это технический подход к анализу и проектированию приложения, системы или бизнеса путем применения объектно-ориентированного программирования , а также использования визуального моделирования на протяжении всего процесса разработки программного обеспечения для управления взаимодействием с заинтересованными сторонами и качеством продукта.
OOAD в современной программной инженерии обычно проводится итеративно и инкрементально. Результатами деятельности OOAD являются модели анализа (для OOA) и модели проектирования (для OOD) соответственно. Цель состоит в том, чтобы они постоянно совершенствовались и развивались, движимые ключевыми факторами, такими как риски и ценность для бизнеса.
На заре объектно-ориентированной технологии до середины 1990-х годов существовало много различных конкурирующих методологий разработки программного обеспечения и объектно-ориентированного моделирования , часто привязанных к конкретным поставщикам инструментов Computer Aided Software Engineering (CASE). Отсутствие стандартных обозначений, последовательных терминов и руководств по процессам было основными проблемами в то время, что снижало эффективность коммуникации и удлиняло кривые обучения.
Некоторые из известных ранних объектно-ориентированных методологий были созданы и вдохновлены такими гуру, как Грэди Буч , Джеймс Рамбо , Ивар Якобсон ( Три Амигоса ), Роберт Мартин , Питер Коуд , Салли Шлаер , Стивен Меллор и Ребекка Вирфс-Брок .
В 1994 году три друга Rational Software начали работать вместе над разработкой унифицированного языка моделирования (UML). Позже, вместе с Филиппом Крухтеном и Уокером Ройсом (старшим сыном Уинстона Ройса ), они возглавили успешную миссию по объединению своих собственных методологий, OMT , OOSE и метода Буча , с различными идеями и опытом других лидеров отрасли в Rational Unified Process (RUP), всеобъемлющее руководство по итеративному и инкрементальному процессу и фреймворк для изучения передовых отраслевых практик разработки программного обеспечения и управления проектами. [1] С тех пор семейство Unified Process стало, вероятно, самой популярной методологией и эталонной моделью для объектно-ориентированного анализа и проектирования.
Объект содержит инкапсулированные данные и процедуры, сгруппированные для представления сущности. «Интерфейс объекта» определяет, как с объектом можно взаимодействовать . Объектно-ориентированная программа описывается взаимодействием этих объектов. Объектно-ориентированное проектирование — это дисциплина определения объектов и их взаимодействий для решения проблемы, которая была выявлена и задокументирована в ходе объектно-ориентированного анализа.
Далее следует описание подмножества объектно-ориентированного проектирования на основе классов , которое не включает подходы на основе прототипов объектов , где объекты обычно получаются не путем создания экземпляров классов, а путем клонирования других (прототипных) объектов. Объектно-ориентированное проектирование — это метод проектирования, охватывающий процесс объектно-ориентированной декомпозиции и нотацию для изображения как логических и физических, так и состояний и динамических моделей проектируемой системы.
Жизненный цикл программного обеспечения обычно делится на этапы, начиная с абстрактного описания проблемы, затем проектирования, затем кодирования и тестирования и, наконец, развертывания. Самые ранние этапы этого процесса — анализ и проектирование. Фазу анализа также часто называют «приобретением требований».
В некоторых подходах к разработке ПО, известных как каскадные модели, границы между каждым этапом должны быть достаточно жесткими и последовательными. Термин «водопад» был придуман для таких методологий, чтобы обозначить, что прогресс идет последовательно только в одном направлении, т. е. как только анализ был завершен, тогда и только тогда начиналось проектирование, и было редко (и считалось источником ошибок), когда проблема дизайна требовала изменения модели анализа или когда проблема кодирования требовала изменения дизайна.
Альтернативой каскадным моделям являются итерационные модели. Это различие было популяризировано Барри Бёмом в очень влиятельной статье о его спиральной модели для итеративной разработки программного обеспечения. С итеративными моделями можно выполнять работу на разных этапах модели параллельно. Так, например, возможно — и не рассматриваться как источник ошибок — работать над анализом, проектированием и даже кодом в один и тот же день и иметь проблемы на одном этапе, влияющие на проблемы на другом. Акцент в итеративных моделях заключается в том, что разработка программного обеспечения — это наукоемкий процесс, и что такие вещи, как анализ, на самом деле не могут быть полностью поняты без понимания проблем проектирования, что проблемы кодирования могут влиять на проектирование, что тестирование может дать информацию о том, как следует модифицировать код или даже проектирование и т. д. [2]
Хотя можно делать объектно-ориентированную разработку с использованием каскадной модели, на практике большинство объектно-ориентированных систем разрабатываются с использованием итеративного подхода. В результате в объектно-ориентированных процессах «анализ и проектирование» часто рассматриваются одновременно.
Объектно-ориентированная парадигма подчеркивает модульность и возможность повторного использования. Целью объектно-ориентированного подхода является удовлетворение принципа «открытости–закрытости» . Модуль является открытым, если он поддерживает расширение или если модуль предоставляет стандартизированные способы добавления новых поведений или описания новых состояний. В объектно-ориентированной парадигме это часто достигается путем создания нового подкласса существующего класса. Модуль является закрытым, если он имеет четко определенный стабильный интерфейс, который должны использовать все другие модули, и который ограничивает взаимодействие и потенциальные ошибки, которые могут быть внесены в один модуль изменениями в другом. В объектно-ориентированной парадигме это достигается путем определения методов, которые вызывают службы на объектах. Методы могут быть как открытыми, так и закрытыми, т. е. определенные поведения, которые являются уникальными для объекта, не раскрываются другим объектам. Это уменьшает источник многих распространенных ошибок в компьютерном программировании. [3]
Жизненный цикл программного обеспечения обычно делится на этапы, идущие от абстрактного описания проблемы к дизайну, затем к кодированию и тестированию и, наконец, к развертыванию. Самые ранние этапы этого процесса — анализ и проектирование. Различие между анализом и проектированием часто описывается как «что против как». В анализе разработчики работают с пользователями и экспертами в предметной области, чтобы определить, что должна делать система. Детали реализации должны быть в основном или полностью (в зависимости от конкретного метода) проигнорированы на этом этапе. Целью этапа анализа является создание функциональной модели системы независимо от ограничений, таких как соответствующая технология. В объектно-ориентированном анализе это обычно делается с помощью вариантов использования и абстрактных определений наиболее важных объектов. Последующий этап проектирования уточняет модель анализа и делает необходимые технологические и другие варианты реализации. В объектно-ориентированном проектировании акцент делается на описании различных объектов, их данных, поведения и взаимодействий. Модель проектирования должна иметь все необходимые детали, чтобы программисты могли реализовать проект в коде. [4]
Целью любой аналитической деятельности в жизненном цикле программного обеспечения является создание модели функциональных требований системы, которая не зависит от ограничений реализации.
Основное отличие объектно-ориентированного анализа от других форм анализа заключается в том, что при объектно-ориентированном подходе мы организуем требования вокруг объектов, которые интегрируют как поведение (процессы), так и состояния (данные), смоделированные по образцу объектов реального мира, с которыми взаимодействует система. В других или традиционных методологиях анализа два аспекта: процессы и данные рассматриваются отдельно. Например, данные могут быть смоделированы с помощью ER-диаграмм , а поведение — с помощью блок-схем или структурных диаграмм .
Распространенными моделями, используемыми в OOA, являются варианты использования и объектные модели . Варианты использования описывают сценарии для стандартных функций домена, которые должна выполнять система. Объектные модели описывают имена, отношения классов (например, Circle является подклассом Shape), операции и свойства основных объектов. Также могут быть созданы макеты или прототипы пользовательского интерфейса для облегчения понимания. [5]
Объектно-ориентированное проектирование (OOD) — это процесс планирования системы взаимодействующих объектов для решения программной проблемы. Это метод проектирования программного обеспечения . Определяя классы и их функциональность для своих потомков (объектов-экземпляров), каждый объект может запустить ту же реализацию класса со своим состоянием.
В ходе OOD разработчик применяет ограничения реализации к концептуальной модели, созданной в объектно-ориентированном анализе. Такие ограничения могут включать аппаратные и программные платформы, требования к производительности, постоянное хранение и транзакции, удобство использования системы и ограничения, налагаемые бюджетами и временем. Концепции в модели анализа, которая не зависит от технологии, отображаются на реализующих классах и интерфейсах, что приводит к модели области решения, т. е. подробному описанию того, как система должна быть построена на конкретных технологиях. [6]
Важные темы в рамках OOD также включают проектирование программных архитектур с применением архитектурных шаблонов и шаблонов проектирования с принципами объектно-ориентированного проектирования.
Входные данные для объектно-ориентированного проектирования предоставляются выходными данными объектно-ориентированного анализа. Осознайте, что выходной артефакт не обязательно должен быть полностью разработан, чтобы служить входными данными объектно-ориентированного проектирования; анализ и проектирование могут происходить параллельно, и на практике результаты одного вида деятельности могут питать другой в коротком цикле обратной связи через итеративный процесс. И анализ, и проектирование могут выполняться пошагово, а артефакты могут непрерывно расти, а не полностью разрабатываться за один раз.
Некоторые типичные артефакты ввода для объектно-ориентированного проектирования:
Пять основных концепций объектно-ориентированного проектирования — это функции уровня реализации, встроенные в язык программирования. Эти функции часто называют следующими общепринятыми именами:
Главное преимущество использования шаблона проектирования заключается в том, что его можно повторно использовать в нескольких приложениях. Его также можно рассматривать как шаблон для решения проблемы, который можно использовать во многих различных ситуациях и/или приложениях. Объектно-ориентированные шаблоны проектирования обычно показывают отношения и взаимодействия между классами или объектами, не указывая конечные классы или объекты приложения.
Объектно-ориентированное моделирование (OOM) — это распространенный подход к моделированию приложений, систем и бизнес-доменов с использованием объектно-ориентированной парадигмы на протяжении всего жизненного цикла разработки . OOM — это основной метод, активно используемый как OOD, так и OOA-деятельностью в современной программной инженерии.
Объектно-ориентированное моделирование обычно делится на два аспекта работы: моделирование динамического поведения, такого как бизнес-процессы и варианты использования , и моделирование статических структур, таких как классы и компоненты. OOA и OOD — это два отдельных абстрактных уровня (т. е. уровень анализа и уровень проектирования) в ходе OOM. Унифицированный язык моделирования (UML) и SysML — два популярных международных стандартных языка, используемых для объектно-ориентированного моделирования. [9]
Преимущества ООМ:
Эффективная и действенная коммуникация
Пользователи обычно испытывают трудности с пониманием подробных документов и кодов языка программирования. Визуальные диаграммы моделей могут быть более понятными и могут позволить пользователям и заинтересованным сторонам давать разработчикам обратную связь по соответствующим требованиям и структуре системы. Ключевая цель объектно-ориентированного подхода — уменьшить «семантический разрыв» между системой и реальным миром и построить систему с использованием терминологии, которая почти такая же, как у заинтересованных сторон в повседневной работе. Объектно-ориентированное моделирование является важным инструментом для облегчения этого.
Полезная и стабильная абстракция
Моделирование помогает кодированию. Цель большинства современных методологий программного обеспечения заключается в том, чтобы сначала ответить на вопросы «что», а затем ответить на вопросы «как», то есть сначала определить функциональность, которую должна предоставить система, не принимая во внимание ограничения реализации, а затем рассмотреть, как сделать конкретные решения для этих абстрактных требований, и усовершенствовать их в подробные проекты и коды с помощью ограничений, таких как технология и бюджет. Объектно-ориентированное моделирование позволяет это сделать, создавая абстрактные и доступные описания как системных требований, так и проектов, то есть моделей, которые определяют их основные структуры и поведение, такие как процессы и объекты, которые являются важными и ценными активами разработки с более высокими уровнями абстракции по сравнению с конкретным и сложным исходным кодом.
