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

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

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

Модель ОО выгодна следующими способами —

• Это облегчает изменения в системе при низких затратах.

• Это способствует повторному использованию компонентов.

• Это упрощает проблему интеграции компонентов для настройки большой системы.

• Это упрощает проектирование распределенных систем.

Это облегчает изменения в системе при низких затратах.

Это способствует повторному использованию компонентов.

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

Это упрощает проектирование распределенных систем.

Элементы объектно-ориентированной системы

Давайте рассмотрим характеристики OO System —

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

• Атрибуты — они описывают информацию об объекте.

• Поведение — определяет, что может делать объект. Он определяет операцию, выполняемую над объектами.

• Класс — класс инкапсулирует данные и их поведение. Объекты с похожим значением и целью сгруппированы вместе как класс.

• Методы — Методы определяют поведение класса. Они — не что иное как действие, которое может выполнить объект.

• Сообщение — сообщение — это вызов функции или процедуры от одного объекта к другому. Это информация, отправляемая объектам для запуска методов. По сути, сообщение — это вызов функции или процедуры от одного объекта к другому.

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

Атрибуты — они описывают информацию об объекте.

Поведение — определяет, что может делать объект. Он определяет операцию, выполняемую над объектами.

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

Методы — Методы определяют поведение класса. Они — не что иное как действие, которое может выполнить объект.

Сообщение — сообщение — это вызов функции или процедуры от одного объекта к другому. Это информация, отправляемая объектам для запуска методов. По сути, сообщение — это вызов функции или процедуры от одного объекта к другому.

Особенности объектно-ориентированной системы

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

Инкапсуляция

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

абстракция

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

Отношения

Все классы в системе связаны друг с другом. Объекты не существуют изолированно, они существуют во взаимосвязи с другими объектами.

Есть три типа объектных отношений —

• Агрегация — указывает на связь между целым и его частями.

• Ассоциация — при этом два класса связаны или связаны каким-либо образом, например, один класс работает с другим для выполнения задачи или один класс воздействует на другой класс.

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

Агрегация — указывает на связь между целым и его частями.

Ассоциация — при этом два класса связаны или связаны каким-либо образом, например, один класс работает с другим для выполнения задачи или один класс воздействует на другой класс.

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

наследование

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

Полиморфизм и динамическое связывание

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

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

Структурный подход против Объектно-ориентированный подход

Следующая таблица объясняет, как объектно-ориентированный подход отличается от традиционного структурированного подхода —

Структурированный подход	Объектно-ориентированный подход
Работает с нисходящим подходом.	Это работает с восходящим подходом.
Программа делится на количество подмодулей или функций.	Программа организована по количеству классов и предметов.
Вызов функции используется.	Передача сообщений используется.
Повторное использование программного обеспечения невозможно.	Возможность многократного использования.
Структурное проектирование программирования обычно оставляют до конца фазы.	Объектно-ориентированное проектирование программируется одновременно с другими фазами.
Структурированный дизайн больше подходит для офшоринга.	Подходит для внутреннего развития.
Это показывает четкий переход от проектирования к реализации.	Не очень понятен переход от дизайна к реализации.
Он подходит для систем реального времени, встроенных систем и проектов, где объекты не являются наиболее полезным уровнем абстракции.	Он подходит для большинства бизнес-приложений, проектов разработки игр, которые, как ожидается, будут настраиваться или расширяться.
Диаграмма DFD & ER моделирует данные.	Диаграмма классов, диаграмма последовательности, диаграмма состояний и варианты использования — все это вносит свой вклад.
В этом случае проекты могут легко управляться благодаря четко идентифицируемым фазам.	При таком подходе управление проектами может быть затруднено из-за неопределенных переходов между этапами.

Унифицированный язык моделирования (UML)

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

Он определяется как набор спецификаций, созданных и распространяемых Группой управления объектами. UML расширяемый и масштабируемый.

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

UML состоит из —

• Диаграммы — это графическое представление процесса, системы или какой-то ее части.

• Обозначения — это состоит из элементов, которые работают вместе в диаграмме, таких как соединители, символы, заметки и т. Д.

Диаграммы — это графическое представление процесса, системы или какой-то ее части.

Обозначения — это состоит из элементов, которые работают вместе в диаграмме, таких как соединители, символы, заметки и т. Д.

Пример нотации UML для класса

Диаграмма экземпляра — нотация UML

Операции над объектами

Следующие операции выполняются на объектах —

• Конструктор / Деструктор — создание новых экземпляров класса и удаление существующих экземпляров класса. Например, добавление нового сотрудника.

• Запрос — Доступ к состоянию без изменения значения, не имеет побочных эффектов. Например, найти адрес конкретного сотрудника.

• Обновление — изменяет значение одного или нескольких атрибутов и влияет на состояние объекта. Например, изменение адреса сотрудника.

Конструктор / Деструктор — создание новых экземпляров класса и удаление существующих экземпляров класса. Например, добавление нового сотрудника.

Запрос — Доступ к состоянию без изменения значения, не имеет побочных эффектов. Например, найти адрес конкретного сотрудника.

Обновление — изменяет значение одного или нескольких атрибутов и влияет на состояние объекта. Например, изменение адреса сотрудника.

Использование UML

UML весьма полезен для следующих целей —

• Моделирование бизнес-процесса
• Описание архитектуры системы
• Отображение структуры приложения
• Захват поведения системы
• Моделирование структуры данных
• Построение подробных спецификаций системы
• Зарисовка идей
• Генерация программного кода

Статические Модели

Статические модели показывают структурные характеристики системы, описывают ее системную структуру и делают акцент на тех частях, которые составляют систему.

• Они используются для определения имен классов, атрибутов, методов, подписи и пакетов.

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

Они используются для определения имен классов, атрибутов, методов, подписи и пакетов.

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

Динамические Модели

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

• Динамические модели определяют необходимый объект и то, как они работают вместе с помощью методов и сообщений.

• Они используются для разработки логики и поведения системы.

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

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

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

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

Жизненный цикл разработки объектно-ориентированной системы

Он состоит из трех макропроцессов —

• Объектно-ориентированный анализ (ООА)
• Объектно-ориентированный дизайн (OOD)
• Объектно-ориентированная реализация (OOI)

Деятельность по разработке объектно-ориентированных систем

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

• Объектно-ориентированный анализ
• Объектно-ориентированный дизайн
• макетирования
• Реализация
• Инкрементальное тестирование

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

Этот этап касается определения системных требований и понимания системных требований для построения модели сценария использования . Вариант использования — это сценарий, описывающий взаимодействие пользователя и компьютерной системы. Эта модель представляет пользовательские потребности или пользовательское представление системы.

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

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

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

макетирования

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

Это также может дать пользователям возможность прокомментировать удобство использования и полезность дизайна. Это может дополнительно определить сценарий использования и значительно упростить моделирование сценария использования.

Реализация

Он использует либо компонентную разработку (CBD), либо быструю разработку приложений (RAD).

Компонентно-ориентированная разработка (CBD)

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

Быстрая разработка приложений (RAD)

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

Его задача состоит в том, чтобы быстро и постепенно реализовать приложение, чтобы реализовать дизайн требований пользователя с помощью таких инструментов, как Visual Basic, Power Builder и т. Д.

Инкрементальное тестирование

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