Оберон-технология: особенности и перспективы |
Тематика обсуждения: Оберон-технология. Особенности, перспективы, практическое применение.
Всего в теме 6256 сообщений
Добавить свое сообщение
Отслеживать это обсуждение Обсуждение из раздела Школа ОБЕРОНА
№ 4196 19-04-2007 23:19 | |
Ответ на »сообщение 4190« (info21)
___________________________
Формулировка -- она не для себя... а для других...
Именно для других я и сформулировал проблему... с самого начала...
№ 4195 19-04-2007 23:17 | |
Ответ на »сообщение 4188« (Stargazer)
___________________________
Высказывание ASU в том и состояло, что из его системы можно выдернуть именно любой компонент, без последствий для остальных. Наверное, речь идёт о двойном-тройном дублировании. Если же нет, то это, наверное, фантастика.
Речь шла о ERP-системе. У нее есть подсистемы (производство, сбыт, финансы и пр.). Каждая подсистема инкапсулирована и ничего не знает о существовании каких-либо других подсистем (системообразующих, в том числе). Системообразующие подсистемы (их сейчас две, но они решают совершенно разные задачи) устанавливают связи между подсистемами. Система является распределенной со «слабыми» связями. Каждая подсистема может быть расположена на отдельном сервере (и мы рекомендуем именно так и делать... «не складывать все яйца в одну корзину»). Если по каким-то причинам одна из функциональных подсистем недоступна, то остальные подсистемы продолжают работать, обслуживать пользователей и обмениваться информацией между собой. После восстановления связи с «недоступной» подсистемой происходит автоматическое включение ее в работу. Если недоступной становится одна из системообразующих подсистем, то прекращается обмен информацией между подсистемами, но при этом сами подсистемы в состоянии какое-то время продолжать обслуживать пользователей. После восстановления подсистемы информация всех функциональных подсистем будет автоматически синхронизирована.
А как будет себя вести система в моменты переключения подсистем, решает архитектор системы.
Совершенно верно.
№ 4194 19-04-2007 22:56 | |
Ответ на »сообщение 4187« (AVC)
___________________________
А есть ли в Вашей схеме отношений модулей место типам?
И если есть, то где оно?
а) это не "моя схема"... это устройство систем...
б) типы обязаны быть, в интерфейсах, в том числе.
Вопрос "где?" я не понял...
№ 4193 19-04-2007 22:53 | |
Ответ на »сообщение 4185« (Руслан Богатырев)
___________________________
>> Речь о том, что модуль с модулем связываться вообще не должны, безотносительно механизмов внутри модулей.
> В языке Оберон модули (MODULE) не связываются напрямую с модулями.
Хорошо... Попробую перестроить вопрос... «Если разработчик пишет модуль, то он может написать из этого модуля обращение к другому модулю?» (Ну, вспомните примеры, которыми иллюстрировали квалифицирующий импорт...)
И еще... Мне кажется, что кто хотел услышать – услышал... Надо ли «толочь воду в ступе»?
№ 4192 19-04-2007 22:47 | |
Ответ на »сообщение 4184« (MS)
___________________________
Вы хотите иметь сущьность более высокого уровня чем модули?
Мое желание... адекватность модели. Если создается система, то это должна быть система, а не конфетти из модулей...
Назавём, например, СуперМодуль.
При этом выстраивается иерархия процедуруы, переменные, объекты объденяются в модули, с соответствующим интерфесом, а сами модули в СуперМодули, которые имеют свои интерфейсы?
Есть более простые и понятные термины: системы и ее элементы. Элементы могут быть простыми или сами являться системами. Иерархия выстраивается от простых элементов до...
Хорошие системы имеют очень небольшое количество уровней.
№ 4191 19-04-2007 17:23 | |
Ответ на »сообщение 4176« (ASU)
___________________________
Тогда у меня остался только один вопрос: «Почему адепты Oberon в одном случае отстаивают простоту и строгость, а в другом аналогичном случае – сложность и халатность? Когда же им верить?»...
Поклеп и провокация.
№ 4190 19-04-2007 17:21 | |
Ответ на »сообщение 4177« (ASU)
___________________________
Ответ на »сообщение 4170« (info21)
___________________________
Хм.. Это называется "сформулирована"?..
С тех пор я ничего нового не сказал... можете сами сравнить...
Формулировка -- она не для себя... а для других...
№ 4189 19-04-2007 13:51 | |
>>> Речь о том, что модуль с модулем связываться вообще не должны
Тогда это даже не пазлы и не кирпичи! У тех края являют собой интерфейс.
Это сюр - орбитальная группировка тех самых бедолаг зайцев в космосе!
Причём здесь "вообще" система?
Развивая идею применения компактного вьюера от Оберона.
Одно дело вьюер внешний по отношению к данным, к составному документу.
Другое дело - интегрированный с самим документом!
Есть вьюер или нет, есть доступ к интернету для закачки вьюера или нет - неважно.
Вьюер и документ в одном флаконе. Причём подходят как ни странно :) друг у другу.
Помните досаду, когда у Вас не установлен нужный (а кой чёрт знает - какой нужный?)
кодек к ролику или когда документ создан в новой версии, а у Вас старая (AutoCAD или Visio)?
Или Вы закачали карту нужной области, а программа её просмотра платная или где её взять?
Возможность манипулирования активным документом со вложенным вьюером впечатляюща.
Такие документы на Обероне, задвинутые в массы, прибавят популярности Оберону.
Представьте сравнение - приаттаченный Word к докладу и вьюер от ББ к презентации с текстом,
возможностью проведения расчётов по данным аудитории, построение по ним тут же графиков
или отображение на схеме перетоков по трубопроводам при различных отсечениях арматурой?
Что, смешно?
Каждый может представить что-то своё. Например, к таблице прилагается расчёт
с интерполяцией сплайнами в промежуточных значениях и т.п.
Это и PowerPoint не сделает. Там только слайды, ну или линейный ролик.
Вот где преимущества Оберона - компактность и активные составные документы заиграют
не на словах, а наглядно на деле.
№ 4188 19-04-2007 13:03 | |
Ответ на »сообщение 4183« (al_mt)
___________________________
Выдернуть "системообразующий" модуль невозможно даже из "ресурсного" ПО :)
Высказывание ASU в том и состояло, что из его системы можно выдернуть именно любой компонент, без последствий для остальных. Наверное, речь идёт о двойном-тройном дублировании. Если же нет, то это, наверное, фантастика.
Если подходит с такой меркой к вышеприведённой задаче, то "системообразующим" будет класс, который как раз и занят "разбором полётов" кто из БД в данный момент рабочий. Всё достаточно естественно (хотя не сказал бы, что просто :)) реализуется в ООП, но с трудом представляю, как это вменяемо сделать без оного :(
Меня больше интересуют механизмы коммутации, тем и интересна Оберон-технология. А как будет себя вести система в моменты переключения подсистем, решает архитектор системы.
№ 4187 19-04-2007 08:56 | |
Ответ на »сообщение 4181« (ASU)
___________________________
>>>Речь о том, что модуль с модулем связываться вообще не должны, безотносительно механизмов внутри модулей.
А есть ли в Вашей схеме отношений модулей место типам?
И если есть, то где оно?
Добавить свое сообщение
Отслеживать это обсуждение
Дополнительная навигация: |
|