Внутренняя объектная модель

из "Реинжиниринг бизнеса - Реинжиниринг организаций и информационные технологии "

П-модель - хорошее средство как для описания требований к бизнесу, гак и для представления наглядной картины того, что бизнес выполняет. П-модель иллюстрирует функции бизнеса, его окружение и бизнес-процессы, которые он предлагает внешнему миру. Тем не менее П-модель не дает ясной картины о внутреннем устройстве бизнеса, т.е. о том, как различные виды деятельности реализуют бизнес-процессы, как эти виды деятельности связываются вместе в цепочки процессов, какой вид ресурсов должен использоваться для реализации того или иного вида деятельности и т. д. Для более полного понимания бизнеса по крайней мере командой по реинжинирингу требуется описание его более полное чем то, которое дается П-моделью. [c.134]
Есть и другие аспекты бизнеса, которые не описываются П-моделью. Очевидно, что бизнес не должен заниматься ничем, что нельзя соотнести с бизнес-процессом неверно думать, что все, что надо выразить, можно выразить в терминах бизнес-процессов. Специалисты наблюдали много попыток бизнес-инжиниринга, когда пытались исказить понятие процесса так, чтобы этим словом можно было обозначить что угодно. Очевидно, что в расчет следует принимать не только требования, регулирующие бизнес-процессы, но и другие например, качество продукции (а не качества самого процесса), структура управления компанией, информация, сообщаемая сотрудникам компании. Можно называть все эти вещи процессами, но это не будет иметь особого смысла. Подобные аспекты будем описывать во внутренней модели. [c.135]
Используются два вида внутренних моделей идеальные или реальные. Идеальная модель - это модель, не учитывающая, как компания должна реализоваться на практике. Такая модель не учитывает, например, что компания географически распределена на несколько филиалов. Реальная модель учитывает все эти факторы. Она учитывает, что в настоящее время компания не располагает персоналом, имеющим уровень компетенции, предполагаемый идеальной моделью. Во многих случаях достаточно построить идеальную модель и предоставить самой компании возможность решать, как ей следует работать, чтобы приблизиться к реальной модели (см. гл. 7). [c.135]
В соответствии с современными тенденциями при описании внутренней модели будем базироваться на понятии объект , поэтому будем называть внутреннюю модель - О-моделью (объект-моделью). Заметим, что и П-модель (если позволяет инструментальное средство) естественно описывать, базируясь на объектном подходе. Использование объектов дает компании прочную архитектуру, которая понятна, поддается изменениям, адаптируема и может использоваться повторно (см. разд. 3.4 и 3.5). [c.135]
При описании О-модели объекты представляют участников процессов и различного рода сущности (продукция, предметы, задачи), используемые в ходе выполнения процессов. Имя, которое дается классу объектов, должно как можно более ясно выражать суть, свойственную экземплярам этого класса. Классам часто дают имена, состоящие из нескольких слов, так как ясность важнее, чем краткость. Имя модели должно быть уникальным, не следует давать классам -или чему-либо еще - похожие имена. Имена классов, как правило, выражаются существительными. [c.135]
Пример. При описании внутренней 0-модели для бизнес-системы Ресторан уместно ввести по крайней мере следующих участников Гардеробщик, Официант и Повар. (На самом деле этот перечень не полон. В зависимости от моделируемых задач могут потребоваться такие участники, как бухгалтер, уборщица и т.п.). К сущностям, используемым в ходе бизнеса, следует отнести Меню и Заказанные блюда (для краткости - Заказ). Итак, для описания бизнес-системы Ресторан вводим следующие классы объектов Гардеробщик, Официант, Повар, Меню и Заказ (рис. 5.3). [c.136]
Объект может соответствовать задачам, продукции или сущностям в бизнесе. Задачи могут быть подразделены на два типа те, что обеспечивают взаимодействие субъектов с бизнесом, и те, которые являются чисто внутренними. Удобно определить различные типы объектов, для того чтобы сделать более ясными задачи, которые они выполняют в модели. Обычно различают следующие типы объектов объекты-сущности, управляющие объекты и интерфейсные объекты. Все классы объектов будем изображать в виде треугольников с добавлением букв внутри треугольника (см. рис.5.3) и - интерфейсные, у - управляющие. [c.136]
Интерфейсные и управляющие объекты представляют задачи, а не типы ресурсов. С другой стороны, эти задачи выполняются людьми, относящимися к определенной категории ресурсов. В ресторане задача по приготовлению пищи выполняется человеком, обученным готовить (поваром). Часто, однако, несколько задач помещаются вместе в один объект, который реализуется одним конкретным экземпляром ресурса. Например, официант может отвечать как за размещение посетителей за столиками, так и за обслуживание посетителей. [c.136]
Интерфейсные объекты представляют в бизнесе операции, каждая из которых должна выполняться одним и тем же ресурсом. Эта задача включает взаимодействие с окружением бизнеса. Следовательно, к коммуникабельности людей, выполняющих эту задачу, предъявляются определенные требования. [c.137]
Интерфейсный объект может участвовать в нескольких прецедентах. Часто объекты этого типа несут ответственность за координацию процесса в той его части, которая касается непосредственного контакта с клиентами. Каждый конкретный клиент должен иметь как можно меньше контактов с компанией. Это, впрочем, не противоречит бизнес-теориям, которые рекомендуют работникам компании быть ближе к клиенту, а просто означает, что в интересах клиента его контакты с компанией должны быть как можно проще и реже. [c.137]
Можно сказать, что часть бизнеса, имеющая непосредственный контакт с внешним миром, видима как интерфейсные объекты, в то время как объекты-сущности и управляющие объекты более независимы от окружения. [c.137]
Управляющие объекты, как и интерфейсные объекты, представляют операции в бизнесе. Различие заключается в том, что эти операции не имеют непосредственного контакта с окружением бизнеса. Название управляющий объект используется потому, что эти объекты активны, они управляют или принимают участие в потоке управления при обработке продукции. Следовательно, экземпляр управляющего объекта часто имеет то же время жизни, что и экземпляр прецедента, в котором он участвует. Типичные примеры управляющих объектов в компании - это Разработчик Продукции и Менеджер Проекта. [c.137]
Отношение ссылки между объектами. При обслуживании клиентов естественно иметь возможность определить для каждого конкретного заказа, какие счета ему соответствуют. Следовательно, объект Заказ должен содержать одну или более ссылок на экземпляры объекта Счет. Ссылка такого вида между объектами обозначается отношением ссылки. Отношение ссылки между объектом А и объектом В определяет тип отношения между А и В. С отношением можно связать количество экземпляров, которые могут быть с ним ассоциированы. В примере, представленном на рис. 5.4, отношение ссылки называется способ оплаты и указано, что по заказу может быть выписано как 0 счетов, если еда (заказ) доставляется на дом, так и несколько, если посетители хотят по одному заказу платить отдельно. [c.138]
Обычный способ именования отношений таков, что цепочка объект - отношение - объект может иметь словесное выражение. Так как названия классов обычно существительные, то имена отношений при этом способе будут глаголами. Например, из последовательности Заказ - Готовит - Повар можно построить фразу Заказ готовится поваром . [c.138]
Однако в [5] предлагается использовать другой способ именования отношений - имя отношения, связывающего А с В, где отношение играет роль объекта В по отношению к объекту А. Таким образом, имя отношения выражается примерно так, как показано на рис. 5.5 Заказ - ответственный за приготовление - Повар , что читается следующим образом Повар отвечает за приготовление заказа . [c.138]
Данный способ именования отношения объясняется двумя причинами. [c.139]
О В объектно-ориентированном мире все рассматривается с точки зрения объекта. В этом мире естественно спросить Как один объект зависит от других объектов Ответ на этот вопрос может дать понятие о ролях, которые другие объекты играют по отношению к данному. Следовательно, вполне логично давать отношениям имена, отражающие их роли. Также можно сказать, что объект А предъявляет требования к ролям, которые другие объекты должны играть по отношению к А. Однако этим объектам вовсе не обязательно знать, кто или какие предъявляет к ним требования. Таким образом, отношения обычно действуют в одном направлении. [c.139]
Агрегаты объектов. Отношения, называемые состоит из и является частью , представляют собой варианты отношения ссылки. Они используются для выражения того, что объект состоит из других объектов. Конструкция такого типа называется агрегатом. Отношение состоит из связывает объект А с объектом Б и указывает, что А состоит из объектов типа Б (рис. 5.6). Отношение является частью выражает обратную ситуацию, т. е. объекты типа Б являются частью объектов типа А. Как правило, отношения состоит из , является частью существуют между экземплярами. [c.139]

Вернуться к основной статье