Ответ на »сообщение 4190« (info21)
___________________________
Формулировка -- она не для себя... а для других...
Именно для других я и сформулировал проблему... с самого начала...

Ответ на »сообщение 4188« (Stargazer)
___________________________
Высказывание ASU в том и состояло, что из его системы можно выдернуть именно любой компонент, без последствий для остальных. Наверное, речь идёт о двойном-тройном дублировании. Если же нет, то это, наверное, фантастика.
Речь шла о ERP-системе. У нее есть подсистемы (производство, сбыт, финансы и пр.). Каждая подсистема инкапсулирована и ничего не знает о существовании каких-либо других подсистем (системообразующих, в том числе). Системообразующие подсистемы (их сейчас две, но они решают совершенно разные задачи) устанавливают связи между подсистемами. Система является распределенной со «слабыми» связями. Каждая подсистема может быть расположена на отдельном сервере (и мы рекомендуем именно так и делать... «не складывать все яйца в одну корзину»). Если по каким-то причинам одна из функциональных подсистем недоступна, то остальные подсистемы продолжают работать, обслуживать пользователей и обмениваться информацией между собой. После восстановления связи с «недоступной» подсистемой происходит автоматическое включение ее в работу. Если недоступной становится одна из системообразующих подсистем, то прекращается обмен информацией между подсистемами, но при этом сами подсистемы в состоянии какое-то время продолжать обслуживать пользователей. После восстановления подсистемы информация всех функциональных подсистем будет автоматически синхронизирована.

А как будет себя вести система в моменты переключения подсистем, решает архитектор системы.
Совершенно верно.

Ответ на »сообщение 4187« (AVC)
___________________________
А есть ли в Вашей схеме отношений модулей место типам?
И если есть, то где оно?
а) это не "моя схема"... это устройство систем...
б) типы обязаны быть, в интерфейсах, в том числе.
Вопрос "где?" я не понял...

Ответ на »сообщение 4185« (Руслан Богатырев)
___________________________
>> Речь о том, что модуль с модулем связываться вообще не должны, безотносительно механизмов внутри модулей.
> В языке Оберон модули (MODULE) не связываются напрямую с модулями.
Хорошо... Попробую перестроить вопрос... «Если разработчик пишет модуль, то он может написать из этого модуля обращение к другому модулю?» (Ну, вспомните примеры, которыми иллюстрировали квалифицирующий импорт...)

И еще... Мне кажется, что кто хотел услышать – услышал... Надо ли «толочь воду в ступе»?

Ответ на »сообщение 4184« (MS)
___________________________
Вы хотите иметь сущьность более высокого уровня чем модули?
Мое желание... адекватность модели. Если создается система, то это должна быть система, а не конфетти из модулей...

Назавём, например, СуперМодуль.
При этом выстраивается иерархия процедуруы, переменные, объекты объденяются в модули, с соответствующим интерфесом, а сами модули в СуперМодули, которые имеют свои интерфейсы?
Есть более простые и понятные термины: системы и ее элементы. Элементы могут быть простыми или сами являться системами. Иерархия выстраивается от простых элементов до...
Хорошие системы имеют очень небольшое количество уровней.

Ответ на »сообщение 4176« (ASU)
___________________________

Тогда у меня остался только один вопрос: «Почему адепты Oberon в одном случае отстаивают простоту и строгость, а в другом аналогичном случае – сложность и халатность? Когда же им верить?»...

Поклеп и провокация.

Ответ на »сообщение 4177« (ASU)
___________________________

Ответ на »сообщение 4170« (info21)
___________________________
Хм.. Это называется "сформулирована"?..
С тех пор я ничего нового не сказал... можете сами сравнить...

Формулировка -- она не для себя... а для других...

>>> Речь о том, что модуль с модулем связываться вообще не должны
Тогда это даже не пазлы и не кирпичи! У тех края являют собой интерфейс.
Это сюр - орбитальная группировка тех самых бедолаг зайцев в космосе!
Причём здесь "вообще" система?


Развивая идею применения компактного вьюера от Оберона.
Одно дело вьюер внешний по отношению к данным, к составному документу.
Другое дело - интегрированный с самим документом!

Есть вьюер или нет, есть доступ к интернету для закачки вьюера или нет - неважно.
Вьюер и документ в одном флаконе. Причём подходят как ни странно :) друг у другу.
Помните досаду, когда у Вас не установлен нужный (а кой чёрт знает - какой нужный?)
кодек к ролику или когда документ создан в новой версии, а у Вас старая (AutoCAD или Visio)?
Или Вы закачали карту нужной области, а программа её просмотра платная или где её взять?

Возможность манипулирования активным документом со вложенным вьюером впечатляюща.
Такие документы на Обероне, задвинутые в массы, прибавят популярности Оберону.

Представьте сравнение - приаттаченный Word к докладу и вьюер от ББ к презентации с текстом,
возможностью проведения расчётов по данным аудитории, построение по ним тут же графиков
или отображение на схеме перетоков по трубопроводам при различных отсечениях арматурой?
Что, смешно?
Каждый может представить что-то своё. Например, к таблице прилагается расчёт
с интерполяцией сплайнами в промежуточных значениях и т.п.
Это и PowerPoint не сделает. Там только слайды, ну или линейный ролик.

Вот где преимущества Оберона - компактность и активные составные документы заиграют
не на словах, а наглядно на деле.

Ответ на »сообщение 4183« (al_mt)
___________________________

Выдернуть "системообразующий" модуль невозможно даже из "ресурсного" ПО :)

Высказывание ASU в том и состояло, что из его системы можно выдернуть именно любой компонент, без последствий для остальных. Наверное, речь идёт о двойном-тройном дублировании. Если же нет, то это, наверное, фантастика.

Если подходит с такой меркой к вышеприведённой задаче, то "системообразующим" будет класс, который как раз и занят "разбором полётов" кто из БД в данный момент рабочий. Всё достаточно естественно (хотя не сказал бы, что просто :)) реализуется в ООП, но с трудом представляю, как это вменяемо сделать без оного :(

Меня больше интересуют механизмы коммутации, тем и интересна Оберон-технология. А как будет себя вести система в моменты переключения подсистем, решает архитектор системы.

Ответ на »сообщение 4181« (ASU)
___________________________

>>>Речь о том, что модуль с модулем связываться вообще не должны, безотносительно механизмов внутри модулей.

А есть ли в Вашей схеме отношений модулей место типам?
И если есть, то где оно?