Нотации моделирования

В середине августа всё замирает. Не происходит совсем ничего, кроме, конечно, роста курса доллара. Дефицит событий, вероятно, провоцирует великих ИТ-архитекторов прошлого на длинные обсуждения в твиттере. В telegram-канале «Архитектура ИС» я приводил уже ссылку на дискуссию с участием Гради Буч и Ивар Якобсена и рассуждениями на тему: зачем мы изобрели UML. Сегодня пара мыслей насчет мини-дискуссии Карла Вигерса и Саймона Брауна.

Собственно, короткий твит Саймона относился к тезису Вигерса

Банальность скажете вы, нотация моделирования помогает нам понять, что за объекты изображены на картинке, а абстрагирование – сделать так, чтоб объектов на картинке не было слишком много.

У меня два антитезиса. Первый состоит в том, что нотации моделирования оперируют настолько абстрактными понятиями, что отсылка к ним понимания добавляет немного. Представьте себе диаграмму, на которой изображено несколько компонент. То, что представленные на рисунке фигурки являются компонентами, а не бизнес-функциями, например, или технологическими сервисами ясно уже из контекста. Добавление пиктограммок из UML к нарисованным фигуркам не несет никакой информации, кроме того, что мы, авторы рисунка, умные и владеем нотациями моделирования. При этом, мы совершенно не знаем идет ли речь о библиотеках, динамически подключаемых библиотеках, исполняемых модулях или еще о чём-то другом. Мы не знаем, отображают ли эти фигурки компоненты времени исполнения или же эти компоненты обладают качеством физической заменяемости только с точки зрения разработчика. Некоторую дополнительную информацию дали бы нам стереотипы. Если на компоненте написано, что это “JavaSE application” или “MS SQL Server Database”, то уровень нашего понимания станет существенно выше. Если дополнить компоненты именованными значениями (tagged value), то узнать о них можно ещё больше. Правда в 2.x версиях UML именованные значения сочли несущественным механизмом и предпочли от него отказаться. Очень много информации принесу дополнительные комментарии, особенно относящиеся не к одному компоненту, а к целой группе: эти три модуля развертываются вместе, эти – разрабатываются одной командой, а вот те лицензируются в рамках единого контракта, который скоро закончится. Очевидно, что такие группы могут пересекаться. Подходы к их визуализации см. в предыдущих сообщениях про концептуальные карты и диаграммы Эйлера

Второй антитезис: переход на более высокие уровни абстракции ухудшает понимание диаграммы. Пока мы говорим о конкретных вещах, оперируем понятиями, более-менее согласованными с объектами реальными мира: процессами, файлами, таблицами базы данных, понимание еще присутствует.  Но всё портится, стоит лишь начать группировать эти объекты в приложения, пакеты, автоматизированные и информационные системы, прочие абстракции понятные лишь авторам, их придумавшим. Исправить ситуацию могут опять же стереотипы, комментарии, подсказки в виде tooltip, гиперссылки, ведущие на страницу описания элемента. Но всё это требует переосмысления формы архитектурных диаграмм, перевод их раздела «картинок» в веб-сайты или архитектурные репозитории.

Но там уже совсем другой набор возможностей, архитектура не аналоговая, а цифровая, если можно так выразиться (см. Digital Enterprise Architecture)

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

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