Пою что вижу, или вижу, что пою?

Основная задача бизнес-аналитика при разработке нового ПО – изучение предметной области и формальное описание полученных сведений в виде модели (Domain Model). Аналитик должен петь то, что он видит и то, что он хочет увидеть. Для этого у него должен быть язык, на котором он исполнит свою песню. Однако, аналитик не всегда знаком с подходящим языком, и потому часто пользуется другими языками. Отчасти это происходит по причине того, что управление проектом ведется не с точки зрения предметной области, а с точки зрения реализации. И тогда с аналитиком может произойти несчастье: он может перестать видеть то, что надо петь и начать видеть лишь то, для чего есть слова в словарном запасе используемого им языка. Все остальное перестает для него существовать. Тогда, вместо того, чтобы петь, что он видит, аналитик начинает видеть то, что поет. Должен сразу заметить, я не против языков, я против сужения области анализа, которое возникает по причине недостаточности этих языков.

Что надо помнить?

Для изучения и описания предметной области аналитик должен знать:

• Как мы мыслим?
• Как мы структурируем результаты мышления? Для этого надо знать формальный язык, который подходит для записи результатов нашего мышления ФМ

Поскольку, для записи результатов у аналитика не всегда есть возможность использовать ФМ, то аналитик должен знать еще и это:

• Области знаний, в которых существуют другие языки моделирования. Например, при помощи SQLможно создавать таблицы. Какие-то части этого языка могут быть отражены в ER модели. UML создан для моделирования программ, написанных на объектных языках программирования.
• Как использовать язык, созданный для других целей, в рамках задачи моделирования предметной области? Для этого аналитик должен уметь отмаппиться с ФМ на другой язык. То есть, он должен понимать, как происходит перекладывание тех или иных конструкций, записанных на языке ФМ, в конструкции другого языка, например, UML.

Нерешенные проблемы

• Существует разрыв между ФМ и языками моделирования, которые используются в программировании.
• При этом есть претенденты на звание ФМ, но ни один из них пока не стал общепризнанным. Пока в программах ВУЗов нет курсов, посвященных этой теме. А пока нет темы, нет вопросов.

Следствие:

Принято считать, что языки UML, а также ER –модели можно использовать для моделирования предметных областей без ограничений. Поэтому аналитики пытаются моделировать предметную область в UML, или ER даже тогда, когда ограничения, накладываемые языком моделирования, не позволяют сделать это корректно.

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

Экскурс в историю

В Европе первым, кто попытался дать ответ на вопрос о том, как мы структурируем результаты нашего мышления, был Аристотель. Он решил, что наше сознание работает так: все предметы, которые мы видим, мы относим к определенным типам. Тип – это, по Аристотелю, перечень атрибутов, которыми описываются экземпляры этого типа. Каждый экземпляр представлен в модели упорядоченными значениями этих атрибутов. Предположение Аристотеля родилось на основании того, что запись об объектах нашего мира изначально велась в виде табличек с данными. Аристотель дал картину, но он не обладал теми знаниями, которыми мы обладаем сейчас, и потому его картина типов должна быть дополнена еще одним свойством. Это свойство я пока не озвучу, оставив его вам. Таким образом:

• таблица – это свод знаний о типе и экземплярах этого типа
• строка параметров — это тип
• заголовок в строке параметров — это название параметра
• строка значений – это экземпляр данного типа
• значение в строке значений — конкретный признак данного экземпляра

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

Также мы встречаем такие таблицы:

Что изображено на этой таблице? Ответ на вопрос можно дать двумя способами. И оба будут верны. Я дам вам самим подумать над вопросом: что моделирует эта таблица? И что значат данные в этой таблице?

Два разных значения одного и того же высказывания

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

• Можно сказать, что объект, который я держу в руках, имеет свойство. Это свойство объекта — быть книгой под названием «Три мушкетера (интенсиональный контекст)
• Можно сказать, что перед нами объект (элемент) класса книг «Три мушкетера». Такое высказывание говорит об экстенсиональном контексте

В представлении Аристотеля мы работаем только в интенсиональном контексте, где все объекты имеют определенные свойства. Данный класс представлений зафиксирован в онтологическом стандарте MOF. На этом стандарте строится и ER-модели, и ООП. Вопрос: действительно ли данный метод типизации объектов дает нам представление о том, как мы мыслим и о том, как структурируем свои знания? Для того чтобы разобраться так ли это, нам понадобится провести эксперимент.

Сотрудники и эксперименты

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

Ровно до тех пор, пока сотрудник не станет работать над двумя экспериментами сразу. Тогда мы не сможем завести параметр «Эксперимент», потому что отношения между сотрудниками и экспериментами сразу становятся многие ко многим.
Моделировать эту связь в терминах признаков уже не удается. Придется создавать новый тип сущности «Связь», который хранит ссылку на сотрудника и на эксперимент, но сам по себе ничего не значит. Таких объектов просто нет в природе!

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

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

Яблони и ареалы

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

Первый вариант реализации

Можно создать статическую переменную у класса «Яблони». Что значит эта переменная? Эта переменная создается для объектов данного класса одна на всех. Вопрос: эта переменная класса, или объектов класса? Логически мы можем сделать вывод: если значение переменной доступно объектам класса, то это переменная объектов класса, а не класса объектов! То есть, создание статической переменной не решит задачу создания переменной класса. Таким образом, мы приходим ко второму способу реализации задачи.

Второй вариант реализации

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

Что не так?

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

Выводы

• Мы увидели, что моделирование в категориях типов или классов ООП приводит нас к тому, что построенные модели, нерасширяемы. То есть, необходимо построить структуру данных заранее на вырост, иначе потом уже не получится расширить функционал без поломки уже существующего функционала.
• Анализ противоречий Аристотелевской логики привел к развитию теории множеств. Сначала примитивной теории, предложенной Кантором, а затем и современной. В одной из аксиоматик современной теории множеств термин множество заменен на термин класс, чтобы подчеркнуть различие между ними. Но это не те классы, к которым все привыкли (классы ООП).
• Оказывается, что модель мира, которую мы создаем, много богаче той, которую мы обычно записываем на бумаге в виде текста, или таблицы. Было потрачено очень много усилий, чтобы понять, как работает наше сознание при создании модели сущего, и того, как ее следует записывать.

Давайте посмотрим, как теория множеств справляется с этими задачами (Продолжение следует).

P.S. Можно подумать, что я против моделирования предметной области в классических нотациях. Нет, я лишь хочу, чтобы мы умели мыслить, умели эти мысли доносить и отражать их в модели корректным способом.

Автор: maxstroy

Источник