Правильно заданный вопрос быстро приводит к правильному ответу. Недавно меня спросили: «Почему стандарты бизнес-анализа сконцентрированы на выявлении требований, но ничего не говорят о превращении этих требований в решение?» В самом начале своей карьеры аналитика я искал ответ на вопрос: как анализировать предметную область и как превращать результат анализа в структуру модели: откуда брать классы, атрибуты и методы? Тогда я нашел один более-менее вразумительный метод, описанный в книге Крега Лармана Применение UML 2.0 и шаблонов проектирования. Введение в объектно-ориентированный анализ, проектирование и итеративную разработку. Аналитику предлагалось прохождение по тексту с маркерами разных цветов: Красный выделяет существительные и является основанием для создания классов, зеленый — прилагательные, причастия и проч. — основа для создания атрибутов этих классов. И глаголы выделяются синим — основа для создания методов.

Однако, в реальности этот метод не работал. Один и тот же факт я мог смоделировать при помощи класса, значения атрибута или метода в зависимости от своего желания. Об этом написано подробно у Крисса Партриджа в книге Business Objects: Re-Engineering for Re-Use.

Он приводит пример с Колли. Это может быть класс объектов, это может быть значение атрибута «Порода» с типом значения либо строковое, либо – ссылка на объект справочника «Породы», либо – значение «да» булевского атрибута «Колли».

В примере Крисса Партриджа мы выбираем между классом и атрибутом. Но есть альтернатива, при которой можно смоделировать один и тот же факт при помощи класса или метода.

Например, можно вообразить себе ситуацию, что позолоту можно смоделировать при помощи класса объектов, при помощи значения атрибута, а, возможно, и метода.
Выбор способа моделирования зависит от контекста и границ информационной модели. Однако, рано или поздно наступает тот момент, когда границы информационной системы вырастают до объема, когда один и тот же факт с одной точки зрения нужно моделировать при помощи. класса, с другой – при помощи функции, операции или значения атрибута. И тогда настоящим вызовом для аналитика становится маппинг между этими разными точками зрения.

Препятствием становится не только технологическая сложность такого маппинга, но и ограниченность нашего воображения.

Мы думаем, будто моделируем устройство мира, хотя давно известно, что у каждого субъекта свой индивидуальный мир, и мы моделируем не мир, а представление субъекта о мире. Разница между первым и вторым тезисом в том, что разные субъекты могут иметь разные точки зрения на одно и то же, поскольку они его видят по-разному.
Мы думаем, что типы и значения атрибутов – это нечто совершенно разное, хотя — это не более чем разные способы выделения групп объектов. В итоге мы с трудом справляется с задачей интеграции данных, когда, например, цвета в одном случае моделируется при помощи отдельных классов, в другом — при помощи литеральных значений, и в третьем — при помощи ссылок на справочник.
Мы легко представляем себе трехмерный объект, мы с трудом представляем себе операции и их последовательности, но чего мы не можем сделать – это представить себе объект как операцию, или операцию как объект. В итоге нам не даются такие действия как: разложение объекта на операции, представление функции в виде набора операций и прочее.

Обо всем этом я писал ранее. Но есть еще один важный вопрос, который мы должны себе задать прежде, чем начнем моделирование. Надо выяснить, какого типа модель мы собираемся строить. Недавно я услышал тезис: модель модели – тоже модель (было упомянуто свойство транзитивности моделей). Например, если у вас есть документ «Договор», который есть модель договоренности, то вордовский файл, моделирующий этот договор – тоже модель договоренности. Фокус в том, что этот тезис верен только для одного типа моделей – для моделей объектов. Для другого типа моделей – концептуальных моделей, — этот тезис неверен. Мало, кто делает различие между ними. Поэтому я решил немного отойти от главной линии изложения и рассказать про типы моделей, с которыми работают аналитики.

Классификация моделей

Начнем с того, что обычно мы называем моделью. Под моделью мы понимаем информационный объект. Допустим, что субъект решил передать другому субъекту свое представление о каком-то объекте реального мира. Для этого он при помощи нотации (языка) делает описание своего представления этого объекта в виде информационного объекта. Этот информационный объект попадает в руки другого субъекта и он, зная нотацию, воссоздает у себя в сознании представление первого субъекта. Так происходит передача знаний от одного субъекта другому, и поэтому язык играет столь существенную роль в обучении.

Строго говоря, модель – это то, что есть в сознании у субъекта, а информационный объект – это модель этой модели. Но, благодаря транзитивности моделей, считается, что информационный объект – тоже модель. Этот информационный объект может постоянно уточняться и правиться по мере необходимости, что и происходит, когда один субъект что-то объясняет другому.

Допустим, что субъект в разных задачах сталкивается с похожими объектами. Например, с похожими деталями. Тогда для разных деталей у него могут получаться похожие модели. В какой-то момент в нем включается аналитик, и этот аналитик требует унификации моделей. Унификация нужна для того, чтобы один раз поработав, сэкономить время на моделировании.

Унификация заключается в том, что для всех похожих деталей аналитик создает одну модель. Это – концепт детали. Его отличие от модели детали в том, что модель детали можно уточнять бесконечно, а вот концепт уточнять бесконечно не получится, потому что он относится не к одному, а к множеству деталей. Детали отличаются друг от друга и потому нет возможности уточнять концепт бесконечно.

Можно ли по концепту восстановить модель объекта? Можно, но при помощи домысливания. Мы легко домысливаем концепт до модели объекта. Однако, легкость, с которой мы это делаем, не означает, что модель концепта – это модель объекта. Для восстановления модели объекта на основе его концепта нужен контекст, который дополнит модель концепта до модели объекта.

Теперь усложним задачу и предположим, что субъект моделирует конструкцию. Напомню, что конструкция – это множество объектов и связей между ними. Очевидно, что модель конструкции, как и модель объекта, можно уточнять бесконечно.

Теперь допустим, что, как и в случае с деталями, у субъекта стоит задача моделирования похожих конструкций, например, конструкций тепловозов. Поступая, так же, как и в первом случае, субъект может унифицировать модели и создать одну для множества конструкций — концепт конструкции.

Концепт конструкции состоит из множества концептов – концептов объектов – элементов конструкции и концептов связей между этими элементами. Для концепта конструкции тепловоза будет верным следующее утверждение: для каждого элемента в концепте конструкции существует один и только один элемент в реальном тепловозе. Иначе можно это переформулировать так: «арность» связей в модели концепта конструкции тепловоза всегда «один-к-одному».

Но в общем случае это неверно. Часто можно встретить концептуальные модели, в которых «арность» связей отличается от «один-к-одному».

Концепт конструкции еще называют концептуальной моделью. Правда, в распространенном определении концептуальной модели есть одна очень серьезная ошибка. Обычно говорится, что концептуальная модель – это модель концептов и связей между ними. Это неверно, потому что в концептуальной модели присутствуют не связи и даже не модели связей, а концепты связей. Чтобы как-то замаскировать эту ошибку, говорят, что связи в концептуальной модели имеют арность – например, «один к трем». Обо всем этом я писал ранее и об этом можно прочитать в моей статье Моделирование объектов учета в разделе «стрелки».

Чтобы лучше представить себе такого рода модели, можно посмотреть на любую ER модель. На них мы видим концепты объектов и концепты связей. Можно ли на основе ER модели восстановить модель концепта конструкции? Увы, нельзя. А, следовательно, нельзя восстановить и модель конструкции.

Итак, подводя итог, можно сказать, что существуют два вида моделей – модели объектов и модели концептов. Для моделей объектов верен принцип транзитивности, но для моделей концептов этот принцип не работает.

Примеры

Допустим, что существует договоренность между двумя контрагентами. Эта договоренность имеет модель – письменный договор. Существует несколько таких документов, каждый из которых – модель этой договоренности. Пусть существует вордовский файл с моделью письменных документов. Это удобно – вносить изменения в одном месте, чтобы потом иметь возможность распечатать столько копий, сколько необходимо. Получается, что этот вордовский файл – тоже модель договоренности.
Пусть есть множество договоренностей, для каждой из которых приходится создавать письменный документ. Сделаем унификацию, и для всех этих документов создадим одну модель – типовой договор. Типовой договор удобен тем, что позволяет быстро создать модель конкретной договоренности. Но он не является моделью конкретной договоренности. Поэтому вордовский файл с типовым договором не является моделью конкретной договоренности. И транзитивности моделей тут нет.

Вопрос: какого типа модель создается при помощи нотации BPMN? Я не буду отвечать на это вопрос, надеясь, что вы сами способны ответить на него.

Вопрос: какого типа модель создается при помощи нотации IDEF0? Также надеюсь, что вы сами ответите на это вопрос.

Типы моделей