2.3. Основы архитектуры OSS Аргус: инфраструктура, среда, приложения
Несколько другой вариант декомпозиции предложен и использован в технической архитектуре OSS Аргус; уровней здесь определяется меньше по причине большей централизованности OSS-системы [23] (рис. 9).
Рис. 9. Принципы организации структуры компонентов (модулей) OSS АРГУС
18
На диаграмме выделено три слоя:
инфраструктура. Программное обеспечение на данном уровне обеспечивает общее функционирование других модулей, предоставляет единую среду выполнения, подключение дополнительных системных библиотек, общие методы работы с БД, механизмы сокрытия аппаратных особенностей, аутентификацию пользователей, сетевую безопасность, отказоустойчивость, резервирование и другие функции «низкого» уровня (нефункциональные требования);
среда. Здесь определены основные общие или абстрактные предметные сущности, требуемые для работы разных модулей. Это, например, понятия из доменов адресной информации, организационной структуры предприятия; базовые средства по управлению задачами (order management). Также обеспечивается работа основных общих инструментов прикладного уровня (трансляция бизнес-понятий логической модели данных
вфизическую модель хранения и обратно; построение единообразного пользовательского интерфейса и др.) Функциональность данного уровня мало полезна сама по себе, пользовательские требования реализовываются
вуровне приложений (продуктов);
бизнес-приложения, или продукты. Самый верхний уровень. Здесь реализовываются независимые друг от друга программные модули, обеспечивающие тот или иной набор функций. Во время развертывания модули могут отключаться по необходимости, или добавляться, тем самым увеличивая гибкость OSS-системы и расширяя набор возможностей для построения более эффективного процесса эксплуатации сети.
Для каждого из компонентов в каждом слое отдельно определяется, какие из уровней (UI, О, П, И) реализовывает компонент в соответствии с парадигмой «Domain-Driven Design» (Проблемно-ориентированное проектирование) [24], [25]:
• UI, Слой представления.
Отвечает за вывод информации пользователю и интерпретирование его команд. Внешним действующим субъектом может быть не человек, а другая компьютерная система;
• О, Операционный.
Определяет задачи, которые должна решить система, и распределяет их между объектами, отражающими суть предметной области. Задания, выполняемые этим уровнем, имеют смысл для пользователя-специалиста или же необходимы для интерактивного взаимодействия с операционными уровнями других систем. В нем не содержатся ни знания, ни деловые регламенты (business rules), а лишь выполняется координирование задач и распределение работы между совокупностями объектов предметной области на
19
следующем, более низком уровне. В нем не отражается состояние объектов прикладной модели, но он может содержать состояние, информирующее пользователя о степени выполнения задачи;
• П, Предметный.
Отвечает за представление понятий прикладной предметной области, рабочие состояния, деловые регламенты. Именно здесь контролируется и используется текущее состояние прикладной модели. Этот уровень является главной, «алгоритмической» частью программы;
• И, Инфраструктурный.
Обеспечивает непосредственную техническую поддержку для верхних уровней: передачу сообщений на операционном уровне, непрерывность существования объектов на уровне модели, вывод элементов управления на уровне пользовательского интерфейса и т. д. Инфраструктурный уровень может также брать на себя поддержку схемы взаимосвязей между четырьмя уровнями через архитектурную среду приложения.
Одной из архитектурных особенностей OSS Аргус является необходимость одновременной поддержки как клиент-серверной, так и java-web- архитектуры (так называемый «тонкий клиент»). Отчасти это вызвано историей развития программного комплекса: ряд модулей OSS Аргус был разработан и внедрен в период широкого распространения клиент-сервер- ных технологий. Однажды разработанные, внедренные в промышленную эксплуатацию и успешно функционирующие компоненты не требуют замены на «идентичные, но реализованные с помощью других инструментов» – подобная замена затратна с точки зрения бизнеса телекоммуникационного оператора и несет риски ошибок при «повторном» запуске в эксплуатацию. Поэтому, как и в любом другом сложном программном комплексе, имеющем достаточно долгую историю, могут одновременно сосуществовать различные варианты построения модулей ПО.
Данный подход иллюстрирует идеи TNA, дает техническую возможность тесного взаимодействия компонентов, существенно различающихся по своей структуре, позволяет реализовывать интеграции с любыми «сторонними» информационными системами, построенными на основе как клиент-серверной архитектуры, так и любой другой (трехзвенной, java web, REST API и проч.).
Данная особенность (совмещение нескольких разных стеков реализации функций) схематично продемонстрирована на рис. 10.
20
21
Рис. 10. Иллюстрация поддержки нескольких инфраструктур в сложной OSS