На тему моделирования предметной области в терминах ООП

в 11:55, , рубрики: анализ, Анализ и проектирование систем, аристотель, логическая парадигма, моделирование предметной области, онтология, ооп, парадигмы, Семантика

Здравствуйте.

Эта замечательная статья подтолкнула меня опубликовать давние мысли, касающиеся моделирования предметной области с помощью объектно-ориентированного программирования.

К актуальности изложенных в статье идей, приходишь подспудно (не имея возможности выразить по причине того, что парадигме моделирования в терминах теории множеств не учат в вузах, будущих «программистов», по крайней мере), долго работая с ООП и реляционными базами данных:

Каждый раз при моделировании предметной области, оперируя терминами ООП (сейчас говорим не об этапе бизнес-анализа, а о последующем этапе реализации модели в коде), для всех сущностей предметной области приходится реализовывать в коде и схеме БД следующий паттерн, состоящий их «подсущностей», связанных между собой:

  • класс/таблицу вида «Машины» (здесь и далее класс употребляю в терминах ООП);
  • класс/таблицу вида «Список машин»;
  • класс/таблицу вида «Машина».

Далее с помощью механизмов ООП и реляционной модели «подсущности связываются между собой.

Причем термины „сущность“ и „подсущность“ применимы именно к модели предметной области в терминах теории множеств,
а в терминах ООП/реляционной модели уместны термины „метасущность“ и „сущность“ соответственно.
Надеюсь, понятно, почему? — ООП/реляционная модель являются более низкоуровневыми механизмами, и сущность предметной области приходится конструировать, нет в них средств, которые нативными образом позволили бы отразить сущность предметной области.

А далее следуют ожидаемые проблемы:


Каждый раз (не только в каждом проекте, а внутри проекта для каждой сущности, подчеркну это) реализуем паттерн?
Отлично, мы занимаемся копипастом.

[offtopic]Отвлекаясь, хотелось бы сказать, я достаточно критически отношусь к паттернам (тема такая модная лет 10-15 уже как; чего ведь только не придумывают вместо того, чтобы заниматься моделированием и написанием качественного кода),
т.к. паттертн — это копипаст по своей сути (если кому-то захочется поспорить на тему — пожалуйста не здесь, заведите публикацию, там поговорим).[/offtopic]

Либо, если хочется сократить себе работу/не заниматься копипастом (или в случае отсутствия понимания необходимости реализации описанного паттерна), в большинстве случаев делается так, реализуется лишь одна сущность:

  1. Код:
    • класс „Машина“ — не множество, а именно характеристики машины, ее описание;
    • список машин представляется абы как — массив (Array), список (List), или перечисление (IEnumerable), т.е. используются низкоуровневые типы данных языка для реализации сущности „список“ — но с такими данными мы можем делать, все что хотим или что случайно получится, а это уже не объектный, а процедурный подход со всеми вытекающими;
    • класс же „машины“ чаще всего вообще не реализуется ни в каком виде.
  2. БД:
    • Как правило, это одна таблица „Машина“ или „Машины“ — таблица, строки которых содержат список машин, а столбцы — характеристики машин.
    • Никогда не задумывались, почему в книжках по БД такую таблицу называют, то „Машина“, то „Машины“ (Student/Students)?
      Есть фреймворки по работе с БД, которые принудительно к названиям таблиц добавляют суффикс „s“ (Mashines/Students).
    • Причина в том, что здесь происходит попытка объединить две сущности в одну (объект и список объектов), или даже все три в одну.
    • Правильно называть такую таблицу „Машина“, а „Список машины“ и „Машины“ реализовывать с помощью других таблиц.

Так вот, какой же вывод я делаю на основании своего опыта и комментируемой статьи:

Хотелось бы иметь такие язык программирования, платформу разработки, теорию БД, СУБД, которые позволили бы в „нативных“ для себя терминах реализовывать модель предметной области в терминах именно теории множеств.
Мне кажется, необходимость появления таких инструментов в мейнстриме давно уже назрела.

Автор: sand14

Источник

Поделиться

* - обязательные к заполнению поля