«Человек живёт только в настоящее мгновение. Всё остальное или прошло уже, или, неизвестно, будет ли.»
 
Консалтинговая компания Марк Аврелий


Проектирование данных на различных уровнях абстрактности и детальности

В моделировании данных, как и в более широкой дисциплине - проектировании информационных систем - выделяют 6 уровней моделирования, но более правильно называть их шестью стадиями проектирования (от идеи до реализации):

Стадия 1. IDENTIFICATION (IDEATION -так может быть лучше) - стадия генерации идеи о том, что нечто может быть выражено в виде данных. Это стадия фантазий и идей. Идентификация может происходить как в форме выработки определенной идеи, так и в виде попыток навесить на наблюдаемую реальность какой-то ярлык. Говоря языком Платона-Аристотеля, здесь происходит попытка скрестить идеальное представление о чем-то с реально наблюдаемым. Идеи или идентифицированные хороши тем, что они не строгие, не четкие, но они лаконичные и это первая четкая попытка указать не столько на то, что нам интересно, сколько отсечь всё то, что нам НЕ ИНТЕРЕСНО. 

Стадия 2. DEFINITION - концептуальная стадия, на которой идея четко очерчивается словами, схемкой, связями с другими понятиями, образуя тем самым новое понятие, термин, а в случае с данными - новый класс или КОНЦЕПТ. Лучшим способом определения объекта данных является перечисление его экземпляров (см. также концетроид Рудда). Взаимоувязанная совокупность концептов (сущностей) даёт концепцию. Прим: слово "взаимоувязанная" здесь несколько лишнее, так как сущности/концепты всегда формируются вместе с набором их отношений к другим сущностям/концептам.

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

На стадии 3 заканчиваются степени абстрактности и начинаются степени детальности. С уровня 4 начинается начинается реализация или переход от проектирования к конструированию.

Стадия 4. SPECIFICATION - стадия разработки (конструирования) спецификации, согласно которой новый объект данных получает полный диапазон его атрибутов, их значений, ограничений, правил и т.д. Учитывается способ реализации объекта данных: на каком языке программирования, в какой СУБД и т.п.  Если на этой стадии еще удается поддержать независимость от вариантов реализации (лучше сказать так: закладывается поддержка множества реализаций, возможность портирования спецификации) - это большой плюс!

Стадия 5. CONFIGURATION  - стадия разработки устойчивых вариантов объекта данных на базе множества возможностей, заданных в спецификации.

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

Рассмотрим два примера для таких концептов, как ПРОДУКТ и КОНТРАГЕНТ.

Стадия проектирования Продукт Контрагент
1. IDENTIFICATION проектируем объект данных, который бы позволял отразить в системе любой объект продажи, передаваемый от продавца покупателю в ходе сделки: товар, услугу, гарантии - а также их потребительские характеристики и параметры, влияющие на цену. проектируем объект данных, который бы позволял учесть в системе контрагента любой природы: клиента, партнера, поставщика, агента, дилера. Основная идея совмещения в конрагенте различных его ролей заключается в том, что одно и тоже юрдическое или физическое лицо может выступать в различных своих ролях одновременно по отношению к рассматриваемому предприятияю.
2. DEFINITION

концепт ПРОДУКТ (PRODUCT) - любой объект продажи независимо от его природы и количества характеристик, который может быть заказан клиентом (оформлен в виде заказа, в том числе путем помещения продукта в корзину на витрине сайта). Может быть композитным или агрегатным, то есть Продукт может состоять из других продуктов или опций, быть пакетом продуктов, соединяться с ценой или скидкой. Приведем, для простоты примеры продуктов для телеком-оператора:

  • мобильный телефон
  • SIM-карта
  • голосовая связь
  • наушники
  • 100 минут 
  • 10 GB трафика
  • страховка на случай кражи телефона
  • чехол
  • премиальное обслуживание на call centre

а также любая комбинация перечисленного. Продукты могут характеризоваться размерами, весом, цветом, количеством. Продукт должен связываться с другими концептами, такими как ЦЕНА, СКИДКА.

Для простоты следует рассмотреть подход к разработке спецификации на "Клиентский профиль", где КЛИЕНТ - более узкий класс  контрагентов, которым мы продаем ПРОДУКТ, как конечному потребителю продукта.
3. REPRESENTATION  Здесь приводятся строгие примеры (чем больше, тем лучше) различных боевых примеров проектируемого концепта. Наивысшая строгость примеров - диаграмма классов UML. Можно также использовать квадратики и стрелочки - не так важна нотация, как ясность и четкость изложения или схематизации.

Важно проверить и отразить все возможные комбинации продуктов, включая их комбинации с ценами и скидками.

Методы по работе с объектом ПРОДУКТ:

  • найти продукт среди других продуктов по наименованию
  • положить/вынуть из корзины
  • рассчитать стоимость с учетом всех заданных параметров продукта
  • отправить на включение
  • отправить на отключение/блокировку
  • выдать конфигурацию продукта по запросу сторонней системы через API

Правила:

  • описываеются все варианты совместимости продуктов
  • описываются все варианты пакетирования продуктов

Строгость репрезентации ПРОДУКТА не должна затруднять проверку модели продукта со стороны бизнес-заказчика, но не должна упрощаться в угоду заказчика, выхолащивая детали.

На этой стадии выполняется прототипирование, демо-макеты, разработка проверочных тестов или вопросов.

4. SPECIFICATION

1) Смотри описание PRODUCT SPEC от TM FORUM в виде набора диаграмм UML.

2) спека на все атрибуты продуктов и варианты их значений.

3) спека на все методы по работе с продуктом: как вызывать метод, какие результаты он должен возвращать.

См. пример схемы в материалах нашего тренинга по SID (нормативная модель данных).
5. CONFIGURATION 

Смотри описание PRODUCT CONFIGURATION от TM FORUM в виде набора диаграмм UML.

Конфигурации - это зафиксированные наборы компонентов и атрибутов (включая их значения) из PRODUCT SPEC. Конфигурации - это то, что клиент будет класть в корзину и далее они будут направляться в подключение.

6. INSTANSIATION Любая конфигурация продукта сохраняется в базе данных в виде XML-файла установленной структуры.