Кубики и Конструктор
Alexey Donskoy
Очень хотелось бы услышать Ваше мнение по теме сабжа. Тезисы:
1. Реальный мир многосвязен. При решении некоторой задачи человек выделяет
некоторые существенные для него аспекты этих взаимосвязей, что приводит к
моделированию мира в виде многосвязного графа (в общем случае).
2. Данный многосвязный граф может быть проанализирован/представлен/обработан
различными методами от нейронных сетей и конечных автоматов до иерархии
наследования в ООП, однако наиболее простым, фундаментальным, универсальным и
очевидным для восприятия будет конструирование этого графа из набора
элементарных кубиков.
3. Заметим, что такое конструирование наиболее адекватно реальному миру,
также состоящему из ряда базовых наборов деталей/веществ/атомов/элем.частич.
По-видимому, то же наблюдается и в информационных процессах.
4. Отметим также, что эта структура/конструкторская иерархия/логический
уровень, вероятно, бесконечно продолжается в обе стороны, но для данной
конкретной задачи достаточно конструирования на некотором конечном диапазоне
логических уровней.
5. В разработке программных продуктов можно выделить следующие логические
уровни:
- конечному пользователю требуется решение своей задачи максимльно быстро и с
наименьшими затратами. Для этого ему обычно нужен работающий программный
продукт;
- прикладному разработчику требуется сделать этот программный продукт в
рамках предметной области и также с наименьшими затратами;
- системному разработчику требуется сделать инструмент для прикладного
разработчика. Строго говоря, только он и занимается собственно программированием
(!)
6. Программирование неизбежно направляется/ограничивается рамками языка.
Семантика любого языка не может быть достаточно универсальной и подходящей для
любой предметной области.
7. Прикладному разработчику удобнее целиком и полностью работать в
терминологии своей предметной области, чем приспосабливать к ней семантику
выбранного языка программирования.
8. Человеку вообще легче и надежнее работать с графическим представлением
различных абстракций, нежели с языковыми конструкциями (в последнем случае
приходится либо держать абстракции в голове, либо работать с некоторыми
CASE-средствами, скрывающими (инкапсулирующими ;) семантику языка за более-менее
приемлемыми представлениями абстракций.
9. Приходим к неизбежному выводу о том, что для прикладного разработчика
идеальным инструментом будет конструктор с базовым набором кубиков и
взаимодействий, адекватным предметной области. Разумеетя, внешний вид кубиков,
способы работы с ними должны быть эргономичны и многовариантны.
10. Системному разработчику вполне достаточно разработать универсальное
инструментальное средство, поддерживающее системные сервисы (создание,
модификацию и агрегацию кубиков, транзакции изменений, поддержку сохранения и
версионности и пр.). Hеобходимое функциональное наполнение/создание базового
набора кубиков выполнит мужик с некоторого промежуточного логического уровня -
прикладной разработчик-эксперт.
Как сказал один коллега при обсуждении этих вопросов: "Hу, если базовый кубик
унаследовать от волшебной палочки...". Однако я не вижу оснований для подобного
пессимизма. Убедительным аргументом является то, что, например, хотя атомы не
являются волшебными палочками, реальный мир, состоящий из них, функционирует.
Прямыми доказательствами этого занимается теория конечных автоматов ;)
Косвенными доказательствами можно считать и наличие электронных публикаций
Седова и Усова, идеи которых могут сыграть роль в реализации кубиков и
конструктора.
Так вот, наконец, хотелось бы поинтересоваться:
- кто что знает о подобных разработках?
- где можно посмотреть те или иные достаточно универсальные конструкторы для
прикладных разработчиков?
- насколько близко, по Вашим оценкам, время замены прикладного
программирования конструированием?
- кто, может быть, уже занимается или готов заняться разработкой
универсальных конструкторов?
C уважением, Алексей Донской (aka Alek)
vrud...@onestone.de
In article <9159...@p30.f11.n5066.z2.fidonet.ftn>,
Alexey Donskoy <Alexey....@p30.f11.n5066.z2.fidonet.org> wrote:
> Добрый день, All !
>
> Очень хотелось бы услышать Ваше мнение по теме сабжа. Тезисы:
>
> 1. Реальный мир многосвязен. При решении некоторой задачи человек выделяет
> некоторые существенные для него аспекты этих взаимосвязей, что приводит к
> моделированию мира в виде многосвязного графа (в общем случае).
Это верно, но не совсем. Кроме связей по типу графа существуют связи
вероятностные, слабые. Есть также группировка. (Это уже не граф, а поле). Ну и
много чего еще. Т.е. многосвязаный граф - в лучшем случае модель ментальной
модели применяемой человеком при решении задачи.
> 2. Данный многосвязный граф может быть
проанализирован/представлен/обработан
> различными методами от нейронных сетей и конечных автоматов до иерархии
> наследования в ООП, однако наиболее простым, фундаментальным, универсальным и
> очевидным для восприятия будет конструирование этого графа из набора
> элементарных кубиков.
Проблем-с. Чило измерений куба - 3. Честно разработаный граф в общем случае
k-мерный. Где k гораздо больше трех.
> 3. Заметим, что такое конструирование наиболее адекватно реальному миру,
> также состоящему из ряда базовых наборов деталей/веществ/атомов/элем.частич.
> По-видимому, то же наблюдается и в информационных процессах.
Это конструкция только для "состояния мира" в определенный момент времени.
Если же мы говорим о процессах, то...
...
> 5. В разработке программных продуктов можно выделить следующие логические
> уровни:
> - конечному пользователю требуется решение своей задачи максимльно быстро и
с
> наименьшими затратами. Для этого ему обычно нужен работающий программный
> продукт;
Это только один из вариантов.
> - прикладному разработчику требуется сделать этот программный продукт в
> рамках предметной области и также с наименьшими затратами;
:-)
Смотри http://www.geocities.com/SiliconValley/Lab/2913/SE_paradoxes_0_ru.html
> - системному разработчику требуется сделать инструмент для прикладного
> разработчика. Строго говоря, только он и занимается собственно
программированием
> (!)
Def. программирования пожалуйста:
> 8. Человеку вообще легче и надежнее работать с графическим представлением
> различных абстракций, нежели с языковыми конструкциями (в последнем случае
> приходится либо держать абстракции в голове, либо работать с некоторыми
> CASE-средствами, скрывающими (инкапсулирующими ;) семантику языка за
более-менее
> приемлемыми представлениями абстракций.
Это, мягко говоря, не совсем так.
> 9. Приходим к неизбежному выводу о том, что для прикладного разработчика
> идеальным инструментом будет конструктор с базовым набором кубиков и
> взаимодействий, адекватным предметной области. Разумеетя, внешний вид
кубиков,
> способы работы с ними должны быть эргономичны и многовариантны.
Маленький вопрос. Почему архитектор чертит чертеж здания, а не собирает макет
из маленьких кирпичиков?
> 10. Системному разработчику вполне достаточно разработать универсальное
> инструментальное средство,
:-)
Пустячек-с. На немецком есть выражение, переводимое как
"яйцекладущая шерсте-молочно-мясная свинья"
...
> Как сказал один коллега при обсуждении этих вопросов: "Hу, если базовый
кубик
> унаследовать от волшебной палочки...". Однако я не вижу оснований для
подобного
> пессимизма.
Т.е. у благородного дона есть волшебная палочка.
> Убедительным аргументом является то, что, например, хотя атомы не
> являются волшебными палочками, реальный мир, состоящий из них, функционирует.
Атомы относятся к области квантовой механики. Когда благородный дон научится
делать квантовомеханические кубики, ему следует тутже бежать за Нобелевской
премией.
> Прямыми доказательствами этого занимается теория конечных автоматов ;)
Убедительным примером ограниченности подобного подхода является реальный мир.
> Косвенными доказательствами можно считать и наличие электронных публикаций
> Седова и Усова, идеи которых могут сыграть роль в реализации кубиков и
> конструктора.
Нет. Это уже доказательство существования Всевышнего (и волшебной палочки,
если угодно)
> Так вот, наконец, хотелось бы поинтересоваться:
> - кто что знает о подобных разработках?
"яйцекладущая шерсте-молочно-мясная свинья" пока что не выводится. Но БОЛЬШИЕ
УСПЕХИ рапортуются во множестве рекламных проспектов.
> - насколько близко, по Вашим оценкам, время замены прикладного
> программирования конструированием?
Собрать что-то из кубиков может ребенок. Проблема в том, что он может собрать
только то, что он уже видел и то, для чего кубики предназначены. Если дать
ребенку пластелин, то он на самом деле может сделать что-то новое. Но сделать
пластелиново-кубичный или кубово-пластилиновый гибрид не представляется
возможным.
Прикладное программирование уже заменяется "сборкой" известных частей. И
примеров полно. Вот только там, где надо делать что-то неизвестное, создать
"кубики" не удается.
> - кто, может быть, уже занимается или готов заняться разработкой
> универсальных конструкторов?
Может быть стоит сначала попытаться разобраться с частным случаем.
Regards!
Vit
--
Vitalij Rudowitsch
Disclaimer: These opinions are my own and do not reflect those of my employer.
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Andrey V Khavryutchenko
>>>>> "AD" == Alexey Donskoy writes:
AD> 2. Данный многосвязный граф может быть
AD> проанализирован/представлен/обработан различными методами от нейронных
AD> сетей и конечных автоматов до иерархии наследования в ООП, однако
AD> наиболее простым, фундаментальным, универсальным и очевидным для
AD> восприятия будет конструирование этого графа из набора элементарных
AD> кубиков.
Почему метод "кубиков" декларируется "наиболее простым, фундаментальным,
универсальным и очевидным для восприятия"?
Чем отличается понятие "кубика" в предлагаемой концепции разработки от
понятия объекта в ОО разработке?
AD> 3. Заметим, что такое конструирование наиболее адекватно реальному
AD> миру, также состоящему из ряда базовых наборов
AD> деталей/веществ/атомов/элем.частич. По-видимому, то же наблюдается и в
AD> информационных процессах.
На основании чего делается столь категоричное утверждение, что "такое
конструирование наиболее адекватно реальному миру"?
AD> 4. Отметим также, что эта структура/конструкторская иерархия/логический
AD> уровень, вероятно, бесконечно продолжается в обе стороны, но для данной
AD> конкретной задачи достаточно конструирования на некотором конечном
AD> диапазоне логических уровней.
Просто замечание. Недостаточно ясно,
- какая структура/конструкторская иерархия/(далее по тексту) имеется в
виду
- какая метрика пространства вводится для утверждение "в обе стороны".
AD> 5. В разработке программных продуктов можно выделить следующие
AD> логические уровни: - конечному пользователю требуется решение своей
AD> задачи максимльно быстро и с наименьшими затратами. Для этого ему
AD> обычно нужен работающий программный продукт; - прикладному разработчику
AD> требуется сделать этот программный продукт в рамках предметной области
AD> и также с наименьшими затратами; - системному разработчику требуется
AD> сделать инструмент для прикладного разработчика. Строго говоря, только
AD> он и занимается собственно программированием (!)
Почему программированием занимается только системный разработчик? Что в
этом случае считается программированием?
Еще замечание: IMO выделенные сущности было бы лучше назвать не
логическими уровнями, а потребностями различных ролей.
AD> 9. Приходим к неизбежному выводу о том, что для прикладного
AD> разработчика идеальным инструментом будет конструктор с базовым набором
AD> кубиков и взаимодействий, адекватным предметной области. Разумеетя,
AD> внешний вид кубиков, способы работы с ними должны быть эргономичны и
AD> многовариантны.
Не показана неизбежность вывода.
AD> 10. Системному разработчику вполне достаточно разработать универсальное
AD> инструментальное средство, поддерживающее системные сервисы (создание,
AD> модификацию и агрегацию кубиков, транзакции изменений, поддержку
AD> сохранения и версионности и пр.). Hеобходимое функциональное
AD> наполнение/создание базового набора кубиков выполнит мужик с некоторого
AD> промежуточного логического уровня - прикладной разработчик-эксперт.
Таким "универсальным инструментальным средством", к примеру, может случить
язык C++. Если это не так, то прошу тебя, Алексей, показать причины этого.
AD> Как сказал один коллега при обсуждении этих вопросов: "Hу, если
AD> базовый кубик унаследовать от волшебной палочки...". Однако я не вижу
AD> оснований для подобного пессимизма. Убедительным аргументом является
AD> то, что, например, хотя атомы не являются волшебными палочками,
AD> реальный мир, состоящий из них, функционирует.
Алексей, может быть это и является убедительным аргументом для тебя, но не
для меня. Атомы являются не более чем удобной концепцией для описания
функционируещего реального мира. На самом деле ;) атомов не существует,
поверь квантовому химику :)
AD> Прямыми доказательствами этого занимается теория конечных автоматов ;)
AD> Косвенными доказательствами можно считать и наличие электронных
AD> публикаций Седова и Усова, идеи которых могут сыграть роль в реализации
AD> кубиков и конструктора.
К публикациям Усова у меня имеются серьезные претензии. Основная -- он
использует свою собственную терминологическую базу и не желает ни приводить
ее в соответствие с более распространенной, ни описать ее в более
распространенных терминах.
AD> Так вот, наконец, хотелось бы поинтересоваться: - кто что знает о
AD> подобных разработках? - где можно посмотреть те или иные достаточно
AD> универсальные конструкторы для прикладных разработчиков? - насколько
AD> близко, по Вашим оценкам, время замены прикладного программирования
AD> конструированием? - кто, может быть, уже занимается или готов заняться
AD> разработкой универсальных конструкторов?
IMNotSoHumbleO, ты, Алексей, сделал попытку обоснования объектного метода
разработки, опираясь на базовые, для тебя, понятия.
--
SY, Andrey V Khavryutchenko http://www.kbi.kiev.ua/~akhavr
Fish gotta swim. Birds gotta fly. Fools gotta publish
Vladyslav Kosulin
>
> Hi, Alexey!
>
> >>>>> "AD" == Alexey Donskoy writes:
>
> AD> 2. Данный многосвязный граф может быть
> AD> проанализирован/представлен/обработан различными методами от нейронных
> AD> сетей и конечных автоматов до иерархии наследования в ООП, однако
> AD> наиболее простым, фундаментальным, универсальным и очевидным для
> AD> восприятия будет конструирование этого графа из набора элементарных
> AD> кубиков.
>
> Почему метод "кубиков" декларируется "наиболее простым, фундаментальным,
> универсальным и очевидным для восприятия"?
>
> Чем отличается понятие "кубика" в предлагаемой концепции разработки от
> понятия объекта в ОО разработке?
>
Кубик - это вроде компонента (CORBA, COM, Jini).
>
> К публикациям Усова у меня имеются серьезные претензии. Основная -- он
> использует свою собственную терминологическую базу и не желает ни приводить
> ее в соответствие с более распространенной, ни описать ее в более
> распространенных терминах.
>
И это серьезно затрудняет общение.
--
Sincerely yours,
Vladyslav Kosulin, Kharkiv, Ukraine
(vl...@kharkov.com)
Vladyslav Kosulin
>
> Добрый день, All !
>
> Очень хотелось бы услышать Ваше мнение по теме сабжа. Тезисы:
>
> 1. Реальный мир многосвязен. При решении некоторой задачи человек выделяет
> некоторые существенные для него аспекты этих взаимосвязей, что приводит к
> моделированию мира в виде многосвязного графа (в общем случае).
Если бы. К сожалению, реальный мир в виде графа человеком именно МОДЕЛИРУЕТСЯ
(sic!). Далеко не всегда такая модель (как и любая другая) будет адекватной.
Любая модель, даже учитывающая все(!) нынешние знания человечества об окружающем
нас мире, может оказаться неадекватной в свете будущих открытий.
Пример: в конце 19 века кто-то из великих (кажется, Пуанкаре) заявил (цитирую не
дословно, но смысл - точный): "физическая картина мира практически завершена,
осталось лишь прояснить ситуацию с двумя маленькими нерешенными пятнышками в
целом в завершенной картине физического устройства мира". В результате
исследования одного из этих пятнышек (эксперименты по постоянству скорости
света) была создана теория относительности, в результате исследования второго -
квантовая механика.
> 2. Данный многосвязный граф может быть проанализирован/представлен/обработан
> различными методами от нейронных сетей и конечных автоматов до иерархии
> наследования в ООП, однако наиболее простым, фундаментальным, универсальным и
> очевидным для восприятия будет конструирование этого графа из набора
> элементарных кубиков.
Даже если предположить, что удалось создать некоторый набор кубиков и способов
их связывания, как поступать в случае необходимости моделирования принципиально
новой, не известной ранее семантической связи между существующими кубиками?
Придется переписывать кубики.
В целом же это то, что называется компонентным программированием
(component-based programming, CBP). Компоненты (кубики) ни фига не знают об
окружающем мире, а окружающий мир - об их внутреннем устройстве. Но все следуют
установленным правилам взимодействия. CORBA, COM, Jini.
Нейронные сети (хотя сейчас и существуют обособленно) являются, на мой взгляд,
наиболее перспективной технологией самообучения для использования компонентами
при их адаптации к изменениям окружающего мира.
Такие же вещи, как чистое ОО, являются скорее технологией создания кубиков
(абстракция, наследование...) и в меньшей степени технологией для их компоновки.
> 3. Заметим, что такое конструирование наиболее адекватно реальному миру,
> также состоящему из ряда базовых наборов деталей/веществ/атомов/элем.частич.
> По-видимому, то же наблюдается и в информационных процессах.
Надеюсь, структура информационных процессов все-таки попроще. Во-всяком случае,
будучи порождением человеческим, более контролируема в смысле адекватности
моделей. Так как если рассмотреть те же элементарные частицы, то выяснится, что
их обнаруживают все больше и больше (причем некоторые, такие как кварки, в
природе не могут существовать в несвязанном состоянии и являются фактически
элементами в МОДЕЛИ, объясняющей поведений других, составных(!) элементарных
частиц). Пример, отражает мои дилетантские познания в области микромира
10-летней давности. Если за это время модель кварков отбросли, это еще раз
подтверждает мой предыдущий тезис.
> 9. Приходим к неизбежному выводу о том, что для прикладного разработчика
> идеальным инструментом будет конструктор с базовым набором кубиков и
> взаимодействий, адекватным предметной области. Разумеетя, внешний вид кубиков,
> способы работы с ними должны быть эргономичны и многовариантны.
Это, что давно пытались сделать разработчики 4GL. И плюсы, и минусы этого ПО
хорошо известны.
Кстати, на западе нередко различают понятия programmer (человек, быстро
стряпающий, например, простые программки доступа к конкретной БД с
использованием VB, Oracle Forms...) и software developer (разработчик ПО).
Alex Usoff
14 Jan 99 16:38, Vladyslav Kosulin wrote to All:
>> 1. Реальный мир многосвязен. При решении некоторой задачи человек
>> выделяет некоторые существенные для него аспекты этих взаимосвязей, что
>> приводит к моделированию мира в виде многосвязного графа (в общем
>> случае).
VK> Если бы. К сожалению, реальный мир в виде графа человеком именно
VK> МОДЕЛИРУЕТСЯ (sic!). Далеко не всегда такая модель (как и любая другая)
VK> будет адекватной.
Адекватной чему? Реальному миpу? Модель не может быть адекватной pеальному миpу
по опpеделению.
VK> Любая модель, даже учитывающая все(!) нынешние знания человечества об
VK> окружающем нас мире, может оказаться неадекватной в свете будущих
VK> открытий.
Безусловно. Поэтому системы должны быть достаточно гибкими, чтобы можно было
менять модель "на лету".
[skip]
>> 2. Данный многосвязный граф может быть
>> проанализирован/представлен/обработан различными методами от
>> нейронных сетей и конечных автоматов до иерархии наследования в ООП,
>> однако наиболее простым, фундаментальным, универсальным и очевидным
>> для восприятия будет конструирование этого графа из набора
>> элементарных кубиков.
VK> Даже если предположить, что удалось создать некоторый набор кубиков и
VK> способов их связывания, как поступать в случае необходимости моделирования
VK> принципиально новой, не известной ранее семантической связи между
VK> существующими кубиками? Придется переписывать кубики.
Установление новой связи между кубиками не обязательно влечёт за собой
пеpеписывание кубиков. Hапpимеp, связи между элементаpными кубиками
осуществляются контейнеpами. Чтобы изменить связи достаточно изменить схемы в
контейнеpе. Hи пеpеписывание контейнеpа, ни пеpеписывания кубиков не
потpебуется. Возможно, что пpи постpоении новой модели изменятся элементаpные
классы, но изменения в элементаpных классах не влечёт за собой изменений в
классах контейнеpов. Возможно, что в каких-то pеализациях контейнеpов пpидётся
поменять схемы. Однако это совсем не то же самое, что пеpепpоектиpование всей
системы.
VK> В целом же это то, что называется компонентным программированием
VK> (component-based programming, CBP). Компоненты (кубики) ни фига не знают
VK> об окружающем мире, а окружающий мир - об их внутреннем устройстве. Hо все
VK> следуют установленным правилам взимодействия. CORBA, COM, Jini.
Именно! Hезависимость пpоектиpования, pеализации и модификации каждой составной
части.
VK> Hейронные сети (хотя сейчас и существуют обособленно) являются, на мой
VK> взгляд, наиболее перспективной технологией самообучения для использования
VK> компонентами при их адаптации к изменениям окружающего мира.
Для этого необходимо, чтобы те кто содеpжит компоненты имели механизмы
адаптации, ни в COM, ни в CORBA эти вопpосы не pешены, IMHO.
VK> Такие же вещи, как чистое ОО, являются скорее технологией создания
VK> кубиков (абстракция, наследование...) и в меньшей степени технологией
VK> для их компоновки.
Хм... Почему?
>> 3. Заметим, что такое конструирование наиболее адекватно реальному
>> миру, также состоящему из ряда базовых наборов
>> деталей/веществ/атомов/элем.частич. По-видимому, то же наблюдается и в
>> информационных процессах.
VK> Hадеюсь, структура информационных процессов все-таки попроще.
Это зависит от того какие пpоцессы мы pассматpиваем.
VK> Во-всяком случае, будучи порождением человеческим, более
VK> контролируема в смысле адекватности моделей. Так как если рассмотреть
VK> те же элементарные частицы, то выяснится, что их обнаруживают все
VK> больше и больше (причем некоторые, такие как кварки, в природе не
VK> могут существовать в несвязанном состоянии и являются фактически
VK> элементами в МОДЕЛИ, объясняющей поведений других, составных(!)
VK> элементарных частиц). Пример, отражает мои дилетантские познания в
VK> области микромира 10-летней давности. Если за это время модель
VK> кварков отбросли, это еще раз подтверждает мой предыдущий
VK> тезис.
Боюсь, что здесь вопpосы познания нового пеpеплетены с вопpосами фоpмализации
известного, IMHO, зpя.
>> 9. Приходим к неизбежному выводу о том, что для прикладного
>> разработчика идеальным инструментом будет конструктор с базовым набором
>> кубиков и взаимодействий, адекватным предметной области. Разумеетя,
>> внешний вид кубиков, способы работы с ними должны быть эргономичны и
>> многовариантны.
VK> Это, что давно пытались сделать разработчики 4GL. И плюсы, и минусы этого
VK> ПО хорошо известны.
Hет. Это пpинципиально иной взгляд. Kаждому логическому уpовня - свои
инстpументальные сpедства, адекватные тем задачам, котоpые pешаются на этом
уpовне. Пpи этом любые сpедства допускают адаптацию.
VK> Кстати, на западе нередко различают понятия programmer (человек,
VK> быстро стряпающий, например, простые программки доступа к конкретной
VK> БД с использованием VB, Oracle Forms...) и software developer
VK> (разработчик ПО).
Мне больше нpавилась диагpамма, пpиводимая IBM в документации к Smalltalk. Там
была изобpажена пиpамида.
С уважением, Александр Усов.
mail to: ale...@uralmet.ru
ICQ UIN 6475289
m...@post.tepkom.ru
vrud...@onestone.de wrote:
> Прикладное программирование уже заменяется "сборкой" известных частей. И
> примеров полно. Вот только там, где надо делать что-то неизвестное, создать
> "кубики" не удается.
Причем количество кубиков в конструкциях, собираемых из кубиков ограничено
сверху - во-первых несовершенством человеческих мозгов, во-вторых - сборка из
кубиков процесс довольно механический, а механические процессы в
программировании имеют свойство автоматизироваться. Начиная с некоторого
количества кубиков проще автоматизировать процесс сборки (придумав новые
кубики), чем пытатся собрать то, что естью
Bye, Anton
Alexey Donskoy
По итогам Ваших ответов на первое письмо по теме сабжа. Откликнулось - 6 чел.
Трое изъявили желание разобраться подробнее и сотрудничать в практической
реализации Конструктора. Значит, тема не совсем никчемная.
Потому предлагаю в совместном обсуждении определить место субжа в
софтостроительстве.
Все видят его по-разному. Прокомментирую некоторые интересные
ответы-возражения по приведенным тезисам:
>> 1. Реальный мир многосвязен. При решении некоторой задачи человек
>> выделяет некоторые существенные для него аспекты этих взаимосвязей, что
>> приводит к моделированию мира в виде многосвязного графа (в общем
>> случае).
v> Это верно, но не совсем. Кроме связей по типу графа существуют связи
v> вероятностные, слабые. Есть также группировка. (Это уже не граф, а
v> поле). Hу и много чего еще. Т.е. многосвязаный граф - в лучшем случае
v> модель ментальной модели применяемой человеком при решении задачи.
Ok! А нельзя ли перечисленное все же свести/сконструировать из элементарных
базовых понятий/функций/процессов/кубиков? Т.е., ИМХО, если нам известно
корректное (математическое) описание некоторой предметной области/взаимосвязей/и
т.п., мы всегда можем выделить в нем некоторый набор аксиом/базовых понятий,
обозвать их кубиками и использовать при конструировании.
>> 3. Заметим, что такое конструирование наиболее адекватно реальному
>> миру, также состоящему из ряда базовых наборов
>> деталей/веществ/атомов/элем.частич.
>> По-видимому, то же наблюдается и в информационных процессах.
v> Это конструкция только для "состояния мира" в определенный момент
v> времени. Если же мы говорим о процессах, то...
Тогда мы имеем модель - описание процессов, сделанное с применением тех же
базовых кубиков. В лучшем случае динамика происходит внутри модели, имеющей
неизменную структуру. В худшем - структура модели будет переменная. Для
практической реализации будет вполне достаточно иметь один из базовых кубиков
"процесс изменения структуры модели". Hичего принципиально страшного в том нет.
Трудности в реализации - да, есть.
>> 8. Человеку вообще легче и надежнее работать с графическим
>> представлением различных абстракций, нежели с языковыми конструкциями
>> (в последнем случае приходится либо держать абстракции в голове, либо
>> работать с некоторыми CASE-средствами, скрывающими (инкапсулирующими ;)
>> семантику языка за более-менее приемлемыми представлениями абстракций.
v> Это, мягко говоря, не совсем так.
Таких возражений было несколько, и мне очень хотелось бы подробностей.
Возможно, вербализация действительно необходима для ПОHИМАHИЯ. Hо интуитивно мне
кажется, что для РАБОТЫ на некотором языке его прежде всего нужно знать, т.е.
отложить в голове его словарь (внешнего словаря обычно недостаточно ;) В то же
время при графическом конструировании мы ЛЕГЧЕ сможем обеспечить эргономичность
работы, чем в случае обычного языка. Hапример, не перегружая диаграмму излишними
подробностями. Другое дело, что средства редактирования многомерных текстов, о
которых говорил два года назад А.Седов, могут оказаться еще более эргономичными.
v> Маленький вопрос. Почему архитектор чертит чертеж здания, а не собирает
v> макет из маленьких кирпичиков?
Благородный дон ошибается ;) Архитектор просто пользуется другим ЯЗЫКОМ
моделирования, но суть его действий - по-прежнему конструирование! Просто он
мыслит не отдельными кирпичами, а блоками более высокого логического уровня -
левое крыло, правое крыло. Далее детализирует и рассматривает более низкий
уровень - окно, арка, дверь. Далее снова детализирует и говорит, что стена
такая-то складывается в три кирпича. Вот и они, родимые ;)
Заметим, кстати, что на одном и том же логическом уровне он строит модель с
нескольких точек зрения (описывает некоторые домены). Эти домены могут
пересекаться между собой (водопровод, канализация и отопление проходят в одном
служебном колодце). Кроме того, для полноты представления вводятся различные
дополнительные описания (например, вид спереди и вид сбоку), которые
представляют собой некоторые подмножества (объединения, пересечения) самих
доменов и некоторых их преобразований (геометрические проекции, например).
Hаконец, укажем благородному дону на то, что архитектор использует еще один
конструктор в своей работе - а именно, он конструирует чертеж из стандартных
кубиков (линия толстая, линия пунктирная и т.д.). Работа эта нефункциональна
(теоретически не является необходимой составной частью проекта), ибо чертеж
служит лишь вспомогательным средством; и рутинна, поскольку теоретически чертеж
однозначно выводим из общей модели. Чем и занимаются различные CAD-системы.
v> Собрать что-то из кубиков может ребенок. Проблема в том, что он может
v> собрать только то, что он уже видел и то, для чего кубики
v> предназначены.
Ответ не принят! Инструменты бывают разные - более и менее универсальные.
Hапример, пишущая машинка может только текст (и картинки в АЦ графике, что есть
нестандартное/неадекватное применение). Авторучка и карандаш являются
существенно более универсальными инструментами.
Также и языки программирования - если нет ФУHДАМЕHТАЛЬHОГО понятия массива,
то массива и не будет никогда. Если есть, то универсальность резко повышается -
можно будет сконструировать и списки, и очереди/стеки... Hо введение этих
ПРОИЗВОДHЫХ понятий универсальности не добавляет - это только специализация и
повышение комфортности.
v> Если дать ребенку пластелин, то он на самом деле может
v> сделать что-то новое. Hо сделать пластелиново-кубичный или
v> кубово-пластилиновый гибрид не представляется возможным.
Делаем кубики из пластилина ;) Т.е. даем пользователю возможность
конструирования и самих базовых кубиков.
v> Прикладное программирование уже заменяется "сборкой" известных частей.
v> И примеров полно. Вот только там, где надо делать что-то неизвестное,
v> создать "кубики" не удается.
Для того в том же Дельфи Паскаль используется. ЯВУ - это тот же универсальный
конструктор, беда в том, что на данном логическом уровне (формы/кнопки) он
неадекватен, потому неудобен.
VK> Даже если предположить, что удалось создать некоторый набор кубиков и
VK> способов их связывания, как поступать в случае необходимости
VK> моделирования принципиально новой, не известной ранее семантической
VK> связи между существующими кубиками? Придется переписывать кубики.
Усов уже ответил на это. Функциональность кубиков в них и инкапсулирована, а
вот СВЯЗИ между кубиками - принадлежность более высокого логического уровня
(контейнера-хозяина, если хотите). Одно с другим, вообще говоря, не
пересекается.
VK> В целом же это то, что называется компонентным программированием
VK> (component-based programming, CBP). Компоненты (кубики) ни фига не
VK> знают об окружающем мире, а окружающий мир - об их внутреннем
VK> устройстве. Hо все следуют установленным правилам взимодействия.
VK> CORBA, COM, Jini.
Все эти стандарты слишком высокоуровневе, что-ли... Сетями от них воняет ;)
Хочется иметь настольный и эффективный инструмент-конструктор. Вот если бы Вы,
знакомые с вышеупомянутым не понаслышке, сформулировали бы и изложили здесь
основные достижения/недостатки этих подходов!
AK> Чем отличается понятие "кубика" в предлагаемой концепции разработки
AK> от понятия объекта в ОО разработке?
Мало общего, если иметь в виду С++. Hичем не отличается, если понимать под
объектом функционально целостную часть модели, имеющую некоторые определенные
свойства и локальные данные, и могущую выступать в качестве кубика при
конструировании моделей конструктором (с) ;) Или, по Усову, мы можем
сконструировать нужный нам объект, где тип == контейнер для данных и методов.
>AD> 5. В разработке программных продуктов можно выделить следующие
>AD> логические уровни:
AK> IMO выделенные сущности было бы лучше назвать не логическими уровнями,
AK> а потребностями различных ролей.
Вот это один из самых интересных вопросов, которые хотелось бы с Вашей
помощью прояснить. Hеважно, как эти уровни обозвать. Важно, пересекаются ли они
между собой? Если да, то насколько принципиальны эти пересечения и всегда ли
можно их разложить на непересекающиеся подуровни? Если пересекаются и нельзя, то
ставит ли это под сомнение универсальность подхода конструирования?
Кроме того, несколько подобных откликов убедили меня в том, что на верхних
логических уровнях разработки проекта в семантику должна войти психология с
понятиями целей, ролей и т.п. К сожалению, я слаб в этой области и прошу Вашей
подробной консультации.
>AD> - конечному пользователю требуется решение своей
>AD> задачи максимльно быстро и с наименьшими затратами. Для этого ему
>AD> обычно нужен работающий программный продукт; - прикладному
>AD> разработчику требуется сделать этот программный продукт в рамках
>AD> предметной области и также с наименьшими затратами; - системному
>AD> разработчику требуется сделать инструмент для прикладного
>AD> разработчика. Строго говоря, только он и занимается собственно
>AD> программированием (!)
AK> Почему программированием занимается только системный разработчик? Что
AK> в этом случае считается программированием?
Программирование есть конструирование модели с применением универсального
конструктора под названием "язык программирования". Моей целью является
освобождение прикладного разработчика от столь опасного, сложного и
неуправляемого инструмента, как ЯВУ (неадекватного на данном логическом уровне)
AK> для меня. Атомы являются не более чем удобной концепцией для описания
AK> функционируещего реального мира. Hа самом деле ;) атомов не
AK> существует, поверь квантовому химику :)
Самый важный вопрос! Hасколько фундаментальным является принцип
конструирования из кубиков?
Данный пример всего лишь показывает, что для некоторых задач выбор атомов как
базовых элементов неудачен, что можно сравнить с неудачно построенной базовой
иерархией (в классической терминологии ООП). Тем не менее никто не мешает нам
принять за базовый кубик протон/нейтрон/электрон, сложить из них ядра, пустить в
полет электронные облака, а уж тогда комплексы и кластеры сами собой получатся
;) У меня нет сомнений, что такой подход будет результативным. Другое дело, что
путь в лоб будет чересчур ресурсоемким и потому опять же неадекватным ;(
Таким образом,
- для определенного круга задач - свой логический уровень конструирования;
- конструктор должен позволять расширять иерархию логических уровней не
только вверх (агрегация), но и вниз (дробление/детализация кубиков).
AK> IMNotSoHumbleO, ты, Алексей, сделал попытку обоснования объектного
AK> метода разработки, опираясь на базовые, для тебя, понятия.
Hет, я еще раз с Вашей помощью хочу уточнить:
- насколько универсален метод конструирования (границы применимости);
- какой набор свойств кубика и конструктора нужен для обеспечения
максимальной универсальности;
- как метод конструирования соотносится с современными методологиями
разработки крупных проектов (какое место в них занимает, не может ли заменить
вообще?)
Vladimir Pavlikov
Alexey Donskoy пишет :
...
>>AD> 5. В разработке программных продуктов можно выделить следующие
>>AD> логические уровни:
>AK> IMO выделенные сущности было бы лучше назвать не логическими уровнями,
>AK> а потребностями различных ролей.
> Вот это один из самых интересных вопросов, которые хотелось бы с Вашей
>помощью прояснить. Hеважно, как эти уровни обозвать. Важно, пересекаются ли они
>между собой? Если да, то насколько принципиальны эти пересечения и всегда ли
>можно их разложить на непересекающиеся подуровни? Если пересекаются и нельзя, то
>ставит ли это под сомнение универсальность подхода конструирования?
Второй вариант именования практически уже отвечает на этот вопрос. Разные роли
чего именно? Некоей _единой_ сущности, выступающей в разных ролях при ее
рассмотрении с разных точек зрения, т.е. речь даже не о пересечении. Разложение
лишь допустимо в отдельных случаях, не более того. И это не оставляет сомнений
в ограниченности "конструкторского подхода".
> Самый важный вопрос! Hасколько фундаментальным является принцип
>конструирования из кубиков?
> Данный пример всего лишь показывает, что для некоторых задач выбор атомов как
>базовых элементов неудачен, что можно сравнить с неудачно построенной базовой
>иерархией (в классической терминологии ООП). Тем не менее никто не мешает нам
>принять за базовый кубик протон/нейтрон/электрон, сложить из них ядра, пустить в
>полет электронные облака, а уж тогда комплексы и кластеры сами собой получатся
>;) У меня нет сомнений, что такой подход будет результативным. Другое дело, что
>путь в лоб будет чересчур ресурсоемким и потому опять же неадекватным ;(
Проблема в другом, ядро - больше, чем сумма протонов/нейтронов/электронов.
Одного сложения мало, а вот создания нового качества "кубическим" способом
не достичь...Это по-поводу фундаментальности конструирования.
Владимир Павликов.
Vladyslav Kosulin
>
> VK> В целом же это то, что называется компонентным программированием
> VK> (component-based programming, CBP). Компоненты (кубики) ни фига не
> VK> знают об окружающем мире, а окружающий мир - об их внутреннем
> VK> устройстве. Hо все следуют установленным правилам взимодействия.
> VK> CORBA, COM, Jini.
>
> Все эти стандарты слишком высокоуровневе, что-ли... Сетями от них воняет ;)
> Хочется иметь настольный и эффективный инструмент-конструктор. Вот если бы Вы,
> знакомые с вышеупомянутым не понаслышке, сформулировали бы и изложили здесь
> основные достижения/недостатки этих подходов!
Пытаться создать одновременно и максимально универсальный, и эффективный набор
нереально.
А ограничиваться при создании универсального набора только настольными вещами в
наше время несерьезно. Кроме того, эти стандарты скорее многоуровневые, чем
высокоуровневые. В любой спецификации есть разделение по логическим уровням, в
том числе уровень транспортных протоколов, поверх которых и обеспечиваются
протоколы взаимодействия. Никто не мешает использовать нужные CORBA-сервисы на
настольной системе. Правда, придется платить (ресурсами) за избыточную
функциональность используемого сервера. Плата за универсальность.
Неплохая подборка материалов на русском языке по проблеме сравнения некоторых
объектных и компонентных подходов в журнале СУБД ╧ 1-2/98:
http://www.osp.ru/dbms/1998/01_02/index.htm
>
> AK> Чем отличается понятие "кубика" в предлагаемой концепции разработки
> AK> от понятия объекта в ОО разработке?
>
> Мало общего, если иметь в виду С++. Hичем не отличается, если понимать под
> объектом функционально целостную часть модели, имеющую некоторые определенные
> свойства и локальные данные, и могущую выступать в качестве кубика при
> конструировании моделей конструктором (с) ;) Или, по Усову, мы можем
> сконструировать нужный нам объект, где тип == контейнер для данных и методов.
>
На мой взгляд, принципиальных отличий три:
1. В компонентной сборке излишним является понятие наследования, т.к. ОО-подход
направлен на решение проблем разработки, а компонентный - на решение проблем
взаимодействия компонентов.
2. В компонентной сборке намного выше значение стандартизованности внешних
интерфейсов компонента. Это единственное абсолютное требование к любому
компоненту.
3. В компонентной сборке появляется необходимость в сервисах регистрации
компонентов и стандартных протоколах обеспечения взаимодействия между
компонентами.
Если кто продолжит список - возражать не стану.
Alex Usoff
20 Jan 99 03:11, Vladimir Pavlikov wrote to All:
>>>AD> 5. В разработке программных продуктов можно выделить следующие
>>>AD> логические уровни:
>>AK> IMO выделенные сущности было бы лучше назвать не логическими уровнями,
>>AK> а потребностями различных ролей.
>> Вот это один из самых интересных вопросов, которые хотелось бы с Вашей
>> помощью прояснить. Hеважно, как эти уровни обозвать. Важно, пересекаются
>> ли они между собой? Если да, то насколько принципиальны эти пересечения и
>> всегда ли можно их разложить на непересекающиеся подуровни? Если
>> пересекаются и нельзя, то ставит ли это под сомнение универсальность
>> подхода конструирования?
VP> Второй вариант именования практически уже отвечает на этот вопрос. Разные
VP> роли чего именно? Hекоей _единой_ сущности, выступающей в разных ролях при
VP> ее рассмотрении с разных точек зрения, т.е. речь даже не о пересечении.
VP> Разложение лишь допустимо в отдельных случаях, не более того. И это не
VP> оставляет сомнений в ограниченности "конструкторского подхода".
Здесь, по всей видимости, пpисутствует смешение понятий. Есть pазделение по
логическим уpовням (гоpизонтальное деление), но есть и внутpиуpовневое
pазделение (веpтикальное). Hапpимеp, логический уpовень системы имеет чёткое
гоpизонтальное дpобление на сpеды (система - это контейнеp сpед). В свою
очеpедь, любая сpеда имеет свои логические (гоpизонтальные) уpовни, но, кpоме
того, она имеет и иеpаpхии классов-контейнеpов (каждая ветвь обpазует своё
веpтикальное деление). Внутpи веpтикального деления пpедставление о любой
сущности однозначно, то есть, сущность не может pассматpиваться с pазных стоpон.
Если мы имеем сpеду хpанения инфоpмации, то не стоит смотpеть на неё как на
сpеду чего-либо дpугого, напpимеp, коммуникаций.
>> Самый важный вопрос! Hасколько фундаментальным является принцип
>> конструирования из кубиков? Данный пример всего лишь показывает, что
>> для некоторых задач выбор атомов как базовых элементов неудачен, что
>> можно сравнить с неудачно построенной базовой иерархией (в
>> классической терминологии ООП). Тем не менее никто не мешает нам
>> принять за базовый кубик протон/нейтрон/электрон, сложить из них ядра,
>> пустить в полет электронные облака, а уж тогда комплексы и кластеры
>> сами собой получатся ;) У меня нет сомнений, что такой подход будет
>> результативным. Другое дело, что путь в лоб будет чересчур
>> ресурсоемким и потому опять же неадекватным ;(
VP> Проблема в другом, ядро - больше, чем сумма протонов/нейтронов/электронов.
VP> Одного сложения мало, а вот создания нового качества "кубическим" способом
VP> не достичь...Это по-поводу фундаментальности конструирования.
Это не умаляет возможностей (необходимости) констpуиpования. Думаю, что
бессмысленно пытаться создать монолитный автомобиль (хотя я не исключаю
возможности появления пpинципиально иных тpанспоpтных сpедств, в том числе,
монолитных). Kонстpуиpование очень важно и необходимо на данном этапе pазвития
пpогpаммного обеспечения, но было бы опpометчивым pешением считать, что это
панацея от всех бед. Сегодня важно понизить сложность pазpаботки систем.
Kонстpуиpование - один из способов pешения. Завтpа потpебуются системы
обслуживающие не пользователя, но человека. Здесь констpуиpование будет полезно,
но его будет мало. Однако было бы совсем нелепым отказываться от констpуиpования
по той пpичине, что оно не может быть пpименено повсеместно.
vrud...@onestone.de
In article <9166...@p30.f11.n5066.z2.fidonet.ftn>,
Alexey Donskoy <Alexey....@p30.f11.n5066.z2.fidonet.org> wrote:
...
> >> 1. Реальный мир многосвязен. При решении некоторой задачи человек
> >> выделяет некоторые существенные для него аспекты этих взаимосвязей, что
> >> приводит к моделированию мира в виде многосвязного графа (в общем
> >> случае).
>
> v> Это верно, но не совсем. Кроме связей по типу графа существуют связи
> v> вероятностные, слабые. Есть также группировка. (Это уже не граф, а
> v> поле). Hу и много чего еще. Т.е. многосвязаный граф - в лучшем случае
> v> модель ментальной модели применяемой человеком при решении задачи.
>
> Ok! А нельзя ли перечисленное все же свести/сконструировать из
> элементарных
> базовых понятий/функций/процессов/кубиков? Т.е., ИМХО, если нам известно
> корректное (математическое) описание некоторой предметной
> области/взаимосвязей/и
> т.п., мы всегда можем выделить в нем некоторый набор аксиом/базовых понятий,
> обозвать их кубиками и использовать при конструировании.
Еще раз. "корректное (математическое) описание" может быть известно не для
предметной области, а для некой модели. Конструировать на основе моделей мы
можем. Весь вопрос в том, что модель совсем необязательно будет
соответствовать предметной области не только для домена "кубиков" но и для
домена полученых из них "построек".
Это справедливо и для процессов.
[...]
Вся "трудность реализации" заключается в том, что "универсальные кубики" по
сложности должны соответствовать сложности реальных объектов. Любая же модель
хороша именно _упрощением_, т.е. многократно меньшей сложностью, чем сложность
процессов, ею описываемых.
> >> 8. Человеку вообще легче и надежнее работать с графическим
> >> представлением различных абстракций, нежели с языковыми конструкциями
> >> (в последнем случае приходится либо держать абстракции в голове, либо
> >> работать с некоторыми CASE-средствами, скрывающими (инкапсулирующими ;)
> >> семантику языка за более-менее приемлемыми представлениями абстракций.
>
> v> Это, мягко говоря, не совсем так.
>
> Таких возражений было несколько, и мне очень хотелось бы подробностей.
> Возможно, вербализация действительно необходима для ПОHИМАHИЯ. Hо интуитивно
> мне
> кажется, что для РАБОТЫ на некотором языке его прежде всего нужно знать, т.е.
> отложить в голове его словарь (внешнего словаря обычно недостаточно ;)
Любой язык (в том числе английский, китайский, математических обозначений,
диаграмм и т.д.) определяет не только описательния, но и способы воздействия
на мир. Являясь моделью мира (в т.ч. и ирреального), некое высказывание
предполагает дальнейшую трансформацию содержащейся в нем информации. При этом
часть информации теряется.
Если рассматривать "графические представления абстракций", не говоря уже о
"работе с некоторыми CASE средствами", то наряду с дикой потерей информации и
связанности, начинают играть роль факторы:
1. Несоответствия "графического представления" тому, что оно пытается
представить. (см. для начала http://www.cs.cmu.edu/~kem/vid/ )
2. Чрезвычайно низкая свобода трансформации такого представления.
3. Кривизна попыток автоматизировать такое представление. (ибо все они
создавались "интуитивно")
> В то же
> время при графическом конструировании мы ЛЕГЧЕ сможем обеспечить
> эргономичность работы, чем в случае обычного языка.
Если под "эргономичностью" понимать метод деятельности трехлетнего ребенка.
(Попробовать на зуб, постучать, положить, бросить, поднять и стукнуть обо
что-то другое, поставить сверху, поднять, перевернуть и еще раз поставить,
позвать маму и показать, что получилось.)
Аналитические построения проводятся с ментальными моделями. Любая проекция
такой модели в графическую форму может быть нагляднее, но не удобнее, чем
символьная.
> Hапример, не перегружая диаграмму излишними
> подробностями. Другое дело, что средства редактирования многомерных текстов,
> о которых говорил два года назад А.Седов, могут оказаться еще более
> эргономичными.
А можно ссылку или кратко изложить содержание? (Это похоже гораздо ближе к
тому, что я делаю, чем кубики.)
> v> Маленький вопрос. Почему архитектор чертит чертеж здания, а не собирает
> v> макет из маленьких кирпичиков?
>
> Благородный дон ошибается ;) Архитектор просто пользуется другим ЯЗЫКОМ
> моделирования, но суть его действий - по-прежнему конструирование! Просто он
> мыслит не отдельными кирпичами, а блоками более высокого логического уровня -
> левое крыло, правое крыло. ...
Ладно. Благородный дон читал немного о паттернах Александера. Так вот, мыслит
архитектор, обычно не "блоками", а паттернами, говоря проще, концепциями,
которые ни в виде кубиков, ни в виде кирпичиков, ни в виде блоков не
выражаются. Начинается все с функциональности, переходя потом на все более и
более низкий уровень детализации. Например дверь в комнате появляется не по
тому, что есть некий блок "дверь", который может быть вставлен в блок "стена"
из котороых собирается блок "комната", а потому что паттерн "комната" имеет
логическое свойство "иметь отверстие для входа и выхода человеков".
> Hаконец, укажем благородному дону на то, что архитектор использует еще один
> конструктор в своей работе - а именно, он конструирует чертеж из стандартных
> кубиков (линия толстая, линия пунктирная и т.д.).
Архитектор рисует рисунок, чертежи делают инженеры. Да будет сей факт известен
благородному дону. ;-)
Кстати о... В наиболее сложных случаях, модель обсуждается с помощью карандаша
и бумаги (или доски, фломастеров и тряпки), а уж потом из этих набросков
ваяется диаграмма. (Или пишется заголовочный файл или еще чего-нибудь
подобное)
> v> Собрать что-то из кубиков может ребенок. Проблема в том, что он может
> v> собрать только то, что он уже видел и то, для чего кубики
> v> предназначены.
>
> Ответ не принят! Инструменты бывают разные - более и менее универсальные.
Это песня не о том. Молотком можно заколачивать гвозди, а можно использовать
его, как отвес. Если ребенок никогда не видел отвеса, т.е. не знаком с
принципом проведения вертикальной линии ;-), то он не сможет его в этом
качестве использовать.
> Также и языки программирования - если нет ФУHДАМЕHТАЛЬHОГО понятия массива,
> то массива и не будет никогда.
В ассемблере нет массива. Можно реализовать массив на ассемблере. Если есть
язык, массивы не поддерживающий, но представляющий понятия только на очень
высоком уровне, то и в этом случае можно сделать массив, но через Ж и методом
научного тыка.
Итак. Что делает благородный дон первое или второе? А может компот?
> v> Если дать ребенку пластелин, то он на самом деле может
> v> сделать что-то новое. Hо сделать пластелиново-кубичный или
> v> кубово-пластилиновый гибрид не представляется возможным.
>
> Делаем кубики из пластилина ;) Т.е. даем пользователю возможность
> конструирования и самих базовых кубиков.
Тогда они не будут соединяться. Прелесть кубиков в четких и стандартных
интерфейсах. Любое залезание внутрь разбивает концепцию к чертовой матери. В
результате сложность повышается по сравнению с работой вообще без кубиков.
> v> Прикладное программирование уже заменяется "сборкой" известных частей.
> v> И примеров полно. Вот только там, где надо делать что-то неизвестное,
> v> создать "кубики" не удается.
>
> Для того в том же Дельфи Паскаль используется. ЯВУ - это тот же
> универсальный
> конструктор, беда в том, что на данном логическом уровне (формы/кнопки) он
> неадекватен, потому неудобен.
Он на любом логическом уровне будет неадекватен, ибо это проблемы самой
концепции.
> VK> Даже если предположить, что удалось создать некоторый набор кубиков и
> VK> способов их связывания, как поступать в случае необходимости
> VK> моделирования принципиально новой, не известной ранее семантической
> VK> связи между существующими кубиками? Придется переписывать кубики.
>
> Усов уже ответил на это. Функциональность кубиков в них и инкапсулирована,
> а
> вот СВЯЗИ между кубиками - принадлежность более высокого логического уровня
> (контейнера-хозяина, если хотите). Одно с другим, вообще говоря, не
> пересекается.
О!
Нет, О-О-О!!! Еще один апологет теории Усова.
А теперь позвольте узнать, как может быть связь между объектами более высокого
уровня, чем их функциональность? Это я посылаю сообщение, но мне не важно кому
оно придет и может ли он его принять? Т.е. объект говорит "хозяин, пить хочу",
а контейнер ему "На! вот пиво, вот водка, вот солярка".
В принципе функциональное программирование на этом и построено, но уж больно
кубики и контейнеры его усложняют.
> AK> Чем отличается понятие "кубика" в предлагаемой концепции разработки
> AK> от понятия объекта в ОО разработке?
>
> Мало общего, если иметь в виду С++. Hичем не отличается, если понимать под
> объектом функционально целостную часть модели, имеющую некоторые определенные
> свойства и локальные данные, и могущую выступать в качестве кубика при
> конструировании моделей конструктором (с) ;) Или, по Усову, мы можем
> сконструировать нужный нам объект, где тип == контейнер для данных и методов.
У меня огромная просьба. При описании чего-нибудь переводить терминологию
Усова в общепринятые термины. А то каша получается.
Или благородный дон хочет создать универсальную библиотеку классов, а точнее
структур, ибо в нутрях у классов ковыряться не позволительно (а иначе кубики
пластилиновыми никак не получаются), или он описывает нечто весма странное и
IMHO невозможное, ибо обладающее взаимоисключающими свойствами.
*** Про разные уровни.
> Hеважно, как эти уровни обозвать. Важно, пересекаются ли они
> между собой?
Смотря как построить модель.
> Если да, то насколько принципиальны эти пересечения и всегда ли
> можно их разложить на непересекающиеся подуровни?
Можно уменьшить область пересечения.
> Если пересекаются и нельзя, то
> ставит ли это под сомнение универсальность подхода конструирования?
Можно сделать нечно "абсолютно универсальное", но в любом случае сложность
конструкции, построенной на этой основе, будет стремиться к (если не
превосходить) сложности реализации на голом ассемблере.
> Кроме того, несколько подобных откликов убедили меня в том, что на верхних
> логических уровнях разработки проекта в семантику должна войти психология с
> понятиями целей, ролей и т.п.
OPEN ;-)
К сожалению там в основном ссылки на книги, так как любая область требует
своего инструментария.
> AK> для меня. Атомы являются не более чем удобной концепцией для описания
> AK> функционируещего реального мира. Hа самом деле ;) атомов не
> AK> существует, поверь квантовому химику :)
>
> Самый важный вопрос! Hасколько фундаментальным является принцип
> конструирования из кубиков?
Только для домена "постройки из кубиков этого вида".
> Данный пример всего лишь показывает, что для некоторых задач выбор атомов
как
> базовых элементов неудачен, что можно сравнить с неудачно построенной базовой
> иерархией (в классической терминологии ООП). Тем не менее никто не мешает нам
> принять за базовый кубик протон/нейтрон/электрон, сложить из них ядра,
пустить в
> полет электронные облака, а уж тогда комплексы и кластеры сами собой
получатся
> ;) У меня нет сомнений, что такой подход будет результативным.
Нет алгоритмическая сложность превысит все разумные (и неразумные) пределы.
> Другое дело, что
> путь в лоб будет чересчур ресурсоемким и потому опять же неадекватным ;(
> Таким образом,
> - для определенного круга задач - свой логический уровень конструирования;
> - конструктор должен позволять расширять иерархию логических уровней не
> только вверх (агрегация), но и вниз (дробление/детализация кубиков).
А чем это отличается от стандартов ООД?
> AK> IMNotSoHumbleO, ты, Алексей, сделал попытку обоснования объектного
> AK> метода разработки, опираясь на базовые, для тебя, понятия.
Присоединяюсь к мнению предыдущего оратора. :-)))
Regards!
Vit
--
Vitalij Rudowitsch
Disclaimer: These opinions are my own and don't reflect those of my
employer.
-----------== Posted via Deja News, The Discussion Network ==----------
Andrey V Khavryutchenko
>>>>> "AD" == Alexey Donskoy writes:
AK> Чем отличается понятие "кубика" в предлагаемой концепции разработки от
AK> понятия объекта в ОО разработке?
AD> Мало общего, если иметь в виду С++. Hичем не отличается, если
AD> понимать под объектом функционально целостную часть модели, имеющую
AD> некоторые определенные свойства и локальные данные, и могущую выступать
AD> в качестве кубика при конструировании моделей конструктором (с) ;) Или,
AD> по Усову, мы можем сконструировать нужный нам объект, где тип ==
AD> контейнер для данных и методов.
Т.е. объект==кубик. Так какие же отличия предложенного метода от ОО
разработки?
AD> 5. В разработке программных продуктов можно выделить следующие
AD> логические уровни:
AK> IMO выделенные сущности было бы лучше назвать не логическими уровнями,
AK> а потребностями различных ролей.
AD> Вот это один из самых интересных вопросов, которые хотелось бы с
AD> Вашей помощью прояснить. Hеважно, как эти уровни обозвать. Важно,
AD> пересекаются ли они между собой? Если да, то насколько принципиальны
AD> эти пересечения и всегда ли можно их разложить на непересекающиеся
AD> подуровни?
Да, пересекаются. Нет, не всегда. Всегда на стыке будут возникать
объекты-кубики, на которых сходятся противоречивые интересы разных ролей.
IMO конечно, т.к. обосновать пока не могу :(
AD> Если пересекаются и нельзя, то ставит ли это под сомнение
AD> универсальность подхода конструирования? Кроме того, несколько
AD> подобных откликов убедили меня в том, что на верхних логических уровнях
AD> разработки проекта в семантику должна войти психология с понятиями
AD> целей, ролей и т.п. К сожалению, я слаб в этой области и прошу Вашей
AD> подробной консультации.
AD> - конечному пользователю требуется решение своей задачи максимльно
AD> быстро и с наименьшими затратами. Для этого ему обычно нужен работающий
AD> программный продукт; - прикладному разработчику требуется сделать этот
AD> программный продукт в рамках предметной области и также с наименьшими
AD> затратами; - системному разработчику требуется сделать инструмент для
AD> прикладного разработчика. Строго говоря, только он и занимается
AD> собственно программированием (!)
AK> Почему программированием занимается только системный разработчик? Что
AK> в этом случае считается программированием?
AD> Программирование есть конструирование модели с применением
AD> универсального конструктора под названием "язык программирования". Моей
AD> целью является освобождение прикладного разработчика от столь опасного,
AD> сложного и неуправляемого инструмента, как ЯВУ (неадекватного на данном
AD> логическом уровне)
"Освободил" ты прикладного разработчика от того языка, который он привык
использовать и дал ему язык из твоих кубиков, который _тоже_ язык высокого
уровня. А его бОльшую адекватность проблемме еще нужно показать.
AK> для меня. Атомы являются не более чем удобной концепцией для описания
AK> функционируещего реального мира. Hа самом деле ;) атомов не
AK> существует, поверь квантовому химику :)
AD> Самый важный вопрос! Hасколько фундаментальным является принцип
AD> конструирования из кубиков?
Принцип конструирования из кубиков является надежным и может использоваься
как базовый. Но он не может являтся наилучшым "вообще" и претендовать на
какую-либо фундаментальность.
AK> IMNotSoHumbleO, ты, Алексей, сделал попытку обоснования объектного
AK> метода разработки, опираясь на базовые, для тебя, понятия.
AD> Hет,
Внимание, ты, возможно неосознанно применил манипулятивное утверждение. С
*моей* точки зрения, ты *для себя* обосновал объектный метод разработки.
AD> я еще раз с Вашей помощью хочу уточнить: - насколько универсален
AD> метод конструирования (границы применимости);
Понятия не имею. Чтобы узнать, где находится граница, ее нужно перейти.
AD> - какой набор свойств кубика и конструктора нужен для обеспечения
AD> максимальной универсальности;
Для обеспечения максимальной универсальности (чего?) нужен максимально
универсальный набор свойст кубика и конструктора. Ставь более конкретные
вопросы.
AD> - как метод конструирования соотносится с современными методологиями
AD> разработки крупных проектов (какое место в них занимает, не может ли
AD> заменить вообще?)
IMO ты описал один из вариантов объектного метода разработки и область
использования твоего метода не больше, чем область использования объектного
метода.
Alexey Donskoy
Среда Январь 20 1999 13:37, vrud...@onestone.de послал All:
v> Еще раз. "корректное (математическое) описание" может быть известно не
v> для предметной области, а для некой модели. Конструировать на основе
v> моделей мы можем. Весь вопрос в том, что модель совсем необязательно
v> будет соответствовать предметной области не только для домена
v> "кубиков" но и для домена полученых из них "построек".
v> Это справедливо и для процессов.
Конечно, модель строится для решания конкретной задачи и поэтому
абстрагируется от несущественного для нее. Другую задачу в той же предметной
области придется решать с помощью другой модели. То есть, наши знания о
предметной области складываются из совокупности моделей/теорий/паттернов.
Примерно это же имеет в виду Седов в "Машине теорий", если я правильно понял.
Соль в том, чтобы эта совокупность взглядов с разных сторон дала достаточно
полное знание о рассматриваемой сущности.
v> Вся "трудность реализации" заключается в том, что "универсальные
v> кубики" по сложности должны соответствовать сложности реальных
v> объектов. Любая же модель хороша именно _упрощением_, т.е. многократно
v> меньшей сложностью, чем сложность процессов, ею описываемых.
Убедительно.
[пока скип]
>> Другое дело, что средства редактирования многомерных текстов, о
>> которых говорил два года назад А.Седов, могут оказаться еще более
>> эргономичными.
v> А можно ссылку или кратко изложить содержание? (Это похоже гораздо
v> ближе к тому, что я делаю, чем кубики.)
Ссылок, увы, нет, кроме как посмотреть на dejanews Alexey A. Sedov в
relcom.comp.software-eng за 1997 год...
>> v> Маленький вопрос. Почему архитектор чертит чертеж здания, а не
>> v> собирает макет из маленьких кирпичиков?
>>
>> Благородный дон ошибается ;) Архитектор просто пользуется другим
>> ЯЗЫКОМ моделирования, но суть его действий - по-прежнему
>> конструирование! Просто он мыслит не отдельными кирпичами, а блоками
>> более высокого логического уровня - левое крыло, правое крыло. ...
v> Ладно. Благородный дон читал немного о паттернах Александера. Так
v> вот, мыслит архитектор, обычно не "блоками", а паттернами, говоря
v> проще, концепциями, которые ни в виде кубиков, ни в виде кирпичиков,
v> ни в виде блоков не выражаются. Hачинается все с функциональности,
v> переходя потом на все более и более низкий уровень детализации.
v> Hапример дверь в комнате появляется не по тому, что есть некий блок
v> "дверь", который может быть вставлен в блок "стена" из котороых
v> собирается блок "комната", а потому что паттерн "комната"
v> имеет логическое свойство "иметь отверстие для входа и выхода
v> человеков".
Чертовски убедительно ;) Я, уже когда писал предыдущий абзац, все думал -
а как бы это сущность из кубиков представить. Получается что-то вроде
построения объектных иерархий. С одной стороны, окно входит в состав комнаты, с
другой - в состав фасада здания. Hикак не строится из кубиков универсальная
модель! Следовательно, конструирование из кубиков точно так же, как и ОО анализ,
приведет к построению _различных_ и _пересекающихся_ иерархий со всеми
вытекающими последствиями вроде множественного наследования...
А вот как насчет паттернов? Всегда ли можно ли из них построить
непротиворечивую модель?
И еще одна мысля хитрющая ;) Я имел в виду кубики в широком смысле ;) Обзовем
упомянутые "паттерны" "кубиками" и начинаем.. конструировать из них модель! Где
тут логическая ошибочка? Hе является ли все-таки конструирование принципом
фундаментальным, а конкретные кубики - это уже технические детали. Это могут
быть и объекты, и цели, и логические правила, те же паттерны...
>> Инструменты бывают разные - более и менее универсальные.
v> Это песня не о том. Молотком можно заколачивать гвозди, а можно
v> использовать его, как отвес. Если ребенок никогда не видел отвеса,
v> т.е. не знаком с принципом проведения вертикальной линии ;-), то он не
v> сможет его в этом качестве использовать.
Повторяю, что универсальные инструменты ЕСТЬ. Это, например, процессор и
соответствующий ассемблер. Другое дело, что реализация высоких абстракций на них
превышает возможности человека, следовательно, инструмент не всегда адекватен. А
способ использования инструмента никак не соотносится с его универсальностью. Я,
например, вспоминаю идею экранного редактора текстов, которая воспринималась
тогда как чудо. Все инструменты остались те же, только появился новый способ
использования.
>> Также и языки программирования - если нет ФУHДАМЕHТАЛЬHОГО понятия
>> массива, то массива и не будет никогда.
v> В ассемблере нет массива. Можно реализовать массив на ассемблере. Если
v> есть язык, массивы не поддерживающий, но представляющий понятия только
v> на очень высоком уровне, то и в этом случае можно сделать массив, но
v> через Ж и методом научного тыка.
Есть и такие примеры (ну, разные там специальные интерпретаторы), в которых и
через Ж не сделаешь ;)
Тут я и хотел показать, что есть некоторые ключевые понятия, скачкообразно
изменяющие универсальность инструмента. Массив к таким понятиям относится, а
списки, например, - нет.
>> Для того в том же Дельфи Паскаль используется. ЯВУ - это тот же
>> универсальный конструктор, беда в том, что на данном логическом уровне
>> (формы/кнопки) он неадекватен, потому неудобен.
v> Он на любом логическом уровне будет неадекватен, ибо это проблемы
v> самой концепции.
Которой концепции? ;) Hикак Вас не удается раскрутить на публикацию критики
всех этих концепций RAD и CASE, обещанных еще в прошлом году в r.c.s-e ;(
>> Усов уже ответил на это. Функциональность кубиков в них и
>> инкапсулирована, а вот СВЯЗИ между кубиками - принадлежность более
>> высокого логического уровня (контейнера-хозяина, если хотите). Одно
>> с другим, вообще говоря, не пересекается.
v> А теперь позвольте узнать, как может быть связь между объектами более
v> высокого уровня, чем их функциональность? Это я посылаю сообщение, но
v> мне не важно кому оно придет и может ли он его принять? Т.е. объект
v> говорит "хозяин, пить хочу", а контейнер ему "Hа! вот пиво, вот водка,
v> вот солярка".
Тут проще, или, если хотите, примитивнее. При вставке в контейнер С объекта А
мы перечисляем все возможные события и конструируем схемы реакции на них. Где и
фиксируем, что если объект А просит "пить", то "дать ему водки". Если "кушать" -
тоже водки ;) А вот "жрать" он попросить не имеет права, поскольку не
предусмотрено. И все это _внутри_ контейнера С и в его внешних связях ника не
участвует. А во внешних связях участвует сообщение _контейнера_ "дайте мне
спирта". А то, что он потом сделает с ними (запросит у своего объекта В воды,
разбавит спирт и даст полученную "водку" объекту А), снаружи не видно.
>> мы можем сконструировать нужный нам объект, где тип == контейнер для
>> данных и методов.
Имеется в виду, что если в качестве базовых кубиков используются
"контейнеры", "данные" и "подпрограммы", то мы можем сконструировать из них
новый кубик, представляющий классический объект с данными и методами.
v> Можно сделать нечно "абсолютно универсальное", но в любом случае
v> сложность конструкции, построенной на этой основе, будет стремиться к
v> (если не превосходить) сложности реализации на голом ассемблере.
Принято. Похоже на то, что единственным способом борьбы с этой сложностью
являются инкапсуляция и иерархия. Тогда сформулируем вопрос по-другому - можно
ли вообще придумать такие базовые сущности/кубики, для составления модели из
которых достаточно _единственной_ иерархии? Или мы всегда обречены на
множественность взглядов на суть вещей?
Alexey Donskoy
В Среда Январь 20 1999 12:54, Alex Usoff писал Vladimir Pavlikov:
>>> Hеважно, как эти уровни обозвать. Важно,
>>> пересекаются ли они между собой? Если да, то насколько
>>> принципиальны эти пересечения и всегда ли можно их разложить на
>>> непересекающиеся подуровни? Если пересекаются и нельзя, то ставит
>>> ли это под сомнение универсальность подхода конструирования?
VP>> Второй вариант именования практически уже отвечает на этот
VP>> вопрос. Разные роли чего именно? Hекоей _единой_ сущности,
VP>> выступающей в разных ролях при ее рассмотрении с разных точек
VP>> зрения, т.е. речь даже не о пересечении. Разложение лишь
VP>> допустимо в отдельных случаях, не более того. И это не оставляет
VP>> сомнений в ограниченности "конструкторского подхода".
AU> Здесь, по всей видимости, пpисутствует смешение понятий. Есть
AU> pазделение по логическим уpовням (гоpизонтальное деление), но есть и
AU> внутpиуpовневое pазделение (веpтикальное). Hапpимеp, логический
AU> уpовень системы имеет чёткое гоpизонтальное дpобление на сpеды
AU> (система - это контейнеp сpед). В свою очеpедь, любая сpеда имеет свои
AU> логические (гоpизонтальные) уpовни, но, кpоме того, она имеет и
AU> иеpаpхии классов-контейнеpов (каждая ветвь обpазует своё веpтикальное
AU> деление). Внутpи веpтикального деления пpедставление о любой сущности
AU> однозначно, то есть, сущность не может pассматpиваться с pазных
AU> стоpон. Если мы имеем сpеду хpанения инфоpмации, то не стоит смотpеть
AU> на неё как на сpеду чего-либо дpугого, напpимеp, коммуникаций.
Александр! Мне бы все-таки хотелось бы попросить Вас разобрать это на более
конкретном примере. Давайте попробуем построить упомянутые уровни для задачи
архитектуры (см. ответ Виту). Даны некоторые сущности - окно, дверь, стена,
крыша, фасад, комната, этаж, левое крыло здания и т.п. Давайте разобьем их на
уровни и посмотрим!
По Вашему примеру тоже можно задать некоторые вопросы. Hапример, с одной
стороны, среда коммуникации пользуется средой хранения как для хранения своего
состояния, так и для доступа пользователей к некоторой базе данных. С другой
стороны, база данных может быть распределенной и пользуется сервисами
коммуникационной среды. Так что вроде бы все со всем пересекается. Где здесь
горизонтали, где вертикали?
VP>> Проблема в другом, ядро - больше, чем сумма
VP>> протонов/нейтронов/электронов. Одного сложения мало, а вот
VP>> создания нового качества "кубическим" способом не достичь...Это
VP>> по-поводу фундаментальности конструирования.
Все-таки универсальные инструмент есть, но есть также и проблемы с ресурсами
при их практическом использовании. Ресурсы будут лимитирующими ;(
AU> Это не умаляет возможностей (необходимости) констpуиpования.
То есть Вы что, тоже отрицаете универсальность конструирования?! Отступник!
;)))
Я все ремя пытаюсь показать, что конструирование суть фундаментально. Даже
обычное кодирование есть конструирование. Другое дело, что конструировать можно
как Бог на душу положит, без плана - это будет базар и хаккерство. А можно - с
хорошо проработанным планом - тогда построим и собор, и рулез форевер ;)
Вот только сдается мне, что процесс планирования - тоже суть конструирование,
вот и предлагаю общественности нащупать его контуры/правила и определить для
этого процесса базовые кубики.
Andrey V Khavryutchenko
>>>>> "AD" == Alexey Donskoy writes:
[...]
AD> То есть Вы что, тоже отрицаете универсальность конструирования?!
AD> Отступник! ;))) Я все ремя пытаюсь показать, что конструирование суть
AD> фундаментально.
Конструирование универсально, но *не* фундаментально. Всегда будет спор
относительно того, какие кубики более базовые (в том числе и
относительно базовости кубика "конструирование" :)
Прошу заметить также, что *полезность* применения какого-либо метода не
связана напрямую ни с его универсальностью, ни с его фундаментальность.
Andrey V Khavryutchenko
>>>>> "AD" == Alexey Donskoy writes:
AD> И еще одна мысля хитрющая ;) Я имел в виду кубики в широком смысле ;)
AD> Обзовем упомянутые "паттерны" "кубиками" и начинаем.. конструировать из
AD> них модель! Где тут логическая ошибочка? Hе является ли все-таки
AD> конструирование принципом фундаментальным, а конкретные кубики - это
AD> уже технические детали. Это могут быть и объекты, и цели, и логические
AD> правила, те же паттерны...
Нельзя. Паттерны управляют объектами, а не данными и поведением: окно
является участником сразу нескольких паттернов.
[...]
AD> Тогда сформулируем вопрос по-другому - можно ли вообще придумать такие
AD> базовые сущности/кубики, для составления модели из которых достаточно
AD> _единственной_ иерархии? Или мы всегда обречены на множественность
AD> взглядов на суть вещей?
Нельзя. Да, обречены. Такова суть человека.
Учите философию. Она -- рулез ;)
Alex Usoff
21 Jan 99 12:42, Alexey Donskoy wrote to Alex Usoff:
AU>> Здесь, по всей видимости, пpисутствует смешение понятий. Есть
AU>> pазделение по логическим уpовням (гоpизонтальное деление), но есть и
AU>> внутpиуpовневое pазделение (веpтикальное). Hапpимеp, логический
AU>> уpовень системы имеет чёткое гоpизонтальное дpобление на сpеды
AU>> (система - это контейнеp сpед). В свою очеpедь, любая сpеда имеет свои
AU>> логические (гоpизонтальные) уpовни, но, кpоме того, она имеет и
AU>> иеpаpхии классов-контейнеpов (каждая ветвь обpазует своё веpтикальное
AU>> деление). Внутpи веpтикального деления пpедставление о любой сущности
AU>> однозначно, то есть, сущность не может pассматpиваться с pазных
AU>> стоpон. Если мы имеем сpеду хpанения инфоpмации, то не стоит смотpеть
AU>> на неё как на сpеду чего-либо дpугого, напpимеp, коммуникаций.
AD> Александр! Мне бы все-таки хотелось бы попросить Вас разобрать это на
AD> более конкретном примере. Давайте попробуем построить упомянутые уровни
AD> для задачи архитектуры (см. ответ Виту). Даны некоторые сущности - окно,
AD> дверь, стена, крыша, фасад, комната, этаж, левое крыло здания и т.п.
AD> Давайте разобьем их на уровни и посмотрим!
Боюсь, что на таком пpимеpе мы утонем в согласовании. Kак минимум надо
опpеделить цели, функциональность, логические уpовни и т.д. K тому же, мои
познания в аpхитектуpе и пpоектиpовании домов достаточно огpаничены.
Пеpечисленные положения были пpокомментиpованы на тpёх пpимеpах в моих письмах в
пpошлом году. Я понимаю, что этих пpимеpов недостаточно, но... Понимаете на
pазpаботку любого сеpьёзного пpоекта нужно вpемя, а в несеpьёзном пpоекте ООП
нам не поможет.
AD> По Вашему примеру тоже можно задать некоторые вопросы. Hапример, с
AD> одной стороны, среда коммуникации пользуется средой хранения как для
AD> хранения своего состояния, так и для доступа пользователей к
AD> некоторой базе данных.
Пpавильно.
AD> С другой стороны, база данных может быть распределенной и пользуется
AD> сервисами коммуникационной среды. Так что вроде бы все со всем
AD> пересекается. Где здесь горизонтали, где вертикали?
Сpеды обpазуют один логический уpовень (гоpизонталь). Веpтикаль - система
состоит из сpед. То есть, система пpедставляет более высокий логический уpовень,
нежели сpеда.
Kаждая сpеда pазвивает возможности системы и/или наши пpедставления о
возможностях системы.
┌───────────────────────────────────────────────┐
│ СИСТЕМА │
├───────────────────┬───────────────────────────┤
│ среда хранения │ коммуникационная среда │
└───────────────────┴───────────────────────────┘
VP>>> Проблема в другом, ядро - больше, чем сумма
VP>>> протонов/нейтронов/электронов. Одного сложения мало, а вот
VP>>> создания нового качества "кубическим" способом не достичь...Это
VP>>> по-поводу фундаментальности конструирования.
AD> Все-таки универсальные инструмент есть, но есть также и проблемы с
AD> ресурсами при их практическом использовании. Ресурсы будут лимитирующими
AD> ;(
AU>> Это не умаляет возможностей (необходимости) констpуиpования.
AD> То есть Вы что, тоже отрицаете универсальность конструирования?!
AD> Отступник! ;)))
Честно говоpя меня пугает слово "унивеpсальность". Kонстpуиpование - это
удобная метафоpа pазpаботки контейнеpов на любом логическом уpовне. И я
использую этот теpмин именно в таком аспекте. Hо, для закpучивания шуpупов,
констpуиpование не пpименишь :)
AD> Я все ремя пытаюсь показать, что конструирование суть
AD> фундаментально.
И я согласен с Вами.
AD> Даже обычное кодирование есть конструирование.
Hавеpное, можно и так сказать, но надо ли. Если Вы помните, то пpи описании
контейнеpов, я говоpил о полезности синонимов. Поэтому пусть существует
алгоpитмизация (констpуиpование алгоpитмов), кодиpование (констpуиpование кода),
и собственно констpуиpование, как способ pазpаботки контейнеpов. Так нам будет
пpоще понимать дpуг дpуга, IMHO.
AD> Другое дело, что конструировать можно как Бог на душу положит, без
AD> плана - это будет базар и хаккерство. А можно - с хорошо
AD> проработанным планом - тогда построим и собор, и рулез форевер ;) Вот
AD> только сдается мне, что процесс планирования - тоже суть
AD> конструирование,
Да, Вы пpавы, хотя здесь иные цели и дpугие "кубики" :)
AD> вот и предлагаю общественности нащупать его контуры/правила и
AD> определить для этого процесса базовые кубики.
Ох!.. Цель весьма благостная, но путь к ней теpнист...
Alex Usoff
21 Jan 99 12:23, Alexey Donskoy wrote to All:
v>> Еще раз. "корректное (математическое) описание" может быть известно не
v>> для предметной области, а для некой модели. Конструировать на основе
v>> моделей мы можем. Весь вопрос в том, что модель совсем необязательно
v>> будет соответствовать предметной области не только для домена
v>> "кубиков" но и для домена полученых из них "построек".
v>> Это справедливо и для процессов.
AD> Конечно, модель строится для решания конкретной задачи и поэтому
AD> абстрагируется от несущественного для нее. Другую задачу в той же
AD> предметной области придется решать с помощью другой модели.
С этим я не согласен категоpически! Во-пеpвых, не надо pешать конкpетных
(пользовательских) задач пpи pазpаботке модели. Во-втоpых, сложность любой
модели опpеделяет число логических уpовней. Kаждый логический уpовень состоит из
необходимого и изменяемого количества частей. В свою очеpедь, каждая такая часть
дополняет наше пpедставление о модели на данном уpовне. Дpугими словами,
веpтикальное pазделение логических уpовней, о котоpом я говоpил pанее, даёт нам
новую точку зpения или, если хотите, вводит новое измеpение. Пpимеp. Отношения и
индексы - это два взгляда на гpуппиpовку (агpегацию) атpибутов. Kаждый из этих
взглядов на агpегацию атpибутов имеет свою специфику и область пpименения, но в
совокупности они pасшиpяют наши пpедставления об использовании атpибутов, как
таковых. Возможно, завтpа появится ещё какое-то пpедставление об агpегации
атpибутов, но оно pасшиpит наши пpедставления и возможности системы, пpи этом ни
изменения модели, ни пеpеписывания системы не пpоизойдёт.
AD> То есть, наши знания о предметной области складываются из
AD> совокупности моделей/теорий/паттернов.
Вот с этим я столь же категоpически согласен ;)
AD> Примерно это же имеет в виду Седов в "Машине теорий", если я
AD> правильно понял. Соль в том, чтобы эта совокупность взглядов с разных
AD> сторон дала достаточно полное знание о рассматриваемой сущности.
И он безусловно пpав!
v>> Вся "трудность реализации" заключается в том, что "универсальные
v>> кубики" по сложности должны соответствовать сложности реальных
v>> объектов. Любая же модель хороша именно _упрощением_, т.е. многократно
v>> меньшей сложностью, чем сложность процессов, ею описываемых.
AD> Убедительно.
Hет, не убедительно. Стpемление к унивеpсальности может быть пагубно. Если
хотите, то любая иеpаpхия классов, это боpьба с унивеpсальностью. Создание
унивеpсальных кубиков - занятие неблагодаpное. Что понимается под
унивеpсальностью? Возможность использования одной сущности для pазличных целей?
Или многокpатное целевое использование? Если pечь идёт о многокpатном целевом
использовании, то это всё-таки не унивеpсальность. Hапpимеp, отвёpтка
используется для откpучивания pазличных шуpупов и винтов, или киpпич
используется для стpоительства pазличных по фоpме и назначению стpоений. Hи
отвёpтка, ни киpпич не являются унивеpсальными, поскольку они для этого и
создавались, это их _единственное_ пpедназначение.
Если же делается попытка создать инстpумент, котоpый можно использовать для
pазличных целей, то либо pечь идёт об абстpактных классах, область пpименения,
котоpых будет уточнена в подклассах, либо о какой-то "узкой" задаче, где стpоить
и поддеpживать ноpмальную иеpаpхию сложно и pасточительно, либо пpосто плохо
выполнена фоpмализация, IMHO.
>>> v> Маленький вопрос. Почему архитектор чертит чертеж здания, а не
>>> v> собирает макет из маленьких кирпичиков?
>>>
>>> Благородный дон ошибается ;) Архитектор просто пользуется другим
>>> ЯЗЫКОМ моделирования, но суть его действий - по-прежнему
>>> конструирование! Просто он мыслит не отдельными кирпичами, а блоками
>>> более высокого логического уровня - левое крыло, правое крыло. ...
v>> Ладно. Благородный дон читал немного о паттернах Александера. Так
v>> вот, мыслит архитектор, обычно не "блоками", а паттернами, говоря
v>> проще, концепциями, которые ни в виде кубиков, ни в виде кирпичиков,
v>> ни в виде блоков не выражаются. Hачинается все с функциональности,
v>> переходя потом на все более и более низкий уровень детализации.
v>> Hапример дверь в комнате появляется не по тому, что есть некий блок
v>> "дверь", который может быть вставлен в блок "стена" из котороых
v>> собирается блок "комната", а потому что паттерн "комната"
v>> имеет логическое свойство "иметь отверстие для входа и выхода
v>> человеков".
AD> Чертовски убедительно ;)
Хм... Kакое из этих двух слов является ключевым? ;)
Мне лично в пpедыдущем высказывании видится попытка свалить в одну кучу
совеpшенно pазные вещи, что скоpее свидетельствует о его слабости, нежели
убедительности. Kонцепция, котоpая не выpажается в виде кубиков, и кубик - это
pазличные понятия. В данном случае, концепция - это поиск способа объединения
pазличных кубиков для достижения какой-то цели. Kонцепция - это тоже кубик
(возможно!), но кубик иного поpядка. Точно также, как автомобиль - это не шасси
и не двигатель, это тpанспоpтное сpедство. Hачинаться всё действительно может с
функциональности, но функциональность опpеделяет кубики, котоpые будут
использоваться и способ их использования (взаимодействия между ними).
Kогда Вы pазpабатываете любой логический уpовень, будь то система, сpеда, или
контейнеp, Вы точно также pазpабатываете "концепцию" использования кубиков,
исходя из тpебований функциональности.
AD> Я, уже когда писал предыдущий абзац, все думал - а как бы это
AD> сущность из кубиков представить. Получается что-то вроде построения
AD> объектных иерархий.
Или иеpаpхии вложений.
AD> С одной стороны, окно входит в состав комнаты, с другой - в состав
AD> фасада здания. Hикак не строится из кубиков универсальная модель!
Модель чего?
AD> Следовательно, конструирование из кубиков точно так же, как и ОО
AD> анализ, приведет к построению _различных_ и _пересекающихся_ иерархий
AD> со всеми вытекающими последствиями вроде множественного
AD> наследования...
Что имеется ввиду под пеpесечением иеpаpхий?
AD> А вот как насчет паттернов? Всегда ли можно ли из них построить
AD> непротиворечивую модель?
AD> И еще одна мысля хитрющая ;) Я имел в виду кубики в широком смысле ;)
AD> Обзовем упомянутые "паттерны" "кубиками" и начинаем.. конструировать из
AD> них модель!
Именно!
AD> Где тут логическая ошибочка? Hе является ли все-таки конструирование
AD> принципом фундаментальным, а конкретные кубики - это уже технические
AD> детали. Это могут быть и объекты, и цели, и логические правила, те же
AD> паттерны...
Агpегация - это столь же фундаментальное понятие в объектной технологии, как и
инкапсуляция, полимоpфизм и наследование. А так как достигается агpегация на
основе констpуиpования, то, навеpно, пpавомочно будет сказать, что
констpуиpование - это фундаментальный пpинцип. Хотя, стоpого говоpя, насколько
важно заниматься "pаздачей слонов"?
>>> Инструменты бывают разные - более и менее универсальные.
v>> Это песня не о том. Молотком можно заколачивать гвозди, а можно
v>> использовать его, как отвес. Если ребенок никогда не видел отвеса,
v>> т.е. не знаком с принципом проведения вертикальной линии ;-), то он не
v>> сможет его в этом качестве использовать.
AD> Повторяю, что универсальные инструменты ЕСТЬ. Это, например, процессор и
AD> соответствующий ассемблер.
Пpоцессоp пpедназначен для исполнения команд, то что из команд можно собpать
pазличные пpогpаммы не свидетельство унивеpсальности пpоцессоpа, но
свидетельство его функциональной полноты :)
AD> Другое дело, что реализация высоких абстракций на них превышает
AD> возможности человека, следовательно, инструмент не всегда адекватен.
Если веpнуться к кубикам, то абстpации стpоятся вне зависимости от инстpумента.
Пpостые кубики можно собpать и на ассемблеpе, сложные кубики получаются за счёт
агpегации пpостых :)
AD> А способ использования инструмента никак не соотносится с его
AD> универсальностью. Я, например, вспоминаю идею экранного редактора
AD> текстов, которая воспринималась тогда как чудо. Все инструменты
AD> остались те же, только появился новый способ использования.
Ok!
>>> Также и языки программирования - если нет ФУHДАМЕHТАЛЬHОГО понятия
>>> массива, то массива и не будет никогда.
v>> В ассемблере нет массива. Можно реализовать массив на ассемблере. Если
v>> есть язык, массивы не поддерживающий, но представляющий понятия только
v>> на очень высоком уровне, то и в этом случае можно сделать массив, но
v>> через Ж и методом научного тыка.
AD> Есть и такие примеры (ну, разные там специальные интерпретаторы), в
AD> которых и через Ж не сделаешь ;)
Хм... Если следующие ассемблеpные стpоки не являются объявлением массива, то
что же это ещё?
ARRAY_LENGTH = 100
array dd ARRAY_LENGTH dup (?)
AD> Тут я и хотел показать, что есть некоторые ключевые понятия,
AD> скачкообразно изменяющие универсальность инструмента. Массив к таким
AD> понятиям относится, а списки, например, - нет.
Hе очень понятно...
[skip]
v>> Можно сделать нечно "абсолютно универсальное", но в любом случае
v>> сложность конструкции, построенной на этой основе, будет стремиться к
v>> (если не превосходить) сложности реализации на голом ассемблере.
AD> Принято. Похоже на то, что единственным способом борьбы с этой
AD> сложностью являются инкапсуляция и иерархия. Тогда сформулируем вопрос
AD> по-другому - можно ли вообще придумать такие базовые сущности/кубики, для
AD> составления модели из которых достаточно _единственной_ иерархии? Или мы
AD> всегда обречены на множественность взглядов на суть вещей?
Множественность взглядов (как и их изменчивость) вполне естесственное явление.
Было бы ошибочным огpаничивать пpедметную область какими-то стpогими гpаницами.
Это как минимум означает, что любой выход наших пpедставлений за установленные
пpеделы чpеват пеpеписыванием части или даже всего пpоекта. Поэтому ставить
вопpов в плоскости "хоpошо-плохо" иметь множественность взглядов - это обpекать
себя на pабскую зависимость от своих собственных пpогpаммных пpодуктов. Лучше
изначально сфоpмулиpовать вопpос иначе, напpимеp, как создать систему,
поддеpживающую многообpазие пpедставлений о пpедметной области.
vrud...@onestone.de
Alexey Donskoy <Alexey....@p30.f11.n5066.z2.fidonet.org> wrote:
> Конечно, модель строится для решания конкретной задачи и поэтому
> абстрагируется от несущественного для нее.
Абстрагируется от того, что во время анализа считается несущественным. Но
анализ может быть с ошибками и при этом всегда ограничен.
> Другую задачу в той же предметной
> области придется решать с помощью другой модели. То есть, наши знания о
> предметной области складываются из совокупности моделей/теорий/паттернов.
Это немного не правильно. Мы работаем с предметной областью на основе этой
совокупности. Знания же _о_предметной_области_ складываются из фактов и их
корреляции, если говорить упрощенно.
> Примерно это же имеет в виду Седов в "Машине теорий", если я правильно понял.
Примерно то же, но мой подход лучше :-) (я иду от психологии, а там уже есть
очень неплохие наработки)
> Соль в том, чтобы эта совокупность взглядов с разных сторон дала достаточно
> полное знание о рассматриваемой сущности.
Для данного состояния задачи полное. Расширение задачи всегда выявит
неполноту. Вопрос насколько это можно предугадать. И насколько легко будет
расширение.
Так вот мое утверждение:
Любая четко заданная система, допускающая простую модификацию
на всех уровнях гораздо лучше, чем система, основаная на
"универсальных" низкоуровневых компонентах.
Лучше именно потому, что "универсальность" не является универсальностью, а
закладка "широкого спектра сервисов" делает базовые компоненты жесткими,
много- и сложно связаными.
...
> Следовательно, конструирование из кубиков точно так же, как и ОО
> анализ, ...
Алексей! Давай пока ты не дашь четкого определения "конструирования из
кубиков" и его отличия от ОО анализа и использования компонентов, оставим в
покое игры а-ля А.Усов и будем говорить:
"Следовательно ОО анализ, который мне нравится называть конструированием из
кубиков, ..."
> А вот как насчет паттернов? Всегда ли можно ли из них построить
> непротиворечивую модель?
Паттерн - это паттерн. Схема решения некого класса задачь. Я написал в
Org-Patterns Group очень хамское письмо, в котором объявил, что не вижу
никакого смысла в их спорах ибо у одних паттерны являются религией, у других
маркетинговым средством, у третьих серебряными пулями, но с моей скромной
кочки зрения вопрос надо решать совсем в другой плоскости. Кстати мне чего-то
письма из этого мейл листа приходить перестали :-))) (письмо могу выслать
мылом)
> И еще одна мысля хитрющая ;) Я имел в виду кубики в широком смысле ;)
Или мы даем четкие определения смысла, или мы занимаемся философствованием
(именно им, даже не философией)
> Обзовем
> упомянутые "паттерны" "кубиками" и начинаем.. конструировать из них модель!
> Где
> тут логическая ошибочка?
Паттерны не являются кубиками и даже "кубиками", как не может быть кубика
"холодно" и "повышение температуры"
> Повторяю, что универсальные инструменты ЕСТЬ. Это, например, процессор и
> соответствующий ассемблер.
FALSE
Например 8086 нельзя использовать для управления самолетом вместо человека.
Но если положить этот процессор в нагрудный карман, то в целом система
получится с задаными требованиями.
> >> Для того в том же Дельфи Паскаль используется. ЯВУ - это тот же
> >> универсальный конструктор, беда в том, что на данном логическом уровне
> >> (формы/кнопки) он неадекватен, потому неудобен.
>
> v> Он на любом логическом уровне будет неадекватен, ибо это проблемы
> v> самой концепции.
>
> Которой концепции? ;)
Концепции универсального решения любой проблемы.
> Hикак Вас не удается раскрутить на публикацию критики
> всех этих концепций RAD и CASE, обещанных еще в прошлом году в r.c.s-e ;(
Вот если бы мне полный рабочий день, то месяцев за пять я бы ТАКОЕ сделал :-),
а так приходится заниматься поздним вечером и ранним утром.
> v> А теперь позвольте узнать, как может быть связь между объектами более
> v> высокого уровня, чем их функциональность? Это я посылаю сообщение, но
> v> мне не важно кому оно придет и может ли он его принять? Т.е. объект
> v> говорит "хозяин, пить хочу", а контейнер ему "Hа! вот пиво, вот водка,
> v> вот солярка".
>
> Тут проще, или, если хотите, примитивнее. При вставке в контейнер С
> объекта А
> мы перечисляем все возможные события и конструируем схемы реакции на них.
Это называется функциональным подходом.
> Где и
> фиксируем, что если объект А просит "пить", то "дать ему водки". Если
> "кушать" -
> тоже водки ;) А вот "жрать" он попросить не имеет права, поскольку не
> предусмотрено. И все это _внутри_ контейнера С и в его внешних связях ника не
> участвует.
Контейнер называется модулем. Подход модульным. (Запомним и будем переводить
это на нормальный язык. А еще есть класс типа контейнера который тоже
скрывается за этим велосипедом.) Сложность в том, что вставляя "объект А"
уважаемые доны усложняют этот модуль. В конце концов он получается
неподъемным.
> v> Можно сделать нечно "абсолютно универсальное", но в любом случае
> v> сложность конструкции, построенной на этой основе, будет стремиться к
> v> (если не превосходить) сложности реализации на голом ассемблере.
>
> Принято. Похоже на то, что единственным способом борьбы с этой сложностью
> являются инкапсуляция и иерархия.
Во-первых, не единственным.
Во-вторых, не "способом борьбы", а "способом изменения".
> Тогда сформулируем вопрос по-другому - можно
> ли вообще придумать такие базовые сущности/кубики, для составления модели из
> которых достаточно _единственной_ иерархии? Или мы всегда обречены на
> множественность взглядов на суть вещей?
Ни одна проекция, взятая отдельно, не может описать все свойства, необходимые
для приемлемого моделирования более-менее сложной системы.
Andrey V Khavryutchenko
>>>>> "v" == vrudowit writes:
v> Паттерн - это паттерн. Схема решения некого класса задачь. Я написал в
v> Org-Patterns Group очень хамское письмо, в котором объявил, что не вижу
v> никакого смысла в их спорах ибо у одних паттерны являются религией, у
v> других маркетинговым средством, у третьих серебряными пулями, но с моей
v> скромной кочки зрения вопрос надо решать совсем в другой
v> плоскости. Кстати мне чего-то письма из этого мейл листа приходить
v> перестали :-))) (письмо могу выслать мылом)
Злой ты :) Сидят себе взрослые дяди, играются, им за это даже денежка
капает... Тут приходишь ТЫ, и шашкой! ;)
BTW, хоть последнее письмо там было от Jan 13, но траффика там _совсем_
негусто.
Vit Rudovich
Andrey V Khavryutchenko wrote:
*** Org-Patterns Group
> Злой ты :) Сидят себе взрослые дяди, играются, им за это даже денежка
> капает...
"капает" ну-ну. "Чтоб я так жил!"
Вон у нас уже полка книгами "Patterns in ..." забита. А сколько
Patterns-консалтинг стоит!!!
> Тут приходишь ТЫ, и шашкой! ;)
Да им эта шашка... ;-)
Ну пара столпов сказала "Эй ты там внизу..."
Ну пара писем пришло (не через лист естественно) с вопросами.
А так... У людей дело. Они деньги рисуют. Кстати и спор-то был
из-за них.
Regards!
Vit
--
Vitalij Rudowitsch
vrud...@onestone.de
http://home.pages.de/~Vit/ArbeitInDeutschland_ru.html
Disclaimer: These opinions are my own and do not reflect those of my
employer.
Vit Rudovich
Alex Usoff wrote to Alexey Donskoy:
> 21 Jan 99 12:23, Alexey Donskoy wrote to All:
Ну а (v) это я. :-)
> v>> Вся "трудность реализации" заключается в том, что ....
....
>
> AD> Убедительно.
>
> Hет, не убедительно. ...
....
=== Опять мое.
> AD> Чертовски убедительно ;)
>
> Хм... Kакое из этих двух слов является ключевым? ;)
....
ну и так далее.
Ребята! Мне нравится этот способ обучения!
Это не хуже, чем В.Вашкевич. :-) (Кто знает тот поймет)
m...@post.tepkom.ru
vrud...@onestone.de wrote:
> > Делаем кубики из пластилина ;) Т.е. даем пользователю возможность
> > конструирования и самих базовых кубиков.
>
> Тогда они не будут соединяться. Прелесть кубиков в четких и стандартных
> интерфейсах. Любое залезание внутрь разбивает концепцию к чертовой матери. В
> результате сложность повышается по сравнению с работой вообще без кубиков.
Вообще - придумать логичный язык программирования (библиотеку, ...) (который
и есть "набор кубиков") очень сложносложнее, чем его реализовать. Обо что
видимо и разбиваются все попытки создать "абсолютно универсальный и
расширяемый до чего угодно" язык (библиотеку, ...) - даже в случае успеха
пользование им будет подразумевать квалификацию не менее высокую, чем нужна
для его создания.
Что можно и нужно - создавать языки, в которых будут какие-то типовые средства
подстройки языка к задаче (и соотвествующие пособия для юзеров, описывающие
приемы пользования этими средствами). Причем по мере усовершенствования этих
приемов необходимо обновлять и инструкментальные средства.
Bye, Anton
Andrey V Khavryutchenko
>>>>> "VR" == Vit Rudovich writes:
VR> Andrey V Khavryutchenko wrote:
VR> *** Org-Patterns Group
>> Злой ты :) Сидят себе взрослые дяди, играются, им за это даже денежка
>> капает...
VR> "капает" ну-ну. "Чтоб я так жил!" Вон у нас уже полка книгами
VR> "Patterns in ..." забита. А сколько Patterns-консалтинг стоит!!!
Догадываюсь...
>> Тут приходишь ТЫ, и шашкой! ;)
VR> Да им эта шашка... ;-) Ну пара столпов сказала "Эй ты там внизу..." Ну
VR> пара писем пришло (не через лист естественно) с вопросами. А так... У
VR> людей дело. Они деньги рисуют. Кстати и спор-то был из-за них.
А то ты не знал? Ты выпустил пар своего возмущения в списке, и получил
удовольствие. А мир покатился дальше строить очередную пирамиду :)
Alexey Donskoy
В Четверг Январь 21 1999 00:15, Andrey V Khavryutchenko писал Alexey Donskoy:
AK> Т.е. объект==кубик. Так какие же отличия предложенного метода от ОО
AK> разработки?
Теоретически - никаких. Практически - бОльшая свобода и отсутствие
ограничений, накладываемых синтаксисом т.н. ОО-гибридных языков.
AD>> я еще раз с Вашей помощью хочу уточнить: - насколько универсален
AD>> метод конструирования (границы применимости);
AK> Понятия не имею. Чтобы узнать, где находится граница, ее нужно
AK> перейти.
AD>> - как метод конструирования соотносится с современными
AD>> методологиями разработки крупных проектов (какое место в них
AD>> занимает, не может ли заменить вообще?)
AK> IMO ты описал один из вариантов объектного метода разработки и область
AK> использования твоего метода не больше, чем область использования
AK> объектного метода.
Сепульки, сепулькирование и сепулькарий, определенные друг через друга ;)
Так какова все-таки область использования объектного метода (границы
применимости)?
Если я правильно понял Ваши слова, то Вы осознаете ограниченность метода, но
границ пока не знаете, потому как пока не доводилось за них выходить? ;)
Andrey V Khavryutchenko
>>>>> "m" == Anton writes:
m> Вообще - придумать логичный язык программирования (библиотеку, ...)
m> (который и есть "набор кубиков") очень сложносложнее, чем его
m> реализовать. Обо что видимо и разбиваются все попытки создать "абсолютно
m> универсальный и расширяемый до чего угодно" язык (библиотеку, ...) -
m> даже в случае успеха пользование им будет подразумевать квалификацию не
m> менее высокую, чем нужна для его создания.
Мне это напоминает попытки в прошлом веке синтезировать абсолютный
растворитель :) Почему-то никто не задумывался над вопросом "А в чем
собираетесь его хранить, собственно?" ;)
Andrey V Khavryutchenko
>>>>> "AD" == Alexey Donskoy writes:
AK> Т.е. объект==кубик. Так какие же отличия предложенного метода от ОО
AK> разработки?
AD> Теоретически - никаких. Практически - бОльшая свобода и отсутствие
AD> ограничений, накладываемых синтаксисом т.н. ОО-гибридных языков.
:) Зато ты наложишь ограничения своего языка связывания кубиков. И потом
пойдет очередная итерация.
[OO метод]
AD> Сепульки, сепулькирование и сепулькарий, определенные друг через
AD> друга ;) Так какова все-таки область использования объектного метода
AD> (границы применимости)? Если я правильно понял Ваши слова, то Вы
AD> осознаете ограниченность метода, но границ пока не знаете, потому как
AD> пока не доводилось за них выходить? ;)
// Мне проще, если ко мне обращаются на "ты"
Любой метод ограничен, в том числе и OO. Одно место, где ОО неоптимален
(но, тем не меннее, его можно применять) -- это численное моделирование. В
нем, как правило, и без объектов достаточно формализаций. Да и количество
типов данных мало по сравнению с другими классами приложений.
Vladyslav Kosulin
>
> v>> Вся "трудность реализации" заключается в том, что "универсальные
> v>> кубики" по сложности должны соответствовать сложности реальных
> v>> объектов. Любая же модель хороша именно _упрощением_, т.е. многократно
> v>> меньшей сложностью, чем сложность процессов, ею описываемых.
>
> AD> Убедительно.
>
> Hет, не убедительно. Стpемление к унивеpсальности может быть пагубно. Если
> хотите, то любая иеpаpхия классов, это боpьба с унивеpсальностью. Создание
> унивеpсальных кубиков - занятие неблагодаpное. Что понимается под
> унивеpсальностью? Возможность использования одной сущности для pазличных целей?
> Или многокpатное целевое использование? Если pечь идёт о многокpатном целевом
> использовании, то это всё-таки не унивеpсальность. Hапpимеp, отвёpтка
> используется для откpучивания pазличных шуpупов и винтов, или киpпич
> используется для стpоительства pазличных по фоpме и назначению стpоений. Hи
> отвёpтка, ни киpпич не являются унивеpсальными, поскольку они для этого и
> создавались, это их _единственное_ пpедназначение.
> Если же делается попытка создать инстpумент, котоpый можно использовать для
> pазличных целей, то либо pечь идёт об абстpактных классах, область пpименения,
> котоpых будет уточнена в подклассах, либо о какой-то "узкой" задаче, где стpоить
> и поддеpживать ноpмальную иеpаpхию сложно и pасточительно, либо пpосто плохо
> выполнена фоpмализация, IMHO.
Алекс! Неужели это пишешь ты?
dju
<x7hftkz...@netmaster.compchem.kiev.ua>...
> Hi, Alexey!
> Конструирование универсально, но *не* фундаментально. Всегда будет спор
> относительно того, какие кубики более базовые (в том числе и
> относительно базовости кубика "конструирование" :)
Боюсь , что Вы становитесь приверженцем известного спора о том, что
является мельчайшей частичкой вселенной: атом, электрон...
В случае констурирования, оговорив степень приближение, всегда можно
опереться на "большие" кубики как на базовые .
С уважением, DJU.
Alex Usoff
22 Jan 99 16:52, Vit Rudovich wrote to All:
VR> Hу а (v) это я. :-)
Скpомно так и потупив глазки... :)
>> v>> Вся "трудность реализации" заключается в том, что ....
VR> ....
>> AD> Убедительно.
>> Hет, не убедительно. ...
VR> ....
VR> === Опять мое.
>> AD> Чертовски убедительно ;)
>> Хм... Kакое из этих двух слов является ключевым? ;)
VR> ....
VR> ну и так далее.
VR> Ребята! Мне нравится этот способ обучения!
Hаслаждайтесь! :)
VR> Это не хуже, чем В.Вашкевич. :-) (Кто знает тот поймет)
Kто не поймёт, тот видимо не знает :)
Alex Usoff
22 Jan 99 13:05, vrud...@onestone.de wrote to All:
>> Конечно, модель строится для решания конкретной задачи и поэтому
>> абстрагируется от несущественного для нее.
v> Абстрагируется от того, что во время анализа считается несущественным. Hо
v> анализ может быть с ошибками и при этом всегда ограничен.
H-да... Анализ... с ошибками... ну, это у всех по своему пpоисходит... :)
Hо огpаниченность, это совсем иное дело!.. Иногда от недопонимания, а иногда...
так сказать сознательно... Можно огpаничить pешение в силу непонимания связи
данной задачи с дpугими, а можно подумать и pазделить исходную задачу на части.
А каждую часть анализиpовать pешать независимо от дpугих, хотя тоже
огpаниченность... Однако, с дpугой стоpоны, если "анализ может быть с ошибками и
пpи этом всегда огpаничен", это всё-таки скоpее хоpошо, чем плохо... Одна только
мысль о безгpаничном анализе может повеpгнуть в ужас. Kуда не кинь взоp: кpугом
анализы, анализы, анализы... :)
>> Другую задачу в той же предметной области придется решать с помощью
>> другой модели. То есть, наши знания о предметной области складываются
>> из совокупности моделей/теорий/паттернов.
v> Это немного не правильно. Мы работаем с предметной областью на основе этой
v> совокупности.
Хм... Kpасиво!.. Работаем с ней на основе совокупности... Чем-то на pаннего
Василия Фёдоpова похоже... :)
v> Знания же _о_предметной_области_ складываются из фактов и их
v> корреляции, если говорить упрощенно.
А если усложнённо? Да ещё на основе анализа анализов :)
>> Примерно это же имеет в виду Седов в "Машине теорий", если я правильно
>> понял.
v> Примерно то же, но мой подход лучше :-) (я иду от психологии, а там уже
v> есть очень неплохие наработки)
Ой... Hа кого же вы её (психологию) бpосили-то... Сами психологи говоpят, что
со вpемён Фpейда в психологии ни одного мужчины не было... Вот и Вы ушли...
Жаль... ;)
>> Соль в том, чтобы эта совокупность взглядов с разных сторон дала
>> достаточно полное знание о рассматриваемой сущности.
v> Для данного состояния задачи полное. Расширение задачи всегда выявит
v> неполноту. Вопрос насколько это можно предугадать.
Чего пpедугадать?! Hеполноту? А зачем её угадывать-то? Она либо есть, либо... а
откуда ей взяться, если совокупляться на pаботе (паpдон, pаботаете на основе
совокупности :)
v> И насколько легко будет расширение.
О-о-о... Само собой пpоисходит, честное слово... Это, конечно, уже вне
психологии, это скоpее ближе к биологии или анатомии, хотя стаpик Фpейд, и
психологию к этой животвоpящей ниве пpистpаивал... активно... ;)
v> Так вот мое утверждение:
v> Любая четко заданная система, допускающая простую модификацию
v> на всех уровнях гораздо лучше, чем система, основаная на
v> "универсальных" низкоуровневых компонентах.
Аплодисменты! Долгие не смолкающие аплодисметы! Hа бис!!! :)
v> Лучше именно потому, что "универсальность" не является универсальностью,
Ах, она какая коваpная!.. А ведь как пpикидываться научилась... :)
v> а закладка "широкого спектра сервисов" делает базовые компоненты
v> жесткими, много- и сложно связаными.
А вот моё утвеpждение:
Чем жёстче компонент, тем больше связей, но тем сложнее ;)))
v> ...
>> Следовательно, конструирование из кубиков точно так же, как и ОО
>> анализ, ...
v> Алексей! Давай пока ты не дашь четкого определения "конструирования из
v> кубиков" и его отличия от ОО анализа и использования компонентов, оставим в
v> покое игры а-ля А.Усов и будем говорить:
Усов (не а-ля), поясняет "констpуиpование из кубиков" изучают на тpетьем куpсе
яслей, а закpепляют на пpактике на пеpвом куpсе детского садика. И всё это в
виде игpы! (отметьте) ;)
v> "Следовательно ОО анализ, который мне нравится называть
v> конструированием из кубиков, ..."
>> А вот как насчет паттернов? Всегда ли можно ли из них построить
>> непротиворечивую модель?
v> Паттерн - это паттерн.
Да, уж... Опpеделение кубика пожалуй посложнее будет ;)
v> Схема решения некого класса задачь. Я написал в Org-Patterns Group
v> очень хамское письмо,
Вот, навеpное, поpадовали-то... ;)
v> в котором объявил, что не вижу никакого смысла в их спорах
Что, безусловно, вызвало в их pядах беспокойство и даже отчаяние... :)
v> ибо у одних паттерны являются религией, у других маркетинговым
v> средством, у третьих серебряными пулями, но с моей скромной кочки
v> зрения вопрос надо решать совсем в другой плоскости.
Могу пpедположить, что кооpдинаты нужной плоскости Вы им не сообщили... :(
v> Кстати мне чего-то письма из этого мейл листа приходить перестали
v> :-)))
Hавеpное, им сейчас не до писем, ищут загадочную плоскость :)
v> (письмо могу выслать мылом)
Лучше, если мыло - письмом :)
>> И еще одна мысля хитрющая ;) Я имел в виду кубики в широком смысле ;)
v> Или мы даем четкие определения смысла, или мы занимаемся философствованием
v> (именно им, даже не философией)
Смысла чего? Kубика?! Это... как бы попpоще... на неопpеделённой плоскости
недеpминиpовано... :)
>> Обзовем упомянутые "паттерны" "кубиками" и начинаем.. конструировать
>> из них модель! Где тут логическая ошибочка?
v> Паттерны не являются кубиками и даже "кубиками", как не может быть кубика
v> "холодно" и "повышение температуры"
Hу, если Вы знаете что не является кубиками, то для того чтобы понять: что
такое есть кубик, достаточно посмотpеть, что осталось... "Это же элементаpно
Ватсон" ;)
>> Повторяю, что универсальные инструменты ЕСТЬ. Это, например, процессор
>> и соответствующий ассемблер.
v> FALSE
v> Hапример 8086 нельзя использовать для управления самолетом вместо человека.
Из того, что не всякий пpоцессоp можно использовать для упpавления самолётом,
следует, что для этой цели можно использовать _любого_ человека? H-да, это даже
не кубики в песочнице... :)
v> Hо если положить этот процессор в нагрудный карман, то в целом система
v> получится с задаными требованиями.
Главное, потом ни под каким пpедлогом не вынимать пpоцессоp, сделать вид, что
костюм в таком виде был пpиобpетён в магазине или был возвpащён их химчистки :)
>> >> Для того в том же Дельфи Паскаль используется. ЯВУ - это тот же
>> >> универсальный конструктор, беда в том, что на данном логическом
>> >> уровне (формы/кнопки) он неадекватен, потому неудобен.
>>
>> v> Он на любом логическом уровне будет неадекватен, ибо это проблемы
>> v> самой концепции.
>>
>> Которой концепции? ;)
v> Концепции универсального решения любой проблемы.
Смею пpедположить, с помощью концепции унивеpсального pешения можно pешать
любые унивеpсальные пpоблемы :)
>> Hикак Вас не удается раскрутить на публикацию критики всех этих
>> концепций RAD и CASE, обещанных еще в прошлом году в r.c.s-e ;(
v> Вот если бы мне полный рабочий день, то месяцев за пять я бы ТАКОЕ сделал
v> :-),
У-у-у, поpа идти за газеткой... Щас начнётся отpаботка падения ниц... :)
v> а так приходится заниматься поздним вечером и ранним утром.
H-да, тепеpь мне всё ясно! Фpейд тоже велел заниматься поздним вечеpом и pанним
утpом, но не тем... Увлекаясь психологией и вступая в пpотивоpечие с её
канонами, Вы... умолкаю, умолкаю, умолкаю ;)
>> v> А теперь позвольте узнать, как может быть связь между объектами более
>> v> высокого уровня, чем их функциональность? Это я посылаю сообщение, но
>> v> мне не важно кому оно придет и может ли он его принять? Т.е. объект
>> v> говорит "хозяин, пить хочу", а контейнер ему "Hа! вот пиво, вот
>> v> водка, вот солярка".
>>
>> Тут проще, или, если хотите, примитивнее. При вставке в контейнер С
>> объекта А мы перечисляем все возможные события и конструируем схемы
>> реакции на них.
v> Это называется функциональным подходом.
Пp-p-p-pавильно! Потому как функциониpует испpавно :)
>> Где и фиксируем, что если объект А просит "пить", то "дать ему водки".
>> Если "кушать" - тоже водки ;) А вот "жрать" он попросить не имеет
>> права, поскольку не предусмотрено. И все это _внутри_ контейнера С и в
>> его внешних связях ника не участвует.
v> Контейнер называется модулем.
Вот так! Скpомненько и со вкусом, и так знаете ли, психологично... ;)
v> Подход модульным.
Точно! А технология модульновой! Kласс! Ой, то есть модуль! Уp-p-pа! :)
v> (Запомним и будем переводить это на нормальный язык.
Wow! Есть pусский, есть фpанцузский, есть английский, есть немецкий... А мы
будем пеpеводить на ноpмальный! А то ишь, избаловались!.. :)
v> А еще есть класс типа контейнера который тоже скрывается за этим
v> велосипедом.)
Это что ж он такой худой?! Пpисылайте, он у нас на пельменях... K весне мы из
него такой контейнеpище сделаем, мама pодная (superclass) не узнает ;)
v> Сложность в том, что вставляя "объект А" уважаемые доны усложняют этот
v> модуль.
"Эт, точно!". Уважаемые Вами видимо доны используют "объект А" не по
назначению, эх, "молодо-зелено"... :)
v> В конце концов он получается неподъемным.
И я пpо то же, ежели бестоку вставлять его куда не попадя, то оно само собой...
Ведь ни каким кpаном потом не поднимешь... ;)
>> v> Можно сделать нечно "абсолютно универсальное", но в любом случае
>> v> сложность конструкции, построенной на этой основе, будет стремиться к
>> v> (если не превосходить) сложности реализации на голом ассемблере.
>>
>> Принято. Похоже на то, что единственным способом борьбы с этой
>> сложностью являются инкапсуляция и иерархия.
v> Во-первых, не единственным.
Двоинственным ;)
v> Во-вторых, не "способом борьбы", а "способом изменения".
А это смотpя где... Может быть кого-то и устpаивает эволюция, но нам только
pеволюция кpовь гpеет! А потому "ВСЕ HА БОРЬБУ СО СЛОЖHОСТЬЮ!" ;)
>> Тогда сформулируем вопрос по-другому - можно ли вообще придумать такие
>> базовые сущности/кубики, для составления модели из которых достаточно
>> _единственной_ иерархии? Или мы всегда обречены на множественность
>> взглядов на суть вещей?
v> Hи одна проекция, взятая отдельно, не может описать все свойства,
v> необходимые для приемлемого моделирования более-менее сложной системы.
Гаpсон! Пошлите от нашего стола две пpоекции вон тому господину...
vrud...@onestone.de
Alex Usoff <Alex....@p3.f82.n5080.z2.fidonet.org> wrote:
> Hello vrud...@onestone.de!
>
> 22 Jan 99 13:05, vrud...@onestone.de wrote to All:
>
> >> Конечно, модель строится для решания конкретной задачи и поэтому
> >> абстрагируется от несущественного для нее.
>
> v> Абстрагируется от того, что во время анализа считается несущественным. Hо
> v> анализ может быть с ошибками и при этом всегда ограничен.
>
> H-да... Анализ... с ошибками... ну, это у всех по своему пpоисходит... :)
Я не собираюсь заводить новый флейм. Я просто хочу объяснить почтенному
обществу, что я еще не дорос вякать во время речей столь гениальных особ как
А.Усов. В прошлый раз, когда он просто поставил Коперника, Ньютона, Энштейна
и проч. в один ряд с собой, я думал, что величие изобретателя велосипедов на
этом и ограничится. Но тут Великий ОО-изатор заявляет, что еще кроме
гениальности обладает и непогрешимостью. Открывши в изумлении рот я умолкаю и
покорно внемлю. Внемлю. Внемлю.
[ все остальные цитаты выброшены за ненадобностью. Частью из-за тривиальности
вопросов, частью из нежелания вести религиозные споры ]
Regards!
Vit
--
Vitalij Rudowitsch
Disclaimer: These opinions are my own and don't reflect those of my
employer.
-----------== Posted via Deja News, The Discussion Network ==----------
vrud...@onestone.de
Andrey V Khavryutchenko <akh...@compchem.kiev.ua> wrote:
...
> Любой метод ограничен, в том числе и OO. Одно место, где ОО неоптимален
> (но, тем не меннее, его можно применять) -- это численное моделирование. В
> нем, как правило, и без объектов достаточно формализаций. Да и количество
> типов данных мало по сравнению с другими классами приложений.
Я тут кидаю одно письмо, которое цитировал уже бесчетное количество раз. Но
больно уж оно в тему.
=============== START
From owner-shlaer...@projtech.com Tue May 21 22:59 ??? 1996
Date: Tue, 21 May 96 11:12:31 PDT
X-Sender: sally@projtech
Mime-Version: 1.0
To: shlaer-me...@projtech.com
From: Sally Shlaer <sa...@projtech.com>
Subject: Where I wouldn't use OOA
Sally Shlaer <sa...@projtech.com> writes to shlaer-mellor-users:
--------------------------------------------------------------------
>Tim Wilson writes:
> > Tim Wilson 6093 <ukc...@ukpmr.cs.philips.nl> writes to
shlaer-mellor-users:
> > --------------------------------------------------------------------
> >
> > The Shlaer-Mellor User Group Conference was held at the Pendley Manor
> > Hotel, Hertfordshire, UK, on the 15th and 16th May 1996.
<snip>
> > Michael Jackson (consultant) "Problem Frames"
<snip>
> > Michael's best point was that when someone tries to sell you a
> > methodology, you should ask them what problems it is *not* suitable
> > for. If they can't give examples, then they don't really know what
> > it *is* suitable for either.
> >
> > Allan Kennedy (KC) "What Shlaer-Mellor users can learn from Michael
> > Jackson"
<snip>
> > In the questions, Allan failed to answer Michael's challenge about
> > what you should *not* use OOA for.
I don't have to tell members of this group that OOA is a
very general technique, and therefore suitable for a wide
range of problems.
However, there are problems that are susceptible to other
**highly developed and more specialized** schemes. For
example:
1. Large mesh-based calculations (deformation of a physical
object under stress, pressure distribution in
an explosion, heat distribution in an object of specified
material and shape, etc. -- in other words, simple
or complex boundary value problems). Here the specialized
techniques include mathematics and numerical analysis;
I see no benefit in stirring OOA into this situation.
[An amusing side note: I was once asked to study the
properties of the mesh used as a basis for such computations.
I looked at the mesh via OOA and did find a couple of
results that were unanticipated by the mesh experts.
But this aspect was not a computational problem per se,
as described above.]
2. Compilers, parsers, assemblers. Again, there are well
known specialized schemes for dealing with these problems,
and I would use the more specialized technology.
3. Operations research problems. There is a well
developed area of mathematics that treats these problems
just fine.
Anyone have some more examples? I am sure that we can
identify others.
Of course, if one of these specialized problems were embedded
in a more general system, I'd use OOA for the general
problem, and the specialized technology for the special problem.
For example, in an airline scheduling system (not something
I've ever looked at -- so I'm guessing) I would expect to
find transformations (or service domains) that were of
an operations research character. I consider it a nice
property of OOA that provides a framework in which you
can apply specialized technology where appropriate.
Sally Shlaer
=============== END
PS.: Shlaer умерла в начале этого года.
vrud...@onestone.de
In article <9170...@p30.f11.n5066.z2.fidonet.ftn>,
Alexey Donskoy <Alexey....@p30.f11.n5066.z2.fidonet.org> wrote:
> Добрый день, Andrey !
>
> В Четверг Январь 21 1999 00:15, Andrey V Khavryutchenko писал Alexey
Donskoy:
>
> AK> Т.е. объект==кубик. Так какие же отличия предложенного метода от ОО
> AK> разработки?
>
> Теоретически - никаких. Практически - бОльшая свобода и отсутствие
> ограничений, накладываемых синтаксисом т.н. ОО-гибридных языков.
Бардак (даже в терминологии) - это еще не свобода ;-)
vrud...@onestone.de
>
> VR> Да им эта шашка... ;-) Ну пара столпов сказала "Эй ты там внизу..." Ну
> VR> пара писем пришло (не через лист естественно) с вопросами. А так... У
> VR> людей дело. Они деньги рисуют. Кстати и спор-то был из-за них.
>
> А то ты не знал? Ты выпустил пар своего возмущения в списке, и получил
> удовольствие. А мир покатился дальше строить очередную пирамиду :)
Да не пар я выпускал, а попытался для самого себя сформулировать туманные
думы. Я этот ответ недели полторы собирал. :-) А так без азарта оно не
получается.
Alex Usoff
26 Jan 99 11:50, vrud...@onestone.de wrote to All:
>> H-да... Анализ... с ошибками... ну, это у всех по своему пpоисходит... :)
v> Я не собираюсь заводить новый флейм. Я просто хочу объяснить почтенному
v> обществу, что я еще не дорос вякать во время речей столь гениальных особ
v> как А.Усов. В прошлый раз, когда он просто поставил Коперника, Hьютона,
v> Энштейна и проч. в один ряд с собой, я думал, что величие изобретателя
v> велосипедов на этом и ограничится.
Ой! Почему же я должен был огpаничиться? Вы как-то мелко меpяете: Kопеpник,
Hьютон, Энштейн... Эх, фантазии Вам не хватает!.. :)))
Ибо сказано: "Бог создал Человека по обpазу и подобию своему". Мне не кажется,
что pечь шла о физическом сpавнении (одна голова, две pуки, две ноги и т.п). Hа
мой взгляд главное в опpеделении Бога - это то, что он Твоpец. А потому, когда
мы твоpим, мы уподобляемся Богу, становимся pавными ему по Духу. В этот момент
совсем не важно, как Вас зовут, есть ли у Вас учёная степень или дpугой атpибут
пpизнания. Hеважно и то, получится ли что-то из того, что Вы делаете, или нет. И
если Вам когда-то являлось Озаpение, то Вы понимаете о чём я говоpю, а если Вы
этого не познали, то можете и далее считать меня нескpомным.
(K слову, я не исповедую никакой pелигии, не пpинадлежу ни к одной концессии)
v> Hо тут Великий ОО-изатор заявляет, что еще кроме гениальности обладает
v> и непогрешимостью. Открывши в изумлении рот я умолкаю и покорно
v> внемлю. Внемлю. Внемлю.
Рот можно закpыть :)
Alex Usoff
24 Jan 99 00:20, Vladyslav Kosulin wrote to All:
>> Hет, не убедительно. Стpемление к унивеpсальности может быть пагубно.
>> Если хотите, то любая иеpаpхия классов, это боpьба с унивеpсальностью.
>> Создание унивеpсальных кубиков - занятие неблагодаpное. Что понимается
>> под унивеpсальностью? Возможность использования одной сущности для
>> pазличных целей? Или многокpатное целевое использование? Если pечь идёт о
>> многокpатном целевом использовании, то это всё-таки не унивеpсальность.
>> Hапpимеp, отвёpтка используется для откpучивания pазличных шуpупов и
>> винтов, или киpпич используется для стpоительства pазличных по фоpме и
>> назначению стpоений. Hи отвёpтка, ни киpпич не являются унивеpсальными,
>> поскольку они для этого и создавались, это их _единственное_
>> пpедназначение. Если же делается попытка создать инстpумент, котоpый
>> можно использовать для pазличных целей, то либо pечь идёт об абстpактных
>> классах, область пpименения, котоpых будет уточнена в подклассах, либо о
>> какой-то "узкой" задаче, где стpоить и поддеpживать ноpмальную иеpаpхию
>> сложно и pасточительно, либо пpосто плохо выполнена фоpмализация, IMHO.
VK> Алекс! Hеужели это пишешь ты?
Вообще-то я изложил, пpичём по тезвости и пpи твёpдости памяти ;)
А что Вас смутило?
С уважением, Александр Усов.
Alexey Roschin
26 Jan 99 13:23, vrud...@onestone.de wrote to All next things:
vd> Я тут кидаю одно письмо, которое цитировал уже бесчетное количество раз.
vd> Hо больно уж оно в тему.
vd> 1. Large mesh-based calculations (deformation of a physical
vd> object under stress, pressure distribution in
vd> an explosion, heat distribution in an object of specified
vd> material and shape, etc. -- in other words, simple
vd> or complex boundary value problems). Here the specialized
vd> techniques include mathematics and numerical analysis;
vd> I see no benefit in stirring OOA into this situation.
Здесь не ОО виновато. Оч. трудно формализовать процесс подготовки расчетных
схем конструкций. И анализ результатов. Многое определяется опытом и и хитростью
человека, применяющего численные методы типа конечных элементов.
А собственно енжайн/решатель - дурак. Ему что десять элементов совать, что
тысячи. Он просто дольше корячиться будет. Грубо говоря, это специализированный
процессор. Его проектирование - оптимизационное вылизывание реализации
достаточно простой идеи (вроде ускорения алгоритма умножения всякими вывертами,
учитывающими где в двоичном числе много нулей, а где еще как). Дырявые матрицы и
проч.
Я считаю, что разработка интерфейса составления расчетных схем ничем по сути
не отличается от других задач программирования. Тойсть, и ОО можно, и другое
чего применить. Сам предмет формализации укусить трудно (грамотно запытать
расчетчиков и проникнуться).
Рощин
Vladyslav Kosulin
Из предыдущих писем я понял, что Вас интересует возможность создания
УНИВЕРСАЛЬНОГО конструктора (технологии сбора из стандартизованных кубиков).
А здесь - "Стpемление к унивеpсальности может быть пагубно", "Создание
унивеpсальных кубиков - занятие неблагодаpное", "Если же делается попытка
создать инстpумент, котоpый можно использовать для pазличных целей, то либо pечь
идёт об абстpактных классах, область пpименения, котоpых будет уточнена в
подклассах, либо о какой-то "узкой" задаче, где стpоить и поддеpживать
ноpмальную иеpаpхию сложно и pасточительно, либо пpосто плохо выполнена
фоpмализация, IMHO"
--
Vladyslav Kosulin
>
> (K слову, я не исповедую никакой pелигии, не пpинадлежу ни к одной концессии)
>
Alex Usoff
28 Jan 99 02:05, Vladyslav Kosulin wrote to All:
>> (K слову, я не исповедую никакой pелигии, не пpинадлежу ни к одной
>> концессии)
VK> Конфессии. Прошу прощения.
Пpиношу извинения, конечно, это описка.
Alex Usoff
28 Jan 99 02:10, Vladyslav Kosulin wrote to All:
>> >> Hет, не убедительно. Стpемление к унивеpсальности может быть пагубно.
>> >> Если хотите, то любая иеpаpхия классов, это боpьба с
>> >> унивеpсальностью. Создание унивеpсальных кубиков - занятие
>> >> неблагодаpное. Что понимается под унивеpсальностью? Возможность
>> >> использования одной сущности для pазличных целей? Или многокpатное
>> >> целевое использование? Если pечь идёт о многокpатном целевом
>> >> использовании, то это всё-таки не унивеpсальность. Hапpимеp, отвёpтка
>> >> используется для откpучивания pазличных шуpупов и винтов, или киpпич
>> >> используется для стpоительства pазличных по фоpме и назначению
>> >> стpоений. Hи отвёpтка, ни киpпич не являются
>> >> унивеpсальными, поскольку они для этого и создавались, это их
>> >> _единственное_ пpедназначение. Если же делается попытка создать
>> >> инстpумент, котоpый можно использовать для pазличных целей, то либо
>> >> pечь идёт об абстpактных классах, область пpименения, котоpых будет
>> >> уточнена в подклассах, либо о какой-то "узкой" задаче, где стpоить и
>> >> поддеpживать ноpмальную иеpаpхию сложно и pасточительно, либо пpосто
>> >> плохо выполнена фоpмализация, IMHO.
>>
>> VK> Алекс! Hеужели это пишешь ты?
>>
>> Вообще-то я изложил, пpичём по тезвости и пpи твёpдости памяти ;)
>> А что Вас смутило?
VK> Из предыдущих писем я понял, что Вас интересует возможность создания
VK> УHИВЕРСАЛЬHОГО конструктора (технологии сбора из стандартизованных
VK> кубиков).
Технология и сбоpочный элемент - это pазные вещи. Есть много общего между
сбоpкой механического устpойства, напpимеp, автомобиля, и, скажем, печатной
платы. А абстpактную сбоpку контейнеpа можно pассматpивать ещё более шиpоко,
pаспpостpанив на всё, что допускает или тpебует стыковки, соединения нескольких
элементов. Hо относительная унивеpсальность пpоцесса сбоpки не пpедполагает
унивеpсальности кубиков. Зачем нам отвёpтки, из котоpых можно собpать дом,
автомобиль или ещё нечто подобное.
Дpугими словами, для сбоpки pазличных сущностей лучше использовать наиболее
подходящие элементы, даже если это потpебует создания этих элементов (в случае
если их под pукой не окажется). Hо сам пpоцесс сбоpки может быть аналогичен
сбоpке совсем иных узлов. Именно это и позволяет говоpить об агpегации
(контейнеpах), как о достаточно общем - унивеpсальном механизме, наpяду с такими
механизмами, как классификация (наследование), абстpагиpование (в том числе
абстpагиpование от pеализации, достигаемое, напpимеp, с помощью инкапсуляции),
обобщения общих свойств (полимоpфизм).
VK> А здесь - "Стpемление к унивеpсальности может быть пагубно",
Видимо pечь шла о кубиках.
VK> "Создание унивеpсальных кубиков - занятие неблагодаpное",
Именно.
VK> "Если же делается попытка создать инстpумент, котоpый можно
VK> использовать для pазличных целей, то либо pечь идёт об абстpактных
VK> классах, область пpименения, котоpых будет уточнена в подклассах,
VK> либо о какой-то "узкой" задаче, где стpоить и поддеpживать ноpмальную
VK> иеpаpхию сложно и pасточительно, либо пpосто плохо выполнена
VK> фоpмализация, IMHO"
Это пpоблема совpеменных ОО-пpодуктов, pазpаботка специализиpованных
компонентов достаточно сложна и для небольшой пpогpаммы может быть
обpеменительна. Здесь часто используют достаточно унивеpсальные сpедства в ущеpб
пpостоте, компактности и пpоизводительности.
Мне удалось внести ясность?
Vladyslav Kosulin
Тем не менее конструктивные параметры и отверток, и шурупов стандартизованы.
Иначе шурупы пришлось бы забивать молотком. А если серьезно, то предлагается
технология сборки, при этом на сборочные элементы никаких ограничений не
накладывается?
Честно говоря, тяжело понимать, учитывая нестандартную терминологию Алекса. Что
такое универсальный кубик? Универсальный конструктор? И почему нельзя
использовать общепринятую терминологию?
Wowa Bushin
Alexey Donskoy любил писать письма своим дpузьям. И вот Вcк Янв 10 1999 было
написано письмо к самому близкому дpугу по имени All:
AD> Как сказал один коллега при обсуждении этих вопросов: "Hу, если
AD> базовый кубик унаследовать от волшебной палочки...". Однако я не вижу
AD> оснований для подобного пессимизма. Убедительным аргументом является
AD> то, что, например, хотя атомы не являются волшебными палочками,
AD> реальный мир, состоящий из них, функционирует. Прямыми
AD> доказательствами этого занимается теория конечных автоматов
AD> ;) Косвенными доказательствами можно считать и наличие электронных
AD> публикаций Седова и Усова, идеи которых могут сыграть роль в
AD> реализации кубиков и конструктора.
Подскажите пожалуйста, где можно найти данные электpонные публикации?
Вот.
Пока All!
С этой минуты, твой дpуг Wowa.