В прошлой статье я говорил о заблуждениях, к которым склонны программисты и обещал рассказать про заблуждения, к которым склонны не только программисты, но и каждый из нас.
Объект учета и результат его классификации (существительные)
Проведем мысленный эксперимент. Представьте себе два хранилища моделей. В одном хранилище созданы классы для хранения моделей плавательных средств, в другом – классы для хранения моделей автомобилей. Допустим, что есть объект, который в одном хранилище описан как объект класса плавсредство, а во второй – как объект класса автомобиль. Допустим, что стоит задача объединения этих хранилищ в одно. Как вы это сделаете?
Возможно, вы создадите подкласс автомобилей, который одновременно является подклассом класса плавсредств, добавите модель в созданный вами подкласс и удалите, теперь ставшие лишними, модель из класса автомобилей и модель из класса плавсредств.
Возможно, вы удалите объект из класса плавсредств, а объект из класса автомобилей одновременно сделаете объектом класса плавсредств.
Как бы вы не поступили, у меня вопрос: как теперь вы назовете моделируемый объект? Автомобиль-плавсредство? А, если потом появятся другие классы, к которым относится этот объект? Будете перечислять их названия через дефис, и говорить: автомобиль-плавсредство-альфа-омега? Если задать этот вопрос аналитику, то ответом будет: это один и тот же объект, одновременно являющийся и автомобилем и плавсредством. Буквально это значит, что есть объект учета, который может быть одновременно классифицирован и как автомобиль, и как плавсредство. Из этого следует, что мы моделируем не автомобили и плавсредства, а объекты учета!
- Создание объекта в хранилище – это моделирование объекта учета
- Помещение созданного объекта в класс – это его классификация.
Поскольку эти две разные операции обычно производятся одновременно, то их не различают. Из-за этого возникает чувство, будто мы моделируем автомобили и плавсредства, хотя на самом деле – объекты учета. Этой путанице способствует наш язык.
Сравните высказывания:
- Это- дерево
- Это- объект учета, классифицированный как дерево.
Второе высказывание корректное, но слишком длинное, чтобы им пользоваться на практике.
ООП наследовал результат этой путаницы, и в нем невозможно разделить операцию по созданию модели объекта от классификации. Поэтому аналитики часто думают, что моделирование предметной области заключается в моделировании машин и плавсредств, а не объектов учета.
В этом смысле стандарт OWL более корректен, потому что в нем можно создать неклассифицированную модель объекта учета. Это позволяет отделить операцию по моделированию объекта учета от операции по его классификации.
Объект учета и результат его классификации (прилагательные)
Когда мы говорим, что машина красная, мы предполагаем, что машина может обладать свойством – быть черной, красной и тд. Но могут ли на самом деле машины иметь свойства?
Продолжим наш мысленный эксперимент. Пусть в двух хранилищах, которые мы рассматривали ранее, есть одноименные атрибуты: у автомобилей — атрибут цвет, и у плавсредств — атрибут цвет. Пусть есть объект, который мы описали как красный автомобиль в одном хранилище, и как красное плавсредство – в другом. Пусть снова стоит задача объединения этих хранилищ в одно. Как вы поступите?
Ранее для моделирования объекта вы создали подкласс автомобилей и плавсредств. Теперь стоит задача моделирования одного цвета вместо двух. Для решения этой задачи вы можете поступить разными способами.
Возможно вы создадите один надкласс для класса автомобилей и класса плавсредств, у которого создадите атрибут цвет. У классов автомобилей и плавсредств вы создадите наследуемые от надкласса атрибуты «цвет». Затем переделаете все объекты, чтобы они соответствовали новому видению.
Возможно, вы определите интерфейс «цвет» и выполните реализацию этого интерфейса в каждом классе.
Что бы вы ни сделали, важно понять, что полученный атрибут «цвет» не будет принадлежать ни автомобилям ни плавсредствам. Это нечто, что существует вне этих классов. И это правильно, поскольку атрибут не связан с типом. Атрибут – это способ деления множества объектов на подмножества другим способом, отличным от типа. Об этом я писал ранее в статье Понятия: множество, тип, атрибут.
.
Поэтому, если быть строгим, нельзя говорить о свойстве, принадлежащем объекту, надо говорить о свойстве независимо от типа, или объекта, например, так:
Объект учета отнесен к классу красных объектов, то есть классифицирован.
Хот я утверждения такого рода являются корректными, на деле говорить подобным образом слишком затратно. Причина в языке. Когда мы передаем информацию другому субъекту, мы стремимся сократить объем выполняемой работы. Сравните высказывания:
- Красный автомобиль
- Объект учета относится к классу автомобилей и к классу красных объектов
В каком случае вы совершили меньше работы? Конечно, в первом. Но беда этого высказывания в том, что он наводит нас на мысль, будто атрибут принадлежит типу, а значение атрибута принадлежит классифицированному объекту.
ООП унаследовал и это заблуждение. С помощью ООП невозможно создать атрибут отдельно от класса (правда для этого можно использовать интерфейсы). И снова OWL нам в помощь: в этом стандарте типы и атрибуты существуют отдельно друг от друга. Поэтому при слиянии двух моделей в OWL нам не придется делать столько работы, сколько пришлось бы делать в ООП. Для слияния надо только объявить два атрибута тождественно равными и более ничего.
Смысл процесса классификации
Пусть есть два хранилища моделей. В одном хранилище хранятся модели операций по продаже инструментов. В другом хранилище хранятся модели операций по покупке инструментов. Пусть есть одна операция, классифицированная в одном хранилище как операция по продаже, исполнителем которой был Мартынов, а в другом хранилище она же классифицирована как операция по покупке, исполнителем которой был Гаврилов. В процессе объединения двух хранилищ стоит задача объединения этих моделей в одну. Вопрос: как в объединенном хранилище представить модель этой операции?
На скорую руку приходит решение о создании новой модели, которая будет моделировать операцию под названием «купля-продажа», исполнителем которой будут Мартынов и Гаврилов. Но тут возникает вопрос: куда делась операция по продаже, исполнителем которой был Мартынов, и куда делась операция по покупке, исполнителем которой был Гаврилов? В новой модели эта информация оказалась потерянной, да еще и возникла коллизия, ведь операция – это такое действие, которое должно иметь цель. У продажи цель есть – продать подороже, и ради нее работал Мартынов. У покупки есть цель – купить подешевле, и ради нее работал Гаврилов. А у купли-продажи нет цели, потому что у нее нет стейкхолдера. Как же сохранить информацию, которая была в хранилищах до их объединения, избежать коллизии и, в то же время, объединить модели операций?
Для этого нам надо поступить так же, как мы поступили с автомобилями. Надо создать модель объекта учета и отнести его к двум разным классам одновременно: к классу операций по продаже и к классу операций по покупке. В разных классах будет один атрибут «исполнитель», значения которого будут зависеть от того, какой класс мы рассматриваем: класс покупок, или класс продаж. И это неожиданно – оказывается, что значения атрибутов одного объекта учета могут зависеть от того, как мы классифицировали объект учета.
Это кажется странным, но здесь нет ничего удивительного. Разные люди могут классифицировать один и тот же объект по-разному. Кто-то считает, что это – машина, а кто-то считает, что это – плавсредство. Для кого-то это — операция по продаже, а для кого-то – операция по покупке. Теперь проясняется смысл классификации. Классификация объекта учета – это выражение определенной точки зрения на объект учета. Нет автомобилей, но есть объект учета и субъект, трактующий этот объект учета как автомобиль. Нет операции по продаже, есть субъект, который трактует объект учета как операцию по продаже.
Тот же смысл имеют значения атрибутов. Есть объект учета и субъект, трактующий этот объект учета как принадлежащий определенному классу значений атрибута.
Поэтому тезисы про автомобиль и плавсредство надо уточнить:
- Объект учета с точки зрения Иванова классифицирован как плавсредство.
- Тот же объект учета с точки зрения Сидорова отнесен к классу плавсредств.
- Тот же объект с точки зрения Иванова и Сидорова отнесен к классу красных объектов.
Говорить что-либо об объекте учета без ссылки на субъект, который провел описание этого объекта, не имеет смысла. Это как-бы очевидно, но почему-то аналитики об этом забывают.
О том, как при помощи OWL можно построить хранилище, в котором будут учтены разнообразные точки зрения, рассказано в статье: Multi-viewpoint Ontologies for Decision-Making Support.
Выводы
Моделирование предметной области – это моделирование объектов учета путем их классификации. Классификация всегда субъективна и потому требует указания на субъект, проведшего классификацию.
Автор: Марк Мельник
