П-модель — хорошее средство как для описания требовании бизнесу, так и для представления наглядной картины того, что бизнес выполняет. П-модель иллюстрирует функции бизнеса, его окружение и бизнес-процессы, которые он предлагает внешнему миру. Тем не менее П-модель не дает ясной картины о внутреннем устройстве бизнеса, т.е. о том, как различные виды деятельности реализует бизнес-процессы, как эти виды деятельности связываются вместе цепочки процессов, какой вид ресурсов должен использоваться до реализации того или иного вида деятельности и т. д. Для более полного понимания бизнеса по крайней мере командой по реинжинирингу требуется описание его более полное чем то, которое дается П — моделью.
В соответствии с современными тенденциями при описании внутренней модели будем базироваться на понятии «объект», поэтому будем называть внутреннюю модель — 0-моделью (объект-моделью). Заметим, что и П-модель (если позволяет инструментальное средство) естественно описывать, базируясь на объектном подходе. Использование объектов дает компании прочную архитектуру, которая понятна, поддается изменениям, адаптируема и может использоваться повторно.
При описании О-модели объекты представляют участников процессов и различного рода сущности (продукция, предметы, задачи), используемые в ходе выполнения процессов. Имя, которое дается классу объектов, должно как можно более ясно выражать суть, свойственную экземплярам этого класса. Классам часто дают имена, состоящие из нескольких слов, так как ясность важнее, чем краткость. Имя модели должно быть уникальным, не следует давать классам или чему-либо еще — похожие имена. Имена классов, как правило, выражаются существительными.
Пример. При описании внутренней О-модели для бизнес-системы Ресторан уместно ввести по крайней мере следующих участников: Гардеробщик, Официант и Повар. (На самом деле этот перечень не полон. В зависимости от моделируемых задач могут потребоваться такие участники, как бухгалтер, уборщица и т.п.).
К сущностям, используемым в ходе бизнеса, следует отнести Меню и Заказанные блюда (для краткости — Заказ). Итак, для описания бизнес-системы Ресторан вводим следующие классы объектов: Гардеробщик, Официант, Повар, Меню и Заказ (рис. 1.3).
Объект может соответствовать задачам, продукции или сущностям в бизнесе. Задачи могут быть подразделены на два типа: те, что обеспечивают взаимодействие субъектов с бизнесом, и те, которые являются чисто внутренними. Удобно определить различные типы объектов, для того чтобы сделать более ясными задачи, которые они выполняют в модели. Обычно различают следующие типы объектов: объекты-сущности, управляющие объекты и интерфейсные объекты. Все классы объектов будем изображать в виде треугольников с добавлением букв внутри треугольника (см. рис.1.3): и — интерфейсные, у — управляющие.
Интерфейсные и управляющие объекты представляют задачи, а не типы ресурсов. С другой стороны, эти задачи выполняются людьми, относящимися к определенной категории ресурсов. В ресторане задача по приготовлению пищи выполняется человеком, обученным готовить (поваром).
Часто, однако, несколько задач помещаются вместе в один объект, который реализуется одним конкретным экземпляром ресурса. Например, официант может отвечать как за размещение посетителей за столиками, так и за обслуживание посетителей. Интерфейсные объекты представляют в бизнесе операции, каждая из которых должна выполняться одним и тем же ресурсом. Эта задача включает взаимодействие с окружением бизнеса. Следовательно, к коммуникабельности людей, выполняющих эту задачу, предъявляются определенные требования.
Интерфейсный объект может участвовать в нескольких прецедентах. Часто объекты этого типа несут ответственность за координацию процесса в той его части, которая касается непосредственного контакта с клиентами. Каждый конкретный клиент должен иметь как можно меньше контактов с компанией. Это, впрочем, не противоречит бизнес-теориям, которые рекомендуют работникам компании быть ближе к клиенту, а просто означает, что в интересах клиента его контакты с компанией должны быть как можно проще и реже.
Можно сказать, что часть бизнеса, имеющая непосредственный контакт с внешним миром, видима как интерфейсные объекты, в то время как объекты-сущности и управляющие объекты более независимы от окружения.
Управляющие объекты, как и интерфейсные объекты, представляют операции в бизнесе. Различие заключается в том, что эти операции не имеют непосредственного контакта с окружением бизнеса. Название «управляющий объект» используется потому, что эти объекты активны, они управляют или принимают участие в потоке управления при обработке продукции. Следовательно, экземпляр управляющего объекта часто имеет то же время жизни, что и экземпляр прецедента, в котором он участвует. Типичные примеры управляющих объектов в компании — это Разработчик Продукции и Менеджер Проекта.
Объекты-сущности представляют такие сущности, как продукция и предметы, которые обрабатываются бизнесом. Объект-сущность участвует не только в одном прецеденте; экземпляр может принимать участие во многих событиях в бизнесе. В отличие от интерфейсных и управляющих объектов, объекты-сущности представляют сущности, не являющиеся человеческими или техническими ресурсами. Типичные примеры объектов-сущностей в компании -Продукция, Извещение (Invoice) и Заказ.
П — модель и О — модель это разные типы описания бизнеса. О — модель, состоящая из сотен объектов и более неудобна для работы и малопонятна, так как слишком сложна. Она содержит детали того, как объекты связаны друг с другом, как они общаются, какой интерфейс используют, что они знают друг о друге и т.д. Информация такого рода делает такое описание слишком детальным, и есть риск, что больше энергии будет тратиться на объяснения внутреннего взаимодействия, чем на понимание бизнес — процессов. Конечно, информация такого рода очень важна при создании подробных моделей бизнес-систем, однако она не обязательна для понимания прецедентов.
Как указывают многие специалисты, выявлять объекты для модели не сложно, сложно находить правильные объекты. Рекомендуется для каждого прецедента определить объекты, принимающие участие в различных прецедентах, то будет больше шансов определить действительно нужные объекты. Рассмотрев все прецеденты, в которых некоторый объект играет какие-либо роли, можно понять назначение этого объекта.
Пример: Прецеденты обслуживания завтрака, обслуживания обеда или ужина, обслуживания мероприятия, поставка продуктов используют набор объектов. Некоторые объекты принимают участие нескольких прецедентах например: Повар участвует во всех. Назначение объекта повар проявляется при рассмотрении всех прецедентов, в которых он используется.
Если необходимо более подробно показать, как объекты взаимодействуют при выполнении прецедентов, то для этого привлекаю например, диаграммы взаимодействий. Более того, именно посредством объектов прецеденты воздействуют друг на друга. Два экземпляра прецедента одного или двух разных классов могут быть реализованы при помощи одного и то] же экземпляра объекта.
В описанном выше примере управляющего объект Повар участвует во всех четырех прецедентах. Вследствие этого могут возникнуть конфликты. Например, если Повар участвует в двух последовательных действиях при Обслуживании Завтрак то его не следует использовать в перерыве в прецеденте Поставки Продуктов, если есть какой-либо риск возникновения несогласованности.
Следовательно, транзакцию в прецеденте необходимо рассматривать как целое, и не следует ее прерывать или разделять. Другой вид конфликта может возникнуть при использован) одного экземпляра объекта-сущности двумя различными экземплярами прецедентов. Если, например, некоторый документ представлен как объект-сущность и этот документ участвует в нескольких экземплярах прецедентов, должно быть ясно указано, кто несет за него ответственность, т.е. имеет право изменять состояние экземпляр Пример с рестораном, однако, не демонстрирует эту проблему. О) возникает, когда объекты-сущности являются носителями информации, например, объект Счет в модели банка и т.п.
Источник: vuzlit.com
Операции в бизнесе которые не имеют непосредственного контакта с окружением бизнеса это
106. Объектом реинжиниринга является:
• бизнес-процессы
107. Одним из ключевых элементов реинжиниринга бизнеса являются:
• информационные технологии
108. Операции в бизнесе, каждая из которых должна выполняться одним и тем же ресурсом, — это __________________ объекты.
• интерфейсные
109. Операции в бизнесе, которые не имеют непосредственного контакта с окружением бизнеса — это __________________ объекты.
• управляющие
110. Описание основного потока событий или альтернативных потоков — это описание .
• каждого прецедента
111. Описание того, как новый бизнес будет реализовывать прецеденты, — это __________________ объектных моделей.
• цель
112. Описание того, что новый бизнес должен предложить окружению, — это __________________ П-модели.
• цель
113. Описание традиционного подхода к управлению поведением работников дают «теория х» и «теория у»:
• Д. Макгрегора
114. Описания всех субъектов, прецедентов и отношений между ними — это описание модели .
• общее
115. Описания конкретного продукта или услуги, производимого компанией, включаются в блок средств моделирования архитектуры компании, именуемый блоком
• элементарных объектов компании
116. Описания концепции, синтаксиса и семантики языков моделирования, а также методологий их применения и процессов построения этих языков и методологий, включаются в блок средств моделирования архитектуры компании, именуемый блоком
• языков метамоделирования и метаметодологий
117. Определение общей стратегии по реинжинирингу и контроль за выполнением работ по проекту — основная цель
• руководящего комитета
118. Определяет процесс
• владелец процесса
119. Освоение рынков, повышение конкурентного статуса компании, создание стойкого спроса на продукцию, расширение доли рынка — это стратегическая цель следующей функциональной подсистемы компании .
• маркетинг
120. Основная задача __________________ проектирования — определить, как структурировать информационную систему, чтобы обеспечить простоту модификации системы при изменении функциональных требований к ней.
• идеального
Источник: oltest.ru
Внутренняя модель бизнес-системы
Внутренняя модель – объект-модель (О-модель). Она описывает, как строится каждый бизнес-процесс предприятия из различных рабочих задач (внутренних процессов) и какие ресурсы он использует. Внутренняя модель использует объекты, соответствующие рабочим задачам, и объекты, соответствующие предметам бизнеса, например продукцию. Если прецеденты выражают, что бизнес должен делать, то внутренняя модель описывает, как бизнес работает. Таким образом, П-модель – есть «что модель», а О-модель – «как модель», представляющая собой UML-диаграммы классов и взаимодействия.
Используются два вида внутренних моделей: идеальные и реальные. Идеальная О-модель – это модель, не учитывающая, как бизнес должен реализоваться на практике. Такая модель не учитывает, например, что предприятие (фирма) географически распределена на несколько филиалов. Реальная О-модель учитывает эти факторы.
Она учитывает, что в настоящее время предприятие не располагает персоналом, имеющим уровень компетенции, предполагаемый идеальной моделью. Во многих случаях достаточно построить идеальную модель и предоставить предприятию возможность решать, как следует работать, чтобы приблизиться к реальной модели.
При описании О-модели объекты представляют участников процессов и различного рода сущности (продукция, предметы, задачи), используемые в ходе их выполнения. Следует различать класс объектов и экземпляр класса (объект). Имя, которое дается классу объектов, должно как можно более ясно выражать суть свойственную экземплярам этого класса, т.е. объектам. Классам часто дают имена, состоящие из нескольких слов (как правило, существительных), так как ясность важнее, чем краткость.
Объект может соответствовать задачам, продукции или сущностям в бизнесе. Задачи могут быть подразделены на два типа: те, что обеспечивают взаимодействие субъектов с бизнесом, и те, которые являются чисто внутренними. Удобно определить различные типы объектов, для того чтобы сделать более ясными задачи, которые они выполняют в модели.
Например, А. Якобсон [97] предлагает различать следующие типы объектов: объекты-сущности, управляющие объекты и интерфейсные объекты. При этом интерфейсные и управляющие объекты представляют задачи, а не типы ресурсов. С другой стороны, эти задачи выполняются людьми, относящимися к определенной категории ресурсов. Часто, однако, несколько задач помещаются вместе в один объект, который реализуется одним конкретным экземпляром ресурса.
Интерфейсные объекты представляют в бизнесе операции, каждая из которых должна выполняться одним и тем же ресурсом. Эта задача включает взаимодействие с окружением бизнеса. Следовательно, к коммуникабельности людей, выполняющих эту задачу, предъявляются определенные требования.
Интерфейсный объект может участвовать в нескольких прецедентах. Часто объекты этого типа несут ответственность за координацию процесса в той его части, которая касается непосредственного контакта с клиентами. Каждый конкретный клиент должен иметь как можно меньше контактов с предприятием. Это, впрочем, не противоречит теориям, которые рекомендуют работникам предприятия быть ближе к клиенту, а просто означает, что в интересах клиента его контакты с предприятием должны быть как можно проще и реже. Можно сказать, что часть бизнеса, имеющая непосредственный контакт с внешним миром, видима как интерфейсные объекты, в то время как объекты-сущности и управляющие объекты более независимы от окружения.
Управляющие объекты, как и интерфейсные объекты, представляют операции в бизнесе. Различие заключается в том, что эти операции не имеют непосредственного контакта с окружением бизнеса. Название «управляющий объект» используется потому, что эти объекты активны, они управляют или принимают участие в потоке управления при обработке продукции. Следовательно, экземпляр управляющего объекта часто имеет то же время жизни, что и экземпляр прецедента, в котором он участвует. Типичные примеры управляющих объектов на предприятии – это Разработчик и МенеджерПроекта.
Объекты-сущности представляют такие сущности, как продукция и предметы, которые обрабатываются бизнесом. Объект-сущность участвует не только в одном прецеденте. Один и тот же экземпляр может принимать участие во многих событиях в бизнесе. В отличие от интерфейсных и управляющих объектов, объекты-сущности представляют сущности, не являющиеся человеческими или техническими ресурсами. Типичные примеры объектов-сущностей: Продукция, Извещение (Invoice) и Заказ.
О-модель с помощью устанавливаемых между объектами отношений показывает, каким образом реализуются прецеденты, описанные в П-модели. Данные отношение связывают два объекта (экземпляра или класса) и изображаются стрелками (дугами). Изучая прецеденты, в которых участвует объект, можно получить представление об обязательствах объекта по отношению к его окружению. Поведение, описываемое в классе объекта, должно подтверждать эти обязательства. Если необходимо более подробно показать, как объекты взаимодействуют при выполнении прецедентов, то для этого привлекают диаграммы взаимодействий.
П-модель и О-модель – это разные типы описания бизнеса. О-модель, состоящая из сотен объектов и более, неудобна для работы и малопонятна, так как слишком сложна. Она содержит детали того, как объекты связаны друг с другом, как они общаются, какой интерфейс используют, что они знают друг о друге и т.д. Информация такого рода делает любое описание слишком детальным, и есть риск, что больше энергии будет тратиться на объяснение внутреннего взаимодействия, чем на понимание бизнес-процессов. Конечно, информация такого рода очень важна при создании подробных моделей бизнес-систем, однако она не обязательна для понимания прецедентов.
Как указывают многие специалисты, выявлять объекты для модели не сложно, сложно находить правильные объекты. Рекомендуется для каждого прецедента определить объекты, необходимые для его выполнения. Если в объектную модель включать объекты, принимающие участие в различных прецедентах, то будет больше шансов определить действительно нужные объекты. Рассмотрев все прецеденты, в которых некоторый объект играет какие-либо роли, можно понять назначение этого объекта в системе.
Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:
Источник: studopedia.ru