Прецеденты и объекты

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

П-модель и О-модель - это разные типы описания бизнеса. О-мо-дель, состоящая из сотен объектов и более, неудобна для работы и малопонятна, так как слишком сложна. Она содержит детали того, как объекты связаны друг с другом, как они общаются, какой интерфейс используют, что они знают друг о друге и т. д. Информация такого рода делает любое описание слишком детальным, и есть риск, что больше энергии будет тратиться на объяснение внутреннего взаимодействия, чем на понимание бизнес-процессов. Конечно, информация такого рода очень важна при создании подробных моделей бизнес-систем, однако она не обязательна для понимания прецедентов. [c.143]
Как указывают многие специалисты [7], [8], выявлять объекты для модели не сложно, сложно находить правильные объекты. Рекомендуется для каждого прецедента определить объекты, необходимые для его выполнения. Если в объектную модель включать объекты, принимающие участие в различных прецедентах, то будет больше шансов определить действительно нужные объекты. Рассмотрев все прецеденты, в которых некоторый объект играет какие-либо роли, можно понять назначение этого объекта в системе [10]. [c.143]
Пример. Прецеденты Обслуживание Завтрака, Обслуживание Обеда или Ужина, Обслуживание Мероприятия, Поставка Продуктов используют набор объектов. Некоторые объекты принимают участие в нескольких прецедентах например, Повар участвует во всех. Назначение объекта Повар проявляется при рассмотрении всех прецедентов, в которых он используется. [c.143]
Если необходимо более подробно показать, как объекты взаимодействуют при выполнении прецедентов, то для этого привлекают, например, диаграммы взаимодействий (см. подразд. 5.4.2). [c.144]
Более того, именно посредством объектов прецеденты воздействуют друг на друга. Два экземпляра прецедента одного или двух разных классов могут быть реализованы при помощи одного и того же экземпляра объекта. В описанном выше примере управляющий объект Повар участвует во всех четырех прецедентах. Вследствие этого могут возникнуть конфликты. Например, если Повар участвует в двух последовательных действиях при Обслуживании Завтрака, то его не следует использовать в перерыве в прецеденте Поставка Продуктов, если есть какой-либо риск возникновения несогласованности. Следовательно, транзакцию в прецеденте необходимо рассматривать как целое, и не следует ее прерывать или разделять. [c.144]
Другой вид конфликта может возникнуть при использовании одного экземпляра объекта-сущности двумя различными экземплярами прецедентов. Если, например, некоторый документ представлен как объект-сущность и этот документ участвует в нескольких экземплярах прецедентов, должно быть ясно указано, кто несет за него ответственность, т.е. имеет право изменять состояние экземпляра. Пример с рестораном, однако, не демонстрирует эту проблему. Она возникает, когда объекты-сущности являются носителями информации, например, объект Счет в модели банка и т.п. [c.144]
Взаимодействие объектов в прецеденте (рис. 5.9) отображает динамику объектной модели. Этот тип представления содержит, помимо объектов, отношения коммуникации, необходимые для выполнения прецедента. Чтобы объяснить, кто и как инициирует потоки событий, необходимо включить в представление субъекты и отношения, связывающие субъекты с объектами. [c.144]
Так как объект участвует в нескольких прецедентах, он будет присутствовать в нескольких представлениях взаимодействия объектов. Вместе эти представления иллюстрируют различные роли, которые объект имеет в системе. Иначе говоря, каждый прецедент, в котором участвует объект, накладывает на него обязательства (ответственность). [c.144]
Объект Гардеробщик спрашивает Посетителя, желает ли тот сдать пальто. Как вариант Посетитель сам может проинформировать Гардеробщика о своем желании. После этого Посетителя встречает Главный Официант, который сажает его за столик в соответствии с Планом Размещения. Затем Главный Официант вызывает Официанта, который будет обслуживать Посетителя. Официант дает Посетителю меню или на словах описывает, что сегодня подают. Предложенные варианты соответствуют текущему экземпляру объекта Меню. [c.145]
Официант заносит заказ посетителя в новый экземпляр объекта Заказ. Затем Официант создает новый экземпляр объекта Счет. Официант информирует экземпляр объекта Повар о том, что поступил новый заказ. [c.145]
Объект Повар готовит различные блюда в соответствии с Рецептами. Он также достает из холодильника заказанные Напитки. [c.145]
Когда еда готова, Повар информирует об этом Официанта, обслуживающего Посетителя. Когда Посетитель кончает есть, ожидается, что он сообщит это некоторому экземпляру объекта Официант. [c.145]
Официант обновляет объект Счет и представляет его Посетителю. Ожидается, что Посетитель заплатит. Затем Посетитель просит объект Гардеробщик вернуть оставленные на хранение вещи и покидает ресторан. На этом прецедент завершается. [c.145]
Если необходимо более подробно описать, как при выполнении потока событий взаимодействуют объекты модели, можно построить диаграмму взаимодействий (см., например, [5]). Эта диаграмма показывает, как взаимодействующие объекты реализуют прецедент. При этом идентифицируются стимулы, передаваемые между объектами, и параметры этих стимулов, т.е. идентифицируются протоколы взаимодействия объектов. [c.146]
В диаграмме взаимодействий объект представляется вертикальным столбцом (рис. 5.10). Порядок расположения столбцов неважен, их просто следует размещать так, чтобы все выглядело нагляднее. Если в прецеденте присутствует несколько экземпляров одного класса, каждый из них можно представить отдельным столбцом. Столбец чаще всего представляет экземпляр, но может представлять и класс. [c.146]
Ось времени в диаграмме взаимодействий идет сверху вниз. Ее не следует понимать как линейную, она определяется стимулами. Другими словами, расстояние между двумя стимулами на диаграмме не имеет ничего общего с интервалом времени между событиями. [c.146]
С левой стороны диаграммы взаимодействий обычно описывают поведение, выполняемое объектами (пути операций). В столбцах пути операций представляются жирными вертикальными отрезками. Описания путей операций дают основу для идентификации и описания операций объектов. Не всегда практично делать описания всех путей операций, так как структура текста на полях может стать слишком сложной. В нашем примере описаны пути операций только для интерфейсных и управляющих объектов, так как именно в этих объектах обрабатываются стимулы. [c.146]
Посетитель входит в ресторан. [c.147]
Проверяется план размещения посетителей. [c.147]

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