Введение

На протяжении нескольких десятилетий задача поиска эффективного повторяемого и предсказуемого процесса или методологии, позволяющей улучшить производительность, качество и надежность разработки программного обеспечения (ПО) и программных систем (ПС) является актуальной. Известны работы, в которых предлагается (на базе методов структурного программирования) технология надежной разработки ПО и ПС, используя при этом тестирование и верификацию программ на основе методов доказательного проектирования [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][6][7] (основными парадигмами считаются Agile (Scrum), Waterfall, Rapid application development (RAD), Test driven development (TDD)), локализация ПС. Эти пункты требуют более детального рассмотрения и описания, что выходит за рамки данной работы.

Постановка задачи

Разработка формальной модели ПС -это важный и основополагающий этап при проектировании сложной ПС, требующий системного анализа выбора математических структур, наиболее подходящих для моделирования заданного набора задач. Разработанная формальная модель должна позволять выполнять:

 многокритериальные качественные и количественные оценки работы системы;

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

С учетом изложенной выше концепции создания программных систем, необходимо разработать формальные модели инструментального средства автоматизированного построения онтологий предметных областей, названного "Инструментальным комплексом онтологического назначения" (ИКОН).

Программная система "Инструментальный комплекс онтологического назначения"

ИКОН является системой, реализующей одно из направлений комплексных технологий Data & Text Mining, а именно -анализ и обработку больших объемов неструктурированных данных, в частности лингвистических корпусов текстов на украинском и/или русском языке, извлечение из них предметных знаний с последующим их представлением в виде системно-онтологической структуры или онтологии предметной области (ПдО). ИКОН предназначен для реализации множества компонентов интегрированной информационной технологии [8].

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

 однопотоковое выполнение процессов (в каждый момент времени выполняется процедура (оператор) только в одной из программ, либо выполняется только одна программа (модуль) и все остальные программы (модули) в этот момент времени приостанавливают свою работу);

 многопотоковое (мультипрограммное) выполнение процессов (в каждый момент времени выполняется процедура (оператор) в каждой программе, либо параллельно выполняются несколько или более программ).

При построении модели ПС следует руководствоваться следующими принципами [10].

1. Модель системы не должна быть чрезмерно детальной (излишняя сложность модели может вызвать существенные вычислительные проблемы при ее формальном анализе).

2. Модель системы не должна быть чрезмерно упрощенной, она должна отражать те аспекты системы, которые имеют отношение к проверяемым свойствам, и сохранять все свойства моделируемой системы, представляющие интерес для анализа.

С точки зрения программной инженерии программная система рассматривается в виде набора описаний, представленных в виде математических моделей, формализмов и техник моделирования [11,12].

Структура математических моделей ПС такого рода включает в себя следующие модели [11,12]: 1) информационная модель;

2) функционально-компонентная модель. Опишем каждую из перечисленных моделей.

Информационная модель ПС ИКОН

Информационные модели используются для представления и описания потоков информации, структур данных, а также программ (модулей) в программной системе.

Обобщенная информационная модель ПС ИКОН представляется некоторой конечной совокупностью программ (программных модулей) [10][11][12]:

, 1     n i ИКОН i ИКОН (1)где n i , 1  , n -количество программных модулей входящих в ПС ИКОН, i ИКОН  -некоторая программа (модуль) ПС ИКОН.

При этом реализуется отображение ИКОН G  интеграции функций множества программных модулей ИКОН в обобщенную (целевую) функцию ИКОН:

, :

ИКОН ИКОН F S G ИКОН  (2)

где ИКОН S -множество функций (набор функций) определенного программного модуля ИКОН, ИКОН F -обобщённая функция ИКОН.

На данном этапе жизненного цикла ПО ПС ИКОН можно представить следующей совокупностью программных модулей:

}. , , , , , , , { МПО МБД МУБДЗ МИПТИ МПТД МВПОС МЛАТД МУГО ИКОН          (3)

Рассмотрим более детально функциональные характеристики программных модулей ИКОН.

Функционально-компонентная модель ПС ИКОН

Функционально-компонентная модель используется для представления взаимодействий, отношений и зависимостей программных модулей в ПС, а также для подробного описания компонентов системы. Обобщенная функционально-компонентная модель ПС ИКОН может быть представлена в виде:

. ) , ( , , , , 0   Stat Dyn Cmp Phys Stat Dyn ИКОН М М P М М М М S (12)

Рассмотрим более подробно функционально-компонентную модель ПС ИКОН.

1.

Dyn М -модель, определяющая поведение системы. Рассматривается как UML dynamic model [13][14][15]:

диаграммы

Трехуровневая архитектура ПС ИКОН

В процессе разработки ПС ИКОН возник ряд проблем, в частности, проблемы масштабируемости, производительности, безопасности. Для решения вышеуказанных проблем была разработана концепция трёхуровневой архитектуры ПС ИКОН.

В терминах программной инженерии трехуровневая архитектура (Multitier architecture) состоит из уровня представления (Presentation tier), уровня логики (Logic tier), уровня данных (Data tier) и предполагает наличие следующих компонентов приложения: клиентское приложение ("тонкий клиент" или терминал), подключенное к серверу приложений, который в свою очередь подключен к серверу базы данных (БД) [18][19][20].

Клиент -это интерфейсный (обычно графический) компонент, который реализует уровень представления, собственно приложение для конечного пользователя. Первый уровень не должен иметь прямых связей с базой данных (по требованиям безопасности), быть нагруженным основной бизнес-логикой [21] (по требованиям масштабируемости) и хранить состояние приложения (по требованиям надежности). На первый уровень может быть вынесена и обычно выносится простейшая бизнес-логика: интерфейс авторизации, алгоритмы шифрования, проверка вводимых значений на допустимость и соответствие формату, несложные операции (сортировка, группировка, подсчет значений) с данными, уже загруженными на терминал.

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

Сервер БД обеспечивает хранение данных и реализует третий уровень -уровень данных. Обычно это стандартная реляционная или объектно-ориентированная система управления базами данных (СУБД). Если третий уровень представляет собой БД вместе с хранимыми процедурами и схемой, описывающей приложение в терминах реляционной модели, то второй уровень строится как программный интерфейс, связывающий клиентские компоненты с прикладной логикой (программным модулем) БД.

В простой конфигурации физически сервер приложений может быть совмещен с сервером БД на одном компьютере, к которому по сети подключается один или несколько терминалов. В "правильной" (с точки зрения безопасности, надежности, масштабируемости) конфигурации сервер БД находится на выделенном компьютере (или кластере), к которому по сети подключены один или несколько серверов приложений, к которым, в свою очередь, по сети подключаются терминалы (рис. 5).

Выводы

В работе предложено обобщённое представление формальной модели программной системы "Инструментальный комплекс онтологического назначения" автоматизированного построения онтологий предметных областей. Разработаны и дополнены формальные модели ПС ИКОН, в соответствии с развитием алгоритмов, процедур, разработки и функционирования программной системы в целом. Спроектирована функционально-компонентная модель ПС ИКОН, в частности, UML-диаграмма компонентов ПС ИКОН, описывающая взаимодействие и отношения программных модулей в системе. Рассмотрена концепция трёхуровневой архитектуры ПС ИКОН в среде клиент-сервер. Описан полный процесс разработки сложных программных систем. За рамками данной работы остались особенности реализации концепции трёхуровневой архитектуры ПС ИКОН, а также описание методологии разработки ПО и ПС в целом.