Слои концептуального устройства существуют в любой, подчёркиваю – в любой, информационной системе, даже если с точки зрения физической архитектуры или конкретного программиста их трудно различить. Это тот случай, когда незнание закона не освобождает от ответственности. Поэтому декомпозиция системы на концептуальные слои является предметом анализа, а не синтеза. Результатом этапа (или этапов) анализа являются, соответственно, концептуальные модели данных, их обработки и ввода/вывода, включая человеко-машинные интерфейсы.
Логическое устройство
Напротив, слои логической архитектуры не являются строго определёнными. Основным способом их выделения является постоянный диалог проектировщика с требованиями к системе и ответами на вопрос «Зачем нужен этот слой в данном случае?». Наиболее типовые вопросы и ответы сведены в так называемые шаблонные решения и рекомендуемые практики.
Логическое устройство является предметом синтеза, на выходе стадии – технический проект. Логическое устройство АИС в разрезе концептуальных слоёв может выглядеть, как на рис. 5.
Рис. 5. Пример организации логических слоёв АИС
Физическое устройство
Аналогично логической архитектуре, физическое устройство тоже является предметом синтеза на стадии проектирования реализации. Физический слой также называется звеном (
Число звеньев системы определяется максимальным количеством процессов клиент-серверной архитектуры, составляющих цепочку между концептуальными слоями.
Рис. 6. Пример организации звеньев АИС
Тонким клиентом (
В противоположность тонкому, толстый клиент (
Так называемый «умный» (
Не секрет, что возможности отображения у веб-браузера, как программируемого терминала, очень скромные, по сравнению с автономным приложением. Компромиссным решением является так называемое «насыщенное интернет-приложение»[94], также являющееся тонким клиентом, но обладающее всеми возможностями отображения клиента толстого.
Уровни
Даже в простой программе типа записной книжки имеется минимум 2 уровня:
• Уровень приложения, реализующий функционал предметной области.
• Уровень служб, поддерживающих общую для всех разрабатываемых приложений функциональность. Например, метаданные, безопасность, конфигурация, доступ к данным и т. д.
Рис. 7. Уровни АИС
В свою очередь, общие для многочисленных служб функции группируются в модули и соответствующие API уровня ядра системы. Таковы, например, API оконной системы графического интерфейса, SQL для доступа к реляционным базам данным, основанные на HTTP-протоколах веб-служб или компонентная среда сервера приложений.
С другой стороны, комплексная информационная система обладает множеством приложений, реализующих функционал нескольких предметных областей. В этом случае функциональность, связанная с их интеграцией и управлением, поднимается на уровень решения. Например, конфигурация информационных потоков между приложениями, включая пакетную обработку.
Совмещение
Теперь если мы наложим слои системы на её уровни, то получим достаточно простую матричную структуру, позволяющую бегло оценить, какой из элементов необходимо реализовать своими силами или же адаптировать уже имеющийся готовый. Но, что более существенно, реализация разных подсистем может осуществляться независимо друг от друга после спецификации своих межуровневых и межслойных интерфейсов.
Рис. 8. Уровни АИС в разрезе концептуальных слоёв
Многозвенная архитектура
Итак, концептуальных слоёв в автоматизированной информационной системе всегда три: хранения данных, их обработки и отображения. А вот физических, их реализующих, может быть от одного, в виде настольного приложения с индексированным файловым хранилищем, до теоретической бесконечности.
Имея опыт разработки систем всех перечисленных на рис. 6 типов, наиболее позитивные впечатления у меня остались от «двухзвенки» с тонким клиентом. Подробнее я расскажу об этой архитектуре в главе про разработку тиражируемой КИС Ultima-Seller.