Готовый перевод A user-friendly,dinamic web enviroment for remote data browsing and analysis of multiparametric geophysical data with MULTIMO project / Дружелюбная к пользователю, динамическая вэб среда для удаленного доступа и анализа многопараметрических геофизических данных в проекте : 8. The system structure

Совместив вместе все инструменты, которые мы описали выше, теперь легко описать как организована функциональность системы.

Схематический рисунок показан на рисунке 10. Входной точкой пользователя, конечно, является сетевой интерфейс. Отсюда он/она могут просматривать через различные контексты предоставленные на портале.

Контекст - это очень общее понятие: это тип "статуса" системы, который помогает хранить след, "где мы находимся" с точки зрения пользователя (Кто вошел?), вулкана(мы имеем дело с вулканом Соуфрир Хиллс или Вильяррикой?), компонентов (мы ишем сенсоры давления или сейсмометр широкополосной сети?)

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

Используя этот принцип нам не нужно подавать запрос к базе данных каждый раз когда изменяется контекст, но мы используем информацию уже накопленную здесь.

Доступ к базе данных будет получен только, когда он будет необходим. Это методология в считанные разы увеличивает производительность системы.

"Движок", который управляет всеми принятыми инструментами - это продукт, который запускается на сетевом сервере приложений.

Этот продукт насчитывает и представление, и логику. Часть представления относится к тому как и какая информация предоставлена, когда часть логическая написана в контекстных объектах и написана на языке Python.

Простой сетевой запрос может привлечь только представление, например , выведя информацию нового контекста в котором мы находимся.

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

Нужно описать две важные фазы более детально: "процедура обработки" и "историю команд".
Рисунок 11.

"Процедура обработки", в самой своей простой форме, разрешает заполнять параметры как определенные в базе данных, для анализа с информацией относящейся к данных над которыми должны применить анализ.

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

Поэтому мы используем "двух-шаговую обработку"

На первом шаге только параметры относящиеся к самому анализу обрабатываются, в то время как параметры относящиеся к именам файлам остаются нетронутыми. Результат этого шага потом добавляется к командной истории.

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

Это основной пункт для разработки приложения пакетов процедур.

Переведено на Нотабеноиде
http://notabenoid.org/book/3427/10803

Переводчики: wuffur