Введение
Принципиальное различие между структурным и объектно-ориентированным подходом заключается в способе декомпозиции системы. Объектно-ориентированный подход использует объектную декомпозицию, при этом статическая структура системы описывается в терминах объектов и связей между ними, а поведение системы описывается в терминах обмена сообщениями между объектами. Каждый объект системы обладает своим собственным поведением, моделирующим поведение объекта реального мира. Понятие "объект" впервые было использовано около 30 лет назад в технических средствах при попытках отойти от традиционной архитектуры фон Неймана и преодолеть барьер между высоким уровнем программных абстракций и низким уровнем абстрагирования на уровне компьютеров. С объектно-ориентированной архитектурой также тесно связаны объектно-ориентированные операционные системы. Однако наиболее значительный вклад в объектный подход был внесен объектными и объектно-ориентированными языками программирования: Simula, Smalltalk, C++, Object Pascal. На объектный подход оказали влияние также развивавшиеся достаточно независимо методы моделирования баз данных, в особенности подход "сущность-связь".

Концептуальной основой объектно-ориентированного подхода является объектная модель. Основными ее элементами являются:

* абстрагирование (abstraction);

* инкапсуляция (encapsulation);

* модульность (modularity);

* иерархия (hierarchy).

Кроме основных имеются еще три дополнительных элемента, не являющихся в отличие от основных строго обязательными:

* типизация (typing),

* параллелизм (concurrency),

* устойчивость (persistence).

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

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

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

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

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

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

Устойчивость - свойство объекта существовать во времени (вне зависимости от процесса, породившего данный объект) и/или в пространстве (при перемещении объекта из адресного пространства, в котором он был создан).

2. Основные понятия объектно-ориентированного подхода - объект и класс
Объект определяется как осязаемая реальность (tangible entity) - предмет или явление, имеющие четко определяемое поведение. Объект обладает состоянием, поведением и индивидуальностью; структура и поведение схожих объектов определяют общий для них класс. Термины "экземпляр класса" и "объект'' являются эквивалентными. Состояние объекта характеризуется перечнем всех возможных (статических) свойств данного объекта и текущими значениями (динамическими) каждого из этих свойств. Поведение характеризует воздействие объекта на другие объекты и наоборот относительно изменения состояния этих объектов и передачи сообщений. Иначе говоря, поведение объекта полностью определяется его действиями. Индивидуальность - это свойства объекта, отличающие его от всех других объектов.

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

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

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

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

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

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

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

Унифицированный язык моделирования UML (Unified Modeling Language) - это преемник того поколения методов ООАП, которые появились в конце 80-х и начале 90-х гг. Создание UML фактически началось в конце 1994 г., когда Гради Буч и Джеймс Рамбо начали работу по объединению методов Booch и ОМТ (Object Modeling Technique) под эгидой компании Rational Software. К концу 1995 г. они создали первую спецификацию объединенного метода, названного ими Unified Method, версия 0.8. Тогда же, в 1995 г., к ним присоединился создатель метода OOSE (Object-oriented Software Engineering) Ивар Якобсон.

Таким образом, UML является прямым объединением и унификацией методов Буча, Рамбо и Якобсона, однако дополняет их новыми возможностями. Главными в разработке UML были следующие цели:

* предоставить пользователям готовый к использованию выразительный язык визуального моделирования, позволяющий разрабатывать осмысленные модели и обмениваться ими;

* предусмотреть механизмы расширяемости и специализации для расширения базовых концепций;

* обеспечить независимость от конкретных языков программирования и процессов разработки;

* обеспечить формальную основу для понимания этого языка моделирования;

(язык должен быть одновременно точным и доступным для понимания, без лишнего формализма);

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

4. Виды диаграмм

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

* ассоциации (например, клиент может сделать заказ);

* подтипы (частный клиент является разновидностью клиента).

Рис.1 Диаграмма классов

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

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

Построение диаграмм классов можно рассматривать в различных аспектах:

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

аспект спецификации - модель спускается на уровень ПО, но рассматриваются только интерфейсы, а не программная реализация классов (под интерфейсом здесь понимается набор операций класса, видимых извне);

аспект реализации - модель действительно определяет реализацию классов ПО. Этот аспект наиболее важен для программистов.

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

При построении диаграммы необходимо выбрать единственный аспект. При чтении диаграммы следует выяснить, в соответствии с каким аспектом она строилась. Если нужно интерпретировать эту диаграмму правильным образом, то без такого знания не обойтись.

Точка зрения на диаграммы классов, не будучи собственно формальной частью UML, однако при построении и анализе моделей является крайне важной. Конструкции UML можно использовать с любой из трех точек зрения. Большинство опытных разработчиков-программистов предпочитают аспект реализации. С другой стороны, очевидно, что построение диаграмм классов на стадии формирования требований к ПО должно выполняться с концептуальной точки зрения.

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

Ассоциации представляют собой связи между экземплярами классов (личность работает в компании, компания имеет ряд офисов).

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

Каждая ассоциация обладает двумя ролями; каждая роль представляет собой направление ассоциации. Таким образом, ассоциация между Клиентом и Заказом содержит две роли: одна от Клиента к Заказу, другая - от Заказа к Клиенту.

Роль может быть явно поименованная с помощью метки. Например, роль ассоциации в направлении от Заказа к Строкам заказа называется "позиция заказа". Если такая метка отсутствует, роли присваивается имя класс - цели - таким образом, роль ассоциации от Заказа к Клиенту может быть названа Клиент (термины "начало" (source) и "цель" (target) употребляются для обозначения классов, являющихся соответственно начальным и конечным для ассоциации).

4.2 Диаграмма взаимодействия
Диаграммы взаимодействия (interaction diagrams) являются моделями, описывающими поведение взаимодействующих групп объектов.

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

Проиллюстрируем данный подход на примере достаточно простого варианта использования, который описывает следующее поведение:

Окно Ввода Заказа посылает Заказу сообщение "приготовиться".

Заказ посылает данное сообщение каждой Строке заказа в данном Заказе.

Каждая Строка заказа проверяет состояние определенного Запаса товара:

Если данная проверка удовлетворяется (результат - true), то Строка заказа удаляет соответствующее количество товара из Запаса.

В противном случае количество Запаса снижается до уровня повторного заказа, и Запас запрашивает новую поставку товара.

Существуют два вида диаграмм взаимодействия: диаграммы последовательности (sequence diagrams) и кооперативные диаграммы (collaboration diagrams).

На диаграмме последовательности объект изображается в виде прямоугольника на вершине пунктирной вертикальной линии (рис.2).

Эта вертикальная линия называется линией жизни (lifeline) объекта. Она представляет собой фрагмент жизненного цикла объекта в процессе взаимодействия. Такую форму представления впервые ввел Ивар Якобсон.

Рис.2 Диаграмма последовательности

Каждое сообщение представляется в виде стрелки между линиями жизни двух объектов. Сообщения появляются в том порядке, как они показаны на странице - сверху вниз. Каждое сообщение помечается, как минимум, именем сообщения; при желании можно добавить также аргументы и некоторую управляющую информацию и, кроме того, можно показать само делегирование (self-delegation) - сообщение, которое объект посылает самому себе, при этом стрелка сообщения указывает на ту же самую линию жизни.

Из всей возможной управляющей информации два ее вида имеют существенное значение. Во-первых, это условие, показывающее, когда посылается сообщение (например, [нуженПовторныйЗаказ = "true"]). Сообщение посылается только при выполнении данного условия. Другой полезный управляющий маркер - это маркер итерации, показывающий, что сообщение посылается много раз для множества объектов-адресатов (например,* приготовиться).

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

Диаграмма (см. рис.2) содержит возврат, означающий не новое сообщение, а возврат из сообщения. На диаграмме возврат отличается от обычных сообщений тем, что его стрелка не сплошная, а имеет вид пары линий.

Диаграммы последовательности можно также использовать для представления параллельных процессов.

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

Рис.3 Параллельные процессы и активизации

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

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

* создавать новую ветвь процесса (в этом случае оно связано с самой верхней частью активизации);

* создавать новый объект;

* устанавливать связь с уже выполняющейся ветвью процесса.

Удаление объекта показано с помощью большого знака "X". Объекты могут выполнить самоуничтожение или могут быть уничтожены посредством еще одного сообщения.

Используя механизм активизации, можно более четко показать смысл само делегирования. Без них, или без такого обозначения с помощью столбиков, которое здесь используется, довольно трудно определить, где же выполняются следующие после само делегирования вызовы - то ли в вызывающем методе, то ли в вызываемом методе. Активизации вносят ясность в этот вопрос.

5. Пример использования объектно-ориентированного подхода

Рис.4 Начальная диаграмма вариантов использования

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

На начальной стадии (или стадии формирования требований) строится начальная диаграмма вариантов использования (рис.4).

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

* Кто использует систему непосредственно?

* Кто отвечает за эксплуатацию системы?

* Какое внешнее оборудование используется системой?

* Какие другие системы взаимодействуют с данной системой?

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

На стадии проектирования уточняется диаграмма вариантов использования и строится архитектура системы, основой которой являются диаграммы классов. В данном примере ограничимся построением диаграммы классов и диаграммы взаимодействия. Диаграммы взаимодействия строятся для уточнения диаграммы вариантов использования и перехода к диаграммам классов. Так, диаграмма последовательности (рис.5) иллюстрирует один из возможных сценариев развития событий в рамках варианта использования "Зарегистрировать налогоплательщика". Предполагается, что налогоплательщик ставится на учет впервые и все его документы в полном порядке.

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

* в описании исходных данных выделяются кандидаты в классы-существительные, которые потенциально могут соответствовать классам (при этом следует помнить, что существительные могут также относиться к объектам, ассоциациям или атрибутам классов);

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

Рис.5 Диаграмма последовательности для варианта использования "Зарегистрировать налогоплательщика"

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

Рис.6 Диаграмма классов предметной области

Определяются действия (операции), выполняемые каждым классом. При определении операций нужно учитывать следующие рекомендации:

* каждая операция должна выполнять одну простую функцию;

* название операции должно отражать результат функции, а не то, как она выполняется.

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

Полученная в результате диаграмма классов предметной области показана на рис.6

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