По бизнес-модели

Унифицированного процесса. Часть 1

Применение бизнес-моделирования для описания

Бизнес-моделирование применяется нами для описания процессов компании-клиента.

Тот же самый подход может быть использован для описываемого в этой книге

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

Когда мы описываем Унифицированный процесс разработки программ-__

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

главу 2). Такой подход имеет важное теоретическое значение, он также очень практичен.

Это своего рода раскрутка, применение метода к нему самому. Она показывает

сильные и слабые стороны такого подхода. Итак, Унифицированный процесс

— это бизнес-вариант использования, применяемый в промышленности создания

программного обеспечения. Внутри промышленности создания программного

обеспечения процесс организован, или, как мы говорим, «реализован» в виде

последовательности взаимозависимых рабочих процессов: определение требований

(обсуждаемое в этой главе и в главе 7), анализ (глава 8), проектирование (глава

9), реализация (глава 10) и тестирование (глава 11). Каждый рабочий процесс —

это реалР1зация части бизнес-варианта использования Унифицированный процесс,

который описан в понятиях:

О сотрудников — например, системных аналитиков и определителей вариантов

использования;

О бизнес-суш[ностей, или, как мы их называем, артефактов — например, вариантов

использования и тестовых примеров;

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

вариантов использования и описания архитектуры.

Сотрудники, бизнес-объекты и рабочие модули Унифицированного процесса

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

Поиск вариантов использования

Используя в качестве исходных данных бизнес-модель, аналитик применяет для

создания модели вариантов использования системный подход.

Сначала аналитик идентифицирует актантов для каждого сотрудника и участника

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

системой.

Пример. Актант — Покупатель. Покупатель использует Биллинговую и Платежную

систему для заказа товаров или услуг и оплаты счетов. Таким образом,

покупатель является как потребителем, так и актантом, потому что использует

платежную систему для заказа и платежей в двух вариантах использования — Заказ

Товаров или Услуг и Оплата счетов.

В информационной системе должен поддерживаться каждый сотрудник (и бизнес-

актант), который будет ее пользователем. Мы определим, какая необходима

поддержка, перебирая всех сотрудников по одному. Для каждого сотрудника мы

должны опознать все бизнес-варианты испол^>зования, в которых он участвует. Для

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

роль, будет существовать реализация варианта использования, в которой эту роль

будет выполнять соответствующий класс.

После того как мы нашли все роли сотрудников или бизнес-актантов, по одной

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

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

сотруднику и участнику бизнеса соответствует актант информационной системы.

Для каждой роли сотрудника или участника бизнеса необходим соответствующий

вариант использования для актанта.__

Таким образом, наиболее естественный способ определить пробный набор вариантов

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

актанта для каждой роли каждого сотрудника или бизнес-актанта.

В результате для любого бизнес-варианта использования будет существовать

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

Аналитики могут затем заниматься детализацией и приведением этих пробных

вариантов использования в порядок.

Аналитики должны также решить, какие из задач сотрудников или участников

бизнеса должны быть автоматизированы информационной системой (в виде вариантов

использования), и реорганизовать варианты использования так, чтобы они

лучше соответствовали потребностям этих лиц. Заметим, что для автоматизации

пригодны не все задачи.

Пример. Определение вариантов использования по бизнес-модели. В продолжение

предшествующего примера мы можем предложить пробный вариант использования

Покупка Товаров или Услуг, которые будут основаны на действиях актанта-

покупателя, выступающего в качестве бизнес-актанта в бизнес-варианте использования

Продажа: От Заказа до Поставки. В ходе дальнейшего анализа становится

очевидно, что Закупку Товаров или Услуг лучше реализовать в виде нескольких

различных вариантов использования, например Заказ Товаров или Услуг или Оплата

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

меньшие варианты использования состоит в том, что покупатель не хочет вы-

полршть вариант использования Покупка Товаров или Услуг в виде одной непрерывной

последовательности действий. Вместо этого он желает дождаться поставки

товаров или услуг, а потом уже оплачивать счет. Последовательность действий

по оплате счета, следовательно, представляется в виде отдельного варианта использования

Оплата Счета, который выполняется после того, как заказанное будет

поставлено.

Итак, мы рассмотрели, как моделировать контекст системы, используя модель

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

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

функциональные требования к системе и большую часть нефункциональных. Некоторые

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

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