Оценка авторской мысли

Какова цель автора?

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

На какой вопрос автор пытается дать ответ?

Каким образом мы можем точно отмоделировать бизнес и отразить эту модель в компьютерной системе?

Какую информацию автор использует в своих умозаключениях?

Каковы главные выводы автора?

Каковы основные концепты и идеи в мышлении автора?

Из каких предположений исходит автор?

С какой позиции автор рассматривает вопрос?

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

Если автор прав, то что из этого следует?

Конспект

Предисловие и пролог

• Два этапа реинжиниринга как пример концептуализации и абстрагирования
• неверное понимание объектов мешает точному моделированию

1. Стратегия реинжиниринга

• Ошибочные предположения в современном бизнес-моделировании
• Сдвиг парадигмы приводит к радикально новому взгляду на мир
• Используемая парадигма может быть сколь угодно старой и даже устаревшей, в том смысле, что уже есть и известны теории/парадигмы, которые более точно описывают мир. Однако возраст или актуальность парадигмы не так важны, как ее пригодность для решения конкретных задач.
• Четыре основные частицы любой информационной парадигмы
• Необходимо реинжинирить бизнес-уровень (прикладную часть, бизнес-модель), потому что это приводит к повышению точности/accuracy модели, что в свою очередь позволяет переиспользовать составные части (это как точность изготовления деталей позволила перейти на стандартные компоненты), а также потому что это предотвращает экспоненциальный рост затрат на разработку модели и ее реализацию в компьютерной системе. Каждый паттерн дает возможность обобщить и упростить систему, а не требует (как в случае сущностной парадигмы) увязки со все возрастающим количеством существующих паттернов.

2. Сущностная парадигма

• Особенности сущностной (entity) информационной парадигмы
• Особенности субстанциальной (substantial) информационной парадигмы

3. Логическая парадигма

Центральный принцип логической (и объектной парадигмы) - это принцип сильной референции. Он гласит, что каждый знак (концепт, sign) в модели реферирует к одному и только одному объекту. И наоборот, к каждому объекту однозначно реферирует один и только один знак. Это приводит к правилу “все есть объект” в ООП, например.

В логической парадигме есть одно проблемное место - определение идентичности объекта с течением времени. Эта жа проблема существует и для классов. То есть, моя машина - это один объект сегодня, т.к. занимает определенное место в пространстве. Но вчера она занимала другое место, значит, это был другой объект. Если же говорить о классе “машины”, то мы вынуждены каждый раз при изменении объекта-члена класса пересоздавать класс заново. Каким же образом класс “машины” остается тем же самым с течением времени, если он постоянно пересоздается? Логическая парадигма не может ответить на этот вопрос.

4. Переход к объектной парадигме

Виды объектов:

• физическое тело (4D-экстент)
• класс
• кортеж
• событие

Операционный уровень и уровень понимания

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

---

4Д-экстенсионализм как критерий идентичности объекта

Очень разрозненные объекты можно соединять (fusion) в физический объект “вещь”(stuff), который является частью объекта “всеобщая вещь” (overall stuff). Пример - молоко в стакане на столе и в кувшине в холодильнике. Их можно объединить (fuse) в один объект “молоко у меня дома”, и этот объект будет частью объекта “все молоко в мире”. Такой всеобщий объект также включает все молоко, которое существовало в мире раньше и будет существовать впредь. Поэтому он является очень “разрозненным/несвязным” (disconnected).

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

Четырехмерный экстенсионализм пока не получил достаточно хорошего отражения в языке. Для трехмерных тел мы успешно используем языковые конструкции вроде “Х является частью У”, но для четырехмерных объектов у нас пока нет устоявшейся общепринятой терминологии. “Х совпадает с У” или “Х перекрывает У”?

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

Изменения как трехмерные объекты

В субстанциальной парадигме состояние - это субстанция, обладающая определенным “привнесенным” атрибутом. В объектной семантике состояние должно быть объектом и должно к чему-то реферировать, то есть обладать протяженность в пространстве-времени либо напрямую, либо косвенно (через коллекцию других объектов). Состояние, таким образом, можно определить как временнУю часть объекта, то есть, пространственно полностью совпадающую с исходным объектом, но являющейся лишь его частью с точки зрения времени.

Наше повседневное, обывательское понимание состояния недостаточно точно описывает этот взгляд.

Состояния в бизнес-моделировании часто формируют иерархии с помощью двух паттернов:

1. Надсостояние - подсостояние. Состояния могут быть частью других состояний, это переиспользование паттерна “часть-целое”.
2. Состояние - подкласс. То есть, выделенные состояния могут быть подклассами основного состояния. Так происходит, когда мы можем выделить “взаимоисключающие” состояния, т.е. такие, которые не могут быть разными временнЫми частями одного объекта. Например, гусеница у бабочки может быть либо красной, либо зеленой, это явно состояния бабочки (зеленая гусеница и красная гусеница), но при этом смены цвета быть не может. Таким образом гусеницы каждого цвета образуют подклассы состояния “гусеница”.

Состояния не обязательно должны быть отдельными и изолированными с точки зрения иерархий, они вполне могут перекрываться. Пример с зараженной гусеницей (состояние “зараженности”), которая превращается в куколку, а затем “выздоравливает”. В этом примере состояние “зараженности” для бабочки перекрывает два других состояния: “гусеница” и “куколка”. Состояния-подклассы тоже могут перекрываться, “большие гусеницы” могут быть как “красными гусеницами”, так и “зелеными гусеницами”.

Состояние как объект НИКОГДА не меняется!

Компонент (или роль) - это сумма/сплав/fusion состояний разных объектов. Пример с машиной и заменой шин. У машины есть компонент “шина переднего правого колеса” (это роль, функциональный объект), в разное время на этом месте установлены разные шины. То есть, компонент - это сумма всех тех временнЫх частей (состояний) разных шин, в течение которых шины были установлены на это место. Другими словами, компонент в данном примере - это часть машины, и это сплав состояний разных шин. Таким образом из рассмотрения устраняется течение времени и загадочные “изменения”.

Некоторые объекты, состояние которых не изменяется (хотя может), являются состоянием для самих себя. На самом деле это означает, что такой объект входит в два класса - свой основной (например, человек) и в класс состояния (например, мужчина). Если пол не изменять, то объект всегда будет входить в эти два класса, и объект состояния совпадет с объектом полностью (а значит, это один и тот же объект).

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

Кортежи можно (и нужно) создавать из состояний (т.к. это вполне валидные объекты). Тогда, например, смена владельца машины будет описываться двумя кортежами типа “владеет”: “Владелец А, машина во владении А” и “Владелец Б, машина во владении Б”. При этом состояния машины прекрасно ложатся на ось времени, как стадии жизненного цикла бабочки.

Изменение не сохраняется во времени, у него нет протяженности (экстента) по оси времени, но есть протяженность по другим измерениям. Может показаться странным, что мгновенный срез объекта во времени имеет какой-то смысл, но это в бытовом понимании. Мгновенный срез объекта - это всего лишь референция, а смысл появляется в связи с другими объектами, и для изменений это крайне важно.

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

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

5. Условные обозначения

• Условные обозначения для бизнес-объектов

Условные обозначения для паттернов бизнес-объектов.

Индивиды могут быть как полностью раздельными (в пространстве-времени), так и частично перекрываться (это за исключением отношений полного включения, т.е. “истинная часть”, “часть-целое”). Раздельность наследуется вниз по иерархии частей-целых, а частичное перекрытие - вверх по иерархии. То есть, если два объекта полностью разделены, то все их части (и их части) наследуют полную раздельность. Если два объекта частично перекрываются, то все их целые (в которые они входят частями) так же частично перекрываются.

6. Использование бизнес-объектов

Важное разделение на уровни модели: фреймворка, приложения и операций.

Суть в том, что есть базовые типы (это вроде как верхняя онтология), используемые для моделирования, и это уровень фреймворка.

Некоторые классы и некоторые индивиды заложены в модель приложения, конечные пользователи никогда не создают эти объекты в момент использования системы (как пример индивида - Нац.Банк, который всегда присутствует в приложении, но никто его в рантайме не создает). Это “время проектирования” системы, уровень приложения.

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

---

Обычно создатели систем применяют неформальный анализ издержек и выгод, решая, что войдет в состав модели и вообще системы. Как правило, это что-то вроде Парето-анализа, который приводит к тому, что в систему попадает (говоря о разработке ПО, это означает “автоматизируется”) 20% предметной области, приносящие 80% выгоды. Это действительно так, т.к. обычно именно такова доля простых, повторяющихся операций, которые можно легко автоматизировать. В результате получается та же история, которую озвучила Maggie Appleton в докладе Home-Cooked Software. То есть, огромное количество функций не будут автоматизированы, потому что они, во-первых, слишком сложны (т.е. их анализ и реализация потребует больших затрат), а во-вторых, они слишком нишевые (т.е. не могут обеспечить достаточно высокую выручку).

В основе этого подхода лежит два предположения:

• сложная часть предметной области должна быть автоматизирована сложным кодом;
• выгода от анализа сложной части предметной области проявляется только во время ее автоматизации, т.е. создания этого сложного кода.

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

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

Такое ощущение, что это очередной пример мантры “Make it work, make it right, make it fast” - сначала составить модель предметной области (любую, лишь бы работала), затем упростить и (главное!) обобщить ее, и только потом думать о технических оптимизациях.

А вот работа по упрощению и обобщению модели - это Концептуализация и абстрагирование идеи.

---

---