Я не понимаю, о чем Вы говорите, потому что, если в природе нет объекта, у которого есть свойство, которое нам дано. как известное, то такого аналитика, который придумал такое свойство надо уволить, либо наоборот, наградить за новое открытие в области онтологии. В случае награждения надо быстро пойти и всем миром поискать объект, А если его не найдем, сказать, что наша парадигма дала трещину и требует пересмотра.
У ООП парадигмы нет. Она не заявлена. Есть онтологический фундамент — это стандарт MOF. Он (MOF) целиком воспроизводит парадигму Аристотеля насчет типов (ставит во главу угла описание при помощи атрибутов). В онтологическом стандарте ИСО 15926 нет атрибутов, кроме тех, которые признаны первичными: ИД, ИМЯ, Время создания, Время смерти. И еще что-то, что я, возможно, забыл. Больше никаких атрибутов! Эта парадигма построена на классах, а в классах нет атрибутов. Вы же в природе их не видите? Вот и в логической модели их нет.
Я говорю про ООП подход. Потому что проектировать при помощи ООП опасно, как я постоянно утверждаю. Это вызовет трансформацию сознания (В природе появятся наследование и полиморфизм).
Подход ООП нацелен на создание работающего кода на основе созданной модели предметной области. Подход ООП нацелен только на код, но не на предметную область. Если он целится в предметную область, то надо тут же маппить термины ООП на термины русского языка, что я и показал, как надо делать. И тот, кто это делает, должен обладать очень серьезными знаниями.
Пример я привел немного раньше. Приходит ко мне программист и говорит, что он создал класс. Как я, аналитик, должен перевести это на русский язык? Он создал описание типа объектов, на основе которого машина в процессе работы создаст объекты, устроенные определенным способом. Ни о предметной области, ни о классах объектов при этом программист нам не сообщил ничего. Это просто надо понимать.
Программист просит меня описать нечто. Я даю ему описание. А потом он приходит ко мне и говорит: я создал класс такой-то. Я должен уметь перевести на язык русский: он создал тип объектов, которые будут созданы в системе, и выглядеть эти объекты будут так.
Я не программист, я говорил об этом. Я не пользуюсь терминами ООП для моделирования домена. Это нормально, Но я бы не хотел, чтобы в домене употреблялись термины ООП. Класс слонов — это домен и там нет ни переменных, ни наследования, ни списков. Но мне кажется, не все это понимают
Если класс — набор объектов, обладающих общими свойствами, то Вы должны уточнить: класс объектов в системе, или в домене? Если в системе, то я не против такого определения. Только тогда синтаксис языка неверен, потому что класс в языке описывает структуру данных. а не класс объектов, созданных на основе этой структуры. Если в домене, то ООП не про домен
ООП можно назвать языком, но очень специфическим. Я не хочу навязывать программистам язык. Я лишь даю трактовку тем терминам, которые они употребляют в общепринятом смысле. Кроме того, я бы хотел разделить аналитиков и программистов. Все-таки аналитики работают с заказчиком, а у заказчика нет наследований и инкапсуляций. Зачем им эти термины?
Да, я с этим не спорю! Я именно это и имею ввиду, когда утверждаю, что ООП не надо тащить в предметную область. А те термины, что там употребляются, надо уметь сказать на русском языке. А если и тащить, то знать все камни
Спасибо. Для разработки программы в соответствии с логической моделью надо иметь специалиста, которых я нас нет в свободном доступе. Обучать пока — тоже не обучают(. Я даже на физтехе не нашел таких курсов, кроме курсов Левенчука, но они. если и рядом, то не о программировании. Язык, или фреймвокр спас бы ситуацию. Поэтому вопрос к тем, кто знает, что такое логическая модель и знает языки программирования: есть ли такие, которые позволяют построит логическую модель в коде, имея все контролки)
Я против применения терминов ООП к моделированию предметной области. Как только я слышу термин ООП про события, ли, процессы, то у меня возникает вопрос: понимает ли говорящий, что он говорит, или просто повторяет словарные шаблоны
Хотелось бы иметь такие язык программирования, платформу разработки, теорию БД, СУБД, которые позволили бы в „нативных“ для себя терминах реализовывать модель предметной области в терминах именно теории множеств.
Мне кажется, необходимость появления таких инструментов в мейнстриме давно уже назрела.
Я не программист, и не берусь судить о тех трудностях, которые программисты испытывают от множественности реализации. Но могу догадываться. Я сталкивался с тем, что программист начинает мыслить шаблонами. То есть у него мир сужается до одного «правильного» способа моделирования. Остальные по «веским» причинам он называет «неверными». Находится другой перец, который начинает с ним спорить. И начинается холивар, какой из способов реализации модели предметной области — лучше. Ни тот ни другой не понимают, что и тот и другой способ — одинаково верны, просто все зависит от контекста, его окружающего. И вот тут начинается головная боль. Поэтому я стараюсь разрабатывать модели максимально далекие от реализации. И хочу, чтобы программисты осознавали сам процесс переноса модели в код.
Давайте еще раз по-порядку. Мы говорили не про программирование, не про код, а про реальные объекты в реальном мире. Я говорил про ту машину, что стоит у меня под окнами. У нее есть колеса, у нее есть класс колес, и это не имеет отношения к программированию никакого. Мы говорим только о предметной области и только о ней. В ООП есть конструкции, которые моделируют эти объекты предметной области. И я утверждаю в статье, что классы реальных объектов в ООП моделируются при помощи типов. Но не при помощи классов. Это беда, потому что целое поколение программистов выросло, не различая эти понятия. Например, кто-то даже написал, что мы используем типизированные классы, или что-то в этом роде. К сожалению, это нам в институте не преподают.
И надо просто понять, что есть классы в природе. Класс слонов — он тот класс, объектов, который состоит из слонов, пасущихся в Африке. И этот класс был задолго до появления компьютеров. Его (класс) тогда изучали биологи.
Мы не в программировании находимся. Программисты пользуются исследованиями, сделанными аналитиком. А аналитик работает в предметной области и его модели в идеале не должны зависеть от той платформы, на которой будет писаться код. Есть две модели: концептуальная, (она вообще не про программирование) и физическая (вот она про код). Между ними (моделями) есть связь, о которой говорят много и много ее изучают, но эти модели разные
Это интересный вопрос. А существует ли класс слонов в природе. Если нет класса, то у какого объекта в природе мы можем указать такой параметр, как средняя высота слонов?
Я говорю про ООП подход. Потому что проектировать при помощи ООП опасно, как я постоянно утверждаю. Это вызовет трансформацию сознания (В природе появятся наследование и полиморфизм).
Подход ООП нацелен на создание работающего кода на основе созданной модели предметной области. Подход ООП нацелен только на код, но не на предметную область. Если он целится в предметную область, то надо тут же маппить термины ООП на термины русского языка, что я и показал, как надо делать. И тот, кто это делает, должен обладать очень серьезными знаниями.
Пример я привел немного раньше. Приходит ко мне программист и говорит, что он создал класс. Как я, аналитик, должен перевести это на русский язык? Он создал описание типа объектов, на основе которого машина в процессе работы создаст объекты, устроенные определенным способом. Ни о предметной области, ни о классах объектов при этом программист нам не сообщил ничего. Это просто надо понимать.
А давайте спросим vvagr: Есть ли такие языки?
И надо просто понять, что есть классы в природе. Класс слонов — он тот класс, объектов, который состоит из слонов, пасущихся в Африке. И этот класс был задолго до появления компьютеров. Его (класс) тогда изучали биологи.