Содержание к диссертации
Введение
Глава 1. Состояние вопроса и постановка задачи исследования 14
1.2 существующие технологии и методы начального этапа проектирования
многокомпонентных программных систем 18
І.2.1. Системный анализ требований 20
1.2.2 Поиск существующих компонентов ... - 25
1.2.3 Композиция архитектурного решения 25
1.2.4 Выводы по современному состоянию вопроса проектирования ПО 27
1.3 Особенности представления знаний на начальном этапе проектирования программных систем 28
1.4 Обзорсущпствующих логических chctfm представления знаний 33
Выводы Постановка задачи исследования 38
ГЛАВА 2. Разработка языка, модели и методики для описания гибридных логических моделей . 40
2.1 Спецификация программных компонентов па основе гибридных логических моделей 40
2.2 Модель интерпретации результатов вывода логических систем 45
2.2.1 Язык описаних гибридных логических моделей. 45
2.2.2 Модель интерпретации результатов вывода... 50
2.3 Методика динамического представления знаний ..,.54
Выводы но ГЛАВЕ 2 59
ГЛАВА 3 Гибридные логические модели описания системы требований и программных компонентов 61
3.1 Логическая модель системы требований 61
3.2 Семантическая модель программных компонентов 65
3.2.1 Семантическая составляющая а спецификации программных компонентов 65
3.2.2 Описание семантики с помощью гибридной логической модели 68
3.2.3 Пример спецификации программных компонентов с помощью семантической модели 7/
Выводы по главе 3 79
ГЛАВА 4. Разработка алгоритмического и программного обеспечения автоматизации начального этапа проектирования 80
4.) Алгоритмическое обеспечение 80
4.І.1 Алгоритм композиции архитектурного решения 80
4.1.2 Оценка алгоритма .90
41 Программный комплекс автоматизации начального этапа проектирования «semo» 91
4J.I Требования к разрабатываемой системе 91
4.2.2 Архитектура 91
4.2.3 Программный комплекс «SeMob 94
4.2.4 Интерфейс пользователя «SeMo/t 99
4.2.5 Тестирование и оценка эффективности «SeMoa 100
Выводы по главе 4 107
Заключение. 108
Библиографический список
- Поиск существующих компонентов
- Модель интерпретации результатов вывода логических систем
- Семантическая составляющая а спецификации программных компонентов
- Алгоритм композиции архитектурного решения
Введение к работе
Актуальность темы исследования. Процесс проектирования программной системы предлагает построение развернутой и точной архитектуры, покрывающей большинство необходимых аспектов для последующей реализации программного обеспечения (ПО). В настоящее время наиболее распространенной и обоснованной является обобщенная технология проектирования, основанная на последовательной реализации трех основных этапов: анализ требований, поиск существующих компонентов, композиция архитектурного решения (анализ и синтез проектных решений).
Автоматизация проектирования, в том числе методов формирования и детального анализа программной системы перед ее реализацией (этап поискового конструирования), на сегодняшний день является наиболее сложной и трудно формализуемой задачей в теории многокомпонентных программных систем и инженерии ПО, В развитии автоматизации проектирования заметную роль сыграли работы Дж. Джонса, М. Принса, И. Сазерленда, И.П. Норенкова, В.А. Осипова, А.И. Половинкина, В.А. Камаева, Ю.М. Соломенцева и многих других ученых. Концептуальной основой автоматизации проектирования и решения задач анализа и синтеза являются накопленные проектные знания. Однако до сих пор проблема согласования различных проектных этапов не решена, А существующие технологии содействуют в решении только некоторых подзадач, таких как документирование требований (с помощью ограниченного естественного языка или графических методов); описание программных компонентов и га поиск по ключевым словам; построение архитектуры программной системы на основе выбранных шаблонов. Анализ новейших методов проектирования показал, что успешность решения указанной проблемы проектирования зависит от создания единого формального базиса, обеспечивающего взаимодействие разнородных моделей, методов, технологий.
Как отмечает И.А. Барков в своих работах, в автоматизированном проектировании проблема согласования разнообразных проектных этапов и компонентов трансформируется в проблему интеграции на инвариантной основе структур данных и процедур решения проектных задач, В настоящее время обоснованно применяются логические модели для представления знаний при создании так называемых интеллектуальных САПР, которые характеризуются возможностью принятия проектных решений при использовании инвариантных к проблемным областям алгоритмов. Однако существующие логические модели описания программных компонентов (OWL-S, WSMO, WSDL-S, FLOWS) строятся только с учетом внутренних характеристик и свойств, независимо от возможных зависимостей и трансформации значений в различных средах. Также эти модели предполагают использование одной конкретной логики для описания различных типов данных, что делает задачу представления знаний трудноформализуемой.
Таким образом, актуальной является задача разработки нового подхода для автоматизации начального этапа проектирования многокомпонентных программных комплексов, ориентированно го на представление знаний и проектных решений с помощью гибридных логических моделей.
Цели и задачи исследования. Целью работы является повышение эффективности проектирования многокомпонентных программных систем за счет обеспечения начального этапа проектирования средствами моделирования, основанными на гибридных логических моделях. Под повышением эффективности понимается сокращение трудоемкости и стоимости относительно существующих на сегодняшний день методик проектирования при соответствующем качестве. Дня достижения данной цели были поставлены и решены следующие задачи;
1. Разработка методики представления знаний о программных компонентах, с учетом трансформации их функциональных и нефункциональных характеристик при взаимодействии с окружающей средой;
2. Разработка логической модели требований к разрабатываемому программному обеспечению;
3. Разработка модели для представления различных по природе знаний о характеристиках программных компонентов с учетом их семантики;
4. Разработка языка для описания гибридных логических моделей, описывающего взаимосвязь между различными типами разнородных данных;
5. Разработка инвариантной программной среды, предназначенной для автоматизации процесса проектирования программных систем. Объектом исследования в диссертационной работе является процесс
проектирования программных систем.
Методы исследования. Для решения поставленных задач были использованы теория и методы автоматизированного проектирования программных систем; методы системного анализа, искусственного интеллекта и математической логики, методы интеллектуального анализа данных и анализа бизнес-процессов, методы проектирования формальных языков.
Реализации результатов работы. Теоретические результаты диссертационной работы реализованы в виде программного комплекса «SeMo», позволяющего проверить работоспособность разработанных моделей и алгоритмов.
Реализация результатов работы. Теоретические результаты диссертационной работы реализованы в виде программного комплекса «SeMo»3 позволяющего проверить работоспособность разработанных моделей и алгоритмов.
Результаты работы внедрены в технологический процесс компании Siemens (отдел СТ SE 2) при создании программных комплексов. Используется для описания программных компонентов с целью повторного использования с помощью предложенной семантической модели и последующей регистрации их в специализированных библиотеках. Позволяет автоматически совмещать логическую модель системы требований с семантическими моделями программных компонентов. После выборки необходимой конфигурации из семейства возможных продуктов программных систем, аналитик получает вариант готовой архитектуры, учитывающей уже существующие программные компоненты.
Достоверность полученных результатов подтверждается успешным применением разработанного программного комплекса «SeMo» к решению задачи автоматизации начального этапа проектирования программных систем в компании Siemens AG, СТ SE 2 (Акт внедрения от 25 сентября 2007 года).
Научная новизна состоит в том, что разработана новая технология автоматизированного проектирования программных систем, включающая в себя:
1, Методику представления знаний о программных компонентах, отличающуюся от существующих возможностью моделирования процедуры изменения значений характеристик при взаимодействии с окружающей средой;
2. Модель интерпретации результатов вывода логических систем, использующую разработанный язык для описания гибридных логических моделей;
3, Методику построения логической модели системы требований, основанную на взаимодействии онтологии предметной области и логической модели семейства продуктов программных систем;
4. Семантическую модель описания функциональных и нефункциональных характеристик программных компонентов, использующую гибридную логическую модель представления знаний с учетом возможной трансформации характеристик при взаимодействии с окружающей средой.
Практическая ценность работы заключается в том, что созданный программный комплекс автоматизации начального этапа проектирования программных систем может быть использован для:
1. Создания адаптивных программных систем. Адаптивные программные системы используются в гетерогенных непредсказуемых окружающих средах, когда система должна мгновенно реагировать на изменение условий, требований и обеспечить надлежащую функциональность с учетом нефункциональных требований к производительности системы;
2. Создания интеллектуальных систем поддержки принятия решений и инженерного творчества. Семантические модели, созданные на базе гибридной логической системы представления знаний с учетом возможной трансформации характеристик, могут быть использованы при описании технических решений для последующего повторного использования в новых системах;
3. Проведения дальнейших исследований в области автоматизированного проектирования программных систем и применения логических систем в инженерии ПО,
Разработанный программный комплекс автоматизации начального этапа проектирования программных систем позволяет существенно сократить время и стоимость, требуемых на определение конфигурации, построение архитектуры программной системы, а также поиск существующих компонентов для повторною использования.
Положения, выносимые на защиту,
1. Модель интерпретации результатов вывода логических систем, которая является основой для построения гибридных логических моделей;
2. Методика динамического представления знаний о программных компонентах, которая позволяет описывать семантику предметной области и возможные трансформации функциональных и нефункциональных характеристик при взаимодействии с окружающей средой;
3. Логическая модель системы требований, которая связывает онтологию предметной области с описанием семейства программных продуктов;
4. Семантическая модель программных компонентов;
5. Алгоритмическое и программное обеспечение, которое повышает эффективность начального этапа проектирования многокомпонентных программных систем.
Апробация работы. Основные положения диссертации докладывались и обсуждались на следующих российских конференциях: Ш-й и IV-й
Международный научно-практический семинар «Интегрированные модели и мягкие вычисления в искусственном интеллекте.», Коломна, 15-17,05.2005 и 28-30,05.2007; 11-я, Ш-я и IV-я Международная научно-техническая конференция «Интеллектуальные системы (A1S 05, 06, 07), Интеллектуальные САПР», Дивноморское, 3-10.09. 2005, 2006 и 2007 гг.; научно-практический семинар, «AIS-ADM 07», Springer LNCS, Санкт-Петербург, 3-5.06.2007.
Также основные положения диссертации докладывались и обсуждались на следующих зарубежных конференциях: Международный семинар «Frameworks for Semantics in Web Services», консорциум W3C, Инсбрук, Австрия, 9-10.06.2005; 1-й научно-практический семинар «Workshop on Product Lines & Variability», Siemens AG и Мюнхенский тех. университет, Мюнхен, Германия, 9.05.2006; научный семинар будущих кандидатов и докторов наук на 20-й Европейской конференции по ОО программированию (ЕСООР 06), Нант, Франция, 3-7.07.2006; 32-я конференция «Euromicro Conference on Software Engineering and Advanced Applications, Component-based Software Engineering track», IEEE, Дубровник, Хорватия, 28.08-1.09.2006; международная конференция «Information Research and Applications i.TECH 2007», Варна, Болгария, 25.06.-1-07.2007.
Публикации. Основное содержание диссертации нашло отражение в 17 опубликованных научных работах, в том числе в 1 статье в журнале из списка ВАК; в 9 зарубежных публикациях на английском языке, из них: ! статья в сборнике работ по искусственному интеллекту «LNAI» издательства Springer Veriag (Германия), 1 статья в сборнике работ по компьютерным технологиям издательства IEEE (США), 1 статья в списке рекомендованных к прочтению статей на сайте международного консорциума W3C, 1 статья в межд. журнале «Information Theories and Applications».
Структура и содержание диссертационной работы. Диссертационная работа состоит из введения, четырех глав с выводами, заключения, библиографического списка из 112 наименований, и приложений. Общий объем работы 107 страниц, в том числе 24 рисунка и 10 таблиц.
Автор выражает глубокую благодарность научному консультанту -доктору технических наук, профессору Заболеевой-Зотовой Алле Викторовне за оказанное содействие и поддержку в ходе выполнения диссертационной работы.
Поиск существующих компонентов
Композиция архитектурного решения является ключевым моментом в проектировании программной системы. Архитектурное решение является результатом анализа системы требований и синтеза на основе сопоставления требований и существующих решений в виде шаблонов, программных компонентов, процессов, баз данных.
В данной диссертационной работе архитектурное проектирование рассматривается с точки зрения концептуального моделирования [29, 39].
Непосредственное отображение требований и описания окружающего мира на программные компоненты не выполняется. Автор рассматривает архитектуру, прежде всего с точки зрения конфигурации, т.е. определенным набором так называемых программных артефактов, создаваемых и используемых в процессе создания программной системы.
Таким образом, автоматизация процесса композиции архитектурного решения включает в себя следующие этапы: 1. Анализ требований к проектируемой программной системе (интерпретация требований, трансформация требований в точные модели и спецификации); 2. Идентификация программных конфшураций (поиск существующих программных компонентов, выявление функций, необходимых для реализации, анализ библиотеки программных компонентов); 3. Управление архитектурным решением (выявление изменений, планирование конфигурационного управления, контроль выполнения); 4. Контроль архитектурного решения (оценка и внесение изменений); 5. Аудит архитектурного решения (оптимизация функциональной и нефункциональной составляющих конфигурации).
При этом конфигурацией многокомпонентной программной системы является множество программных компонентов и отношений между ними. Отношение используется здесь в самом широком смысле, включающем весь набор родственных понятий, таких, как ограничение, структура, информация, организация, сцепление, связь, соединение, взаимосвязь, зависимость и т,д. [45].
Конфигурация К представляет, таким образом, упорядоченную пару K=(Ct R), где С есть множество соответствующих компонентов, a R --множество отношений между элементами множества С. Также вводятся определенные классы упорядоченных пар (С, R), относящиеся к выделенным задачам. Эти классы можно ввести с помощью одного из двух фундаментальных критериев различия: выделение систем, базирующихся на определенных типах элементов; выделение систем, базирующихся на определенных типах отношений,
В итоге проведенный анализ систем автоматизации проектирования ПО на российском и зарубежных рынках указал на следующие особенности процесса проектирования программных систем, возникающие при композиции архитектурного решения:
1. Требования заказчика, формализуемые на начальном этапе проектирования, описываются с помощью ограниченного естественного языка и с помощью графических методов (И-ИЛИ деревья, направленный граф);
2. Аналитик (проектировщик, архитектор) принимает архитектурное решение, основываясь на знании существующих шаблонов проектирования и собственном опыте их применения;
3. Наличие уже реализованных программных компонентов в проекте архитектуры будущей системы зависит от наполнения библиотеки готовых компонентов и времени, затраченного на поиск и анализ подходящих компонентов аналитиком;
4. Время и стоимость реализации проектного решения зависит от количества существующих программных компонентов для повторного использования, упоминаемых в архитектуре будущей системы; точности самой архитектуры, связей между компонентами;
5. Время и стоимость тестирования программной системы зависит, прежде всего, от учтенных в проектном решении зависимостей ОТ нефункциональных свойств программных компонентов (время реакции, время ответа, производительность и др.). Перечисленные особенности процесса принятия решений при проектировании программных систем свидетельствуют об актуальности разработки новых методов проектирования программных систем, которые могли бы быть полезными проектировщикам для автоматизации выполнения начального этапа проектирования, поиска и анализа существующих компонентов, проверки архитектуры программной системы на ошибки. Успешность автоматизации всего процесса проектирования зависит от создания единого формального базиса, обеспечивающего взаимодействие разнородных моделей, методов, технологий. Таким образом, актуальными задачами являются: выбор подходящего метода представления знаний обо всех этапах проектирования и составление алгоритмов автоматизированной композиции архитектурного решения, основанных на выбранных методах представления знаний.
Модель интерпретации результатов вывода логических систем
Модель интерпретации результатов вывода логических систем строится на основе языка для описания гибридных логических моделей. Язык описания гибридных логических моделей строится на основе выбранного языка описания онтологии (Description Logic [98]), языка описания правил (SWRL [106]), модальной логики Кп [51].
Язык описания гибридных логических моделей представлен следующим образом; Пусть NR и Nc - непересекающиеся множества имен отношений и классов; N - множество натуральных чисел, Nr - множество имен объектов классов, Мп- множество модальных параметров, тогда:
Class - 1 Т \ ciassName \ Class \ Class п Class Class u Class -і Class V relation. Class 3 relation. Class number relation \ , number relation где Class - это терм I класс; ciassName є Nc - имя класса; r є NR - имя отношения между классами; number є TV- натуральное число. assertion - a : Class (a, b) : relation где assertion - выражение, определяющее принадлежность объекта класса к какому то определенному классу, и задающее отношения между объектами классов; a, b eNj- объекты классов. rule " (Condition consequence)
Condition - atom \ atom A Condition consequence - atom atom - Class(x) j relationfx, y) \ sameAs(x, y) \ differentFrom(x, y) где rule - правило / зависимость значений объекта класса; condition -предусловие правила; consequence - последствие правила; х,у- переменные, объекты классов или конкретные значения данных, sameAs - отношение эквивалентности, differentFrom - отношение различия, atom - атомарное выражение. ProbabilityExpr - Class \ ProbabilityExpr г\ ProbabilityExpr \ ProbabilityExpr KJ ProbabilityExpr \ -і ProbabilityExpr \ [m] ProbabilityExpr \ m ProbabilityExpr где m є Mn- модальный параметр, ProbabilityExpr - модальная фрмула.
Первая часть грамматики используется для возможности описания данных в виде онтологии - части гибридной логической модели. Онтологии, как и семантические сети, состоят из: Узлов - соответствуют объектам, понятиям и событиям; Дуг - связывают узлы и описывают отношения между ними.
Таким образом, онтология отображает совокупность объектов предметной области и отношений между ними. При этом объектам соответствуют вершины аналогичной семантической сети, а отношениям -соответствующие дуги. В онтологию включаются только те объекты (классы и их представители - объекты классов) предметной области, которые необходимы для решения прикладных задач. В качестве классов могут выступать имена событий, действий, обобщенные понятия или свойства объектов из предметной области. Классы соединяются отношениями между классами или дугами на семантической сети, если соответствующие объекты предметной области находятся в каком-либо отношении.
Для описания предметных областей, относящихся к многокомпонентным программным системам, разработан список наиболее употребляемых отношений: JS-A - для выражения иерархии классов или отношения класс - объект класса (например, для описания используемой терминологии программного компонента, см. Рисунок 2.2.);
has - задает различные свойства объекта (например, характеристики программного компонента);
isConsequenceOf - отражает причинно-следственные связи (например, выражение Postcondition с Э isConsequenceOf.Task означает, что постусловие есть следствие задания автоматизации);
hasValue - задает значения свойств объектов (например, выражение NameOfComponent HhasVaiue.String означает, что имя компонента должно иметь значение с типом данных String);
consistsOf- задает составные части объекта проектирования (например, многокомпонентная программная система состоит из компонентов и описывается следующим образом: System с IconsistsOf.Component, и это будет означать, что система состоит хотя бы из одного компонента);
belongsTo - задает параметр принадлежности описываемой характеристики к определенной области или внешнему компоненту (например, выражение Property с IconsistsOf Component относится к общей модели и определяет, что каждая характеристика должна относится к определенному компоненту);
specifiedBy - задает отношение компонент-модель или компонент-документация. Используется при указании других (внешних) источников информации;
isRecievedFrom - используется при описании предметной области использования программных компонентов. Определяет источник получения определенного компонента.
Семантическая составляющая а спецификации программных компонентов
Эксперт, описывающий семейство продуктов ПО, пользуется разработанными графическими системами (например, UML 2,0). Перевод графической модели в логическую является автоматическим и линейным по времени (в данной диссертационной работе сам транслятор не описывается, так как задача трансляции является вторичной). Таким образом, система логического вывода, использующая набор фактов и сведений, состоящих из формального описания текущего семейства программных продуктов и логической модели системы требований к конкретной реализации, определяет условия выборки характеристик и автоматизирует принятие решения относительно текущей конфигурации необходимой системы.
Сама модель требований описывается с помощью следующей формулы: Requirement = 3 consistsOf.(Predicate \J Objective и StatusProperty) r\ 3 kasProcessingRuIe.RuIe. где требование описывается с помощью либо объекта требований, либо предиката; дополнительно вводится отношение hasProcessingRule для спецификации правила образования правила. Графическое отображение данной формулы в спецификации UML представлено на Рисунок 3.2.
Тнюш оорадам требование состоит ш двух щшгш: предикатной и объектной. На представленном ирдавдрд егаецйфик&пша требований (см. Рисунок 33. ) предикатная чж\ъ - это оператор аргіпія {печатать), а объектвад 1ттъ - шп&ря (карта). Как видно из указанного примера, предикатим будет1 во многом отлетать за ту функцию, которая требуется w пользователи- Па примере также указана информация оо окружающей среде {Relevant information).
Ситуации неопределенности которые возникают во нреш повторного использования программного кода в новых проектах возникают постоянно. Попытка разгадать программный код десяти строк оборачивается затраченным временем, нто осложняет работу и оборачивается практически полностью отказом от повторного использования даже наипростейших компонентов программных систем.
Понимание кода и закодированных алгоритмов лежит в семантике использованных операторов, а не только в их синтаксическом написании. Профессор Шалыто в своих работах [68] отмечает, что открытые исходные тексты программных компонентов не обеспечивают в достаточном объеме проблемы понимания программ и лежащих алгоритмов. Он приводит слова ведущего аналитика корпорации BASF, и одновременно профессора университета Fairleigb Dickinson, Н. Безрукова, который считает, что центральный вопрос в практике программирования - это вопрос понимания программных текстов. Всегда хорошо иметь исходники, но проблема состоит в том, что зачастую их недостаточно. Чтобы понять некоторую нетривиальную программу, обычно требуется дополнительная документация. И эта потребность растет экспонициально с ростом объема кода. Анализ текстов программ, направленный на восстановление первоначальных проектных решений, принятых разработчиками, и понимание программ являются двумя важными ветвями технологии программирования.
Однако большинство крупных проектов по созданию новых программных систем содержит в себе массу отлично написанных программных текстов, но плохо задокументированных. Доступность исходных текстов не помогает анализу содержания и поведения программного компонента, когда отсутствует доступ к ключевым разработчикам, В таких ситуациях ценность документации более высокого уровня, такой как спецификация интерфейсов и описание архитектуры может превысить стоимость самого программного исходного текста.
Программные компоненты с подробной открытой проектной документацией, в которой программная документация является лишь составной частью, может рассматриваться в качестве новой разновидности паттернов проектирования, позволяющих достаточно просто оценить как достоинства, так и недостатки выполненных проектов. Рефакторинг изменение структуры программы от ишевенкя ее функциональное ги) иди предварительное проектирование программы в этом случае может быть выполнено значительно проще, чем при наличии только исходных текстов Проектная документация должка содержать формальную спецификацию, гак иттмум, на логику разрабатываемой программы, так как то. іго и& специфицировано формально да может быть проверено, я то, чт не может быть проверено, не может быть бедашвбонньш».
Алгоритм композиции архитектурного решения
Разработанный алгоритм обеспечивает автоматизированную композицию архитектурного решения. Концептуальная идея представлена на Рисунок 4Л. Из этого изображения очевидно, что алгоритм основан на использовании всесторонней информации: требования (логическая модель системы требований), описание существующих компонентов (семантическая модель программных компонентов), аспекты окружающей среды (онтология).
Начальный этап алгоритма - описание системы требований и особенностей окружающей среды. Система требований описывает желания пользователей на разработку программного продукта. Окружающая среда представляет текущее состояние внешних объектов, общие характеристики системы и платформы реализации. Основная проблема, существующая до сих пор, - это отсутствие стандартного подхода по описанию системы требований и окружающей среды, т.к. каэвдый элемент специфичен и его представление зависит от той предметной области, которая используется. Таким образом, предлагаемая логическая модель системы требований и окружающей средм с помощью онтшогда новдіут решить эту проблему.
Очевидно, что аналогичным образом решается проблема еопшеюванм моделей дл$ автоштщацші тмптшт архитектурного решения, с помощью сшшпичеекой модели программных компонентов.
Все необходимые модели заносятся в систему с помощью существующих графических методов и необходимых автоматически генерируемых шаблонов, минуя этап логического моделирования,
С точки зрения алгоритма композиции, наиболее важным этапом является определение точки сравнения будущих кандидатов на роль компонентов в требуемую программную систему. Для реализации этого этапа в алгоритме вводится метод getPivot(). Основываясь на этом методе, алгоритм использует полученных кандидатов в программные компоненты требуемой системы (например, перебором или с помощью алгоритмов индексации). Этот подход представлен на Рисунок 4.2.
Сам алгоритм композиции архитектурного решения состоит из нескольких частей: анализ требований (см. Рисунок 4.2.), выбор кандидата в программный компонент, проверка кандидата на соответствие семантики интерфейса. Обобщенный алгоритм композиции представлен на Рисунок 4.3. Выбор кандидата в программные компоненты основывается на оценке системы требований и условий окружающей среды. Логический запрос генерируется в соответствии с логическим представлением требований и анализом онтологии как системы фактов. Таким образом, компоненты проверены на возможность их использования в зависимости от их семантического описания (семантической модели). Перед тем, как представить подходящий компонент в качестве кандидата, система проверяет его динамическую составляющую (динамический уровень) семантической модели на предмет наличия правил / зависимостей от условий окружающей среды. Например, если выбранный компонент - сервис телевизионных программ, то методы turnON (включить) и setVolume (выключить) могут После выбора компонента и вызова необходимых методов, алгоритм композиции осуществляет поиск семантически эквивалентных программных компонентов, которые могут вызывать необходимые методы и менять их параметры. Если поиск оканчивается успехом, то композиция расширяется добавлением компонента в структуру требуемого программного продукта. Проверка на эквивалентность семантических параметров основана процедуре сравнения, представленной на Рисунок 4 А
Для генерации архитектурного решения используется технология моделирования бизнес-процессов, позволяющая представление таких структур как синхронный / асинхронный, расщепленный / объединенный процесс, петля, и т.п.
Алгоритм композиции архитектурного решения представлен с помощью формального синтаксиса следующим образом: быть вызваны перед тем, как выбрать данный компонент.
