Принципы 7 многослойной модели

Хотя это легче сказать, чем сделать, я хотел бы начать на этой неделе geofumando По этому вопросу, хотя есть полные книги по этому вопросу, мы будем использовать принципы 7 Web 2.0, чтобы обобщить схему многослойной модели и применить ее к геоматическому полю.

Концепция, известная как многоуровневость, возникла после бума клиент-серверных приложений, связанного с ростом Интернета, когда частные сети (Интранет) также стали популярными. Одна из наиболее важных целей состоит в том, чтобы разработка не влияла на работу, не говоря уже о пользователях запросов в системе, которая постоянно используется.

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

Давайте посмотрим на слои этой модели и ее принципы.

Уровень разработки

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

2. Приложения для работы с несколькими устройствами.  Необходимо учитывать, что пользователи захотят получать доступ к информации с настольных или различных мобильных устройств через Интернет, поэтому при разработке необходимо учитывать этот принцип. Хотя предсказать эволюцию хорошо известных гаджетов непросто, по крайней мере, следует учитывать специфику проекта для целей подачи и загрузки данных, как в случае кадастрового процесса, использования оборудования GPS и КПК с приложениями ГИС. / САПР с минимальными возможностями подачи табличных данных и использованием растровых / векторных данных. Поскольку специализация бизнеса диверсифицирована, необходимо знать о развитии технологий.

3. Через базу данных.  Чтобы не допустить коллапса процессора, необходимо учитывать, что любое действие, выполняемое пользователем, является простым вызовом базы данных, поэтому, если используется передача файлов, предпочтительно создавать веб-службы. Если будут использоваться карты, идеальным вариантом является создание служб IMS для публикации, а если документы будут загружены, ищите использование веб-служб.

Уровень процесса

4. Интернет как платформа.  Будь то интрасеть или Интернет, концепция одна и та же: рабочая среда пользователей должна быть онлайн, чтобы любой тип процесса запускался с сервера. Это дополняется следующим принципом, поскольку цель состоит в том, чтобы гарантировать, что работа процессов не требует оборудования с большими ресурсами, хотя необходимо перепроектировать настольные приложения.

5. Использование онлайн-приложений.  Это большая проблема для разработчиков, поскольку этот уровень также включает уровень пользователей, которые выполняют процессы, выходящие за рамки запроса. Так обстоит дело с ведением кадастра, которое требует использования отдельных файлов, а не только манипулирования табличными данными. Для этого выбранное программное обеспечение должно обеспечивать контролируемую среду управления файлами, управление версиями и процесс, известный как checkout-checkin; Также ожидается, что API предоставит возможности для конкретизации функций и предотвращения усложнения синхронизации процессами рабочего стола.

Пользовательский слой

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

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

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