Модель приложения
Если предметная область автоматизации представляет собой систему взаимодействующих значений, способных находиться в различных согласованных состояниях, то такую предметную область можно однозначно описать Entity-Relation моделью, которая образована экземплярами всего четырех абстрактных сущностей: класс данных, атрибут класса, отношение классов и связь атрибутов. Такая модель, называемая моделью приложения, не только образует логическую структуру базы данных, но обладает всеми свойствами программы, так как содержит в себе полный комплект деклараций, описывающих бизнес-логику прикладной задачи. И при этом, что примечательно, не содержит в себе никаких исполняемых кодов, оставаясь комбинацией простых структур данных.
Для иллюстрации сказанного рассмотрим живой пример, который в привычном нам табличном представлении показывает взаимодействие (через отношение) нескольких сущностей (таблиц) в предметной области товарно-денежного оборота, и может быть использован в качестве правила при создании экземпляров этих сущностей (записей в таблицах) ...
... и присваивании им значений (в ячейках соответствующей записи таблицы).
Обратим внимание, в традиционном табличном представлении для реализации отношения используются первичные (колонка Name в таблице Goods и колонка Number в таблице Invoice) и вторичные ключи (колонки Number и Goods в таблице Record of Invoice), и при этом напрочь отсутствуют описания показанных на рисунке зависимостей, присущих значениям колонок Amount (= Quantity * Price) и Subtotal ( = ∑ Amount).
Теперь рассмотрим тот же самый фрагмент, но уже в объектном представлении, которое отличается от табличного явно выраженной демонстрацией того факта, что класс данных хранит свои атрибуты в формате кортежа. Логически это в точности соответствует тому, как таблица хранит свои колонки, но в отличие от табличного способа (который нам неизвестен и неинтересен) внутренняя организация класса в дальнейшем будет представлять чисто практический интерес.
Первое существенное отличие объектного представления от традиционных таблиц, которое бросается в глаза, это способ реализации отношения сущностей. В отличие от пары первичный-вторичный ключ, обеспечивающей связь записей таблиц исключительно по совпадению значений ключа, каждый из связанных отношением классов в своем кортеже содержит атрибут, типизированный идентификатором оппозитного класса. Соответственно, при реализации такой связи на уровне двух объектов, каждый из них в соответствующем атрибуте будет хранить прямой идентификатор связанного объекта. При этом между двумя атрибутами отношения существует прямая причинно-следственная зависимость, которая рассматривается в отдельной статье.
Второе существенное отличие заключается в том, что каждый атрибут класса может, используя виртуальный соединитель, установить связь с другими атрибутами класса, и для этих целей обладает собственным кортежем, в котором размещаются концевые элементы соединителя, именуемые сокеты. По умолчанию, атрибут объекта использует в качестве хранимого значение, полученное извне. При наличии одного или нескольких входящих соединителей, атрибуту назначается функционал, с помощью которого хранимое значение формируется из входящих значений-аргументов. Различные варианты использования соединителей и функционалов атрибутов более подробно рассмотрены в отдельной статье.
Модель приложения создается визуальным конструктором, который для этих целей предлагает набор инструментов для создания элементов модели и изменения их свойств. Процесс создания модели приложения выглядит примерно так (на простом примере):
Сколь странным это ни покажется, но модель приложения, с сугубо пользовательской точки зрения являясь первичным описанием целевой предметной области, тем не менее наполовину виртуальна, и существует как форма представления исполнительной модели данных. Все дело в том, что в образовании модели приложения, наряду с вещественными сущностями: классом и атрибутом, принимают участие такие виртуальные сущности как отношение, описывающее связь классов, и соединитель, описывающий связь атрибутов, которые не имеют собственных хранимых деклараций.
Таким образом, модель приложения существует исключительно в визуальной среде конструктора модели, и в нашем воображении — давая наглядную картину внутреннего устройства рассматриваемой предметной области, и скрывая тем самым более простую и рациональную модель данных. При этом для отображения используются классы и атрибуты непосредственно самой модели данных, а виртуальные отношения классов и соединители атрибутов реконструируются из деклараций атрибутов и сокетов модели данных, при этом частично инкапсулируя сам факт их существования. Отметим, что виртуальные сущности являются экземплярами соответствующих абстрактных субъектов мета-модели — мета-отношения и мета-соединителя, использование которых существенно облегчает процесс конструирования модели данных.
