Comments 222
Давайте, пожалуй, начнем с простого вопроса: что именно вы понимаете под ООП?
Вы сначала найдите это чужое описание, поймите его, поймите причины его возникновения и существования, а затем уже только начинайте критиковать (с предложением вариантов, улучшающих решение конкретных задач). Пока вы критикуете только собственное незнание терминов.
Можете начать с https://ru.wikipedia.org/wiki/Процесс_(информатика).
Программисты часто употребляют этот термин ["экземпляр этого процесса"]
Я вот не употребляю. И нигде, кроме как в дискуссиях с вами, его не слышал.
Так это и есть дискуссия с вами.
Ну или в стандартах OMG, да?
Ничего не могу сказать поэтому поводу, я не пользуюсь стандартами OMG.
Например, BPMN является частью UML.
Ээээ, правда?
Прямо вот главную страницу открываем и читаем:
The unified modelling language (UML) takes an object-oriented approach to the modeling of applications, while BPMN takes a process-oriented approach to modelling of systems. Where BPMN has a focus on business processes, the UML has a focus on software design and therefore the two are not competing notations but are different views on systems. The BPMN and the UML are compatible with each other.
Ладно, возьмем спеку — так там про это тоже ни слова.
(не то что бы это было важно для обсуждаемого вопроса, но просто показательно)
History of object-oriented methods and notation
BPMN явно в стандарт UML не входит, BPMN диаграммы, условно, можно разложить на UML.
lair же думает, что моделируя код, он моделирует предметную область
Спасибо, но нет. Я так не думаю — и нигде такого не писал, кстати.
для решаемых нами задач — это не важно
И я снова спрошу: кто эти "вы", которые решают какие-то задачи, и какие конкретно задачи "вы" решаете?
Поэтому бессмысленно обсуждать ограничения ООП
… но вы это постоянно зачем-то делаете.
Там нет нигде выражения "экземпляр этого процесса". Слово "Process" там используется как название типа сущностей. "Экземпляр определенного типа" это корректное выражение.
Я вам уже много чего сказал про типы и экземпляры. Лучше вы мне скажите.
Вот есть некоторый список действий "взять молоток, взять гвоздь, стучать по шляпке гвоздя пока он не зайдет в дерево на необходимую глубину". Я беру список, беру конкретный гвоздь и молоток, выполняю все действия следуя списку. Потом беру другой гвоздь и снова повторяю все действия.
Что в вашей терминологии здесь является процессом, что из них соответствует термину "забить гвоздь", и как называется другое понятие.
> Возможно, что для решения конкретной задачи нам все равно, какой из этих объектов использовать.
Возможно, что вопрос выбора объекта даже не ставится. Т.е., монеток-объектов в экономической задаче просто нет.
Два объекта имеют одинаковую стоимость, но не равны.
Это зависит от решаемой задачи.
(кстати, прекрасно описано у все того же Эванса, в рассуждениях о "сущностях" и "значениях")
Да. Если уж совсем точно следовать терминологии DDD, то оба они будут объектами-значениями, для которых нет понятия "один и тот же", потому что нет понятия "идентичность", есть только понятие "равенство".
Типичный пример, кстати, это "а давайте посчитаем количество употреблений каждого слова в тексте". В тексте "объект покупки и объект продажи" есть два слова "объект", которые, с точки зрения модели, построенной для задачи, считаются одним словом "объект", употребленным два раза.
Ответьте на вопрос, пожалуйста. И не вводите новых терминов наподобие "операция", вы говорили про процессы.
Какое отношение это имеет к вопросу? Там не надо определять, из чего состоит процесс. Просто скажите, как вы называете эти сущности.
Понятие "забить гвоздь" из вашего коммента это что? Инструкция или последовательность?
Инструкция — это типовой сценарий, последовательность это сценарий.
Так вот чтобы не путаться и не уточнять каждый раз, типовой это сценарий или нет (кстати, какой тогда?), и используют термин "экземпляр". А так как конкретный выполняемый экземпляр мало кого интересует (пришло миллион пользователей, выполнилось миллион процессов отдачи веб-страницы), то обычно рассматривают описание процесса (инструкция в вашем понимании), которое и называют для краткости просто "процесс".
Фразу "экземпляр этого процесса" обычно никто не использует, я просто предположил, что она могла бы означать, если вы услышали ее от кого-то из ваших программистов.
Процесс — это процесс, а регламент — это чертеж процесса. И никто не путает процесс и его чертеж.
Ну это банально не так.
"Процесс приема заявок состоит из" — имеется в виду (в ваших терминах) "регламент процесса приема заявок состоит из".
"В процессе приема заявок создается описание заявки" — имеется в виду, что каждый раз, когда принимают заявку, создается описание заявки.
"Вчера, в процессе приема заявок от Х, было создано описание заявки Y" — имеется в виду конкретная ситуация.
Повторюсь, в обыденной речи людям свойственно заменять общее и частное. "Никто не путает" только потому, что эта информация восстанавливается из контекста разговора.
Нет. Понятие "стул" (или "слон", "сосна", "забить гвоздь") обозначает некоторые общие свойства. И это не то же самое, что "чертеж стула". Спросите у двух людей, как они представляют себе стул, какой у него цвет? Вряд ли они вам опишут один и тот же конкретный стул.
А когда имеют в виду конкретный объект, говорят "вот этот стул", "вон та сосна". Обычно это понятно из контекста ("стул скрипит" = "этот стул скрипит", "собака друг человека" = "животные типа 'собака' друзья человека"). А если непонятно, люди задают уточняющие вопросы ("твоя собака или вообще?"). Поскольку компьютер или модель на бумаге понимать контекст не умеют, то надо использовать более точные термины — например, тип и экземпляр.
Вот для "обычного человека" нет разницы между "любая собака" и "тип собаки". Ну не нужно ему в обыденной жизни это разделение.
Спросите у двух людей, что такое "a chair". Вряд ли они вам опишут один и тот же конкретный "the chair", но в их описании будут некоторые общие свойства. Общие свойства — это тип.
Нет, чтобы не путаться, стул называют стулом, а чертеж, по которому сделали этот стул называют чертежом.
Кстати, если пойти в любой мебельный магазин, позиция "стул Х" будет обозначать тип стульев, а не конкретный стул.
Стул Икс будет означать любой стул из класса, а не тип стульев
Эти понятия, как я уже писал выше, в обыденном сознании взаимозаменимы. Причем взамозаменимы в понимании "тип стульев — это такая [...], характеристики которой применимы ко всем стульям этого типа".
В английском — артикль a означает любой объект данного типа, а не тип объектов
Кстати, нет. Не "любой", а "неопределенный".
Вы никогда "в миру" не слышали фразы "процесс регистрации документа состоит из..."?
То есть вы правда никогда не слышали приведенной мной фразы?
Я слышал эту фразу много раз, но каждый раз спрашивал: что вы имеете ввиду под термином процесс? Я насчитал более 30-ти разных смыслов этого термина и потому для меня эта фраза без определения понятия процесс выглядит бессмысленной.
Ну так зачем же вы теперь утверждаете, что "в миру процесс — это" и подсовываете что-то конкретное? Я вот больше одного раза слышал приведенную фразу, и каждый раз в ней имелся в виду "типовой процесс".
(а "регламентом процесса" у тех же людей называлась еще более третья, отдельная сущность, со своими развлечениями)
Это к тому, что людям вообще свойственно в (обыденной) речи заменять "тип" и "экземпляр" — как раз по метонимическому переносу "частное-общее" (точнее говоря, по синекдохе, но не важно). И те люди, которым по каким-то причинам надо отделять одно, от другого, придумывают разные способы борьбы. Кто-то — слово "instance". Кто-то — слово "тип". Кто-то — слово "прототип". И так далее, далее, далее. Нет никаких оснований говорить, что один способ правильнее другого.
Я не понимаю, что такое ООП в применении к моделированию предметных областей
… но продолжаете утверждать, что оно не может того и того. Как это вообще сочетается — вы что-то утверждаете о том, о чем — вы же — говорите, что не понимаете?
Но меня, как аналитика смущает.что программисты путают написание кода и моделирование предметных областей.
А программисты не путают. Может это вы что-то путаете?
Понятно, что код имеет отношение к предметной области, но какое — нам неведомо, потому что никто этого не знает и нигде нет этому описания.
Ну так вы почитайте того же Эванса, и вам станет "ведомо". Понимаете вот эти "мы", которым неведомо — это не мы, это вы. Вам неведомо. Но вы же не программист, почему вам вообще должно быть это понятно?
Проблемы, поднятые как серьезные — не так принципиальны практически. У вагона есть разные атрибуты габаритов и вместимости, как и у слона. Атрибуты всегда в жизни постулируются, а не извлекаются из непостулированного. Из-за этого атрибуты находятся в сложном взаимопорожденном отношении, зависимом от способа их определения. В мире нет безусловного сходства или безусловного различия, сходства и различия определяются критериями.
Стремление дать более удачные определения — похвальны. Нужно лишь помнить, что так рождается новая модель, конкурирующая с другими и не имеющая пока инженерного воплощения или хотя бы его спецификаций.
ООП — лишь спецификация к определенному кругу принципов, не являющихся даже теорией. Выстроить теорию на основе современных взглядов на онтологию — это круто.
Но, нужна принципиальность и строгость, а не частные рассуждения, претендующие на общность и глубину, которых в них пока нет.
Надеюсь, со временем, Вы свяжете эти идеи в теорию.
Предварительно нужно связать синтаксис этого языка с некоторой семантической моделью. Тогда программа на таком языке будет не просто «компьютер получил данные на вход, выполнил алгоритм, выплюнул выходные данные», а описанием (с доказательством!) некоторой сущности, которой придан смысл, семантика.
В текущей статье я определю следующие термины: объект, состояние, событие, операция, функция.
Каковы границы применимости ваших определений?
В качестве мета-метамодели для моделирования мы возьмем теорию множеств, а не MOF.
Я несколько раз прочитал всю статью, и не нашел в ней ни одного использования аппарата теории множеств. Сам термин "множество" используется, но в общеупотребительном смысле. Так что никакие свойства теории множеств (как то: математическая основа и границы применимости) на подход, описанный в посте, переносить нельзя. Но это так, ремарка на всякий случай.
В качестве примера такого ограничения можно представить себе моделирование высоты у объектов класса слон и объектов класса вагон. Эти два атрибута в [какой-то парадигме] никак не связаны между собой, поэтому понять, что слон поместится в вагон можно только, обратившись к программисту, создавшему эти атрибуты.
Давайте просто запомним этот пример, нам еще придется к нему вернуться.
Коль скоро мы определили объект как модель 4-объема в 4-пространстве
Это самое близкое к "определению" утверждение об объектах в этом посте. Итак, повторюсь: объект — это (субъективная) модель четырехмерного объема в четырехмерном пространстве.
Вернемся к задаче выше: у нас есть слон и вагон, нам надо понять, влезает ли слон в вагон. При их моделировании мы получаем объекты (для простоты считаем, что их временные координаты полностью совпадают, и дальше будем говорить о трехмерных объектах): объект "слон" и объект "вагон", у обоих этих объектов есть объемы.
Вспомним так же и другой тезис из поста: "принято считать объект плотным объектом, который не может одновременно пересекаться с другими объектами". Оба наших объекта, в терминологии автора, "плотные" — два вагона не могут находиться в одном объеме, два слона — тоже.
Первый подход: слон влезает в вагон, если все измерения его объема меньше, чем (соответствующие) измерения объема вагона. Это, однако, противоречит тезису про плотность: два плотных объекта не могут пересекаться в одном объеме.
Второй подход: попробуем смоделировать вагон более детально — т.е., как набор объектов (стены, двери, пол, потолок). В этом случае слон помещается в вагон, если измерения его объема меньше, чем… хм, чем разница таких-то координат составляющих объектов (иными словами, расстояние от пола до потолка и от стены до стены). Можно ли это понять, не обращаясь к "программисту, создавшему эти объекты"? Нет, поэтому этот подход имеет те же ограничения, что и описанные в п.2 в начале статьи (откуда и взят пример).
Третий подход: окей, давайте попробуем смоделировать вагон как вагон и пустое пространство в нем — т.е., два объекта, один "плотный", другой "рыхлый" (по терминологии автора поста). Теперь слон помещается в вагон в том случае, если измерения "слона" меньше, чем соответствующие измерения "пустого пространства", связанного с интересующим вагоном. Что получилось? Во-первых, нам понадобилось ввести понятие связи между объектами, во-вторых, эта логика тоже не вытекает из модели — опять возвращаемся к программисту.
(Ну и на самом деле, слон не влезает в этот вагон. Почему? Потому что там уже есть бегемот. Не забывайте уменьшать "пустое пространство" при каждом помещении в него "плотного" объекта.)
Ладно, чуть-чуть видоизменим задачу: у нас есть слон, массой X тонн, и вагон, рассчитанный на нагрузку в Y тонн (и ж/д путь, рассчитанный на нагрузку в Z тонн). Сможем ли мы довезти до точки назначения слона в вагоне (по пути)? Объекты, являющиеся моделями четырехмерного пространства, никак не помогут нам в ответе на этот вопрос. Опять надо идти к программисту.
Что получилось в итоге? Предлагаемое в статье определение объекта в общем случае не решает те проблемы, которые автор приводит как ограничения [других подходов].
Допустим, что есть множество моделей 4-объемов, или множество объектов. Эти модели хранятся у субъекта в сознании. Если эти модели похожи друг на друга, то субъект может создать модель этих моделей. Эта модель также хранится в сознании субъекта. Эта модель моделей и есть тип объектов.
Немедленно возникает вопрос: униформен ли предлагаемый автором подход? Иными словами:
- Является ли объект (модель четырехмерного объема) четырехмерным объемом? Как, следствие,
- Является ли тип объектов объектом?
Выглядит так, как если бы ответ на оба этих вопроса был "нет". В принципе, это логично: существующая в сознании модель не имеет измерений в четырехмерном пространстве (кроме единственной координаты "время начала существования"), поэтому ее модель не является объектом. Далее аналогично.
А теперь снова вернемся к слонам. У нас есть типы контейнеров (десяти-, двадцати- и сорокафутовые). То есть где-то, несомненно, существуют конкретные контейнеры каждого типа, но мы не владеем ни одним из них, поэтому для нас их нет. Нам надо выбрать, контейнер какого типа мы закажем, чтобы перевезти в нем нашего слона. Поскольку выше мы предположили, что тип объектов (в данном случае — тип контейнеров) не является объектом, мы не можем применять к нему те же подходы по ответу на вопрос "влезает ли слон в", которые мы (условно) успешно применяли к вагону. Какой подход здесь рекомендует применять автор?
Такое описание объекта соответствует описанию бизнес-функции, и говорят, что это функция по выпуску веников.
"Бизнес-функция" и "функция" — это одно и то же?
Бизнес-функция – это 4-х мерный объект,
Какова протяженность этого объекта во времени?
Бизнес-функция – это 4-х мерный объект, который имеет описание в виде набора типов событий с указанием плотности этих событий во времени
Скажем, "бизнес-функция" шредера — это превратить бумагу в мишуру. Продолжительность этого превращения с точки зрения наблюдателя, которого интересует эта бизнес-функция — не равна нулю, поэтому такое превращение — это не событие (напомню определение из поста: "событие — это изменение состояния объекта учета за столь короткое время, что наблюдатель считает это время равным нулю"). Что в этом случае будет типом (типами) событий, которые описывают эту бизнес-функцию, и какова их плотность во времени?
Или просто "превращение бумаги в мишуру" — это не бизнес-функция?
Или подойдем с другой стороны: какую задачу решает модель бизнес-функции?
Скажем, «бизнес-функция» шредера — это превратить бумагу в мишуру. Продолжительность этого превращения с точки зрения наблюдателя, которого интересует эта бизнес-функция — не равна нулю, поэтому такое превращение — это не событие (напомню определение из поста: «событие — это изменение состояния объекта учета за столь короткое время, что наблюдатель считает это время равным нулю»)
По словам автора, бизнес-функция — это «набор» типов событий с указанием плотности этих событий во времени. Если в мелких деталях разобрать каждую деталь механизма шредера, от валов, перемещающих бумагу, до лезвий, нарезающих ее, то можно вполне себе представить их теми самыми типами действий. Например вращение резинового вала, перемещающего бумагу, можно представить как стремящееся к бесконечному большому кол-ву мгновенных сдвигов на угол, стремящийся к бесконечно малому значению — что тоже стыкуется с «событием», которое «изменение состояние объекта за короткой время (бесконечно малое)». Короче говоря, весь шредер не может быть событием, но может состоять из бесконечного числа событий.
Модель шредера, состоящая из бесконечного числа событий, на мой взгляд, имеет бесконечно малую применимость.
При этом бумага до встречи со шредером находилась в одном состоянии, во время пережевывания — в соответствующем состоянии измельчения, а после — уже не существует вовсе (заменена множеством полосок).
А вот события в определении автора тут есть: включение и выключение шредера, они же начало уничтожения и прекращение существования соответственно для бумаги.
Это не решает других вопросов и даже добавляет: что делать с такими совокупными событиями? Являются ли они единым событием (маловероятно, ведь они показывают изменения совершенно разных состояний разных объектов) или жестко связанными различными событиями (тогда не помешало бы модели по отношениям событий).
BTW, вот один из подходов к решению задачи о слоне и вагоне:
IShippable elephant;
IShippingContainer carriage;
elephant.CouldBeShippedIn(carriage);
И это, заметим, модель конкретной предметной области.
В своей модели вы нагружаете слона некой семантикой (интерфейс IShippable), может ли слон быть отправлен в неком вагоне.
Но слон в силу своей природы не может знать, может ли он поместиться в тот или иной вагон.
И в динамическом языке при получении такого сообщения, объект "слон" возвратил бы ошибку.
В случае статического языка можно генерировать InvalidOperationException, а лучше вообще не добавлять такой интерфейс.
В данном случае подходит анемичная модель, когда есть слон с минимально-необходимым набором атрибутов (вес, габариты) и сервис, который по значению атрибутов может вычислить, уместится ли слон в вагон.
В своей модели вы нагружаете слона некой семантикой (интерфейс IShippable), может ли слон быть отправлен в неком вагоне.
Неа. Я нагружаю слона семантикой, что он вообще может быть куда-то отправлен (причем не обязательно, что эта семантика статична).
И в динамическом языке при получении такого сообщения, объект "слон" возвратил бы ошибку.
А кто вам сказал, что это сообщение получил именно слон?
В ООП есть термин наследование. Это инструмент моделирования иерархии тип-подтип. Это значит, что ООП построено на логике Аристотеля.
Этот вывод кажется мне странным. Разве любой инструмент моделирования иерархии тип-подтип обязан подчиняться логике Аристотеля?
Потому что это единственный на сегодняшний день известный способ моделирования, который имеет математическую основу, границы применимости которого нам хорошо известны, достаточно широки и обоснованы.
Ой ли? А классическая логика предикатов таковой не является? В конце концов, теория множеств — это частный случай логической теории. Тут правильнее было бы сказать «единственный известный мне способ».
Не кажется ли вам, что это по природе своей это разные вещи, и для изучения и моделирования их используются разные инструменты и описательные категории?
Я понимаю, что объем статьи таков, что в нее не удалось поместить все детали, но из имеющегося текста не удается восстановить ответы на эти вопросы.
Как в этом подходе смоделировать клиента с неизвестным на данный момент именем, который придет завтра в неизвестное время с неизвестной на данный момент целью?
Здесь опять торчат уши понятий «тип процессов» и «экземпляр этого типа процессов» (которые для краткости называют «тип процесса» и «экземпляр процесса»).
Модель клиента я описал, она задается типом «Клиент».
Модель регистрации нового клиента, задается типом процессов «Регистрация клиента», который представляет собой список действий, одно из которых это моделирование создания экземпляра типа «Клиент», и указание его конкретного имени.
Экземпляр типа процессов «Регистрация клиента» создается в момент прихода клиента. Экземпляр типа объектов «Клиент» с конкретным именем создается во время выполнения этого экземпляра процесса.
Поскольку на момент моделирования я имя клиента не знаю, да он и не пришел еще, то это моделирование будущих событий.
Кстати, раз уж я прояснил постановку задачи, то как в вашем подходе смоделировать эти «прошедшие» события и клиента в них?
Извините, но высказанная вами позиция делает невозможной разработку любой прикладной программной системы — потому что на момент составления требований всё, что эта система призвана автоматизировать, находится в будущем.
Вы же говорите о моделировании уже прошедших событий, когда мы знаем, что был клиент, что он пришел.
Как это он пришел, если он еще не пришел? Да ладно, прошедшие, будущие, не суть. Как с вашим подходом их смоделировать? Почему вы снова уходите от ответа?
Мы не можем смоделировать то, что завтра придет клиент, потому что может придет, а может не придет, может клиент, может не клиент…
А как тогда по-вашему работают заранее написанные программы? Они именно что моделируют будущие события. И да, вы снова путаете тип и экземпляр. Это экземпляр находится в будущем. Но задав тип, мы можем работать со всеми экземплярами такого типа.
… является комм тайной. Поэтому я рассказываю те условия, которые привели нас к этой модели, но саму модель я показывать не буду.
А, то есть практической ценности для других специалистов у нее нет. Ок.
Почему вы снова уходите от ответа?
Будущее неизвестно! Модель должна это учитывать. Если модель будущего этого не учитывает, она плохая модель. Мы моделируем вероятностное будущее. Это значит, что у нас клиент может прийти, может не прийти, может не клиент, может налоговик, не важно, потому что мы готовы ко всему. А, когда нам станет известно, кто пришел, вот тогда мы занесем это в модель. Но и то — мы же можем обмануться. Пришел, представился клиентом, а на самом деле налоговик. Мы тогда сможем переклассифицировать пришедшего в новый класс, и сделать новую интерпретацию прошедшим событиям. Я исчерпывающе ответил?
Я исчерпывающе ответил?
Нет. Была простая задача — сделать модель регистрации новых клиентов, чтобы программист мог написать по ней программу. Вместо трех строк с описанием модели вы написали кучу текста про прошлое и будущее, упомянув мимоходом, что это сложный случай для вашего подхода. Задачу вы не решили.
Как смоделировать клиента с неизвестным на данный момент именем, который придет завтра в неизвестное время с неизвестной на данный момент целью?
Если нужно решить задачу регистрации новых клиентов, то — это совсем другая задача.
Для этого регистрируется новой лицо, физическое, юридическое, предприниматель и проч… А затем указывается, что это лицо — клиент. Клиент одновременно может быть и поставщиком, не забываем про это. Но это простая задача регистрации, а не попытка смоделировать события будущего. Будущее, как я сказал, неизвестно, но вероятностно. Мы с какой-то вероятностью можем о нем рассуждать. И моделирование будущего — это моделирование вероятных исходов.
Для этого регистрируется новой лицо, физическое, юридическое, предприниматель и проч… А затем указывается, что это лицо — клиент.
Во-первых, вы переусложнили — нет никаких ФЛ, ЮЛ и ИП в задаче. А во-вторых, "регистрируется" где? В системе. Система написана без модели? Без требований? В ней нет внутренней модели (хотя бы на уровне БД)?
Клиент одновременно может быть и поставщиком, не забываем про это.
… особенно это круто для той системы, где вообще нет поставщиков.
Надо указать, как минимум, двух субъектов, чтобы понять, кто поставщик, а кто клиент. Как иначе?
Да легко. Если поставщиком выступает та организация, которая владеет/заказывает информационную систему, то этот субъект в ИС может существовать неявно.
Аналогично и с точкой зрения — она может быть единственной, и поэтому в модели явного выражения не иметь.
Я говорю про моделирование предметной области (про концептуальную модель
Всякая ли модель предметной области будет концептуальной?
а вы про информационную систему, которая воплощает эту модель (она моделируется физической моделью).
Кто "она"? Информационная система? Тогда я не понимаю, что вы называете физической моделью.
но для создания физической использование UML — обязательно, если мы кодим на ООП языках
При использовании ОО-языков использование UML необязательно.
Разведите по разные стороны моделирование предметной области и моделирование кода, тогда вам станет ясно, что мои модели не про код, а про предметную область
Код — он тоже про предметную область. И код — обычно — не моделируют.
Если нужно решить задачу регистрации новых клиентов, то — это совсем другая задача.
Я вас попросил об этом в следующем комменте, когда выяснилось, что у вас другое понимание исходной постановки. И понятие "новый клиент" подразумевает, что изначально мы не знаем его имени и цели обращения.
Так все-таки, вы сможете сделать модель для этой задачи? Фразы типа "Для регистрации клиента регистрируется лицо, а потом указывается что оно клиент" моделью не являются, так как и в левой и в правой частях используется понятие "регистрация". Как тогда смоделировать регистрацию физического лица?
А, когда нам станет известно, кто пришел, вот тогда мы занесем это в модель.
Мы это должны занести не в модель, а в информационную систему. Которая построена по модели. Для которой приход находится в далеком будущем.
Я занесу в модель, а будет ли ИС на этот момент, мне неизвестно. Я могу записать это на бумажке, на магнитофонной ленте голосом, не имеет значения.
На момент "кто пришел" вас уже не будет, система сдана заказчику. И по его требованиям заносить надо в ИС.
При чем тут ИС?
При том, что мы на хабрахабре.
Вы привязываетесь к ИС, как будто только с ее помощью можно моделировать предметную область.
ИС — обычно — используется не для моделирования предметной области, а для ее автоматизации.
Если не секрет, в теории множеств есть понятие "атрибут множества"?
Если не загоняться на тему математических извратов, то границей 4-х мерного объекта будет 3-х мерный объект.
С чего бы это? Разве что только для визуализации проще рассматривать 2 оси координат в декартовой системе координат, а 3-ю ось обозначить как время.
К примеру мерность объектов не имеет смысла сама по себе, зачем находить 4-х мерный объект для операции подтверждения покупки в интернет сайте? Любой бухгалтер запросто добавит вашему объекту несколько новых измерений, которые на поверку будут более бизнес-значимы чем ваша модель. А задача точно определить 4-х мерные координаты моего остатка на счету в банке может оказаться любопытной, но сложно-достижимой и уж точно эти знания не важны для пользования остатком.
Так что сначала ответьте на вопрос: “Зачем нужна новая методология и какие задачи она будет решать?” А из ответа на этот вопрос сами собою последуют определения объекта, события и всего остального.
на мой взгляд проблема заключается не в автоматизации управления чем-либо, с этим аналитики и программисты неплохо справляются. Проблема же в интеграции систем управления разных направлений (например, ERP, MES, SCADA, CAD, ...), так в них используются свои, несовместимые с другими, подходы к моделированию одних и тех же физических «объектов учета» (как называет их Марк). Универсальный подход, на мой взгляд, должен позволить объявить каждую из этих моделей частным случаем более общей модели, пусть даже сама универсальная модель будет иметь ограниченное применение для создания новых информационных систем. Если получится «отмапить» существующие модели (UML, BPMN, ...) на одну общую, то это позволит семантически «бесшовно» интегрировать данные из самых разных информационных систем.
Объекты имеют смысл только в рамках какой-либо задачи (или методологии решения конкретных типов задач). Абсолюта не существует (см. [нео/пост]позитивизм в научном методе).
Любая модель вносит свои “искажения” в представляемые данные, решать задачу интеграции построением некой новой “супермодели” спорная задача, так как супермодель уже существует — это наш реальный мир. В интеграционных задачах зачастую важно предавать между системами и методологиями только реальные данные, очищенные от трактовок различных подходов. Как правило, методика на входе имеет поток фактов, а на выходе получаются трактовки, при интеграции систем пытаются из трактовок восстановить поток исходных данных, дополнить его недостающими фактами (иногда даже домыслить их) и передать их другой системе. Основная проблема здесь, убедится что при передаче сами факты представлены адекватными переходными представлениями, которые строятся исходя из специфики каждой из систем и решаемой задачи интеграции.
Решать же задачу интеграции заочно в отсутствие самих субъектов слишком трудоёмко, так как предполагает фиксацию абсолютно всех доступных данных в неком представлении с минимумом искажений, то есть в трактовках максимально близких к природе самих данных. В то же время, люди придумывают методологии именно для того чтобы избавить себя от необходимости такой плотной фиксации, выделяя в потоке данных лишь значимые сведения. Случайное противоречие? Не думаю…
> семантически «бесшовно» интегрировать данные из самых разных информационных систем.
Я новичок в этой области, но вынужден в нее погружаться, поэтому простите за возможную наивность, но…
А нет ли ощущения, что упомянутая бесшовность просто в принципе невозможна?
Примерно в том же смысле, как невлияние наблюдателя на результат измерения в физике.
И откуда эта «шовность» берется?
Не из авторства ли, не из того, что модели пишутся людьми под определенные — индивидуальные по факту — цели, опираясь на индивидуальный же частный (дискретный) опыт в дискретном же (в виде предложений, слов, букв)?..
Вот, говорят, по тексту, описывающему одно и то же событие, можно опознать автора.
Как обстоят дела в моделировании мира — возможно здесь «отстроиться» от автора, его целей, опыта и т.д.?
Вы с какой частью не согласны?
И вам неоднократно писали, где вы не правы, и приводили примеры. Только вы их игнорируете и упорно продолжаете твердить одно и то же. Вы не знаете программирования, соответственно, это вы не можете смоделировать предметную область с помощью ООП. Это не значит, что ООП для моделирования не подходит.
Ну да. Вы просто пишете "ООП не может x и y" (или, что не менее весело, "в ООП так и так") но тех, кто с этим не согласен, "к диспуту не приглашаете". Прекрасная, прекрасная политика.
… а каждое публично высказанное мнение может быть обсуждено (публично или частно — второй вопрос).
был бы описан хотя бы терминологический аппарат ООП
… давайте начнем с ответа на вопрос "что вы понимаете под ООП".
Потому что то, что я читал — это аппарат описания кода, а не предметных областей.
Программа содержит в себе модель предметной области (качество ее оставим за скобками). Соответственно, парадигма, использованная для написания этой программы, была использована для создания модели предметной области.
И пока никто не дал мне ссылок на источники, в которых было бы сказано обратное
Вы Эванса уже прочитали? Ссылки на него вам давали неоднократно. Вот вам цитата:
Object-oriented programming is powerful because it is based on a modeling paradigm, and it provides implementations of the model constructs.
Меня не устраивает
Ну вот видите. Стоит вам дать ссылку, как вы немедленно ее игнорируете и переходите к тому, что лично вас не устраивает (не по ссылке, а вообще). Ну и какой смысл был просить ссылку?
наделение неживого возможностью что-то делать
А в этом тоже ООП виновато? Я думал, это мир таков.
подмена отношения тип-подтип на родитель- ребенок.
А это и вовсе что-то, что вы придумали. Нет, вы вольны придумывать себе что-то, что вас не устраивает, конечно.
а апофеозом стала путаница, когда вместо элемента класса стали говорить экземпляр класса
Не вижу никакой путаницы. Путаница возникает у тех, кто пытается одновременно использовать термины из нескольких областей знания, но кто же их заставляет это делать?
С таким количеством багов ничего смоделировать невозможно
Ну то есть программ не существует. Крутое мнение, да.
Понимаете ли, в чем дело… есть разница между "мне не нравится Х" и "Х не способно". Вы постоянно заменяете первое на второе.
Лично мне не нравится, потому что не способно.
Вот это "не способно" — это ваше ничем не подтвержденное утверждение.
Кому-то кажется, что солнце светит, а кому-то известно, что солнце не является живым организмом и не может светить.
Тем не менее, общеизвестен тот факт, что солнце светит. Ваши попытки утверждать, что это не так, выглядят, скажем так, странно.
Про то, откуда в наш язык пришли эти странные для нашего сегодняшнего мировосприятия вещи — из мистического сознания.
Раньше вы писали, что из мифологического (это не одно и то же). И нет, в мифологическом сознании это тоже не так.
Кстати, эти "странные" вещи странны лишь для вашего мировосприятия. Для мировосприятия обычного человека — включая филологов — ничего странного в этих вещах нет. Зато филологам очень странно, что трансформатор не может преобразовывать, но может быть участником. И вообще может.
Я об этом писал. И опять — игнор.
"Игнор" — это ваша реакция на аргументы к вашим постам о том, что солнце не может светить, хотя оно (и это очевидно) светит.
Вот я налил воду в кастрюлю, поставил кастрюлю на плиту, включил плиту. Вода закипела. Теперь докажите мне, что вода не может кипеть, хотя я своими глазами вижу, что она кипит, и любой находящийся на кухне человек согласен со мной в том, что она кипит.
BTW, нет никакой связи между "методы привязаны к объектам" и "солнце светит". Объект — это модель, и метод — это модель, и там могут быть любые соглашения, до тех пор, пока они приняты в модели.
Если бы вместо слова "class" в ООП использовалось слово "type", что-то бы принципиально изменилось?
Ни один программист пока не дал определение процесса, а также определение экземпляра.
Ну здрасьте-приехали.
Экземпляр класса (англ. instance) — это описание конкретного объекта в памяти. Класс описывает свойства и методы, которые будут доступны у объекта, построенного по описанию, заложенному в классе. Экземпляры используются для представления (моделирования) конкретных сущностей реального мира.
Инстанцирование (англ. instantiation) — создание экземпляра класса.
(слово "класс" заменяйте на слово "тип", а не на слово "множество", ибо такая терминология)
Множественные экземпляры (multiple instances) действия показывают, что одно действие выполняется многократно, по одному разу для каждого объекта. Например, для каждого объекта в заказе клиента выполняется один экземпляр действия. Экземпляры действия могут выполняться параллельно или последовательно.
A Process can be executed or performed many times, but each time is expected to follow the steps laid out in the Process model. For example, the Process in Figure 10.1 will occur every Friday, but each instance is expected to perform Task “Receive Issue List”, then Task “Review Issue List”, and so on, as specified in the model.
A Process is instantiated when one of its Start Event soccurs. Each occurrence of a Start Event creates a new Process instance.
https://habrahabr.ru/post/319442/#comment_10012614
https://habrahabr.ru/post/319032/#comment_10001142
https://habrahabr.ru/post/319032/#comment_10000466
https://habrahabr.ru/post/319032/#comment_10000372
Это ссылки только на мои комменты, а вам на ваши ошибки указывали многие.
Да, вы говорите об объектах, создаваемых в памяти компьютера
Если создавать объекты в памяти компьютера, соответствующие объектам некоторой пространственно-временной области, то получится модель этой области. И BPMN это все-таки не про компьютеры.
отличной от моделирования кода
При написании программы код не моделируется. Он пишется, то есть создается. В коде задана модель предметной области и некоторых технических объектов, необходимых для работоспособности программы.
Действия не могут выполняться многократно.
Вы снова путаете тип и экземпляр. Причем упорно не желаете это признавать.
Поэтому экземпляр процесса не моделирует экземпляр действия, но моделирует действие.
Экземпляр не может ничего моделировать. Экземпляр это уже конкретное воплощение. И вообще, он же не живое существо.
А еще мастер участка говорит "резец режет", хотя резец, очевидно, неодушевленный, и не может резать. Но в одном случае вам его словоупотребление авторитетно, а в другом — нет.
Действия не могут выполняться многократно
Это ваше личное мнение.
ТМ (или ТП) тоже не годится для передачи наших ощущений.
ООП перепутало классы и типы. То, что называется типами у Аристотеля, в ООП назвали классами
Есть ОО-языки, где путаницы с терминами в части названия типов данных нет.
Например, современный Visual Basic — являющийся по сути, тем же C#, но с синтаксисом Basic:
Data Type Summary (Visual Basic)
Любой тип данных — это тип данных.
И от того, что он является ссылочным (экземпляры размещаются в куче) или его экземпляры размещаются на стеке, он не перестает быть типом данных, и не превращается в класс или структуру.
Если в описании увидите слово class — из контекста сразу будет видно, что это проведение соответствия между ссылочным типом VB (reference data type) и ссылочным типом исполняющей среды (там это по-прежнему называется "класс").
а то, что математики называют классами, в ООП не имеет названия
Скорее, есть определенная недосказанность.
Если то, что математики называют классами это множество, то множества в ОО-нужно соответственно моделировать, создавая тип данных, описывающий множество.
В общем случае алгоритм создания типа данных "Множество":
- Создается тип данных (в терминах большинства языков — класс) "Множество" с добавлением необходимых атрибутов и операций для этого множества (в зависимости от предметной области).
- Тип данных "Множество" должен инкапсулировать в себе данные — поле, указывающее непосредственно на множество объектов.
В качестве типа данных для такого поля лучше выбрать один из многочисленных типов данных для работы с множествами, которые есть во всех современных платформах — хеш-таблицы (ближе всего к понятию "множество"), словари, многочисленные виды списков ("просто" списоки, связные списки, etc), очереди FIFI/LIFO, и даже обычные массивы.
Ментальная ловушка «хочу формализовать всё, что возможно во вселенной, даже чего мы пока не знаем» приводит к попыткам формализовать процесс формализации (к попыткам моделировать мышление человека), что получается пока не очень
Пытаясь в очередной раз вникнуть в ООП, прочёл книгу «Software Factories: Assembling Applications with Patterns, Frameworks, Models & Tools», где во вступительных главах описываются слои абстракции от предметной области к железу, и почему UML не позволит аналитикам с менеджерами создавать нормальный код без программистов.
Или Вы пытаетесь создать инструмент для универсальной модели бизнеса? Так получается тоже нечто странное, плодятся божественные объекты, менеджеры менеджеров и фабрики фабрик. Люди пытаются всё распихать по объектам-существительным, и отказываются выносить действия в отдельные сущности.
Если удастся создать некоторый единый обобщенный подход к описанию мира, то будет отлично, но поскольку на естесственных языках такого до сих пор не случилось, я не верю, что такое в принципе возможно, если не использовать
А это точно их задача?
(а) это не задача программистов
(б) кому не хочется калечиться об UML, могут его не использовать
(ц) есть прекрасная книга Вигерса о том, как писать требования, и которая UML только упоминает мимоходом
А вообще, конечно, "подходящий для аналитиков язык" давно придумали. И это, в большей части случаев, их родной язык (оставшиеся случаи — это ситуации, когда надо писать, скажем, на общем языке команды, английском, например). Ну да, этот язык формализуется и ограничивается для уменьшения неоднозначностей, но он уже есть. И это работает.
А когда я слышу ваши "термины", мне тоже много чего хочется спросить — и я спрашиваю, — но вы тоже не даете определений (начиная с определения "ООП"). Ну и в чем разница?
И вообще, в русском языке нет термина "процесс", есть только слово "процесс". Термином оно становится, оказавшись в конкретной системе.
предметную область сначала переваривают а потом результат моделируют и это слабо похоже на исходный предмет.
Тем не менее, получившийся результат все еще является моделью предметной области. А то, что модель не похожа на то, по чему она строилась, так это (в зависимости от цели моделирования) нормально...
зачастую «ООП» понятие не имеет о предметной области, в исходниках нету классов покупатель и товар, а есть рекорсеты с полями и правила отношений между ними
Эмм. Во-первых, то, что вы описываете (рекордсеты и отношения) — это не то ООП, которое описывает автор поста (описанные им недостатки просто не совмещаются с вашим описанием).
Во-вторых, что важнее, это все равно модель предметной области.
Давайте на минуту отойдем от ООП и посмотрим на реляционную базу данных. В ней как раз есть наборы записей (с колонками-атрибутами) и отношения между записями. Модель ли это предметной области? Конечно (более того, я видел много аналитиков, которые других моделей и не умели строить). Просто это не объектно-ориентированная модель (в обычном понимании объектно-ориентированности), ну так никто же и не требовал.
А теперь давайте вернемся в код из вашего примера. В нем та же самая модель, просто реализованная не средствами реляционной БД, а средствами ОО-языка. И что? Модель от этого изменилась? Да нет.
Так что, хотя это и контринтуитивно, но объектно-ориентированная программа может содержать не-объектно-ориентированную модель предметной области.
Ну и в-третьих, я описанного вами подхода к программированию не видел лет восемь, если не больше. У него есть недостатки, они описаны больше десяти лет назад (это только те книги, которые я лично читал, а скорее всего — и давнее), и люди перестают им пользоваться.
а так как речь идет о времени появления ООП
Э, где? Я думал, речь идет о текущем состоянии дел.
(не говоря уже о том, что и "во время появления" ситуация тоже была… другой)
Рекордсеты я привел в пример как производная отличается непосредственной предметной области.
перечитайте начало, Автор именно рассматривает ООП на уровне «основных понятий» из вики,
Автор вообще отказывается сказать, что именно он называет ООП. Я склонен думать, что это обособленные одиночные пикеты, если честно.
Рекордсеты я привел в пример как производная отличается непосредственной предметной области.
Любая модель предметной области отличается от предметной области, так что я не понимаю, на основании чего вы утверждаете, что ООП не нужно использовать для моделирования предметной области.
А что такое "непосредственное моделирование"?
например у Автора действия над объектом жестко транслируются в методы класса (смутно припоминаю что в теории (не ООП) так принято, хотя могу врать)
перенос предметной области в код как есть, без каких либо обобщений\изменений
Это в общем случае невозможно (вне зависимости от выбранной парадигмы разработки и моделирования); какой смысл это вообще обсуждать и упоминать?
Не "Автор", а вы пишете, что "ООП можно использовать для моделирования, но не нужно". Так вот, для "непосредственного моделирования" (в вашем понимании), ООП использовать нельзя, потому что эта задача не имеет решения.
(автор, кстати, утверждает, что он пишет не про код, а про моделирование предметных областей, а код тут ну вообще ни при чем)
Ну и неплохо было бы помнить программистам, что код они пишут для машины и код — это описание процессов, происходящих внутри ВМ, а не в предметной области, так что зря они себя тешат иллюзией о том, что они моделируют предметную область.
То что ООПешников не могут понять предметники это явно не их проблема, это проблема организации работ, т.е. рядовая ситуация, ООПешники как раз прекрасно понимают птичий язык предметников, и если все таки это переходит в ряд серьезных проблем то по вине предметников не желающих сотрудничать, как-то так.
Ну и неплохо было бы помнить программистам, что код они пишут для машины и код — это описание процессов, происходящих внутри ВМ, а не в предметной области, так что зря они себя тешат иллюзией о том, что они моделируют предметную область.
:), Вы так написали как будто программисты спят и видят как они моделируют предметную область, это не так, как раз наоборот, они мечтают максимально отдалится от нее, создать максимально универсальные решения, что-то вроде «Теории Всего» программирования и отдать полученные инструменты предметникам, дабы не слушать их птичий язык.
Сначала ввело свои собственные термины, но из слов, похожих на те, которыми пользуются предметники
С равным успехом про предметников можно сказать, что они ввели собственные термины из слов, похожих на те, которыми пользуются обычные люди. Профессиональный жаргон, вот это все.
Если ООПэшник сказал «экземпляр процесса», то на русском языке — это план-график работ. Если он сказал «процесс», то это на русском языке — регламент.
Не "на русском", а "на вашем". Вы почему-то считаете, что выбранная вами терминология корректна и универсальна, хотя вам неоднократно показывали, что это не так.
Ну и неплохо было бы помнить программистам, что код они пишут для машины и код — это описание процессов, происходящих внутри ВМ, а не в предметной области
Код — не описание процессов, происходящих внутри машины (как уже неоднократно говорилось, вы не программист, и не понимаете в программировании, и это очередная иллюстрация).
зря они себя тешат иллюзией о том, что они моделируют предметную область.
Угу. Попробуйте формально доказать утверждение "ни одна программа не содержит модели предметной области".
Не было ли таких попыток?
Во-вторых, как соотносится теорема Гёделя со сводом законов? Мы же не пытаемся опереть их сами на себя, мы используем более сложную математику для верификации. Математики давно уже пережили этот шок и способны двигаться дальше, заниматься интересными вещами и находить новые законы. Печально, что многие школьники, не разбираясь особо даже в существе вопроса, используют теорему Гёделя как индульгенцию для того, чтобы забросить математику. «Если абсолютная строгость не достижима, то зачем математика нужна». Нужна. Она приносит и практическую пользу и эстетическое наслаждение.
В-третьих, можно вспомнить о другой полноте — имени Тьюринга. Которая не мешает существованию различных верификаторов программного кода. Да, есть множественные ограничения на использование. Но хоть какие-то автоматические проверки лучше чем совсем ничего, даёт больше уверенности.
Но всё это никогда будет применено на практике. Потому что простой люд полагает компьютер чем-то магическим. «Я ничего не делал — оно само случилось». Мало до кого доходит, что компьютер безжалостен как природа и делает в точности то, что ему приказал человек. Но люди не готовы брать на себя ответственность. Они предпочитают думать, что внутри компьютера живут волшебные гномики, а разве можно доверять гномикам?
С другой стороны чиновники тоже в недоумении. Где у компьютерного алгоритма верификации находится купюроприёмник? Как заносить ему взятки? Хотя попытки подкупить компьютер — это всё равно что попытки отменить законодательно физику. Она работать будет в любом случае, безотносительно желания человека
Совсем недавно нам поступил запрос именно на такую работу — создание верифицированной модели в области законодательства. Это нормально и возможно. Правда, это касается нормативных отраслевых актов, но лиха беда начало.
Я тоже об этом думал, но попыток не нашёл. Это требует серьёзного развития канцелярита, как минимум — появления официально одобренного словаря терминов (всех без исключния слов, встречающихся в текстах законов), а потом нужно переписать законы так, чтобы они читались и толковались единственным способом. В реальном мире это сильно ограничит применимость законов, так что навряд ли кто-то займётся.
Например, здесь — https://github.com/RinkeHoekstra/lkif-core
Строгое определение понятий: объект, состояние, событие, бизнес-операция и бизнес- функция