Comments 147
В какой компании вы работаете? Просто интересно на будущее, куда заявку точно не стоит подавать.
Ну серьёзно, нафига программисту нужен системный анализ? На мех-мате это один из самых укуренных и бесполезных после философии предметов.
Ну серьёзно, нафига программисту нужен системный анализ? На мех-мате это один из самых укуренных и бесполезных после философии предметов.
«нафига программисту нужен системный анализ?»
Сильно! Программист — один из первых, кому нужен системный анализ.
Другое дело, что побочным эффектом внедрения agile-технологий явилось то, что под программистом теперь понимается не разработчик, а кодер (с соответствующим результатом на выходе).
Похоже, что тс укурился колесами. :)
Правда, некоторые связи будут весьма странными с точки зрения логики обывателя. Но это не исключает их невозможности.
Это не системный анализ.
Это умствования одного человека.
ПРИКЛАДНОЙ системный анализ вообще предельно прагматичен.
Это умствования одного человека.
ПРИКЛАДНОЙ системный анализ вообще предельно прагматичен.
Не могли б вы поделится ссылками на прикладной системный анализ?
А то нам в институте сплошную муть читают…
А то нам в институте сплошную муть читают…
Прикладной системный анализ в ИТ-проектах сводится по сути к инженерии требований (Requirements Engineering).
Вот тут у нас подборка статей и книг, начиная с бесплатных: school.system-analysis.ru/books/
Вот тут у нас подборка статей и книг, начиная с бесплатных: school.system-analysis.ru/books/
Вопрос: слушая хозяина машины, что мы себе представляем: то, что машина состоит из колес одного класса? Или то, что машина состоит из класса колес?
Ни то, и ни другое, очевидно.
Под классом колес мы понимаем множество объектов. Не то, что понимается под этим термином в ООП (описание типа, модель объектов, описание общих признаков), нет. Мы понимаем просто набор каких-то объектов.
Кто эти «мы», которые так понимают?
Если мы задаем этот вопрос программистам, то они входят в ступор
И не только программисты. Без контекста этот вопрос бессмысленнен.
В таком случае мы обычно говорим — машина состоит из пяти колес.
И снова: кто эти «мы»? Я не знаю ни одного человека (кроме, возможно, вас), кто так бы говорил.
Умение из рассказа заказчика извлекать нужные сущности и моделировать их корректным образом и есть искусство аналитика.
Искусство аналитика в первую очередь состоит в том, что корректно определить решаемую задачу.
колеса — это множество, класс — колесо, но при этом одно колесо — это объект. А трава да, видать неплохая…
«состоит из», а не «включает в себя»
Зачем спорить о терминах на собеседовании? Факт останется фактом. Когда дело дойдёт до кода, всех менеджеров и прочих будет интесовать лишь один вопрос «как быстро это сделаешь?», а не разговоры о сфероконях.
Умение из рассказа заказчика извлекать нужные сущности и моделировать их корректным образом и есть искусство аналитика
80/20 в деле. Чаще всего заказчик сам не знает чего ему надобно. И если так дотошно его расспрашивать то скорей всего он просто пойдет в другое место, где ему скажут 3 вещи: да, сделаем, N сумма денег.
Когда дело дойдёт до кода, всех менеджеров и прочих будет интесовать лишь один вопрос «как быстро это сделаешь?», а не разговоры о сфероконях.
Факт!
Но как и факт то, чем это обычно заканчивается. Если интересно, описал это тут (в разделе 1 про ИТ-компании).
Не находите, если бы не титаны вроде профессора Вирта, Бьерна Страуструпа, Эдсгера Дейкстры да и многих-многих других, занимавшихся вроде как «сфероконями» с т.ч. зрения исполнителей-кодеров, то в конечном итоге и тех же C#, Java сегодня не было бы?
А без Бойса, Кодда, Дейта что было бы с реляционными БД?
Т.е., что было бы со всем этим инструментарием, который и позволяет «быстро сделать»?
Не могу не согласиться. Но данный пост в данном контексте описывает в таком случае создание велосипеда и не более. Вот сейчас как раз недавно начался у меня один проект. Была спроектирована бд. С флексфилдами и прочим. Потом пришли люди со сфероконями и сказали что ожидали увидеть таблиц 300 а не 7 таблиц которые позволяют описать любой объект динамически. Т. Е. На грамотно составленную дбишником схему просто люди без технических знаний сказали «г*вно». А в итоге головная боль у людей которым это делать.
О, интересно. У меня тоже был проект, где с помощью нескольких таблиц была реализована возможность описать любой объект.
И суть как раз в том, что объект нужно описывать динамически, т.к. на момент проектирования БД все возможные типы объектов неизвестны, и требуется система их параметрического описания при внедрении/эксплуатации системы.
Альтернатива — рождать «300» таблиц, да еще в каждой добавлять по NNN полей различных типов на все случаи жизни, и потом все равно пришлось бы добавлять еще.
И суть как раз в том, что объект нужно описывать динамически, т.к. на момент проектирования БД все возможные типы объектов неизвестны, и требуется система их параметрического описания при внедрении/эксплуатации системы.
Альтернатива — рождать «300» таблиц, да еще в каждой добавлять по NNN полей различных типов на все случаи жизни, и потом все равно пришлось бы добавлять еще.
Конкретная машина не состоит не из каких колес. Конкретная машина включает в себя 4 или 5 конкретных колес. Это то, что подсказывает нам здравый смысл. Если ваш формализм вступает против здравого смысла — значит ваш формализм неверен.
Что-то тут перекручено.
Класс — это объект (экземпляр) класса «класс».
Класс (объект класса «класс») «машина» состоит из четырёх копий класса «колесо» (которые тоже объекты класса «класс»). Когда мы создаём объект «машина А» класса «машина» — мы создаём заодно и все объекты всех подобъектов.
Вот и вся магия.
Класс — это объект (экземпляр) класса «класс».
Класс (объект класса «класс») «машина» состоит из четырёх копий класса «колесо» (которые тоже объекты класса «класс»). Когда мы создаём объект «машина А» класса «машина» — мы создаём заодно и все объекты всех подобъектов.
Вот и вся магия.
Это уже ООП головного мозга. Собеседование — это вообще такой процесс, который вгоняет почти любого в состояние дискомфорта, так вы еще своими извращёнными вопросами собрались добивать своих претендентов на работу и посильнее разрывать им мозги?) Не думаю я, что вы таким образом сможете набрать в свою команду действительно талантливых людей, способных писать хороший код.
Лучше просто дайте небольшое тестовое задание человеку и посмотрите на его работу. Это и сделать проще, и результат будет куда более показателен и информативен.
Лучше просто дайте небольшое тестовое задание человеку и посмотрите на его работу. Это и сделать проще, и результат будет куда более показателен и информативен.
Насколько я понял, он сам устраивался на работу, а вопросы к интервьюерам со стороны работодателя в диалогах про ООП.
Насколько понимаю, в статье речь не про ООП, а про анализ предметной области в терминах теории множеств (но который не следует выполнять в терминах ООП).
Когда результат анализа требуется запрограммировать в коде, начинаются проблемы, связанные с путаницей в терминологии:
«класс» в ООП это не более, чем ключевое слово для обозначения объектно-ориентированного типа данных.
Если бы мы писали что-то вроде «public [object-oriented]datatype MyType» вместо «public class MyClass», то и лишних вопросов не возникало бы.
Заодно было бы понимание, что статические поля можно использовать только дополнительного описания типа данных (а, значит, использовать их только как readonly и immutable), а не для того, чтобы помещать туда данные (как правило, динамического характера), общие для всех экземпляров этого типа данных.
Когда результат анализа требуется запрограммировать в коде, начинаются проблемы, связанные с путаницей в терминологии:
«класс» в ООП это не более, чем ключевое слово для обозначения объектно-ориентированного типа данных.
Если бы мы писали что-то вроде «public [object-oriented]datatype MyType» вместо «public class MyClass», то и лишних вопросов не возникало бы.
Заодно было бы понимание, что статические поля можно использовать только дополнительного описания типа данных (а, значит, использовать их только как readonly и immutable), а не для того, чтобы помещать туда данные (как правило, динамического характера), общие для всех экземпляров этого типа данных.
Под классом колес мы понимаем множество объектов. Не то, что понимается под этим термином в ООП (описание типа, модель объектов, описание общих признаков), нет. Мы понимаем просто набор каких-то объектов.
В теории множеств классом называют обобщение над множествами, а являются-ли все классы множествами это еще тот вопрос. Утвердительный ответ приводит к парадоксам, поэтому в некоторых формальных системах они не эквивалентны. Без конкретизации теории, последующие логические выкладки выглядят умопомрачительно, прямо как «Алиса в стране чудес».
Если мне удалось уловить смысл статьи, то для программирования можно было рассмотреть более привычную ситуацию — проектирование реляционной базы данных — на примере таблиц автомобилей (Auto), колес (Wheels) и их атрибутов.
«машина состоит из множества колес»
Auto: (wheel1_id, wheel2_id, wheel3_id, wheel4_id, wheel5_id)
Wheels: (id, ...)
«машина состоит из колес одного множества»
Auto: (id)
Wheels: (auto_id, ...)
Не уверен в правильности трактовки, ибо СПГС.
Во втором случае получается, что множество колес «входят в машину»/«относятся к машине»/«принадлежат машине», а нам нужно «машина состоит из колес одного множества»?
Тогда лучше записать это так:
Auto: (id, wheel_set_id, ...)
WheelSet: (id, wheel1_id, wheel2_id, ...)
Wheels: (id, ...)
Множество колес не должно «знать», к какой машине оно относится, так же, как и конкретное колесо, не знает, к какому множеству оно относится.
А вот сущности более верхнего уровня «знают», из каких сущностей более нижних уровней они состоят.
Тогда лучше записать это так:
Auto: (id, wheel_set_id, ...)
WheelSet: (id, wheel1_id, wheel2_id, ...)
Wheels: (id, ...)
Множество колес не должно «знать», к какой машине оно относится, так же, как и конкретное колесо, не знает, к какому множеству оно относится.
А вот сущности более верхнего уровня «знают», из каких сущностей более нижних уровней они состоят.
Если колесо не знает о машине, то кому оно передаст сообщение, что оно лопнуло/отвинтилось/наехало на камень? И откуда оно тогда будет знать, что оно — именно колесо, а не какая-нибудь покрышка на баррикадах?
При необходимости «колесо» или любая нижестоящая сущность может, конечно, иметь ссылку на «владельца».
Однако, не получается ли тут пресловутая «сильная связанность»?
Возможно, колесу лучше передавать ссылку на некий интерфейс, или делегат, или подписать его на событие (в обработчик события будет находиться у владельца, т.к. владелец лучше колеса знает, что делать если въехал не туда).
Однако, не получается ли тут пресловутая «сильная связанность»?
Возможно, колесу лучше передавать ссылку на некий интерфейс, или делегат, или подписать его на событие (в обработчик события будет находиться у владельца, т.к. владелец лучше колеса знает, что делать если въехал не туда).
Если колесо не знает о машине, то кому оно передаст сообщение, что оно лопнуло/отвинтилось/наехало на камень?
Подписчику. Это если у вас событийная модель, а не опрос состояния.
И откуда оно тогда будет знать, что оно — именно колесо, а не какая-нибудь покрышка на баррикадах?
А зачем ему это знать?
ООП тут вообще не при чем. Автор очень любит его упомянуть, но при этом всегда вне границ применения.
Машина состоит из (имеет в качестве составных частей) 5 экземпляров класса «колесо». То, что эти колёса лежат в конкретных полях объекта «машина» (переднее правое и т.п.) — хорошо, но не очень важно: табуретка состоит из множества объектов класса «молекула», не имеющих конкретного индекса. А вот то, что колесо можно открутить от машины, и поставить на его место другое (при этом почти все свойства каждого из этих колёс сохранятся), говорит о том, что принадлежность колеса данной машине — уже вторичный признак.
Но эта принадлежность позволяет определить подкласс класса колёс — «колёса, принадлежащие этой машине». Нельзя с уверенностью сказать, что машина состоит из этого класса — она его определяет: первично то, что колесо включили в машину — и только после этого колесо попало в соответствующий подкласс.
С другой стороны, машина определяет и более широкий подкласс — те колёса, которые ей подходят. Но из этого класса она не состоит. И даже класс машин, совместимых с ней по колёсам, не состоит из этого подкласса колёс, ведь колёса могут быть и не принадлежащими никакой машине…
Хотя… если мы разберём машину, и разложим её составные части по классам, то увидим класс болтов, класс гаек, класс непонятной металлической фигни… и класс колёс — тех самых, что принадлежали этой машине. Так что можно сказать, что она в самом деле состоит из этого класса, который она когда-то определяла.
Но эта принадлежность позволяет определить подкласс класса колёс — «колёса, принадлежащие этой машине». Нельзя с уверенностью сказать, что машина состоит из этого класса — она его определяет: первично то, что колесо включили в машину — и только после этого колесо попало в соответствующий подкласс.
С другой стороны, машина определяет и более широкий подкласс — те колёса, которые ей подходят. Но из этого класса она не состоит. И даже класс машин, совместимых с ней по колёсам, не состоит из этого подкласса колёс, ведь колёса могут быть и не принадлежащими никакой машине…
Хотя… если мы разберём машину, и разложим её составные части по классам, то увидим класс болтов, класс гаек, класс непонятной металлической фигни… и класс колёс — тех самых, что принадлежали этой машине. Так что можно сказать, что она в самом деле состоит из этого класса, который она когда-то определяла.
В предметной области нет экземпляров. Есть колеса. Машина состоит не из колес, Вы верно это заметили. она состоит из темпоральных частей колес. То есть временных частей колес. временная часть — это часть колеса с и по какой-то момент.
Машина — не более, чем результат взаимосвязи своих компонент, т.е. множество объектов (возможно, имеющее какую-то структуру), для которого выполняются определённые предикаты — есть пять колёс, четыре из них закреплены на осях, а пятое прикручено сзади. Оси крепятся к шасси, и некоторые из них связаны с двигателем. Каждое из колёс, в свою очередь — такой же конгломерат объектов, свойства которого позволяют называть его колесом. Когда шина лопнет, некоторые из предикатов перестанут выполняться, и машина временно потеряет свойства машины. Потом, возможно, их восстановит. Так что экземпляры есть, но их принадлежность к тому или иному классу определяется свойствами и структурой этих экземпляров. А сами классы лежат в платоновском мире идей, и «конкретно эта машина в данный момент» из них состоять никак не может.
В предметной области нет экземпляров.
Заодно там нет и классов, и темпоральных областей. Все это — терминология, которую аналитик привносит в предметную область.
Вопрос — для чего такие извращения на собеседовании? Определяете потенциальных собутыльников?
Весьма и весьма показательная фраза. Ощущение, что собеседования проводятся вами для развлечения себя любимого.
Соглашусь с первой строкой первого комментария в треде.
Шоу обеспечено.
Весьма и весьма показательная фраза. Ощущение, что собеседования проводятся вами для развлечения себя любимого.
Соглашусь с первой строкой первого комментария в треде.
Для потенциальных собутыльников лучше сразу спрашивать, в чём преимущества и недостатки копенгагенской модели по сравнению с моделью ветвящихся вселенных. Или что-нибудь ещё настолько же философское… А если известно, что проект такой, что в нём каждому приходится быть архитектором, то предложение поиграть с изменённой моделью класса вполне может пригодиться. Например, для более точного определения круга задач — куда соискателя можно пускать, а куда нельзя. А если он вдруг скажет, как в действительности называется эта модель, то вообще хорошо.
М-да, обожаю такого типа вопросы на собеседованиях, ответить корректно практически невозможно (ибо там неозвученный контекст автора) и самое печальное, что часто потом даже правильного ответа не говорят. Чувствуешь себя полным идиотои и желание работать в такой компании пропадает.
Полагаю, придуманный вопрос больше предназначен для аналитиков предметных областей, чем для программистов.
В случае аналитика, было бы интересно, как он начнет рассуждать:
И здесь будет очень важна адекватность стороны, задающей вопрос, чтобы оценить именно ход мысли при ответе,
а не готовый ответ, которого может и не быть, при том, в общем случае отвечающему может быть и неизвестно «а как надо ответить»,
какой неозвученный бэкграунд имеется у задающего вопрос.
Действительно, довольно печально, когда задается вопрос или даже дается тестовое задание, и при этом это выглядит, как «черный ящик», т.е. не понятно, а что действительно хотели спросить, каков на самом деле некий «внутренний вопрос», и что для задающей вопрос стороне на самом деле важно в обсуждаемом вопросе/задаче (включая, в каком объеме/масштабе и с какой степенью детализации требуется ответ/решение).
Что касается обсуждаемой статьи, то вопрос то нормальный для аналитиков, да и для программистов, желающих заниматься и анализом предметной области.
А путаница, возникает, повторюсь (писал выше), из-за не самой корректной терминологии, используемой в ООП.
Возможно, в статье нужно было сразу оговорится, что речь пойдет в терминах теории множеств, а не ООП.
В случае аналитика, было бы интересно, как он начнет рассуждать:
И здесь будет очень важна адекватность стороны, задающей вопрос, чтобы оценить именно ход мысли при ответе,
а не готовый ответ, которого может и не быть, при том, в общем случае отвечающему может быть и неизвестно «а как надо ответить»,
какой неозвученный бэкграунд имеется у задающего вопрос.
Действительно, довольно печально, когда задается вопрос или даже дается тестовое задание, и при этом это выглядит, как «черный ящик», т.е. не понятно, а что действительно хотели спросить, каков на самом деле некий «внутренний вопрос», и что для задающей вопрос стороне на самом деле важно в обсуждаемом вопросе/задаче (включая, в каком объеме/масштабе и с какой степенью детализации требуется ответ/решение).
Что касается обсуждаемой статьи, то вопрос то нормальный для аналитиков, да и для программистов, желающих заниматься и анализом предметной области.
А путаница, возникает, повторюсь (писал выше), из-за не самой корректной терминологии, используемой в ООП.
Возможно, в статье нужно было сразу оговорится, что речь пойдет в терминах теории множеств, а не ООП.
Что касается обсуждаемой статьи, то вопрос то нормальный для аналитиков, да и для программистов, желающих заниматься и анализом предметной области.
А вот что этот вопрос должен показать? Знаком ли человек с теорией множеств применительно к анализу предметной области?
Мы вот, когда нам интересно, как человек делает анализ, просто даем несложную предметную область и предлагаем построить модель, а лучше — несколько.
А вот что этот вопрос должен показать? Знаком ли человек с теорией множеств применительно к анализу предметной области?Наверное, это больше к автору. Но мне кажется так:
если человек не знаком с теорией множеств (хотя как так может быть? аналитик должен быть математиком, а там ее изучают, у программистов теорию множеств так или иначе «проходят» в рамках курсов технологии программирования/теории графов/дискретной математики/информатики),
то хотя бы пусть спросит, а какие-такие классы имеются в виду?
если и этого не будет, то пусть попробует в терминах ООП смоделировать, и посмотрим, что получится.
Мы вот, когда нам интересно, как человек делает анализ, просто даем несложную предметную область и предлагаем построить модель, а лучше — несколько.
А что именно вы хотите в таких случаях? Модель сущностей в UML, модель процессов в IDEF0, BMPN,
или реляционную модель + модель в классах ООП?
аналитик должен быть математиком
Это почему?
а какие-такие классы имеются в виду?
… после чего получит в ответ определение из поста и потратит большую часть времени на выражение задачи в терминах того, кто ее ставит. Особенно учитывая, что все это делается на слух — это избыточная сложность.
А что именно вы хотите в таких случаях?
Увидеть, как человек размышляет. В 90+ процентах случаев кандидат не может нарисовать непротиворечиво одну. Обычно дело начинается с физической модели — на ее основании просим нарисовать логическую. Если человек рисует процесс — просим нарисовать переходы состояний. Со сценариями использования тоже по-разному выходит.
Это почему?
Да пусть хоть кем будет, но базовые вещи то нужно знать.
В плане множеств, хотя бы на уровне, что такое множество, и какие операции к ним применимы.
Лучше это спрашивать, чем про какие то конкретные вещи — например, оператор SQL JOIN.
… после чего получит в ответ определение из поста и потратит большую часть времени на выражение задачи в терминах того, кто ее ставит. Особенно учитывая, что все это делается на слух — это избыточная сложность.
Может, так, и может, и нет. Зависит от обеих сторон.
Можно предложить «паттерн», как в терминах ООП реализовать сущность предметной области.
Увидеть, как человек размышляет. В 90+ процентах случаев кандидат не может нарисовать непротиворечиво одну. Обычно дело начинается с физической модели — на ее основании просим нарисовать логическую. Если человек рисует процесс — просим нарисовать переходы состояний. Со сценариями использования тоже по-разному выходит.
Неплохо. А как по времени все это занимает?
У меня был опыт вот так в реальном времени, построить некую модель, рассуждая и имея бумагу и ручку. Получилось нормально. Я использовал реляционный подход.
Да пусть хоть кем будет, но базовые вещи то нужно знать.
Понятие базовых вещей у всех отличается.
В плане множеств, хотя бы на уровне, что такое множество, и какие операции к ним применимы.
… а это совсем не то же самое, что классы множеств.
Можно предложить «паттерн», как в терминах ООП реализовать сущность предметной области.
Разработчику? Извините, но эта задача сама по себе бессмысленна, потому что в терминах ООП, если не оговаривать специфику, сущность предметной области реализуется как объект. Аналитику? Ему не надо мыслить терминами ООП (если П — это программирование).
Неплохо. А как по времени все это занимает?
Конкретно этот этап — минут 10-15, в максимуме — до получаса. Предметная область простая.
Понятие базовых вещей у всех отличается.
Аналитик должен иметь хотя бы представление о множествах.
Иначе как он сможет проанализировать задачу, и поставить ее разработчикам,
например, такую: напишите программу, которая среди всех синих и зеленых машин найдет все машины с мощностью более 100 л.с.?
Разработчику? Извините, но эта задача сама по себе бессмысленна, потому что в терминах ООП, если не оговаривать специфику, сущность предметной области реализуется как объект. Аналитику? Ему не надо мыслить терминами ООП (если П — это программирование).
Не извиню:
Что такое объект? Вы имеет в виду класс в терминах современного ООП, экземпляры которого (объекты) мы можем создавать?
В предыдущей дискуссии, если помните, один из участников предлагал на полном серьезе, с выкладками кода, завести у класса (сущности) Слон поле «Общее количество слонов».
Вы понимаете, что «Слон» и «Слоны» это разные сущности? Что у Слона не может быть поля «общее количество»? (конкретные причины про статик поля я уже подробно излагал, да и не в них только дело).
Другое дело, что если слону нужно непременно знать, к какому множеству он относится, и количество слонов в этом множестве, то Слон в конструкторе может получить ссылку на «владельца» (Слонов), или как-то еще это сделать.
С подходом «одна сущность — один объект» к вам придет такой разработчик и наплодить статик полей у сущностей. И вариант класс «Слон» — статик «Общее кол-во слонов» тут будет еще не самым худшим.
Задумайтесь, мы же если мы назвали сущность «Слон», а не «Слоны», какие тут могут быть «Общие количества»? Слон и Слоны — это разные сущности.
Именно поэтому я и написал вам, что как вариант, если интервьюируемый задумается и поймет, что те сущности, про которых его спрашивают на собеседовании, нужно реализовывать с помощью нескольких ООП-шых сущностей.
Аналитик должен иметь хотя бы представление о множествах.
Иначе как он сможет проанализировать задачу, и поставить ее разработчикам,
например, такую: напишите программу, которая среди всех синих и зеленых машин найдет все машины с мощностью более 100 л.с.?
Вот именно так, как вы ее описали. Это простое и понятное разработчику объяснение. Оно, конечно, неполное (в нем не хватает «откуда» и «куда»), но для данного примера это не критично.
Видите? Вообще слово «множество» не понадобилось, не говоря уже о классах.
Что такое объект? Вы имеет в виду класс в терминах современного ООП, экземпляры которого (объекты) мы можем создавать?
Нет, я имею в виду именно объект: совокупность данных и операций над ними. Я на всякий случай еще раз напомню, что class-based OOP — не единственная реализация ОО-парадигмы.
С подходом «одна сущность — один объект» к вам придет такой разработчик и наплодить статик полей у сущностей.
Нет. У объекта per se нет статических полей — они появляются только в конкретном языке. Вы же говорите «как реализовать в ООП», а не «как реализовать на <впишите ваш язык>»?
И да, то, о чем вы говорите — это как раз «оговаривать специфику». Изначально вы ставили задачу как «как реализовать сущность», а теперь говорите о группе связанных сущностей (причем я бы еще поспорил, является ли каждая из них сущностью в терминах предметной области, или нет).
Видите? Вообще слово «множество» не понадобилось, не говоря уже о классах.
Полагаю, что для того, чтобы верно, корректно проанализировать проблему и корректно поставить задачу в простых терминах понятных любому кодеру (без множеств и тем более классов), необходим некий бэкграунд.
Понимание множеств — один из удачных бэкграундов для данного примера с машинами.
Сложно представить, когда образованный аналитик не имеет понятия о множествах.
Нет, я имею в виду именно объект: совокупность данных и операций над ними. Я на всякий случай еще раз напомню, что class-based OOP — не единственная реализация ОО-парадигмы.
Нет. У объекта per se нет статических полей — они появляются только в конкретном языке. Вы же говорите «как реализовать в ООП», а не «как реализовать на <впишите ваш язык>»?
А вот это очень ценное замечание. Лично я считаю ООП достаточно хорошая парадигма, но есть идея, и есть ее реализация.
Мы сейчас уже который раз будем говорить об родном и том же. Что такое class-based OOP?
Достаточно было бы использовать ключевое слово datatype вместо class, и не было бы неверного представления, что типу данных Слон можно завести статическое поле «Общее кол-во слонов» или «Среднее кол-во слонов».
Достаточно было бы разрешить статик поля только как readonly и immutable, и уже даже технической возможности сделать этого не было бы.
Изначально вы ставили задачу как «как реализовать сущность», а теперь говорите о группе связанных сущностей (причем я бы еще поспорил, является ли каждая из них сущностью в терминах предметной области, или нет).Если вы помните наши предыдущие дискуссии и мою небольшую статью-комментарий, то я как раз и говорил о том, что «каждая из этих сущностей» не является сущностью в терминах предметной области.
А вот связанная группа сущностей («метасущность») образует сущность в терминах предметной области.
Понимание множеств — один из удачных бэкграундов для данного примера с машинами.
Ну вот у меня нет формального образования в области теории множеств. Все, что я про множества знаю — это принадлежность и производные от нее операции (объединение, пересечение, исключение). При этом я прекрасно понял вашу задачу.
Что такое class-based OOP?
Такой стиль объектно-ориентированного программирования, в котором в противовес объектам выделяются классы, и именно классы — как шаблон — и определяют структуру и поведение объекта (экземпляра этого класса).
Достаточно было бы использовать ключевое слово datatype вместо class, и не было бы неверного представления, что типу данных Слон можно завести статическое поле «Общее кол-во слонов» или «Среднее кол-во слонов».
Это представление никак не связано с термином «класс». Оно связано с тем, что есть языковой примитив, объединяющий все объекты конкретного типа, и, как следствие, подходящий для общей для этого типа информации. Проблема — в реальности — состоит в неумении адекватно выделять информацию, общую для типа и для группы объектов.
Достаточно было бы разрешить статик поля только как readonly и immutable, и уже даже технической возможности сделать этого не было бы.
Равно как и возможности реализовать другие удобные шаблоны программирования. Нет, спасибо.
А вот связанная группа сущностей («метасущность») образует сущность в терминах предметной области.
Каким, интересно, образом? Можете привести пример?
Я вот ни разу не видел, чтобы заказчик воспринимал множества сущностей как самостоятельные сущности в терминах предметной области. Это всегда именно множества, объединенные по тому или иному критерию. Сущность появляется тогда, когда у множества сущностей появляются дополнительные признаки, не вытекающие из комбинации свойств его членов (например, у отдела может быть название и функции).
Я вот ни разу не видел, чтобы заказчик воспринимал множества сущностей как самостоятельные сущности в терминах предметной области. Это всегда именно множества, объединенные по тому или иному критерию.
Что-то похожее возникает, когда множество точек на плоскости или в пространстве (например, «уголки» на изображении, или геодезические маркеры в 3D) начинает интерпретироваться, как жёсткий объект, и используется для поиска соответствия между разными изображениями или сканами (и приведения их в общую систему координат). Вроде бы, ничего нового не появилось — был набор координат (и, возможно, дескрипторов), он же и остался. Но за счёт того, что точки находятся в единой (для данного множества) системе координат, они превратились в самостоятельную сущность — созвездие маркеров. И пользователь про обе сущности — и исходные маркеры, и их созвездия — знает.
В точку! Мы знаем точки и созвездия! И это разные объекты! Спасибо за понимание статьи!
начинает интерпретироваться, как жёсткий объект,
Вот эта формулировка для меня означает, что у «набора» появился идентификатор, собственная ценность — т.е. это больше не просто «точки, расположенные левее оси х», а «точки, входящие в группу а». С этого момента группа определяется не точками, а сама по себе (а точки могут в нее входить или не входить).
Возможно, впрочем, я неправильно понял вашу предметную область.
Поискали точки в одной картинке — получили список (множество) точек. Поискали в другой — ещё одно множество. Отдали эти множества в функцию, которая ищет соответствия — с её точки зрения, эти множества оказались самостоятельными сущностями. И ничего нового: как были «точки, найденные на этой картинке», так и остались. Даже идентификатор картинки добавлять не обязательно, он уже есть в самих точках. Группа продолжает состоять из тех же точек, и её свойства определяются всё теми же точками (и взаимодействием с точками из других групп).
С другой стороны, ситуация неустойчива. Как только появятся какие-то дополнительные данные (например, показания датчика GPS), окажется, что группа определяется не только множеством точек. И она тем более станет самостоятельной сущностью. Но пока что функции передаются просто списки координат, иногда даже очищенные от имён точек.
С другой стороны, ситуация неустойчива. Как только появятся какие-то дополнительные данные (например, показания датчика GPS), окажется, что группа определяется не только множеством точек. И она тем более станет самостоятельной сущностью. Но пока что функции передаются просто списки координат, иногда даже очищенные от имён точек.
Собственно, мой кейс был много проще. Мне надо было разобрать, из чего состоит операция: из множества гвоздей, или из гвоздей множества? И ответ оказался очень не очевидным. Завели параметр «количество гвоздей» у операции «Сколотить ящик» — получили, что операция состоит из класса гвоздей. Но! Завели отдельно объекты класса «гвозди», а потом забрали их в операцию, например, создав список из перечисленных гвоздей, и получили, что операция состоит из гвоздей класса. Это было довольно трудно понять, но поняв, стало просто решать подобные задачи.
Вот понимаете, с моей точки зрения, мы сейчас на очень шаткой почве.
А почему сущностями, почему они не остались двумя множествами? Что изменилось? Вы и сам дальше пишете: «функции передают просто списки координат». Зачем выделять лишнюю сущность? Любая адекватная моделирующая нотация поддерживает коллекции — чем они недостаточны?
Отдали эти множества в функцию, которая ищет соответствия — с её точки зрения, эти множества оказались самостоятельными сущностями.
А почему сущностями, почему они не остались двумя множествами? Что изменилось? Вы и сам дальше пишете: «функции передают просто списки координат». Зачем выделять лишнюю сущность? Любая адекватная моделирующая нотация поддерживает коллекции — чем они недостаточны?
Да, это одна из проблем подхода YAGNI. Почему новая сущность не выделена сейчас, чем это мешает и в какой момент её будет необходимо выделить?
Не выделена — потому что пока можно обойтись без неё, и казалось, что это даёт чуть большее удобство в использовании: сформировать массив или список немного проще, чем объект нового класса. Хотя ясно, что разница — в одном вызове конструктора.
Любая коллекция не подходит: результат работы функции соответствия содержит индексы сопоставленных друг другу точек в исходных списках. А индексы есть не в любой коллекции. Это уже как бы намекает, что пора бы завести класс, но пока не очень уверенно.
А дальше начинается: можем захотеть сопоставить не два, а больше созвездий. В таблице сопоставленных точек появятся идентификаторы — из какого созвездия эта точка пришла. Пока не страшно: передадим массив списков, и вернём индексы в этом массиве.
Можем захотеть хранить в созвездии статистику его сопоставления с другими — сколько точек сопоставилось, какова средняя и максимальная ошибка… Хорошо, что мы этого не сделали — долго бы пришлось выпутываться :) Ведь созвездие, теоретически, может участвовать в нескольких разных сопоставлениях.
Можем захотеть добавить метаинформацию — откуда точки взялись, как их там найти (например, координаты в пикселях картинки)… но не будет ли правильнее держать её том объекте, из которого созвездие получено?
Можем попытаться найти новые свойства, которые появились из-за самого факта, что множество рассматривается, как созвездие. Например, дескрипторы точек в созвездии (список ближайших точек, расстояние до них, углы), отсортированный по длинам список отрезков или треугольников… Это очень полезно алгоритму сопоставления. Но проблема в том, что об этом знает именно этот алгоритм, а для других нужна совсем другая информация. Пусть алгоритм и считает?
Можем хранить точки созвездия в другой структуре, более удобной для навигации. Например, в каком-нибудь K-D tree. Пожалуй, при определённой статистике обращений это было бы полезно, и тогда пригодился бы отдельный класс. Но это можно сделать потом, во время оптимизации. Пока хватит и статической функции «найди ближайшую точку в списке».
В общем, странная картина. Сущность, вроде бы, есть. Но все её свойства, как сущности, находятся где-то снаружи, как результат её наблюдения, или того факта, что над ней происходит какая-то работа. Таких свойств, которые бы возникли именно из-за объединения точек в созвездие, и при этом с хорошей вероятностью были бы нужны более, чем в одном месте (кроме банального «количества точек»), обнаружить не удаётся. Так нужен ли для неё класс? Или она так и будет существовать, как короткоживущие объекты без названия, возникающие там, где нужно, и в той форме, в какой нужно?
Не выделена — потому что пока можно обойтись без неё, и казалось, что это даёт чуть большее удобство в использовании: сформировать массив или список немного проще, чем объект нового класса. Хотя ясно, что разница — в одном вызове конструктора.
Любая коллекция не подходит: результат работы функции соответствия содержит индексы сопоставленных друг другу точек в исходных списках. А индексы есть не в любой коллекции. Это уже как бы намекает, что пора бы завести класс, но пока не очень уверенно.
А дальше начинается: можем захотеть сопоставить не два, а больше созвездий. В таблице сопоставленных точек появятся идентификаторы — из какого созвездия эта точка пришла. Пока не страшно: передадим массив списков, и вернём индексы в этом массиве.
Можем захотеть хранить в созвездии статистику его сопоставления с другими — сколько точек сопоставилось, какова средняя и максимальная ошибка… Хорошо, что мы этого не сделали — долго бы пришлось выпутываться :) Ведь созвездие, теоретически, может участвовать в нескольких разных сопоставлениях.
Можем захотеть добавить метаинформацию — откуда точки взялись, как их там найти (например, координаты в пикселях картинки)… но не будет ли правильнее держать её том объекте, из которого созвездие получено?
Можем попытаться найти новые свойства, которые появились из-за самого факта, что множество рассматривается, как созвездие. Например, дескрипторы точек в созвездии (список ближайших точек, расстояние до них, углы), отсортированный по длинам список отрезков или треугольников… Это очень полезно алгоритму сопоставления. Но проблема в том, что об этом знает именно этот алгоритм, а для других нужна совсем другая информация. Пусть алгоритм и считает?
Можем хранить точки созвездия в другой структуре, более удобной для навигации. Например, в каком-нибудь K-D tree. Пожалуй, при определённой статистике обращений это было бы полезно, и тогда пригодился бы отдельный класс. Но это можно сделать потом, во время оптимизации. Пока хватит и статической функции «найди ближайшую точку в списке».
В общем, странная картина. Сущность, вроде бы, есть. Но все её свойства, как сущности, находятся где-то снаружи, как результат её наблюдения, или того факта, что над ней происходит какая-то работа. Таких свойств, которые бы возникли именно из-за объединения точек в созвездие, и при этом с хорошей вероятностью были бы нужны более, чем в одном месте (кроме банального «количества точек»), обнаружить не удаётся. Так нужен ли для неё класс? Или она так и будет существовать, как короткоживущие объекты без названия, возникающие там, где нужно, и в той форме, в какой нужно?
Когда я писал аналитику для учета, оказалось что существуют как свойства объектов класса, так и свойства класса объектов. Поэтому мне для описания аналитики нужно было иметь в натуре, то есть в аналитике и в коде, как объекты класса так и класс объектов. С тех пор, я предлагаю своим коллегам делить явно свойства объектов и свойства класса объектов. Это очень помогает в рисовании ясной аналитики.
В нашей беседе есть одна проблема: и вы, и я, к сожалению, обсуждаем реализацию. Функции, массивы, индексы, классы, алгоритмы… это реализация. Это не совсем предметная область.
Верно. Можно сказать так:
Множество точек объявили созвездием. Что от этого изменилось?
Многое. У созвездия есть центр масс, эллипсоид инерции, области наибольшего сгущения. У точек в нём возникло понятие «ближайшая точка». Появилась возможность придумать дескриптор, чего у исходных точек не было. В этом смысле, созвездие явно является новой сущностью.
Вроде бы, это не про реализацию. Но вопрос: эти свойства появились сами по себе? Или под воздействием внешнего влияния — того, как созвездие будет использоваться? И второй вопрос: а имеет ли смысл первый вопрос, или новая сущность всегда появляется под воздействием внешнего влияния?
Множество точек объявили созвездием. Что от этого изменилось?
Многое. У созвездия есть центр масс, эллипсоид инерции, области наибольшего сгущения. У точек в нём возникло понятие «ближайшая точка». Появилась возможность придумать дескриптор, чего у исходных точек не было. В этом смысле, созвездие явно является новой сущностью.
Вроде бы, это не про реализацию. Но вопрос: эти свойства появились сами по себе? Или под воздействием внешнего влияния — того, как созвездие будет использоваться? И второй вопрос: а имеет ли смысл первый вопрос, или новая сущность всегда появляется под воздействием внешнего влияния?
Понимаете ли, важный момент состоит в том, есть ли термин «созвездие» (с описаннными вами характеристиками) в постановке задачи. Не важно, откуда он пришел — от аналитика по результатам разговора с заказчиком, или же от разработчика по результатам уточнения той же задачи. Важно, что он выплыл из плоскости кода в плоскость требований.
В постановке…
Заказчик сказал «хочу, чтобы получалась красивая панорама» (или «единая модель объекта» — не важно). Алгоритмист сказал «Можно, например, выделить такие-то точки и сопоставить их такими-то алгоритмами». Пока ещё слово «созвездие» не прозвучало (или прозвучало — но как «множество безымянных точек», чтобы отличать их от именованных). Характеристики (центр масс, дескрипторы,...) присутствуют в описании алгоритма, но, сами понимаете, достаточно бесструктурно — слишком многие связи остались на неявном уровне. И уже потом кто-то (аналитик? архитектор? разработчик? не знаю, какая это роль) обнаружил, что думает об этих точках и их общих свойствах, как о «созвездии». Попадёт ли эта сущность в постановку задачи на каком-нибудь уровне? Или останется исключительно на уровне реализации, или в чьей-нибудь голове?
Заказчик сказал «хочу, чтобы получалась красивая панорама» (или «единая модель объекта» — не важно). Алгоритмист сказал «Можно, например, выделить такие-то точки и сопоставить их такими-то алгоритмами». Пока ещё слово «созвездие» не прозвучало (или прозвучало — но как «множество безымянных точек», чтобы отличать их от именованных). Характеристики (центр масс, дескрипторы,...) присутствуют в описании алгоритма, но, сами понимаете, достаточно бесструктурно — слишком многие связи остались на неявном уровне. И уже потом кто-то (аналитик? архитектор? разработчик? не знаю, какая это роль) обнаружил, что думает об этих точках и их общих свойствах, как о «созвездии». Попадёт ли эта сущность в постановку задачи на каком-нибудь уровне? Или останется исключительно на уровне реализации, или в чьей-нибудь голове?
Кстати, получилось, что «точка в созвездии» — тоже новая сущность, отличная от просто «точки». Так ещё получится, что колесо, прикрученное к машине — это уже другое колесо, пусть и «отнаследованное» от оригинального. И никакие «подписчики на события» это не обойдут.
Это рулится, но уже другими методами. Это требует введение такого понятия, как темпоральная часть объекта и линия жизни объекта. В данном сообщении я специально не усложняю модель до этого уровня. Предполагается, что мы не рассматриваем изменения в нашей модели, или это значит, что линия жизни машины и линия жизни колес совпадают. Эти термины заимствованы из ИСО 15926.
Как у вас так получилось?
У объекта «точка в созвездии» появились новые свойства (например, «ближайшая точка в том же созвездии»), которых у точки самой по себе просто не может быть.
А. Это появляющаяся (emergent) сущность, основой для которой служит не сущность, а связь.
Т.е. у вас есть сущности «точка» и «созвездие». У вас (автоматически) появилась связь «точка входит в созвездие». Теперь вы замечаете, что у этой связи есть собственные атрибуты (ну не знаю, конкретная категория внутри созвездия) и связи (ближайшая точка). В этот момент связь «повышается» до сущности («принадлежность точки к созвездию»), которая имеет связь с точкой, связь с созвездием и связь с другой такой же сущностью («ближайшая»).
То есть это не «другая сущность, отнаследованная от», это промежуточная сущность, связанная с.
Т.е. у вас есть сущности «точка» и «созвездие». У вас (автоматически) появилась связь «точка входит в созвездие». Теперь вы замечаете, что у этой связи есть собственные атрибуты (ну не знаю, конкретная категория внутри созвездия) и связи (ближайшая точка). В этот момент связь «повышается» до сущности («принадлежность точки к созвездию»), которая имеет связь с точкой, связь с созвездием и связь с другой такой же сущностью («ближайшая»).
То есть это не «другая сущность, отнаследованная от», это промежуточная сущность, связанная с.
Что-то «emergent properties» и «emergent entities» в Гугле выдают сплошную философию. Где можно прочитать про это применительно к программированию?
А то моя первая мысль — что эти «связи» не имеют «связь с созвездием», а являются его частью, и, более того, подменяют собой точки — созвездие смотрит на точку, а видит «точку в созвездии», со всеми вновь появившимися атрибутами. Но я понимаю, что смотрю на картину с точки зрения реализации, а не анализа.
А то моя первая мысль — что эти «связи» не имеют «связь с созвездием», а являются его частью, и, более того, подменяют собой точки — созвездие смотрит на точку, а видит «точку в созвездии», со всеми вновь появившимися атрибутами. Но я понимаю, что смотрю на картину с точки зрения реализации, а не анализа.
«emergent properties» это вообще не про это. Это про то, что целое не есть сумма его частей. Чисто философское понимание композиции. К данному разговору не имеет отношения. В данном примере мы не рассматриваем композицию, мы рассматриваем классификацию. Хотя, если продолжать дальше, там всплывает множество сущностей, которые мы просто пропускаем в своих рассуждениях ради упрощения.
Что-то «emergent properties» и «emergent entities» в Гугле выдают сплошную философию. Где можно прочитать про это применительно к программированию?
Нигде, это просто не имеющее адекватного русского перевода английское слово, которое означает, что что-то появляется (как «выплывает из глубин»).
А то моя первая мысль — что эти «связи» не имеют «связь с созвездием», а являются его частью,
«Являться частью» — это тоже вид связи. Если вы в ER-модели разделяете references и contains (иногда так делают), то эти сущности действительно contained, а не referenced. Если не разделяете (так делают для уменьшения числа примитивов в модели) — то связь есть.
более того, подменяют собой точки — созвездие смотрит на точку, а видит «точку в созвездии», со всеми вновь появившимися атрибутами.
Вы совершенно правильно пишете дальше, что это уже деталь реализации. По факту, то, что вы описываете, это денормализация — мы из нормализованных сущностей (связь с созвездием + точка) вытаскиваем денормализованную информацию в связь с созвездием, чтобы созвездию было проще работать. Но это реализационное решение, оно к чистой модели отношения уже не имеет.
дубль.
Каждый раз, когда вижу рассказы про ООП и программистов, у меня ощущение, что я читаю откровения какой-то секты и её ритуалов посвящения. Настолько это далеко и от задач CS, и от задач реального мира, что просто только руками развести остаётся.
ООП — это инструмент SE, а не CS
Но тут товарищ автор не имеет отношения ни к первому (ООП), ни ко второму (программистам), ни к третьему (CS), ни к четвёртому (SE).
Но тут товарищ автор не имеет отношения ни к первому (ООП), ни ко второму (программистам), ни к третьему (CS), ни к четвёртому (SE).
Вот я в идустрии рядом с SE очень плотно. Обсуждаемые абстрактные в вакууме колёса и отношения классов к своим объектам настолько далеки от реальных проблем SE, что просто слов никаких не хватает.
Про ООП я хотел сказать лишь то, что класс, употребляемый мной в тексте не есть класс в смысле ООП. Потому что иначе возникнет путаница
Забей еще, есть машины без колёс
интересно, какое отношение это все имеет к программированию?
Я давно прочитал, не хотел высказываться. Но Вы, говорят, прямо интересовались моим мнением. Поэтому скажу так:
Мне неизвестна формальная логическая система, в которой было бы верно данное Ваше утверждение:
«Можно сказать, что машина состоит из класса колес, как двигатель состоит из класса болтов, как табуретка состоит из класса молекул. При этом мы не можем сказать, как именно машина состоит из колес, потому что в такой риторике нет координат, которые описывали бы местоположение колес в машине. В таком случае мы обычно говорим — машина состоит из пяти колес.»
Возможно, такую систему можно разработать, не знаю.
Мне неизвестна формальная логическая система, в которой было бы верно данное Ваше утверждение:
«Можно сказать, что машина состоит из класса колес, как двигатель состоит из класса болтов, как табуретка состоит из класса молекул. При этом мы не можем сказать, как именно машина состоит из колес, потому что в такой риторике нет координат, которые описывали бы местоположение колес в машине. В таком случае мы обычно говорим — машина состоит из пяти колес.»
Возможно, такую систему можно разработать, не знаю.
Спасибо за комментарий!
Представим себе, что у нас учетная система склада, на котором хранится 100 болтов. Предположим, я оформляю отгрузку 10-ти из них нашему дорогому клиенту. Кладовщик на складе берет первые попавшиеся 10 болтов и отгружает их. Выдает сертификат соответствия для любого болта данной марки. Вариант второй — у меня на складе 100 болтов. К каждому из них у меня приклеена электронная метка с ИД. Все ИД заведены в базе данных и на каждый ИД заведена история изготовления и хранения. Я выписываю документы на отгрузку, в которых указываю, какие болты с какими ИД следует отгрузить клиенту. Клиенту уходят 10 конкретных болтов, которые еще надо найти, а не взять первые попавшиеся, вместе с документами на каждый болт отдельно.
Эти два кейса демонстрируют нам две модели учета. Первая учитывает только класс объектов, но не учитывает объекты класса.
Вторая учитывает объекты класса, но не учитывает класс объектов. Хотя учесть класс объектов для нее очень просто — просто хранить количество оставшихся болтов.
Итак, в реальной жизни надо иметь возможность моделировать как один кейс, так и второй. В первом случае склад будет иметь связь «хранит» с классом болтов, а во втором будет иметь сто связей «хранит» с каждым болтом класса, что и будет представлено в структуре данных соответствующим образом.
Это простой пример, но когда речь заходит о более сложных, например, при моделировании активности, то невозможность моделировать такого класса связи в ИСО 15926 вызывает у меня сильное беспокойство.
Я бы предложил оформить эти кейсы соответствующим образом и передать разработчикам ИСО для ознакомления. Если их стандарт построен на работах того же Криса, то они легко поймут это ограничение. поскольку у Криса этого ограничения нет.
Представим себе, что у нас учетная система склада, на котором хранится 100 болтов. Предположим, я оформляю отгрузку 10-ти из них нашему дорогому клиенту. Кладовщик на складе берет первые попавшиеся 10 болтов и отгружает их. Выдает сертификат соответствия для любого болта данной марки. Вариант второй — у меня на складе 100 болтов. К каждому из них у меня приклеена электронная метка с ИД. Все ИД заведены в базе данных и на каждый ИД заведена история изготовления и хранения. Я выписываю документы на отгрузку, в которых указываю, какие болты с какими ИД следует отгрузить клиенту. Клиенту уходят 10 конкретных болтов, которые еще надо найти, а не взять первые попавшиеся, вместе с документами на каждый болт отдельно.
Эти два кейса демонстрируют нам две модели учета. Первая учитывает только класс объектов, но не учитывает объекты класса.
Вторая учитывает объекты класса, но не учитывает класс объектов. Хотя учесть класс объектов для нее очень просто — просто хранить количество оставшихся болтов.
Итак, в реальной жизни надо иметь возможность моделировать как один кейс, так и второй. В первом случае склад будет иметь связь «хранит» с классом болтов, а во втором будет иметь сто связей «хранит» с каждым болтом класса, что и будет представлено в структуре данных соответствующим образом.
Это простой пример, но когда речь заходит о более сложных, например, при моделировании активности, то невозможность моделировать такого класса связи в ИСО 15926 вызывает у меня сильное беспокойство.
Я бы предложил оформить эти кейсы соответствующим образом и передать разработчикам ИСО для ознакомления. Если их стандарт построен на работах того же Криса, то они легко поймут это ограничение. поскольку у Криса этого ограничения нет.
К каждому из них у меня приклеена электронная метка с ИД. Все ИД заведены в базе данных и на каждый ИД заведена история изготовления и хранения.
Для справки: Traceability systems.
Это очень странный подход.
На самом деле в обоих случаях есть и класс, и индивид (объект хранения).
Во-первых, необходим класс БОЛТ М10, в обоих случаях один и тот же. Это стандартный класс, класс всех болтов данного стандарта в мире, имеет все стандартные атрибуты и не имеет никакого отношения к нашему складу. Лучше бы вообще брать его ID из национальной библиотеки справочных данных.
Во-вторых, есть объект хранения, индивид.
По второму варианту тут всё очевидно, индивиды индивидуализированы метками, классифицированы классом БОЛТ М10.
По первому варианту надо повозиться, если есть желание достичь строгости. Надо написать логическое утверждение о том, что темпоральные части нашего хранимого индивида состоят из объектов, классифицированных классом БОЛТ М10. У этих темпоральных частей (индивидов!) есть атрибут ВЕС.
Но в обоих случаях у склада связь ХРАНИТ с индивидом, несколькими или одним.
Никогда не делаются утверждения «склад хранит класс» или «машина состоит из класса». Всякий класс — вечен и неизменен, поэтому нет никакой разумной и удобной для имплементации возможности считать хранимым объектом какой-бы то ни было класс. Всё это верно в рамках той парадигмы моделирования, которой я занимаюсь, разумеется.
На самом деле в обоих случаях есть и класс, и индивид (объект хранения).
Во-первых, необходим класс БОЛТ М10, в обоих случаях один и тот же. Это стандартный класс, класс всех болтов данного стандарта в мире, имеет все стандартные атрибуты и не имеет никакого отношения к нашему складу. Лучше бы вообще брать его ID из национальной библиотеки справочных данных.
Во-вторых, есть объект хранения, индивид.
По второму варианту тут всё очевидно, индивиды индивидуализированы метками, классифицированы классом БОЛТ М10.
По первому варианту надо повозиться, если есть желание достичь строгости. Надо написать логическое утверждение о том, что темпоральные части нашего хранимого индивида состоят из объектов, классифицированных классом БОЛТ М10. У этих темпоральных частей (индивидов!) есть атрибут ВЕС.
Но в обоих случаях у склада связь ХРАНИТ с индивидом, несколькими или одним.
Никогда не делаются утверждения «склад хранит класс» или «машина состоит из класса». Всякий класс — вечен и неизменен, поэтому нет никакой разумной и удобной для имплементации возможности считать хранимым объектом какой-бы то ни было класс. Всё это верно в рамках той парадигмы моделирования, которой я занимаюсь, разумеется.
Никогда не делаются утверждения «склад хранит класс» или «машина состоит из класса».
Спасибо, вы избавили меня от подозрения в сумасшествии.
класс болтов М10 можно связать связью специализация с классом болтов, которые произведены на момент 10 июля 2015 года в 12-00. И те, которые будут произведены после этой даты. Возможно, сюда нужно добавить класс возможных болтов М10, которые никогда не будут произведены. Итак, берем класс произведенных болтов на момент времени t. Из этого класса выделяем тот подкласс болтов, который был произведен 1-го октября 2012 года на заводе Красный Коммунар. Из этого класса выделяем подкласс болтов, который ушел на склад номер 1 в количестве 100 штук. Понятно, что это такой же класс, как и все другие. По крайней мере, я не вижу разницы. Теперь вопрос: почему у этого класса болтов не может быть темпоральных частей, как и у объектов этого класса? Берем всю линию жизни этого класса от момента его создания в учетной системе и до момента завершения учета этой позиции. и смотрим на изменение количества объектов этого класса? Например, есть класс яблонь нашего сада. Понятно, что этот класс меняется во времени.
АЙ, сам же попался!!! У нас ничего не меняется!!! Просто хранимый класс — есть набор темпоральных частей болтов. И у этого класса есть подклассы — темпоральные части, которые присутствуют в этом классе на момент времени t! То есть, состав класса яблонь на момент времени определяется связью специализация с классом всех темпоральных частей всех яблонь, где специализация проводится по принципу отсева по времени.
Ну так этот подкласс темпоральных частей на данный момент и является тем индивидом, который должен учитываться в системе. Потому что значение атрибута Вес может быть только у индивида, у класса полагается интервал значений.
Вообще же всегда можно заменить объекты классами по одному объекту, только это замутнит модель данных до неприличия. А цель — прозрачная модель данных.
Вообще же всегда можно заменить объекты классами по одному объекту, только это замутнит модель данных до неприличия. А цель — прозрачная модель данных.
Чтобы не замутить, я рассматривал примитивный кейс: машина состоит из колес, — это раз, линия жизни машины совпадает с линией жизни колес — два. Поэтому рассмотрение темпоральных частей я не планировал. Однако, в моем втором кейсе с учетом болтов я ненамеренно исказил свою же задумку, введя в модель непостоянство состава этого класса во времени. Тем самым заставив Вас перейти к темпоральным частям. Это мой косяк.
Вообще же мышление на эту тему мне пока дается с трудом.
Так вот, если оставаться с машиной, то я вижу множество колес и вижу колеса множества и вижу два вида учета этих объектов. У меня это уже не отнять). Я тестировал этот тезис на разных людях и никто не высказал сомнений в моей картинке. Сомнения возникли только у тех, кто реально занимается моделированием, например, у Вас. Я все же склонен считать это инерцией мышления, вызванной применяемым инструментарием.
Мне еще понадобится в будущем возможность связывать классы и объекты, чтобы связать термины операция и функция. И придуманный здесь простой пример был сконструирован мной как упрощенная иллюстрация к будущим конструкциям.
В ИСО нет такого раздела как операции над множествами. Там просто отсутствует начисто математика темпоральных частей. И это уже серьезный косяк. Мы можем склеивать темпоральные части вместе, образуя новые, Фактически, темпоральные части образуют борелевское множество без меры на нем. Это, правда, пока лишь гипотеза. Так вот в этой математике обязана быть операция над множеством темпоральных частей, приводящая к образованию одной темпоральной части. И вот тут появляется связь: множество — объект. И пока я не вижу в этой операции никаких противоречий.
Вообще же мышление на эту тему мне пока дается с трудом.
Так вот, если оставаться с машиной, то я вижу множество колес и вижу колеса множества и вижу два вида учета этих объектов. У меня это уже не отнять). Я тестировал этот тезис на разных людях и никто не высказал сомнений в моей картинке. Сомнения возникли только у тех, кто реально занимается моделированием, например, у Вас. Я все же склонен считать это инерцией мышления, вызванной применяемым инструментарием.
Мне еще понадобится в будущем возможность связывать классы и объекты, чтобы связать термины операция и функция. И придуманный здесь простой пример был сконструирован мной как упрощенная иллюстрация к будущим конструкциям.
В ИСО нет такого раздела как операции над множествами. Там просто отсутствует начисто математика темпоральных частей. И это уже серьезный косяк. Мы можем склеивать темпоральные части вместе, образуя новые, Фактически, темпоральные части образуют борелевское множество без меры на нем. Это, правда, пока лишь гипотеза. Так вот в этой математике обязана быть операция над множеством темпоральных частей, приводящая к образованию одной темпоральной части. И вот тут появляется связь: множество — объект. И пока я не вижу в этой операции никаких противоречий.
Ну вот опять сам себя подловил)). В быту мы настолько неаккуратно используем термины, что мне очень сложно быть аккуратным в своих высказываниях. я сказал, что:
На самом деле надо было сказать: должна быть операция над темпоральными частями множества.
Итак, надо быть аккуратным в терминах и различать в речи множества объектов и объекты множества. В очередной раз убеждаюсь в этом!
в этой математике обязана быть операция над множеством темпоральных частей
На самом деле надо было сказать: должна быть операция над темпоральными частями множества.
Итак, надо быть аккуратным в терминах и различать в речи множества объектов и объекты множества. В очередной раз убеждаюсь в этом!
И второе — есть темпоральные части объектов. Логично было бы ввести темпоральные части множеств объектов. Но этого тоже пока нет.
Примером связи объекта и класса является тезис: воздушный шарик наполнен молекулами газа. Я не поверю, что кто-либо когда либо учитывал каждую молекулу в этом объеме. (обойдемся без темпоральных частей). Связь между шариком и чем-то, состоящим из молекул, — одна. Если это так, то это может быть связь только с классом молекул. Не может быть одной связи между шариком и каждом молекулой.
Поэтому в комментах про созвездие полная картина (без учета темпоральных частей) будет такая: Есть звезды, есть множество звезд и есть созвездие. Тезис «созвездие состоит из звезд» будет читаться двумя способами. Первый, если речь идет про конкретное созвездие — созвездие состоит из множества звезд. Второй, если речь идет про любое созвездие, может трактоваться в свою очередь двумя способами. способ а: любое созвездие состоит из множества звезд. способ б: созвездие состоит из конкретных звезд, количество которых может быть разным. Тезис «конкретное созвездие состоит из вот этих конкретных звезд будет означать, что созвездие состоит из звезд класса и описывается множеством связей между созвездием и звездами этого созвездия. Итого, 4 способа трактовки почти неразличимых на слух тезисов.
Поэтому в комментах про созвездие полная картина (без учета темпоральных частей) будет такая: Есть звезды, есть множество звезд и есть созвездие. Тезис «созвездие состоит из звезд» будет читаться двумя способами. Первый, если речь идет про конкретное созвездие — созвездие состоит из множества звезд. Второй, если речь идет про любое созвездие, может трактоваться в свою очередь двумя способами. способ а: любое созвездие состоит из множества звезд. способ б: созвездие состоит из конкретных звезд, количество которых может быть разным. Тезис «конкретное созвездие состоит из вот этих конкретных звезд будет означать, что созвездие состоит из звезд класса и описывается множеством связей между созвездием и звездами этого созвездия. Итого, 4 способа трактовки почти неразличимых на слух тезисов.
пришла аналогия из физики. С чем еще можно сравнить описания через класс объектов и через объекты класса: с газом! Если мы рассматриваем газ молекул, то мы можем померить координаты и скорости каждой молекулы. Такое описание будет абсолютно исчерпывающим для данной системы. И это будет означать, что мы знаем о системе абсолютно все. Другое дело, когда мы знаем занимаемый газом объем, температуру газа. Но не знаем ничего о каждой молекуле. Такое знание тоже говорит нам что-то о системе. Так и с колесами: знание о каждом колесе позволяет нам говорить, что о колесах мы знаем все, например, индивидуальные особенности шин. Знание о классе колес позволяет нам знать количество колес, но не позволяет знать их положение в пространстве. То есть, во втором случае мы знаем что-то о колесах, но не все.
Газ не эквивалентен классу молекул.
конечно
Вот и ваша аналогия неверна.
я не говорю, что газ эквивалентен классу молекул
Множество точек прямой не есть прямая. Множество атомов газа не есть газ. Это верно.Но я не говорю, что газ есть молекулы, или множество молекул, я говорю, что газ связан семантикой с молекулами газа и с множеством молекул газа. Семантика — это смысл, который приписывается этой связи субъектом. Смыслом, пусть воображаемым можно связать что угодно с чем угодно. Например, связи между газом и конкретной молекулой газа можно придать смысл «состоит из», «включает», «находится в», «содержит». и так далее. связи между газом и классом молекул можно придать смысл: «состоит из», «является», и так далее. В своем сообщении я специально не стал указывать на семантику связи между газом и классом молекул, пусть каждый возьмет свою. В то же время в самой статье я специально указал эту семантику. «Состоит из». Не потому, что это мой выбор, а потому что так сказал субъект — хозяин машины. В его представлении семантика такая. Я лишь записал это в модели.
Представление заказчика не обязательно верно. И тем более формулировка заказчика не обязательно верна, особенно в терминах модели.
Семантика всегда в голове у субъекта. Или у субъектов, если они договорятся. Мы тратим очень много времени на договоренности, которые позволят нам иметь одинаковую семантику исходя из класса решаемых задач, или имеющихся представлений. Семантика — это точка зрения, не более того. Главное, что к этой точке зрения предъявляются требования. Где-то непротиворечивости, где-то образности и так далее. Но по сути семантика всегда произвольна в рамках этих ограничений. Мы можем слушать заказчика и решать только одно: его семантическая паутина противоречива или нет, соответствует ли она общим представлениям, имеет ли она коммерческую пользу и так далее. Мы даже можем помочь ему оптимизировать эту сеть. Но навязывать ему свою сеть только потому что мы привыкли к ней, — глупо.
Ну вот в данном случае она противоречит общим представлениям, не имеет коммерческой пользы и в будущем, вероятно, приведет к противоречиям в модели. Как следствие, ее надо исправить сейчас.
Она не противоречит как как минимум, одной методологии и представлению заказчика. Надо — поправим, а пока нам известно, что известно. Аналитик услышал и записал.
Записал — сколько угодно. Ссылаться на это как на заведомо верную семантику — нельзя.
Все слышимые мной тезисы «состоит из» я разложил в шесть групп, которые описал в статье. Конечно, для каждой группы неплохо было бы иметь отдельное наименование, но в русском языке их нет(. Есть только в математической логике. Например, в высказываниях «прямая состоит из множества точек» и «прямая состоит из отрезков» термин «состоит из» имеет совершенно разный смысл. Но, увы, в языке на слух они неразличимы. Философы давно различают два значения «состоит из»: композицию и агрегацию, но не учитывают возможности связей между объектами и множествами объектов, потому что в философию эти понятия глубоко еще не проникли. При этом я уверен, что подобные многозначные слова нас окружают повсюду, но. поскольку мы гипнабельны, нам очень сложно выйти за пределы гипнотического влияния слов.
Я всегда считал, что любой многозначности в требованиях (и моделях, как части требований) надо избегать. Если у термина больше одного значения, надо найти другой. Если найти другой невозможно, нужно зафиксировать одно значение из многих.
Ну и да, это все никак не меняет того факта, что если заказчик что-то сказал терминологически неверно, его надо вежливо поправить, а не вносить эту ошибку в модель.
(наконец, отдельно замечу, что автомобилисты не говорят «машина состоит из колес», более того, ни один человек, которого я спросил, так не говорит)
Ну и да, это все никак не меняет того факта, что если заказчик что-то сказал терминологически неверно, его надо вежливо поправить, а не вносить эту ошибку в модель.
(наконец, отдельно замечу, что автомобилисты не говорят «машина состоит из колес», более того, ни один человек, которого я спросил, так не говорит)
По-моему, я понял, почему ИСО 15926 не может связать объект с классом объектов. Как я сказал, в моем понимании все можно связать со всем, в том числе объект с классом объектов, или с классом классов объектов, или класс объектов с классом классов, например, класс яблонь с классом сортов яблонь.
Проблема в том, что в ИСО по какой-то причине считается, что это недопустимая связь. И причина эта кроется в том, что в ИСО класс провозглашен множеством лишь на словах! Я посмотрел определение множества объектов и нашел: множество -это совокупность различных элементов, мыслимое как единое целое. То есть, это не абстракция, а вполне конкретная совокупность объектов! Скорее всего, ИСО просто не сделало следующий логический шаг. Уж если отказываться от Аристотеля, то надо признавать объективность множества, и позволить связывать семантикой объекты и множества.
Проблема в том, что в ИСО по какой-то причине считается, что это недопустимая связь. И причина эта кроется в том, что в ИСО класс провозглашен множеством лишь на словах! Я посмотрел определение множества объектов и нашел: множество -это совокупность различных элементов, мыслимое как единое целое. То есть, это не абстракция, а вполне конкретная совокупность объектов! Скорее всего, ИСО просто не сделало следующий логический шаг. Уж если отказываться от Аристотеля, то надо признавать объективность множества, и позволить связывать семантикой объекты и множества.
На мой взгляд, проблема сугубо терминологическая — о том как говорить. Хотя и не только.
Да любое множество объектов однотипно относящихся к некоторому объекту можно выделить в отельный класс: класс «все колеса данной машины», «все пассажиры данной машины», «все болты данной марки на данном складе» и т.п. И все это — специализации классов «колеса», «люди», болты данной марки". И, да, можно говорить, что все классы однотипных элементов данной машины или болтов на складе есть объекты. Тут все тривиально.
Проблемы начинаются, когда мы пытаемся установить отношения между объектами. Можно два объекта типа «класс» (пассажиров и колеса) соединить в новый класс? Да, конечно. Можно два индивида сделать частью другого индивида (колесо прикрутить к машине)? Да. А можно объект-класс прикрутить к машине? Нет. То есть проблема не в том, можно или нельзя объекты по любому признаку объединять в классы и эти классы воспринимать как объекты, а в том, что устанавливать отношения можно только между объектами одного типа. Нельзя на склад завести класс. Надо сначала положить на полки индивиды, а потом уже по признаку нахождения на складе включить их в класс.
Да любое множество объектов однотипно относящихся к некоторому объекту можно выделить в отельный класс: класс «все колеса данной машины», «все пассажиры данной машины», «все болты данной марки на данном складе» и т.п. И все это — специализации классов «колеса», «люди», болты данной марки". И, да, можно говорить, что все классы однотипных элементов данной машины или болтов на складе есть объекты. Тут все тривиально.
Проблемы начинаются, когда мы пытаемся установить отношения между объектами. Можно два объекта типа «класс» (пассажиров и колеса) соединить в новый класс? Да, конечно. Можно два индивида сделать частью другого индивида (колесо прикрутить к машине)? Да. А можно объект-класс прикрутить к машине? Нет. То есть проблема не в том, можно или нельзя объекты по любому признаку объединять в классы и эти классы воспринимать как объекты, а в том, что устанавливать отношения можно только между объектами одного типа. Нельзя на склад завести класс. Надо сначала положить на полки индивиды, а потом уже по признаку нахождения на складе включить их в класс.
Нельзя на склад завести класс
Это вопрос учета. Объекты могут быть расставлены по полкам. Но может так случиться, что нам неизвестно это расположение. Молекулы газа в любой момент времени расположены определенным образом, но нам очень редко бывает известно их точно расположение. От этого появляется понятие энтропии. Энтропия может быть определена двумя способами. У газа, как у макроскопического объекта как внутренняя энергия, которую возможно отдать в виде работы, или как логарифм термодинамической вероятности. В обоих случаях мы получаем согласующиеся формулы, хотя в первом случае мы понятия не имеем, что газ состоит из молекул, а во втором — это наше предположение. Но, если бы мы знали расположение товара на полках, или молекул газа в газе, то произошло бы чудо! Мы могли бы нарушить второй закон термодинамики и преобразовать всю внутреннюю энергию в работу.
еще один пример из системы учета. Мы выпускаем трактора. каждый из них обладает уникальным номером и мы следим за каждым из них по уникальному ИДишнику. Однако, правительство, когда отчитывается о выпущенных в этом году тракторах, не говорит, что выпустили один трактор с таким ИД, другой — с таким… Оно говорит: выпустили 300 тракторов в год! Это точка зрения на газ, когда нам не важно расположение молекул. Нам надо знать лишь их количество.
Я понимаю вашу логику введения класса объектов, включенных в другой объект. Это вполне прагматично. Что и показывают ваши примеры. Я лишь за чистоту языка и логики, то есть я принципиально не согласен с фразой «машина состоит из класса колес» или на «склад завезли класс болтов».
Некорректность этих фраз легко понять, если использовать событийный подход. Вот в перед нами множество (больше 5) колес — «класс колес в гараже» и машина без колес — индивид. Можно сказать, что мы этот класс колес сделаем частью машины? Нет. В этом действии/акте/операции не может участвовать такой объект как «класс колес». У нас есть четыре события «колесо [индивид] стало частью машины». И если у нас есть «класс колес этой машины», то только после каждого события присоединения колесо переходит из класса «колеса в гараже» в класс «колеса машины».
Поэтому логически и лексически корректнее говорить колесо/болт (индивиды) стали частью машины/склада (индивида), что автоматом вызывает событие включение колеса/болта в класс «колеса машины»/«болты склада». Но при этом понятно, что класс не может быть частью индивида. Только индивид может быть часть индивида, а класс может быть частью класса.
Некорректность этих фраз легко понять, если использовать событийный подход. Вот в перед нами множество (больше 5) колес — «класс колес в гараже» и машина без колес — индивид. Можно сказать, что мы этот класс колес сделаем частью машины? Нет. В этом действии/акте/операции не может участвовать такой объект как «класс колес». У нас есть четыре события «колесо [индивид] стало частью машины». И если у нас есть «класс колес этой машины», то только после каждого события присоединения колесо переходит из класса «колеса в гараже» в класс «колеса машины».
Поэтому логически и лексически корректнее говорить колесо/болт (индивиды) стали частью машины/склада (индивида), что автоматом вызывает событие включение колеса/болта в класс «колеса машины»/«болты склада». Но при этом понятно, что класс не может быть частью индивида. Только индивид может быть часть индивида, а класс может быть частью класса.
Но при этом понятно, что класс не может быть частью индивида.
Не очень понятно. В предикате для определения класса «колёса машины» используется конкретный объект — эта машина. В описании машины тоже есть ссылка на этот класс (в случае, если в используемом языке классы имеют представление в виде объекта), а если нет — её легко создать динамически — а так же на список самих объектов этого класса. Причём физически класс «колёса этой машины» стал появляться не сразу, а только когда машина «доросла» до класса «объект, у которого могут быть колёса» (до этого она могла не поддерживать интерфейс, позволяющий прикрутить колесо).
Получается, что класс не существует, пока конкретной машины нет; его можно получить, имея в своём распоряжении только экземпляр машины; но только при условии, что этот экземпляр это позволит. Чем не часть?
Класс в натуре — это просто группа. Класс — это математическое название такого объекта как группа. Если так проще, то можно говорить что наше описание включает в себя объекты, группы объектов, группы групп объектов. Теперь про создание объектов. Я очень признателен Вам за комментарий, но должен заметить один нюанс. Ссылка на класс созданная динамически, говорит нам о том, что Вы говорите о коде. Мой же кейс о коде ни слова.Попробуйте подумать о машине без терминов ООП, или терминов, описывающих код.
Без терминов ООП я думать не могу, потому что объекты, классы, интерфейсы и свойства объектов (предикаты) здесь явно присутствуют. А они и составляют ООП.
А «динамическое создание класса» мне понадобилось вот по какой причине. Априори не ясно, определяется ли класс однозначно своим описанием. И не может ли у нас возникнуть два класса «болтов М1 на данном складе», с возможностью приписать болт к тому или иному классу. В функциональной модели так, вроде бы, нельзя — функция «построения класса по описанию» вроде бы чистая. В процедурной модели ничто не мешает классам, созданным по одним и тем же параметрам в 16:23 и в 18:47 быть разными: поставили две коробки на одну и ту же полку, и на каждой написали M1 — и как их теперь различишь?
А «динамическое создание класса» мне понадобилось вот по какой причине. Априори не ясно, определяется ли класс однозначно своим описанием. И не может ли у нас возникнуть два класса «болтов М1 на данном складе», с возможностью приписать болт к тому или иному классу. В функциональной модели так, вроде бы, нельзя — функция «построения класса по описанию» вроде бы чистая. В процедурной модели ничто не мешает классам, созданным по одним и тем же параметрам в 16:23 и в 18:47 быть разными: поставили две коробки на одну и ту же полку, и на каждой написали M1 — и как их теперь различишь?
Надо наверно сказать, что мои статьи направлены на более точно определение места ООП в аналитике предметной области с переходом к критике процессного подхода. Я специально выбрасываю из своих рассуждений ООП, чтобы потом отмаппиться на него. Вы, вероятно, читали мою статью, в которой я критикую термины ООП. И это лишь маленький кусочек моей критики.
Теперь про вторую часть. Вы задали вопрос: два класса, или один? И как их различить? Та же задача стоит в реальных учетных программах. Мы спокойно можем учитывать как один, так и несколько классов одновременно. Например, две партии по миллион болтов. Мы их не сливаем вместе, а учитывает отдельно.
Теперь про вторую часть. Вы задали вопрос: два класса, или один? И как их различить? Та же задача стоит в реальных учетных программах. Мы спокойно можем учитывать как один, так и несколько классов одновременно. Например, две партии по миллион болтов. Мы их не сливаем вместе, а учитывает отдельно.
Я думаю, что если в модели правильно задано отношение часть-целое, то это невозможно. Иначе получится, что можно добавлять и изымать части индивида при этом не меняя его: удалил класс «колеса этой машины», а машина не изменилась. )
Объект действительно не знает ничего о своем составе. Есть объект, и есть отдельно от объекта — множество разнообразных конструкций объекта. каждая конструкция — отражение чьей-то точки зрения на объект. Объект ничего не знает о своей конструкции. Знает — конструкция. Поэтому машина не знает о классе своих колес. Но об этом классе знает конструкция. То есть некий субъект, в воображении которого существует эта конструкция.
Вопрос же был не про то, кто что знает, а про понимание отношения «часть-целое». Вопрос: может ли объект (конструкция) лишится некой своей части или приобрести еще одну часть и остаться тем же самым объектом — с неизмененной конструкцией?
связь такая: объект- конструкция объекта — часть конструкции. Между объектом и частью конструкции стоит промежуточный объект: конструкция объекта. Поэтому отношение между частью и целым есть между конструкцией объекта и его частью, но не между объектом и частью конструкции
Чего частью является объект «класс колес этого автомобиля»? Объекта или конструкции объекта?
если быть точным, то конструкции автомобиля, но не автомобиля. К сожалению. я сокращаю запись до «часть автомобиля». Это было сделано специально, чтобы не усложнять запись. Однако в полном варианте надо развязать объект и части его конструкции объектом под названием конструкция.
Хорошо, объект-класс есть часть конструкции автомобиля. Теперь попробуйте так определить отношение часть-целое, чтобы была возможна ситуация: части добавляются, части изымаются, а конструкция остается неизменной. Именно такую ситуацию мы имеем, когда объект-класс считаем частью.
допустим, у меня есть баллон с газом. Конструкция объекта: баллон и газ. Газ в данном контексте — это класс молекул, который не знает свои молекулы «в лицо». Пусть часть молекул улетучилась, а часть прибавилось. Газ об этом не узнал, потому что его макроскопическое состояние не изменилось. Так и с колесами машины. Пусть конструкция машины состоит из класса колес, который не знает свои колеса «в лицо». Пусть часть колес заменили на другие колеса. Ничего не изменилось и машина едет дальше на других колесах, но на том же классе колес.Том же классе, который не знает о своих колесах ничего, кроме их количества.
Проблема не в том, кто, что знает. У нас отдельно (!) есть класс колес и сами четыре колеса (индивида). Каждое колесо — это часть конструкции машины (индивида). Если я сниму одно колесо (часть), то конструкция (целое) изменится; поставлю на место — конструкция изменится. Любое изъятие и добавление частей к целому меняет конструкцию целого. Теперь добавим к конструкции класс «колеса машины», потом добавим класс «передние колеса», потом добавим класс «правые колеса» и т.д. Изменится от этого целое — конструкция машины?
Вы поставили вопрос о методе учета. Мы можем учитывать, или инвентаризировать наш мир разными способами с разной степенью детализации. Конструкция автомобиля может состоять из колес класса, из класса колес, или из классов колес. Вы в своих примерах приводите примеры из разных методов. Например, если Вы сняли колесо и конструкция это заметила, то конструкция состоит из этого колеса. Но конструкция могла не знать, какое колесо Вы сняли, а лишь счетчик колес изменил свое значение. Тогда конструкция не знает о колесе ничего. И тогда конструкция состоит из класса колес. Введение передних и задних колес просто разбивает класс колес на два подкласса.
Нет. Мой вопрос не про методы учета. Он про суть, смысл отношения «часть-целое». Давайте просто ответим на вопросы:
1. Что такое отношение часть-целое? какие условия должны соблюдаться, чтобы мы один объект посчитали частью другого объекта (целого)?
2. Подпадают ли отношения между объектом «класс колес автомобиля» и объектом «конструкция автомобиля» под отношения часть-целое?
Первый вопрос я задаю уже не первый раз — обратите на него внимание.
1. Что такое отношение часть-целое? какие условия должны соблюдаться, чтобы мы один объект посчитали частью другого объекта (целого)?
2. Подпадают ли отношения между объектом «класс колес автомобиля» и объектом «конструкция автомобиля» под отношения часть-целое?
Первый вопрос я задаю уже не первый раз — обратите на него внимание.
Что такое отношение часть-целое? какие условия должны соблюдаться, чтобы мы один объект посчитали частью другого объекта (целого)?
Отношение между целым и его частью устанавливает субъект «мы». Между объектом и его частями стоит еще один термин — конструкция. Конструкция — это субъективное мнение об устройстве объекта. Так что часть связана с объектом транзитом через субъекта, его точку зрения и конструкцию. Чтобы мы посчитали один объект частью другого, нам для этого надо иметь такую точку зрения, в которой это было бы возможно. Поскольку методов учета объектов у нас много, то можно поискать такую точку зрения, при которой один объект состоит из другого. Если мы находим такую точку зрения, то задача решена. Можно попытаться классифицировать популярные точки зрения, которые могли бы давать такое отношение между объектами, но я такую классификацию не делал.
Подпадают ли отношения между объектом «класс колес автомобиля» и объектом «конструкция автомобиля» под отношения часть-целое?
Мое мнение, что при определенной точки зрения такое возможно. Об этом моя статья. Я проверял этот тезис с учетчиками. Они не нашли противоречий в этом тезисе.
Я проверял этот тезис с учетчиками.Это сильный аргумент. )))
Жаль, что так и не удалось получить ответ на простой вопрос, что же такое отношение часть-целое. А без него любой ответ на второй вопрос не имеет смысла.
На мой взгляд, объект-класс принципиально не может быть частью объекта-индивид. Почему — объяснение было в комментариях.
Спасибо
Я знаю, что ограничение на отношение объект-класс существует во всех моделлерах. Но именно это ограничение не позволяет дать мне определение некоторых объектов нашего мира. Именно тех, в которых мы ничего не знаем об объектах, но зато знаем о классе объектов.
Да, это проблема. Ее надо озвучить, сформулировать. Найти решение. Но это решение, на мой взгляд, не должно приводить к конфликтам с существующими описаниями. Надо искать другую форму отношения между объектами — не целое-часть. Иначе весь смысл отношения часть-целое пропадает: ведь оно фиксирует именно тот момент, что добавление или изъятие части из целого меняет конструкцию целого. Если конструкция не меняется, то это уже не отношения целое-часть. А какое-то другое.
Давайте подробно. Есть класс колес. Есть автомобиль. Я говорю, что авто состоит из класса колес. Это значит, что авто связано с классом колес. Класс колес — это такой же объект учета, как и другие объекты. Пусть в нашем примере класс колес при замене колеса считается идентичным. Мы имеем право на такой метод учета, потому что я приводил пример с газом. Потеря молекул в нашем восприятии не меняет газ. В таком методе учета конструкция не заметит смены колеса, потому что метод учета не позволяет ей это сделать.
Я говорю, что авто состоит из класса колес.Как всегда надо начинать с терминологии. Что такое «состоит»? На сколько я понял, под «состоит» вы подразумеваете отношение часть-целое (класс есть часть автомобиля).
Объект А состоит из объекта Б означает, что Б есть часть А. Так? Теперь выясняем суть отношения часть-целое. Для нас достаточно выяснить выполняется ли тождество А (с Б)==А (без Б)? То есть останется ли объект-индивид А тождественным самому себе, если из него изъять одну из его частей Б? Или останется ли его конструкция неизменной? Думаю ответ вполне очевиден: А без некой своей части не тождественно А с этой частью. (В противном случае нам надо переписывать все существующие онтологии.)
Ну а теперь рассуждаем про объект-класс: сколько бы классов мы ни добавляли к объекту-индивиду, сколько бы ни удаляли — конструкция объекта не изменится. Вывод объект-класс не может считаться частью объекта-индивид, индивид не может состоять из классов.
И это не проблема способа учета и прочих точек зрения, а исключительно терминологическая проблема на уровне определения типа отношений «часть-целое».
Ну а теперь рассуждаем про объект-класс: сколько бы классов мы ни добавляли к объекту-индивиду, сколько бы ни удаляли — конструкция объекта не изменится
Если мы удалим из конструкции авто класс колес, то конструкция изменится. Поэтому класс колес — есть конструктивный элемент. Вот замена колеса в классе колес будет влиять или не влиять на класс в зависимости от метода учета. Я сказал, что наш метод учета говорит нам, что класс не изменился. Следовательно, замена колеса никак не повлияла на конструкцию авто с данной точки зрения. Точно также как замена масла в двигателе не влияет с Вашей точки зрения на конструкцию двигателя. Но кто-то может и не согласиться с этим, посчитав, что масло — есть существенная часть двигателя, требующая учета.
Если мы удалим из конструкции авто класс колес, то конструкция изменится.Класс существует либо у нас в голове или в виде информационного объекта. Если мы потеряете память или удалим класс из информационной системы, то с конструкцией машины ничего не произойдет. Но тут лучше думать не об удалении, а о добавлении: мы можем сколько угодно добавлять классов (места в авто, правые колеса плюс болты в кузове), именно классов, а не индивидов, при этом конструкция не изменится.
Следовательно, замена колеса никак не повлияла на конструкцию авто с данной точки зрения.Конечно, мы же проделываем две операции: удалили часть, вернули на место эту же честь. Что тут может изменится. Конструкция изменилась между этими операциями: удалили колесо — конструкция изменилась. А при удалении класса (а не индивидов) конструкция никак не может изменится.
И опять, причем тут учет? Речь идет о банальной проблеме отношения часть и целое. На уровне детских игрушек: отвалилась лапа — игрушка не целая. А какие бы операции с введением или удалением классов или форм учета никак не могут повлиять на целостность игрушки.
Если мы потеряете память или удалим класс из информационной системы, то с конструкцией машины ничего не произойдет
Произойдет, она исчезнет. Конструкцию придется делать снова. Это все равно, что увидеть инопланетный корабль, выглядящий как медуза. Опишите его конструкцию! Откуда Вам знать, из чего он состоит. Вы увидите одно, но на самом деле все было иначе. Нет описания, нет конструкции.
Произойдет, она исчезнет.А автомобиль (индивид — ведь именно о конкретном автомобиле вы писали), частью которого является класс так же исчезнет?
Зависит от того, исчезнут или нет знания о нем. Если останется кто-то, кто помнит, что это автомобиль, то автомобиль не исчезнет. Если не останутся, то может появиться новый объект. Этот объект будет обладать свойством летать и грукать. Я понятия не имею, что такое грукать, но для тех, кто выживет, это будет иметь вполне себе смысл. Надо только надлогать под блокс и эта хрень поднимется в воздух и загрукает. Поэтому те, кто останутся, будут думать, что это не автомобиль, это — машина времени, только она сломалась.
Или они будут считать, что это амулет, приносящий удачу. А колеса свинтят за ненадобностью)
Или они будут считать, что это амулет, приносящий удачу. А колеса свинтят за ненадобностью)
Понятно
ТовариСЧи, ну это же пиз… ц какой-то. Я прошу прощения у всех Хабро-Жителей за такие слова. Но других просто нет. Заминусуйте, если того «требует кодекс».
boldachev, восхищаюсь Вашим терпением, последовательностью в изложении аргументов и целеустремленностью.
Лично мне, как сама статья, так и комментарии ТС, как то:
напоминают старый анекдот:
Развод в Одессе.
Судья:
— Почему Вы с ней хотите развестись?
— Она меня не удовлетворяет.
Голос из зала:
— Подумаешь, пол-Одессы удовлетворяет, а его нет.
Отсюда и вопрос к maxstroy: При разработке каких систем (конкретно, пожалуйста, с примерами) Вы уперлись в принципиальную невозможность решить поставленную перед Вами задачу? И как предлагаемая Вами концепция позволила преодолеть эти трудности?
P.S.
Мне кажется, что Вы не в том положении, что бы задавать вопросы. Слушайте, слушайте, и еще раз слушайте. Каждое новое собеседование — это способ обнаружить пробелы в Ваших знаниях.
boldachev, восхищаюсь Вашим терпением, последовательностью в изложении аргументов и целеустремленностью.
Лично мне, как сама статья, так и комментарии ТС, как то:
Я знаю, что ограничение на отношение объект-класс существует во всех моделлерах. Но именно это ограничение не позволяет дать мне определение некоторых объектов нашего мира.
напоминают старый анекдот:
Развод в Одессе.
Судья:
— Почему Вы с ней хотите развестись?
— Она меня не удовлетворяет.
Голос из зала:
— Подумаешь, пол-Одессы удовлетворяет, а его нет.
Отсюда и вопрос к maxstroy: При разработке каких систем (конкретно, пожалуйста, с примерами) Вы уперлись в принципиальную невозможность решить поставленную перед Вами задачу? И как предлагаемая Вами концепция позволила преодолеть эти трудности?
P.S.
Устраиваясь на новую работу, я придумал новый вопрос для собеседования.
Мне кажется, что Вы не в том положении, что бы задавать вопросы. Слушайте, слушайте, и еще раз слушайте. Каждое новое собеседование — это способ обнаружить пробелы в Ваших знаниях.
Большинство людей достаточно прагматично относятся к знаниям. Мало, кто может объяснить простейшие конструкции, потому что им этого не надо в практической работе. Например, мало, кто может объяснить, почему для расчета площади прямоугольника надо ширину умножить на длину. как-то этот вопрос задали на форуме и оказалось, что никто не смог дать ответа. Я читал на днях стандарт ИСО 21500 и ужасался безграмотности их составителей. На каждом шагу нас поджидают неожиданности в виде жуткой неграмотности. Я не просто пишу сказки. Эти сказки проверены как минимум несколькими специалистами. Поэтому Вы можете относиться к ним скептически, но я не могу. Если я и делаю ошибки, то я очень рад, когда их находят, как сделал Александр. Но Вы пока просто поддались эмоциям. Хорошо, но непродуктивно.
Sign up to leave a comment.
Класс объектов или объекты класса?