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

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

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

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

История

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

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

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

Обзор

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Входные данные (источники) для объектно-ориентированного проектирования

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

Вот некоторые типичные входные артефакты объектно-ориентированного проектирования:

Концептуальная модель : результат объектно-ориентированного анализа, фиксирующий концепции проблемной области . Концептуальная модель явно выбирается независимой от деталей реализации, таких как параллелизм или хранение данных.
Вариант использования : описание последовательности событий, которые в совокупности приводят к тому, что система делает что-то полезное. Каждый вариант использования предоставляет один или несколько сценариев , которые описывают, как система должна взаимодействовать с пользователями, называемыми субъектами, для достижения определенной бизнес-цели или функции. Субъектами варианта использования могут быть конечные пользователи или другие системы. Во многих случаях варианты использования дополнительно детализируются в диаграммы вариантов использования . Диаграммы вариантов использования используются для идентификации действующих лиц (пользователей или других систем) и процессов, которые они выполняют.
Диаграмма последовательности системы . Диаграмма последовательности системы (SSD) — это изображение, которое показывает для конкретного сценария варианта использования события, генерируемые внешними субъектами, их порядок и возможные межсистемные события.
Документация пользовательского интерфейса (если применимо): документ, который показывает и описывает внешний вид пользовательского интерфейса конечного продукта. Это не обязательно, но это помогает визуализировать конечный продукт и, следовательно, помогает дизайнеру.
Реляционная модель данных (если применимо). Модель данных — это абстрактная модель, которая описывает, как данные представляются и используются. Если объектная база данных не используется, реляционную модель данных обычно следует создавать до проектирования, поскольку стратегия, выбранная для объектно-реляционного сопоставления, является результатом процесса объектно-ориентированного проектирования. Однако можно разрабатывать реляционную модель данных и артефакты объектно-ориентированного проектирования параллельно, а рост одного артефакта может стимулировать совершенствование других артефактов.

Объектно-ориентированные концепции

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

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

Концепции проектирования

Определение объектов, создание диаграммы классов на основе концептуальной диаграммы : обычно сопоставляет сущность с классом.
Определение атрибутов и их моделей.
Используйте шаблоны проектирования (если применимо). Шаблон проектирования — это не законченный проект, а описание решения распространенной проблемы в контексте. ^[7]

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

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

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

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

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

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

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

Внедрение зависимостей . Основная идея заключается в том, что если объект зависит от наличия экземпляра какого-либо другого объекта, то необходимый объект «вводится» в зависимый объект; например, подключение к базе данных передается в качестве аргумента конструктору вместо его внутреннего создания.
Принцип ациклических зависимостей : Граф зависимостей пакетов или компонентов (детализация зависит от объёма работ одного разработчика) не должен иметь циклов. Это также называется ориентированным ациклическим графом . ^[8] Например, пакет C зависит от пакета B, который зависит от пакета A. Если бы пакет A зависел от пакета C, у вас был бы цикл.
Принцип составного повторного использования : отдавайте предпочтение полиморфной композиции объектов, а не наследованию. ^[7]

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

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

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

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

Эффективное и результативное общение

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

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

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

См. также

Ссылки

^ «Лучшие практики Rational Unified Process для групп разработчиков программного обеспечения» (PDF) . Технический документ по программному обеспечению Rational (TP026B). 1998 год . Проверено 12 декабря 2013 г.
^ Бем Б., «Спиральная модель разработки и улучшения программного обеспечения », IEEE Computer, IEEE, 21 (5): 61-72, май 1988 г.
^ Мейер, Бертран (1988). Объектно-ориентированное построение программного обеспечения . Кембридж: Международная серия Прентис-Холл по информатике. п. 23. ISBN 0-13-629049-3 .
^ Якобсен, Ивар; Магнус Кристерсон; Патрик Йонссон; Гуннар Овергаард (1992). Объектно-ориентированная разработка программного обеспечения . Аддисон-Уэсли ACM Press. стр. 15, 199 . ISBN 0-201-54435-0 .
^ Якобсен, Ивар; Магнус Кристерсон; Патрик Йонссон; Гуннар Овергаард (1992). Объектно-ориентированная разработка программного обеспечения . Аддисон-Уэсли ACM Press. стр. 77–79 . ISBN 0-201-54435-0 .
^ Коналлен, Джим (2000). Создание веб-приложений с помощью UML . Эддисон Уэсли. п. 147 . ISBN 0201615770 .
^ Перейти обратно: ^а ^б Эрих Гамма ; Ричард Хелм ; Ральф Джонсон ; Джон Влиссидес (2 января 1995 г.). Шаблоны проектирования: элементы объектно-ориентированного программного обеспечения многократного использования . Аддисон-Уэсли . ISBN 978-0-201-63361-0 .
^ «Что такое объектно-ориентированное проектирование?» . Объект Наставник. Архивировано из оригинала 30 июня 2007 г. Проверено 3 июля 2007 г.
^ Якобсен, Ивар; Магнус Кристерсон; Патрик Йонссон; Гуннар Овергаард (1992). Объектно-ориентированная разработка программного обеспечения . Аддисон-Уэсли ACM Press. стр. 15, 199 . ISBN 0-201-54435-0 .

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

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

Внешние ссылки

статьи «Объектно-ориентированный анализ и проектирование с использованием UML и RUP» (также о картах CRC). Обзор
Применение UML — по объектно-ориентированному анализу и проектированию учебное пособие
Веб-сайт и форумы ресурсов OOAD и UML — объектно-ориентированный анализ и проектирование с использованием UML .
Анализ требований к программному обеспечению с использованием статьи UML Дираджа Шетти.
Статья Объектно-ориентированный анализ в реальном мире
Объектно-ориентированный анализ и проектирование — обзор использования UML
Ларман, Крейг. Применение UML и шаблонов — третье издание
Объектно-ориентированный анализ и проектирование
LePUS3 и Class-Z : формальные языки моделирования для объектно-ориентированного проектирования.

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

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

[3] Мейер, Бертран (1988). Объектно-ориентированное построение программного обеспечения . Кембридж: Международная серия Прентис-Холл по информатике. п. 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 .

[gof-7] Перейти обратно: ^а ^б Эрих Гамма ; Ричард Хелм ; Ральф Джонсон ; Джон Влиссидес (2 января 1995 г.). Шаблоны проектирования: элементы объектно-ориентированного программного обеспечения многократного использования . Аддисон-Уэсли . ISBN 978-0-201-63361-0 .

[objectMentor-8] «Что такое объектно-ориентированное проектирование?» . Объект Наставник. Архивировано из оригинала 30 июня 2007 г. Проверено 3 июля 2007 г.

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

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]