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

Понимание и познание

Когда мы описываем предметную область, мы думаем, что пытаемся ПОЗНАТЬ ее, а на самом деле занимаемся ПОНИМАНИЕМ предметной области и описанием своего понимания. Разницу между знанием и пониманием стоит подчеркнуть. Дело в том, что те модели, которые мы строим, являются субъективными, и потому являются отражением нашего понимания предмета, но не знания о предмете. Причина, по которой знание недостижимо, – это противоречивость того способа, который мы выбрали в качестве инструмента познания – расчленение объекта на части (анализ) и сборка их вместе (синтез) Моделирование объекта как целого и как композиции. Поэтому можно сказать, что мы нацелены прежде всего на понимание, но не на познание. Вопросами понимания занимается герменевтика. Понимание у каждого свое. Нет смысла спорить о том, у кого оно лучше или хуже. Можно спорить лишь о том, какое понимание способно объяснить более широкий круг практических задач, или является непротиворечивым в рамках определенных аксиом. Требовать от понимания большего нельзя. Например, я могу утверждать, что та модель, которую я предлагаю к рассмотрению, более полно описывает наше представление о реальности, чем модель, построенная на принципах реляционных данных. Но не могу сказать, что предлагаемая мной модель верно описывает наше представление о мире. Те же, кто не видят разницы между пониманием и знанием, часто претендуют в своих спорах на знание истины. Если рассуждать логически, и предположить, что истина постижима, то результатом ее постижения стало бы невозможность выразить его словами.

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

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

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

В статье «Моделирование объекта как целого и как композиции» я рассмотрел два подхода к моделированию объекта: как целого и как конструкции. В текущей статье нам это деление понадобится.

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

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