В поисках Святого Грааля бизнес-анализа

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

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

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

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

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

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

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

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

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

Следствие:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что не так?

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

Выводы

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

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

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

Автор: maxstroy

Источник ^[3]