Что такое состояние объекта?
Состояние объекта — это набор изменяющихся во времени параметров, которые описывают объект. Учитывается и протекание процессов внутри самого объекта и воздействие управляющих устройств. Так же это переменные свойства — изменение состава, отношений и связей.
Объектом может быть предмет, человек, вещество, система, отвлеченное понятие и многое другое.
- Больной находится в тяжелом состоянии — это характеристика протекания процессов внутри самого объекта.
- Вода (вещество) в жидком, твердом или газообразном состоянии — изменение состава объекта.
Даже совокупность материального имущества человека (капитал), называют его состоянием.
Термины, относящиеся к состоянию объекта
"ГОСТ Р 27.102-2021. Национальный стандарт Российской Федерации. Надежность в технике. Надежность объекта. Термины и определения" (утв. и введен в действие Приказом Росстандарта от 08.10.2021 N 1104-ст)
Термины, относящиеся к состоянию объекта
12 исправное состояние (исправность): Состояние объекта, в котором все параметры объекта соответствуют всем требованиям, установленным в документации на этот объект.
Примечание — См. примечание 2 к пункту 15.
perfect (flawless) state
13 неисправное состояние (неисправность): Состояние объекта, в котором хотя бы один параметр объекта не соответствует хотя бы одному из требований, установленных в документации на этот объект.
Примечание — См. примечание к пункту 15.
imperfect state (flaw)
14 работоспособное состояние: Состояние объекта, в котором значения всех параметров, характеризующих его способность выполнять заданные функции, соответствуют требованиям нормативной и технической документации.
1 Отсутствие необходимых внешних ресурсов может препятствовать работе объекта, но это не влияет на его пребывание в работоспособном состоянии.
2 См. примечание 2 к пункту 15.
15 неработоспособное состояние: Состояние объекта, в котором значение хотя бы одного из параметров, характеризующих способность объекта выполнять заданные функции, не соответствует требованиям документации на этот объект.
1 Для сложных объектов возможно деление их неработоспособных состояний. При этом из множества неработоспособных состояний выделяют частично неработоспособные состояния, в которых объект способен частично выполнять требуемые функции.
2 Исправный объект всегда работоспособен, неисправный объект может быть как работоспособным, так и неработоспособным. Работоспособный объект может быть исправен и неисправен, неработоспособный объект всегда неисправен.
16 состояние готовности (объекта): Состояние неработающего работоспособного объекта, в котором объект может выполнять требуемые функции в заданных условиях применения при условии, что все необходимые внешние ресурсы обеспечены.
1 Работоспособный объект не всегда находится в состоянии готовности (при отсутствии необходимых ресурсов).
2 Объект, находящийся в резерве, может в некоторых случаях подвергаться воздействию рабочих параметров резервируемого объекта.
availability status (of item)
17 рабочее состояние: Состояние объекта, в котором он выполняет хотя бы одну требуемую функцию.
Примечание — Работающий объект может находиться в работоспособном или в частично неработоспособном состоянии.
18 нерабочее состояние: Состояние объекта, в котором он не выполняет ни одной из требуемых функций.
Примечание — Неработающий объект может находиться в любом из состояний, приведенных в пунктах 12 — 15.
19 предельное состояние: Состояние объекта, в котором его дальнейшая эксплуатация недопустима или нецелесообразна, либо восстановление его работоспособного состояния невозможно или нецелесообразно.
Примечание — Недопустимость дальнейшей эксплуатации устанавливают на основе критериев предельного состояния объекта.
20 критерий предельного состояния: Признак или совокупность признаков, установленных в документации, появление которых свидетельствует о возникновении предельного состояния объекта.
1 В зависимости от условий эксплуатации для одного и того же объекта могут быть установлены два и более критериев предельного состояния.
2 Предельное состояние может возникнуть как в результате внутренних процессов/причин, так и внешних воздействий на объект в процессе его функционирования.
limiting state criterion
21 опасное состояние: Состояние объекта, которому соответствует высокая вероятность или высокая значимость неблагоприятных последствий для людей, окружающей среды и материальных ценностей.
Примечание — Опасное состояние может возникнуть как в результате отказа, так и в процессе работы объекта.
22 техническое состояние: Состояние объекта в определенный момент времени, при определенных условиях внешней среды, характеризующееся фактическими значениями параметров, установленных в документации.
23 состояние резервирования: Нерабочее состояние работоспособного объекта, находящегося в резерве, в течение заданного периода времени.
Примечание — В некоторых случаях объект, находящийся в резерве, может подвергаться воздействию рабочих параметров резервируемого объекта.
NEWOBJ.ru → Введение в ООП с примерами на C# →
Состояние объекта (state) – перечень полей объекта (обычно статический) и текущих значений каждого из этих полей (обычно динамический).
Мы оговариваем, что перечень полей обычно статический, то есть зафиксированный в определении класса, так как в некоторых языках перечень полей может быть изменен после создания объекта.
Мы оговариваем, что перечень текущих значений полей обычно динамический, то есть может меняться после создания объекта, так как во всех языках есть механизмы, позволяющие ограничить изменение полей после создания объекта. Мы обсудим некоторые из таких возможностей в следующем параграфе.
В настоящей книге мы используем термин поле ( field ), так как оно используется в C#. При этом в других языках программирования для обозначения полей класса могут применяться и другие термины: переменная-член ( member variable, member ), свойство ( property ). Отметим, что термин свойство, в свою очередь, имеет в C# специфическое значение и будет рассмотрен ниже в настоящей главе.
Приведем определение поведения объекта аналогичное определению состояния объекта [3].
Поведение объекта (behavior) — перечень (обычно статический) методов объекта и результатов их вызова (зависят от текущего состояния).
Мы оговариваем, что перечень методов, обычно статический, так как в некоторых языках программирования существуют механизмы, позволяющие изменять перечень методов класса или отдельного объекта при выполнении программы.
Мы оговариваем, что результаты вызова методов зависят от текущего состояния или, по-другому, определяются историей объекта (то есть историей изменения его состояния), так как один и тот же метод в общем случае может возвращать разные результаты в зависимости от состояния.
В предыдущих главах мы уже показывали, что методы имеют доступ ко всем полям объекта независимо от уровня видимости. При этом доступ выполняется через неявно передаваемую в метод переменную this , указывающую на объект, для которого был вызван метод. Если локальная переменная метода имеет такое же имя, как и некоторое поле класса, то эта локальная переменная скрывает ( hide ) поле класса. Мы уже рассматривали эту возможность ране в § 7.
Сокрытие переменных можно назвать разновидностью более общего понятия – перегрузки – использования в одной и той же области видимости одного и того же имени для обозначения разных элементов языка. Если «элемент языка» – метод, то мы имеем дело с перегрузкой методов.
Перегрузка метода (overloading) – определение в одной и той же области видимости нескольких методов с одинаковым именем, но различающихся количеством или типами параметров.
Компилятор, используя различие в параметрах, определяет на этапе компиляции, какой именно метод необходимо вызывать.
Мы используем термин метод, так как он используется в C#, но в других языках и, в целом, в объектно-ориентированном программировании как синонимы также используются термины функция (function) и функция-член (member function). Исторически термин функция возник в процедурном программировании и обозначал функцию, не связанную ни с каким классом. В объектно-ориентированных языках чтобы различать функции, не связанные ни с каким классом, и функции класса, последние стали называть другими терминами, например, функциями-членами в C++ и методами в C# и Java, оставив термин функция для функций, объявленных вне классов. При этом во многих объектно-ориентированных языках вовсе нет возможности объявить функцию вне какого-либо класса.
В заключение напомним, что при проектировании класса, как правило, следует избегать открытых полей – для изменения состояния объекта следует использовать методы 24 .
§ 16. Неизменяемость. Изменение программистом значений переменных (состояния объектов) в ходе выполнения программы выглядит вполне естественной практикой. Однако существует множество ситуаций, когда желательно так или иначе ограничивать эту возможность.
Во-первых, некоторые объекты представляют семантически неизменяемые данные, константы. Например, мы не хотели бы иметь возможность изменять переменные, в которых хранится число π, или число e, или коэффициенты перевода единиц измерения, или другие подобные значения. Семантически константами могут быть и более сложные объекты, например, точка-центр координат, объект-прямоугольник с размерами страниц стандартного формата. параметры работы приложения, не допускающие изменения после запуска. Очень часто локальные переменные не должны изменяться после инициализации согласно логике метода. Конечно, можно сказать, что раз эти объекты не должны меняться, то и не следует их менять. Например, в Python это единственная рекомендация для разработчика 25 . Однако во многих других современных языках программирования принята практика ограничений изменения семантически неизменяемых объектов на уровне языка.
Во-вторых, часто желательно ограничить возможность изменения состояния объекта только некоторыми фрагментами кода. В следующем примере будет ли изменено состояние объекта reportData внутри метода Create ?
Метод Create создает объект-отчет report , используя данные из объекта reportData . Разумно предположить, что метод Create использует данные reportData , но не изменяет их. Однако это не точно: код метода Create вполне может случайно или намеренно (в этом случае речь идет о неудачной архитектуре) изменить какие-то поля объекта reportData .
Приведем еще пример:
Здесь класс ReporDataProvider выполняет загрузку данных из базы данных с использованием переданного в конструкторе объекта-подключения db . Как и в предыдущем примере, разумно предположить, что объект reportDataProvider использует объект-подключение db , но не изменяет его. Однако (как и в предыдущем примере), это не точно. Особенно важна задача локализации фрагментов кода, изменяющих состояние объекта, в многопоточных приложениях. Так, если мы используем объект db для нескольких объектов-провайдеров, каждый из которых будет менять свойства подключения, то при параллельном запуске этих провайдеров отследить кто и что изменил значительно сложнее, чем при последовательном.
Дополнительным аргументов в пользу неизменяемости состояния объектов является потенциальное повышение производительности. Компилятор, зная, что значение тех или иных переменных не будет никогда меняться, может сгенерировать более оптимальный код.
Способы ограничивать изменение состояния объектов сильно отличаются в различных языках программирования. Рассмотрим коротко основные возможности C#: механизм констант ( const ) и механизм readonly -полей классов.
Локальные переменные методов и поля классов значимых типов могут быть помечены как константы ключевым словом const . Такие объекты невозможно изменить во время выполнения приложения. Рассмотрите следующий пример:
Значения констант должны быть определены на момент компиляции приложения, поэтому мы не можем их использовать со ссылочными переменными – экземплярами классов 26 :
Для ограничения изменения переменных ссылочного типа в C# используется механизм readonly -полей. Поля классов могут быть помечены как доступные только на чтение ключевым словом readonly (англ. «только чтение») . Это значит, что мы сможем присваивать значения этим полям только в конструкторе класса или непосредственно при инициализации поля. Рассмотрим следующий пример неизменяемого ( immutable ) класса:
Этот пример демонстрирует несколько важных особенностей.
Во-первых, в C# неизменяемость ( immutability ) – это свойство класса, а не объекта: или мы объявляем класс как неизменяемый и все его экземпляры будут неизменяемыми. Или мы объявляем класс как изменяемый и все его экземпляры будут также изменяемыми. У нас нет возможности сделать неизменяемым только некоторые экземпляры этого класса. Для сравнения, отметим, что в C++ такая возможность есть: мы можем отметить ключевым слово const переменную или даже параметр метода и это будет значить, что указанную переменная или параметр метода невозможно изменить, но другие, не отмеченные этим словом экземпляры будут изменяемыми, а объект-параметр будет изменяемым вне соответствующего метода.
Другая особенность, демонстрируемая примером с кругом – класс может быть не полностью неизменяемым. То есть часть полей может быть изменяемая, часть – нет. Полностью неизменяемый объект мы можем сделать только если все вложенные объекты (поля класса) также реализованы как неизменяемые. Так, в классе Circle недостаточно написать readonly Point , нужно чтобы и сам Point был неизменяемым, так как readonly для ссылочного типа обозначает лишь невозможность изменить его значение (ссылку), но не состояние объекта, на который он ссылается.
И последний момент, который мы разберем – особенность копирования неизменяемых объектов. В конструкторе для копирования объекта-центра мы используем копирование ссылки, так как уверены, что переданный объект уже не будет никогда изменен и вполне достаточно иметь всего один экземпляр объекта, на который будут ссылаться множество логически не связанных между собой переменных.
В заключение отметим, что, применяя имеющиеся возможности языка, как правило, лучше избыточно ограничить изменение переменных и позже снять это ограничение, чем случайно изменить переменную, которая с точки зрения других фрагментов кода, должна быть неизменяемой.
Несмотря на широкое использование в ежедневной практике, для объектно-ориентированного программирования неизменяемость – это всегда ограничение, так как исходно переменные в ООП изменяемые ( mutable ). Более того, в теории языков программирования введение неизменяемости для всех объектов – это определение функциональной парадигмы программирования [Мартин 11].
§ 17. Сохраняемость. Иногда требуется сохранить состояние объекта между запусками программы или при перемещении объекта между приложениями. Конечно, строго говоря, при восстановлении сохраненного состояния, мы в действительности создаем новый объект в памяти и присваиваем его полям значения, соответствующе тем, которые были у другого объекта. Однако удобно представлять этот процесс на более высоком уровне абстракции, как сохранение и восстановление.
Сохраняемость – способность объекта существовать во времени, переживая породивший его процесс, и (или) в пространстве, перемещаясь из своего первоначального адресного пространства. [Буч 3]
Для сохранения объекта в файл, передачи по сети или другому процессу, как правило, требуется привести значения полей объекта в формат, который будет понятен получателю и преобразовать их в непрерывную последовательность байт. Этот процесс называется сериализацией (от англ. serial – последовательный).
Сериализация (serialization) – преобразование состояния объекта в последовательность байт. Сериализация может быть двоичная, текстовая (JSON, XML) или какая-либо другая. Обратный процесс называется десериализацией.
На следующем рисунке предоставлен пример сериализации объекта в формат JSON.
Особая тема – сохранение объектов в реляционную базу данных. Чаще всего используется следующий подход: объект соответствует строке таблицы, а поля – столбцам этой таблицы. Значения значимых полей хранятся непосредственно в ячейках строки таблицы, а ссылочные поля реализуются с помощью внешних ключей, связывающих строку таблицы объекта со строкой или строками таблицы другого объекта, на который указывает ссылочное поле 27 . На следующем рисунке приведен пример сохранения уже рассмотренного выше объекта Circle c в две таблицы реляционной базы данных:
Очевидно, процесс сохранения и восстановления состояния объекта из базы достаточно трудоемкий для программиста, поэтому крайне привлекательна идея сохранения и загрузки состояния объекта в реляционную базу данных простым вызовом некоторых встроенных методов Save и Load . Библиотеки, упрощающие сохранение и загрузку состояния объектов или реализующие так или иначе эти методы Save и Load , называют ORM-библиотеками:
ORM (object-relational mapping) – «объектно-реляционное сопоставление» – механизм (реализуемый не языком программирования, а сторонними библиотеками), позволяющий сохранять или восстанавливать состояние объекта в приложении в реляционную базу данных.
Эти механизмы используются крайне широко и любое промышленное приложение использует ту или иную ORM, например, EntityFramework или Dapper .
Следует отметить, что полноценное «зеркалирование» базы данных в объекты памяти помимо трудоемкости, а точнее рутинности этого процесса, сопряжено с множеством концептуальных проблем, прежде всего, связанных с транзакциями. Чтобы преодолеть эти ограничения некоторые базы данных заявляются как объектные, а не реляционные, в том смысле, что при работе с ними мы не транслируем объектную модель программы в реляционную модель БД с помощью ORM, а напрямую сохраняем в БД в объектной модели. Хотя эти направления динамично развиваются, однако пока остаются нишевыми.
§ 18. Свойства в C#. В заключение главы, коротко рассмотрим специальную синтаксическую разновидность методов в C# – свойства. В C# мы можем объявить метод, возвращающий значение заданного типа или принимающий один параметр заданного типа, используя следующий специальный синтаксис, позволяющий пользователям класса обращаться к этим методам, как к полям:
Для свойства может объявлен только метод get , тогда мы создаем свойство доступное только на чтение, или, наоборот, только метод set , тогда мы создаем свойство, доступное только на запись (как правило, неудачное решение). Для методов get и set нет устоявшегося перевода на русский язык, по-английски их называют getter и setter .
Отметим еще раз, что свойства – специфическая возможность C# и представляет лишь синтаксическое упрощение для объявления и вызова определенных методов, а термин «свойство» вне языка C# часто используется для обозначения обычных полей класса.
Вопросы и задания
1. Дайте определение следующим терминам и сопоставьте русские термины с английскими: состояние объекта, поле, переменная-член, свойство, поведение объекта, метод, перегрузка метода, функция, функция-член, сокрытие локальных переменных неизменяемость, константа; state, field, member variable, property, behavior, method, overloading, member function, immutability.
2. Имеет ли открытый ( public ) метод класса доступ к закрытым ( private ) полям того же класса (1) того же объекта, для которого этот метод был вызван; (2) для другого объекта того же класса, который был передан как параметр этого метода?
3. В чем отличие между классом без состояния ( stateless ) и неизменяемым классом ( immutable )?
4. Почему нельзя перегрузить методы с одинаковыми параметрами, но отличающимися типами возвращаемых значений?
5. Изучите различия классов string и StringBuilder .
6. Назовите преимущества и недостатки использования неизменяемых типов данных.
7. Можно ли в C# объявить локальную переменную или параметр метода с ключевым словом readonly ?
8. Можно ли в конструкторе присваивать значения readonly -полю несколько раз?
9. Является ли массив неизменяемым типом данных в C#?
10. Повышают ли производительность приложений использование const и readonly в C#? Является ли производительность фактором, который необходимо учитывать, применяя механизмы языка программирования по ограничению изменения состояния объектов?
11. Объясните утверждение, что в C# неизменяемость – свойство классов, а не объектов.
12.* Познакомьтесь с подходом «event sourcing» (к сожалению, устоявшегося перевода этого термина нет), в рамках которого мы храним список транзакций, то есть событий об изменении состояния, но не храним само состояние.
13.* Приведите аргументы в пользу следующего тезиса: «Чем большей памятью мы располагаем и чем быстрее становятся наши компьютеры, тем меньше мы нуждаемся в изменяемых состояниях.» [11]
24. Или – в C# – свойства, см. § 18.
25. Системы статического анализа кода не в счет, так как это внешние по отношению к языку программирования инструменты.
26. Строго говоря, структуры C# (struct) также не могут быть константами, хотя и являются значимыми типами.
27. Нередко этот способ сохранения объектов в реляционную БД подвергают критике. Подробный анализ этого вопроса приведен, например, в [Дейт 4]. Однако по факту, именно описанная модель сегодня является самой распространенной.
Строгое определение понятий: объект, состояние, событие, бизнес-операция и бизнес- функция
В текущей статье я определю следующие термины: объект, состояние, событие, операция, функция. Я расскажу о том, как можно представить себе их. В качестве мета-метамодели для моделирования мы возьмем теорию множеств, а не MOF. Почему именно ее? Потому что это единственный на сегодняшний день известный способ моделирования, который имеет математическую основу, границы применимости которого нам хорошо известны, достаточно широки и обоснованы.
-
ООП перепутало классы и типы. То, что называется типами у Аристотеля, в ООП назвали классами, а то, что математики называют классами, в ООП не имеет названия.
Решение по крайней мере части этих проблем предоставляют методики онтологического моделирования, в частности – технологии семантической сети, semantic web. Несмотря на неудачное название и сложную судьбу, они предоставляют куда лучший инструментарий для воплощения в электронной форме моделей частей реального мира, чем ООП или распространенные нотации моделирования бизнес-процессов. Познакомиться с особенностями этих технологий можно здесь.
Особое внимание стоит обратить на то, что с помощью этих технологий можно достаточно просто моделировать различные точки зрения на разные объекты, отражая и то общее, в чем согласны несколько субъектов, и частные взгляды каждого из них. Можно даже выражать в модели факты, противоречащие друг другу (с точки зрения разных людей), и получать логические выводы с учетом этих противоречий. С примером использования инструментария онтологий для работы с такими знаниями можно познакомиться здесь.
Рассмотрим моделирование объекта. Принято считать, что объект в пространстве имеет ясно выраженные границы. Однако, нам надо привыкнуть к тому, что не все объекты учета имеют такие границы. Например, операция. Представьте себе шарик с газом. Его пространственные границы ясны и понятны – это стенки шарика. Допустим, что шарик лопнул и газ, заключенный в нем, стал расширяться. После этого мы не можем точно описать поверхность, которая ограничивает объем области, в котором находится распространяющийся газ, но можем описать границы, за которые этот газ точно не вышел (пока не вышел). Точно также мы не можем описать точные границы операции, но очень легко можем описать те границы, за которые операция не выходит. Например, операция по точению болта на выходит за пределы цеха. Таким образом, мы можем сказать, что операция происходит (находится) в цехе. Кроме того, принято считать объект плотным объектом, который не может одновременно пересекаться с другими объектами. Однако, про операцию так сказать не получится. Две операции могут происходить в одном цехе одновременно. Если продолжить сравнение с шариком, то после того, как шарик лопнул, распространяющийся газ стал занимать объем, пересекающийся с другими газами. Про операцию можно сказать, во сколько она началась и во сколько она закончилась. Это – описание границ объекта во времени. Точно также можно обозначить временные границы не только операции, но и любого объекта. Например, болт существует с 1-го сентября 2016 года по 23 ноября 2017 года, когда он был переплавлен.
Для описания границ болта мы используем термины: в пространстве: где находится? Во времени: когда существует? Для описания границ операции мы используем термины: в пространстве: где произошло? Во времени: когда произошло? Нам непривычно было бы спросить про болт: произошел когда? А про операцию: существует где? Проблема в языке. Один и тот же вопрос для разных типов объектов учета формулируется по-разному. Это еще одна причина, по которой нам сложно представить себе операцию как 4-х мерный объект.
Поэтому для моделирования 4-х мерного объекта надо отделить описание его границ в 4-мерном пространстве-времени от трактовки этого описания. В дальнейших рассуждениях я расскажу, какие приемы мы используем для моделирования 4-х мерных объектов и с какими трактовками связаны эти способы описания.
Для описания объекта строятся границы, которые ограничивают моделируемый объект. Если не загоняться на тему математических извратов, то границей 4-х мерного объекта будет 3-х мерный объект. Знать эту 3-х мерного границу хочется максимально точно. Например, если сказать, что молоток (4-х мерный объект) находится на складе с 1-го декабря 2016 года по 1-го марта 2017, — это будет плохая модель молотка. Хочется знать про молоток немного больше. Например, можно задать точные координаты куба, в котором он находится. Точные границы куба могли бы выглядеть так: по оси X: с 10 до 20 см, по оси Y: с 30 до 35 см, по оси Z: с 120 по 135 см, по оси времени с 1-го декабря 2016 года по 1-го марта 2017 года. Теперь возьмем 4-х мерный объект, трактуемый как операция. Описание этого 4-х мерного объекта выглядит также, как и описание 4-х мерного объекта, трактуемого как молоток. Для этого 3-граница описывается при помощи места, где происходит происшествие, времени начала и времени завершения операции. Пока ничто не отличает описание операции от описания молотка. Что реально отличает операцию от молотка – так это наше представление о нем. Молоток в нашем представлении – плотный объект, не меняющий свою форму во времени. Операция же наоборот – рыхлая по составу и не имеющая постоянной выраженной формы. Но это знание не содержится в модели, а содержится в тех договоренностях, которые сопровождают эти модели. Чтобы подчеркнуть разницу между молотком и операцией используется языковые паттерны: операция происходит, молоток существует. Эти паттерны подчеркивают неизменность молотка и переменчивость операции.
Предположим, что мы изучаем молоток и движемся по его ручке. При таком движении фактура поверхности не меняется. Чтобы представить себе аналог такого движения по оси времени, надо понять, что поверхность 4-х мерного объекта при движении по оси времени описывается состояниями. Это значит, что, для проведения аналогии, необходимо, чтобы движение по оси времени не меняло состояние объекта учета. Например, молоток лежит на столе и им никто не пользуется. Состояние молотка не меняется.
Теперь представим, что ручка молотка покрашена краской и эта краска градиентная от красного до синего. Двигаясь по ручке, мы наблюдаем небольшие изменения в цвете. Аналогом такого движения по времени будет наблюдение смены состояний объекта, каждое из которых (состояний) ничтожно мало отличается от соседнего по времени состояния. Примером такой смены состояний может быть движение материального молотка в пространстве. Состояние тела меняется непрерывно и плавно. При этом изменения, накопленные за конечное время, могут быть достаточно сильными для их диагностики и наблюдения. Такое изменение за конечное время называется операцией.
Теперь представим, что, двигаясь вдоль по ручке молотка, мы наткнулись на боек. Это – скачкообразное изменение фактуры поверхности. Аналогом такого скачка при движении вдоль оси времени будет резкая смена состояния объекта учета, или событие. Если рассматривать движение молотка в пространстве, то это был бы неожиданный скачек его положения в пространстве. Для материального тела представить это сложно, потому что оно имеет инерцию, препятствующую такому скачку. Однако, если рассматривать классическую бизнес-операцию, то это событие могло быть поглощением ресурсов в операции, интеграцией двух функциональных объектов в один: токарь встал на рабочее место, выпуском продукции. Так или иначе, событие — это изменение состояния объекта учета за столь короткое время, что наблюдатель считает это время равным нулю. Понятно, что другой наблюдатель может более внимательно подойти к изучению состояний и найти, что изменения произошли не мгновенно, а постепенно. Поэтому событие – это субъективное восприятие изменения состояния объекта. Очень часто можно услышать, что объекты являются частью объективной реальности, модель которой мы строим. Однако, как мы недавно видели, сами объекты – это тоже субъективное представление некоторого 4-объема в 4-пространстве. Поэтому, что объекты, что события, что операции – это модели реальности, — результат субъективного восприятия.
Коль скоро мы определили объект как модель 4-объема в 4-пространстве, мы можем определить, что такое тип объектов. Допустим, что есть множество моделей 4-объемов, или множество объектов. Эти модели хранятся у субъекта в сознании. Если эти модели похожи друг на друга, то субъект может создать модель этих моделей. Эта модель также хранится в сознании субъекта. Эта модель моделей и есть тип объектов. Модель моделей – это второй уровень абстракции. Первым уровнем абстракции были модели 4-пространств, которые мы называем объектами.
Для моделирования 4-х мерного объектов через моделирование их поверхности требуется большой объем данных. Есть способы сократить этот объем, сделав определенные допущения.
Например, для описания операции можно сделать допущение, что в операции все события по поглощению ресурсов и интеграции функциональных объектов происходят в момент начала операции, а выпуск готового продукта – по окончанию операции. Понятно, что в общем это неверно, однако, такой способ описания позволяет все события свести либо к началу операции, либо к ее завершению.
Допустим, что требуется смоделировать болт, резьба которого имеет много витков. Для его моделирования достаточно указать шаг и длину резьбы. Это значит, что, если поверхность можно разделить на элементы, каждый из которых похож друг на друга, то для моделей всех этих элементов можно сделать одну модель (тип витка). Если затем указать количество этих элементов и способ их стыковки, то количество информации, необходимой для моделирования такой поверхности можно сильно сократить. Такое описание позволяет сократить объем модели посредством классификации элементов поверхности.
Если требуется смоделировать операцию, в которой события по выпуску веников, как витки резьбы у болта, следуют регулярно (но теперь уже не в пространстве, а во времени), то можно создать одну модель для всех этих событий (тип событий) и указать время, в течении которого выпускались веники. Это позволяет сократить объем модели операции посредством классификации событий.
Теперь допустим, что моделируется резьба, длина которой в рамках рассматриваемой модели заведомо неизвестна, но больше, чем моделируемая область. Этакая длинная бесконечная резьба. Для ее моделирования мы можем также создать модель моделей витков (тип витков), но указать их количество мы не можем, потому что их количество в рамках нашей модели бесконечно. Единственное, что мы можем сказать – это шаг резьбы, или количество витков на единицу длины. Таким образом, описанием такой бесконечной резьбы будет тип витков.
Аналогом описания бесконечной резьбы, при котором повторяются не геометрические объекты в пространстве, а события во времени, является описание, в котором через определенные промежутки времени случаются похожие события, например, выпускается очередной веник. Поскольку мы не знаем количество таких событий, можно сказать лишь об их частоте: например, один веник в час. Такое описание объекта соответствует описанию бизнес-функции, и говорят, что это функция по выпуску веников. То есть, описанием функции будет тип событий.
Мы подошли к моему определению понятия бизнес-функция. Бизнес-функция – это 4-х мерный объект, который имеет описание в виде набора типов событий с указанием плотности этих событий во времени (в вырожденном случае может содержать всего один тип, например, тип событий по выпуску веников). Замечу, что это определение сильно отличается о общепринятого, в котором функция определена как преобразование входных потоков в выходные. Но здесь нет никакого противоречия. Просто обычное определение функции является частным случаем моего. Все дело в том, что каждому множеству однотипных событий (классу событий), которые моделируют функцию, можно приписать поток материальных объектов учета. И тогда каждому типу событий можно будет приписать поток объектов и направление этого потока. Однако, такое понимание функции страдает тем же, что и описание операции при помощи акторов, совершающих действие. Это – невозможность посмотреть на модель с другой точки зрения. Если в моем определении каждому типу событий аналитик может приписать свои только ему необходимые объекты учета, то в классической модели сделать это не удастся. А это, в свою очередь, не позволит построить модель с учетом требований Трейсабилити. Кроме того, моделируя типы событий, я вообще не привязан к моделированию потоков. Бывают случаи, когда описать поток объектов невозможно, потому что трудно найти объекты учета, которые приходят, или покидают функцию. Например, если моделируется функция удержания вращающегося мячика на пальце клоуна, то смоделировать поток объектов в такой функции невозможно – ничто не покидает систему «клоун-шар» и ничто туда не втекает, а функция – вот она! Правда в системе «клоун-шар» события, которые происходят, носят не дискретный характер, а непрерывный.
Для понимания, что такое непрерывный поток событий, обратимся к электромотору. С одной стороны, электромотор легко представить себе в виде объекта. Очень часто так и делается. Если не нужно моделировать движение вала электромотора, аналитик просто пишет: электромотор такой-то. Это моделирование 4-х мерного объекта в виде 3-х мерного объекта. С другой стороны, можно попытаться смоделировать вращение вала электромотора. Вал электромотора вращается равномерно. Каждое положение вала в любой момент времени – это состояние. Все подобные состояния являются однотипными. Количество таких состояний зависит от дискреты, с которой производится замер. Это может быть дискрета временная, а может – угловая. Для целей моделирования удобно взять угловую дискрету, то есть, считать однотипными такие состояния, которые совпадают с поворотом вала на определенный угол, например, один оборот. Тогда плотность таких состояний на оси времени – количество оборотов в минуту, будет говорить о скорости вращения вала. Таким образом, вращающийся шар на пальце у клоуна будет описываться угловой скоростью вращения этого шара. Плотность состояний, распределенных по оси времени, говорит нам о скорости, с которой происходят переходы из одного однотипного состояния в другое. Там, где человеческое сознание сталкивается с огромным множеством однотипных состояний, аналитик вынужден переходить от моделирования состояний к моделированию плотности состояний, а это и есть описание объекта в виде функции. В случае с вращением вала электродвигателя – это функция вращения вала.
Замечу, что 4-х мерный объект может быть одновременно смоделирован:
- Как 3-объект – мотор.
- Как функция вращения вала.
В следующей статье мы рассмотрим отношения «часть-целое» между 4-х мерными объектами и расскажу, какие понятия это позволит нам определить.