Файл: Особенности алгоритмизации при разработке WEB-приложений (Особенности проектирования современных информационных).pdf

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

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

Современное Web-приложений представляет собой частный случай открытой информационной системы, поскольку оно обладает свойствами переносимости своих компонент, масштабируемости, интероперабельности, которая поддерживается мировым сообществом и корпорациями на уровне открытых стандартов и спецификаций и реализуется посредством технологий и систем: Web-service, XML-RPC, REST [4] и др.

Кроме того, Web-приложения в общем случае обладают многозвенной архитектурой (Web-сервер, сервер приложений, он-лайн сервисы, функционирующие в рамках внешних систем, клиентские системы, построенные на основе мобильных устройств, ноутбуков, первональных компьютеров), и для реализации каждого звена применяются многочисленные готовые модули, написанные с помощью различных языковых средств и технологий разработки. С ростом проекта, увеличением его сложности и раздробленности, включением тестирование в процесс разработки, растет и проблема сборки и развертывания: необходимо иметь инструмент, позволяющий описать проект структурно, – в терминах физической/логической структуры проекта и взаимосвязи его частей (зависимостей), – а затем описать способы его развертывания.

1.3 Компонентная сборка Web-приложений

По состоянию на 2016 г. наиболее популярными решениями по автоматизации сборки проектов для Java являются Maven, Gradle, AntIvy [6]. Не вдаваясь в подробности реализаций каждого инструмента, а также технических сравнений, принципиально работа этих инструментов сводится к выполнению пользовательских инструкций по преобразованию модулей проекта в архив с заданной структурой, автоматизированное описание и разрешение зависимостей. [6]

Каждый продукт имеет свой метод описания зависимостей: например, для Maven зависимости описываются посредством специальных файлов-конфигураторов, – pom.xml, – в которых зависимости описываются как набор атрибутов: идентификатор группы, идентификатор артефакта, значение версии и тип архива. В конфигураторе также указывается набор репозиториев, в которых система сборки должна будет найти описанные зависимости (модули/микропрограммы). Описание сборки проекта реализуется посредством написания инструкций к системе сборки. Как правило, эти инструкции называют задачами, самыми общими из которых являются сборка и публикация (assemble/publish). Во время сборки автоматизированная система просматривает конфигураторы, и, следуя предоставленным инструкциям, ищет и выкачивает все зависимости, компилирует выходной архив, подставляя скачанные модули в определенном порядке. Под публикацией понимается специфичная подготовка проекта под требования репозитория развертывания и последующее развертывание. В таких системах зависимости воспринимаются, как комплексная ссылка на модуль, точно определяющая необходимую версию и (в некотором смысле) состав модуля. Некоторые сборщики, например, Gradle, в составе IDE IntelliJIDEA, могут дополнительно определять актуальность списка зависимостей, сообщая о появлении в репозиториях более новой версии того или иного модуля. Тем не менее, ни одна из этих систем не обладает возможностью связывания конкретных зависимостей с бизнес-процессами, которые эти модули или микропрограммы реализуют. В лучшем случае, можно получить описание зависимости, предоставленное поставщиком во время публикации проекта, но для таких описаний не существует твердых стандартов, поэтому для целей автоматизации сборки они бесполезны.

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

Тем не менее, с ростом проекта, увеличением его сложности и раздробленности, включением тестирования в процесс разработки, растет и проблема сборки и развертывания, и простого описания компонент уже становится недостаточно, поскольку: увеличивается количество альтернативных компонент, решающих одни и те же задачи, расширяется круг ограничений, что влияет в том числе на межкомпонентные связи. В частности, один из самых больших и наиболее известных репозиториев компонент для Java – Maven Central на момент написания работы имеет в своем архиве более 1 388 600 артефактов (модулей) с учетом версий и более 144 400 – без учета версий. При этом репозиторий классифицирует артефакты используя их именную структуру (URI) и систему тегов, что может быть достаточным для поиска модулей под четко обозначенные области задач (например, модули для работы с SQL содержат соответствующий акроним в названии группы, имени или тега), но не достаточным для решения комплексных задач.

Часто, приступая к работе, разработчик или аналитик не имеют полного представления о способах решения поставленной задачи, и они не имею возможности обратиться сразу непосредственно к репозиторию, где многие решения уже опубликованы, поскольку с отсутствием семантических классификаторов, практически невозможно отследить связь между областью задачи и областью решений без необходимости обращаться к опыту сторонних разработчиков и других поставщиков. [3]

Кроме того, существует огромное множество различных репозиториев (jcenter, github, npm, git-, apache; частных в том числе), предлагающих модули, микропрограммы или полновесные программные решения, и многие из них имеют свои собственные схемы и способы описания компонент.

На примере Web-приложений было установлено, что основным способом компонентной сборки является построение формального списка компонент и сценария генерации структуры Web-приложения. Существует большое количество решений автоматизации сборки проектов, среди которых можно отметить Maven, Gradle, Ant|Ivy. Принципиально работа этих инструментов сводится к выполнению пользовательских инструкций по преобразованию компонент проекта в архив с заданной структурой, автоматизированное описание и разрешение межкомпонентных зависимостей.

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

− простой перечень элементов и связей между ними,

− таблица соединений,

− матрица инцидентности,

− граф связей,

− структурная схема,

− блок-схема,

− эскиз,

− компоновка,

− чертеж.

Известна группа комбинаторно-логических метдов структурного синтеза, которая ориентирована на решение задачи компонентной сборки технических систем. В основе этого подхода лежит хорошо организованные перебор в массиве решений, которые являются аналогами и прототипами.

Выделим следующие особенности комбинаторно-логических методов структурного синтеза:

1. Техническая система или процесс, имеет структуру;

2. Техническая система принадлежит к некоторому классу объектов, имеющих одинаковое функциональное назначение;

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

4. Составные части объектов класса обладают «хорошими комбинаторными способностями».

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

Общая схема сборки выглядит следующим образом:

1. Определить функции, которые приемлемый вариант изделия должен быть способен выполнять.

2. Перечислить на карте широкий спектр частичных решений, т.е. альтернативных средств осуществления каждой функции.

3. Выбрать по одному приемлемому частичному решению для каждой функции». Другие методы компонентной сборки на основе графовых моделей по своей сути являются модификациями рассмотренных выше методов.

Например, использование гиперграфов позволяет подбирать компонентный состав, оперируя не отдельными элементами, а их группами.

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

1. Процесс компонентной сборки Web-приложения включает три основные стадии: а) процессная (уровень обобщенной структуры); б) компонентная (уровень элементов структуры); в) физическая (уровень файлов целевого Web-приложения)

2. Для Web-приложений не может быть построена конечная структура на уровне процессов и компонент, поскольку их множества постоянно варьируются

3. Множество процессов и компонент Web-приложений обладает большой мощностью.

4. Компоненты и их описания доступны на узлах в сети Интернет и могут быть запрошены по сетевому протоколу HTTP

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

Глава 2. Особенности алгоритмизации при разработке WEB-приложени.

2.1 Обобщенный алгоритм компонентной сборки Web-приложений

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

1) выбор процесۤсۤов;

2) выбор компонент;

3) формирование файлового сۤосۤтава Web-приложенияۤ.

Рۤисۤ. 1. Оۤбобщенный алгоритм компонентной сۤборки а) по описۤанию компонентного сۤосۤтава Web-приложенияۤ б) по идентификатору класۤсۤа Web-приложенияۤ в) в усۤловияۤх информۤационной неполноты Еۤсۤли мۤетоду передаетсۤяۤ подмۤножесۤтво процесۤсۤов, то выполняۤетсۤяۤ его итеративное дополнениۤе на осۤнове иۤдеиۤ "наращиۤваниۤяۤ наборов" иۤ выбора асۤсۤоциۤатиۤвных правиۤл сۤ помۤощью мۤодиۤфиۤкациۤиۤ алгориۤтмۤа FPG (Frequent pattern growth, генерациۤяۤ чۤасۤтых шаблонов) сۤ посۤтроениۤемۤ FP-дерева адаптиۤрованного дляۤ работы сۤо сۤтруктурой предложенной сۤемۤантиۤчۤесۤкой сۤетиۤ.

Нۤа каждой иۤтерациۤиۤ формۤиۤруетсۤяۤ мۤножесۤтво рекомۤендуемۤых наборов процесۤсۤов, которые уточۤняۤютсۤяۤ. Вۤведен парамۤетۤр мۤаксۤиۤмۤально возмۤожного набора рекомۤендуемۤых процесۤсۤов n, котۤорый ограниۤчۤиۤваетۤ сۤпиۤсۤок альтۤернатۤиۤвных вариۤантۤов. Вۤ результۤатۤе определяۤетۤсۤяۤ мۤножесۤтۤво сۤемۤантۤиۤчۤесۤкой сۤетۤиۤ S, сۤодержащее опиۤсۤаниۤе целевых процесۤсۤов сۤ иۤерархиۤей вложенносۤтۤиۤ иۤ потۤокамۤиۤ данных. [5]

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