Правильно заданный вопрос быстро приводит к правильному ответу.
Недавно меня спросили: «Почему стандарты бизнес-анализа сосредоточены на выявлении требований, но ничего не говорят о превращении этих требований в решениеЭ» В самом начале своей карьеры аналитика я искал ответ на вопрос: как анализировать предметную область и как превратить результат анализа в структуру модели: где взять классы, атрибуты и методы? Потом я нашел один более-менее внятный метод, описанный в книге Крейга Лармана.
Применение UML 2.0 и шаблонов проектирования.
Введение в объектно-ориентированный анализ, проектирование и итеративную разработку.
.
Аналитику предлагалось пройти по тексту маркерами разного цвета: красный выделяет существительные и является основой для создания классов, зеленый — прилагательные, причастия и т. д. — основой для создания признаков этих классов.
А глаголы выделены синим цветом — основа для создания методов.
Однако на самом деле этот метод не сработал.
Я мог бы смоделировать тот же факт, используя класс, значение атрибута или метод, в зависимости от моего желания.
Об этом подробно написано в книге Крисса Партриджа.
Бизнес-объекты: реинжиниринг для повторного использования .
Он приводит пример Колли.
Это может быть класс объектов, это может быть значение атрибута «Порода» с типом значения либо строка, либо ссылка на объект справочника «Породы», либо значение «да» булева атрибута «Колли».
».
В примере Крисса Партриджа мы выбираем между классом и атрибутом.
Но есть альтернатива, при которой тот же факт можно смоделировать с помощью класса или метода.
Например, вы можете представить себе ситуацию, когда позолоту можно смоделировать с помощью класса объекта, значения атрибута и, возможно, метода.
Выбор метода моделирования зависит от контекста и границ информационной модели.
Однако рано или поздно наступает момент, когда границы информационной системы разрастаются до такой степени, что один и тот же факт с одной точки зрения необходимо моделировать с помощью .
класс, с другой стороны, используя функцию, операцию или значение атрибута.
И тогда настоящей проблемой для аналитика становится сопоставление этих различных точек зрения.
Препятствием является не только технологическая сложность такого картографирования, но и ограниченность нашего воображения.
- Мы думаем, что моделируем устройство мира, хотя давно известно, что каждый субъект имеет свой индивидуальный мир, и мы моделируем не мир, а представление субъекта о мире.
Разница между первым и вторым тезисом состоит в том, что разные испытуемые могут иметь разные точки зрения на одну и ту же вещь, поскольку видят ее по-разному.
- Мы думаем, что типы атрибутов и значения атрибутов — это нечто совершенно разное, хотя это не что иное, как разные способы различения групп объектов.
В результате мы с трудом справляемся с задачей интеграции данных, когда, например, цвета моделируются в одном случае с помощью отдельных классов, в другом — с помощью литеральных значений, а в третьем — с помощью ссылок на справочник.
- Мы легко представляем себе трехмерный объект, нам трудно представить себе операции и их последовательности, но чего мы не можем, так это представить объект как операцию или операцию как объект. В результате нам не предоставляются такие действия, как: разложение объекта на операции, представление функции как набора операций и т.д.
Но есть еще один важный вопрос, который мы должны задать себе, прежде чем приступить к моделированию.
Нам нужно выяснить, какую модель мы собираемся построить.
Недавно услышал тезис: модель модели – это тоже модель (упоминалось свойство транзитивности моделей).
Например, если у вас есть документ «Договор», который является моделью соглашения, то файл Word, моделирующий это соглашение, также является моделью соглашения.
Хитрость в том, что этот тезис справедлив только для одного типа моделей — для объектных моделей.
Для другого типа моделей — концептуальных моделей — этот тезис неверен.
Мало кто делает между ними различие.
Поэтому я решил немного отклониться от основной линии изложения и рассказать о типах моделей, с которыми работают аналитики.
Классификация моделей
Начнем с того, что мы обычно называем моделью.Под моделью мы подразумеваем информационный объект. Предположим, что субъект решил передать другому субъекту свое представление о каком-то объекте реального мира.
Для этого он использует нотацию (язык) для описания своего представления этого объекта в виде информационного объекта.
Этот информационный объект попадает в руки другого субъекта и он, зная обозначения, воссоздает в своем сознании представление первого субъекта.
Именно так знания передаются от одного предмета к другому, и именно поэтому язык играет такую важную роль в обучении.
Строго говоря, модель – это то, что находится в сознании субъекта, а информационный объект – модель этой модели.
Но из-за транзитивности моделей считается, что информационный объект также является моделью.
Этот информационный объект может постоянно уточняться и корректироваться по мере необходимости, что и происходит, когда один субъект что-то объясняет другому.
Предположим, что испытуемый встречает схожие объекты в разных задачах.
Например, с подобными деталями.
Тогда он сможет изготавливать аналогичные модели для разных деталей.
В какой-то момент в него включается аналитик, и этот аналитик требует унификации моделей.
Унификация нужна для того, чтобы сэкономить время на моделировании после однократной работы.
Унификация заключается в том, что аналитик создает одну модель для всех схожих частей.
Это концепция части.
Ее отличие от модели детали состоит в том, что модель детали можно уточнять бесконечно, но понятие нельзя уточнять бесконечно, поскольку оно относится не к одной, а ко многим деталям.
Детали отличаются друг от друга и поэтому бесконечно совершенствовать концепцию невозможно.
Можно ли на основе концепции восстановить объектную модель? Это возможно, но с помощью спекуляций.
Мы легко превращаем концепцию в модель объекта.
Однако легкость, с которой мы это делаем, не означает, что концептуальная модель является моделью объекта.
Для восстановления объектной модели на основе ее концепции необходим контекст, который будет дополнять концептуальную модель объектной моделью.
Теперь усложним задачу и предположим, что испытуемый моделирует конструкцию.
Напомню, структура — это совокупность объектов и связей между ними.
Очевидно, что проектную модель, как и объектную модель, можно бесконечно совершенствовать.
Теперь предположим, что, как и в случае с деталями, перед испытуемым стоит задача моделирования аналогичных конструкций, например, конструкций тепловозов.
Делая то же, что и в первом случае, испытуемый может унифицировать модели и создать одну для многих структур — концепцию дизайна.
Концепция дизайна состоит из множества концепций – концепций объектов – элементов дизайна и концепций связей между этими элементами.
Для концепции конструкции тепловоза будет справедливо следующее утверждение: каждому элементу концепции конструкции соответствует один и только один элемент в реальном тепловозе.
Иначе это можно переформулировать так: «арность» связей в конструктивной модели тепловоза всегда «один к одному».
Но в целом это не так.
Часто можно встретить концептуальные модели, в которых «арность» связей отличается от «один к одному».
Концепция дизайна также называется концептуальной моделью.
Однако в общепринятом определении концептуальной модели есть одна очень серьезная ошибка.
Обычно говорят, что концептуальная модель — это модель концепций и отношений между ними.
Это неверно, поскольку в концептуальной модели существуют не связи и даже не модели связей, а понятия связей.
Чтобы как-то замаскировать эту ошибку, говорят, что связи в концептуальной модели имеют арность – например, «один к трем».
Обо всем этом я писал ранее и вы можете прочитать об этом в моей статье.
Моделирование объектов учета в разделе «стрелки».
Чтобы лучше представить себе эти типы моделей, вы можете взглянуть на любую модель ER. На них мы видим понятия объектов и понятия связей.
Можно ли реконструировать концептуальную модель проекта на основе модели ER? Увы, это невозможно.
А, следовательно, восстановить проектную модель невозможно.
Итак, подводя итог, можно сказать, что существует два типа моделей — объектные модели и концептуальные модели.
Для объектных моделей справедлив принцип транзитивности, но для концептуальных моделей этот принцип не работает.
Примеры
Предположим, что существует соглашение между двумя контрагентами.Данное соглашение имеет модель – письменный договор.
Таких документов несколько, каждый из которых является образцом этого соглашения.
Пусть есть файл Word с образцом написанного документа.
Удобно вносить изменения в одном месте и потом иметь возможность распечатать столько копий, сколько необходимо.
Оказывается, этот файл Word также является моделью договора.
Предположим, существует множество соглашений, по каждому из которых необходимо создать письменный документ. Мы сделаем унификацию, и для всех этих документов создадим одну модель – типовой договор.
Типовой договор удобен тем, что позволяет быстро создать модель конкретного договора.
Но это не модель конкретного соглашения.
Таким образом, файл Word со стандартным соглашением не является образцом конкретного соглашения.
И никакой транзитивности моделей здесь нет. Вопрос: Какой тип модели создается с использованием нотации BPMN? Я не буду отвечать на этот вопрос, надеясь, что вы сможете ответить на него сами.
Вопрос: Какой тип модели создается с использованием нотации IDEF0? Я также надеюсь, что вы сами ответите на этот вопрос.
Теги: #бизнес-модель #моделирование предметной области #Семантика #Анализ и проектирование систем #ИТ-стандарты #математика
-
Как Купить Дешевый Android-Планшет?
19 Oct, 24 -
Роботы Итэр
19 Oct, 24 -
Беспроводная Сеть – Беззаботный Веб-Серфинг?
19 Oct, 24 -
Камера Для Людей Со Слабым Зрением
19 Oct, 24 -
Первые Впечатления От Visual Studio 11
19 Oct, 24 -
Fixber: Мы Официально Запустили
19 Oct, 24
