Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 142
В терминах ООП говорят так: есть класс ООП автомобилей и есть класс ООП колес. Между этими классами ООП есть связь один к четырем. Связь называется: «автомобиль-колесо».
Это неверно. В терминах ООП нет связей. В терминах ООП у одного из этих объектов будет свойство, хранящее ссылку, или коллекцию ссылок, или экземпляры другого объекта.
Но ни тот ни другой метод моделирования не позволяет моделировать семантические отношения между объектами и классами объектов. Это является существенным ограничением современных моделлеров, которое необходимо устранять.
Зачем? Для решения какой конкретной прикладной задачи это необходимо?
Связи в UML есть. Они не могут не есть). Например, тут видно описание этих связей: 
Правда, тут же говорится, что связь между классами означает связь между объектами классов, но вот тут они перегнули палку. Если такая связь и есть, то она совершенно другая.
Правда, тут же говорится, что связь между классами означает связь между объектами классов, но вот тут они перегнули палку. Если такая связь и есть, то она совершенно другая.А вы не путайте UML и ООП, хорошо? Если вы свое представление об ООП строите на UML, то лучше так и пишите — «в используемой мной UML-нотации», а не «в ООП».
ОК, спаибо! Но я имел ввиду подход, а не программирование. Надо будет уточнять это.
Подход тем более не в UML описывается.
Любая программа — это взаимосвязь блоков и отношения частей (ваш К.О.). И ООП — не исключение, свойства отражают это отношение, но вводит еще и связь «хранит».
Парадигма «вещей и связей» вообще одна из самых универсальных, так что не удивительно, что и ООП может быть выражено с ее помощью. Вопрос в том, надо ли подменять внутреннюю терминологию ООП терминологией более общей парадигмы.
Термины ООП предназначены для описания кода. Они не предназначены для описания предметной области, отличной от кода. Попытки «натянуть» ООП на описание предметной области порождают термины, которые трудно себе представить. Например, наследование в классах. Нет наследования в природе, кроме того, которое возникает при размножении. Попытка аналитиков говорить на птичьем языке вызывает у меня удивление. Лично мне прикольно слышать «экземпляр этого молотка». Оставьте термины ООП для описания кода и все будет хорошо.
Все же, мне кажется, вы нарушаете принцип логической парадигмы. Для того, чтобы зафиксировать количество колес на индивиде-автомобиль надо отнести его к классу «автомобили с 4 связями авто-колесо» или просто «с 4 колесами». Связь между индивидом (автомобилем) и классом может быть только «классификация» (отнесение индивида к тому или иному классу). Указанная вами связь «индивид имеет класс» в логической парадигме принципиально невозможна. Если вы хотите ее ввести, то говорите о иной парадигме.
В математике мы часто встречаем связи между объектами и классами. Например, прямая и класс точек прямой, или множество монет и покупка. Мое мнение, что отсутствие в текстах подобной связи говорит об инерции мышления, а не о порочности такого способа мышления. И, если логическая парадигма строится на теории множеств, то подобная конструкция допустима. Иначе надо признать, что логическая парадигма строится не на теории множеств.
В математике мы часто встречаем связи между объектами и классами.Но это не связи типа «прямая имеет класс точек», «покупка имеет множество монет».
Связь логической парадигмы с теорией множеств заключается в том, что мы описание каждого объекта ведем через причисление его к тому или иному множеству/классу. Вы сами это декларировали в предыдущих статьях. Отношение «объект имеет класс» выходит за рамки логической парадигмы.
Мое мнение, что отсутствие в текстах подобной связи говорит об инерции мышления, а не о порочности такого способа мышления.Да вы имеете полное право как угодно расширять рамки мышления и вводить новые парадигмы. Но это надо оговаривать отдельно, начиная с того, зачем это нужно и какие задачи вы собираетесь решать.
Но это не связи типа «прямая имеет класс точек», «покупка имеет множество монет».
Семантика связи — тема отдельная. Главное, что такая связь есть, и ее надо уметь моделировать
Главное, что такая связь есть, и ее надо уметь моделироватьС этого — с постановки проблемы — и надо начинать. Но вопрос-то заключается именно в том, что такой связи нет в логической парадигме. Это надо признать и строить другую, в которой имеются другие связи между объектом и классом/множеством кроме «классификация».
Поддерживаю, особенно если связей несколько, вообще не понятно, о каком множестве речь.
Думаю, можно было бы рассматривать подмножество множества всех возможных кортежей вида автомобиль-колесо1-колесо2-колесо3-колесо4.
Думаю, можно было бы рассматривать подмножество множества всех возможных кортежей вида автомобиль-колесо1-колесо2-колесо3-колесо4.
Каждый кортеж что-то значит. Например, пусть есть Маша и Миша. Кортеж (Маша; Миша) может принадлежать классу кортежей с семантикой: «женаты». Кортеж (Миша;(Миша; Маша)) может принадлежать классу кортежей с семантикой: «отношение супруга к браку». Поэтому перечень объектов в кортеже, их порядок важны. Кортеж вида (автомобиль№1; колесо№1; колесо№2; колесо№3; колесо№4) может иметь определенную семантику, но надо явно проговорить какую. Иначе не ясно, о чем идет речь.
Но это не связи типа «прямая имеет класс точек»
Давайте посмотрим. У прямой есть два свойства — с одной стороны, она определяет некоторое множество точек, с другой — у неё есть направление. Говорить, как учили в школе, что «прямая является множеством точек» не очень хорошо. Одна из причин — что у «множества точек» направления нет. В терминах ООП мы могли бы сказать, что прямая наследуется от множества точек. Математики будут возражать: например, проективная плоскость определяется как множество точек и множество прямых, связанных предикатом «точка лежит на прямой». Прямая там равноправна с точкой. Можно сказать, что у прямой есть интерфейс «множество точек». А можно сказать, что у прямой есть property «множество точек», так же как и property «направление». И если мы можем сказать «прямая имеет направление», то почему не верно, что «прямая имеет множество точек»? Да, так не говорят. Но разницы в типах связи «прямая — направление» и «прямая — множество точек» я не вижу.
У прямой есть два свойства — с одной стороны, она определяет некоторое множество точекЭто не свойство, а способ описания.
И если мы можем сказать «прямая имеет направление», то почему не верно, что «прямая имеет множество точек»? Да, так не говорят. Но разницы в типах связи «прямая — направление» и «прямая — множество точек» я не вижу.Здесь проблема в слове «имеет». Да, сказать «прямая — множество точек» вполне можно — это означает, что мы можем представить/описать прямую как множество точек. Но «прямая имеет множество точек» выражает отношение часть-целое, мол есть некая прямая и у нее есть (не она сама есть, а у нее есть) множество точек.
Так и с машиной и колесами: можно сказать, что машина есть множество ее деталей, но у машине есть класс колес, машина содержит класс колес принципиально некорректно. Отношение часть-целое может быть только между однородными сущностями. Вещь может быть частью вещи, множество может быть частью только множества.
Это не свойство, а способ описания.
Это именно свойство. Говорить, что прямая определяется множеством точек можно не всегда.
Например, в классификации кривых второго порядка «кривая» x^2+y^2=0 классифицируется как «пара пересекающихся комплексно сопряженных прямых». Каждая из этих прямых на плоскости имеет ровно одну точку (0,0) — но при этом прямые разные. А «пара параллельных мнимых прямых» x^2+1=0 вообще точек не имеет. Это не мешает прямым быть прямыми и участвовать в различных выкладках. То, что прямые при этом определяют какие-то множества на плоскости с комплексными координатами, чаще всего никого не интересует — все работают с уравнениями.
А насчёт слова «имеет» — формулировку «прямая имеет направление» или «машина имеет цвет» вы тоже будете считать некорректной? Эти случаи трудно воспринять как отношение «часть-целое». Есть целая машина, и у неё есть цвет, цена, хозяин, порт приписки и дата первого запуска мотора. Все они относятся к машине так же, как множество её колёс. И как множество точек — к прямой.
А насчёт слова «имеет» — формулировку «прямая имеет направление» или «машина имеет цвет» вы тоже будете считать некорректной?Проблема ведь не в словах. Сам maxstroy использует слово «имеет» как указание на то, что класс колес является частью машины. Посмотрите на рисунок, там написано «класс колес стоит на машине».
класс колес является частью машины
В данном контексте я этого не говорил. Дело в том, что под «имеет» я имел ввиду слова заказчика. В его воображении машина имеет группу колес, что я и записал, Никакого другого смысла я в это не вкладывал. Правда, перед тем, как записать это, я проверил и спросил заказчика: Вам действительно не важно, если я переставлю колеса местами, или заменю одни колеса на другие? Он сказал, что ему по бую. Поэтому я и нарисовал связь между машиной и группой колес.
В данном контексте я этого не говорил.Я понимаю, что контекст может быть разным, но в данном тексте вы продолжаете развивать идею записи "Класс объектов или объекты класса?", а там в комментариях вы написали:
@maxstroy: Есть класс колес. Есть автомобиль. Я говорю, что авто состоит из класса колес. (ссылка)И на картинке в текущем тексте у вас связь между классом колес и автомобилем обозначена как «класс колес стоит на автомобиле». Причем тут заказчик? Вы же пытаетесь сформировать точный язык, строгую логику. И вам надо дать однозначный ответ на вопрос: может ли индивид (автомобиль №12) вступать с классом в отношение целое-часть.
Кстати, я не очень понимаю, почему вы вообще избегаете называть эту связь своим именем? Двигатель стоит на авто — это означает двигатель является частью авто.
В прошлой статье я имел ввиду совсем другой контекст. В данной статье я специально изменил его, чтобы не возникало лишних вопросов. «Стоит на» не равно «состоит из».
«Стоит на» не равно «состоит из».Да, конечно, не равно. Но обе фразы («стоит на» и «состоит из») указывают на отношение «часть-целое», которое вы упорно не хотите обсуждать. Даже избегаете его произносить.
Повторю свой вопрос: может ли индивид (автомобиль №12) вступать с классом в отношение целое-часть?
Но обе фразы («стоит на» и «состоит из») указывают на отношение «часть-целое», которое вы упорно не хотите обсуждать
В данной статье я специально не обсуждаю эту тему. Это заготовка под статью, где я расскажу про все отношения «Часть-целое», которые мы используем в быту. Но пока рано — не все определения введены. Прошлая статья показала, что без полного введения всех сущностей, понять отношения часть-целое не удается. Поэтому отложим этот разговор до будущих времен. А сейчас обсуждаем только отношение «стоит на»
«Часть-целое», которые мы используем в быту.Забавно. Это одно из первейших семантических отношений (см. например, тут). Куча книг и статей написано на эту тему.
А сейчас обсуждаем только отношение «стоит на»Хорошо. Можно ли считать это положительным ответом на вопрос: может ли класс стоять на индивиде?. Если да, то требуется уточнение: класс стоит на индивиде (авто), так же как на авто стоит двигатель? Нужен ли слесарь, чтобы снять класс с авто? или достаточно просто удалить класс из онтологии на моделлере?
И могу повторить и свой изначальный вопрос, по которому вы так и не дали пояснений. В логической парадигме все свойства любого объекта задаются указанием на вхождение его в тот или иной класс (так вы писали в первых текстах). Теперь вы вводите принципиально новое отношение объекта и класса (класс стоит на объекте). Как это соотносится с логической парадигмой? На мой взгляд, это уже нечто совершенно иное (безотносительно самой осмысленности этого отношения). То есть вы уже не имеете право ссылаться на логическую парадигму.
Мы обсуждаем семантику. Какие семантические отношения возможны и между чем? Берем термин «состоит из» и смотрим, между объектами каких классов возможно такое отношение. Берем термин «стоит на» и смотрим, между объектами каких классов возможны такие отношения. Берем термин «Похож на» и смотрим, между объектами каких классов возможны такие отношения. Логическая парадигма — это теоретико-множественный подход. В логической парадигме мы можем рассматривать любые концепты и анализировать их. В логической парадигме есть отношения «похож на», «стоит рядом», «женат» и так далее.
В логической парадигме есть отношения «похож на», «стоит рядом», «женат» и так далее.Да какие угодно. Но все они выражаются через отнесение объекта к одному из классов: класс «похожие на Бреда Пита», класс «стоящие рядом с пивным ларьком», класс «женатые». Других отношений между индивидом и классом в логической парадигме нет. Это и есть теоретико-множественный подход.
А что такое класс стоит на автомобиле я даже представить себе не могу. Есть класс "колеса стоящие на авто" — его элементами являются колеса. Может быть класс "автомобили с 4 стоящими на нем колесами" — его элементами являются автомобили. В логической парадигме автомобиль может только входить в класс, но никак не включает класс в себя.
Последний контрольный вопрос: может ли в логической парадигме какое либо-другое отношение между индивидом и классом кроме индивид является элементом класса? (Я спрашиваю не про ваши соображения о возможных отношениях, а конкретно про логическую парадигму.)
А что такое класс стоит на автомобиле я даже представить себе не могу
Я тоже не могу, но логика говорит о том, что такое возможно. Именно это я и доказываю. И это не противоречит теории множеств.
В логической парадигме автомобиль может только входить в класс, но никак не включает класс в себя.
Термин «включает» требует определения. Также как термин «состоит из». Об этом я буду говорить в следующих статьях.
может ли в логической парадигме какое либо-другое отношение между индивидом и классом кроме индивид является элементом класса?
Отвечу: а в теории множеств есть такие отношения? Если есть в теории множеств, то есть и в логической парадигме. Примеры приводились ранее и не только мной.
В теории множеств класс колёс автомобиля можно построить с помощью схемы выделения, используя класс колёс вообще в качестве базового множества, а автомобиль — как часть формулы селекции. Но будет ли это считаться «отношением» между классом и автомобилем, это вопрос. Понятно, что можно записать такое отношение, вынеся автомобиль за пределы формулы, и сделав его аргументом отношения. Тогда про любой класс можно будет сказать, является ли он именно классом колёс и именно этого автомобиля.
maxstroy: Я тоже не могу, но логика говорит о том, что такое возможно.Я этой логики не увидел.
А в конструкции «класс колёс, стоящих на конкретном автомобиле» какое отношение между классом колёс и индивидом автомобиля? Явно не «индивид является элементом класса». Или подобное отношение («индивид является частью предиката, определяющего класс») в логическую парадигму не входит?
в конструкции «класс колёс, стоящих на конкретном автомобиле» какое отношение между классом колёс и индивидом автомобиля?
Отношение «стоит на».
А в конструкции «множество чисел, больших X»? Сказать, что множество больше числа, мы не можем.
Как говорил мой знакомый математик, мы можем говорить все, что нам захочется, если дадим терминам определение. Если мы определим, что значит отношение между множеством и числом, то ничто потом не помешает нам пользоваться этим отношением.
Было такое. Примерно 150 лет назад:
«When I use a word,» Humpty Dumpty said, in rather a scornful tone, «it means just what I choose it to mean—neither more nor less.»
«The question is,» said Alice, «whether you can make words mean so many different things.»
«The question is,» said Humpty Dumpty, «which is to be master—that's all.»
спасибо! Я не читал оригинал, сожалею. Вы правы. Вопрос в том, кто и как определит термин. Главное — определить его. Есть общеупотребительные термины, есть те, которые создаются под задачу. Если необходимо создать новый термин, нам ничто не мешает это сделать. Главное — чтобы он был нужен и не был синонимом уже существующего.
Супремум и инфинум.
Наименьшее число, ограничивающее сверху некоторое множество чисел называется точной верхней гранью
или супремумом этого множества. Двойственным образом наибольшее число ограничивающее снизу неко-
торое множество чисел называется точной нижней гранью или инфинумом этого множества. Супремум множества A обозначается sup A, инфинум множества A обозначается inf A.
В этих определениях вводится семантическая связь между числом и множеством чисел.
Супремум и инфинум.
Наименьшее число, ограничивающее сверху некоторое множество чисел называется точной верхней гранью
или супремумом этого множества. Двойственным образом наибольшее число ограничивающее снизу неко-
торое множество чисел называется точной нижней гранью или инфинумом этого множества. Супремум множества A обозначается sup A, инфинум множества A обозначается inf A.
В этих определениях вводится семантическая связь между числом и множеством чисел.
А в конструкции «класс колёс, стоящих на конкретном автомобиле» какое отношение между классом колёс и индивидом автомобиля?Это название класса. Назовите так «колеса автомобиля» или «КА»
Не могу. Для разных автомобилей будут разные классы, а сами автомобили названия не имеют, это всего лишь объекты — в программе или в мире. Поэтому включить автомобиль в название не удастся. И определить по названию «колёса автомобиля#812», какой автомобиль использовался в построении, тоже не получится. А это вполне конкретный автомобиль. Связанный с этим классом, но не входящий в него.
To Mrrl
Мне кажется, тут у нас получилась какая-то каша. Название класса — это просто название, ну хоть «Hu65FDE6». Способ задания элементов класса тут простой — перечисление его элементов (колеса на конкретном авто). Поэтому ваш вопрос:
Мне кажется, тут у нас получилась какая-то каша. Название класса — это просто название, ну хоть «Hu65FDE6». Способ задания элементов класса тут простой — перечисление его элементов (колеса на конкретном авто). Поэтому ваш вопрос:
А в конструкции «класс колёс, стоящих на конкретном автомобиле» какое отношение между классом колёс и индивидом автомобиля?Не имеет смысла. Он про название или про элементы класса. Или проще ответить так: никакого нет отношения. Поскольку это просто класс и для фиксации его отношений с другими сущностями надо как-то определять эти отношения. В процедуре задания класса и тем более в его названии они не определены.
Способ задания элементов класса тут простой — перечисление его элементов (колеса на конкретном авто).
Такой способ задания будет неустойчив к отвинчиванию колеса и использованию его на баррикадах — класс по-прежнему будет считать, что это колесо всё ещё относится к этому автомобилю.
Но класс можно задать как-то так:
Car thisCar;
…
class wheelsOfCar=(class Wheel).RestrictedBy(x => x.AttachedTo(thisCar));
(синтаксис условный). Тогда в класс будут входить именно те колёса, которые стоят сейчас на конкретном автомобиле. И какое теперь отношение между автомобилем и классом?
А это приводит нас к следующей задаче: необходима историйность класса. Что и когда входило в этот класс?
Такой способ задания будет неустойчив к отвинчиванию колесаНе понял. Что значит «неустойчив»? Отвинтили колесо — в классе «Hu65FDE6» стало на один элемент меньше. Где проблемы?
И какое теперь отношение между автомобилем и классом?Никакого. В логической парадигме может быть только одно отношение: объект является/не является элементом класса. Если вы о чем-то другом (не о логической парадигме, которую излагает maxstroy), то тогда и разговор будет другим.
Поправьте меня, но глядя на вашу ЕР диаграмму: нельзя добавить автомобиль, пока нет колес и нельзя добавить колесо, пока нет автомобиля.
В воображаемом мире, который мы описываем, автомобиль создается вместе с колесами.
Одновременно вставлять записи в две таблицы можно, действительно, только в воображаемом мире.
Концептуальная модель предметной области не моделирует таблицы. Это заблуждение, что концептуальная модель имеет какое-то отношение к хранению данных. Таблицы моделирует другая модель: физическая, или модель данных. Но даже в физических таблицах одновременное добавление записей возможно и порой необходимо. Это реализуется механизмом транзакций.
Вообще-то, транзакция над двумя таблицами не дает одновременного добавления записей, только согласованное. А по времени оно (если записи вставляются на одном сервере) последовательное.
Конечно, но для пользователя они добавляются обе вместе, или не добавляются. Невозможно добавить одну, не добавив другую. Иначе — коллизия.
Вот только эта невозможность добавить не имеет ничего общего с физическими таблицами. И, что важнее, не означет возможность одновременной вставки записей в эти таблицы.
Так что, хотя на уровне домена чтобы объекты были согласованными, они должны содержать заполненные встречные связи, на уровне физической модели такое ограничение (и такая операция) как минимум в ряде реляционных СУБД невозможно.
Так что, хотя на уровне домена чтобы объекты были согласованными, они должны содержать заполненные встречные связи, на уровне физической модели такое ограничение (и такая операция) как минимум в ряде реляционных СУБД невозможно.
Хорошо, пусть так. я не претендую на моделирование данных. Мои работы направлены на моделирование предметных областей, где нет ни таблиц, ни транзакций, ни записей.
Я очередной раз прошу вас не делать утверждений в тех областях, в которых вы не разбираетесь.
Качество диспута зависит от всех сторон-участников. Если бы участники оставались в рамках обсуждаемой темы, было бы проще. Но в данной ветке зачем-то обсуждается модель данных, в параллельной — в чем рисовать модели. С акынами трудно вести конструктивный диалог. Так что пока — поем каждый свою песню.
Похоже на Sybase Power Designer, дороговатый инструмент для рисования диаграмм.
Не то слово! Но я склоняю голову перед теми, кто сделал этот продукт! Если почитать хелпы, становится ясно, сколько времени потрачено на вылизывание платформы. Очень точные и очень лаконичные термины. Сшито все очень качественно. Качественно по сравнению с другими продуктами. Но по абсолюту можно еще доработать.
Любое моделирование должно иметь цель, тогда уже легче ответить на вопросы как смоделировать. Это может быть просто познание мира, автоматизация, моделирование ситуация «что если», передача знаний ребенку, пердача знаний другому специалисту и многое другое.
Также если говоритьь о концептуальной модели, то это инструмент для отображения общего понимания предмета разговора, если говорить кратко.
Потому вопросы:
1. Какая ваша цель моделироавания?
2. Что дают дополнительные элементы на диаграмме? Почему мало 2х элементов автомобиль и колесо плюс связи 1-4 (вот прям так и написать на связи жестко, концептуальное моделирование это разрешает).
3.Зачем производить концептуальную модель в виде ЕР диаграммы?
Также если говоритьь о концептуальной модели, то это инструмент для отображения общего понимания предмета разговора, если говорить кратко.
Потому вопросы:
1. Какая ваша цель моделироавания?
2. Что дают дополнительные элементы на диаграмме? Почему мало 2х элементов автомобиль и колесо плюс связи 1-4 (вот прям так и написать на связи жестко, концептуальное моделирование это разрешает).
3.Зачем производить концептуальную модель в виде ЕР диаграммы?
Какая ваша цель моделирования?
Я использую критерий: способен ли я создать представление модели без искажения смысла? Если клиент говорит одно, а я в модели рисую другое, — то либо я плохой аналитик, либо инструмент моделирования плох. Я рассматриваю те кейсы, в которых, даже, если бы я и хотел записать слова клиента корректно, то не могу по причине того, что инструмент моделирования мне этого не позволяет. И говорю, чего именно мне не хватает.
Почему мало 2х элементов автомобиль и колесо плюс связи 1-4
Мы правильно понимаем, что вы связали автомобиль и колесо четырьмя связями? Но у автомобиля 4 колеса, а не одно колесо. Поэтому вопрос не понятен.
Зачем производить концептуальную модель в виде ЕР диаграммы?
Причина, по которой я предпочитаю ER модель, я указал: это то, что она ближе к моделированию классов, чем диаграмма классов UML.
про ясную цель моделирования все же ничего не сказано. цель — создать представление модели без искажения смысла? можно ли так вообще формулировать цель? веь взяв любой объект можно сделать миллион его разных моделей. Тот же автомобиль —
— если хотим детям объяснить что такое КРАЗ — можно показать игрушечную модельку КРАЗа не таща ребенка на производство
— если нужно запрограммировать сайт для продажи колес автомобиля, то нужна модель не самого автомобиля а данных про автомобиль которые нужно сохранить в базе (если упрощенно)
— если мы рисуем схему ДТП то на ней машинка в виде прямоугольника с палочками в виде колес — это тоже модель.
и так далее. о каком искажении смысла идет речь?
при построении любой модели важно:
а) понимать настоящую цель ее использования и применения
б) точку зрения того кто делает модель ()для руководителя и для подчиненного модель одного и того же почти всегда будет разной)
в) найти способ максимально упрощенно представить модель чтобы в ней не было ничего лишнего что не касается вашей цели
г) сделать это наглядно
Если клиент говорит одно… тут похоже есть конкретная ситуация с клиентом, которую может быть стоит разобрать?
Клиенту на модели такого вида обычно вообще все равно, используем их мы — аналитик, разработчики, для обмена знаниями, построения программ и т.п.
Последняя диаграмма в приведенной статье — вот о ней я говорила. Она вполне достаточна для большинства задач связанные с моделированием машины. просто на линии поставить слева 1, справа 4 и все.
погодите… Вам нужно промоделировать классы? или все же данные для хранения информации?
Концептуальная модель — это общая диаграмма на которой может быть ЧТО УГОДНО и КАК УГОДНО и это принципиально, она может отражать любой срез который хочет аналитик без привязок. Обычно полезна вначале понимания предметной области когда еще не понятно где точно функция, где информационный поток, где какие роли.
Я просто почему пишу это — в Вашей статье есть некоторые аспекты которые начинающие наверняка неправильно истолкуют. Если цель поделиться знаниями для подрастающего поколения — я внесла бы коррективы на этот счет.
— если хотим детям объяснить что такое КРАЗ — можно показать игрушечную модельку КРАЗа не таща ребенка на производство
— если нужно запрограммировать сайт для продажи колес автомобиля, то нужна модель не самого автомобиля а данных про автомобиль которые нужно сохранить в базе (если упрощенно)
— если мы рисуем схему ДТП то на ней машинка в виде прямоугольника с палочками в виде колес — это тоже модель.
и так далее. о каком искажении смысла идет речь?
при построении любой модели важно:
а) понимать настоящую цель ее использования и применения
б) точку зрения того кто делает модель ()для руководителя и для подчиненного модель одного и того же почти всегда будет разной)
в) найти способ максимально упрощенно представить модель чтобы в ней не было ничего лишнего что не касается вашей цели
г) сделать это наглядно
Если клиент говорит одно… тут похоже есть конкретная ситуация с клиентом, которую может быть стоит разобрать?
Клиенту на модели такого вида обычно вообще все равно, используем их мы — аналитик, разработчики, для обмена знаниями, построения программ и т.п.
Последняя диаграмма в приведенной статье — вот о ней я говорила. Она вполне достаточна для большинства задач связанные с моделированием машины. просто на линии поставить слева 1, справа 4 и все.
Причина, по которой я предпочитаю ER модель, я указал: это то, что она ближе к моделированию классов, чем диаграмма классов UML.
погодите… Вам нужно промоделировать классы? или все же данные для хранения информации?
Концептуальная модель — это общая диаграмма на которой может быть ЧТО УГОДНО и КАК УГОДНО и это принципиально, она может отражать любой срез который хочет аналитик без привязок. Обычно полезна вначале понимания предметной области когда еще не понятно где точно функция, где информационный поток, где какие роли.
Я просто почему пишу это — в Вашей статье есть некоторые аспекты которые начинающие наверняка неправильно истолкуют. Если цель поделиться знаниями для подрастающего поколения — я внесла бы коррективы на этот счет.
цель — создать представление модели без искажения смысла? можно ли так вообще формулировать цель? веь взяв любой объект можно сделать миллион его разных моделей.
Боюсь, что Вы неправильно меня поняли. Я не пытаюсь создавать модель. Модель создает заказчик. Моя задача — записать эту модель без искажений. Поэтому, если заказчик говорит, что у мотопупки сверху чвакалка, — моя задача указать это в представлении модели, а не пытаться придумывать модель за заказчика. Вторая задача — это верификация модели. На основе проверки я могу задавать уточняющие вопросы, чтобы прояснить детали, но ничего не придумываю сам. Это тот кейс, который я рассматриваю сейчас. После того, как мы научимся записывать модели за заказчиком, нам предстоит вторая задача — научиться придумывать их самостоятельно.
У заказчика как раз в норме нет модели, у него есть работающий (или не очень) процесс, нуждающийся в (простом случае) автоматизации.
Возможно, поэтому Вы меня не понимаете, потому что пытаетесь решить не ту задачу, которую решаю я. У меня не стоит задача автоматизации процесса. У меня стоит задача фиксации модели. То есть, я концентрирую свое внимание на записи концептуальной модели корректным образом тогда, когда она уже существует в голове у заказчика.
Я и не говорил, что у вас стоит задача автоматизации процесса.
Но в любом случае, задачи корректной записи модели из чужой головы стоят не может: поскольку телепатов (предположительно) не существует, необходимо сначала узнать, что в чужой голове (т.е., фактически построить свою модель), а только затем зафиксировать это.
Но в любом случае, задачи корректной записи модели из чужой головы стоят не может: поскольку телепатов (предположительно) не существует, необходимо сначала узнать, что в чужой голове (т.е., фактически построить свою модель), а только затем зафиксировать это.
Хорошо, но заказчиком исполнения модели могу быть я сам. Кто является заказчиком — не важно. Важно умение передать модель без ее искажения. Это моя задача. Эта задача ровно та же, что решалась математиками, когда они стремились найти способ описания мира. который был бы максимально приближен к нашему способу мышления. И нашли такой способ — математическую логику. Если мы хотим строить наши модели корректно, то нам придется воспользоваться достижениями математиков. Что я пытаюсь делать.
Кто является заказчиком — не важно
Важно, потому что от этого зависит, что именно вам как аналитику придется делать и как.
Эта задача ровно та же, что решалась математиками, когда они стремились найти способ описания мира. который был бы максимально приближен к нашему способу мышления. И нашли такой способ — математическую логику.
Вы серьезно? Я всегда считал, что (а) математика не занимается описанием мира, (б) математическая логика не является способом описания мира и (ц) математическая логика не так уж приближена к «нашему способу мышления».
Так что нет, математика — не обязательный пререквизит для корректного построения моделей. Особенно учитывая, что корректность модели — не такая очевидная характеристика, как вам того бы хотелось.
Мне всегда казалось, и так меня учили, что математика — это язык философии. Я не готов принять тот факт, что математика оторвана от реальности. Это кажется мне бессмысленным.
так меня учили, что математика — это язык философии
Это излишне романтизированное представление о математике.
Я не готов принять тот факт, что математика оторвана от реальности.
А я и не говорил, что математика оторвана от реальности, я всего лишь сказал, что математика не занимается описанием мира.
Это излишне романтизированное представление о математике.
Не согласен.
так меня учили, что математика — это язык философииИ это излишне примитивизированное представление о философии.
Это излишне романтизированное представление о математике.
Хотя можно ответить и проще: откройте тексты философов и поищите там формулы ))
я не хочу сказать, что все концепты философии можно описать формулами, но я утверждаю, что все математические концепты имеют философский смысл. То есть мое утвержден ие необходимое, но не достаточное.
Если не все концепты философии можно описать формулами, то математика не может являться языков философии, потому что она не способна ее выразить.
Не говоря уже о том, что из тезиса «все математические концепты имеют философский смысл», пусть и спорного, ровным счетом никак не вытекает, что математика — это способ описания мира.
Не говоря уже о том, что из тезиса «все математические концепты имеют философский смысл», пусть и спорного, ровным счетом никак не вытекает, что математика — это способ описания мира.
Я лишь утверждаю, что, если мы хотим научиться моделировать пространство-время, нам придется воспользоваться достижениями математики. Или их повторить. Мне кажется, что это очевидно. Если Вы считаете, что математика в этом не поможет, то нам не стоит продолжать дискуссию.
Я лишь утверждаю, что, если мы хотим научиться моделировать пространство-время, нам придется воспользоваться достижениями математики.
Во-первых, не математики, а физики. Математика не оперирует временем. Во-вторых, к математической логике это отношения не имеет.
Ну и в-третьих, не все моделируют пространство-время в своих задачах.
В каких-нибудь случайных процессах время очень даже присутствует. И в дифференциальных уравнениях переменная, по которой идёт дифференцирование, часто обозначается буквой t. Случайность? Не думаю.
И все же, математика per se оперирует некими величинами. Геометрия (часть математики) оперирует величинами, ассоциированными с пространством.
(при этом нет, не случайно, что дифференцирование идет по t, потому что дифференцирование хорошо ассоциируется с физикой; но если математическая формула решает какую-то прикладную задачу, то это еще не значит, что сама математика оперирует этими задачами, это всего лишь значит, что прикладная задача сводима к математической подменой терминов)
(при этом нет, не случайно, что дифференцирование идет по t, потому что дифференцирование хорошо ассоциируется с физикой; но если математическая формула решает какую-то прикладную задачу, то это еще не значит, что сама математика оперирует этими задачами, это всего лишь значит, что прикладная задача сводима к математической подменой терминов)
Я думаю, что данная тема бессмысленна в рамках данного контекста. Все, что я хотел сказать. я сказал в статье. Обсуждение математики, или физики в данном контексте выглядит лишним)
Тема беседы: может ли объект быть связан с классом объектов семантической связью. Обсуждаем.
Ответ на этот вопрос зависит от определения понятия «объект» и «класс объектов» в конкретной системе моделирования, а так же от решаемой задачи. Есть методологии, которые запрешают связь объекта с классом объектов, но при этом успешно решают все поставленные прикладные задачи, не испытывая проблем из-за этого ограничения. Так что обсуждать тут нечего.
Мне существенно интереснее вопрос, который я задал вам выше (и на который вы не ответили): для решения какой прикладной задачи вам понадобилась такая связь?
Мне существенно интереснее вопрос, который я задал вам выше (и на который вы не ответили): для решения какой прикладной задачи вам понадобилась такая связь?
для решения какой прикладной задачи вам понадобилась такая связь?
Давайте оставаться в рамках темы. Тема: возможность такой связи. Я бы предпочел обсуждать эту тему.
Абстрактная [не]возможность этой связи показана мной в комментарии, на который вы отвечаете. Поэтому, повторюсь, обсуждать там нечего.
Чтобы обсуждать практическую возможность этой связи в конкретном методе моделирования, необходимо:
Чтобы обсуждать практическую возможность этой связи в конкретном методе моделирования, необходимо:
- строго определить понятия «объект» и «класс объектов»
- строго определить понятие «семантическая связь»
строго определить понятия «объект» и «класс объектов»
Когда я задал этот вопрос математикам, они ответили, что термин класс определяется аксиоматически. А термин объект определен как 4-Д объем пространства-времени.
строго определить понятие «семантическая связь»
Это та связь, которая в воображении субъекта связывает (что связывает, описываю я в своих статьях) смыслом. В классике под объектами связи рассматриваются слова, знаки, и прочие информационные объекты. В моем случае я смотрю на то. что обозначают эти термины и смотрю, как мы связываем то, что обозначено терминами.
Если идти от теории множеств, то там любой объект является множеством. Множество объектов — такой же объект, как и любой другой. Если класс, о котором вы рассуждаете, является отражением понятия «множество», то он является объектом, равноправным с остальными.
Именно это я пытаюсь донести до слушателей. Пока читатели разделились на тех, кому трудно обсуждать эту тему по причине недостаточной концентрации, тех. кто пока не смог допустить этот тезис как допустимый и того, кто задал вполне резонный вопрос о реальности групп. Болдачев, огромное ему спасибо, натолкнул меня на великолепный пример. который я рассмотрю в следующей статье, где докажу со всей очевидностью, что мы, человеки, рассматриваем объекты и классы объектов как «равнонастоящие» в отличие от типа объектов. И это довольно трудно для понимания.
Честно говоря, я не могу увидеть особого смысла в этом вопросе. В случае колёс автомобиля, первый вопрос, который у меня возникает (если возникает вообще) — идентификация этого объекта (класса): чем он определяется, как отличается от других, в какой период он существует, возможно ли его «расщепление» (когда в двух разных контекстах он станет различным). Следующим этапом (уже во время программирования) будет его представление, момент и способ создания, контроль за изменением, интерфейсы… И эти детали могут меняться: при очередном рефакторинге вполне можно переключиться с явного хранения множества, «стоящего на автомобиле» на представление в виде «гораздо более широкий класс+предикат». На адекватность модели это нисколько не повлияет, это всего лишь детали реализации.
С точки зрения моделирования — все просто. Допустив существование классов объектов, можно построить много интересных конструкций. Но меня интересуют те из них, которые всегда существовали, но не были распознаны нами как классы. Статья разгонная. Основной материал будет посвящен именно таким объектам.
Я вижу два варианта. Либо разрывается связь «автомобиль — колесо», и теперь «автомобиль стоит на колесе» раскрывается в «колесо принадлежит множеству колёс автомобиля», либо класс определяется, как «колёса, стоящие на этом автомобиле», и автомобиль является его атрибутом (не знаю, как это вкладывается в конкретную модель). Тогда автомобиль этого класса не содержит (хотя имеет право знать о нём), и работать с этим классом, как с коллекцией мы тоже не можем — можем только проверить, принадлежит ли колесо этому классу (и для этой проверки нам нужен автомобиль).
Я очень благодарен Вам за Ваше терпение. Однако, мы можем поступить двумя способами: поговорить лично голосом, чтобы я понял Ваш тезис лучше и мог бы корректно на него ответить. Или мы можем подождать следующей статьи. В ней я дам первый очень важный намек, и ттогда станет очевидно, к чему я так старательно веду.
Посмотрим, что за намёк…
Вопрос такой: можете ли вы вообще определить класс, как пересечение двух классов? Например, класса деталей автомобиля и класса всех колёс?
Если да — то приведёт ли добавление к классу деталей автомобиля ещё одного колеса к автоматическому изменению класса колёс автомобиля?
Если тоже да — то не противоречит ли это тому, что класс определяется исключительно перечислением своих элементов?
Если да — то приведёт ли добавление к классу деталей автомобиля ещё одного колеса к автоматическому изменению класса колёс автомобиля?
Если тоже да — то не противоречит ли это тому, что класс определяется исключительно перечислением своих элементов?
пересечение двух классов: деталей автомобиля и класса всех колес — дает нам класс из 4-х колес.
Это зависит от метода учета.
Класс, или группа также могут быть разложены на темпоральные части. как и объект. В какой-то момент времени есть 4 колеса в классе, в какой-то — 5. Я не вижу в этом сложности. а Вы?
приведёт ли добавление к классу деталей автомобиля ещё одного колеса к автоматическому изменению класса колёс автомобиля?
Это зависит от метода учета.
не противоречит ли это тому, что класс определяется исключительно перечислением своих элементов?
Класс, или группа также могут быть разложены на темпоральные части. как и объект. В какой-то момент времени есть 4 колеса в классе, в какой-то — 5. Я не вижу в этом сложности. а Вы?
В какой-то момент времени есть 4 колеса в классе, в какой-то — 5.
Вопрос о согласованности. Если на диаграмме (в модели) можно указать, что класс колёс автомобиля — это всегда пересечение двух классов, и, следовательно, события изменения класса деталей автомобиля и класса его колёс происходят синхронно — это одно дело. Модель получает математическую окраску, и если на диаграмму добавить достаточное количество логических и теоретико-множественных связок (включая кванторы — «любой элемент класса» и «некоторый элемент класса»), то можно будет описать всё, что нужно (в случае колёс автомобиля — просто показать класс деталей (он задаётся явным перечислением), класс его колёс (строится как пересечение), и то, что пересечение классов имеет мощность 4).
Если же такой способ описания класса недопустим… то утверждение о 4 колёсах тоже можно нарисовать. Закодировав пересечение с помощью кванторов и связки «A лежит в B». Тогда класс колёс автомобиля возникнет как временная безымянная сущность. И это будет громоздко и непонятно.
Есть более сложная задача — смоделировать утверждение, что все 4 колеса должны быть одной марки. Предполагается что класс классов колёс, сгруппированных по маркам, у нас есть.
Сорри, но мне трудно понять вопрос. Все, что я читаю, верно. Можно указывать как пересечение, можно перечислять объекты. Правда надо делать оговорку, что данное перечисление соответствует такому-то времени.
Это делается очень просто: указав класс, к которому относятся данные колеса: класс «Бриджстаунмля»
Есть более сложная задача — смоделировать утверждение, что все 4 колеса должны быть одной марки
Это делается очень просто: указав класс, к которому относятся данные колеса: класс «Бриджстаунмля»
Это делается очень просто: указав класс, к которому относятся данные колеса: класс «Бриджстаунмля»
Это же совсем другое утверждение! Оно запретит существование автомобиля, все колёса которого относятся к классу «Лонгюра». Или какому-нибудь пока неизвестному классу.
Понял!!! Вы создаете мир на основе модели, а я модель на основе мира! Разве нет?
В какой-то мере. Если в модели написано «любая ворона — чёрная», значит, в мире не может быть белых ворон. Иначе либо модель, либо мир неправильны.
колеса одних автомобилей могут относиться к одной марке (марка колес связана с соответствующим классом), а могут — к другой марке. Если мы говорим, что все автомобили оснащены колесами одной марки, то мы утверждаем, что автомобили с другими колесами — это автомобили уже не этого класса, но они (автомобили) не «запрещены» в принципе.
То есть, когда автомобилю меняют зимнюю резину на летнюю, он может поменять класс. Бедный пользователь, ему теперь два раза в год придётся перерегистрировать машину. А ведь как просто было бы написать:
∃ WT ∈ WheelTypes: ∀ W ∈ (CarDetails ∩ Wheels): W ∈ WT
и не привязываться к конкретной марке резины.
∃ WT ∈ WheelTypes: ∀ W ∈ (CarDetails ∩ Wheels): W ∈ WT
и не привязываться к конкретной марке резины.
Мы упираемся в метод учета. Как скажет учетчик, так мы и поступим. Скажет, что автомобиль меняет класс со сменой колес, учтем это так. Скажет, что не меняет, учтем это так. Например, автомобиль требует перерегистрации при смене двигателя. Это требование метода учета. С тем же успехом можно ввести закон о перерегистрации при смене колес.
Но сможете ли вы сделать то, что сказал учётчик? Поддержит ли модель утверждение, что все колёса должны быть одного класса, но этот класс может быть любым, и класс автомобиля не зависит от класса резины?
Можно указывать как пересечение, можно перечислять объекты. Правда надо делать оговорку, что данное перечисление соответствует такому-то времени.
Ну да. Одно дело, когда вы напишете
∀ T: CarWheels(T) = CarDetails(T) ∩ Wheels;
Другое — когда
CarDetails(TAttach) = CarDetails(TAttach-1) U CarWheels
и третье — когда
∀ T: CarDetails(T) = CarWheels(T) U CarGlasses(T) U CarMetalStuff(T) U ...
(в этом случае класс колёс будет базовым по отношению к деталям автомобиля, и автомобиль будет стоять на классе колёс, а не на отдельных колёсах)
Получаются слегка разные модели. И разные связи между автомобилем и классом колёс.
Геометрия оперирует теми величинами, которые ей дадут в качестве координат. Задачи линейной аппроксимации, кластеризации, многофакторного анализа и т.п. формулируются и решаются в геометрических терминах, хотя моделируемые величины ничего общего с физическим пространством могут и не иметь.
Время вполне может быть одной из координат в геометрической постановке задачи. Или более, чем одной. Конечно, то, как представляется физическое время в конкретной модели, зависит от способа построения модели, но чтобы потом с этим представлением времени работать — математика точно пригодится.
Время вполне может быть одной из координат в геометрической постановке задачи. Или более, чем одной. Конечно, то, как представляется физическое время в конкретной модели, зависит от способа построения модели, но чтобы потом с этим представлением времени работать — математика точно пригодится.
Вы говорите о сведении задачи к математической. Это не означает, что сама задача выражена в математических терминах.
время может быть временем, как в анализе временных рядов
Тогда надо было написать «философия — это язык математики» ))
А вообще философский смысл можно отыскать везде. А вот в обратную сторону не получится: философия невыразима на нефилософском языке. И на математическом.
А вообще философский смысл можно отыскать везде. А вот в обратную сторону не получится: философия невыразима на нефилософском языке. И на математическом.
Ну да, трудно поспорить). Философского языка нет. Как только он появится, философские концепты автоматом будут формализованы. Философия тем и хороша, что она не замыкается на формальной логике и формальных выводах. Просто потому что наше восприятие и наше мышление — не есть способы вывода.
Как это философского языка нет? Не на птичьем же языке написаны все философские тексты? ))) Еще скажите, что нет языка музыки, поэзии, живописи… И как язык искусства, так и язык философии никогда не будет формализован. Хотя локально философские системы вполне рациональны.
Про язык философии я бы с радостью послушал. Я понятия не имею, на что его положить и как его позиционировать. У меня нет ни сил ни возможности понять это. Поэтому я буду плескаться на поверхности мелководья, где игры разума породили устойчивые структуры, которыми можно забавляться, — формальный язык.
Записать модель без искажений… а где вы определили уровень детализации?
Без искажений вообще — это показать сам автомобиль. А так всегда будут искажения зависящие от целей моделирования.
Задача «просто сделать модель» — кому это нужно? Заказчику не нужно, другим тоже. Если только Вам, тогда это не несет полезности для общественности.
Вобщем мой меседж в том что должна быть цель моделирования, как описано во всех методологиях моделирования, той же АРИС.
Без искажений вообще — это показать сам автомобиль. А так всегда будут искажения зависящие от целей моделирования.
Задача «просто сделать модель» — кому это нужно? Заказчику не нужно, другим тоже. Если только Вам, тогда это не несет полезности для общественности.
Вобщем мой меседж в том что должна быть цель моделирования, как описано во всех методологиях моделирования, той же АРИС.
Записать модель без искажений… а где вы определили уровень детализации?
Вы путаете модель и ее представление. Я не говорю о моделировании. Я говорю о записи моделей, или об их представлении. Степень детализации определяет моделировщик, он же решает вопросы о непротиворечивости модели. Я же говорю только о записи представления этой модели, модели. созданной в другом процессе. Вы же смешиваете два процесса: создание модели и ее записи.
Чтобы «записать» модель, нужно, чтобы она была «построена» в тех же терминах, в которых вы будете ее «записывать».
Хороший вопрос. Вы знаете исследования на эту тему? То, что мне ответил психолог, звучит так: запись модели будет отличаться для разных целевых групп. Если я имею модель шамбалы, но обращаюсь к аборигенам, не имеющим органов восприятия шамбалы, то моя модель будет строиться на языке аборигенов по принципу аналогий. «Знаете, что такое апельсин? так вот самолет — это штука, совершенно не похожая на апельсин!» Иногда, чтобы передать модель приходится рассказывать метод приобретения аппарата восприятия, на основе которого потом можно будет передать и модель. Поэтому Ваш тезис верен только в том случае, если тот, кто передает модель и тот, кто ее принимает, используют один и тот же понятийный аппарат и один и тот же аппарат восприятия. В противном случае — модель и представление модели будут отличаться как понятиями, так и конструкциями.
Я об этом и говорю: если представление модели отличается от модели, то оно является другой моделью. Что возвращает нас к тезису, что задача аналитика — создание модели, а не ее запись.
Поддерживаю полностью lair.
Все просто — есть обьект реальный — автомобиль и есть миллион разных его моделей в зависимости от целей и задач для чего нужны эти модели, а какую модель сделать — собственно это и есть главная задача аналитика.
Все просто — есть обьект реальный — автомобиль и есть миллион разных его моделей в зависимости от целей и задач для чего нужны эти модели, а какую модель сделать — собственно это и есть главная задача аналитика.
Давайте не переходить на личности. Я исхожу из того что все тут грамтные думающие люди и мы ведем полезную дисскуссию.
Насчет «представления модели». Можете дать определение и ссылку на определение данного понятия? В терминах моделирования предметных областей используют понятия «представление знаний», «модель».
Как-то не стыковуется пока что — получается что представление модели это модель модели. Зачем это? Если вы говорите о визуальном представлении модели — так это и емть модель ))) Ивопрос то вобщем-то не в этом. Вопос в том что если что-то моделируется то это для чего-то нужно, для передачи знаний, для автоматизации, для исследования зависимостей или будь-чего.
Насчет «представления модели». Можете дать определение и ссылку на определение данного понятия? В терминах моделирования предметных областей используют понятия «представление знаний», «модель».
Как-то не стыковуется пока что — получается что представление модели это модель модели. Зачем это? Если вы говорите о визуальном представлении модели — так это и емть модель ))) Ивопрос то вобщем-то не в этом. Вопос в том что если что-то моделируется то это для чего-то нужно, для передачи знаний, для автоматизации, для исследования зависимостей или будь-чего.
Насчет «представления модели». Можете дать определение и ссылку на определение данного понятия?
В ИСО 15926 введен такой термин и вот пример его применения:
Но это не все, я спрашивал много людей по поводу различения модели в башке и ее представления на бумаге, в кирпиче, или глине и все согласны с тем, что модель в башке и ее представление в натуре — разные вещи. Так что мне это просто очевидно.Вам нужно промоделировать классы? или все же данные для хранения информации?
Мне нужно моделировать предметную область. Предметной областью может быть что угодно: настроение, галлюцинации, заводы… Концептуальная модель как раз для этого предназначена. Она не моделирует данные, она моделирует предметную область.
Что-то странное.
На третьей диаграмме не отображено то, что написано текстом: «для каждого автомобиля найдется 4 связи с колесами в классе семантических связей под названием «Автомобиль имеет колесо», для каждого колеса существует только одна такая связь в этом классе. „
А причина этого проста. И на диаграмме, и в текстовом формализме логических моделей это записывается именно как “семантическая связь между классом ТМ автомобилей и классом ТМ колес». Точно с теми же кардинальностями, как на UML и прочих диаграммах.
А фразы "В такой постановке задачи – нет. Есть класс связей между автомобилями и колесами, но нет связи между классом ТМ автомобилей и классом ТМ колес. " — не соответствуют действительности. Ибо это единственный способ разумно записать то самое правило «для каждого автомобиля найдется 4 связи с колесами».
На третьей диаграмме не отображено то, что написано текстом: «для каждого автомобиля найдется 4 связи с колесами в классе семантических связей под названием «Автомобиль имеет колесо», для каждого колеса существует только одна такая связь в этом классе. „
А причина этого проста. И на диаграмме, и в текстовом формализме логических моделей это записывается именно как “семантическая связь между классом ТМ автомобилей и классом ТМ колес». Точно с теми же кардинальностями, как на UML и прочих диаграммах.
А фразы "В такой постановке задачи – нет. Есть класс связей между автомобилями и колесами, но нет связи между классом ТМ автомобилей и классом ТМ колес. " — не соответствуют действительности. Ибо это единственный способ разумно записать то самое правило «для каждого автомобиля найдется 4 связи с колесами».
семантическая связь между классом ТМ автомобилей и классом ТМ колес
Я могу придумать связь между классом автомобилей и классом колес. Это может быть так: для производства группы автомобилей из 600 штук необходима группа колес из 2400 штук. Но то, что я обозначил в тексте не связывает класс автомобилей и класс колес.
Хотя, я понял, что «для каждого автомобиля найдется 4 связи с колесами в классе семантических связей под названием «Автомобиль имеет колесо» есть тоже описание класса автомобилей и класса колес. Однако, эта связь между классами должна быть выделена отдельно от класса связей между автомобилями и колесами. Получается, что есть класс связей между колесами и автомобилями, а также есть связь между классом автомобилей и классом колес. Но класс связей и связь не есть одно и то же. Поэтому надо точно понимать, что имеется ввиду в ER модели? класс связей. или связь между классами? ИМХО, имеется ввиду все-таки связь между объектами класса.
Связь между классами — это и есть класс связей между их членами, поэтому ничего отдельного в ней нет. Надо всего лишь записать ряд свойств для класса связей «Автомобили-колёса», который прекрасно нарисован на третей диаграмме.
Эти свойства в том, что одна роль ограничена «Класс ТМ автомобилей», вторая — «Класс ТМ колёс». Именно в этом смысле (и ни в каком ином) класс отношений является отношением между классами концов этих отношений.
Ну и через обычное утверждение о кардинальностях записываем что есть по 4 члена на каждый автомобиль и по одному на каждое колесо.
Эти свойства в том, что одна роль ограничена «Класс ТМ автомобилей», вторая — «Класс ТМ колёс». Именно в этом смысле (и ни в каком ином) класс отношений является отношением между классами концов этих отношений.
Ну и через обычное утверждение о кардинальностях записываем что есть по 4 члена на каждый автомобиль и по одному на каждое колесо.
Связь между классами — это и есть класс связей между их членами
Не согласен. И далее становится ясно, что это принципиальный момент. Кстати, Крис Партридж согласен со мной:
(только сейчас заметил)
Не вы ли писали «В ER-модели [...] построить конструкции, которые меня бы удовлетворили, я не могу»?
Сегодня я расскажу, почему я предпочитаю строить концептуальные модели в виде ER диаграмм.
Не вы ли писали «В ER-модели [...] построить конструкции, которые меня бы удовлетворили, я не могу»?
да, ER модели меня не устраивают. По Гамбургскому счету.
Тогда почему же вы предпочитаете их, а не модели из той же логической парадигмы?
Для моих моделей нет нотации и нет языка. В своей статье я однажды сказал, что моя цель — построение такого языка и такой нотации. Поэтому приходится моделировать в том, что есть.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Особенности концептуального моделирования предметной области