Объектно-ориентированный анализ и дизайн - Object-oriented analysis and design

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

OOAD в современной разработке программного обеспечения обычно выполняется итеративно и поэтапно. Результатами действий OOAD являются модели анализа (для OOA) и модели проектирования (для OOD) соответственно. Намерение состоит в том, чтобы они постоянно совершенствовались и развивались с учетом таких ключевых факторов, как риски и стоимость бизнеса.

История

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

Некоторые из хорошо известных ранних объектно-ориентированных методологий были созданы и вдохновлены такими гуру, как Грейди Буч, Джеймс Рамбо, Ивар Якобсон (в Три Амигоса), Роберт Мартин, Питер Коуд, Салли Шлаер, Стивен Меллор, и Ребекка Вирфс-Брок.

В 1994 г. Три Амигоса компании Rational Software начали совместную работу по разработке Единый язык моделирования (UML). Позже вместе с Филипп Крюхтен и Уокер Ройс (старший сын Уинстон Ройс ), они провели успешную миссию по объединению собственных методологий, OMT, OOSE и Метод Буча, с различными идеями и опытом других лидеров отрасли в рациональный унифицированный процесс (RUP), всеобъемлющее руководство по итеративным и инкрементным процессам и структура для изучения лучших отраслевых практик разработки программного обеспечения и управления проектами.^[1] С тех пор Единый процесс Это семейство стало, вероятно, самой популярной методологией и эталонной моделью объектно-ориентированного анализа и проектирования.

Обзор

Жизненный цикл программного обеспечения обычно делится на этапы: от абстрактного описания проблемы до проектирования, затем кода и тестирования и, наконец, до развертывания. Самые ранние стадии этого процесса - анализ и проектирование. Фаза анализа также часто называется «сбор требований».

В Модель водопада.

OOAD выполняется итеративно и поэтапно, как это сформулировано Единый процесс.

В некоторых подходах к разработке программного обеспечения, известных под общим названием «каскадные модели», границы между каждым этапом должны быть довольно жесткими и последовательными. Термин «водопад» был придуман для таких методологий, чтобы обозначить, что прогресс идет последовательно только в одном направлении, то есть, как только анализ был завершен, тогда и только тогда начиналось проектирование, и редко (и считалось источником ошибки), когда проблема дизайна требовали изменения модели анализа или когда проблема кодирования требовала изменения конструкции.

Альтернативой каскадным моделям являются итерационные модели. Это различие было популяризировано Барри Бём в очень влиятельной статье о его спиральной модели для итеративной разработки программного обеспечения. С итеративными моделями можно выполнять работу на различных этапах модели параллельно. Так, например, можно - и это не рассматривается как источник ошибки - работать над анализом, проектированием и даже кодом в один и тот же день, и проблемы на одной стадии влияют на проблемы на другой. Акцент на итеративных моделях заключается в том, что разработка программного обеспечения - это наукоемкий процесс, и что такие вещи, как анализ, не могут быть полностью поняты без понимания проблем дизайна, что проблемы кодирования могут повлиять на дизайн, что тестирование может дать информацию о том, как код или даже следует доработать дизайн и т. д.^[2]

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

Объектно-ориентированная парадигма подчеркивает модульность и возможность повторного использования. Цель объектно-ориентированного подхода - удовлетворить «открытый закрытый принцип». Модуль является открытым, если он поддерживает расширение, или если модуль предоставляет стандартизированные способы добавления нового поведения или описания новых состояний. В объектно-ориентированной парадигме это часто достигается путем создания нового подкласса существующего класса. Модуль закрывается, если у него есть четко определенный стабильный интерфейс, который должны использовать все другие модули, и который ограничивает взаимодействие и потенциальные ошибки, которые могут быть внесены в один модуль путем изменений в другом. В объектно-ориентированной парадигме это достигается путем определения методов, которые вызывают службы для объектов. Методы могут быть общедоступными или частными, т. Е. Определенные поведения, уникальные для объекта, не отображаются для других объектов. Это уменьшает источник многих распространенных ошибок в компьютерном программировании.^[3]

Жизненный цикл программного обеспечения обычно делится на этапы: от абстрактного описания проблемы до проектирования, затем кода и тестирования и, наконец, до развертывания. Самые ранние стадии этого процесса - анализ и проектирование. Различие между анализом и дизайном часто описывается как «что и как». При анализе разработчики работают с пользователями и экспертами в предметной области, чтобы определить, что система должна делать. Предполагается, что на этом этапе детали реализации в основном или полностью (в зависимости от конкретного метода) игнорируются. Цель этапа анализа - создать функциональную модель системы независимо от ограничений, таких как соответствующая технология. В объектно-ориентированном анализе это обычно делается с помощью вариантов использования и абстрактных определений наиболее важных объектов. На последующем этапе разработки модель анализа уточняется и выбираются необходимые технологии и другие варианты реализации. В объектно-ориентированном дизайне упор делается на описание различных объектов, их данных, поведения и взаимодействий. Модель проекта должна содержать все необходимые детали, чтобы программисты могли реализовать проект в коде.^[4].

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

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

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

Общие модели, используемые в OOA, - это варианты использования и объектные модели. Сценарии использования описывать сценарии для стандартных функций предметной области, которые должна выполнять система. Объектные модели описывают имена, отношения классов (например, Circle является подклассом Shape), операции и свойства основных объектов. Для облегчения понимания можно также создавать макеты или прототипы пользовательского интерфейса.^[5]

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

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

Объектно-ориентированное моделирование

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

Объектно-ориентированное моделирование обычно делится на два аспекта работы: моделирование динамического поведения, такого как бизнес-процессы и сценарии использования, а также моделирование статических структур, таких как классы и компоненты. OOA и OOD - это два различных абстрактных уровня (т.е. уровень анализа и уровень проектирования) во время OOM. В Единый язык моделирования (UML) и SysML - это два популярных международных стандартных языка, используемых для объектно-ориентированного моделирования.^[7]

Преимущества OOM:

Эффективное и действенное общение

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

Полезная и стабильная абстракция

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

Смотрите также

дальнейшее чтение

Грейди Буч. «Объектно-ориентированный анализ и дизайн с приложениями, 3-е издание»:http://www.informit.com/store/product.aspx?isbn=020189551X Аддисон-Уэсли 2007.
Ребекка Вирфс-Брок, Брайан Вилкерсон, Лорен Винер. Разработка объектно-ориентированного программного обеспечения. Prentice Hall, 1990. [Практическое введение в объектно-ориентированное программирование и дизайн.]
Теория объектно-ориентированного дизайна: Строительные блоки OOD и нотации для их представления (с акцентом на шаблоны проектирования).
Мартин Фаулер. Шаблоны анализа: многоразовые объектные модели. Аддисон-Уэсли, 1997. [Введение в объектно-ориентированный анализ с концептуальными моделями]
Бертран Мейер. Построение объектно-ориентированного программного обеспечения. Прентис Холл, 1997
Крейг Ларман. Применение UML и шаблонов - Введение в OOA / D и итеративную разработку. Prentice Hall PTR, 3-е изд. 2005г., Миннм, н, ннн
Сетраг Хошафян. Ориентация объекта.
Ульрих Норбисрат, Альберт Цюндорф, Рубен Джубех. Сюжетное моделирование. Amazon Createspace. п. 333., 2013. ISBN 9781483949253.

внешняя ссылка

Статья Объектно-ориентированный анализ и дизайн с помощью UML и RUP обзор (также о картах CRC).
Применение UML - Объектно-ориентированный анализ и дизайн руководство
Веб-сайт и форумы ресурсов OOAD и UML - Объектно-ориентированный анализ и дизайн с UML.
Анализ требований к программному обеспечению с использованием UML статья Дхираджа Шетти.
Статья Объектно-ориентированный анализ в реальном мире

[1] «Лучшие практики Rational Unified Process для команд разработчиков программного обеспечения» (PDF). Официальный документ Rational Software (TP026B). 1998 г.. Получено 12 декабря 2013.

[2] Бём Б, "Спиральная модель разработки и улучшения программного обеспечения ", IEEE Computer, IEEE, 21 (5): 61-72, май 1988 г.

[3] Мейер, Бертран (1988). Построение объектно-ориентированного программного обеспечения. Кембридж: Международная серия Prentise Hall по компьютерным наукам. п. 23. ISBN 0-13-629049-3.

[4] Якобсен, Ивар; Магнус Кристерсон; Патрик Йонссон; Гуннар Овергаард (1992). Объектно-ориентированная разработка программного обеспечения. Эддисон-Уэсли ACM Press. стр.15, 199. ISBN 0-201-54435-0.

[5] Якобсен, Ивар; Магнус Кристерсон; Патрик Йонссон; Гуннар Овергаард (1992). Объектно-ориентированная разработка программного обеспечения. Эддисон-Уэсли ACM Press. стр.77–79. ISBN 0-201-54435-0.

[6] Коналлен, Джим (2000). Создание веб-приложений с помощью UML. Эддисон Уэсли. п.147. ISBN 0201615770.

[7] Якобсен, Ивар; Магнус Кристерсон; Патрик Йонссон; Гуннар Овергаард (1992). Объектно-ориентированная разработка программного обеспечения. Эддисон-Уэсли ACM Press. стр.15, 199. ISBN 0-201-54435-0.

[1]

[2]

[3]

[4]

[5]

[6]

[7]