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


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

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

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

Стадия 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-файла установленной структуры.