Внутренняя модель бизнес-системы

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

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

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

Объект может соответствовать задачам, продукции или сущностям в бизнесе. Задачи могут быть подразделены на два типа: те, что обеспечивают взаимодействие субъектов с бизнесом, и те, которые являются чисто внутренними. Удобно определить различные типы объектов, для того чтобы сделать более ясными задачи, которые они выполняют в модели. Например, А. Якобсон [97] предлагает различать следующие типы объектов: объекты-сущности, управляющие объекты и интерфейсные объекты. При этом интерфейсные и управляющие объекты представляют задачи, а не типы ресурсов. С другой стороны, эти задачи выполняются людьми, относящимися к определенной категории ресурсов. Часто, однако, несколько задач помещаются вместе в один объект, который реализуется одним конкретным экземпляром ресурса.

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

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

Управляющие объекты, как и интерфейсные объекты, представляют операции в бизнесе. Различие заключается в том, что эти операции не имеют непосредственного контакта с окружением бизнеса. Название «управляющий объект» используется потому, что эти объекты активны, они управляют или принимают участие в потоке управления при обработке продукции. Следовательно, экземпляр управляющего объекта часто имеет то же время жизни, что и экземпляр прецедента, в котором он участвует. Типичные примеры управляющих объектов на предприятии – это Разработчик и МенеджерПроекта.

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

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

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

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

Дата добавления: 2014-12-27