Файл: Visual Paradigm for UML.pdf

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

Данный подход к проектированию ИС подразумевает выполнение трех этапов:

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

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

Объектно-ориентированное программирование - методология программирования, предполагающая реализацию модели системы на объектно-ориентированном языке программирования, непосредственно выполняющего отражение определенных объектов и предоставляющего средства для определения классов объектов.

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

Каждый объект относится к некоторому объектному типу (классу), в котором определена внутренняя структура данных любого объекта данного класса, а также программный код методов объекта.

Основные принципы построения объектной модели:

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

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

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

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

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

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

Де-факто стандартом моделирования в рамках объектно-ориентированного подхода стал унифицированный язык моделирования UML (Unified Modeling Language).

Унифицированный язык моделирования UML — это визуальный язык для определения, конструирования и документирования систем.

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

Данный язык содержит следующий набор диаграмм:

1. Структурные (structural) модели:

диаграммы классов (class diagrams) - для моделирования статической структуры классов системы и связей между ними;
диаграммы компонентов (component diagrams) - для моделирования иерархии компонентов (подсистем) системы;
диаграммы размещения (deployment diagrams) - для моделирования физической архитектуры системы.

2. Модели поведения (behavioral):

диаграммы вариантов использования (use case diagrams) — для моделирования функциональных требований к системе (в виде сценариев взаимодействия пользователей с системой);
диаграммы взаимодействия (interaction diagrams): диаграммы последовательности (sequence diagrams) и кооперативные диаграммы (collaboration diagrams) — для моделирования процесса обмена сообщениями между объектами;
диаграммы состояний (statechart diagrams) — для моделирования поведения объектов системы при переходе из одного состояния в другое
диаграммы деятельности (activity diagrams) - для моделирования поведения системы в рамках различных вариантов использования, или потоков управления.

В целях адаптации UML к конкретным условиям использования, в него введен механизм расширения, что принципиально отличает его методологий структурного моделирования (семейство стандартов IDEF, DFD, STD и ERD). Структурные нотации относятся к сильно типизированным языкам моделирования, не допускающим произвольную интерпретацию семантики элементов моделей. UML, являясь слабо типизированным языком, такую интерпретацию допускает.

2. Преимущества и недостатки объектно-ориентированного подхода к проектированию

2.1. Преимущества объектно-ориентированного подхода к проектированию

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

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

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

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

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

- Мы сокращаем время на разработку, которое с выгодой может быть отдано другим проектам.

- Компоненты многоразового использования обычно содержат гораздо меньше ошибок, чем вновь разработанные, ведь они уже не раз подвергались проверке.

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

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

2.2. Недостатки объектно-ориентированного подхода к проектированию

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

Объектно-ориентированное программирование требует знания четырех вещей.

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

(2) Многоразовое использование требует от программиста познакомиться с большими библиотеками классов. А это может оказаться сложнее, чем даже изучение нового языка программирования. Библиотека классов фактически представляет собой виртуальный язык, который может включать в себя сотни типов и тысячи операций. В языке Smalltalk, к примеру, до того, как перейти к практическому программированию, нужно изучить значительную часть его библиотеки классов. А это тоже требует времени.