Re[5]: Эволюция диаграмм сущности-связи
От: Sinclair Россия https://github.com/evilguest/
Дата: 09.11.22 14:00
Оценка:
Здравствуйте, velkin, Вы писали:

V>Дело в том, что все виды схем или диаграмм имеют какую-то парадигму.

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

V>Про ту же RDF (не графическая схема) можно было бы говорить ещё проще, граф.

RDF — это не просто граф, и не всякий граф — это RDF.

V>У меня же речь идёт о парсинге (синтаксический анализ) с точки зрения обработки текста (text processing).


Диаграммы и обработка текста связаны между собой примерно никак.

V>Мысль у меня такая, обычный человек не сможет сразу уйти с текстового представление на графически представленный граф.

"Графическое" представление позволяет ускорить восприятие некоторых вещей, замедляя восприятие других.

Повторюсь: вопрос не столько в "картинках", сколько в устройстве и топологии модели.

V>Существует огромное количество проблем. Начать хотя бы с представления данных. Они ведь не только на английском языке, будь они даже на русском, это не значит, что выбор слов был наилучшим для конкретного человека. Например, append и push back частный случай insert в самый конец, а то и какой нибудь add со своими нюансами.


Пока что всё ещё непонятно, в какой области возникают проблемы, и какие решения вы предполагаете.
В целом, мы говорим о какой-то модели. Модель выражена в терминах каких-то "частей", которые тем или иным образом складываются в цельную картину.
Чтобы модель передать от одного разума к другому, нам нужен некоторый язык.
Может быть — текстовый, может быть — звуковой, может быть — графический.
Или комбинация тех и других.

Но есть два разных аспекта: структура самой модели (метамодель), и устройство языка, которым эта модель описывается.
ER-модель можно описывать текстом, можно — диаграммой с фигурами и линиями. Но модель будет одна и та же.
Если в мета-модели у вас есть понятия "атрибут", "тип атрибута", "сущность", "тип сущности", "связь", "тип связи", "роль", то модель строится именно в этих терминах.
Мы можем выбирать разные способы изображения этих понятий — формой, цветом, текстом. Но если вы говорите, "давайте откажемся от этих понятий", то вы теряете в выразительности модели, независимо от конкретного языка, которым вы её описываете.


V>Взять тот же UML, что он делает. А ничего, он просто обёртывает всё по старому методу боксов, то есть список с заголовком.

Ничего подобного. Без мета-модели, то есть некоторой договорённости о том, что означают "боксы", UML-диаграммы не имеют никакого смысла.
V>Но людям скажут, что это теперь не список с заголовком, а класс со свойствами и методами. Тоже самое и с ER, мне то какая разница что они там нарисовали прямоугольник или ромб с овалом, если внутри всё тот же текст. Есть ещё блок-схемы, диаграммы потоков и многое другое.
Совершенно верно. И все они означают совершенно разные вещи. Я не понимаю, как вы собираетесь "заменить все диаграммы одной диаграммой" без потери смысла.

V>Действительно ли форма элементов, то есть вершин как-то решает. Вот здесь я сильно сомневаюсь. Ну или вместо этого можно было бы делать подпись как у стереотипа в UML, или изобрести цветовую кодировку. Если рассуждать в стиле я человек простой, то если это атрибут я мог бы просто делать дополнительную подпись "атрибут", а не выдумывать овал. Тоже самое касается отношения и чего угодно. По сути форма фигур ограничивает количество вариантов количеством форм.

Вы явно путаете форму и суть. Любую ER-диаграмму можно записать в текстовом представлении; для того, чтобы она описывала именно ER-модель, на это текстовое представление придётся наложить какие-то ограничения.
Например, в обычной ER-диаграмме нельзя использовать фигуру "звезда". Это никак не связано с формой — в текстовом описании модели вы точно так же не сможете, к примеру, привязать что-то с припиской "метод" к типу сущности. Потому что в мета-модели ER нет понятия "метод". Есть только "атрибут", "тип атрибута", "сущность", "тип сущности", "связь", "тип связи", "роль". А в диаграмме классов UML (или в описании класса ООП модели) вы к классу привязать "метод" вполне можете.

V>Вот именно для этого все вышеупомянутые мной диаграммы и нужны. Только каждая пытается следовать какой-то парадигме заложенной авторами по своему разумению. И скажем так, эволюция им бы не помешала, так как простые вещи они выражают довольно криво.


Вы всё ещё даже не попробовали повыражать хоть какие-то вещи при помощи этих диаграмм. Практика — критерий истины, а не абстрактные рассуждения "можно ли заменить форму цветом". Кстати, нет, нельзя — это сделает вашу диаграмму нечитаемой значительной долей целевой аудитории.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.