Потихоньку развиваю проект, основанный на своих (сложных) инженерных изысканиях, опубликованных тут:

Теория разработки информационно-исторических систем с реализацией концепта

и частично, (может, не совсем удачно, но как-то по-проще) описанных тут:

Прикладное использование теории построения информационно-исторических систем

Сразу хочу предупредить, что описанное в статье - еще на разработке, и в проекте появится не скоро.

Поехали!

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

Как это обычно выглядит.

Начальный этап проектирования:

Наименование (строка 10): Яблоко

Количество (число 2.0): 15

Можно на этом и остановится, но в данной модели не понятно — что значит «Количество». Не хватает размерности. Допустим, раз у нас количество — целое число, значит штуки? Может быть. А может и вагоны, и допустим... груженные корабли, целых 15 штук идут по морям и океанам... Стороннему наблюдателю эти числа ничего не сообщат. Архитектор, находящийся в контексте задачи может подразумевать — к примеру расфасованные предварительно упаковки по одному килограмму (фунту, штуке?).

На вопрос — сколько яблок — последует ответ 15. 15 — «чего»? Текущая модель не ответит. На эту информацию сможет ответить только погруженный в контекст наблюдатель.

Поправим модель с учетом передачи контекста в модель.

Наименование (строка 10): Яблоко

Количество (число 2.0): 15

Наименование единицы (Строка 10): Упаковка

Внесение описательной характеристики позволяет получить контекст. Но для целей учета это слабо функционально.

Начинаем придираться, мы же должны сделать так, чтобы наблюдатель меньше работал с догадками, и больше работал с фактами?

Что нам дало это для модели? Наверное только одно. Перед нами не Яблоко — знакомое с детства по азбуке, а какая-то упаковка. Что тогда — упаковка?

Яблоко на палочке в глазури, красиво обернутое бумагой — это упаковка?

Фасовка на пенопластовой подложке в виде 3 шт Яблок в обертке — упаковка?

Пакет яблок накиданных на глаз на рынке — упаковка?

Наблюдатель следящий за моделью все равно остается вне контекста архитектора.

Внесем изменение в модель.

Наименование (строка 10): Яблоко

Количество (число 2.0): 15

Единица (Строка 10): Упаковка

Количество в единице: (число 2.0): 10

Вроде бы добавили все правильно — но натолкнулись на следующую итерацию. 10 — чего?

У нас в модели есть Яблоко — 15 упаковок. Упаковка — это 10. 10 — это чего? Напрашиваются штуки... но почему-бы яблоки не продавать упаковками по 10 коробок?

Наш Архитектор не сдается:

Наименование (строка 10): Яблоко

Количество (число 2.0): 15

Единица (Строка 10): Упаковка

Количество в единице: (число 2.0): 10

Наименование количества а единице: (Строка 2): Шт.

Рассмотрим полученную модель в порядке записи:

Яблоко 15 упаковок, упаковка = 10 шт.

К штукам пока придираться не будем. В основном все понимают, что из себя представляет - 1 штука яблок. Это переход к глобальным контекстам (общедоступным, предметной области, групповым и т. д.)

А что если сделать так?

Запись - {упаковка = 10 шт}. Где ШТ — это единичный базовый объект, выражающийся сам через себя — является в нашей системе слайсом (Не путаем со слайсами в Python. Просто я люблю пиццу...). По — другому — это автоматические правила нарезки или компоновки (разборки, сборки... группировки или разгруппировки) объектов в интерфейсе, в техпроцессах на уровне платформы.

Для определения метрики в модели, для числовых полей, отмеченных, как метрическое, запишем это в поле для определения, как мы будем «нарезать Количество на слайсы».

Наименование (строка 10): Яблоко

Количество (json): [ 15 {1 «Упаковка» = 10 «шт»{1 «шт» = 1}} ]

Без примера тут не обойтись:

И можно получать такие вещи (концепт-дизайн):

Если в этом поле ничего не указано — то «слайс» по умолчанию работает так {1 «шт» = 1}. Пицца остается неразрезной.

Для весовых объектов можно задать такую конструкцию

{1 центнер = 100 кг {1 кг = 1000 гр {1 гр = 1}}}

Коэффициенты можно задать так как хочется. Наименование «простых» слайсов тоже.

В общем виде слайсы — это json структура. Задается через Eval (Есть у меня такое в проекте. Позволяет написать код на Python, как в Jupiter Notebook, работает при отрисовке страницы) поле. И это позволяет делать совершенно прикольные штуки.

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

Пример слайса:

1 шт = 1 набор {1 аккумулятор = 1 [[234....]]; 1 корпус = 1 [[118....]]; 1 экран = 1 [[120....]]}

Можно вообще сослаться на массив объектов, например спецификацию товаров с сделке

1 Взаиморасчеты = 1 товарная спецификация {[[ссылка на массив]]}

и на единичное поле.

1 Взаиморасчеты = 1 денежное поле {[[Ссылка на ключевое поле]]}

что в сочетании с ТП (техпроцессами), которые позволяют разбивать Ключевые поля на разные блоки - позволяет сделать такую вещь:

1 Товарная спецификация = 1 Денежное поле.

На этом пока все. Повторю, что функционал находится на разработке.

Спасибо за внимание, и за обратную связь!