Проектирование данных на различных уровнях абстрактности и детальности
В моделировании данных, как и в более широкой дисциплине - проектировании информационных систем - выделяют 6 уровней моделирования, но более правильно называть их шестью стадиями проектирования (от идеи до реализации):
Стадия 1. IDENTIFICATION - стадия генерации идеи о том, что нечто может быть выражено в виде данных. Это стадия фантазий и идей. Идентификация может происходить как в форме выработки определенной идеи, так и в виде попыток навесить на наблюдаемую реальность какой-то ярлык. Говоря языком Платона-Аристотеля, здесь происходит попытка скрестить идеальное представление о чем-то с реально наблюдаемым. Идеи или идентифицированные хороши тем, что они не строгие, не четкие, но они лаконичные и это первая четкая попытка указать не столько на то, что нам интересно, сколько отсечь всё то, что нам НЕ ИНТЕРЕСНО.
Стадия 2. DEFINITION - концептуальная стадия, на которой идея четко очерчивается словами, схемкой, связями с другими понятиями, образуя тем самым новое понятие, термин, а в случае с данными - новый класс или КОНЦЕПТ. Лучшим способом определения объекта данных является перечисление его экземпляров (см. также концетроид Рудда). Взаимоувязанная совокупность концептов (сущностей) даёт концепцию. Прим: слово "взаимоувязанная" здесь несколько лишнее, так как сущности/концепты всегда формируются вместе с набором их отношений к другим сущностям/концептам.
Стадия 3. REPRESENTATION (синонимы - логическая, системная) - стадия макетирования или моделирования вновь родившегося понятия, термина, класса, концепта. Здесь свойства и характеристики будущего объекта данных превращаются в конкретные мета-атрибуты и мета-связи, а также объект данных обрастает нужными методами для работы с ним. Вполне можно заявлять, что на этой стадии мы получаем прототип нашего цифрового двойника. Макет/модель на этой стадии намеренно не зависит от реализации, но реализуемость мрдели безусловно подразумевается и исследуется.
На стадии 3 заканчиваются степени абстрактности и начинаются степени детальности. С уровня 4 начинается начинается реализация или переход от проектирования к конструированию.
Стадия 4. SPECIFICATION - стадия разработки (конструирования) спецификации, согласно которой новый объект данных получает полный диапазон его атрибутов, их значений, ограничений, правил и т.д. Учитывается способ реализации объекта данных: на каком языке программирования, в какой СУБД и т.п. Если на этой стадии еще удается поддержать независимость от вариантов реализации (лучше сказать так: закладывается поддержка множества реализаций, возможность портирования спецификации) - это большой плюс!
Стадия 5. CONFIGURATION - стадия разработки устойчивых вариантов объекта данных на базе множества возможностей, заданных в спецификации.
Стадия 6. INSTANSIATION - стадия разработки структур физической модели, где будут храниться экземпляры фактических данных о чем-то из реальности.
Рассмотрим два примера для таких концептов, как ПРОДУКТ и КОНТРАГЕНТ.
| Стадия проектирования | Продукт | Контрагент |
| 1. IDENTIFICATION | проектируем объект данных, который бы позволял отразить в системе любой объект продажи, передаваемый от продавца покупателю в ходе сделки: товар, услугу, гарантии - а также их потребительские характеристики и параметры, влияющие на цену. | проектируем объект данных, который бы позволял учесть в системе контрагента любой природы: клиента, партнера, поставщика, агента, дилера. Основная идея совмещения в конрагенте различных его ролей заключается в том, что одно и тоже юрдическое или физическое лицо может выступать в различных своих ролях одновременно по отношению к рассматриваемому предприятияю. |
| 2. DEFINITION |
концепт ПРОДУКТ (PRODUCT) - любой объект продажи независимо от его природы и количества характеристик, который может быть заказан клиентом (оформлен в виде заказа, в том числе путем помещения продукта в корзину на витрине сайта). Может быть композитным или агрегатным, то есть Продукт может состоять из других продуктов или опций, быть пакетом продуктов, соединяться с ценой или скидкой. Приведем, для простоты примеры продуктов для телеком-оператора:
а также любая комбинация перечисленного. Продукты могут характеризоваться размерами, весом, цветом, количеством. Продукт должен связываться с другими концептами, такими как ЦЕНА, СКИДКА. |
Для простоты следует рассмотреть подход к разработке спецификации на "Клиентский профиль", где КЛИЕНТ - более узкий класс контрагентов, которым мы продаем ПРОДУКТ, как конечному потребителю продукта. |
| 3. REPRESENTATION | Здесь приводятся строгие примеры (чем больше, тем лучше) различных боевых примеров проектируемого концепта. Наивысшая строгость примеров - диаграмма классов UML. Можно также использовать квадратики и стрелочки - не так важна нотация, как ясность и четкость изложения или схематизации. | |
|
Важно проверить и отразить все возможные комбинации продуктов, включая их комбинации с ценами и скидками. Методы по работе с объектом ПРОДУКТ:
Правила:
Строгость репрезентации ПРОДУКТА не должна затруднять проверку модели продукта со стороны бизнес-заказчика, но не должна упрощаться в угоду заказчика, выхолащивая детали. На этой стадии выполняется прототипирование, демо-макеты, разработка проверочных тестов или вопросов. |
||
| 4. SPECIFICATION |
1) Смотри описание PRODUCT SPEC от TM FORUM в виде набора диаграмм UML. 2) спека на все атрибуты продуктов и варианты их значений. 3) спека на все методы по работе с продуктом: как вызывать метод, какие результаты он должен возвращать. |
См. пример схемы в материалах нашего тренинга по SID (нормативная модель данных). |
| 5. CONFIGURATION |
Смотри описание PRODUCT CONFIGURATION от TM FORUM в виде набора диаграмм UML. Конфигурации - это зафиксированные наборы компонентов и атрибутов (включая их значения) из PRODUCT SPEC. Конфигурации - это то, что клиент будет класть в корзину и далее они будут направляться в подключение. |
|
| 6. INSTANSIATION | Любая конфигурация продукта сохраняется в базе данных в виде XML-файла установленной структуры. | |
