Анализ функционирования
Проектировщик РИС безусловно нуждается в возможности прогнозировать эксплуатационные характеристики и производительность независимо создаваемых компонентов, доступных на уровне проекта, но без их использования в приложении. Прогресс в решении этой задачи обычно достигается ценой сокращения усилий на прототипирование, например, благодаря автоматизированной генерации систем тестов. Тестирование прототипа придает очевидность пригодности проектируемой архитектуры приложения, но оно неэффективно при прогнозировании производительности.
Производительность зависит от следующих факторов:
- поведение компонентов и их взаимодействие,
- частности реализации компонентной инфраструктуры,
- выбор конфигурационных установок,
- установка аттрибутов как для компонентов приложения, так и для компонентов инфраструктуры,
- одновременная загрузка запросов.
Это вынуждает повышать производительность ИК поиском определенной топологии соединений компонентов, обеспечением устойчивости сообщений и контролем потоков данных, что приводит к специальной компонентной технологии, дающей уверенность в достаточной надежности прогноза, более оперативного, чем прототипирование с тестированием.
Чтобы преодолеть усложненность анализа критических свойств РИС, нужен новый подход в контексте композируемости и повторного использования компонентного анализа при конструировании систем из компонентов. Такие свойства для систем должны выводиться из свойств подсистем или компонентов. Нужен механизм описания поведения компонентов при отказах по отношению ко всем возможным обстановкам.
Основная идея анализа поведения РИС - вся система однородна и исходный текст ее компонентов доступен для анализа. Это не соответсвует практике применения и создания компонентов по ряду причин:
- некоторые компоненты доступны лишь в виде двоичного кода;
- результаты анализа компонентов представляют интерес, даже если целой программы еще не существует;
- с точки зрения расхода времени и ресурсов многократно повторяемый анализ всех компонентов программы не всегда обоснован, (например, анализ библиотечных модулей, присоединяемых к программе);
- рассмотрение программы как единой однородной сущности означает, что изменение любого компонента требует полного повторного анализа всей программы;
- чтобы достичь практичного времени анализа, он должен использовать аппроксимации, которые обычно редуцируют точность и полезность/выполнимость анализируемых решений.
Необходим альтернативный подход - анализ на уровне компонентов, при котором на входе вместо исходного текста завершенной программы анализируется исходный код отдельных компонентов, дополненный некоторой информацией о контексте применения этих компонентов. Такая дополнительная обобщенная информация об остальных, возможно недоступных и даже еще не существующих, компонентах выполняют роль консервирующих допущений, что позволяет ввести меру консервативности частичного определения ИС. Далее ставится задача, обойти ограничения полнопрограммного анализа:
- анализ без исходного кода, по обобщеной информации - спецификации,
- анализ по консервирующим допущениям,
- многократное использование обощенной информации, чтобы избежать повторного анализа компонентов,
- сокращение работы при ручном изменении кода, поскольку можно не анализировать код, незатронутый изменениями.
Методика такого анализа технически подобна мемо-функциям в функциональном программировании.
