Здравствуйте, ferrata, Вы писали:
F>Hello, All!
F>Вот занимаюсь субжем, "Мультипарадигменное проектирование..". F>В главе 1.2.2 (Проектирование, стр.21) встречаю фразу: F>
F>Это известный подвох объектно-ориентированных методов — допущение, что классы, выведенные в результате анализа, точно отразятся в классах C++.
F>Что за известный подвох? О чем это он? Где почитать?
Да везде.
Практически в любой книге, где затрагиваются вопросы моделирования подчеркивается то, что нарисовав модель предметной области вы еще не имеете классы. Мне очень нравится аналогия с моделированием БД. ER модель — это еще далеко не модель базы данных, там нет суррогатных ключей, ХП.
Ларман. Применение UML и шаблонов проектирования. Глава 10, модель предметной области: визуализация понятий, стр 148
Основная идея
Модель предметной области представляет классы понятий реального мира, а не программные компоненты. Это не набор диаграмм, описывающих программные классы или программные объекты с их обязанностями.
Собственно там несколько глав говорится именно о предметных областях
Фаулер. UML. Основы, второе издание, Глава 4 стр 67
Следуя сказанному Стивом Куком (Steve Cook) и Джоном Дэниелсом (John Daniels), 1994 [13], я утверждаю, что существуют три различные точки зрения на построение диаграмм классов или любой другой модели, однако эти различия в наибольшей степени касаются диаграмм классов:
• Концептуальная точка зрения. Если рассматривать диаграммы классов с концептуальной точки зрения, то они служат для представления понятий изучаемой предметной области. Эти понятия, естественно, будут соответствовать реализующим их классам, однако такое прямое соответствие зачастую отсутствует. В действительности, концептуальная модель может иметь весьма слабое отношение или вообще не иметь никакого отношения к реализующему ее программному обеспечению, поэтому ее можно рассматривать независимо от языка программирования. (Кук и Дэниеле называют такую точку зрения первичной).
• Точка зрения спецификации. В этом случае мы переходим к рассмотрению программной системы, при этом рассматриваем только ее интерфейсы, но не реализацию. Объектно-ориентированная разработка подчеркивает существенное различие между интерфейсом и реализацией, но на практике оно часто игнорируется, поскольку нотация класса в объектно-ориентированных языках программирования объединяет в себе как интерфейс, так и реализацию. Это весьма досадно, поскольку ключевым фактором эффективного объектно-ориентированного программирования является программирование именно интерфейса класса, а не его реализации. Это хорошо описано в первой главе книги Гаммы и др., 1995 [20]. Вы часто слышите слово «тип», когда речь идет об интерфейсе класса; тип может иметь несколько классов, которые его реализуют, а класс может реализовывать несколько типов.
• Точка зрения реализации. С этой точки зрения мы действительно имеем дело с классами, опустившись на уровень реализации. Эта точка зрения, вероятно, встречается наиболее часто, однако во многих ситуациях точка зрения спецификации является более предпочтительной для аналитика.
Понимание точки зрения разработчика крайне важно как для построения, так и для чтения диаграмм классов. К сожалению, различия между отмеченными особенностями представления не столь отчетливы, и большинство разработчиков при построении диаграмм смешивают различные точки зрения. Я полагаю, что часто не имеет большого значения различие между концептуальной точкой зрения и точкой зрения спецификации, и гораздо важнее различать особенности представления с точки зрения спецификации и реализации.
Здравствуйте, ferrata, Вы писали:
F>Это известный подвох объектно-ориентированных методов — допущение, что классы, выведенные в результате анализа, точно отразятся в классах C++.
F>Что за известный подвох? О чем это он? Где почитать?
Это значит, что в "жизни", у тебя квадрат — частный случай прямоугольника, а при реализации наследования всё будет наобороот: ты унаследуешь прям. от квадрата, чтобы добавить поле "высота". Ну это примерно всё, реально прям. и квадрат не должны быть на разных уровнях иерархии.
Здравствуйте, qbit, Вы писали:
Q>Здравствуйте, ferrata, Вы писали:
F>>Это известный подвох объектно-ориентированных методов — допущение, что классы, выведенные в результате анализа, точно отразятся в классах C++.
F>>Что за известный подвох? О чем это он? Где почитать?
Q>Это значит, что в "жизни", у тебя квадрат — частный случай прямоугольника, а при реализации наследования всё будет наобороот: ты унаследуешь прям. от квадрата, чтобы добавить поле "высота".
Это довольно брутальный тип наследования, куда более брутальный чем наследовать квадрат от прямоугальника.
Лучше и квадрат и прямоугольник вообще не связывать отношением наследования.
Имхо в статье какой-то бред. Автор зачем-то мешает вместе тодель предметной области и модель реализации, диаграмму классов и диаграмму объектов...
Пример с запуском двух экземпляров приложения вообще какой-то смешной...
Читал из этого списка Лармана. Когда читал возникло резкое несогласие с товарищем Ларманом. Не удобно, конечно, как-то таких людей обвинять в непонимании, но, по-моему, он плохо понимает суть ООА/ООД/ООП.
Они говорят, что есть 2 (а по Фаулеру аж 3) различных модели (модель предметной области и модель класс, которые присутствуют в программе) и что существует некий нетривиальный переход от одной модели к другой.
В корне не согласен, что это модели разные. Основной принцип ООА/ООД/ООП — делай классы в программе такие как в жизни! А они говорят, что вот мы разобрались как всё в жизни, а теперь напишем другие классы в программе.
А суть, по-моему, в том, что эти 2 представления (по Фаулеру 3) относятся к одной модели, только составлены на разных уровнях детализации. Просто в модели реализации добавлены дополнительные подробности в ту же модель предметной области. "За" говорит тот факт, что преобразования между этими моделями взаимнооднозначные (насколько помню у Лармана так).
Естественно, что класс, который составил аналитик с заказчиком, отличается от класса написанного программистом. С их стороны просто наивно так думать. Конечно там добавляются хотя бы, к примеру, конструктор/деструктор, которых естественно нет в модели предметной области.
В общем, лохи они. Составление 2 (3) моделей — лажа. Надо одну модель составить, а потом её детализировать до нужного уровня.
Здравствуйте, remark, Вы писали:
R>Здравствуйте, Andy Panda, Вы писали:
R>Читал из этого списка Лармана. Когда читал возникло резкое несогласие с товарищем Ларманом. Не удобно, конечно, как-то таких людей обвинять в непонимании, но, по-моему, он плохо понимает суть ООА/ООД/ООП.
[] R>В общем, лохи они. Составление 2 (3) моделей — лажа. Надо одну модель составить, а потом её детализировать до нужного уровня.
Не согласен!
В процессе анализа строится модеь AS-IS (как есть), описывающая существующие положение дел в автоматизируемой предметной области...
А при проектировании строится модель TO-BE (как должно быть), описывающая собственно проект. Так что моджели все же разные... По крайней мере — две... Если совпадает — это большая удача...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, remark, Вы писали:
R>... Основной принцип ООА/ООД/ООП — делай классы в программе такие как в жизни! ...
К этому надо стремиться, но в действительности не получается.
Интересно, где бы в жизни ты смог найти то, для чего нужен какой-нибудь SelectionProviderMediator или TreeHierarchyLayoutProblemsDecorator.
И ты не сможешь их получить в результате детализации предметной диаграммы, т.к. они результат взаимодействия программных, а не предметных сущностей.
Только не говори, что они в программе не нужны — нужны!
Просто если речь идет об уровне примитивой складской программы или редакторе фигурок, тогда диаграммы предметной области наверное достаточно.
Но я бы посмотрел как ты написал компилятор таким способом.
Здравствуйте, remark, Вы писали:
R>В корне не согласен, что это модели разные. Основной принцип ООА/ООД/ООП — делай классы в программе такие как в жизни!
И в этом ООА/ООД ошибаются. Хотя сейчас сторонники ООА/ООД отходят от этой концепции, убедившись в том, что она неверна. И пытаются сказать, что люди просто не понимают истинного смысла ООА/ООД. А на самом деле — это просто ООА/ООД подход в корне неверен.
Никогда не надо выводить классов из объектов реального мира.
Здравствуйте, remark, Вы писали:
R>Имхо в статье какой-то бред. Автор зачем-то мешает вместе тодель предметной области и модель реализации, диаграмму классов и диаграмму объектов... R>Пример с запуском двух экземпляров приложения вообще какой-то смешной...
Что-то очень похоже на паттерны "bridge" + "decorator" (для разделения иерархий объектов предметной области и объектов-проксей доступа к ним). А вообще идея правильная, только автор некорректные определения использует. Имхо.
R>
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Здравствуйте, LaptevVV, Вы писали:
LVV>Здравствуйте, remark, Вы писали:
R>>Здравствуйте, Andy Panda, Вы писали:
R>>Читал из этого списка Лармана. Когда читал возникло резкое несогласие с товарищем Ларманом. Не удобно, конечно, как-то таких людей обвинять в непонимании, но, по-моему, он плохо понимает суть ООА/ООД/ООП.
LVV>[] R>>В общем, лохи они. Составление 2 (3) моделей — лажа. Надо одну модель составить, а потом её детализировать до нужного уровня.
LVV>Не согласен! LVV>В процессе анализа строится модеь AS-IS (как есть), описывающая существующие положение дел в автоматизируемой предметной области... LVV>А при проектировании строится модель TO-BE (как должно быть), описывающая собственно проект. Так что моджели все же разные... По крайней мере — две... Если совпадает — это большая удача...
Ты имеешь в виду рефакторинг бизнес процессов при автоматизации или нет?
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Здравствуйте, remark, Вы писали:
R>>В корне не согласен, что это модели разные. Основной принцип ООА/ООД/ООП — делай классы в программе такие как в жизни!
КЛ>И в этом ООА/ООД ошибаются. Хотя сейчас сторонники ООА/ООД отходят от этой концепции, убедившись в том, что она неверна. И пытаются сказать, что люди просто не понимают истинного смысла ООА/ООД. А на самом деле — это просто ООА/ООД подход в корне неверен.
КЛ>Никогда не надо выводить классов из объектов реального мира.
Почему? Можно поподробнее.
Я считаю, зачем фантазировать. Если нафантазировать что-то оторванное от реальности, то тогда будет (1) непонятно, (2) поведение будет криво отражаться на код, (3) требования будут криво отражаться на код, (4) добавление элементарных требований может приводить необходимости непомерных изменений в программе.
Здравствуйте, ewro, Вы писали:
E>Здравствуйте, remark, Вы писали:
R>>... Основной принцип ООА/ООД/ООП — делай классы в программе такие как в жизни! ...
E>К этому надо стремиться, но в действительности не получается. E>Интересно, где бы в жизни ты смог найти то, для чего нужен какой-нибудь SelectionProviderMediator или TreeHierarchyLayoutProblemsDecorator. E>И ты не сможешь их получить в результате детализации предметной диаграммы, т.к. они результат взаимодействия программных, а не предметных сущностей. E>Только не говори, что они в программе не нужны — нужны!
E>Просто если речь идет об уровне примитивой складской программы или редакторе фигурок, тогда диаграммы предметной области наверное достаточно. E>Но я бы посмотрел как ты написал компилятор таким способом.
Тут я считаю так. В любой программе есть 2 предметных области: 1. предметная область связанная с функциональность программы (медицина/страхование/торговря) и её модель (куда входят как раз все эти Покупатель/Ордер/Счёт) и 2. предметная область т.с. самой программы (и вот сюда относятся все эти SelectionProviderMediator и TreeHierarchyLayoutProblemsDecorator).
Попробую аргументировать. К любой программе предъявляются требования не только функциональные, но так же связанные с другими атрибутами — готовность/надёжность/производительность, в конце концов она должна просто запускаться.
Можно дать заказчику ряд объектных файлов с точными определениями классов его предметной области. Но это наверное не то, что он хочет, если он даже запустить это не может.
А вот когда мы реализуем вторую часть (связанную с предметной областью самой программы), вот тут и появляются классы типы SelectionProviderMediator, которые некоторых пугают тем, что их не было в изначальной диаграмме, которую составил аналитик.
Можно даже взять пример попроще SelectionProviderMediator, например какой-то диалог. Очевидно, что класса диалога нет в диаграмме аналитика. Но очевидно, что если есть требование по отображению/вводу информации, то в программе необходим класс диалога.
И эти классы не надо никоим боком пытаться приплести к модели предметной области (где Покупатель/Ордер/Счёт).
Вот эти 2 модели есть. Согласен. Их как раз надо чётко разделять.
А вот того, что есть 2 модели предметной области (одна, которую составил аналитик, а вторая, которую составил программист) я не признаю.
Здравствуйте, remark, Вы писали:
КЛ>>Никогда не надо выводить классов из объектов реального мира.
R>Почему? Можно поподробнее. R>Я считаю, зачем фантазировать. Если нафантазировать что-то оторванное от реальности, то тогда будет (1) непонятно, (2) поведение будет криво отражаться на код, (3) требования будут криво отражаться на код, (4) добавление элементарных требований может приводить необходимости непомерных изменений в программе.
Вообще я с тобой согласен.
Но вообще всего должно быть в меру, нигде не надо лезть в крайности. С одной стороны объектная модель должна хотя бы отчасти отражать реальный мир и быть понятной для программиста, с другой стороны можно столкнуться с такими, задачами, где отображение 1 в 1 попросту невозможно. А если и возможно, то совершенно непрактично и бессмысленно. Нерасширяемо, плохопроизводительно и т.п., в-общем нужно отдавать себе отчет, что иногда можно сделать по-другому, а не затачиваться копированием объектов реального мира.
Часто еще приводится пример с падающей в лужу каплей воды и расходящимися после этого волнами, который очень трудно адекватно отобразить в программной объектной модели. Здесь: Re[4]: OOP Is Much Better in Theory Than in Practice
Здравствуйте, ekamaloff, Вы писали:
E>Здравствуйте, remark, Вы писали:
КЛ>>>Никогда не надо выводить классов из объектов реального мира.
R>>Почему? Можно поподробнее. R>>Я считаю, зачем фантазировать. Если нафантазировать что-то оторванное от реальности, то тогда будет (1) непонятно, (2) поведение будет криво отражаться на код, (3) требования будут криво отражаться на код, (4) добавление элементарных требований может приводить необходимости непомерных изменений в программе.
E>Вообще я с тобой согласен.
E>Но вообще всего должно быть в меру, нигде не надо лезть в крайности. С одной стороны объектная модель должна хотя бы отчасти отражать реальный мир и быть понятной для программиста, с другой стороны можно столкнуться с такими, задачами, где отображение 1 в 1 попросту невозможно. А если и возможно, то совершенно непрактично и бессмысленно. Нерасширяемо, плохопроизводительно и т.п., в-общем нужно отдавать себе отчет, что иногда можно сделать по-другому, а не затачиваться копированием объектов реального мира.
E>Часто еще приводится пример с падающей в лужу каплей воды и расходящимися после этого волнами, который очень трудно адекватно отобразить в программной объектной модели. Здесь: Re[4]: OOP Is Much Better in Theory Than in Practice
и ниже по ветке было обсуждение похожей темы. И вообще в философии программирования этот вопрос очень часто затрагивается
ООП как и любая другая технология имеет свою область применения. Она не везде хороша, это очевидно, иногда лучше подходит структурное/функциональное/сентенсиальное/автоматное программирование.
Если решать задачу задачу визуализации в контексте лужи с помощью ООП, то надо спуститься до уровня мельчайших частиц и лучей (или как там такие задачи решаются). Да, так говорит ООП. Да, возможно это решение не будет удовлетворять с т.з. производительности. Но, кстати, с концептуальной т.з. оно возможно будет вполне красивым.
Глупо ругать ООП, путаясь натянуть его за уши на то, для чего оно совершенно не предназначено.
По поводу перврого абзаца. Это не относится к ООП. Точно так же и при структурном программировании может быть красивая единообразная структура программы, а для обработки одного единственного очень большого потока данных для обеспечения производительности может применятся совершенно выбивающаяся из структуры "кривая" конструкция, но зато обеспечивающая максимальное быстродействие.
Это вопрос более высокого порядка, что такие атрибуты качества как, например, целостность и модифицируемость могут придти в несоответствие с производительностью.
Здравствуйте, remark, Вы писали:
R>Да, возможно это решение не будет удовлетворять с т.з. производительности. Но, кстати, с концептуальной т.з. оно возможно будет вполне красивым.
Зачем нам это надо, чтобы оно было красивым? Есть такое требование к ПО? Оно для начало просто должно работать. И если оно не удовлетворяет каким-то предъявляемым изначально требованиям, значит это вовсе не решение.
R>Глупо ругать ООП, путаясь натянуть его за уши на то, для чего оно совершенно не предназначено.
Для чего оно предназначено и где об этом написано? Насколько я его понимаю это не более чем подход, применяемый в программировании. Есть вполне конкретная задача — смоделировать процесс расхождения волн от падающей капли. Что, именно эту задачу не надо решать с применением ООП? ООП должно быть, просто не надо тупо копировать объекты реального мира, без абстракций в данной задаче не обойтись.
R>По поводу перврого абзаца. Это не относится к ООП. Точно так же и при структурном программировании может быть красивая единообразная структура программы, а для обработки одного единственного очень большого потока данных для обеспечения производительности может применятся совершенно выбивающаяся из структуры "кривая" конструкция, но зато обеспечивающая максимальное быстродействие.
R>Это вопрос более высокого порядка, что такие атрибуты качества как, например, целостность и модифицируемость могут придти в несоответствие с производительностью.
Тут ничего не понял.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
It is always bad to give advices, but you will be never forgiven for a good one.
Oscar Wilde
Здравствуйте, ekamaloff, Вы писали:
E>Здравствуйте, remark, Вы писали:
R>>Да, возможно это решение не будет удовлетворять с т.з. производительности. Но, кстати, с концептуальной т.з. оно возможно будет вполне красивым.
E>Зачем нам это надо, чтобы оно было красивым? Есть такое требование к ПО? Оно для начало просто должно работать. И если оно не удовлетворяет каким-то предъявляемым изначально требованиям, значит это вовсе не решение.
Под "красивостью" я имел в виду такие вещи как концептуальную целостность, понятность, сопровождаемость, модифицируемость.
R>>Глупо ругать ООП, путаясь натянуть его за уши на то, для чего оно совершенно не предназначено.
E>Для чего оно предназначено и где об этом написано? Насколько я его понимаю это не более чем подход, применяемый в программировании. Есть вполне конкретная задача — смоделировать процесс расхождения волн от падающей капли. Что, именно эту задачу не надо решать с применением ООП? ООП должно быть, просто не надо тупо копировать объекты реального мира, без абстракций в данной задаче не обойтись.
Да, именно так. Некоторые задачи не надо решать с помощью ООП.
Для некоторых задач лучше подходит, например, функциональное программирование и соотв. декомпозиция.
R>>По поводу перврого абзаца. Это не относится к ООП. Точно так же и при структурном программировании может быть красивая единообразная структура программы, а для обработки одного единственного очень большого потока данных для обеспечения производительности может применятся совершенно выбивающаяся из структуры "кривая" конструкция, но зато обеспечивающая максимальное быстродействие.
R>>Это вопрос более высокого порядка, что такие атрибуты качества как, например, целостность и модифицируемость могут придти в несоответствие с производительностью.
E>Тут ничего не понял.
Ты написал:
С одной стороны объектная модель должна хотя бы отчасти отражать реальный мир и быть понятной для программиста, с другой стороны можно столкнуться с такими, задачами, где отображение 1 в 1 попросту невозможно. А если и возможно, то совершенно непрактично и бессмысленно. Нерасширяемо, плохопроизводительно и т.п.,
Я говорю, что это проблема не ООП и отображения "1 к 1". Это проблема в конфликте между разными требования (сопровождаемостью и производительностью, например). Она может встать в точно в таком же виде при применении структурного программирования, и тебе тоже придётся прибешать к "некрасивым" решениям.
При этом, если убрать, требование по производительности, то ООП и отображение "1 к 1" может дать очень хороший результат.
Т.о. я бы так описал приведённый тобой пример: для удовлетворения нефункциональных требований приходится отходить от ООП.
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Здравствуйте, remark, Вы писали:
КЛ>>>Никогда не надо выводить классов из объектов реального мира.
R>>Почему? Можно поподробнее.
КЛ>На этот вопрос дан детальный ответ в этой статье: http://www.triz-ri.ru/themes/method/creative/creative57.asp
В целом согласен с автором, только пришет уж большо сложно и через одно место.
И это ни как не подрывает моей уверенности в том, что программные сущности надо выводить из сущностей реального мира. Точнее не из реального мира, а из предметной области.
Вот тут похоже у многих людей кроется большое недопонимание, чем отличается реальный мир от предметной области. Причём автор статьи тоже плохо понимает разницу. отсюда и все вопросы.
Здравствуйте, remark, Вы писали:
R>В целом согласен с автором, только пришет уж большо сложно и через одно место.
У статьи два автора. Один из них — Ваш покорный слуга.
R>Вот тут похоже у многих людей кроется большое недопонимание, чем отличается реальный мир от предметной области. Причём автор статьи тоже плохо понимает разницу. отсюда и все вопросы.
Здравствуйте, remark, Вы писали:
R>Т.о. я бы так описал приведённый тобой пример: для удовлетворения нефункциональных требований приходится отходить от ООП.
Это смотря что ты понимаешь под термином OOП
Вообще есть два подхода. Первый подход — делается статическая диаграмма и на нее навешиваются действия. Ессно при этом статика преобразуется сообразно задаче. Другой подход — делается динамика и уже с помощью нее создаются статические классы. Первый подход в основном уже не используется(разве что крутыми базоведами ). Такой подход привести к ошибкам, хотя теоретически и тот и другой подход сходимы и должны привести к одной модели. Аналитик на выходе не обязан давать диаграмму сущностей предметной области. На выходе у него должны быть прецеденты, то есть сценарии работы пользователей вместе с системой. И на основе этих действий, классы(не важно, с состоянием или без) выводятся более детерменировано чем в обратном случае.
Основная проблема моделей в том, что естественные сущности слишком сложны, и их просто невозможно реализовать в рамках компьютера и человеческого мозга. А задача программиста реализовывать конкретные действия а не сущности. Как верно заметил LaptevVV, модель TO-BE существенно отличается от модели AS-IS.
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Здравствуйте, remark, Вы писали:
R>>В целом согласен с автором, только пришет уж большо сложно и через одно место.
КЛ>У статьи два автора. Один из них — Ваш покорный слуга.
R>>Вот тут похоже у многих людей кроется большое недопонимание, чем отличается реальный мир от предметной области. Причём автор статьи тоже плохо понимает разницу. отсюда и все вопросы.
КЛ>Поясните, пожалуйста, на примерах.
Ооопс... Прошу сильно не обижаться за моё имхо.
Мысль эту я бы выразил так. Диаграмма классов строится по модели предметной области. Реальный мир никогда не порождает модель предметной области. Модель предметной области порождает реальный мир и решаемая задача. При чём решаемая задача может "выделять" из реального мира далеко не тривиальные вещи. Сущности и их признаки, которые остаются от реального мира в предметной области, могут далеко не соответствовать общечеловеческим представлениям о сущностях и их признаках, которые есть в реальном мире.
Ещё я бы к этому добавил, что процесс порождения модели предметной области по реальному миру и задаче есть один из наиболее сложных, нетривиальных и творческих в ООП.
Вот это я бы назвал первичным. От этого надо плясать. Тогда всё встаёт на свои места.
Исходя из таких мыслей, становится видно, что даже не то что бы примеры, приводимые в статье, неправильны, а то, что при их построении изначально неправильный подход. Отсюда и возникают проблемы при попытках запрограммировать на основе такой декомпозиции.
Как я понял в статье похожие мысли. Там проскакивает слово "контекст", я так понимаю это контекст задачи.
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, remark, Вы писали:
R>>Т.о. я бы так описал приведённый тобой пример: для удовлетворения нефункциональных требований приходится отходить от ООП. GZ>Это смотря что ты понимаешь под термином OOП GZ>Вообще есть два подхода. Первый подход — делается статическая диаграмма и на нее навешиваются действия. Ессно при этом статика преобразуется сообразно задаче. Другой подход — делается динамика и уже с помощью нее создаются статические классы. Первый подход в основном уже не используется(разве что крутыми базоведами ). Такой подход привести к ошибкам, хотя теоретически и тот и другой подход сходимы и должны привести к одной модели. Аналитик на выходе не обязан давать диаграмму сущностей предметной области. На выходе у него должны быть прецеденты, то есть сценарии работы пользователей вместе с системой. И на основе этих действий, классы(не важно, с состоянием или без) выводятся более детерменировано чем в обратном случае. GZ>Основная проблема моделей в том, что естественные сущности слишком сложны, и их просто невозможно реализовать в рамках компьютера и человеческого мозга. А задача программиста реализовывать конкретные действия а не сущности. Как верно заметил LaptevVV, модель TO-BE существенно отличается от модели AS-IS.
.
Кто пытается строить систему исходя из реального мира, я считаю, не понимает основы ООД/ООП. Все строится на основе модели предметной области, а она значительно проще.
Здравствуйте, remark, Вы писали:
R>Ещё я бы к этому добавил, что процесс порождения модели предметной области по реальному миру и задаче есть один из наиболее сложных, нетривиальных и творческих в ООП.
Попробую изложить свой подход. Мне представляется, что любая программа разрабатывается ради функционала. Т.е. в первую очередь, при проектировании следует рассматривать функции, а не "объекты реального мира" или объекты предметной области. Если программист разрабатывает систему для авоматизации бизнес-процесса, то в первую очередь он должен составить схему этого бизнес-процесса на бумаге. Если схема кривая и/или "глючная", то ее исправить. Потому что "глюки" на бумаге обернутся гораздо большими "глюками" в софте.
К сожалению, классики ООП мало говорят о функционале и рекомендут с самого начала строить объектную модель. (Прошу не путать со структурной схемой в системном анализе и ФСА, которую рекомендуется строить по ходу анализа.) При чем в ранних публикациях ООП-классики на полном серьезе говорили о том, что построенная диаграмма классов один в один проецируется в код. Через некоторое время "классики" говорить о том, что в ходе анализа могут быть выявлены еще и другие классы, которых не видно было в начале, и диаграмма будет пополняться. Сейчас они уже говорят, что на основе построенной схемы не нужно писать код, и классы в коде могут быть совсем другими.
На мой взгляд, такое изменение точки зрения "классиков" говорит не столько о том, что это это программисты не понимают суть ООД, а скорее это сам подход ООД непавльный.
R>Исходя из таких мыслей, становится видно, что даже не то что бы примеры, приводимые в статье, неправильны, а то, что при их построении изначально неправильный подход. Отсюда и возникают проблемы при попытках запрограммировать на основе такой декомпозиции.
Мне кажется, что все-таки это не примеры неправильные, а подход разработчика, продемонстрированный в этих примерах, неправильный.
Здравствуйте, ferrata, Вы писали:
F>Что за известный подвох? О чем это он? Где почитать?
Подвох в том, что модель предметной области и модель реализации, как правило, суть разные модели. Особенно в случае сложных систем. Попытки использования модели предметной области в качестве модели реализации ни к чему хорошему не приводят.
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Здравствуйте, remark, Вы писали:
R>>Ещё я бы к этому добавил, что процесс порождения модели предметной области по реальному миру и задаче есть один из наиболее сложных, нетривиальных и творческих в ООП.
КЛ>Попробую изложить свой подход. Мне представляется, что любая программа разрабатывается ради функционала. Т.е. в первую очередь, при проектировании следует рассматривать функции, а не "объекты реального мира" или объекты предметной области.
В целом согласен. Но я бы это назвал так: надо рассматривать "объекты реального мира" через призму решаемой задачи. Я хочу подчеркнуть, что компонента должно быть именно 2: "объекты реального мира" и решаемая задача (я так понимаю, что это аналог того, что ты называешь "функции"). Я бы не стал какой-либо из них выделять на первое место. И так же считаю невозможным выкинуть какой-либо из них.
Ошибка того как подают ООД — всё внимание концентрируют на первом компоненте, при этом второй задвигают или не упоминают. Мне кажется это абсурдным.
Подход разработчика к ООА/ООД, который приводятся в статье (например первый со столом), можно перефразировать так: заведите 5-летнего ребёнка в комнату, покажите ему стол, и спросите, из чего он состоит. Далее то, что он назовёт, отразите на классы программы. Конечно, ничего хорошего не получится, конечно, нужно не так.
КЛ>Если программист разрабатывает систему для авоматизации бизнес-процесса, то в первую очередь он должен составить схему этого бизнес-процесса на бумаге. Если схема кривая и/или "глючная", то ее исправить. Потому что "глюки" на бумаге обернутся гораздо большими "глюками" в софте.
Разьве схема бизнес-процессов не есть схема предметной области, не есть отражение реального мира?
КЛ>К сожалению, классики ООП мало говорят о функционале и рекомендут с самого начала строить объектную модель. (Прошу не путать со структурной схемой в системном анализе и ФСА, которую рекомендуется строить по ходу анализа.) При чем в ранних публикациях ООП-классики на полном серьезе говорили о том, что построенная диаграмма классов один в один проецируется в код. Через некоторое время "классики" говорить о том, что в ходе анализа могут быть выявлены еще и другие классы, которых не видно было в начале, и диаграмма будет пополняться. Сейчас они уже говорят, что на основе построенной схемы не нужно писать код, и классы в коде могут быть совсем другими.
Опять же. Если смотреть на реальный мир через призму решаемой задачи, то сразу некоторые "классы" и "объекты" могут исчезнуть, некоторые могут появиться или "всплыть" на первый план, вообще классы могут группироваться совсем по другому признаку (например, экскаватор и шариковая ручка могут неожиданно стать экземплярами одного класса ).
КЛ>На мой взгляд, такое изменение точки зрения "классиков" говорит не столько о том, что это это программисты не понимают суть ООД, а скорее это сам подход ООД непавльный.
У меня, конечно, нет 30 лет опыта за плечами, но я [пока] не пришёл к такой мысли
R>>Исходя из таких мыслей, становится видно, что даже не то что бы примеры, приводимые в статье, неправильны, а то, что при их построении изначально неправильный подход. Отсюда и возникают проблемы при попытках запрограммировать на основе такой декомпозиции.
КЛ>Мне кажется, что все-таки это не примеры неправильные, а подход разработчика, продемонстрированный в этих примерах, неправильный.
Здравствуйте, remark, Вы писали:
R>Мысль эту я бы выразил так. Диаграмма классов строится по модели предметной области. Реальный мир никогда не порождает модель предметной области. Модель предметной области порождает реальный мир и решаемая задача. При чём решаемая задача может "выделять" из реального мира далеко не тривиальные вещи. Сущности и их признаки, которые остаются от реального мира в предметной области, могут далеко не соответствовать общечеловеческим представлениям о сущностях и их признаках, которые есть в реальном мире.
R>Ещё я бы к этому добавил, что процесс порождения модели предметной области по реальному миру и задаче есть один из наиболее сложных, нетривиальных и творческих в ООП.
Ну, я не знаю точно, что такое "предметная область". Но мое интуитивное понимание "предметной области" таково, что из прямая модель "предметной области" никогда не отобразится в код сколь-нибудь предсказуемым образом.
Ну вот на простом примере:
— Реальный мир: строительство здания. Тут дохрена всяких подробностей: люди, машины, рельеф местности, чертежи, стройматериалы, поставки, опоздания, ошибки...
— Предметная область "строительство". Это некоторая модель реального мира. В ней, как правило, есть некоторый документооборот. Появляются "табели", "проекты", "договора", "активы" и т.п.
И вот в этот момент мы начинаем автоматизировать эту предметную область. Тут есть опять же два этапа:
1. Сначала мы документируем ту часть предметной области, которая нам нужна. Шансов, что мы полностью покроем предметную область нашим моделированием — 0%. Она проще, чем реальный мир, но все еще слишком сложна.
2. Затем мы придумываем то, как будет устроен автоматизированный процесс.
Это — принципиальный момент. Важно понимать, что наблюдаем мы неавтоматизированную деятельность, но мы не пытаемся тупо воспроизвести ее в машине. Мы собираемся изменить процесс, и одно это влияет на то, какой код мы напишем. В оригинальной предметной области не было таймаутов соединения и секурити логов. Просто потому, что там не было никаких соединений, и администрирование софта не входило в бизнес процессы.
3. Теперь мы моделируем этот автоматизированный процесс.
Тут могут появиться сущности, косвенно связанные с исходной предметной областью. Например, будет какой-то класс, объект которого описывает реальный "мешок цемента". Вряд ли он опишет цвет мешка и запах нагретой солнцем бумаги. Возможно, этот объект будет содержать марку, вес, срок годности, цену и т.п.
С другой стороны, у нас появится объект "диалог свойств партии товара", который не соответствует ничему из оригинальной предметной области. Мы только что изобрели новую предметную область, в которой на равне с мешками цемента фигурирут "диалоги", "экраны", "кнопки" и прочие элементы.
4. Даже сущности и отношения, обнаруженные нами на предыдущем этапе, зачастую не станут напрямую отображаться в код. Для каких-то сущностей потребуется вводить отдельные классы, каким-то хватит определенного значения признака. Реализация потребует каких-то своих потрошков. К примеру, "Пул коннектов к СУБД" не присутствует ни в модели исходной предметной области, ни в модели автоматизированного процесса. Он есть только там, внутри, и появляется как результат решения творческой задачи.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, qbit, Вы писали:
Q>Это значит, что в "жизни", у тебя квадрат — частный случай прямоугольника, а при реализации наследования всё будет наобороот: ты унаследуешь прям. от квадрата, чтобы добавить поле "высота". Ну это примерно всё, реально прям. и квадрат не должны быть на разных уровнях иерархии.
За такие "наследования" по рукам бить надо. Клавиатурой.
В результате подобных архитектуных изысков и получается, что функция, желающая указатель на квадрат, получает указатель на прямоугольник и абсолютно некорректно с ним работает, ибо (совершенно обоснованно, вот в чём фикус!) полагает, что имеет дело с квадратом — четырёхугольником с 90-градусными углами и равными сторонами.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, remark, Вы писали:
R>>Мысль эту я бы выразил так. Диаграмма классов строится по модели предметной области. Реальный мир никогда не порождает модель предметной области. Модель предметной области порождает реальный мир и решаемая задача. При чём решаемая задача может "выделять" из реального мира далеко не тривиальные вещи. Сущности и их признаки, которые остаются от реального мира в предметной области, могут далеко не соответствовать общечеловеческим представлениям о сущностях и их признаках, которые есть в реальном мире.
R>>Ещё я бы к этому добавил, что процесс порождения модели предметной области по реальному миру и задаче есть один из наиболее сложных, нетривиальных и творческих в ООП. S>Ну, я не знаю точно, что такое "предметная область". Но мое интуитивное понимание "предметной области" таково, что из прямая модель "предметной области" никогда не отобразится в код сколь-нибудь предсказуемым образом.
Предметная область — часть реального мира, интересующая нас в контексте решения некой конкретной задачи.
S>Ну вот на простом примере: S>- Реальный мир: строительство здания. Тут дохрена всяких подробностей: люди, машины, рельеф местности, чертежи, стройматериалы, поставки, опоздания, ошибки... S>- Предметная область "строительство". Это некоторая модель реального мира. В ней, как правило, есть некоторый документооборот. Появляются "табели", "проекты", "договора", "активы" и т.п.
Нет. Не так. В предметной области есть только то, что интересует нас в контексте решения нашей конкретной задачи.
S>И вот в этот момент мы начинаем автоматизировать эту предметную область. Тут есть опять же два этапа: S>1. Сначала мы документируем ту часть предметной области, которая нам нужна. Шансов, что мы полностью покроем предметную область нашим моделированием — 0%. Она проще, чем реальный мир, но все еще слишком сложна.
Предметная область — это и есть то, что нам нужно!
Т.е. образом мы имеем покрытие 100%. По определению.
S>2. Затем мы придумываем то, как будет устроен автоматизированный процесс. S>Это — принципиальный момент. Важно понимать, что наблюдаем мы неавтоматизированную деятельность, но мы не пытаемся тупо воспроизвести ее в машине. Мы собираемся изменить процесс, и одно это влияет на то, какой код мы напишем.
BPR — это уже совсем другая история. Пока я рассматривал всё так, как будто процессы мы менять не собираемся.
S> В оригинальной предметной области не было таймаутов соединения и секурити логов. Просто потому, что там не было никаких соединений, и администрирование софта не входило в бизнес процессы.
По моим опнятиям таймауты и логи никак не должны повлиять на БП и на работу персонала.
S>3. Теперь мы моделируем этот автоматизированный процесс. S>Тут могут появиться сущности, косвенно связанные с исходной предметной областью. Например, будет какой-то класс, объект которого описывает реальный "мешок цемента". Вряд ли он опишет цвет мешка и запах нагретой солнцем бумаги. Возможно, этот объект будет содержать марку, вес, срок годности, цену и т.п.
Если при решении данной задачи нам не нужно знать цвет мешка, то зачем даже пытаться его хранить? Цвет мешка должен уйти при переходе от реального мира к модели предметной области.
S>С другой стороны, у нас появится объект "диалог свойств партии товара", который не соответствует ничему из оригинальной предметной области. Мы только что изобрели новую предметную область, в которой на равне с мешками цемента фигурирут "диалоги", "экраны", "кнопки" и прочие элементы.
Я писал выше, в любой программе есть 2 предметной области: предметная область решаемой задчи и предметная область самой программы.
Не надо их пытаться как-либо соединить. Зачем вы пытаетесь соединить воедино документооборот строительства и технологию построения программных систем? По любому ООП тут совсем ни при чём. Никакая технология декомпозиции/анализа не даст при анализе документооборота строительства ничего связанного с диалогами и пулингом соединений с БД.
Все эти сущности появляются при удовлетворении нефункциональных требований к системе. Они перпендикулярны.
S>4. Даже сущности и отношения, обнаруженные нами на предыдущем этапе, зачастую не станут напрямую отображаться в код. Для каких-то сущностей потребуется вводить отдельные классы, каким-то хватит определенного значения признака. Реализация потребует каких-то своих потрошков.
Это касается детализации модели.
S>К примеру, "Пул коннектов к СУБД" не присутствует ни в модели исходной предметной области, ни в модели автоматизированного процесса. Он есть только там, внутри, и появляется как результат решения творческой задачи.
См. ответ выше. Пул появляется в результате удовлетворения нефункциональных требований и никак не связан с документооборотом строительства. Я не понимаю, откуда постоянно попытки соединить это воедино, и найти диалоги и пулы в модели предметной области. Да ещё в контексте критики ООП. Разьве процедурная декомпозиция выявит в документообороте строительства пуллинг коннектов к БД???
Здравствуйте, remark, Вы писали:
R>Предметная область — часть реального мира, интересующая нас в контексте решения некой конкретной задачи.
Гм. У нас есть абстрактная задача — строить дома.
При этом мы выбираем способы ее решения и способы улучшения этого решения.
Эти способы, вообще говоря, включают в себя:
— внедрение новых технологий строительства
— внедрение новых технологий управления строительством
Я не понимаю, что такое "конкретная задача" и откуда она берется. Задача "скопировать некоторое количество байт из одной области памяти в другую" вполне конкретна.
Покажи мне предметную область, в которой эта задача присутствует, и что это за часть реального мира. А потом покажи мне программу, которая ухитряется обойтись без решения этой задачи.
R>Нет. Не так. В предметной области есть только то, что интересует нас в контексте решения нашей конкретной задачи.
Ок. Приведи мне эту конкретную задачу. R>Предметная область — это и есть то, что нам нужно!
А ядерная бомба всегда попадает в эпицентр.
R>BPR — это уже совсем другая история. Пока я рассматривал всё так, как будто процессы мы менять не собираемся.
Отлично. Пока ты имеешь 100% шансы провалить проект, т.к. такая модель неверно описывает реальность. Либо заказчик выкинет решение за несовместимость с жизнью, либо команда будет в панике дописывать те части, которые автоматизируют ранее отсутствовавшие бизнес-процессы: бэкап, аудит, администрирование пользователей, администрирование софта...
R>По моим опнятиям таймауты и логи никак не должны повлиять на БП и на работу персонала.
Отличные понятия. По моему опыту, такие понятия встревают. Сразу же при контакте с реальностью. Если мы делаем распределенную систему, то надо уметь обрабатывать таймауты и предусматривать это в модели, иначе периодически работа будет просто вставать и системой нельзя будет пользоваться. Если не предусмотреть логи, то придется краснеть в ответ на вопрос "как нам узнать, кто поставил проекту статус "завершен"?".
R>Если при решении данной задачи нам не нужно знать цвет мешка, то зачем даже пытаться его хранить? Цвет мешка должен уйти при переходе от реального мира к модели предметной области.
Может быть. А может и нет. Смотря что называть "предметной областью".
S>>С другой стороны, у нас появится объект "диалог свойств партии товара", который не соответствует ничему из оригинальной предметной области. Мы только что изобрели новую предметную область, в которой на равне с мешками цемента фигурирут "диалоги", "экраны", "кнопки" и прочие элементы.
R>Я писал выше, в любой программе есть 2 предметной области: предметная область решаемой задчи и предметная область самой программы. R>Не надо их пытаться как-либо соединить. Зачем вы пытаетесь соединить воедино документооборот строительства и технологию построения программных систем?
Я чего-то не понимаю.
1. Почему этих предметных областей 2? А не три, не четыре?
2. Как избежать их соединения? Вот мы рисуем модель, которая как-то описывает нашу программу. Какие сущности будут в ней отражены?
Если это несколько моделей, то как они связаны между собой?
R>По любому ООП тут совсем ни при чём. Никакая технология декомпозиции/анализа не даст при анализе документооборота строительства ничего связанного с диалогами и пулингом соединений с БД.
Очень плохо, что не даст. Потому, что на практике оказывается, что значительная часть усилий разработчиков уходит именно на диалоги и пулинг. А собсно модель, имеющая какое-то опосредованное отношение к реальному миру, занимает махонькую часть айсберга. R>Все эти сущности появляются при удовлетворении нефункциональных требований к системе.
Как это "нефункциональны"??? Ну-ка, объясни мне, из какого именно требования появляется диалог. Или все 800 диалогов магически появляются у нас из одного требования "Система должна обеспечивать дружественный интерфейс"? R>Они перпендикулярны.
Ну как же перпендикулярны? Я еще могу понять, что, например, производительность перпендикулярна функциональности. Но с точки зрения здравого смысла нет никакого философского различия между перетаскиванием мешка с первого на пятый этажи и перетаскиванием иконки из одной папки в другую. И то и другое — часть вполне реального бизнес процесса. И я не вижу, почему надо проводить искусственную границу между этими частями, и откуда возьмутся эти требования.
R>Это касается детализации модели.
Никакая детализация не приведет к выявлению сущностей, изначально в модели не присутствующих.
R>См. ответ выше. Пул появляется в результате удовлетворения нефункциональных требований и никак не связан с документооборотом строительства.
Ждем примера нефункционального требования, из которого появляется диалог. Или такой объект, как Link R>Я не понимаю, откуда постоянно попытки соединить это воедино, и найти диалоги и пулы в модели предметной области.
А где их искать? R>Да ещё в контексте критики ООП.
Это в контексте критики критики ООП. R>Разьве процедурная декомпозиция выявит в документообороте строительства пуллинг коннектов к БД???
Скажем, так: если под "процедурной декомпозиции" понимать анализ бизнес процессов, то таки да. Потому, что при анализе бизнес-процесса "сдать проект" у нас обнаружится процедура "изменить статус записи о проекте в базе компании", а в ней появится подпрограмма "подключиться к БД". И требования по производительности, предъявляемые к процедуре "изменить статус" и другим процедурам, неизбежно приведут к изобретению пула соединений.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Я потерял нить обсуждения/спора. Я начал с того, что высказал несогласие с Ларманом в том, что существует 2 отдельных модели предметной области (у Фаулера аж 3).
Твой тезис в чём? В том, что ты согласен с Ларманом в том, существует несклько моделей предметной области? Или в чём?
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, remark, Вы писали:
R>>Предметная область — часть реального мира, интересующая нас в контексте решения некой конкретной задачи. S>Гм. У нас есть абстрактная задача — строить дома. S>При этом мы выбираем способы ее решения и способы улучшения этого решения. S>Эти способы, вообще говоря, включают в себя: S>- внедрение новых технологий строительства S>- внедрение новых технологий управления строительством
Повторюсь. Я считаю, что это отдельная тема. Внедрять новые технологии строительства/управления строительства никак не связано с автоматизацией. Так же как и формализация и рефакторинг бизнес-процессов.
Хотя, конечно, я согласен, что часто это происходит вместе, т.к. только при автоматизации начинают задумываться, а какие у нас собственно бизнес-процессы.
Но разобраться бы пока с самой ОО разработкой ПО, не учитывая пока, что во время неё могут ещё начать меняться БП.
S>Я не понимаю, что такое "конкретная задача" и откуда она берется. Задача "скопировать некоторое количество байт из одной области памяти в другую" вполне конкретна. S>Покажи мне предметную область, в которой эта задача присутствует, и что это за часть реального мира. А потом покажи мне программу, которая ухитряется обойтись без решения этой задачи.
Вообще не понял. Привожу пример как я понимаю эти термины. Реальный мир: некая фирма занимается строительством, рабочие грузят мешки с цементом, каждый мешок имеет определённый цвет. Задача: отв. лицо из строительной компании приходит в фирму, занимающуюся разработкой ПО и автоматизацией, и говорит "сделайте нам автоматизированную систему, которая будет управлять всеми нашими БП". Перед разработчиками встаёт задача — автоматизировать БП конкретной фирмы. Предметная область: разработчики начинают изучать деятельность фирмы и во время этого процесса из реального мира выделяется предметная область, т.е. то, что их будет интересовать во время решения задачи (автоматизации БП фирмы). В предметной области в частности уже отсутствуют цвет мешка с цементом как таковой.
R>>Нет. Не так. В предметной области есть только то, что интересует нас в контексте решения нашей конкретной задачи. S>Ок. Приведи мне эту конкретную задачу.
Автоматизировать деятельность конкретной строительной фирмы.
R>>Предметная область — это и есть то, что нам нужно! S>А ядерная бомба всегда попадает в эпицентр.
В данном случае так и есть. Не я придумывал эти термины и понятия, но мне лично они кажутся очень адекватными.
R>>BPR — это уже совсем другая история. Пока я рассматривал всё так, как будто процессы мы менять не собираемся. S>Отлично. Пока ты имеешь 100% шансы провалить проект, т.к. такая модель неверно описывает реальность. Либо заказчик выкинет решение за несовместимость с жизнью, либо команда будет в панике дописывать те части, которые автоматизируют ранее отсутствовавшие бизнес-процессы: бэкап, аудит, администрирование пользователей, администрирование софта...
Если заказчик с начала не включил это в требования, то туда ему и дорога. Ничего дописывать не обязательно, т.к. этого нет в контракте.
R>>По моим опнятиям таймауты и логи никак не должны повлиять на БП и на работу персонала. S>Отличные понятия. По моему опыту, такие понятия встревают. Сразу же при контакте с реальностью. Если мы делаем распределенную систему, то надо уметь обрабатывать таймауты и предусматривать это в модели, иначе периодически работа будет просто вставать и системой нельзя будет пользоваться. Если не предусмотреть логи, то придется краснеть в ответ на вопрос "как нам узнать, кто поставил проекту статус "завершен"?".
Это имеет отношение к нефункциональным требованиям и к модели программы.
Я не понимаю твоего тезиса. Ты хочешь сказать, какая-то другая технология декомпозиции/анализа (не ОО), например структурная/процедурная/функциональная/автоматная и т.д. найдёт в модели предметной области автоматизации строительного бизнеса такие сущности как логирование, таймауты???
Абсолютно такая же картина у тебя будет при применении любой другой технологии.
R>>Если при решении данной задачи нам не нужно знать цвет мешка, то зачем даже пытаться его хранить? Цвет мешка должен уйти при переходе от реального мира к модели предметной области. S>Может быть. А может и нет. Смотря что называть "предметной областью".
выше
S>>>С другой стороны, у нас появится объект "диалог свойств партии товара", который не соответствует ничему из оригинальной предметной области. Мы только что изобрели новую предметную область, в которой на равне с мешками цемента фигурирут "диалоги", "экраны", "кнопки" и прочие элементы.
R>>Я писал выше, в любой программе есть 2 предметной области: предметная область решаемой задчи и предметная область самой программы. R>>Не надо их пытаться как-либо соединить. Зачем вы пытаетесь соединить воедино документооборот строительства и технологию построения программных систем? S>Я чего-то не понимаю. S>1. Почему этих предметных областей 2? А не три, не четыре? S>2. Как избежать их соединения? Вот мы рисуем модель, которая как-то описывает нашу программу. Какие сущности будут в ней отражены? S>Если это несколько моделей, то как они связаны между собой?
Вопрос хороший. В принципе можно больше. Но мне кажется, что вполне достаточно 1 модели предметной области и 1 модели программы, в которой отражены сущности, которые реализуют нефункциональные требования.
Поясню на примере. Аналитик общается с заказчиком/пользователями и составляет модель предметной области, на которой отражены такие сущности как Рабочий, Документ, Подряд и т.д.
Архитектор (назовём его так) берёт список нефункциональных требований и составляет совсем другую модель, на которой появляются такие сущности как ДатаМаппер, Диалог, Логгер, ДиспатчерКалбеков и т.д.
Мне достаточно очевидно, что это именно 2 модели. При этом их можно строить достаточно независимо. Так Аналитику совершенно не надо значть ни про какие таймауты, логи, диалоги и т.д. Архитектору совсем не обязательно знать про Документ, Рабочего и т.д.
Про связи моделей. Они достаточно номинальные, но они есть. Связи такого рода: ДатаМаппер (сущность модели приложения) может загрузать/сохранять в БД сущности из модели предметной области. Диалог может отображать сущности из предметной области.
Эти связи необходимы, т.к. сущности предметной области сами по себе не могут даже отобразиться на экране. В конце концов они даже не могут породить выполняемый файл.
Опять же хочу подчеркнуть, что аналогичную картину мы получим при применении любой другой технологии декомпозиции/анализа/проектирования.
R>>По любому ООП тут совсем ни при чём. Никакая технология декомпозиции/анализа не даст при анализе документооборота строительства ничего связанного с диалогами и пулингом соединений с БД. S>Очень плохо, что не даст. Потому, что на практике оказывается, что значительная часть усилий разработчиков уходит именно на диалоги и пулинг. А собсно модель, имеющая какое-то опосредованное отношение к реальному миру, занимает махонькую часть айсберга.
Но они на это и не нацелены. На это нацелены другие процедуры.
R>>Все эти сущности появляются при удовлетворении нефункциональных требований к системе. S>Как это "нефункциональны"??? Ну-ка, объясни мне, из какого именно требования появляется диалог. Или все 800 диалогов магически появляются у нас из одного требования "Система должна обеспечивать дружественный интерфейс"?
К любой системе предъявляются требования по какому-либо выводу результатов своей работы куда-либо. Иначе это абсурдная система. Из этих требований и появляются диалоги.
R>>Они перпендикулярны. S>Ну как же перпендикулярны? Я еще могу понять, что, например, производительность перпендикулярна функциональности. Но с точки зрения здравого смысла нет никакого философского различия между перетаскиванием мешка с первого на пятый этажи и перетаскиванием иконки из одной папки в другую. И то и другое — часть вполне реального бизнес процесса. И я не вижу, почему надо проводить искусственную границу между этими частями, и откуда возьмутся эти требования.
Не понял.
R>>Это касается детализации модели. S>Никакая детализация не приведет к выявлению сущностей, изначально в модели не присутствующих.
Детализации касается не это. Детализации касается, например, то, что связь один ко многим заменяется массивом ссылок.
R>>См. ответ выше. Пул появляется в результате удовлетворения нефункциональных требований и никак не связан с документооборотом строительства. S>Ждем примера нефункционального требования, из которого появляется диалог. Или такой объект, как Link
К системам, которые ты делаешь, не предъявляется требований как-то отображать результаты своей работы???
R>>Я не понимаю, откуда постоянно попытки соединить это воедино, и найти диалоги и пулы в модели предметной области. S>А где их искать?
В модели приложения (к термину прошу не придираться). Её составляет совсем другой человек, исходя из других данных, отталкиваясь совсем от других знаний.
R>>Да ещё в контексте критики ООП. S>Это в контексте критики критики ООП.
Встречный вопрос. Покажи на примере процедурной декомпозиции, где в декомпозиции строительства ты найдёшь логирование/пуллинг коннектов/отображение информации на диспей? (можно на примере любой другой декомпозиции)
Очень бы хотелось увидеть ответ, как другие технологии решают проблему.
R>>Разьве процедурная декомпозиция выявит в документообороте строительства пуллинг коннектов к БД??? S>Скажем, так: если под "процедурной декомпозиции" понимать анализ бизнес процессов, то таки да. Потому, что при анализе бизнес-процесса "сдать проект" у нас обнаружится процедура "изменить статус записи о проекте в базе компании", а в ней появится подпрограмма "подключиться к БД". И требования по производительности, предъявляемые к процедуре "изменить статус" и другим процедурам, неизбежно приведут к изобретению пула соединений.
Во-первых, если так рассуждать, то и ООП даст в точности тот же результат, только в других терминах. Не веришь? Объект класса Проект в методе ИзменитьСтатус(), должен отобразить это изменение в БД, следовательно обращается к объекту СоединениеСБД. Из требований по производительности приходим к тому, что объект СоединениеСБД должен обращаться к объекту ПулКоннектов для получения реального соединения.
Во-вторых, это бред. Т.к. в бизнес-процессах неавтоматизированного предприятия нет никакого БД! На предприятии никто может и не знать ни про какое БД. Поэтому при анализе БП этого предприятия ничего подобного не будет.
В реальности будет так — начальник чего-то там скажет "после этого мы изменяем статус проекта, для этого вот в этом табеле я делаю вот такую пометку".
1.1.4 stable rev. 510
