1Разработка документации на изготовление экспериментального образца системы 1.1Архитектура экспериментального образца системы административного мониторинга 1.1.1Общая архитектура программного обеспечения экспериментального образца системы
Обобщенная архитектура программного обеспечения экспериментального образца системы административного мониторинга получена на основе анализа:
– обобщенной модели системы организационного управления (приведена в отчете по второму этапу НИР), составной частью которой является система административного мониторинга;
– принципов организации административного мониторинга (приведены в отчете по 1-му этапу НИР).
На рисунке 1.1 приведено графическое представление архитектуры адаптивной системы административного мониторинга.
В соответствии с принципами организации административного мониторинга первичные данные о состоянии объекта мониторинга могут поступать в систему либо путем ручного ввода операторами, либо путем импорта из существующих информационных систем.
В первом случае первичные данные перед их сохранением структурируются подсистемой сбора данных в соответствии с логической информационной моделью хранения данных, являющейся абстракцией объекта мониторинга.
Во втором случае первичные данные, представленные в заданном формате, обрабатываются и сохраняются в базе данных подсистемой импорта данных.
Задание информационной модели объекта и процедуры административного мониторинга (адаптация системы к задаче и параметрам процедуры мониторинга) осуществляется администратором системы посредством подсистемы настройки сбора и хранения данных.
Сохраненные в базе данных, структурированные в соответствии с заданной информационной моделью значения показателей могут быть в любой момент выданы для обработки.
Простейшая обработка данных, заключающаяся в построении сводных (за счет агрегации и простейшей математической обработки) и детальных отчетов осуществляется подсистемой генерации отчетов.
Получение информационно-аналитических ресурсов (представления состояния объекта административного мониторинга на более высоком уровне абстракции, пригодном для анализа и принятия управленческих решений) осуществляется в подсистеме анализа и контроля данных административного мониторинга.
Аналитической обработке и контролю могут быть подвержены как детальные данные (первично необработанные значения показателей), так и результаты их обработки, полученные посредством подсистемы генерации отчетов.
1.1.2Модель программной архитектуры базовых элементов системы административного мониторинга
Основными программными элементами системы мониторинга являются блоки чтения и записи элементов модели объекта мониторинга. В качестве основы программной архитектуры данных блоков была выбрана классическая трехуровневая архитектура, включающая компоненты хранилища, логики и представления. Однако в свете современных представлений о проектировании, целесообразнее использовать видоизменную архитектуру, более подходящую под концепцию MVC («model-view-controller»). От классической трехуровневой она отличается тем, что в ней выделен дополнительный связующий компонент – «контроллер». Контроллер является звеном между «представлением» и «логикой» (model в англоязычной литературе) системы, посредством которого и существует возможность произвести разделение между ними. Контроллер получает данные от пользователя и передает их в компонент «логика». Кроме того, он получает сообщения от логики, и передает их в «представление». Контроллер следит за переданными данными от пользователя и проводит их первичный анализ, в результате которого определяет необходимость одного из следующих действий:
– передать данные модулю логики;
– обработать ошибочный ввод без привлечения модуля логики, отправив «представлению» сообщение о некорректном вводе.
Кроме того, контроллер обязан определять тип данных, полученных от модуля логики (есть ли это готовый результат, отсутствие результата, либо сообщение об ошибке) и передавать информацию в модуль представления.
Фактически связка контроллер и представление и определяют интерфейс пользователя. Контроллер стоит на входе обработки пользовательской активности, а представление – на выходе.
На модуль логики данные поступают в формате, удобном для построения запросов к хранилищу, реализованному согласно модели хранения. Модуль логики на основе полученных данных формирует необходимые запросы к хранилищу и обрабатывает результат.
Данная архитектура позволяет строить алгоритмы, генерирующие все перечисленные в отчете по третьему этапу виды интерфейса (чтения и записи).
Генерация интерфейса чтения начинается с события открытия интерфейса навигации по отношению. Данное событие регистрирует контроллер, который обрабатывает данные о текущем месте пребывания пользователя среди элементов отношения и определяет новое требуемое состояние интерфейса чтения. В случае первого открытия интерфейса состояние определяется корневым элементом отношения, относительно которого и строится интерфейс. В случае совершения перехода пользователем по интерфейсу, новое состояние определяется текущим состоянием и навигационной ссылкой.
Определив необходимое состояние интерфейса, контроллер направляет вызов генерации определенно указанного интерфейса в компонент логики, который и проводит все непосредственные алгоритмические действия по генерации. В частности компонент логики запрашивает хранимые данные из хранилища, обрабатывает пришедший результат и передает полученную структуру интерфейса в контроллер.
Если в процессе обращения к хранилищу произошли ошибки, контроллер оповещается об этом и на представление уходит сообщение об ошибке. Если ошибок при работе компонента логики не возникло, то полученная контроллером структура направляется на «представление» для превращения ее в разметку вывода.
Описанный процесс представлен на рисунке 1.2.
Далее приведем архитектурную схему для генерации интерфейсов записи новых данных. Она в структурном понимании сходна с предыдущей. В событийной модели запись значения (показателя или объекта учета) начинается с события выбора «точки привязки» нового узла, значения, элемента списка и другого значения. Однако как было сказано выше, событие выбора «точки привязки» нового значения повторяет цикл, описанный в архитектурной схеме чтения при возникновении события перехода в интерфейсе навигации. Поэтому, в описании архитектурной схемы записи цикл поиска «родителя» пропустим.
Рисунок 1.2 – Архитектура реализации генерации интерфейса
чтения отношения
После определения «родителя», к которому в пару будет добавлено новое значение, контроллер должен зарегистрировать событие указания вида нового значения, что определит один из трех возможных типов интерфейса записи. Выражая это языком, представленным в модели хранения, после указания конкретного элемента множества области определения, необходимо в одном случае указать, во втором случае создать элемент множества области значения отношения, в третьем случае – создать ассоциацию между ними.
После того, как вид интерфейса записи определен, контроллер обращается к компоненту логики для вызова построения структуры интерфейса. Компонент логики, как и в предыдущем описании, получает необходимые для построения данные из хранилища и затем возвращает результат своей работы контроллеру. Если ошибок не возникло, то представление транслирует полученную структуру интерфейса в язык разметки и алгоритмы, обрабатывающие события на стороне клиента.
После получения форм интерфейса ввода, пользователь вводит в них новые данные и цикл запускается вновь. На контроллер поступает теперь не только текущее состояние интерфейса, но и введенное значение. Контроллер проводит контроль и первичную обработку поступившего значения. Если новое значение содержит форматную или другую ошибку, то контроллер без привлечения компонента модели отправляет ошибочную ситуацию на обработку «представлению», которое выводит сообщение об ошибочном вводе.
Если введенное данное удовлетворяет условиям проверки, то контроллер запускает процесс записи нового значения, осуществляемый в компоненте логики. В результате его работы в хранилище направляется запрос на вставку значения в базу данных, после чего на контроллер поступает извещение об изменениях.
После этого контроллер запускает обновление представления, отображающее интерфейс ввода, включающий информацию о введенном значении.
Схематично данную архитектуру можно представить циклом, аналогичным предыдущему рисунку, но со своей спецификой (Рисунок 1.3).
Не смотря на то, что в описании присутствуют две «итерации» цикла, на рисунке для упрощения представлена только одна. Чтобы лучше представить хронологически архитектурное взаимодействие воспользуется специализированным языком UML и представим на нем последовательность вызовов архитектурных компонентов.
Два участника взаимодействий между архитектурными компонентами - пользователь, которого представляет его агент и база данных – сами не являются реализационными элементами и не представлены классами. Агент пользователя может обращаться только к контроллеру, поскольку адрес, по которому пользователь запрашивает некоторый интерфейс, содержит в себе указатель на контроллер. Пользовательский агент не может обратится к чему-либо еще, ни к логике, ни к представлению. Таким образом, контроллер выступает своеобразным распределительным центром.
Рисунок 1.3 – Архитектура реализации генерации интерфейса записи данных
Несмотря на то, что при проектировании генератора интерфейсов были построены многие другие классы, на диаграмме последовательности они не показаны, так как данная диаграмма уделяет внимание только тем объектам, которые непосредственно участвуют во взаимодействии, обеспечивая связность архитектуры. В диаграмме последовательности не показаны статические ассоциации компонентов архитектуры с другими объектами.
Инициатором взаимодействия изобразим пользователя. Фокус управления пользователя будет присутствовать постоянно, характеризуя возможность его асинхронной активности. Не смотря на то, что формально существует время, уходящее на генерацию структуры интерфейса компонентом логики, во время которого пользователь находится в режиме пассивного ожидания ответа, но фактически это время достаточно мало, чтобы им можно было пренебречь.
После отправки запроса пользователем дальнейшее взаимодействие компонентов соответствует вышеописанному, только расположено в хронологическом порядке (Рисунок 1.4).
Представленная архитектура удобна тем, что для каждого компонента можно практически однозначно реализовывать свой основной класс, основанный на более общих служебных классах. Функциональность «представления» реализована в классе представления, который отвечает за формирование элементов управления блоков интерфейса или сообщений об ошибках. Контроллер реализован в отдельном классе. Поскольку контроллер отвечает за первичную проверку поступающих данных, а происходит это очень часто, то имеет смысл наследовать класс контроллера от более общего и повсеместно используемого класса проверки корректности данных. Компонент, реализующий логику, также должен располагаться в отдельном классе, наследованном от класса, обеспечивающего взаимодействие с базой данной через дополнительный логический слой.
Рисунок 1.4 – Диаграмма последовательности, специфицирующая коммуникацию между объектами путем передачи сообщений
|
