Ответ на »сообщение 2975« (Денис Зайцев)
___________________________

Ответ на »сообщение 2974« (Сергей Перовский)
___________________________

Если Вы не можете предсказать потребности пользователя на несколько лет вперед, значит пока не надо браться за задачи в этой области.
Сильно сказано! Мне кажется, если бы все пользовались этим правилом, 90% софта вообще не было бы написано.

Ну, с одной стороны, может, это было бы и к лучшему.

С другой стороны, самое страшное в том, что сами задачи меняются после внедрения ИТ-системы, причем образом, труднопредсказуемым ввиду сложности как задач, так и оных ИТ-систем. Можно сказать, сам взгляд на прикладную область меняется. Иногда радикально. Свидетельствую как "тот самый специалист".

Ответ на »сообщение 2974« (Сергей Перовский)
___________________________

Если Вы не можете предсказать потребности пользователя на несколько лет вперед, значит пока не надо браться за задачи в этой области.
Сильно сказано! Мне кажется, если бы все пользовались этим правилом, 90% софта вообще не было бы написано. Уж даже не знаю, какой пример привести. Развитие операционных систем, офисных, графических пакетов, особенно на начальной стадии - это всё, по-моему, настолько очевидные примеры того, что софт пишется в постоянном контакте с пользователями. У Майкрософта вон целая программа по улучшению качества ПО, в которой может участвовать каждый желающий. И что, Вы хотите сказать, что потребности пользователей на несколько лет вперёд уже предсказаны Майкрософтом, и они только выбирают по результатам голосования, какую именно потребность нужно будет удовлетворить в следующем релизе?

Конечно, надо стараться предсказывать потребности, никто не спорит, но быть уверенным в том, что они будут именно такими, можно, на мой взгляд, только в устоявшихся областях, например, в математических пакетах. В активно развивающихся областях, как мне кажется, на это рассчитывать никак нельзя.

Ответ на »сообщение 2971« (Как слышно? Приём!)
___________________________
>>>И всё дерево - фтопку и всё что было наработано тоже.
Если задача вышла за область применения реализованной математической модели, то надо менять модель, а не только ее программную реализацию.
КА со сбоями - вероятностный конечный автомат я, конечно, могу описать как наследника КА. Но в общем случае любая программная система имеет область применимости и не надо жадничать, закладываясь на очень широкую область.
Когда строят тракторный завод, обязательно закладывают возможность перехода на танки. А при строительстве нефтеперерабатывающего завода такой вариант никогда не рассматривается :)
Все, что было наработано - это прежде всего понимание задачи, а потом уже некоторые тексты. Так, что "фтопку" это слишком сильно.

>>>Ибо многообразие практики бесконечно :)
Если Вы не можете предсказать потребности пользователя на несколько лет вперед, значит пока не надо браться за задачи в этой области. Я уже говорил: чтобы сделать полезную для специалиста программу, нужно самому быть специалистом.
Потому написано столько аудиопроигрывателей, что в прослушивании музыки каждый сам себе постановщик задачи. А для расчета скорости мумивизации сепулированных глюкал мало школьного образования :)

Ответ на »сообщение 2972« (Mirage)
___________________________
>>>Так это ж вроде бы и есть software bus. В применении к отдельно взятому классу.
Да, и это нисколько не конфликтует с обычным наследованием.

Ответ на »сообщение 2968« (Сергей Перовский)
___________________________

А сигналы представляют собой объекты - наследники базового объекта. Так что они тоже свободно расширяемые. У каждого КА есть список обрабатываемых сигналов. Сигнал обрабатывается, только если он есть в списке.

Так это ж вроде бы и есть software bus. В применении к отдельно взятому классу.

>>> Каков алгоритм КА?
>>> 1.Получить сигнал.
>>> 2.По сигналу и текущему состоянию найти строку в таблице переходов.
>>> 3.Выполнить процедуру, указанную в строке.
>>> 4.Установить состояние, указанное в строке.
>>> Может ли этот алгоритм изменится?
>>> Если речь идет о КА, то нет - он соответствует математическому определению КА.

Ну, математическому - оно конечно! Нечем крыть :)
А вот Ваш заказчик захотел исследовать сбои в Ваших КА.
Как раз те самые нарушения в работе алгоритма КА.
И всё дерево - фтопку и всё что было наработано тоже.
Или задача экзотическая? Вроде нет.
Для практических и живых задач так будет всегда.
Ибо многообразие практики бесконечно :)

Ответ на »сообщение 2969« (Сергей Губанов)
___________________________
В Active Oberon - синтаксически запрета нет, но нет и разрешения: в сообщении не описано что будет если попытаться расширить тип объектов у которого уже определено тело, заменится ли оно другим телом или как...
Тело активности в наследнике запускается параллельно с телами активностей, объявленных в предках (после отработки конструктора наследника, а, следовательно, позже запуска тел в предках).

Ответ на »сообщение 2966« (AVC)
Если не расширять, то нерасширяемы. :-)

Т.е. все-таки расширяемы?

В Zonnon - точно не расширяемы.

В Active Oberon - синтаксически запрета нет, но нет и разрешения: в сообщении не описано что будет если попытаться расширить тип объектов у которого уже определено тело, заменится ли оно другим телом или как... Видимо оставлено на усмотрение реализации.

В Active Oberon for .Net - не помню.

Ответ на »сообщение 2967« (AVC)
___________________________
>>>Например, пришел байт по модему или пришел целый пакет по сети -- все это события, но с ними связаны данные разных типов.
А сигналы представляют собой объекты - наследники базового объекта. Так что они тоже свободно расширяемые. У каждого КА есть список обрабатываемых сигналов. Сигнал обрабатывается, только если он есть в списке.

Ответ на »сообщение 2965« (Сергей Перовский)
___________________________

>>>3.Выполнить процедуру, указанную в строке.

Здесь еще важен механизм передачи этой процедуре параметров (сигнала/события).
Например, пришел байт по модему или пришел целый пакет по сети -- все это события, но с ними связаны данные разных типов.
Если КА -- просто таблица, то откуда ему известна сигнатура вызываемого метода?