Содержание к диссертации
Введение
ГЛАВА 1. Аналитический обзор методов и алгоритмов компонентной сборки информационных систем 11
1.1. Особенности проектирования современных информационных 11
систем 11
1.2. Подходы к разработке информационных систем 18
1.2.1. Эволюция технологии программирования 18
1.2.2 Концепция открытых систем 20
1.2.3 Прикладные модели открытых информационных систем 28
1.3 Компонентная сборка Web-приложений 31
1.4. Выводы по главе 1 38
ГЛАВА 2. Семантическая модель процессов и компонент web-приложения 40
2.1 Семантическая модель стандартизированного профиля информационной системы 40
2.2. Информационные преобразования процесса компонентной сборки Web-приложений 61
2.3 Моделирование компонентной сборки Web-приложений на основе семантической сети 63
2.4 Выводы по главе 2 70
ГЛАВА 3. Алгоритмы компонентной сборки web приложения . 72
3.1 Обобщенный алгоритм компонентной сборки Web-приложений 72
3.2 Алгоритмы подбора процессов и компонент Web-приложений 74
3.3 Алгоритмы обработки стандартизированного профиля Web-приложения 76
3.4 Стандартизированный профиль системы компонентной сборки Web-приложений 84
3.5 Выводы по главе 3 91
ГЛАВА 4. Практическая реализация и эксперимент 93
4.1 Архитектура платформы компонентной сборки Web-приложений 93
4.2 Экспериментальная проверка работы систем логического вывода базы знаний по стандартизированным профилям 102
4.3 Экспериментальная проверка механизма интеграции документов 106
4.4 Выводы по главе 4 114
Заключение 117
Список литературы
- Эволюция технологии программирования
- Моделирование компонентной сборки Web-приложений на основе семантической сети
- Алгоритмы подбора процессов и компонент Web-приложений
- Экспериментальная проверка работы систем логического вывода базы знаний по стандартизированным профилям
Введение к работе
Актуальность исследования.
Общепризнанно, что информационная инфраструктура любого уровня должна основываться на принципах обеспечения совместимости и способности к взаимодействию входящих в информационную среду компонент (интероперабельности), а также на стандартах и технологии открытых систем, проблемы развития которых, согласно решению государственной академии наук, включены в программу фундаментальных исследований России на 2013-2020 гг.
С различных позиций вопросы обеспечения открытости изучались отечественными и зарубежными учеными, среди которых Ю.В. Гуляев, А.Я. Олейников, В.А. Сухомлин, В.К. Батоврин, А.В. Бойченко, М. Ю. Брауде-Золотарев, Е.Е. Журавлев, А.С. Королев, K. Blind, G. Booch, CoreyD. Schou, K. Jakobs, и другие.
С позиций открытых информационных систем исследуются современные Web-приложения, которые собираются из компонент и выполняются в гетерогенной среде глобальных вычислительных сетей.
В настоящее время ведутся активные исследования в области структурного синтеза информационных систем, и, в частности, это касается вопросов компонентной сборки Web-приложений. Известные подходы и реализующие их средства, такие как Ant, Maven, Gradle и другие решают эту задачу "в лоб", запрашивая у пользователя формализованные списки с описанием компонент, на основании которых осуществляется их поиск и генерация файлового состава Web-приложения. При этом вопросами подбора компонент под конкретные задачи занимается сам разработчик, что приводит зачастую к большим временным затратам и многочисленным ошибкам из-за которых часто возникает необходимость изменения состава Web-приложений даже поздних стадиях его разработки.
Таким образом, процесс компонентной сборки Web-приложений является актуальной задачей, требующей развития семантических моделей, а также информационно-поисковых алгоритмов.
Цель и задачи диссертационной работы.
Разработка семантической модели процессов и компонент Web-приложения и основанных на ней информационно-поисковых алгоритмов компонентной сборки, позволяющие снизить временные затраты и сократить число ошибок на этапе структурного синтеза Web-приложения.
Для достижения поставленной цели были решены следующие задачи: аналитический обзор публикаций по теме исследования;
разработка семантической модели процессов и реализующих их программных компонент;
разработка обобщенного алгоритма компонентной сборки Web-приложения;
разработка информационно-поисковых алгоритмов подбора процессов и компонент;
программная реализация разработанных алгоритмов компонентной сборкиWeb-приложения;
Объектом исследований являются Web-приложения. Предметом исследований являются методы и алгоритмы компонентной
сборки Web-приложений.
Методы исследования. Методическая и теоретическая часть работы основаны на использовании теории системного анализа, классической теории множеств, дескрипционной логики, теории графов, теории алгоритмов, аппарата семантических сетей к описанию предметной области. Используются технология открытых систем, методы функционального моделирования IDEF0.
Достоверность и обоснованность результатов определяется использованием математического аппарата и обеспечивается экспериментальной проверкой.
По итогам диссертационного исследования получены следующие результаты, обладающие научной новизной и являющиеся предметом защиты:
-
Предложена семантическая модель структуры Web-приложения, отличающаяся формализацией как индивидуальных, так и системных свойств процессов и компонентов, позволяющая построить обобщенный алгоритм управления компонентной сборкой (Соответствует области исследования 3 паспорта специальности).
-
На основе предложенной модели разработан обобщенный алгоритм компонентной сборки Web-приложений, отличающийся тем, что позволяет восстанавливать наборы процессов и компонент по их частичному описанию (Соответствует области исследования 4 паспорта специальности).
-
Создан алгоритмический комплекс компонентной сборки Web-приложений, отличающийся возможностью построения альтернативных и расширенных наборов процессов и компонент Web-приложений, что позволяет сократить число ошибок при формировании компонентной структуры Web-приложения (Соответствует области исследования 5 паспорта специальности).
Основные положения, выносимые на защиту:
1. Семантическая модель структуры Web-приложения с описанием индивидуальных так и системных свойств ее процессов и компонентов.
-
Обобщенный алгоритм компонентной сборки Web-приложений, позволяющий восстанавливать наборы процессов и компонент по их частичному описанию.
-
Алгоритмы построения альтернативных и расширенных наборов процессов и компонент Web-приложений.
Практическая значимость результатов диссертационной работы. Результаты работы могут быть использованы при проектировании открытых информационных систем. На основе разработанных модели и алгоритмов построены инженерные решения, которые рекомендованы к применению при проектировании, реализации и сопровождения Web-приложений, а также при создании интегрированных решений на основе различных программных компонент. Создана технология формирования облачных баз знаний поддержки генерации стандартизированных профилей Web-приложений.
Реализация и внедрение работы. Теоретические и прикладные результаты диссертационной работы внедрены:
-
В ООО «МФИ Софт» г. Нижний Новгород при разработке стандартизированных профилей межкомпонентных и межсистемных интерфейсов программного обеспечения, выпускаемого компанией ООО «МФИ Софт».
-
В учебном процессе ФГБОУ ВО Нижегородского государственного технического университета им. Р.Е. Алексеева при проведении курсов «Открытые информационные системы», «Технологии разработки программного обеспечения» при подготовке магистров по направлению «Информатика и вычислительная техника».
Апробация результатов работы. Основные положения и результаты диссертационной работы докладывались и обсуждались на следующих научно-технических семинарах и конференциях: «Компьютерное моделирование» (между-нар., науч.-техн. конф. г. Санкт-Петербург, 2009) «Имитационное моделирование. Теория и практика. ИММОД-2009» (всеросс. конф. г. Санкт-Петербург, 2009), «Перспективы развития информационных технологий» (III междунар. науч.-практ. конф., Новосибирск, 2011), «Информационные системы и технологии» (XIX междунар. науч.-техн. конф., Нижний Новгород, 2013, 2014), «Системный анализ в проектировании и управлении» (XX Международная научно-практическая конференция, Санкт-Петербург, Ростов-на-Дону, 2016).
Публикации. Основное содержание диссертационной работы отражено в 11 печатных работах; 4 представлены в научных изданиях, рекомендуемых ВАК Министерства образования и науки РФ; 5 работ в сборниках трудов международных
конференций, 1 свидетельство о регистрации программы для ЭВМ и 1 работа в издании РИНЦ.
Свидетельства о регистрации программ для ЭВМ. 1. Аристов А.В., Жев-нерчук Д.В., Чепкасов В.Л., Свидетельство о государственной регистрации программы для ЭВМ № 2014615446 от 27.05.2014 " Открытая система поддержки диалоговых сервисов в Web" 2014
Структура и объем работы. Диссертация изложена на 138-и страницах машинописного текста (179 с. с приложениями). Работа иллюстрирована 36-ю рисунками (39 с учетом приложений), 10-ю таблицами (13-ю с учетом приложений), содержит 4 приложения. Библиография включает 65 отечественных, 51 иностранных источников, 13 нормативных и иных документов.
Эволюция технологии программирования
Существует множество определений автоматизированной информационной системы (АИС). В широком смысле АИС представляет собой взаимосвязанную совокупность средств, методов и персонала, используемых для хранения, обработки и выдачи информации в интересах достижения поставленной цели.
Автоматизированная информационная система представляет собой подмножество более общего класса автоматизированных систем, состав которых определяется совокупностью обеспечений: - техническое обеспечение – устройства вычислительной техники, средства и каналы передачи данных, составляющие аппаратную часть вычислительной системы, устройства оргтехники, сервисные и другие устройства и их сочетания. - математическое обеспечение – методы, математические модели, алгоритмы, на базе которых построен процесс функционирования системы обработки информации; - программное обеспечение – программы на машинных носителях, исходные тексты, эксплуатационная документация информационное обеспечение – совокупность входных, выходных и промежуточных данных и сведений, необходимых для функционирования системы обработки информации, организованных, как правило, в виде баз данных и систем управления ими; лингвистическое обеспечение – терминология, языки, сопровождающие цикл обработки информации в автоматизированной системе методическое обеспечение – совокупность документов, устанавливающих состав и правила отбора и эксплуатации средств системы обработки информации организационное обеспечение – совокупность документов, устанавливающих функции и структуру подразделений организации-пользователя автоматизированной системы, имеющих отношение к системе обработки информации, а также регламентирующих их взаимодействие с вычислительной системой.
В документе [89] под АИС понимается система обработки информации и соответствующие организационные ресурсы (человеческие, технические, финансовые и т. д.), которые обеспечивают и распространяют информацию. Многочисленные области приложения ИС, средства и технологии проектирования и разработки явились предпосылками для создания и развития систем классификации и классификационных признаков: однопользовательские, групповые и корпоративные (по масштабу), файл-сервер, клиент-сервер с толстым и тонким клиентом, многозвенные (по архитектуре) и т.д. [90].
Известны эффективные методики, концепции, технологии, подходы к управлению развитием ИС в контексте определенных направлений деятельности и сфер приложения, нашедшие своё эффективное применение в раз личных задачах у нас в стране и по всему миру. Некоторые из них приобрели статус международных, государственных, корпоративных стандартов. Ниже перечислены некоторые, наиболее важные, технологии и стандарты, применяемые при разработке ИС: MRP (Material Requirements Planning) – планирование поставок материалов, исходя из данных о комплектации производимой продукции и плана продаж. CRP (Capacity Requirements Planning) – планирование производственных мощностей, исходя из данных о технологии производимой продукции и прогноза спроса. MRPII (Manufacture Resource Planning) – планирование материальных, мощностных и финансовых ресурсов, необходимых для производства. Стандартизовано ISO. ERP (Enterprise Resource Planning) – финансово-ориентированное планирование ресурсов предприятия, необходимых для получения, изготовления, отгрузки и учёта заказов потребителей на основе интеграции всех отделов и подразделений компании. SCM (Supple Chain Management) – управление цепочками поставок. Реализация бизнес-процессов на базе внешних предприятий и торговых площадок. Основано на референтной модели SCOR, стандартизованной Supply Chain Council. CRM (Customer Relationship Management) – управление взаимоотношениями с заказчиками. Комплекс методов и средств, нацеленный на завоевание, удовлетворение требований и сохранение платежеспособных клиентов. ERPII (Enterprise Resource and Relationship Processing) – управление ресурсами и взаимоотношениями предприятия. Объединяет в себе 3 вышеперечисленные технологии. Workflow – технология, управляющая потоком работ при помощи программного обеспечения, способного интерпретировать описание процесса, взаимодействовать с его участниками и при необходимости вызывать соответствующие программные приложения. - OLAP (Online Analytical Processing) – оперативный анализ данных. Технология поддержки принятия управленческих решений на основе концепции многомерных кубов информации. - Project Management – управление проектами. Поддерживается рядом международных стандартов. - CALS (Continuous Acquisition and Lifecycle Support) – непрерывная информационная поддержка поставок и жизненного цикла. Описывает совокупность принципов и технологий информационной поддержки жизненного цикла продукции на всех его стадиях. Объединяет в себе практически все вышеперечисленные подходы и технологии. Для анализа сильных и слабых сторон существующих подходов, методов и инструментов проектирования и реализации информационных систем необходимо выделить систему требований к ним. Известны определения понятия термина "Требование". В работе [45] приводится такая формулировка: «Требование – это условие или возможность, которой должна соответствовать система». В IEEE Standard Glossary of Software Engineering Terminology (1990) данное понятие трактуется шире.
Моделирование компонентной сборки Web-приложений на основе семантической сети
Система SF выполняет формализацию входного воздействия, т.е. строит отображения вида Д: С - Cf, С- C f,f2\P - Р/; Р - P f, f3:Q Qf, Q Q f, причем результаты отображений Д,/2 поступают в систему SSN и далее отображаются на единую структуру данных о процессах и компонентах. Система SM принимает на вход результаты отображения f3 и сведения о компонентах и процессах из SSN, и формирует процессный и компонентный состав М целевого Web-приложения. Множество информационных преобразований можно описать следующей композицией: c,p,q -» Чу(/і(с),/2(р)),/з( 7)) Представлена общая схема автоматизированной системы компонентной сборкой, в которой существо систем SF, SSN, SM раскрывается через подсистемы первичного анализа и форматирования данных, подсистемы управления хранилищем данных о процессах и компонентах, а также подсистем, формирующих компонентный состав М Web-приложения (рис. 2.6). Рис 2.6 – Общая схема автоматизированной системы компонентной сборкой Web-приложений
По результатам аналитического обзора, выполненного в первой главе, были сформулированы следующие предположения:
1. Web-приложение описывается на трех уровнях: а) логический (описание на уровне обобщенных, декомпозируемых процессов); б) компонентный (описание на уровне библиотек и сервисов, которые реализуют процессы логического уровня); в) физический уровень (описание размещения компонент в структуре проекта Web-приложения).
2. Процесс компонентной сборки Web-приложения включает три основные стадии, связанные с уровнями представления: а) процессная (формирование графа процессов, которые определяют функциональные особенности целевого Web-приложения); б) компонентная (формирование списка целевых компонент с их зависимостями, которые в совокупности реализуют процессы логического уровня); в) структурная (формирование плана импорта компонент и их размещения в структуре проекта Web-приложения).
3. Подбор процессов осуществляется итерационно, на каждом шаге формируется множество альтернативных наборов процессов-кандидатов на включение в целевую структуру Web-приложения на логическом уровне.
4. Компоненты разделяются на внутренние (библиотеки, классы) и внешние (on-line сервисы). Внутренние компоненты включаются в структуру Web-приложения, внешние компоненты используются в режиме удаленного доступа посредством компонентов сопряжения.
5. Интероперабельность компонент определяется множеством поддерживаемых ими интерфейсов. Предложена семантическая модель, которая описывает: а) индивидуальные свойства процессов и компонент Web-приложений; б) иерархии процессов ("целое"-"часть"); в) комбинации процессов, которые были успешно применены при разработке Web-приложений; г) компоненты, реализующие процессы и взаимодействующие друг с другом посредством множества интерфейсов.
Пусть Р = {рг, ...,рт} множество процессов, описанных в семантической сети S. Т = {тг, ...,тп\ті Q Р], \Т\ = п - множество наборов процессов, описывающих Web-приложения, Р1 = [р{, —,Ph} - подмножество процессов, которое, в общем случае, частично описывает целевое і-е Web приложение. Под (о(Р;) = L обозначим характеристику поддержки (support) подмножества процессов Pt. Введем - значение минимальной поддержки, считаем, что если (р(Р{) , то набор процессов Pt является частым и может быть использован для восстановления процессов по входящим запросам. На основании множества частых наборов процессов строятся ассоциативные правила вида а -»/? , где а, /? Є Pt -непересекающиеся подмножества процессов, входящие в частый набор Р1: Ц){а U /?) . Причем для значимости правила а -»/? выполняется: (p(a\j3) = о, где о — минимальная величина значимости. Для хранения информации о наборах процессов используется префиксное дерево (FP-дерево), позволяющее строить алгоритмы поиска ассоциативных правил, обладающие высокой скоростью выполнения. На рис. 2.7-2.8 показаны фрагменты семантической модели процессов и компонент Web-приложения. В таблицах 2.4 - 2.5 приведена расшифровка описанных процессов и компонент
Алгоритмы подбора процессов и компонент Web-приложений
Под контроллерами (Controller) обычно понимаются сгруппированные по какому-то бизнес-признаку методы, где каждый метод связан («замаплен») с релятивной частью URL основного домена, а также типом HTTP-запроса (что вместе называется просто роутингом), переходя по которым, или вызывая которые средствами ajax, клиентское приложение дает серверу и фреймворку понять какой конкретно метод должен быть проинициализирован.
Общение сервера и клиента происходит исключительно через контроллеры, а сами роутинги можно понимать, как API серверного приложения (сервиса), которым могут воспользоваться другие приложения/сервисы при условии наличия доступа.
Поскольку именно методы контроллеров принимают данные, для них существую специальные механизмы сериализации/десериализации. Например, в Spring при помощипакета Jackson данные из HTTP-запроса могут быть десериализованы в POJO-модель (или просто строку или объект) или, наоборот, в HTTP-ответе сериализованы обратно в JSON-строку. Для корректной сериализации данные в JSON должны структурно соответствовать объекту (модели), в который эти данные переносятся (на уровне коллекций ключей).
Кроме контроллеров важное место в MVC-архитектуре занимают модели (Model). Модели обычно агрегируют в себя структурное описание бизнес-модели или процесса и включают соответствующую специфичную логику, которая выполнима только в рамках этой модели. Например, конвертация данных в другой формат, какой-то рефлексирующий отчет и т.п.
Чаще всего, если однообразных моделей много, то общая для них функциональность, либо выносится в абстрактную родительскую модель, либо в специальный сервис (если для выполнения функционала требуются какие-то внешние вызовы, взаимодействие со сторонними библиотеками и т.п.). Существуют также такие виды моделей, как DTO (Datatransferobject), которые являются одновременно паттерном разработки и могут встречаться в различных сервисно-ориентированных архитектурах. DTO не содержит методов и является моделью без логики, которая нужна только для переноса данных между сервисами. DAO (Dataaccessobject) – еще один вид моделей и паттерн программирования, которая определяет абстрактный интерфейс для доступа к данным из определенной БД.
За контроллерами и моделями лежат представления (View). Представлениями могут быть, как обычные html-файлы, так и специальные файлы шаблоны (ejs, jsp), которые, позволяют автоматизировать построение html разметки с помощью встраивания серверного когда в специальные мета-элементы. Такие шаблоны, перед отправкой на клиент будут перекомпилированы сервером (фреймворком) в статичный html. Представления, в данной архитектуре, принято отдавать клиенту через методы контроллеров. Именно в представления встраиваются все прочие статичные элементы: css, js, картинки, видео и т.п.
Как было описано выше, на уровне функционального расширения применяется платформа NodeJS, фреймворк которой на текущий момент не является строгим и не специфицирован на уровне архитектуры программных систем. В рамках Model manager было принято решение строить приложение по тому же паттерну MVC, как наиболее подходящему для сервисно-ориентированных задач.
NodeJS express включает модули фреймворка, модули приложения, представления и публичные (статичные) ресурсы. В отличии от Spring-MVC NodeJS express не оперирует понятиями контроллер/модель: вместо этого есть просто роутинги, которые можно привязать к любой функции любого модуля.
Структура серверного приложения состоит из модуля ядра app.js, который конфигурирует сервер общего назначения и обозначает роутинги для модулей приложения для API 1го уровня (Рис. 4.7). Под API 1го уровня понимается API основного модуля Model manager – manager.js (инжектор на рисунке), который занимается транслированием клиентской части менеджера приложений на клиент, а также вопросами загрузки архивов моделей-приложений, их распаковкой и подключением их, как модулей внутрь проекта, определением их роутингов, который являются частью API 2го уровня.
Manager.js также имеет метод сканирования структуры проекта на предмет подключенных моделей-приложений. Таким образом, API 2го уровня не доступно до тех пор, пока manager.js не просканирует проект и не определит каждой модели свой собственный роутинг, - дальше можно переходить к любой подключенной модели.
Экспериментальная проверка работы систем логического вывода базы знаний по стандартизированным профилям
Для проведения серии экспериментов применялся генератор семантических сетей процессов, компонент и запрашиваемых наборов процессов. Таким образом, все обозначения процессов и компонент приводятся условно.
Каждому процессу Pi, представленному в дереве соответсвует компонент Cpi. Компоненты Cp1 и Cp13 поддерживают интерфейс I: hasOutputInterface для Cp1, hasInputInterface для Cp13. Таким образом, при корректной работе алгоритмов и продукционных правил, в модель закладывается интероперабельность компонент Cp1и Cp13посредством интерфейса I. Для данной модели была собрана матрица транзакций 100x10: p1p2p13, p1p2p15, p1p16, p2p13p15…Матрица сложена с предположением сочетания p1, p2 со всеми процессами p9. Т.е. считается, что для набора (p1,p2) должны будут предлагаться рекомендательные наборы, включающие процесс p9 со всеми вариациями дочерних процессов.Таким образом имитируется связность процессов p1,p2 с p9. Для 100x10x0.2 для p1p2 получили рекомендации: p9, p12p13, p15p16, p15, p13p16p15, p13p16. P17 не попал в рекомендации из-за малой индивидуальной поддержки в обучающем наборе. По компонентам: с1с2 + [c9, c12c13, c15c16, c15, c13c16c15, c13c16, … + комбинации со вложенными]. По компонентам с учетом ограничения на интероперабельность:c1 + [с13]. В табл. 4.3 приведены результаты эксперимента. Указана зависимость количества неправильных наборов для тестовой выборки от значения выбранной минимальной поддержки minSupport (элемент алгоритма FPG). Количество неправильных наборов проверяется экспертом (по экспертной выборке).
По факту определения количества неправильных наборов можно установить диапазон оптимального значения minSupport для текущей (генеральной) выборки. Некоторое небольшое количество неправильных наборов приветствуется, поскольку может свидетельствовать о наличии классов web-приложений, набор процессов которых не учитывался экспертом (не был формализован в экспертной выборке).
В текущем примере оптимальное значение minSupport находится в диапазоне (0.18 , 0. 20). В приложении В приводится фрагмент сгенерированого целевого файла с компонентными зависимостями для системы сборки проектовс программных систем MAVEN.
Проведен комплекс тестов, связанных с проверкой интероперабельности, специфика которых заключается в экспериментальной проверке совместимости компонент платформы на техническом, семантическом и организационном уровне: 1. Проверка возможности использования браузерных клиентов (техническая интероперабельность с клиентскими платформами) 2. Проверка расширяемости по новым моделям (семантическая интероперабельность с GENERIC-структурами) 3. Проверка возможности взаимодействия с узлами в сети Интернет, на которых расположены электронные версии нормативных документов (техническая интероперабельность с платформами хранения электронных документов) 4. Проверка возможности использовать несколько узлов как единую полнотекстовую базу данных (семантическая интероперабельность с платформами хранения электронных документов) 5. Проверка возможности организации системы формирования профиля как SaaS (организационная интероперабельность). Были получены следующие результаты: 1. Платформа обеспечивает интероперабельность с клиентскими системами на основе браузеров Google Chrome, Firefox, Internet Explorer. 2. Платформа расширяема по новым семантическим моделям, реализованным стандартными POJO и спецификацией OWL-DL. 3. Точка доступа Fuseki 2 позволяет обрабатывать Web-онтологии, расположенные на произвольных узлах сети Интернет и обладающих уникальными адресами. 4. Для обработки спецификаций, расположенных на различных узлах сети Интернет, они должны быть преобразованы в соответствии со спецификациями HTML5 или PDF с поддержкой. Было подготовлено порядка 50 моделей с описанием стандартизированных профилей, структура которых представлена в формате OWL-DL, доступ к которым осуществляется через 2 SPARQL точки. Спецификации, входящие в тестовые профили, расположены на серверах IETF, W3C, находятся в открытом доступе в форматах pdf и html с разметкой. По результатам тестовой проверки было сгенерировано 100% профилей. 5. Взаимодействие со всей совокупностью электронных файлов осуществляется как с единой базой данных, в единой системе идентификаторов и семантике, определяемой Web-онтологиями. 6. Доступ к электронным файлам настраивается на основе спецификации java spring security, поэтому все документы обрабатываются в режиме приложение как сервис SaaS, что позволяет автоматизировать процедуру согласования лицензионных соглашений об использовании. 7. Масштабируемость определяется сервис-ориентированной архитектурой платформы в контексте Java Spring MVC и может выступать в качестве базовой единицы более крупных систем. В четвертой главе описана реализация тестовой автоматизированной системы компонентной сборки Web-приложений, изложены результаты экспериментальной проверки построенных моделей и алгоритмов. На основе профиля, предложенного в главе 3, была построена трехуровневая модель общей архитектуры, включающая ядро, уровень базовых операций и уровень функционального расширения, а также операционная среда, обеспечивающая интероперабельность компонент платформы формирования стандартизированных профилей. Предложенная прикладная модель архитектуры платформы, базирующаяся на трехуровневой модели архитектуры, выполнена: 1. Уровень ядра: MVC-система в контексте Java-Spring, включающая слой Jena и сервера Tomcat 8, Fuseki 2 . 2. Уровень базовых операций: совокупность контроллеров, моделей, представлений, а также интерфейса прикладного программирования, обеспечивающих развертывание распределенной операционной среды корпоративного уровня и взаимодействие с RDF сервером для выполнения CRUD-операций с Web-онтологиями. 3. Уровень функционального расширения: блок управления моделями Model manager реализованный на платформе NodeJS, которая работает с интерпретируемым языком javascript, и движком GoogleV8. Слой функционального расширения позволяет менять структуру моделей на уровне предметных областей и добавлять ее поддержку механизмами уровня базовых операций. Блок управления моделями Model manager может также выступать в качестве платформы прототипиирования приложений.