Software Developer
16,9
рейтинг
29 января 2015 в 14:55

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

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


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

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

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

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

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


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

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

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


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

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


Хотелось бы иметь такие язык программирования, платформу разработки, теорию БД, СУБД, которые позволили бы в «нативных» для себя терминах реализовывать модель предметной области в терминах именно теории множеств.
Мне кажется, необходимость появления таких инструментов в мейнстриме давно уже назрела.
@sand14
карма
4,2
рейтинг 16,9
Software Developer
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (44)

  • –1
    Правильно называть такую таблицу „Машина“


    У Криса есть другая версия, которая мне более симпатична. Таблица — есть описание типа объектов. По сути таблица содержит перечень параметров. Но это по-определению и есть тип Аристотеля!
    • +2
      Таблицу надо таки называть «Машины». Потому что таблица — это вообще другой уровень, это реализация, а не концептуальная модель. А вот перечень заголовков её столбцов — это описание класса «Машина».
      • 0
        Раз так, то лучше называть таблицу в единственном числе из-за возможных неоднозначностей в форме множественного числа -es -s. Подразумевая что в ней лежат машины.
      • 0
        Если так, то что имеется ввиду под термином машины? любая машина класса, или класс машин?
        • 0
          «Машины» я предложил именно для заголовка таблицы БД, то есть это обозначение понятия из реализации, это индивид совершенно другой онтологии. В онтологии реального мира класс «Машина», индивид «машина VIN 6786786786767677878».

          На самом деле формально-логически таблица должна называться «Некоторые машины», или «Машины, учтённые в АСУ ГАИ г. Москвы», и представлять подкласс класса «Машина».
  • +2
    Да, таблица «Машина» реализует именно перечень параметров (т.е. реализует аристолевский тип), но с помощью этой таблицы чаще всего моделируются и «Список машин», и «Машины».
    Возможное взаимное непонимание как раз из-за путаницы терминов и может происходить.
    • +1
      Сама таблица, а точнее ее структура — это описание типа объектов, или типа типов, типа связей, или типа типов связей. Иерархию типов можно продолжать до бесконечности. С помощью таблицы моделируются объекты, типы и так далее данного типа. Связи также имеют смысл и ровно тот же)) От этого иногда возникает головокружение, но это, блин, реальность)) А связи, которые реализуются ключами тоже)).
  • 0
    Каждый раз при моделировании предметной области, оперируя терминами ООП (сейчас говорим не об этапе бизнес-анализа, а о последующем этапе реализации модели в коде), для всех сущностей предметной области приходится реализовывать в коде и схеме БД следующий паттерн, состоящий их «подсущностей», связанных между собой:

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

    Эээ, а зачем это все реализовывать? Я что-то не сталкивался с задачами, которые бы одновременно требовали реализации сразу всех трех сущностей (и более того, которые бы их выделяли).
    • +2
      Очень просто указать на такой класс задач. Вам может понадобиться одновременно хранить в системе ограничение «машина имеет ровно 4 колеса», а также в таблице для каждой конкретной машины хранить серийные номера всех колёс. И, разумеется, хранить информацию о том, что машина и колёса в ограничении — это те же самые машина и колёса, что в таблице конкретных машин.
      • –2
        Ограничение «машина имеет ровно четыре колеса» закладывается либо на уровне «у сущности машина есть четыре различных связи с сущностью колесо» либо на уровне «связь машина-колесо имеет множественность 0..1-4». Соответственно, таким образом и реализуется в коде и хранилище.
        • +2
          Разумеется, моё утверждение на русском языке можно и в UML нарисовать. Это не называется «закладывается».

          Реализацию в коде через жёсткую прошивку ограничения мы сразу не рассматриваем, это не про эту задачу, надеюсь, это понятно.

          А вот про реализацию в хранилище я и говорю. Надо придумать структуру хранения сущностей Машина, Колесо. В то время как в таблице конкретных машин Машина — это вся таблица, а Колесо — это колонка. Что в одной модели объект — то во второй атрибут.
          • 0
            А вот про реализацию в хранилище я и говорю. Надо придумать структуру хранения сущностей Машина, Колесо. В то время как в таблице конкретных машин Машина — это вся таблица, а Колесо — это колонка. Что в одной модели объект — то во второй атрибут.

            Кто ж так делает-то? Есть две сущности, между ними есть связи.
            • 0
              Какие именно связи вы можете использовать для связывания объектов в БД с именами колонок и таблиц в этой же БД?
              • –2
                Эээ, а зачем?
                • +2
                  Я написал: Надо придумать структуру хранения сущностей Машина, Колесо. В то время как в таблице конкретных машин Машина — это вся таблица, а Колесо — это колонка.

                  Вы ответили: Есть две сущности, между ними есть связи.

                  Какие именно сущности вы имели в виду?
                  • 0
                    Вот когда придумывается структура хранения, тогда нелепые противоречия «машина — это таблица, колесо — это колонка» и снимаются.

                    И машина, и колесо — это сущности. В терминах реляционной БД — таблицы. Отношение «это колесо прибито к [полу]оси в этой машине» выражается связью между сущностями. В терминах реляционной БД — это либо дополнительный атрибут, либо таблица связей.
                    • +1
                      «И машина, и колесо — это сущности. В терминах реляционной БД — таблицы.»


                      И как после этого записывается факт

                      «у сущности машина есть четыре различных связи с сущностью колесо»

                      Отношение «это колесо прибито к [полу]оси в этой машине»


                      Нам надо записать факт про машину вообще и про колесо вообще, не про «это» колесо. В той же БД. Отразив, что это те же самые машины и колёса, что таблицы для записи «этих» машин и колёс.
                      • –1
                        Нам надо записать факт про машину вообще и про колесо вообще, не про «это» колесо. В той же БД.

                        Внешние ключи несут именно эту информацию.
                        • 0
                          Этого утверждения я уже не понимаю. Возможно, мои познания в клссических СУБД слишком ограничены :-(

                          Если возможно, нарисуйте пример.
                          • –1
                            Вот смотрите, если взять современную реляционную СУБД, то:

                            В них есть данные (для конкретной машины — VIN 1237890 и черный цвет, для конкретного колеса — вес 15 кг и серийный номер АБ879, для связей — колесо с номером АБ879 прибито к машине с VIN 1237890).

                            А еще в них есть метаданные: у машин есть VIN и цвет, у колес есть вес и серийный номер, между машинами и колесами есть связь «колесо прибито к машине». Это, собственно, структура БД и данные о ней.
                            • +1
                              Смотрите. Я знаю, что на этапе дизайна СУБД есть инструменты для работы с такими ограничениями, и для генерации проверок. Мой сценарий — про другое. Мне нужны хранимые правила, которые могут вноситься и меняться в процессе работы с готовой базой, а не её авторами.
                              • 0
                                О, вы хотите настраиваемую систему. Окей, просто поднимаемся на уровень выше, и в БД храним абстрактные «сущности», «атрибуты» и «связи», а также метаданные обо всем это, все остальное делаем в рантайме. Все минусы конфигурируемых в рантайме систем — с вами.

                                Но концептуально это ничем не отличается, мы просто двигаем момент модифицируемости той или иной информации (и всего, что от нее зависит) в разные стороны.
                                • +1
                                  Вот об этом и речь в моём кейсе в ответ на ваш исходный вопрос " а зачем это все реализовывать?".

                                  В этом сценарии и необходимы выделение, реализация и вынесение в интерфейс всех сущностей, обычно разносимых на разные уровни «мета».

                                  А у кого такой задачи нет — тот, разумеется, и не реализует все уровни, а использует классические интрументы настройки СУБД, работающие на уровне модели данных.
                                  • 0
                                    Заметим, что нет. Для вашего сценария из трех перечисленных вещей необходимо реализовать одну — описание (метаданные) сущности. Сами сущности из него в любом случае получаются автоматом, а списки вообще в вашей задаче не участвуют.

                                    Т.е. в таких сценариях все равно есть разделение на две составляющих — интерфейс работы с метаданными (аналогично дизайнеру БД) и интерфейс работы с данными (аналогично формам ввода информации с БД), и каждая из них существует ровно в своем пласте.
                                    • +1
                                      В сфере САПР, где я с этим сталкивался, базовые типы оборудования могут быть зашиты и недоступны пользователю, их подтипы — пополняемы, включая новые атрибуты, а новые правила доступны для создания пользователю и могут ссылаться и на зашитые типы, и на их кастомизированные подтипы. То есть в продукте таки есть минимум три уровня, не считая индивидуальные объекты.

                                      Про «в своём пласте» я вообще не понимаю. Разумеется управление разными слоями разнесено между экранами и ролями, но хранилище под этим одно, и в его модели надо решить все эти проблемы.
                                      • 0
                                        хранилище под этим одно, и в его модели надо решить все эти проблемы.

                                        Хранилище под этим не обязательно одно, а у этих проблем есть типовые решения. Но в общем, я вас услышал, в классе динамических систем такая задача (хотя и в неполном виде) действительно востребована.
                          • 0
                            Чем вас не устраивает такой вариант:

                            Таблица Машин:
                            {VIN (ID машины, ключ),
                            модель,
                            число осей,… и т.д.}

                            Таблица колес:
                            {Номер (ID колеса, ключ),
                            Диаметр,
                            Ширина,… и т.д.}

                            Таблица связей «Колеса машин»:
                            {VIN (ID машины, внешний ключ),
                            Номер (ID колеса, внешний ключ),
                            Вариант установки}

                            Таблица (или перечисление) «Варианты установки»:
                            {Первая ось — левое,
                            Первая ось — правое,
                            Вторая ось — левое,
                            Вторая ось — правое, и т.д.}

                            ?
                            • +1
                              Вы всё же прочтите всю дискуссию. Тут меня всё устраивает. Мне нужна запись правил о сущностях Машина и Колесо без редизайна базы. Например, у каждой машины ровно 4 колеса. Как хранить это правило?
                              • 0
                                Обязательно вдумчиво прочту на выходных. Для меня это тоже очень важная тема.
        • 0
          А если появится трехосный грузовик с удвоенными колесными парами? Переписывать все?
          • 0
            В зависимости от первоначальных требований и дизайна системы. Может быть, много, может быть — мало. Зависит во многом от того, насколько в систему закладывали подвижность в этой области.
  • +2
    А почему-бы не перейти к парадигме онтологий — «ключ — тип связи — значение»? OWL, RDF?

    Связи, которые есть у всех машин — базовый класс. Добавление специфичных связей к специфичной машине — наследование. Более того — список машин и одна машина в обработке никак не отличаются. Запросы простые — похожи на SQL (SPARQL). Есть и стандарт на эту тему ISO15925
    • +2
      Как вариант, да. Однако, пост о том, что хотелось бы реализаций этих продвинутых онтологий в мейнстриме уровня C#/Java/SQL Server — речь не о конкретных языках/СУБД, а об уровне мейнстрима.
    • +2
      Да, именно это решение для такого класса задач и применяется. Правда, пока в извращённой форме. Отдельно дизайнится реляционная или объектная система хранения ограничений. Отдельно — система хранения данных о конкретных машинах. А в RDF хранится общая концептуальная модель предметной области и мэппинг, который отдельный engine может использовать для извлечения правил из первой БД и верификации данных во второй.
  • 0
    Как важное понятие «поведение» ложится на язык теории множеств? Теория множеств вообще оперирует понятиями принадлежности, булевых операций, мощности, функций. Даже беглый взгляд на коддовскую алгебру показывает, что это нечто более богатое, чем стандартная теория множеств. Тем более ООП.
    • 0
      Думаю, этот вопрос лучше задать в исходной статье: habrahabr.ru/post/249165/

      Здесь же я предложил обсудить вопросы моделирования, связанные с описанием сущностей и их признаков.

      Но давайте попробует поговорить и о поведении:

      Вы знаете, что поведение, которое в ООП наследуется, а также может перекрываться (полиморфизм), часто подвергается критике?

      И есть такой подход, когда поведение не наследуется, наследования вообще как бы нет,
      но каждый объект может реализовывать множество разных интерфейсов.
      Такой подход реализован в т.ч. и в таком потенциальном кандидате на будущий мейнстрим, как Golang?
      В этом случае у нас при моделировании предметной области снимаются сложные вопросы, связанные с реализацией поведение в части наследования и полиморфизма.
      В общем, какое нужно, такое и добавляем поведение через интерфейсы.
      • 0
        Это не ответ. Вопрос ведь не в том, чем плохи или хороши механизмы ООП, а в том, каким образом специфицировать поведение на языке теории множеств?

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

        Существует метод, основанный напрямую на аксиоматике Цермело-Френкеля дял теории множеств, это Z-нотация. К сожалению, я не специалист по этой теме, но беглый взгляд на мануал spivey.oriel.ox.ac.uk/mike/zrm/zrm.pdf не позволяет сказать, что этот метод заточен под динамические аспекты систем. Возможно, я ошибаюсь.
        • 0
          Если вас не удовлетворяет мой ответ, то это связано с тем, что я являюсь специалистом по ООП и реляционным БД (а также моделированию предметной области в той части, где это можно сделать путем средствами ООП и реляционной модели), но не являюсь специалистом по теории множеств.

          Поэтому ответы на вопросы, которые вы задаете, мне тоже были бы интересны.

          Повторюсь, идея публикации в том, что работа с ООП и реляционными БД выявила их недостатки, связанные с моделированием предметной области или реализацией в коде/схеме БД уже имеющихся моделей, полученных от бизнес-аналитиков.
          И поэтому вопрос
          чем плохи или хороши механизмы ООП
          имеет место быть.

          Ответ на ваш вопрос дадут, видимо, специалисты по теории множеств, а мне как разработчику по-прежнему хотелось иметь такие средства и платформы разработки, которые нативным образом позволяли бы реализовывать «метод, основанный напрямую на аксиоматике Цермело-Френкеля» или любой другой, который вас устроит в части реализации поведения в теории множеств.
          • 0
            Осталось найти этих специалистов и подключить к дискуссии :) Лично я, будучи знаком с теорией множеств как математик, не нахожу ее саму по себе достаточной, для того чтобы заменить существующие практики, выросшие из или рядом с ООП. Но с другой стороны, я всегда смотрел на теорию множеств как на внутренний инструмент самой математики…
            • 0
              Павел, один из столпов логической парадигмы — это представление мира в виде 4-Д пространства-времени. В таком пространстве нет изменений. там все статично. Это позволяет применить теорию множеств к описанию динамики систем через описание 4-Д экстентов.
    • 0
      Насколько я понимаю, никаким. ISO 15926 направлен на стандарты описания и передачи данных, а не описание их обработки. Я сильно подозреваю, что эта парадигма неплохо ложится на функциональное программирование, когда данные (в частности, описанные в терминах принадлежности ко множествам) прогоняются через не имеющие собственного состояния обработчики.
    • 0
      поведение в логической парадигме описывается при помощи 4-Д объектов. В лекции очень хорошо про это рассказано.
  • 0
    дубль.
  • 0
    что-то вроде orientdb.com?

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