Разработка архитектурной модели системы управления информационными ресурсами организаций

Введение

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

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

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

Рисунок 1 – Итерационный процесс архитектурного анализа

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

Создание формальных моделей - сложный и трудоемкий процесс, тем более архитектурных моделей. Одним из известных и широко распространенных является подход к описанию архитектуры с использованием видов (представлений). Филипп Крухтен описал модель представления архитектуры программного обеспечения "4+1” для описания архитектуры сложных программных систем в 1995 году [2]. Дальнейшее развитие эта модель получила в разработках модели Rational Unified Process, а также в стандарте IEEE 1471-2000/ISO 42010. В оригинальной модели "4+1" используются пять видов: использования (Use Case View), логических представлений (Logical view), компонентов (Development view), развертывания/размещения (Physical view), динамическое представление (Process view). Каждый вид модели "4+1" описывает процесс с определенной точки зрения. Модель изменяемая, т.е. можно ограничивать количество предлагаемых видов, или расширять, добавляя другие виды для описания системы с другой точки зрения.

Разработаем структурную архитектурную модель для системы управления информационными ресурсами организаций (СУИР), опираясь на аппарат формализации и архитектурную модель "4+1".

Разработка структурной архитектурной модели ИС

Взяв за основу известную архитектурную модель "4+1", модифицируем ее, уделив в первую очередь внимание структурным и статическим аспектам построения ИС. Описание полученной архитектурной модели сведем в таблицу 1.

Диаграммы модели представляют собой средство для визуализации. Таким образом, архитектурная модель СУИР состоит из ряда формальных моделей, представленных в виде графических диаграмм нотации UML, а также дополнительной Structural diagram, в комплексе описывающих структуру и функциональность разрабатываемой ИС (см. рис. 2).

Рисунок 2 – Набор видов и диаграмм архитектурной модели

Одной из первых задач, которую надо решить при архитектурном проектировании ― определение существенно значимых требований. Роль архитектора систем заключается в том, чтобы создать целевую архитектуру, подходящую для удовлетворения основных потребностей пользователя. Поэтому необходимо изучить сценарии и определить факторы, которые оказывают существенное влияние на будущий архитектурный проект. Для описания функциональности ИС, взаимодействия пользователя с внешними информационными системами на практике обычно используются USE-CASE диаграммы в нотации UML — это термин, посвященный системному проектированию [3]. Диаграмма вариантов использования представляет собой граф специального вида, который является формализованной нотацией для представления конкретных вариантов использования, актеров, возможно некоторых интерфейсов, и отношений между этими элементами [4]. Вариант использования представляет собой некоторый сценарий или отдельную функцию, а актер описывает или пользователя, взаимодействующего с вариантом использования или некоторую внешнюю систему.

В работе [1] были разработаны и приведены обобщенная функциональная модель и абстрактная архитектура программного комплекса системы управления профессиональными знаниями сотрудников вуза (см. рис. 3), которая включает в себя 15 основных модулей. Описание программных модулей сведем в табл. 2.

С функциями системы работают несколько пользователей: эксперт, администратор знаний, преподаватель и студент. Самым востребованным специалистом на этапе наполнения базы знаний является эксперт. Помощь ему предоставляет инженер по управлению знаниями (администратор знаний). Но без участия всего коллектива трудно достигнуть хорошего результата. Между ролями установлена иерархия пользователей. Это означает, что пользователь с более высоким уровнем прав наследует всю функциональность менее привилегированного пользователя.

Рисунок 3 – Диаграмма вариантов использования (use-case diagram)

Модульная структурная модель системы (package diagram)

Диаграмма пакетов используется, чтобы изобразить зависимости между пакетами, которые составляют модель [5]. Основная цель — показать взаимосвязь между различными крупными компонентами, которые образуют сложную систему. Пакет (package) объединяет некоторые элементы диаграммы UML в единую структурную единицу. В нашем случае пакеты представляют собой отдельные независимые подсистемы, реализующие основные функции системы управления ИР.

В работах [6,7] были изучены аспекты применения онтологий при проектировании ИС научно-образовательных организаций и обоснована целесообразность онтологического подхода к разработке системы обработки данных научных и научно-образовательных организаций.

Процессы управления знаниями базируются на следующих основных принципах: приобретения, представления, хранения, извлечения знаний. Структура системы базируется на метамодели, приведенной в работе [1], и представляет собой типичную структуру системы управления знаниями (СУЗ), построенную на онтологическом подходе. Основными компонентами предлагаемой технологии создания системы являются: блоки приобретения данных, конвейер для обработки и классификации данных, а также блок выдачи и продукции знаний. Поскольку ядром, базовым компонентом метамодели системы является его онтология, то центральным блоком системы является онтологический редактор, который предназначен для реализации основных операций по работе с онтологиями, в том числе и процедур автоматического и полуавтоматического пополнения знаний.

Основные структурные модули (пакеты), входящие в состав проектируемой СУИР, следующие: acquiring knowledge; knowledge discovery and classification of knowledge; knowledge extraction; ontology editor; interface. Модульная структурная модель системы (package diagram) представлена на рис. 4, а назначение и описание основных пакетов сведено в табл. 3.

Рисунок 4 – Модульная структурная модель системы (package diagram)

Обобщенная компонентная модель системы (component diagram)

Диаграмма компонентов (Component diagram) — статическая структурная диаграмма, показывает разбиение программной системы на структурные компоненты и связи (зависимости) между компонентами [8]. Сomponent diagram предназначена для моделирования иерархии компонентов (а также модулей, пакетов и подсистем), что позволяет определить структуру разрабатываемой системы (см. рис. 5).

Рисунок 5 – Компонентная модель системы (component diagram)

В качестве физических компонентов могут выступать файлы, библиотеки, модули, исполняемые файлы, пакеты и др. В нашем случае component diagram описывает основные пакеты, описание которых приведено в табл. 3 и программные модули, описание которых сведено в табл.2.

Обобщенная структурно-функциональная модель системы Structural model

Формализуем обобщенную компонентную модель системы, наполнив ее функциональным содержимым и назовем обобщенной структурно-функциональной моделью системы (structural model). Эта модель представляет собой комбинацию из некоторого конечного множества пакетов Pi, каждый из которых включает в себя некоторый набор программных модулей Mj. В свою очередь каждый j-й модуль реализует некоторое количество функций F(Pi).

Таким образом, F(MODEL) - обобщённая функция системы, определяется следующим образом:

Сведем описание всех функций ИС в таблицу 4.

Опишем функциональную модель каждого программного модуля (см. табл. 5).

Исходя из выше приведенных выражений 1-4 получаем:

MODEL= {P1, P2, P3, P4, P5}

P1= {M1, M2, M3, M4};

P2= {M5, M6, M7, M8};

P3= {M9, M10, M11};

P4= {M12, M13, M14};

P5={M15}

F(P1) =F(M1) U F(M2) U F(M3) U F(M4);

F(P2) =F(M5) U F(M6) U F(M7) U F(M8);

F(P3) =F(M9) U F(M10) U F(M11);

F(P4) =F(M12) U F(M13) U F(M14);

F(P5) =F(M15);

F(MODEL)= F(P1) UF(P2) UF(P3) UF(P4) UF(P5)

Модель размещения компонентов системы (deployment diagram)

Диаграммы deployment diagrams (размещения/развертывания) используются для моделирования физической архитектуры системы [8]. Диаграмма отображает аппаратные узлы и программные модули, и связи между ними. Узел (node) представляет собой некоторый физически существующий элемент системы, обладающий некоторым вычислительным ресурсом. Графически на диаграмме развертывания узел изображается в форме трехмерного куба. Узел имеет собственное имя, которое указывается внутри этого графического символа.

На данной диаграмме хорошо просматривается трехуровневая клиент-серверная архитектура приложения. Особенностью является физическое отделение данных от программ (сервер приложения), обрабатывающих эти данные. Такое разделение программных компонент позволяет оптимизировать нагрузки как на сетевое, так и на вычислительное оборудование комплекса. Компоненты трехуровневой архитектуры, с точки зрения программного обеспечения, реализуют сервера БД, Web-сервера и браузеры в качестве Web-клиентов.

Опишем взаимодействие компонентов трехуровневой архитектуры клиент-серверного приложения. Сервер БД представлен Cache-сервером Ontology Server, роль сервера приложений играет «Web Server», роль клиента «ClientWS#1» выполняет компьютер с клиентским ПО (см. рис 6).

Рисунок 6 – Модель размещения компонентов системы (deployment diagram)

Никаких ограничений на количество клиентских станций не накладывается. На клиентском ПК установлен любой браузер, например Operа, и локально установленный компонент Rich Java Script Ui, задействованный в обмене данных с сервером данных.

Сервер приложений представляет веб сервер Apache с установленным серверным ПО. Разработка серверного ПО проводилась с использованием языка PHP7.0 и различных фреймворков и библиотек, например phpmorphy, phpquery-single, adam-lutka/php-wndb, php-text-analysis, pdfparser, wikibase-api, ext-json, ext-curl, ext-zip, PHPCache и др.

На рис. 5 показана архитектура узла «Web Server» при развертывании в условиях конкретной организации. На сервере уже функционирует веб-сервер Windows Server IIS, который используется для решения других задач и нет возможности использовать еще один узел. Для работы нашего программного комплекса пришлось установить веб сервер Apache для работы с PHP и различными фреймворками на том же физическом узле и настроить на различные порты для обеспечения совместного функционирования.

Узел «OntologyServer» представляет собой сервер данных CACHE InterSystems IRIS, который представляет собой современную платформу для работы с многомерными данными, ориентированную для работы в среде Веб-пространства и использующей в работе встроенный HTTP Server.

Взаимодействие между узлами «ClientWS#1» и «Web Server», а также узлами «Web Server» и «OntologyServer» осуществляется стандартным образом с помощью HTTP – запросов поверх сетевого протокола TCP/IP. Передача данных происходит в JSON формате через взаимодействие компонета Server RESTFull Brocker, входящего в состав CACHE InterSystems IRIS и компонента Rich Java Script Ui, установленном на клиенте.

Выводы

В статье приводится подход на базе известной архитектурной модели “4+1” к разработке модели системы, которую можно рассматривать как совокупность архитектурно - конструкторских решений, формирующих результирующее программное решение. Была описана структурная архитектурная модель, представляющая собой набор следующих диаграмм: функциональную модель (use-case diagram), структурную модель системы (package diagram), обобщенную компонентную модель системы (component diagram), модель размещения компонентов системы (deployment diagram) с помощью нотации UML. Приведено формализованное описание структурно-функциональных моделей отдельных программных блоков и всей системы в целом (structural diagram). Описанная структурная архитектурная модель может использоваться при проектировании различных систем управления информационными и библиотечными ресурсами, а также применяться в различных системах управления знаниями.

Литература