Отображение пути вместо рисования связей

incДля упомянутого в предыдущем сообщении вебинара я нарисовал простую картинку (см. рисунок, кликабельно). Я не следовал какой-то строгой нотации в этом наброске. Моей целью являлось в двух словах рассказать о том, что такое система управления инцидентами, какие акторы (действующие лица) участвуют в работе с такого рода системой и как выглядит процесс решения инцидента. Главным характеризующим свойством такого рода процессов является наличие двух уровней поддержки. (Иногда выделяют большее количество уровней, но для нас сейчас это не принципиально) На первом уровне происходит классификация обращения и назначение его на соответствующую группу второго уровня. Иногда инцидент может быть решен и на первом уровне. Есть даже специальный KPI, именуемый First Line Resolution Rate, который показывает долю инцидентов, закрытых первым уровнем поддержки.

Если показать этот рисунок настоящим системным архитекторам, то думаю – холивара не избежать. Наверняка кто-нибудь из них задал бы вопрос, который я сам люблю задавать: Что означают эти стрелки на вашем рисунке? И в этом случае такой вопрос поставил бы меня в сложную ситуацию. Мы привыкли относится к стрелкам на архитектурных диаграммах как к элементам строгой нотации, коннекторам между двумя компонентами, определенным Philippe Kruchten-ом в основополагающей работе «Architectural Blueprints – The “4+1” View Model of Software Architecture». Для нас стрелки всегда являются элементами графа архитектурной модели и должны иметь точно передаваемый смысл. В отношении зависимости (dependency) стрелка в направлении от первого объекта ко второму указывает на то, что при изменении спецификации второго объекта нам вероятно потребуется что-то поменять в первом. Иногда это отношение еще называют supplier-client relationship. Стрелка в отношении наследования всегда указывает на родительский класс. Ну а что-же означают стрелки на моём небрежном наброске? Начинающий архитектор попробовал бы оправдаться тем, что такие стрелки показывают направление потоков данных. Вряд ли это вызвало бы понимание.

Рассматриваемый рисунок не сильно похож на диаграмму потоков данных DFD ни в нотации Йордана(Yourdon), ни в нотации Гейна-Сарсона(Gane-Sarson).  Мне просто хотелось показать на этой картинке описание основного сценария. Совместить с исходным рисунком диаграмму последовательности или диаграмму взаимодействия. Отобразить путь по которому могут развиваться события. Для пущей убедительности я мог бы нарисовать над стрелками цифры. Может быть этот набросок и не соответствует ни одной из нотацией моделирования, но его зрители наверняка сумеют ухватить смысл.

Время раскрыть карты. Двадцать лет назад появилась книжка Ray Buhr и Ron Casselman: “Use Case Maps for Object-Oriented Systems”, описывающая нотацию, разрешающую нам одной стрелкой объединить несколько объектов на диаграмме. В предисловии к ней, автор вариантов использования(use cases) и соавтор языка UML Ivar Jacobson написал:

“Use case maps fill a very important need. They fill the gap between verbal descriptions and detailed descriptions in terms of interaction diagrams. Interaction diagrams focus on the interaction between components, let these be actors, subsystems, objects, or the like. The responsibilities of the components are verbal annotations to the interaction diagrams. Use case maps allow us to reason about the responsibilities of the components without going into the details about the messaging between the components…

Use case maps are one of the most important contributions to our understanding of use cases.”

Причем появились карты вариантов использования в рамках не менее интересной инициативы, именуемой User Requirements Notation (URN). Краткая иллюстрация UCM приведена на рисунке ниже.

usecasemap

Нотация позволяет разветвлять процесс, обозначать ответственность отдельных компонент, совмещать на одном рисунке несколько сценариев и делать другие интересные вещи. Краткое описание UCM доступно по этой ссылке. Скачать полный текст книжки можно со страницы VirLibUcmBook1995.

Надеюсь этот любопытный подход позволит ИТ архитекторам проще относится к свои эскизам, что в свою очередь сделает их более понятными для заказчиков и участников ИТ-проектов.

Отображение пути вместо рисования связей: 6 комментариев

  1. RE “Может быть этот набросок и не соответствует ни одной из нотацией моделирования, но его зрители наверняка сумеют ухватить смысл.” It seems that your diagram shows “flow-of-control” (like BPMN and many workflow notations) which is different from the “flow-of-data” (or “flow-of-assets”).

    Thanks,
    AS

    1. Моя картинка – это неформальный набросок, не более того. А вот Use case map довольно сильно отличается и от блок-схем и от других способов отображения потока событий. Отличается хотя бы тем, что не базируется на графе и не описывается набором компонент и коннекторов между ними

  2. По мне, так исходная картинка – типичная DFD диаграмма.

    Все стрелочки – поток информации. Внешняя сущность, хранилище и процессы также присутствуют.

    То что [Очередь Инцидентов] раздвоена, так это для удобочитаемости. Во многих инструментах такая возможность есть, не знаю уж, насколько это Йордану соответствует.

  3. URN мне тоже очень понравился. Еще не доводилось использовать, но как только, так сразу поставлю jUCMNav. Добавлю еще, что он стандартизирован (вместе с GRL) ITU-T Z.151.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *