Диаграммы взаимодействия

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

Продавец проверяет наличие требуемого Продукта на складе, затем принимает деньги за него и сообщает Отправителю количество Продукта и адрес Клиента. [c.195]
Продавец получав информацию о заказе и передает Проектировщику. Проектировщик модифицирует Продукт в соответствии с требованиями Клиента, продавец сообщает Отправителю количество Продукта и адрес Клиента. [c.195]
В левой части диаграммы находятся описания прецедентов Продажа Готового Продукта и Продажа Заказного Продукта в том виде, как они приведены в П-модели. Эти описания не претендуют на полноту, они просто демонстрируют, как прецедент накладывает требования на участвующие в его выполнении объекты. В правой части диаграммы можно увидеть, как описания этих прецедентов выглядят в объектной модели. [c.196]
Так как прецедент часто включает несколько альтернативных потоков событий, то обычно из практических соображений описания разбивают на несколько диаграмм взаимодействия. Каждая диаграмма получает уникальное имя для каждого прецедента. В одной диаграмме взаимодействия описывается основной поток событий, а все альтернативные потоки для облегчения понимания - в отдельных диаграммах. [c.196]
Только после того, как нарисованы диаграммы взаимодействия для потоков событий всех прецедентов, можно быть уверенным в том, что все роли, которые играет данный объект в системе, и, следовательно, его обязательства (ответственность) выявлены. На рис. 7.7 показано, как требования диаграммы взаимодействия (рис. 7.6) влияют на объект Продавец. [c.196]
При распределении ответственности между людьми, осуществляющими разработку прецедента, и специалистами, которые отвечают за разработку объектов, участвующих в этом прецеденте, могут возникнуть трудности. Диаграмма взаимодействия - это часть документации по прецеденту, поэтому ее должен строить тот, кто отвечает за прецедент. Когда диаграмма взаимодействия создана, поток событий прецедента распределяется между участвующими объектами. Это означает, что человек, ответственный за прецедент, накладывает требования и обязательства на соответствующие объекты. Все подобные требования к объекту собираются в документ, называемый спецификацией объекта. Затем человек, отвечающий за объекты, формулирует эти требования в описании объекта. [c.197]
При использовании описанной выше методики есть риск увлечься деталями на самом деле совершенно не обязательно слишком глубоко вникать в описание ответственности объекта. Определение всех операций, представляющих ответственность объекта, и параметров этих операций обычно заводит слишком далеко. Конечно, иногда детализация описания нужна, но делать ее без веских причин не стоит. [c.197]

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