30.01.2021
Автор: Виктор Рудь
Концептуальная модель - это совокупность концептов (понятий, смыслов) и их связей. Подробнее рассмотрим ниже, а пока дадим простейший пример. Перед нами текст, описывающий бизнес-ситуацию (ситуацию некого фрагмента реальности):
клиент по имени Петров оплатил счет в размере 450 рублей и получил чек за три ручки и два карандаша марки "Архитектор" в торговой точке (канцелярский бутик) внутри магазина "ГУМ" (Москва); основанием для покупки явилось воздействие рекламной компании, проводимой по радио.
Что мы можем выделить из этого текста в качестве концептуальной или смысловой модели (мета-модели)?
Так рождается концептуальная модель, задающая тон всему последующему процессу проектирования [информационной системы].
Внимание: если мы рассуждаем о данных, то концептуальная модель собственно данные не содержит. Сами данные - это ГУМ, Петров, радио, карандаш, ручка, 450 рублей. Концепты - это метаданные, то есть они указывают не на объекты реальности, а на классы объектов реальности: товары, точки продаж, оплаты, покупки. Обратите внимание, что "ГУМ", Петров, радио, карандаш марки "Архитектор" - это именно данные, а не сама реальность. Реальность мы не можем привести здесь в тексте, мы можем лишь репрезентировать её в словах (что мы и делаем) или репрезентировать её в виде записей в СУБД (см. ниже про физический уровнь). Более подробно на эту тему советуем изучить трактат Витгенштейна.
Можно также трактовать концептуальную модель как сущностное или смыслое мышление. У Фреге Готлоба мы имеем в треугольнике "Знак, Значение, Означаемое". Знаки нас не интересуют - это просто буквы кириллицы. Означаемое - ГУМ, Петров, радио, карандаш, ручка, деньги - это нам сейчас не интересно, это реальность. Берем в концептуальную модель лишь "значения", которые есть смыслы или классы (умение соотносить единичное означаемое с классом, которому оно принадлежит).
Существует три уровня (уровня абстрактности-детальности) в моделировании данных (их можно считать минимально рекомендованными стадиями проектирования как самих метаданных, так и операций собственно над данными):
Часто задают вопрос, откуда возникло деление именно на 3 уровня? На самом деле их может быть и больше, в объекто-ориентированной парадигме проектирования их реально больше. Можно посоветовать взглянуть на матрицу Захмана, которая напоминает нам, что проектирование ведёт свою историю со времен древних греков (правда древними, в части проектирования, назвать их сложно - едва ли мы превзошли их сегодня). Концептуальный уровень - уровень определений, он задает границы понятий. Различая знак и означаемое знаком (смотри Фреге Готлоба), мы должны дать определение какого-то понятия, то есть "что стоит за знаком?", что есть есть означаемое? Этот уровень называют DEFENITION; это про смыслы. Определения или концепты зачастую есть просто слова. Логический уровень у Захмана - это МОДЕЛЬ. Этимология слова МОДЕЛЬ весьма интересна, можно сказать, что это чертеж, на котором выверяются отношения частей внутри проектируемого объекта (например, для дома - высота потолка, площадь пола, стороны света, места расположения входов/выходов, размеры и число окон, число колонн и т.п.). Логический уровень - это макет проектируемого изделия. Иногда этот уровень называют не только логическим, но и SYSTEM, то есть из каких частей будет состоять некая система (прим: обычно проектированию подлежат именно системы в ширком смысле слова: от пиджака со шлицами и рукавами до экосистемы), как эти части соединяются в целое, образуя проектируемую систему. Физический уровень - это уровень реализации, тут особо нечего добавить. Между логическим и физическим пропущены еще два уровня. Это уровень SPECIFICATION - спецификация логических объектов. И уровень CONFIGURATION - конфигурация логических объектов в рамках заданной спеки. Об этом мы никогда не писали, но когда-то добавим. А также нужно добавить доконцептуальный уровень - IDENTIFICATION. Это уровень фантазий, мечт, идей. Ведь написать концепцию сразу можно только на готовое или полуготовое явление/изделие, но даже и в этом случае IDENTIFICATION имеет значимое влияние, как самая ранняя стадия установки границ проектируемой системы. Например, будем мы производить кресла или велосипеды? - это стадия идеи, до концепции здесь еще как до луны.
Смотри также здесь:
Правильное использование концепций предполагает
постоянные споры об их правильном использовании.
Роберт Бейли "Теория концептуализма"
Назначение моделей концептуального уровня или зачем это нужно? На концептуальном уровне моделирования (максимально абстрактном с точки зрения реализации в информационных системах) мы выясняем и определяем основные понятия (смыслы) предметной области и их взаимосвязь. На этом уровне мы расчленяем реальность на объекты или концепты. Иногда также используют термин «построение онтологиии предметной области». Концептуальная модель задаёт границы приложения, отражая своим содержанием не только то, чем мы будем заниматься, но также и то, чем мы заниматься не будем. Концептуальная модель не зависит от реализации её в какой-то системе. Её можно подогнать под некоторую реализацию, но изначально она от реализации абсолютно независима. Концептуальная модель - это безусловно метамодель.
Концепт, определение, смысл, класс, сущность - все это можно считать синонимами. Определение - есть словесное выражение смысла или концепта, но не просто выражение, а сущностное описание. Если определение дать сложно, то можно задать его перечислением экземпляров класса (см. концентроид Рудда).
Базовый элемент концептуальной модели: концепт или бизнес-объект, или бизнес-сущность. Более точно, на языке IT, - класс, то есть совокупность предметов реальности, отнесенных пользователями или экспертами к определенному классу. Примечение: это называют сущностью, если хотят подчеркнуть тот общий признак, ту суть, по которой предметы реальности отбираются в класс. Это называют классом, если хотят подчеркнуть, что речь идет не об единичном предмете, а о множестве предметов с одинаковой сутью. Например, "пишущий прибор" - это и шариковая ручка, и карандаш, и ручка перьевая, и сотни моделей различных ручек разной конструкции и эстетики. "Пишущий прибор" - сущность, суть которой есть нЕчто, позволяющее писать. Но также "пишущий прибор" - указание на класс предметов реальности, с помощью которых можно писать.
Примеры бизнес-сущностей (бизнес-объектов):
Концептуальная модель бизнеса (модель размышления или онтологическая картинка бизнеса), как правило, представлена в документах класса ГЛОССАРИЙ. Это может быть как местная wiki, так и разрозненные главы типа «Глоссарий» в различных документах компании. Качество таких глоссариев не высокое, для автоматизации и тем более цифровизации они не годятся, но безусловно словарь или тезаурус - это первый артефакт, с изучения которого должен начать аналитик. Цель аналитика - построить настоящую концепт-модель из концептуальных объектов данных, где объект данных - это контейнер с атрибутами, имеющий как четкие семантически границы, так и выделенные свойства объекта - атрибуты. Собственно атрибуты-свойства (например, марка карандаша или ручки) и есть лучший способ определения концептуального объекта. Если вы не можете выделить атрибуты (ну естественно речь идет о мета-атрибутах), то такой концепт не важен для автоматизации или цифровизации, хотя может быть важен для понимания полной онтологической картины предметной области. Схематически (графически) наиболее удобным способом представления концептуальной модели является схема типа «диаграмма классов». Изображение каждого класса на схеме содержит:
Например, концепт АВТОМОБИЛЬ может быть задан так: любой предмет реальности, у которого можно выделить такие его свойства, как объем двигателя, габариты, числов возможных пассажиров в кабине. Под такое определение может попасть и кран, и грузовик, и трактор. И это вам решать, имеет ли место быть концептуальная ошибка или нет.
Концептуализация предметов (вещей) является относительно простой задачей. Концептуализация явлений сложнее. Концептуализация ментально-когнитивных явлений наиболее сложна. Дайте концептуальное определение и мета-атрибуты для таких явлений, как ПРОБЛЕМА, ПРЕТЕНЗИЯ, ИНИЦИАТИВА, ИДЕЯ. Легко? Потренируйтесь также в определении того, что есть ТРЕБОВАНИЕ, ОГРАНИЧЕНИЕ, ПРИНЦИП, ИНТЕРЕС, ФУНКЦИЯ, ПРОЦЕССНЫЙ ШАГ.
Бизнес-сущности (бизнес-объекты) имеют связи друг с другом. Связи при именовании полезно «окрашивать» именами действий или отношений из предметной области, например, клиент заключает сделку, заказ состоит из товаров (см. о предикатах сущности здесь >>>). Наилучшая нотация для концептуального уровня — подборка элементов из доменов Business и Motivation языка Archimate. Из концептов языка Архимейт рекомендуется отобрать для использования Business Object в связке с Meaning, а также бизнес-сущности могут быть привязаны к ряду других концептов Архимейт (например, value или capability), что улучшает "окрашивание" бизнес-сущностей или лучше структурирует (делает более наглядной) моделируемую предметную область.
Фокус моделирования:
Сложные концептуальные модели, содержащие десятки бизнес-сущностей, разбиваются на домены. Домен — группировка «родственных» сущностей, образующих модель отдельного фрагмента моделируемой предметной области. Иногда концептуальная модель становится существенной частью логической модели. Это бывает в следующих случаях:
В отдельных случаях приходится поддерживать концептуальные модели двух видов:
Замечание 2: следует все-таки различать концептуальную модель предметной области и концептуальную модель данных этой предметной области. Концептуальная модель - это фактически онтология, тезаурус, глоссарий... имеющие целью выделить концепты и прояснить их смыслы. Концептуальная модель данных (КМД) преследует более узкие цели, она "смотрит" на мир через призму именно данных, то есть концептуальная модель данных за каждым концептом пытается увидеть его цифрового двойника, выраженного в форме данных (атрибутов и связей). С точки зрения проектирования можно сказать, что КМД пытается зафиксировать, как то или иное предмет/явление реальности может быть оцифровано, можно ли выделить в нем свойста, можно ли зафиксировать его отношения и связи с другими предметами/явлениями.
Замечаение 3. На концептуальном уровне моделирования аналитики не задумаются о том, что бизнес-сущности - это не только объекты концентрации данных, но и объекты поведения. Наделение сущностей поведением - это задача логической модели.
Для дизайна и управления концептуальной моделью данных может быть использована российская СиММА - Система Многослойного Моделирования Архитектуры.
Логическая модель является уточнением и детализацией (более точно - макетом или спецификацией) концептуальной модели. Но это лишь с одной стороны (со стороны концептуального моделирования). С противоположной стороны (со стороны реализации) на построение логической модели влияет:
Назначение моделей логического уровня или зачем это нужно? Логический уровень моделирования — это уровень логики организации данных, то есть какие данные и как сгруппированы и связаны друг с другом. Концептуальный уровень больше заботится о смысловой нагрузке, о возможности свести смыслы к свойствам и связям, логический - заботится о разработке спецификации на эти свойства и связи (эти спеки часто называют метаданные или мета-атрибуты и мета-связи). Эти спецификации, в конечном итоге, должны будут реализованы программистом как на логическом уровне приложения, так и на физическом (например, поля у таблиц и ключи связи между таблицами). Концептуальный уровень оперирует бизнес-сущностями, логический — сущностями будущей или фактически имеющейся информационной системы (например, базы данных или сервера приложений). В компаниях с большой историей логический уровень задан фактически развернутыми системами конкретных вендоров. На вопрос "зачем нужен логический уровень?" можно было бы ответить так: "это тот набор мыслей, с которым вы садитесь что-то программировать, его не может не быть".
Примечание: логический - не означает выделенный с точки зрения здравого смысла и причинно-следственных рассуждений. Логический - значит формализованный по законам формальной (!) логики выбранного способа представления данных: таблично-реляционного или объектно-ориентированного, или сетевого, векторного, графового и т.д. Так, например, причины неудач в процессной автоматизации связаны с тем, что 9 из 10 аналитиков и программистов не в состоянии формализовать на логическом уровне такое сложное явление как "процесс", потому что никогда не слышали об алгебре процессов (и даже более того - безнадежно застряли в модели акторов). А, как известно, без формализации нет и автоматизации. Точнее сказать, всё ещё наблюдается автоматизация процессов в акторной модели - а это путь в тупик, начало которому было положено в далёких 90-х. Его активно развивают адепты СМК.
Важное замечание №1. В простейших случаях концептуальные объекты (бизнес-сущности) совпадают с объектами логического уровня. В таких случаях фаза концептуального моделирования может совсем не требоваться или совпадать с фазой построения логической модели.
Важное замечание №2. Очень часто молодые системные аналитики пытаются построить сложную логическую модель и проваливают работу, не подозревая о необходимости фазы концептуального моделирования, которая должна выполняться с участием бизнес-аналитиков и самого бизнеса. В настоящее время — время диджитал — концептуализация и цифровизация должны рассматриваться как синонимы. Ну и конечно же не стоит забывать про DDD: чем строже соответствие логической и концептуальной моделей (вплоть до совпадения), тем лучше для качества проекта.
Тип объектов логического уровня соответствует типам объектов избранной СУБД или фреймворка. Для реляционных баз данных - это кортеш из атрибутов одной таблицы. Для объектно-ориентированных баз данных и фреймворков — это собственно "объекты". Объекты логического уровня (их часто называют ENTITY, сущности) - это то, чем оперирует информационная система (база данных или сервер приложений) или программист [в ходе написания кода]. К сущностям логического уровня подвязываются методы работы с этими сущностями. То есть в зависимости от того, какая именно физическая реализация концепт-модели будет выбрана, сущности логического уровня получат опеределенные степени сводобы-несвободы.
Базовый элемент логической модели: сущность или объект (в ООП — класс, где объект - экземпляр класса).
Для проектирования реляционных баз данных используется нотация ERD. Рамками этой нотации фактически и задаётся логический уровень моделирования. Однако для трехзвенных систем, имеющих на среднем уровне объектно-ориентированный сервер приложения, логический уровень описывается диаграммной классов (из нотации UML). Детализирующие (вспомогательные) и часто используемые диаграммы логического уровня моделирования — это диаграммы состояний.
Учитывая тот факт, что объекты логической модели проектируются не только как объекты данных, но как и объекты поведения, полезными вспомогательными диаграммами являются диаграммы взаимодействия классов (UML Sequence Diagramm).
Примеры сущностей (классов):
Логические модели данных с примерами сущностей и их связями системно рассматриваются в ходе консультационного семинара по SID.
Вспомним наш пример из начала данной статьи:
Реальность: клиент по имени Петров оплатил счет в размере 450 рублей и получил чек за три ручки и два карандаша марки "Архитектор" в торговой точке (канцелярский бутик) внутри магазина "ГУМ" (Москва); основанием для покупки явилось воздействие рекламной компании, проводимой по радио.
Концептуальная модель.
Концепты (возьмем три из них): Клиент. Товар. Чек.
Информационные свойства (мета-атрибуты) концептов:
Отношения концептов (мета-связи): Клиент совершает Покупку. Клиент совершает Оплату. Клиент получает Товар. Чек отражает Оплату. Оплата соответствует Счету.
Логическая модель.
Фокус моделирования на логическом уровне:
Немаловажное влияние на сущности логического уровня и их взаимосвязи оказывает тип проектируемой системы. Если проектируемая система относится к BI-классу, то следует понимать назначение BI-системы, ожидаемые от нее витрины, срезы, аналитики, метод моделирования времени (динамика изменения данных) и т.п.
Если в ходе проектирования разрабатывается логическая модель не одной, а нескольких систем, что часто имеет место быть в крупных компаниях, внедряющих пятую, десятую или сто двадцатую систему, то при разработке логической модели указывают к какой системе принадлежит (или будет принадлежать) та или иная сущность. Распределение сущностей по различным информационным системам даёт возможность грубо наметить (спрогнозировать) будущие информационные потоки (и точки интеграции) между системами.
Важное замечание. При разработке новой информационной системы, являющейся частью комплекса унаследованных систем, часто приходится использовать как проектирование сверху вниз (от концептуального уровня к физическому), так и обратное — снизу вверх: от уже существующих физических моделей к логической и далее мапирование в концептуальную. Это на порядок или даже на 2 порядка усложняет проектирование даже если нужно создать/автоматизировать один сквозной процесс, протекающий через ряд информационных систем.
Иногда при проработке логического уровня возникают сущности, которые трудно подвязать к бизнес-сущностям концептуального уровня и тогда возникает вопрос: нужно ли на концептуальном уровне завести новую бизнес-сущность? Ответ таков:
Каждый вендор информационной системы имеет логическую модель своей системы даже если он и не раскрывает ее своим клиентам. При интеграции нескольких систем приходится сначала увязывать их логические модели на концептуальном уровне моделирования, а лишь потом строить связи между логическими моделями разных систем. Например, в системе автоматизации продаж клиент может быть представлен как PARTY, в ERP-системе той же компании как КОНТРАГЕНТ, а в системе биллинга той же компании, как АБОНЕНТ.
Физический уровень — это уровень таблиц для реляционных моделей данных. На самом деле не только таблиц, но также индексов, тригеров, хранимых процедур и прочего, что необходимо для реализации логической модели.
Базовый элемент физической модели: таблица.
Примеры таблиц:
Не исключается, что одна таблица физического уровня может участвовать в моделировании (отражать собой) сразу несколько логических сущностей. Но также и наоборот, одна логическая сущность может быть представлена совокупностью таблиц (для целей нормализации данных, например).
Фокус моделирования:
В простейших случаях логические объекты (сущности) совпадают с объектами физического уровня. Это характерно для самых простых баз данных реляционного типа. Нотация Питера Чена (реализована в СиММА) хорошо подходит для увязывания логического и физического уровня проектирования.
Таким образом, мы имеем следующую цепочку отображения/преобразования: реальность -> данные -> модель данных (совокупность мета-данных). То есть модель данных – это способ упорядочить и связать данные путем выделения определенных концептов, репрезентирующих данные. Такие концепты часто называют сущности или классы.
Однако стоит посмотреть на эту же ситуацию по-другому. Всегда ли мы знаем как собрать данные о реальности? Какие данные собирать о погоде? Какие данные собирать о клиентах? Какие данные собирать о продажах? Мы не всегда знаем это. В таком случае цепочка отображения будет следующей: реальность -> модель данных (совокупность мета-данных) -> данные. То есть в этой цепочке модель данных предопределяет какие именно данные (типы данных) о реальности мы собираемся фиксировать/собирать. В этом случае модель данных (более правильно модель мета-данны) предопределит собственно состав самих данных.
Третий вариант: мы собрали данные о реальности, какие данные мы собрали? – например, все доступные. Как их интерпретировать и связывать? Мета-модель в этом случае выступает способом интерпретации данных. И из этого следует, что одни и те же данные можно упорядочить по-разному в зависимости от того, какое исследование данных мы хотим проводить.
Исходя из этого рассуждения можно сделать полезные выводы:
Полезные статьи для продолжения чтения по теме:
