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

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

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

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

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

Язык UML включает в себя специальные механизмы расширения, которые позволяют ввести в рассмотрение дополнительные графические обозначения, ориентированные для решения задач из определенной предметной области. Например, известны бизнес‑расширения языка UML [15, 16] которые используют специальные обозначения на диаграммах вариантов использования: бизнес‑актер, сотрудник и бизнес‑вариант использования.

Бизнес-актер (business actor) – индивидуум, группа, организация, компания или система, которые взаимодействуют с моделируемой бизнес-системой, но не входят в нее, т.е. не являются частью моделируемой системы. Графическое изображение бизнес-актера приводится на рис. 3.19а. Примерами бизнес-актеров являются клиенты, покупатели, поставщики, партнеры. Общее свойство бизнес-актеров состоит в том, что они являются инициаторами или клиентами бизнес-процессов моделируемой системы.

Сотрудник (business worker) – индивидуум, который действует внутри моделируемой бизнес-системы, взаимодействует с другими сотрудниками и является участником бизнес-процесса моделируемой системы. Графическое изображение сотрудника приводится на рис. 3.19б. Примерами сотрудников являются менеджеры, администраторы, кассиры, инженеры. Общее свойство сотрудников заключается в том то, что они являются субъектами и входят в состав моделируемой системы.

Бизнес-вариант использования (business use case) – вариант использования, определяющий последовательность действий моделируемой системы, направленных на выполнение отдельного бизнес-процесса. Графическое изображение бизнес-варианта использования приведено на рис. 3.19в. Бизнес-варианты использования являются концептуальной моделью отдельных бизнес-процессов моделируемой системы.

Рис. 3.19. Графические изображения бизнес-актера (а), бизнес-сотрудника (б) и бизнес-варианта использования (в)

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

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

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

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

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

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

Рис. 3.20. Диаграмма вариантов использования для системы продажи товаров по каталогу в общих обозначениях языка UML

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

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

Последовательность проектирования информационной системы при использовании объектной методологии рассмотрим на примере технологии RUP – Rational Unified Process [17].

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

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

В результате изучения всех диаграмм последовательностей создаются классы. Классы создаются в три этапа.

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

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

На третьем этапе определяются отношения ассоциации между классами – они обеспечивают пересылки сообщений между соответствующими объектами.

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

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

Дальнейшая разработка информационной системы идет по технологии разработки программного обеспечения.