Рассмотрено обобщенное представление математической модели программной системы ИКОН, разработаны формальные модели ПС ИКОН, представленные в аналитическом виде UML-диаграмм. Описана трехуровневая архитектура ПС ИКОН в среде клиентсервер, а также процесс разработки сложных программных систем. The given paper describes а generalized representation of the mathematical model of the software system Instrumental Complex for Ontological Engineering Purpose (ICOEP). ICOEP is a system that implements one of the areas of complex technologies Data & Text Mining, namely, analysis and processing of linguistic corpus in Ukrainian and/or Russian, extraction of subject knowledge from them and representation of knowledge in ontology of the subject domain. To solve the problems of scalability, performance and security, a concept for the three-tier architecture of the ICOEP in the client-server environment was developed. Multitier architecture of the ICOEP consists of a presentation tier, a logic tier and a data tier. Functional-component model and UML diagrams (use case diagram, activity diagram, software entities diagram) of the ICOEP are presented. The process of developing complex software systems is described.
ПС с помощью выбранного языка 4. Тестирование и отладка (Testing, Debugging): поиск и исправление ошибок в программных модулях ПС.
6. Внедрение программной системы (Deployment): процесс настройки ПС под определенные условия эксплуатации, а также обучение пользователей работе с программным продуктом.
Разработка формальной модели ПС – это важный и основополагающий этап при проектировании сложной ПС, требующий системного анализа выбора математических структур, наиболее подходящих для моделирования заданного набора задач. Разработанная формальная модель должна позволять выполнять: оптимизацию алгоритмов функционирования моделей на протяжении всего жизненного цикла системы, в соответствии с критериями сложности реализации ПС и соответствующих алгоритмов, производительности, ограничения реального времени получения результата и другие.
С учетом изложенной выше концепции создания программных систем, необходимо разработать формальные модели инструментального средства автоматизированного построения онтологий предметных областей, названного “Инструментальным комплексом онтологического назначения” (ИКОН). Программная система “Инструментальный комплекс онтологического назначения” ИКОН является системой, реализующей одно из направлений комплексных технологий Data & Text Mining, а именно – анализ и обработку больших объемов неструктурированных данных, в частности лингвистических корпусов текстов на украинском и/или русском языке, извлечение из них предметных знаний с последующим их представлением в виде системно-онтологической структуры или онтологии предметной области (ПдО). ИКОН предназначен для реализации множества компонентов интегрированной информационной технологии [8].
Современный этап развития и построения программных систем характеризуется существенным усложнением процесса их разработки. Под программной системой понимается некоторая конечная совокупность программ, предназначенных для достижения поставленной цели (целей). Функционирование системы заключается в использовании входящих в нее программ (программных модулей), и может быть выполнено двумя способами [9]:
однопотоковое выполнение процессов (в каждый момент времени выполняется процедура (оператор) только в одной из программ, либо выполняется только одна программа (модуль) и все остальные программы (модули) в этот момент времени приостанавливают свою работу);
многопотоковое (мультипрограммное) выполнение процессов (в каждый момент времени выполняется
процедура (оператор) в каждой программе, либо параллельно выполняются несколько или более программ).
При построении модели ПС следует руководствоваться следующими принципами [
1. Модель системы не должна быть чрезмерно детальной (излишняя сложность модели может вызвать существенные вычислительные проблемы при ее формальном анализе).
2. Модель системы не должна быть чрезмерно упрощенной, она должна отражать те аспекты системы, которые имеют отношение к проверяемым свойствам, и сохранять все свойства моделируемой системы, представляющие интерес для анализа.
С точки зрения программной инженерии программная система рассматривается в виде набора описаний,
представленных в виде математических моделей, формализмов и техник моделирования [
Опишем каждую из перечисленных моделей. Информационная модель ПС ИКОН
Информационные модели используются для представления и описания потоков информации, структур данных, а также программ (модулей) в программной системе.
Обобщенная информационная модель ПС ИКОН представляется некоторой конечной совокупностью
программ (программных модулей) [
i1 интеграции функций множества программных модулей
GИКОН : SИКОН FИКОН , n – количество программных модулей входящих в ПС ИКОН, ИКОНi – некоторая программа (модуль) ПС ИКОН.
При этом реализуется отображение GИКОН ИКОН в обобщенную (целевую) функцию ИКОН: где i 1, n , где SИКОН – множество функций (набор функций) определенного программного модуля ИКОН, FИКОН – обобщённая функция ИКОН. (1) (2) ИКОН {МУГО , МЛАТД , МВПОС , МПТД , МИПТИ , МУБДЗ , МБД , МПО}. Рассмотрим более детально функциональные характеристики программных модулей ИКОН. 1. МУГО – набор функций программного модуля “Управляющая графическая оболочка”,
SИКОН (МУГО ) S1, S2 , S3, S4 , S5 , S6 , где S1 – осуществляет предварительное наполнение среды внешними электронными коллекциями энциклопедических, толковых словарей и тезаурусов, описывающих домен предметных знаний;
S2 – обеспечивает запуск и последовательность исполнения прикладных программ, реализующих составные информационные технологии проектирования онтологии ПдО и системной интеграции междисциплинарных знаний;
S3 – отображает ход процесса проектирования онтологии ПдО;
S4 – содержит позиции меню для запуска как последовательностей, так и отдельных прикладных программ, используемых в процессе проектирования онтологии ПдО;
S5 – обеспечивает интерфейс с естественным интеллектом; S6 – обеспечивает обмен информацией между прикладными программами и базами данных.
2. МПТД – набор функций программного модуля поиска текстовых документов, где S7 – поиск текстовой информации во внешних источниках;
S8 – формирование лингвистического корпуса текстов в библиотеке (базе данных) текстовых документов.
3. МИПТИ – набор функций программного модуля индексации и поиска текстовой информации, где S9 – создание и манипулирование индексами, по которым возможно найти информацию в соответствующих библиотеках ТД, тезаурусах, онтологиях. На данном этапе жизненного цикла ПО ПС ИКОН можно представить следующей совокупностью программных модулей: (3) (4) (5) (6) (7) (8) SИКОН (МИПТИ ) S9 ,
SИКОН (МЛАТД ) S10 , S11, S12 , 4. МЛАТД – набор функций программного модуля лингвистического анализа текстовых документов, где S10 – формирование множества терминов;
S11 – формирование множества понятий; S12 – формирование множества отношений между понятиями; 5. МПО – набор функций программного модуля построения онтологии ПдО,
S ИКОН ( МПО ) S13 , S14 , S15 , S16 , S17 , S18 , S19 , где S13 – считывает из модуля визуального проектирования онтологических структур начальную онтологию ПдО. Из библиотеки ЭК считывает определения понятий, входящих в начальную онтологию, и формирует множества функций интерпретации;
S14 – считывает из соответствующей библиотеки онтографы и формализованные описания онтологий ТД, проверяет их на непротиворечивость;
S15 – анализирует на полноту множества функций интерпретации. Просматривает электронные коллекции энциклопедических, толковых словарей и тезаурусов и пополняет множества последних для соответствующих понятий-объектов и понятий-процессов;
S16 – в процессе построения онтологии, по необходимости, обращается к любому информационному хранилищу;
S17 – выполняет поочередную привязку онтографов и функций интерпретации онтологий ТД; S18 – выполняет привязку общего онтографа ТД и множеств функций интерпретации с онтографом и множествами функций интерпретации начальной онтологии соответственно;
6. структур, S19 – передает полученный результат в модуль визуального проектирования на верификацию. МВПОС – набор функций программного модуля визуального проектирования онтологических
SИКОН (МВПОС ) S20 , S21, S22 , где S20 – разработка начальной онтологии ПдО;
S21 – ручное неавтоматизированное проектирование онтологии ПдО; S22 – верификация онтографа.
7. МУБДЗ – набор функций программного модуля управления библиотеками данных и знаний,
S ИКОН ( МУБДЗ ) S 23 , S 24 , где S23 – осуществляет запись, накопление и хранение информации в соответствующих библиотеках; S24 – по запросу менеджера проектов осуществляет чтение из библиотек запрашиваемой информации. 8. МБД – набор функций программного модуля базы данных,
SИКОН (МБД ) S25 , S26 , S27 , S28 , S29 , S30 , S31 , где S25 – накопление и хранение онтологий ПдО;
S26 – накопление и хранение ТД; S27 – накопление и хранение ЛКТ; S29 – накопление и хранение проектов ИКОН; S30 – поиск по БД; S31 – работа в режиме клиент-сервер.
S28 – накопление и хранение списков множеств терминов, понятий и отношений; Функционально-компонентная модель ПС ИКОН
Функционально-компонентная модель используется для представления взаимодействий, отношений и зависимостей программных модулей в ПС, а также для подробного описания компонентов системы. Обобщенная функционально-компонентная модель ПС ИКОН может быть представлена в виде:
SИКОН М Dyn , М Stat , М Phys , М Cmp , P0 (М Dyn , М Stat ) . Рассмотрим более подробно функционально-компонентную модель ПС ИКОН.
1. М Dyn – модель, определяющая поведение системы. Рассматривается как UML dynamic model [
M Dyn duse , dact , dseq , где duse – множество UML-диаграмм вариантов использования ПС ИКОН, dact – множество UML-диаграмм активности ПС ИКОН, dseq – множество UML-диаграмм взаимодействий ПС ИКОН.
2. М Stat – модель, определяющая структуру системы. Рассматривается как UML static model [
M Stat dclass ,bStat , req ,
где dclass – множество UML-диаграмм классов ПС ИКОН,
bStat – множество статических блок-схем ПС ИКОН,
req – техническое задание на проектирование ПС ИКОН.
(9)
(10)
(11)
(12)
(13)
(14)
исходного кода, библиотеки, исполняемые файлы, и отношения между ними. Физическая модель (Physical
model) [
M Phys src,lib,exef , (15) где src – файлы исходного кода, lib – программные библиотеки, exef – исполняемые файлы.
4.
М Cmp – модель (схема) компонентов ПС, используется для визуализации высокоуровневой
структуры системы и поведения служб (сервисов), предоставляемых и потребляемых этими элементами
(компонентами) через интерфейсы. Компонент – это модульная единица, заменяемая в пределах среды. Его
внутренние составляющие скрыты, но доступ к функциям компонента можно получить с помощью одного или
нескольких четко определенных предоставленных интерфейсов (provided interfaces). Компонент также может
иметь требуемые интерфейсы (required interfaces). Требуемый интерфейс определяет, какие функции и службы
(сервисы) он требует от других компонентов. Объединив предоставленные и требуемые интерфейсы
нескольких компонентов, можно создать более крупный компонент. Можно сказать, что вся ПС, по сути,
представляет собой компонент [
Создание схем компонентов имеет несколько преимуществ.
Анализ основных элементов ПС позволяет команде разработчиков понять принципы существующей системы и создать новую.
Представление ПС в качестве коллекции компонентов с четко определенными предоставленными и требуемыми интерфейсами позволяет более эффективно разделить компоненты. В свою очередь, это облегчает понимание конструкции ПС и ее корректирование при изменении требований.
Использование диаграммы (схемы) компонентов для представления конструкции ПС независимо от того, какой язык программирования или программная платформа используется сейчас или будет использоваться в будущем.
5. P0 (М Dyn , М Stat ) – предикат целостности системы, определяющий назначение системы, семантику (смысл) моделей М Dyn и М Stat [17];
UML-диаграмма вариантов использования высокого уровня абстракции ПС ИКОН показана на рис. 1. Суть данной диаграммы состоит в следующем: проектируемая система представляется в виде множества сущностей или акторов (actor), взаимодействующих с системой с помощью так называемых вариантов использования. При этом актором или действующим лицом называется любая сущность, взаимодействующая с системой извне. Это может быть человек, техническое устройство, программа или любая другая система, которая может служить источником воздействия на моделируемую систему. В свою очередь, вариант использования служит для описания сервисов, которые система предоставляет актору. Эксперт ПдО Формирование
множества терминов и понятий <include>
<include> УГО ИКОН
<uses> Визуализация о проверка онтографа ПдО(Protege) Инструментальный комплекс онтологического назначения <include> Формирование множества отношений
<include> <include> Поиск текстовых документов в сети Internet <include> ИнИТ автоматизированно го построения онтологий <include>
<include> Индексация и поиск текстовой информации <include>
<include> Визуальное пректирование
онтологий Управление библиотеками ИКОН Лингвистический анализ ТД ПдО <extend> <include> <include> <extend> Поиск с помощью WolframAlpha API Поиск с помощью
Bing API Поиск с помощью
Google API Конвертация файлов описания онтологий Библиотека справочной информации Рис. 1. UML-диаграмма вариантов использования ПС ИКОН.
UML-диаграмма активности высокого уровня абстракции ПС ИКОН показана на рис. 2.
С помощью диаграммы активности (рис. 2) можно изучать поведение системы с использованием моделей потока данных и потока управления. Диаграмма активности отображает некоторый алгоритм, описывающий жизненный цикл объекта, состояния которого могут меняться.
Наполнениеподсистемы "Информационный ресурс" (локальный сервер БД Redis) Инициализация модулей ИКОН Анализ ТД ПдО Формирование множества терминов Формирование
множества отношений между терминами Инициализация
УГОИКОН [инициализация] Наполнениеподсистемы "Информационный ресурс" (Удалённый сервер БД Redis) [иначе] [сохранить] Визуальное проектирование онтологии ПдО [да] Построение онтологии ПдО [нет]
Рис. 2. UML-диаграмма активности ПС ИКОН Физическая модель программных сущностей ПС ИКОН показана на рис. 3.
Knowledge engine
WolframAlpha Search engine
Bing Search engine
Google БД Redis [выход] Представленная модель отображает неизменяемую структуру программных сущностей, в частности файлов исходного кода, библиотек, исполняемых файлов, и отношений между ними.
Instrumental complex for ontological engineering purpose Downloads
Lib Redis-2.6.9
DJNativeSwing-SWT.jar DJNativeSwing.jar WolframAlpha-1.1.jar beansbinding-1.2.1.jar bing-search-java-sdk.jar commons-codec-1.4.jar httpcore-4.1.2.jar httpmime-4.1.2.jar jackson-core-asl-1.9.4.jar 1.10.3-beta.jar google-api-client-appengine.jar google-api-client-servlet .jar google-customsearch.jar jedis-2.1.0.jar jna.jar.zip jsr305-1.3.9.jar protobuf-java-2.2.0.jar swing-layout-1.0.4.jar swt-3.6M7-win32-win32-x86.jar gson-1.4.jar
UML-диаграмма компонентов высокого уровня абстракции ПС ИКОН представлена на рис. 4, а и б. UML-диаграмма компонентов используется для визуализации высокоуровневой структуры системы и поведения служб (сервисов), предоставляемых и потребляемых этими элементами (компонентами) через интерфейсы. Трехуровневая архитектура ПС ИКОН В процессе разработки ПС ИКОН возник ряд проблем, в частности, проблемы масштабируемости, производительности, безопасности. Для решения вышеуказанных проблем была разработана концепция трёхуровневой архитектуры ПС ИКОН.
В терминах программной инженерии трехуровневая архитектура (Multitier architecture) состоит из уровня
представления (Presentation tier), уровня логики (Logic tier), уровня данных (Data tier) и предполагает наличие
следующих компонентов приложения: клиентское приложение (“тонкий клиент” или терминал), подключенное
к серверу приложений, который в свою очередь подключен к серверу базы данных (БД) [
Клиент – это интерфейсный (обычно графический) компонент, который реализует уровень представления, собственно приложение для конечного пользователя. Первый уровень не должен иметь прямых связей с базой данных (по требованиям безопасности), быть нагруженным основной бизнес-логикой [21] (по требованиям масштабируемости) и хранить состояние приложения (по требованиям надежности). На первый уровень может быть вынесена и обычно выносится простейшая бизнес-логика: интерфейс авторизации, алгоритмы шифрования, проверка вводимых значений на допустимость и соответствие формату, несложные операции (сортировка, группировка, подсчет значений) с данными, уже загруженными на терминал.
Сервер приложений реализует уровень логики ПС ИКОН, на котором сосредоточена бо́льшая часть бизнес-логики (описание функциональных алгоритмов, обрабатывающих обмен информацией между сервером БД и клиентом). Вне его остаются фрагменты, экспортируемые на терминалы, а также погруженные в третий уровень хранимые процедуры и функции.
Сервер БД обеспечивает хранение данных и реализует третий уровень – уровень данных. Обычно это стандартная реляционная или объектно-ориентированная система управления базами данных (СУБД). Если третий уровень представляет собой БД вместе с хранимыми процедурами и схемой, описывающей приложение в терминах реляционной модели, то второй уровень строится как программный интерфейс, связывающий клиентские компоненты с прикладной логикой (программным модулем) БД.
В простой конфигурации физически сервер приложений может быть совмещен с сервером БД на одном компьютере, к которому по сети подключается один или несколько терминалов. В “правильной” (с точки зрения безопасности, надежности, масштабируемости) конфигурации сервер БД находится на выделенном компьютере (или кластере), к которому по сети подключены один или несколько серверов приложений, к которым, в свою очередь, по сети подключаются терминалы (рис. 5).
Сервер Приложений (Сервисов) Сервер
базы данных Клиент 1 Клиент 2
Клиент 3 Рис. 5. Пример трехуровневой архитектуры Основные достоинства трехуровневой архитектуры ПС: масштабируемость – способность системы справляться с увеличением рабочей нагрузки (увеличивать свою производительность) при добавлении аппаратных ресурсов; конфигурируемость – изолированность уровней друг от друга позволяет (при правильном развертывании архитектуры) быстро и простыми средствами переконфигурировать систему при возникновении сбоев или при плановом обслуживании на одном из уровней; высокие безопасность и надежность; низкие требования к скорости передачи информации канала (сети) между терминалами и сервером приложений;
низкие требования к производительности и техническим характеристикам терминалов, как следствие снижение их стоимости. Терминалом может выступать не только компьютер, но и, например, мобильный телефон.
К недостаткам трехуровневой архитектуры ПС в сравнении с файл-серверной архитектурой следует отнести: более высокая сложность создания приложений; сложнее в разворачивании и администрировании; высокие требования к производительности серверов приложений и сервера базы данных, а, значит, и высокая стоимость серверного оборудования;
высокие требования к скорости канала (сети) между сервером базы данных и серверами приложений. Рассмотрим реализацию трехуровневой архитектуры ИКОН. На рис. 6 представлена обобщенная структурная схема трехуровневой архитектуры ИКОН.
Уровень представления
(Presentation tier) Пользовательский интерфейс
(User interface) Управляющая графическая оболочка ИКОН Уровень логики (Logic tier) Сервисы (Services) Процедуры и функции реализующие интегрированную информационную технологию автоматизированного построения онтологий предметных областей Уровень данных (Data tier) Сервер БД Рис. 6. Обобщенная структурная схема трехуровневой архитектуры ИКОН На уровне представления реализовано клиентское приложение “Управляющая графическая оболочка”. На уровне логики реализованы процедуры и функции, обеспечивающие функционирование программных модулей ПС ИКОН и предоставляемых ими сервисов (модуль управления библиотеками; модуль индексации и поиска текстовой информации; модуль построения онтологии ПдО; модуля поиска текстовых документов; модуля лингвистического анализа текстовых документов; модуля визуального проектирования онтологических структур; модуль построения отношений между понятиями). На уровне данных реализован сервер БД Redis, обеспечивающий хранение данных ИКОН (лингвистического корпуса текстов, цифровой библиотеки справочной информации, онтологических структур, терминов, понятий, словарей, тезаурусов, текстовых документов). Уровни архитектуры ПС ИКОН находятся в двусторонней зависимости, которая указывает на то, что один уровень может использовать функции другого уровня и наоборот.
Инициализация клиентского приложеия УГО Начало Загрузка текстового документа Отправка текстовго документа на сервер бизнес логики Logic tier
Лингвистический анализ текстового документа библиотекой
konspektlib.dll Построение онтологии ПдО Отправка результатов выполнения бизнес логики клиентскому
приложению УГО Отображение результатов выполнения бизнес логики в клиентском приложении УГО Сохранение данных в БДRedis
Конец Рис. 7. Алгоритм работы ИКОН в трехуровневой архитектуре Выводы
В работе предложено обобщённое представление формальной модели программной системы “Инструментальный комплекс онтологического назначения” автоматизированного построения онтологий предметных областей. Разработаны и дополнены формальные модели ПС ИКОН, в соответствии с развитием алгоритмов, процедур, разработки и функционирования программной системы в целом. Спроектирована функционально-компонентная модель ПС ИКОН, в частности, UML-диаграмма компонентов ПС ИКОН, описывающая взаимодействие и отношения программных модулей в системе. Рассмотрена концепция трёхуровневой архитектуры ПС ИКОН в среде клиент-сервер. Описан полный процесс разработки сложных программных систем. За рамками данной работы остались особенности реализации концепции трёхуровневой архитектуры ПС ИКОН, а также описание методологии разработки ПО и ПС в целом.