В чем заключается моделирование предметной области при проектировании по

Как запутать аналитика. Часть вторая: что такое моделирование предметной области?

В прошлой статье я говорил о заблуждениях, к которым склонны программисты и обещал рассказать про заблуждения, к которым склонны не только программисты, но и каждый из нас.

Объект учета и результат его классификации (существительные)

Проведем мысленный эксперимент. Представьте себе два хранилища моделей. В одном хранилище созданы классы для хранения моделей плавательных средств, в другом – классы для хранения моделей автомобилей. Допустим, что есть объект, который в одном хранилище описан как объект класса плавсредство, а во второй – как объект класса автомобиль. Допустим, что стоит задача объединения этих хранилищ в одно. Как вы это сделаете?

Возможно, вы создадите подкласс автомобилей, который одновременно является подклассом класса плавсредств, добавите модель в созданный вами подкласс и удалите, теперь ставшие лишними, модель из класса автомобилей и модель из класса плавсредств. Возможно, вы удалите объект из класса плавсредств, а объект из класса автомобилей одновременно сделаете объектом класса плавсредств.

Как бы вы не поступили, у меня вопрос: как теперь вы назовете моделируемый объект? Автомобиль-плавсредство? А, если потом появятся другие классы, к которым относится этот объект? Будете перечислять их названия через дефис, и говорить: автомобиль-плавсредство-альфа-омега? Если задать этот вопрос аналитику, то ответом будет: это один и тот же объект, одновременно являющийся и автомобилем и плавсредством. Буквально это значит, что есть объект учета, который может быть одновременно классифицирован и как автомобиль, и как плавсредство. Из этого следует, что мы моделируем не автомобили и плавсредства, а объекты учета!

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

В этом смысле стандарт OWL более корректен, потому что в нем можно создать неклассифицированную модель объекта учета. Это позволяет отделить операцию по моделированию объекта учета от операции по его классификации.

Объект учета и результат его классификации (прилагательные)

Когда мы говорим, что машина красная, мы предполагаем, что машина может обладать свойством – быть черной, красной и тд. Но могут ли на самом деле машины иметь свойства?

Продолжим наш мысленный эксперимент. Пусть в двух хранилищах, которые мы рассматривали ранее, есть одноименные атрибуты: у автомобилей — атрибут цвет, и у плавсредств — атрибут цвет. Пусть есть объект, который мы описали как красный автомобиль в одном хранилище, и как красное плавсредство – в другом. Пусть снова стоит задача объединения этих хранилищ в одно. Как вы поступите?

Ранее для моделирования объекта вы создали подкласс автомобилей и плавсредств. Теперь стоит задача моделирования одного цвета вместо двух. Для решения этой задачи вы можете поступить разными способами.

Возможно вы создадите один надкласс для класса автомобилей и класса плавсредств, у которого создадите атрибут цвет. У классов автомобилей и плавсредств вы создадите наследуемые от надкласса атрибуты «цвет». Затем переделаете все объекты, чтобы они соответствовали новому видению.
Возможно, вы определите интерфейс «цвет» и выполните реализацию этого интерфейса в каждом классе.

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

Объект учета отнесен к классу красных объектов, то есть классифицирован.

Хот я утверждения такого рода являются корректными, на деле говорить подобным образом слишком затратно. Причина в языке. Когда мы передаем информацию другому субъекту, мы стремимся сократить объем выполняемой работы. Сравните высказывания:

ООП унаследовал и это заблуждение. С помощью ООП невозможно создать атрибут отдельно от класса (правда для этого можно использовать интерфейсы). И снова OWL нам в помощь: в этом стандарте типы и атрибуты существуют отдельно друг от друга. Поэтому при слиянии двух моделей в OWL нам не придется делать столько работы, сколько пришлось бы делать в ООП. Для слияния надо только объявить два атрибута тождественно равными и более ничего.

Смысл процесса классификации

Пусть есть два хранилища моделей. В одном хранилище хранятся модели операций по продаже инструментов. В другом хранилище хранятся модели операций по покупке инструментов. Пусть есть одна операция, классифицированная в одном хранилище как операция по продаже, исполнителем которой был Мартынов, а в другом хранилище она же классифицирована как операция по покупке, исполнителем которой был Гаврилов. В процессе объединения двух хранилищ стоит задача объединения этих моделей в одну. Вопрос: как в объединенном хранилище представить модель этой операции?

На скорую руку приходит решение о создании новой модели, которая будет моделировать операцию под названием «купля-продажа», исполнителем которой будут Мартынов и Гаврилов. Но тут возникает вопрос: куда делась операция по продаже, исполнителем которой был Мартынов, и куда делась операция по покупке, исполнителем которой был Гаврилов? В новой модели эта информация оказалась потерянной, да еще и возникла коллизия, ведь операция – это такое действие, которое должно иметь цель. У продажи цель есть – продать подороже, и ради нее работал Мартынов. У покупки есть цель – купить подешевле, и ради нее работал Гаврилов. А у купли-продажи нет цели, потому что у нее нет стейкхолдера. Как же сохранить информацию, которая была в хранилищах до их объединения, избежать коллизии и, в то же время, объединить модели операций?

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

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

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

Поэтому тезисы про автомобиль и плавсредство надо уточнить:

О том, как при помощи OWL можно построить хранилище, в котором будут учтены разнообразные точки зрения, рассказано в статье: Multi-viewpoint Ontologies for Decision-Making Support.

Источник

Знакомство с парадигмами построения моделей предметной области

Введение

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

Давайте зададим аналитикам простой вопрос.

Те, кто моделировал процессы, наверно, знакомы с нотацией BPMN. Очень часто при моделировании операции по заключению договора я встречаю такой фрагмент диаграммы:

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

Как мы строим модель сущего?

Посмотрите на рисунок. На нем схематично изображен процесс построения модели сущего.

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

Если мы делаем ДОПУЩЕНИЕ, что мир ДЕЙСТВИТЕЛЬНО состоит из 4-Д пространства-времени и объектов в нем расположенных, то картинку можно перерисовать так:

Особенности парадигм

Для описания мира мы обычно используем две парадигмы: парадигму Аристотеля и логическую парадигму. Обе они покоятся на предположении о том, что мир предметен и представляет из себя 4-Д пространство-время. Но между парадигмами есть различия, которые я должен подчеркнуть.

Хорошо, когда парадигма и нотация согласованы. Тогда возможности парадигмы будут полностью использованы. И тогда становится возможным «мышление при помощи записей». То есть, можно будет рисовать представление модели одновременно с ее созданием. Так мыслят многие, когда, например, пишут статьи, рисуют картины, или чертят чертежи.

С парадигмой Аристотеля согласуется моделирование в виде таблиц. Однако связи между таблицами – это то, что Аристотель не планировал. Поэтому нотация ER-диаграмм, хоть и основана на парадигме Аристотеля, но выходит за ее границы. Нотация диаграмма классов также идет за пределы парадигмы Аристотеля и не согласуется с ней. Она служит для моделирования программного кода. В предметном мире вы не найдете ни наследования, ни инкапсуляции. Все эти термины программирования, а не предметной области. Для описания предметной области диаграммы классов и ER-диаграммы подходят, как сказал Левенчук одной из своих статей, между плохо и очень плохо. Многие не знают этих ограничений, и потому считают, что ограничений нет вообще. Это заблуждение лечится только одним способом – изучением логической парадигмы. Для логической парадигмы используется две нотации, описанные в стандарте ИСО 15926.

Существует спор между инженерами и философами. Инженеры часто упрекают философов, что те, мол, занимаются словоблудием. Философы говорят о том, что если бы не их словоблудие, не было бы инженеров. А математики молчат. Но фокус в том, что математика и философия до 20-го века были слиты вместе. Декарт и Кантор – великие философы – математики. Задача была простая. Мало было придумать парадигму, надо было придумать нотацию для передачи моделей в этой парадигме другим гражданам, а также надо было уметь проверить парадигму на непротиворечивость. Решением этой задачи занималась наемница философии – математика. Но в 20-м веке Рассел предположил, что надо отделить математику от философии. Просто потому что математика давала результаты слишком далекие от нашего эмпирического опыта. И вместо того, чтобы постулировать ограниченность нашего опыта, Рассел поступил в духе антропоцентризма, — он предложил более не думать над смыслом математических открытий. Молодец! Мы пожинаем плоды этого разделения сейчас. Теперь мало, кому известны парадигмы и для чего они существуют. Плодятся множество нотаций, оторванных от парадигм, задача которых удовлетворить потребности здесь и сейчас. А то, что они противоречивы и границы их возможностей не описаны, — это мало кого волнует. Жаль, потому что в результате нотации массово используется для построения моделей предметных областей людьми, которые не знают ограничений этих нотаций. Однако, не все так плохо. Есть те, кому это известно. В книге на странице 36-37 написано:

Программные объекты в некотором смысле соответствуют объектам реального мира, но не являются их точными моделями или копиями. Хотя полученная диаграмма классов проектирования не до конца соответствует модели предметной области, некоторые имена классов и их характеристики совпадают. Объектно-ориентированные проектные решения и языки позволяют уменьшить разрыв между представлением информации в виде программных компонентов и ментальными моделями предметной области. Это улучшает образность представления.

Хорошо, когда создаваемые модели удовлетворяют свойствам: полнота (все, что мы хотели сказать, должно присутствовать в модели), непротиворечивость (одна часть описания должна не противоречить другой части), расширяемость (добавление новых данных не должно приводить к возникновению противоречий). Для того, чтобы модель имела указанные свойства, парадигма построения моделей должна позволять это сделать. Парадигма Аристотеля не удовлетворяет требованию непротиворечивости и расширяемости моделей. Именно поэтому на смену Аристотелевской пришла логическая парадигма, основанная на теории множеств.

Построение одной модели более чем для одного объекта

Построив одну модель для одного объекта, можно попробовать посмотреть, насколько она подходит другому объекту. Или так: можно сразу строить модель с учетом того, что она будет описывать много объектов реального мира. Так мы получаем одну универсальную модель для множества объектов одновременно. Это очень облегчает задачу описания реального мира. Мы находим предметы чем-то похожие друг на друга и описываем их одной моделью. Конечно, некоторые индивидуальные черты придется «дописывать» для каждой модели отдельно, но это мелочи по сравнению с индивидуальным описанием каждого объекта отдельно. Именно так мы поступаем, когда создаем чертеж, на основании которого потом может быть создан один функциональный объект, а может и много! Эти объекты образуют множество, или класс. Про любой объект этого класса можно сказать, что чертеж является его моделью. Аристотель использовал другую риторику. Он говорил, что чертеж — есть описание типа объектов. А объекты — есть экземпляры этого типа.

Как поступает сценарист, пишущий сценарий? Он делает сценарий, а будет ли поставлен по нему спектакль и сколько будет в итоге представлений, — он не знает. Сценарий может быть моделью одного выступления, например, празднования Нового 2015 года. Или он может моделировать множество выступлений, как, например, сценарий балета Щелкунчик. Понятно, что сценарий – один, а выступлений – много. В логической парадигме это описание выглядело бы так: есть множество всех выступлений, подмножество этого множества – есть выступления, сделанные на основе сценария «Балет Щелкунчик».

То же самое в парадигме Аристотеля выглядело бы так. Есть объекты — выступления. Любое выступление – есть экземпляр выступления. Есть объекты другого типа – это выступления, сделанные по одному сценарию «Балет Щелкунчик». Любое выступление по этому сценарию – это экземпляр выступления «Балет Щелкунчик». Одно и то же выступление одновременно является экземпляром выступления и экземпляром выступления «Балет Щелкунчик». При этом Аристотель сейчас должен немного заволноваться, потому что он такого не говорил! У него нет того, что один объект может принадлежать разным типам! Это уже наша интерпретация, основанная на моделировании в виде ER-диаграмм. Это и еще много чего не позволяют построить непротиворечивую модель предметной области на основе парадигмы Аристотеля.

Модель информационных объектов

Таким образом, в логической парадигме объектам одного множества может быть поставлена в соответствие одна модель:

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

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

Множество информационных моделей описывается моделью информационных объектов. Модель эта находится в головах и людей. Эта модель порождается в результате применения специальной парадигмы, которая рассматривает объект предметной области как информационный. Потом после применения нотации модель информационных моделей может быть выражена в виде представлений этой модели.

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

Договор

Если применить построенную конструкцию к нарисованной в самом начале статьи диаграмме, то у нас возникают вопросы: что такое договоренность? Это реальность, или модель реальности? Что такое договор? Что такое листочки с печатями? Что такое файл в формате MS Word? Что такое запись в БД? И что она фиксирует: договор, договоренность, реальность?
Я нарисовал кусок модели, начиная с договоренности, но не расшифровывал, что такое сама договоренность.

Мы видим, что реальная модель предметной области довольно сложна. При этом мы не нарисовали всех подробностей и не нарисовали всех уровней модели, потому что умение работать с MS Word не предполагает знания формата хранения данных. А знание формата хранения данных не означает знание правил управления печатной головкой. И так далее. Есть физические объекты и субъекты, есть информационные объекты и функциональные, и связаны они порой довольно сложными иерархическими связями. Надо учиться эти связи моделировать и передавать другим в качестве знаний.
Например, 7-ми уровневая сетевая модель OSI – есть иерархическая модель физических и информационных объектов.

В сокращенном варианте приведенная модель выглядит так:

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

Мы дальтоники. Только не в смысле: цвета не различаем, нет. Мы не различаем смысл слов, употребляемых в разном контексте.

То, что мы говорим сокращенные фразы, смысл которых определяется контекстом, — это вынужденная мера для выживания. Мы должны иметь возможность быстро изъясняться: Глянь: голодный волк! вместо: Погляди: объект, принадлежащий множеству волков, одновременно принадлежит классу голодных живых существ! Но, употребляя сокращенные фразы, мы не должны забывать об их полном смысле, и должны уметь этот смысл восстанавливать. Однако, пока происходит обратный процесс: используя сокращенные элементы языка, мы все дальше и дальше удаляемся от понимания того, что скрывается за ними.

Когда я еду в деревню, то готовлюсь к празднику слуха. Разговор деревенских полон смысла, оттенков и музыки. Я вижу, что, произнося слова, деревенский житель не просто жонглирует ментальными конструкциями, как это принято в городской среде, он одновременно переживает и образы, скрытые за словами, и погружен всем своим существом в контекст, в котором живут эти образы. Переживание образов и контекста как основы удерживает целостность конструкций, и не дает повода для возникновения противоречий.

В отличие от деревенского, городской житель, наученный восприятию слов в отрыве от контекста, может использовать стандартные языковые шаблоны. Это приводит к потере сначала контекста, а потом и размытию смысла самих слов. Отрыв слов от контекста не позволяет удержать целостность и непротиворечивость конструкций. В итоге происходит подлог: набор языковых паттернов подменяет знание. Поскольку слушателями такого человека часто являются такие же как и он, — неспособные одновременно удерживать в сознании и смысл и контекст, то этот фокус проходит. Я встречаю мастеров жонглирования словами. Это те, кто умеют менять контекст, и в соответствии с этим менять языковые паттерны: психотерапевты, учителя, мошенники и хорошие политики, хорошие аналитики. А вот плохие учителя, например, не понимают в чем секрет такой гибкости и умеют лишь имитировать действия хороших. Секрет прост – переживание контекста дает возможность сохранять целостность, а умение менять контекст, дает возможность творить.

Источник

Методологии моделирования предметной области

Структурная модель предметной области

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

Предварительное моделирование предметной области позволяет сократить время и сроки проведения проектировочных работ и получить более эффективный и качественный проект. Без проведения моделирования предметной области велика вероятность допущения большого количества ошибок в решении стратегических вопросов, приводящих к экономическим потерям и высоким затратам на последующее перепроектирование системы. Вследствие этого все современные технологии проектирования ИС основываются на использовании методологии моделирования предметной области.

К моделям предметных областей предъявляются следующие требования:

Структурный аспект предполагает построение:

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

Графическое изображение нередко оказывается наиболее емкой формой представления информации. При этом проектировщики должны учитывать, что графические методы документирования не могут полностью обеспечить декомпозицию проектных решений от постановки задачи проектирования до реализации программ ЭВМ. Трудности возникают при переходе от этапа анализа системы к этапу проектирования и в особенности к программированию.

Главный критерий адекватности структурной модели предметной области заключается в функциональной полноте разрабатываемой ИС.

Оценочные аспекты моделирования предметной области связаны с разрабатываемыми показателями эффективности автоматизируемых процессов, к которым относятся:

Объектная структура

Объект — это сущность, которая используется при выполнении некоторой функции или операции (преобразования, обработки, формирования и т.д.). Объекты могут иметь динамическую или статическую природу: динамические объекты используются в одном цикле воспроизводства, например заказы на продукцию, счета на оплату, платежи; статические объекты используются во многих циклах воспроизводства, например, оборудование, персонал, запасы материалов.

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

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

Источник