Rambler's Top100
"Knowledge itself is power"
F.Bacon
Поиск | Карта сайта | Помощь | О проекте | ТТХ  
 Базарная площадь
  
О разделе

Основная страница

Группы обсуждений


Тематический каталог обсуждений

Архив

 
 К н и г и
 
Книжная полка
 
 
Библиотека
 
  
  
 


Поиск
 
Поиск по КС
Поиск в статьях
Яndex© + Google©
Поиск книг

 
  
Тематический каталог
Все манускрипты

 
  
Карта VCL
ОШИБКИ
Сообщения системы

 
Форумы
 
Круглый стол
Новые вопросы

 
  
Базарная площадь
Городская площадь

 
   
С Л С

 
Летопись
 
Королевские Хроники
Рыцарский Зал
Глас народа!

 
  
ТТХ
Конкурсы
Королевская клюква

 
Разделы
 
Hello, World!
Лицей

Квинтана

 
  
Сокровищница
Подземелье Магов
Подводные камни
Свитки

 
  
Школа ОБЕРОНА

 
  
Арсенальная башня
Фолианты
Полигон

 
  
Книга Песка
Дальние земли

 
  
АРХИВЫ

 
 

Сейчас на сайте присутствуют:
 
  
 
Во Флориде и в Королевстве сейчас  15:23[Войти] | [Зарегистрироваться]
Обсуждение темы:
Оберон-технология: особенности и перспективы


Тематика обсуждения: Оберон-технология. Особенности, перспективы, практическое применение. 

Количество сообщений на странице

Порядок сортировки сообщений
Новое сообщение вверху списка (сетевая хронология)
Первое сообщение вверху списка (обычная хронология)

Перейти на конкретную страницу по номеру


Всего в теме 6256 сообщений

Добавить свое сообщение

Отслеживать это обсуждение

Обсуждение из раздела
Школа ОБЕРОНА

<<<... | 4206—4197 | 4196—4187 | 4186—4177 | ...>>>
Всего сообщений в теме: 6256; страниц: 626; текущая страница: 207


№ 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)
___________________________

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

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


<<<... | 4206—4197 | 4196—4187 | 4186—4177 | ...>>>
Всего сообщений в теме: 6256; страниц: 626; текущая страница: 207


Добавить свое сообщение

Отслеживать это обсуждение

Дополнительная навигация:
Количество сообщений на странице

Порядок сортировки сообщений
Новое сообщение вверху списка (сетевая хронология)
Первое сообщение вверху списка (обычная хронология)

Перейти на конкретную страницу по номеру
  
Время на сайте: GMT минус 5 часов

Если вы заметили орфографическую ошибку на этой странице, просто выделите ошибку мышью и нажмите Ctrl+Enter.
Функция может не работать в некоторых версиях броузеров.

Web hosting for this web site provided by DotNetPark (ASP.NET, SharePoint, MS SQL hosting)  
Software for IIS, Hyper-V, MS SQL. Tools for Windows server administrators. Server migration utilities  

 
© При использовании любых материалов «Королевства Delphi» необходимо указывать источник информации. Перепечатка авторских статей возможна только при согласии всех авторов и администрации сайта.
Все используемые на сайте торговые марки являются собственностью их производителей.

Яндекс цитирования