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

Эта статья требует дополнительных ссылок для проверки . Пожалуйста, помогите улучшить эту статью , добавив цитаты из надежных источников . Материал, не полученный от источника, может быть оспорен и удален. Найти источники:  «Объектно-ориентированный анализ и дизайн»  -  новости  · газеты  · книги  · ученый  · JSTOR ( ноябрь 2019 г. ) ( Узнайте, как и когда удалить это сообщение-шаблон )

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

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

История [ править ]

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

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

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

Обзор [ править ]

Этот раздел может потребовать очистки для соответствия стандартам качества Википедии . Конкретная проблема: удалите дубликаты, сократите описания водопада и сделайте заявления более краткими. Пожалуйста, помогите улучшить этот раздел, если можете. ( Январь 2014 г. ) ( Узнайте, как и когда удалить этот шаблон сообщения )

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

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

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

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

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

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

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

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

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

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

Объектно-ориентированный дизайн [ править ]

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

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

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

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

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

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

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

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

Полезная и устойчивая абстракция

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

См. Также [ править ]

Ссылки [ править ]

Дальнейшее чтение [ править ]

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

Внешние ссылки [ править ]

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

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