Development of formal models, algorithms, procedures, engineering and functioning of the software system “Instrumental complex for ontological engineering purpose”
The given paper considered a generalized model representation of the SS ICOP. Represented complete software system development process. Developed relevant formal models of SS ICOP, represented as mathematical expressions, UML diagrams, and also described the three-tier architecture of SS ICOP in a c...
Gespeichert in:
| Datum: | 2025 |
|---|---|
| Hauptverfasser: | , , , |
| Format: | Artikel |
| Sprache: | Russian |
| Veröffentlicht: |
PROBLEMS IN PROGRAMMING
2025
|
| Schlagworte: | |
| Online Zugang: | https://pp.isofts.kiev.ua/index.php/ojs1/article/view/715 |
| Tags: |
Tag hinzufügen
Keine Tags, Fügen Sie den ersten Tag hinzu!
|
| Назва журналу: | Problems in programming |
| Завантажити файл: |  |
Institution
Problems in programming| id |
pp_isofts_kiev_ua-article-715 |
|---|---|
| record_format |
ojs |
| resource_txt_mv |
ppisoftskievua/85/1b44cd96a6037a6c13f307dbb3f92285.pdf |
| spelling |
pp_isofts_kiev_ua-article-7152025-04-09T22:22:32Z Development of formal models, algorithms, procedures, engineering and functioning of the software system “Instrumental complex for ontological engineering purpose” Развитие формальных моделей, алгоритмов, процедур, разработки и функционирования программной системы "Инструментальный комплекс онтологического назначения” Palagin, O.V. Petrenko, M.G. Velychko, V.Yu. Malakhov, K.S. UDC 004.2: 004.3 УДК 004.2: 004.3 The given paper considered a generalized model representation of the SS ICOP. Represented complete software system development process. Developed relevant formal models of SS ICOP, represented as mathematical expressions, UML diagrams, and also described the three-tier architecture of SS ICOP in a client-server environment.Prombles in programming 2014; 2-3: 221-232 Рассмотрено обобщенное представление математической модели программной системы ИКОН, разработаны формальные модели ПС ИКОН, представленные в аналитическом виде UML-диаграмм. Описана трехуровневая архитектура ПС ИКОН в среде клиент-сервер, а также процесс разработки сложных программных систем.Prombles in programming 2014; 2-3: 221-232 PROBLEMS IN PROGRAMMING ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ ПРОБЛЕМИ ПРОГРАМУВАННЯ 2025-04-09 Article Article application/pdf https://pp.isofts.kiev.ua/index.php/ojs1/article/view/715 PROBLEMS IN PROGRAMMING; No 2-3 (2014); 221-232 ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ; No 2-3 (2014); 221-232 ПРОБЛЕМИ ПРОГРАМУВАННЯ; No 2-3 (2014); 221-232 1727-4907 ru https://pp.isofts.kiev.ua/index.php/ojs1/article/view/715/767 Copyright (c) 2025 PROBLEMS IN PROGRAMMING |
| institution |
Problems in programming |
| baseUrl_str |
https://pp.isofts.kiev.ua/index.php/ojs1/oai |
| datestamp_date |
2025-04-09T22:22:32Z |
| collection |
OJS |
| language |
Russian |
| topic |
UDC 004.2: 004.3 |
| spellingShingle |
UDC 004.2: 004.3 Palagin, O.V. Petrenko, M.G. Velychko, V.Yu. Malakhov, K.S. Development of formal models, algorithms, procedures, engineering and functioning of the software system “Instrumental complex for ontological engineering purpose” |
| topic_facet |
UDC 004.2: 004.3 УДК 004.2: 004.3 |
| format |
Article |
| author |
Palagin, O.V. Petrenko, M.G. Velychko, V.Yu. Malakhov, K.S. |
| author_facet |
Palagin, O.V. Petrenko, M.G. Velychko, V.Yu. Malakhov, K.S. |
| author_sort |
Palagin, O.V. |
| title |
Development of formal models, algorithms, procedures, engineering and functioning of the software system “Instrumental complex for ontological engineering purpose” |
| title_short |
Development of formal models, algorithms, procedures, engineering and functioning of the software system “Instrumental complex for ontological engineering purpose” |
| title_full |
Development of formal models, algorithms, procedures, engineering and functioning of the software system “Instrumental complex for ontological engineering purpose” |
| title_fullStr |
Development of formal models, algorithms, procedures, engineering and functioning of the software system “Instrumental complex for ontological engineering purpose” |
| title_full_unstemmed |
Development of formal models, algorithms, procedures, engineering and functioning of the software system “Instrumental complex for ontological engineering purpose” |
| title_sort |
development of formal models, algorithms, procedures, engineering and functioning of the software system “instrumental complex for ontological engineering purpose” |
| title_alt |
Развитие формальных моделей, алгоритмов, процедур, разработки и функционирования программной системы "Инструментальный комплекс онтологического назначения” |
| description |
The given paper considered a generalized model representation of the SS ICOP. Represented complete software system development process. Developed relevant formal models of SS ICOP, represented as mathematical expressions, UML diagrams, and also described the three-tier architecture of SS ICOP in a client-server environment.Prombles in programming 2014; 2-3: 221-232 |
| publisher |
PROBLEMS IN PROGRAMMING |
| publishDate |
2025 |
| url |
https://pp.isofts.kiev.ua/index.php/ojs1/article/view/715 |
| work_keys_str_mv |
AT palaginov developmentofformalmodelsalgorithmsproceduresengineeringandfunctioningofthesoftwaresysteminstrumentalcomplexforontologicalengineeringpurpose AT petrenkomg developmentofformalmodelsalgorithmsproceduresengineeringandfunctioningofthesoftwaresysteminstrumentalcomplexforontologicalengineeringpurpose AT velychkovyu developmentofformalmodelsalgorithmsproceduresengineeringandfunctioningofthesoftwaresysteminstrumentalcomplexforontologicalengineeringpurpose AT malakhovks developmentofformalmodelsalgorithmsproceduresengineeringandfunctioningofthesoftwaresysteminstrumentalcomplexforontologicalengineeringpurpose AT palaginov razvitieformalʹnyhmodelejalgoritmovprocedurrazrabotkiifunkcionirovaniâprogrammnojsistemyinstrumentalʹnyjkompleksontologičeskogonaznačeniâ AT petrenkomg razvitieformalʹnyhmodelejalgoritmovprocedurrazrabotkiifunkcionirovaniâprogrammnojsistemyinstrumentalʹnyjkompleksontologičeskogonaznačeniâ AT velychkovyu razvitieformalʹnyhmodelejalgoritmovprocedurrazrabotkiifunkcionirovaniâprogrammnojsistemyinstrumentalʹnyjkompleksontologičeskogonaznačeniâ AT malakhovks razvitieformalʹnyhmodelejalgoritmovprocedurrazrabotkiifunkcionirovaniâprogrammnojsistemyinstrumentalʹnyjkompleksontologičeskogonaznačeniâ |
| first_indexed |
2025-07-17T10:08:38Z |
| last_indexed |
2025-07-17T10:08:38Z |
| _version_ |
1850411378316148736 |
| fulltext |
Інтелектуальні інформаційні технології
© О.В. Палагін, М.Г. Петренко, В.Ю. Величко, К.C. Малахов, 2014
ISSN 1727-4907. Проблеми програмування. 2014. № 2–3. Спеціальний випуск 221
УДК 004.2: 004.3
РАЗВИТИЕ ФОРМАЛЬНЫХ МОДЕЛЕЙ, АЛГОРИТМОВ,
ПРОЦЕДУР, РАЗРАБОТКИ И ФУНКЦИОНИРОВАНИЯ
ПРОГРАММНОЙ СИСТЕМЫ “ИНСТРУМЕНТАЛЬНЫЙ
КОМПЛЕКС ОНТОЛОГИЧЕСКОГО НАЗНАЧЕНИЯ”
А.В. Палагин, Н.Г. Петренко, В.Ю. Величко, К.С. Малахов
Институт кибернетики имени В.М. Глушкова НАН Украины,
Киев-187 МСП, 03680, проспект Академика Глушкова, 40,
email: palagin_a@ukr.net, факс: +38044 5263348
Рассмотрено обобщенное представление математической модели программной системы ИКОН, разработаны формальные модели
ПС ИКОН, представленные в аналитическом виде UML-диаграмм. Описана трехуровневая архитектура ПС ИКОН в среде клиент-
сервер, а также процесс разработки сложных программных систем.
The given paper considered a generalized model representation of the SS ICOP. Represented complete software system development
process. Developed relevant formal models of SS ICOP, represented as mathematical expressions, UML diagrams, and also described the
three-tier architecture of SS ICOP in a client- server environment.
Введение
На протяжении нескольких десятилетий задача поиска эффективного повторяемого и предсказуемого
процесса или методологии, позволяющей улучшить производительность, качество и надежность разработки
программного обеспечения (ПО) и программных систем (ПС) является актуальной. Известны работы, в кото-
рых предлагается (на базе методов структурного программирования) технология надежной разработки ПО и
ПС, используя при этом тестирование и верификацию программ на основе методов доказательного проекти-
рования [1]. Разработка программных систем [2, 3] (Software development process, Software development life-
cycle (SDLC)) – это процесс, направленный на создание и поддержку работоспособности, качества и надеж-
ности ПС, используя технологии и методологии из информатики, математики и других инженерно-
прикладных дисциплин. Полный процесс разработки ПС [2, 4] выполняется в несколько этапов.
1. Определение требований к ПС (Requirements, Specification): извлечение, анализ, спецификация и
утверждение требований для ПС (или составление технического задания на проектирование ПС).
2. Проектирование ПС (Architecture, Design): построение формальной модели ПС, проектирование ПС
средствами Computer-Aided Software Engineering (описание моделей ПС на унифицированном языке моделиро-
вания UML).
3. Инженерия ПС (Software engineering): реализация ПС с помощью выбранного языка программирова-
ния (написание исходного кода).
4. Тестирование и отладка (Testing, Debugging): поиск и исправление ошибок в программных модулях ПС.
5. Подготовка документации на ПС (Software documentation): множество необходимых инструкций
пользователя ПС.
6. Внедрение программной системы (Deployment): процесс настройки ПС под определенные условия
эксплуатации, а также обучение пользователей работе с программным продуктом.
7. Сопровождение программной системы (Maintenance): процесс оптимизации и устранения обнаружен-
ных в процессе опытной эксплуатации дефектов функционирования ПС, передача ПС в эксплуатацию.
За рамками приведенного выше списка этапов остались такие пункты как: выбор методологии процесса
разработки ПО и ПС [5–7] (основными парадигмами считаются Agile (Scrum), Waterfall, Rapid application
development (RAD), Test driven development (TDD)), локализация ПС. Эти пункты требуют более детального
рассмотрения и описания, что выходит за рамки данной работы.
Постановка задачи
Разработка формальной модели ПС – это важный и основополагающий этап при проектировании слож-
ной ПС, требующий системного анализа выбора математических структур, наиболее подходящих для модели-
рования заданного набора задач. Разработанная формальная модель должна позволять выполнять:
многокритериальные качественные и количественные оценки работы системы;
оптимизацию алгоритмов функционирования моделей на протяжении всего жизненного цикла систе-
мы, в соответствии с критериями сложности реализации ПС и соответствующих алгоритмов, производительно-
сти, ограничения реального времени получения результата и другие.
mailto:palagin_a@ukr.net
Інтелектуальні інформаційні технології
222
С учетом изложенной выше концепции создания программных систем, необходимо разработать фор-
мальные модели инструментального средства автоматизированного построения онтологий предметных обла-
стей, названного “Инструментальным комплексом онтологического назначения” (ИКОН).
Программная система “Инструментальный комплекс онтологического назначения”
ИКОН является системой, реализующей одно из направлений комплексных технологий Data & Text
Mining, а именно – анализ и обработку больших объемов неструктурированных данных, в частности лингви-
стических корпусов текстов на украинском и/или русском языке, извлечение из них предметных знаний с
последующим их представлением в виде системно-онтологической структуры или онтологии предметной
области (ПдО). ИКОН предназначен для реализации множества компонентов интегрированной информаци-
онной технологии [8].
Современный этап развития и построения программных систем характеризуется существенным
усложнением процесса их разработки. Под программной системой понимается некоторая конечная совокуп-
ность программ, предназначенных для достижения поставленной цели (целей). Функционирование системы
заключается в использовании входящих в нее программ (программных модулей), и может быть выполнено
двумя способами [9]:
однопотоковое выполнение процессов (в каждый момент времени выполняется процедура (оператор)
только в одной из программ, либо выполняется только одна программа (модуль) и все остальные программы
(модули) в этот момент времени приостанавливают свою работу);
многопотоковое (мультипрограммное) выполнение процессов (в каждый момент времени выполняется
процедура (оператор) в каждой программе, либо параллельно выполняются несколько или более программ).
При построении модели ПС следует руководствоваться следующими принципами [10].
1. Модель системы не должна быть чрезмерно детальной (излишняя сложность модели может вызвать
существенные вычислительные проблемы при ее формальном анализе).
2. Модель системы не должна быть чрезмерно упрощенной, она должна отражать те аспекты системы,
которые имеют отношение к проверяемым свойствам, и сохранять все свойства моделируемой системы, пред-
ставляющие интерес для анализа.
С точки зрения программной инженерии программная система рассматривается в виде набора описаний,
представленных в виде математических моделей, формализмов и техник моделирования [11, 12].
Структура математических моделей ПС такого рода включает в себя следующие модели [11, 12]:
1) информационная модель;
2) функционально-компонентная модель.
Опишем каждую из перечисленных моделей.
Информационная модель ПС ИКОН
Информационные модели используются для представления и описания потоков информации, структур
данных, а также программ (модулей) в программной системе.
Обобщенная информационная модель ПС ИКОН представляется некоторой конечной совокупностью
программ (программных модулей) [10–12]:
,
1
n
i
ИКОНi
ИКОН (1)
где ni ,1 ,
n – количество программных модулей входящих в ПС ИКОН,
iИКОН – некоторая программа (модуль) ПС ИКОН.
При этом реализуется отображение
ИКОН
G интеграции функций множества программных модулей
ИКОН в обобщенную (целевую) функцию ИКОН:
,: ИКОНИКОН FSG
ИКОН
(2)
где ИКОНS – множество функций (набор функций) определенного программного модуля ИКОН,
ИКОНF – обобщённая функция ИКОН.
На данном этапе жизненного цикла ПО ПС ИКОН можно представить следующей совокупностью
программных модулей:
}.,,,,,,,{ МПОМБДМУБДЗМИПТИМПТДМВПОСМЛАТДМУГОИКОН (3)
Інтелектуальні інформаційні технології
223
Рассмотрим более детально функциональные характеристики программных модулей ИКОН.
1. МУГО – набор функций программного модуля “Управляющая графическая оболочка”,
,,,,,,)( 654321 SSSSSSS МУГОИКОН (4)
где 1S – осуществляет предварительное наполнение среды внешними электронными коллекциями энциклопе-
дических, толковых словарей и тезаурусов, описывающих домен предметных знаний;
2S – обеспечивает запуск и последовательность исполнения прикладных программ, реализующих состав-
ные информационные технологии проектирования онтологии ПдО и системной интеграции междисциплинар-
ных знаний;
3S – отображает ход процесса проектирования онтологии ПдО;
4S – содержит позиции меню для запуска как последовательностей, так и отдельных прикладных про-
грамм, используемых в процессе проектирования онтологии ПдО;
5S – обеспечивает интерфейс с естественным интеллектом;
6S – обеспечивает обмен информацией между прикладными программами и базами данных.
2. МПТД – набор функций программного модуля поиска текстовых документов,
,,)( 87 SSS МПТДИКОН (5)
где 7S – поиск текстовой информации во внешних источниках;
8S – формирование лингвистического корпуса текстов в библиотеке (базе данных) текстовых документов.
3. МИПТИ – набор функций программного модуля индексации и поиска текстовой информации,
,)( 9 SS МИПТИИКОН (6)
где 9S – создание и манипулирование индексами, по которым возможно найти информацию в соответствую-
щих библиотеках ТД, тезаурусах, онтологиях.
4. МЛАТД – набор функций программного модуля лингвистического анализа текстовых документов,
,,,)( 121110 SSSS МЛАТДИКОН (7)
где 10S – формирование множества терминов;
11S – формирование множества понятий;
12S – формирование множества отношений между понятиями;
5. МПО – набор функций программного модуля построения онтологии ПдО,
,,,,,,,)( 19181716151413 SSSSSSSS МПОИКОН
(8)
где 13S – считывает из модуля визуального проектирования онтологических структур начальную онтологию
ПдО. Из библиотеки ЭК считывает определения понятий, входящих в начальную онтологию, и формирует
множества функций интерпретации;
14S – считывает из соответствующей библиотеки онтографы и формализованные описания онтологий ТД,
проверяет их на непротиворечивость;
15S – анализирует на полноту множества функций интерпретации. Просматривает электронные коллекции
энциклопедических, толковых словарей и тезаурусов и пополняет множества последних для соответствующих
понятий-объектов и понятий-процессов;
16S – в процессе построения онтологии, по необходимости, обращается к любому информационному хра-
нилищу;
17S – выполняет поочередную привязку онтографов и функций интерпретации онтологий ТД;
18S – выполняет привязку общего онтографа ТД и множеств функций интерпретации с онтографом и мно-
жествами функций интерпретации начальной онтологии соответственно;
19S – передает полученный результат в модуль визуального проектирования на верификацию.
6. МВПОС – набор функций программного модуля визуального проектирования онтологических
структур,
Інтелектуальні інформаційні технології
224
,,,)( 222120 SSSS МВПОСИКОН (9)
где 20S – разработка начальной онтологии ПдО;
21S – ручное неавтоматизированное проектирование онтологии ПдО;
22S – верификация онтографа.
7. МУБДЗ – набор функций программного модуля управления библиотеками данных и знаний,
,,)( 2423 SSS МУБДЗИКОН
(10)
где 23S – осуществляет запись, накопление и хранение информации в соответствующих библиотеках;
24S – по запросу менеджера проектов осуществляет чтение из библиотек запрашиваемой информации.
8. МБД – набор функций программного модуля базы данных,
,,,,,,,)( 31302928272625 SSSSSSSS МБДИКОН (11)
где 25S – накопление и хранение онтологий ПдО;
26S – накопление и хранение ТД;
27S – накопление и хранение ЛКТ;
28S – накопление и хранение списков множеств терминов, понятий и отношений;
29S – накопление и хранение проектов ИКОН;
30S – поиск по БД;
31S – работа в режиме клиент-сервер.
Функционально-компонентная модель ПС ИКОН
Функционально-компонентная модель используется для представления взаимодействий, отношений и
зависимостей программных модулей в ПС, а также для подробного описания компонентов системы. Обобщен-
ная функционально-компонентная модель ПС ИКОН может быть представлена в виде:
.),(,,,, 0 StatDynCmpPhysStatDynИКОН ММPММММS
(12)
Рассмотрим более подробно функционально-компонентную модель ПС ИКОН.
1. DynМ – модель, определяющая поведение системы. Рассматривается как UML dynamic model [13–15]:
диаграммы вариантов использования (use case diagram); диаграммы активности (activity diagram), диаграммы
взаимодействий (sequence diagram); Динамическая модель (Dynamic model) описывает поведение системы,
например, изменение программных сущностей (software entities) во время выполнения приложения.
,,, seqactuseDyn dddM (13)
где used – множество UML-диаграмм вариантов использования ПС ИКОН,
actd – множество UML-диаграмм активности ПС ИКОН,
seqd – множество UML-диаграмм взаимодействий ПС ИКОН.
2. StatМ – модель, определяющая структуру системы. Рассматривается как UML static model [13–15]:
диаграммы классов (class diagram) и описание основных модулей системы в виде статических блок-схем.
Статическая модель (Static model) описывает элементы системы и их взаимоотношения (классы, атрибуты,
операторы).
,,, reqbdM StatclassStat (14)
где classd – множество UML-диаграмм классов ПС ИКОН,
Statb – множество статических блок-схем ПС ИКОН,
req – техническое задание на проектирование ПС ИКОН.
3. PhysМ – модель, определяющая структуру программных сущностей. Рассматривается как файлы ис-
ходного кода, библиотеки, исполняемые файлы, и отношения между ними. Физическая модель (Physical model)
[13] отображает неизменяемую структуру программных сущностей, в частности файлов исходного кода, биб-
лиотек, исполняемых файлов, и отношений между ними.
Інтелектуальні інформаційні технології
225
,,, exeflibsrcMPhys (15)
где src – файлы исходного кода,
lib – программные библиотеки,
exef – исполняемые файлы.
4. CmpМ – модель (схема) компонентов ПС, используется для визуализации высокоуровневой струк-
туры системы и поведения служб (сервисов), предоставляемых и потребляемых этими элементами (компонен-
тами) через интерфейсы. Компонент – это модульная единица, заменяемая в пределах среды. Его внутренние
составляющие скрыты, но доступ к функциям компонента можно получить с помощью одного или нескольких
четко определенных предоставленных интерфейсов (provided interfaces). Компонент также может иметь требу-
емые интерфейсы (required interfaces). Требуемый интерфейс определяет, какие функции и службы (сервисы)
он требует от других компонентов. Объединив предоставленные и требуемые интерфейсы нескольких компо-
нентов, можно создать более крупный компонент. Можно сказать, что вся ПС, по сути, представляет собой
компонент [16].
Создание схем компонентов имеет несколько преимуществ.
Анализ основных элементов ПС позволяет команде разработчиков понять принципы существующей
системы и создать новую.
Представление ПС в качестве коллекции компонентов с четко определенными предоставленными и
требуемыми интерфейсами позволяет более эффективно разделить компоненты. В свою очередь, это облегчает
понимание конструкции ПС и ее корректирование при изменении требований.
Использование диаграммы (схемы) компонентов для представления конструкции ПС независимо от
того, какой язык программирования или программная платформа используется сейчас или будет использовать-
ся в будущем.
5. ),(0 StatDyn ММP – предикат целостности системы, определяющий назначение системы, семантику
(смысл) моделей DynМ и StatМ [17];
UML-диаграмма вариантов использования высокого уровня абстракции ПС ИКОН показана на рис. 1.
Суть данной диаграммы состоит в следующем: проектируемая система представляется в виде множества
сущностей или акторов (actor), взаимодействующих с системой с помощью так называемых вариантов исполь-
зования. При этом актором или действующим лицом называется любая сущность, взаимодействующая с систе-
мой извне. Это может быть человек, техническое устройство, программа или любая другая система, которая
может служить источником воздействия на моделируемую систему. В свою очередь, вариант использования
служит для описания сервисов, которые система предоставляет актору.
Инструментальный комплекс
онтологического назначения
Эксперт
ПдО
ИнИТ
автоматизированно
го построения
онтологий
инженер
по
знаниям
Формирование
множества
терминов и понятий
Лингвистический
анализ ТД ПдО
<include>
Поиск текстовых
документов в
сети Internet
Визуальное
пректирование
онтологий
<include>
Поиск с помощью
Google API
<include>
<extend>
Поиск с помощью
WolframAlpha API
Индексация и
поиск текстовой
информации
Визуализация о
проверка онтографа
ПдО (Protege)
<uses>
Поиск с помощью
Bing API
Формирование
множества
отношений
УГО ИКОН
<include>
<include>
<include>
<include>
<include>
<include>
<include>
<include>
Knowledge engine
WolframAlpha
Search engine
Bing
Search engine
Google
Конвертация
файлов описания
онтологий
Управление
библиотеками
ИКОН
<include>
Библиотека
справочной
информации
<extend>
БД Redis
Рис. 1. UML-диаграмма вариантов использования ПС ИКОН.
Інтелектуальні інформаційні технології
226
UML-диаграмма активности высокого уровня абстракции ПС ИКОН показана на рис. 2.
С помощью диаграммы активности (рис. 2) можно изучать поведение системы с использованием моде-
лей потока данных и потока управления. Диаграмма активности отображает некоторый алгоритм, описываю-
щий жизненный цикл объекта, состояния которого могут меняться.
Инициализация
УГО ИКОН
Инициализация
модулей ИКОН
Анализ ТД ПдО
Формирование
множества
терминов
Формирование
множества
отношений между
терминами
Построение
онтологии ПдО
Визуальное
проектирование
онтологии ПдО
[иначе][инициализация]
[сохранить]
[выход]
[нет]
[да]
Наполнение подсистемы
"Информационный
ресурс" (Удалённый
сервер БД Redis)
Наполнение подсистемы
"Информационный
ресурс" (локальный
сервер БД Redis)
Рис. 2. UML-диаграмма активности ПС ИКОН
Физическая модель программных сущностей ПС ИКОН показана на рис. 3.
Представленная модель отображает неизменяемую структуру программных сущностей, в частности фай-
лов исходного кода, библиотек, исполняемых файлов, и отношений между ними.
Instrumental complex for ontological engineering purpose
Downloads
Lib
InCom.jar
Kospekt.dll
Readme.TXT
DJNativeSwing-SWT.jar gson-2.1.jar
DJNativeSwing.jar guava-11.0.1.jar
WolframAlpha-1.1.jar httpclient-4.0.3.jar
beansbinding-1.2.1.jar httpclient-4.1.2.jar
bing-search-java-sdk.jar httpclient-cache-4.1.2.jar
commons-codec-1.4.jar httpcore-4.0.1.jar
httpcore-4.1.2.jar google-ajax-apis.jar
httpmime-4.1.2.jar google-api-client-1.10.3-beta.jar
jackson-core-asl-1.9.4.jar google-api-client-android2-
1.10.3-beta.jar javaFlacEncoder-0.2.3.jar
google-api-client-appengine.jar jdo2-api-2.3-eb.jar
google-api-client-servlet.jar jdom.jar
google-customsearch.jar commons-logging-1.1.1.jar
jedis-2.1.0.jar google-http-client-1.10.3-beta.jar
jna.jar.zip google-http-client-android.jar
jsr305-1.3.9.jar platform.jar.zip
protobuf-java-2.2.0.jar google-oauth-client.jar
swing-layout-1.0.4.jar google-oauth-appengine.jar
swt-3.6M7-win32-win32-x86.jar transaction-api-1.1.jar
gson-1.4.jar
Redis-2.6.9
Рис. 3. Физическая структура программных сущностей ПС ИКОН
UML-диаграмма компонентов высокого уровня абстракции ПС ИКОН представлена на рис. 4, а и б.
UML-диаграмма компонентов используется для визуализации высокоуровневой структуры системы и поведе-
ния служб (сервисов), предоставляемых и потребляемых этими элементами (компонентами) через интерфейсы.
http://www.mql5.com/go?http://ru.wikipedia.org/wiki/%D0%94%D0%B8%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B0_%D0%B4%D0%B5%D1%8F%D1%82%D0%B5%D0%BB%D1%8C%D0%BD%D0%BE%D1%81%D1%82%D0%B8%20%5Co%20http://ru.wikipedia.org/wiki/%D0%94%D0%B8%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B0_%D0%B4%D0%B5%D1%8F%D1%82%D0%B5%D0%BB%D1%8C%D0%BD%D0%BE%D1%81%D1%82%D0%B8%20%5Ct%20_blank
Інтелектуальні інформаційні технології
227
а
Інтелектуальні інформаційні технології
228
б
Р
и
с.
4
.
U
M
L
-д
и
аг
р
ам
м
а
к
о
м
п
о
н
ен
то
в
в
ы
со
к
о
го
у
р
о
в
н
я
а
б
ст
р
ак
ц
и
и
П
С
И
К
О
Н
Інтелектуальні інформаційні технології
229
Трехуровневая архитектура ПС ИКОН
В процессе разработки ПС ИКОН возник ряд проблем, в частности, проблемы масштабируемости, про-
изводительности, безопасности. Для решения вышеуказанных проблем была разработана концепция трёхуров-
невой архитектуры ПС ИКОН.
В терминах программной инженерии трехуровневая архитектура (Multitier architecture) состоит из уровня
представления (Presentation tier), уровня логики (Logic tier), уровня данных (Data tier) и предполагает наличие
следующих компонентов приложения: клиентское приложение (“тонкий клиент” или терминал), подключенное
к серверу приложений, который в свою очередь подключен к серверу базы данных (БД) [18–20].
Клиент – это интерфейсный (обычно графический) компонент, который реализует уровень представле-
ния, собственно приложение для конечного пользователя. Первый уровень не должен иметь прямых связей с
базой данных (по требованиям безопасности), быть нагруженным основной бизнес-логикой [21] (по требовани-
ям масштабируемости) и хранить состояние приложения (по требованиям надежности). На первый уровень мо-
жет быть вынесена и обычно выносится простейшая бизнес-логика: интерфейс авторизации, алгоритмы шиф-
рования, проверка вводимых значений на допустимость и соответствие формату, несложные операции (сорти-
ровка, группировка, подсчет значений) с данными, уже загруженными на терминал.
Сервер приложений реализует уровень логики ПС ИКОН, на котором сосредоточена бо льшая часть биз-
нес-логики (описание функциональных алгоритмов, обрабатывающих обмен информацией между сервером БД
и клиентом). Вне его остаются фрагменты, экспортируемые на терминалы, а также погруженные в третий уро-
вень хранимые процедуры и функции.
Сервер БД обеспечивает хранение данных и реализует третий уровень – уровень данных. Обычно это
стандартная реляционная или объектно-ориентированная система управления базами данных (СУБД). Если
третий уровень представляет собой БД вместе с хранимыми процедурами и схемой, описывающей приложение
в терминах реляционной модели, то второй уровень строится как программный интерфейс, связывающий кли-
ентские компоненты с прикладной логикой (программным модулем) БД.
В простой конфигурации физически сервер приложений может быть совмещен с сервером БД на одном
компьютере, к которому по сети подключается один или несколько терминалов. В “правильной” (с точки зре-
ния безопасности, надежности, масштабируемости) конфигурации сервер БД находится на выделенном компь-
ютере (или кластере), к которому по сети подключены один или несколько серверов приложений, к которым, в
свою очередь, по сети подключаются терминалы (рис. 5).
Клиент 1 Клиент 2 Клиент 3
Сервер
Приложений
(Сервисов)
Сервер
базы
данных
Рис. 5. Пример трехуровневой архитектуры
Основные достоинства трехуровневой архитектуры ПС:
масштабируемость – способность системы справляться с увеличением рабочей нагрузки (увеличивать
свою производительность) при добавлении аппаратных ресурсов;
http://en.wikipedia.org/wiki/Multitier_architecture
http://ru.wikipedia.org/wiki/%D0%A2%D0%BE%D0%BD%D0%BA%D0%B8%D0%B9_%D0%BA%D0%BB%D0%B8%D0%B5%D0%BD%D1%82
http://ru.wikipedia.org/wiki/%D0%93%D1%80%D0%B0%D1%84%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D0%B9_%D0%B8%D0%BD%D1%82%D0%B5%D1%80%D1%84%D0%B5%D0%B9%D1%81_%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D1%82%D0%B5%D0%BB%D1%8F
http://ru.wikipedia.org/wiki/%D0%91%D0%B8%D0%B7%D0%BD%D0%B5%D1%81-%D0%BB%D0%BE%D0%B3%D0%B8%D0%BA%D0%B0
http://ru.wikipedia.org/wiki/%D0%9C%D0%B0%D1%81%D1%88%D1%82%D0%B0%D0%B1%D0%B8%D1%80%D1%83%D0%B5%D0%BC%D0%BE%D1%81%D1%82%D1%8C
http://ru.wikipedia.org/wiki/ASP.NET_state_management
http://ru.wikipedia.org/wiki/%D0%90%D0%B2%D1%82%D0%BE%D1%80%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D1%8F
http://ru.wikipedia.org/wiki/%D0%A0%D0%B5%D0%BB%D1%8F%D1%86%D0%B8%D0%BE%D0%BD%D0%BD%D0%B0%D1%8F_%D0%A1%D0%A3%D0%91%D0%94
http://ru.wikipedia.org/wiki/%D0%9E%D0%B1%D1%8A%D0%B5%D0%BA%D1%82%D0%BD%D0%BE-%D0%BE%D1%80%D0%B8%D0%B5%D0%BD%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D0%B0%D1%8F_%D0%A1%D0%A3%D0%91%D0%94
http://ru.wikipedia.org/wiki/%D0%A1%D0%A3%D0%91%D0%94
http://ru.wikipedia.org/wiki/%D0%A5%D1%80%D0%B0%D0%BD%D0%B8%D0%BC%D0%B0%D1%8F_%D0%BF%D1%80%D0%BE%D1%86%D0%B5%D0%B4%D1%83%D1%80%D0%B0
http://ru.wikipedia.org/wiki/%D0%9A%D0%BB%D0%B0%D1%81%D1%82%D0%B5%D1%80
http://ru.wikipedia.org/wiki/%D0%9C%D0%B0%D1%81%D1%88%D1%82%D0%B0%D0%B1%D0%B8%D1%80%D1%83%D0%B5%D0%BC%D0%BE%D1%81%D1%82%D1%8C
Інтелектуальні інформаційні технології
230
конфигурируемость – изолированность уровней друг от друга позволяет (при правильном разверты-
вании архитектуры) быстро и простыми средствами переконфигурировать систему при возникновении сбоев
или при плановом обслуживании на одном из уровней;
высокие безопасность и надежность;
низкие требования к скорости передачи информации канала (сети) между терминалами и сервером
приложений;
низкие требования к производительности и техническим характеристикам терминалов, как следствие
снижение их стоимости. Терминалом может выступать не только компьютер, но и, например, мобильный теле-
фон.
К недостаткам трехуровневой архитектуры ПС в сравнении с файл-серверной архитектурой следует от-
нести:
более высокая сложность создания приложений;
сложнее в разворачивании и администрировании;
высокие требования к производительности серверов приложений и сервера базы данных, а, значит,
и высокая стоимость серверного оборудования;
высокие требования к скорости канала (сети) между сервером базы данных и серверами приложений.
Рассмотрим реализацию трехуровневой архитектуры ИКОН. На рис. 6 представлена обобщенная струк-
турная схема трехуровневой архитектуры ИКОН.
Уровень представления
(Presentation tier)
Пользовательский интерфейс
(User interface)
Управляющая графическая оболочка ИКОН
Уровень логики
(Logic tier)
Сервисы
(Services)
Процедуры и функции реализующие интегрированную
информационную технологию автоматизированного
построения онтологий предметных областей
Уровень данных
(Data tier)
Сервер БД
БД Redis
Рис. 6. Обобщенная структурная схема трехуровневой архитектуры ИКОН
Інтелектуальні інформаційні технології
231
На уровне представления реализовано клиентское приложение “Управляющая графическая оболочка”.
На уровне логики реализованы процедуры и функции, обеспечивающие функционирование программных мо-
дулей ПС ИКОН и предоставляемых ими сервисов (модуль управления библиотеками; модуль индексации и
поиска текстовой информации; модуль построения онтологии ПдО; модуля поиска текстовых документов; мо-
дуля лингвистического анализа текстовых документов; модуля визуального проектирования онтологических
структур; модуль построения отношений между понятиями). На уровне данных реализован сервер БД Redis,
обеспечивающий хранение данных ИКОН (лингвистического корпуса текстов, цифровой библиотеки справоч-
ной информации, онтологических структур, терминов, понятий, словарей, тезаурусов, текстовых документов).
Уровни архитектуры ПС ИКОН находятся в двусторонней зависимости, которая указывает на то, что один уро-
вень может использовать функции другого уровня и наоборот.
Блок-схема алгоритма работы ПС ИКОН в трехуровневой архитектуре показана на рис. 7.
Data tier
Presentation tier
Logic tier
Presentation tier
Начало
Инициализация клиентского
приложеия УГО
Загрузка
текстового
документа
Отправка текстовго документа на
сервер бизнес логики Logic tier
Лингвистический анализ
текстового документа библиотекой
konspektlib.dll
Отображение результатов
выполнения бизнес логики в
клиентском приложении УГО
Отправка результатов выполнения
бизнес логики клиентскому
приложению УГО
Построение онтологии ПдО
Сохранение данных в БД Redis
Конец
Рис. 7. Алгоритм работы ИКОН в трехуровневой архитектуре
Інтелектуальні інформаційні технології
232
Выводы
В работе предложено обобщённое представление формальной модели программной системы “Инстру-
ментальный комплекс онтологического назначения” автоматизированного построения онтологий предметных
областей. Разработаны и дополнены формальные модели ПС ИКОН, в соответствии с развитием алгоритмов,
процедур, разработки и функционирования программной системы в целом. Спроектирована функционально-
компонентная модель ПС ИКОН, в частности, UML-диаграмма компонентов ПС ИКОН, описывающая взаимо-
действие и отношения программных модулей в системе. Рассмотрена концепция трёхуровневой архитектуры
ПС ИКОН в среде клиент-сервер. Описан полный процесс разработки сложных программных систем. За рам-
ками данной работы остались особенности реализации концепции трёхуровневой архитектуры ПС ИКОН, а
также описание методологии разработки ПО и ПС в целом.
1. Коваль В.Н. Доказательное проектирование. – Киев: Наук. думка, 2001. – 182 с.
2. Соммервилл И. Инженерия программного обеспечения. – 6-е изд. – М.: «Вильямс», 2002. – С. 642.
3. Гринфилд Д., Кит Шорт, Стив Кук, Стюарт Кент, Джон Крупи. Фабрики разработки программ: потоковая сборка типовых прило-
жений =Software Factories: Assembling applications with patterns, models, frameworks and tools. – М.: «Диалектика», 2006. – С. 592.
4. Кривий С.Л. Вступ до методів створення програмних продуктів. Видавничий дім «Букрек», 2012. – 424 с.
5. Кон М. Scrum: гибкая разработка ПО = Succeeding with Agile: Software Development Using Scrum. (Addison-Wesley Signature Series). –
М.: «Вильямс», 2011. – С. 576.
6. Koskela L. Test Driven: TDD and Acceptance TDD for Java Developers // Manning Publications, 2007.
7. McConnell S. Software Estimation: Demystifying the Black Art // Microsoft Press, 2006.
8. Палагин А.В., Крывый С.Л., Петренко Н.Г. Онтологические методы и средства обработки предметных знаний – [монография] – Лу-
ганск: изд-во ВНУ им. В. Даля, 2012. – 323 с.
9. Жуков Д.Ю., Миронов А.М. Математическая модель и методы верификации программных систем // Информационные технологии и
вычислительные системы, 2005, Вып. 1. – С. 49–67.
10. Миронов А.М. Математическая теория программных систем // Материалы к спецкурсу Вычислительная логика. Режим доступа:
http://www.intsys.msu.ru/staff/mironov/mthprogsys.pdf. – Дата доступа: 07.12.2013
11. Broy M. Mathematical Methods in System and Software Engineering // NATO ASI SERIES F COMPUTER AND SYSTEMS SCIENCES. –
SPRINGER VERLAG, German. – 1997. – Vol 158. – P. 271–312.
12. Broy M. Mathematical System Models as a Basis of Software Engineering // LECTURE NOTES IN COMPUTER SCIENCE. – 1995. – ISSUE
1000. – P. 292.
13. Marshall C. Enterprise Modelling with UML // Addison-Wesley, Reading, MA, 2000.
14. Booch G., Rumbaugh J., Jacobson I. The Unified Modeling Language User Guide // Addison-Wesley, Reading, MA, 1999.
15. Quatrani T. Visual Modeling with Rational Rose and UML // Addison-Wesley, Reading, MA, 1998.
16. UML Component Diagrams: Guidelines. Режим доступа: http://msdn.microsoft.com/en-us/library/vstudio/dd409393.aspx. – Дата доступа:
07.12.2013
17. Голышев Л.К. Системный подход к анализу и проектированию сложных систем. Системный проект: научн. моногр. К. : ГП «Инфор-
мационно-аналитическое агентство», 2011. – 555 с.
18. Deployment Patterns (Microsoft Enterprise Architecture, Patterns, and Practices). Режим доступа: http://msdn.microsoft.com/en-
us/library/ff646997.aspx. – Дата доступа: 07.12.2013.
19. Fowler M. Patterns of Enterprise Application Architecture. Addison Wesley, 2003.
20. Eckerson W. Three Tier Client/Server Architecture: Achieving Scalability, Performance, and Efficiency in Client Server Applications // Open
Information Systems 10, 1, January 1995: 3(20).
http://ru.wikipedia.org/w/index.php?title=%D0%92%D0%B8%D0%BB%D1%8C%D1%8F%D0%BC%D1%81_(%D0%B8%D0%B7%D0%B4%D0%B0%D1%82%D0%B5%D0%BB%D1%8C%D1%81%D1%82%D0%B2%D0%BE)&action=edit&redlink=1
http://en.wikipedia.org/wiki/Steve_McConnell
http://www.intsys.msu.ru/staff/mironov/mthprogsys.pdf
http://www.intsys.msu.ru/staff/mironov/mthprogsys.pdf
http://msdn.microsoft.com/en-us/library/vstudio/dd409393.aspx
http://msdn.microsoft.com/en-us/library/ms998478.aspx
http://msdn.microsoft.com/en-us/library/vstudio/dd409393.aspx
http://msdn.microsoft.com/en-us/library/vstudio/dd409393.aspx
|