Статья представляет собой обзор ряда зарубежных публикаций по весьма актуальной теме синтеза архитектуры программных и аппаратных систем, моделирования и верификации разрабатываемых программных систем.
Существует много интерпретаций термина «архитектура программного обеспечения» и «архитектура аппаратных средств» (здесь мы сознательно не ограничиваемся понятием «архитектуры вычислительных средств»). Наиболее удачное определение термина «архитектура» было дано впервые в 1994 году дискуссионной группой по архитектуре программного обеспечения (ПО) из Software Engineering Institute. Это определение можно распространить как на программные, так и аппаратные средства. Архитектура – структура компонентов программы или системы, их взаимосвязи, принципы и руководства для их проектирования и развития во времени [1].
Большинство описаний архитектуры представляют собой рисунки, в которых прямоугольниками показаны исполняемые компоненты, а разного рода стрелками – взаимодействие среди этих компонентов. Эти рисунки аккумулируют опыт создания конкретной системы, который предлагается распостранить на системы, подобные проектируемой. Такой подход для практики проектирования был основным примерно до 80-х годов.
В качестве примера приведем эффективный опыт разработки сложной программной и аппаратной системы – имитатор команд и управления для удаленного пилотируемого аппарата [2]. Цикл развития проекта был традиционным: с параллельным планированием по аппаратной и программной частям. Техника планирования архитектуры позволяет составить план проекта ПО, оставаться в пределах ограниченного бюджета и выполнять все требуемые функции. Первая задача, которая стояла перед разработчиками заключалась в выборе компьютера, удовлетворяющего множеству системных требований. Выбор компьютера определялся в конечном итоге бюджетом. Необходимость эффективного развития ПО требовала обоснования адекватных средств разработки или «центра генерации программ» (PGC). Был выбран компьютер (Data General Nova 800), который позволял вести как разработку ПО, так и моделирование в реальном времени.
В области языков описания аппаратной части (hardware) известными примерами являются VHDL [3] и Verilog [4]. Языки описания hardware обеспечивают наиболее ясное представление архитектуры коммуникаций. Например, в VHDL компоненты интерфейсов (декларативные графические примитивы) могут быть объединены в архитектуру до того, как они будут связаны (в конфигурации) для выполнения. Архитектура в VHDL может иметь много различных вариантов связывания компонентов (конфигураций), но все они имеют ту же самую схему взаимодействия. Возможные варианты архитектур при описании на VHDL ограничены режимом статики: число компонентов и их соединения определяются во время компиляции.
Синтез и анализ архитектуры программных средствВопросы программной архитектуры стали важной областью для изучения практиков и ученых. Важность этого направления подчеркивается появлением большого числа работ в таких областях как языки модульного интерфейса и описания архитектуры, образцы и справочники, формально описывающие проектирование архитектуры и архитектурное проектирование интерфейса ПО.
Однако рост важности понимания архитектуры ПО ведет к более явному использованию архитектурного проектирования. Это видно в следующих подходах: стандартизация компонентов, общность продуктов, платформы, доменно-ориентированная архитектура.
Использование стандартизованных компонентов имеет место там, где производители ПО осознают, что существует общее множество компонентов, которое используется параллельно некоторым множеством продуктов. Пример этого – BaseWorx [5], множество стандартных компонентов которого формирует базис для множества связанных операций, поддерживаемых системами. Специфические системы создаются добавлением специфических компонентов к стандартным компонентам.
Общность продуктов является одним из средств накопления ценных свойств продуктов – актива. Базу актива используют для создания ряда тесно связанных архитектур прикладных систем.
Платформа в общем – это множество компонентов, которые формируют базис некоторого разнообразия связанных продуктов. Эти компоненты являются обычно общими характеристиками, такие как базы данных, генераторы графического интерфейса пользователя и т.д. Компоненты обеспечены средствами специализации либо с помощью специальных декларативных языков, либо языками сценариев специального назначения. Платформа подобна множеству стандартизованных компонентов, но она заполнена с большой детализацией компонентов, которая необходима, чтобы быть специализированной для прикладных программных систем.
В последние годы ясно просматриваются два направления развития архитектуры ПО. Первое – проектировщики развивают широкий набор методов, технических приемов, моделей и идиом для структурирования сложных программных систем. Например, блок-схемы и принципиальные (линейные) схемы и объяснения к ним, которые обычно сопровождают высокоуровневые описания системы часто ссылающиеся к таким устройствам и системам, как конвейер или клиент-серверная система. Второе направление связано с возможностью многократного использования частей интегрированной системы для продуктов, имеющих общие черты. Направление основано на той идее, что общие аспекты набора связанных систем могут быть выделены так, что каждая новая система может быть построена за относительно низкую стоимость. Примерами этого направления являются: стандартная декомпозиция компилятора, стандартизованные протоколы обмена данными, языки программирования четвертого поколения, инструментальные средства пользовательского интерфейса и структуры, которые обеспечивают как многократно используемые структуры для развития интерфейсов, так и множества повторно используемых компонентов, таких как меню и диалоговые окна.
Обобщая эти направления можно показать четыре ярких различия между ними. Первое различие – между традиционным интересом к проектированию алгоритмов и структуры данных с одной стороны и интересами архитектуры по организации больших систем с другой стороны. В частности, проектирование архитектуры менее интересуется алгоритмами и структурами данных, используемыми внутри модулей, чем вопросами общей организации и глобального управления структуры, протоколами обмена, синхронизацией, доступом к данным, назначением функциональности к проектируемым элементам, физическим размещением, объединением проектируемых элементов, масштабированием и представлением, и выбором среди проектируемых альтернатив.
Второе различие заключается в способе представления – между описанием системы, основанном на определении-использовании компонентов структуры, и архитектурным описанием, основанным на графах взаимодействующих компонентов [6]. В прошлом разбиение системы на модули в терминах исходного кода обычно делает ясной зависимость между используемыми местами кода и соответствующими местами определения. В современном подходе модульность системы рассматривается как граф или конфигурация компонентов и соединений. Компоненты определяют прикладной уровень вычислений и хранимые данные системы. Например, клиенты, серверы, фильтры, базы данных и объекты. Соединения определяют взаимодействия между этими компонентами. Эти взаимодействия могут быть такими простыми, как вызовы процедур, передача сообщений или более сложными, включая клиент-серверные протоколы, протоколы доступа к базам данных и т.п.
Третье различие – между архитектурной реализацией и архитектурным стилем. Архитектурная реализация программы относится к архитектуре специфической системы. Блок-схемы и принципиальные схемы, которые сопровождают системную документацию, описывают архитектуру программы, поскольку они приложимы к индивидуальным программам. Архитектурный стиль определяет внутреннюю непротиворечивость формы и структуры совокупности архитектурных реализаций, имеющих общие черты [7,8]. Архитектурный стиль описывает,например, словарь компонентов и связи (например, фильтры и каналы), топологические ограничения, обеспечивающие внутреннюю непротиворечивость (например, граф должен быть ациклическим) и семантические (например, фильтры не могут совместно использовать состояние).
Четвертое различие – это различие между методами проектирования ПО (такими как объектно-ориентированное проектирование и структурный анализ) и программной архитектурой. Хотя оба метода проектирования и архитектура связаны с проблемой преодоления разрыва между требованиями и реализацией, существует важное различие между их сферами интереса. В идеале метод проектирования определяет каждый шаг, который делает проектировщик системы от требований к решению. Программная архитектура имеет дело с пространством архитектурных проектов. Внутри этого пространства объектно-ориентированные структуры и структуры потоков данных являются двумя из множества возможных.
Проектирование архитектуры больших систем всегда играло важную роль. Принципиальное использование программой архитектуры может дать позитивный эффект по крайней мере в пяти аспектах развития ПО.
1. В понимании – программная архитектура усиливает нашу способность постичь, охватить большие системы представлением их на таком уровне абстракции, на котором проекты большой сложности могут быть поняты.
2. В многократном использовании – описания архитектуры поддерживают многократное использование на целом ряде уровней и обычно сфокусированы на компонентах библиотек. Проектирование архитектуры поддерживает, как многократное использование больших компонентов, так и структур, в которых компоненты могут быть интегрированы.
3. В развитии – программная архитектура позволяет определить границы, вдоль которой ожидается развитие системы. Делая более ясной «несущую опору» системы, инженеры могут лучше понимать ответвления изменений и, следовательно, более точно оценить стоимость изменений [7]. Кроме того, описание архитектуры помогает разделить то, что связано с функциональностью компонентов, от способа которым эти функциональные элементы соединены (т.е. взаимодействуют) с другими компонентами. Это позволяет изменять механизм соединения под управлением эволюции представления, многократного использования и т.п.
4. Анализ – описание архитектуры дает новые возможности для анализа, включая высокоуровневые формы системно непротиворечивого контроля [9], соответствие архитектурному стилю [8] и качеству атрибутов [10], доменно-специфический анализ для архитектуры, который согласуется со спецификой стилей [11].
5. В управлении – сейчас ясно, что достижение жизнеспособной программной архитектуры является ключевой вехой в индустриальном процессе развития ПО. Архитектура системы должна строиться с учетом ожидаемого роста системы, ее размерности, удовлетворяя начальным требованиям и предвосхищая направление роста.
Исследования в области программной архитектуры наиболее активно ведутся в следующих областях:
•языки описания архитектуры; •формальное обоснование программной архитектуры; •техника архитектурного анализа; • развитие методов архитектуры; •регенерация архитектуры и перепроектирование; •кодификация и руководства в области архитектуры; •средства и окружение архитектурных проектов. Рассмотрим некоторые из этих областей. Языки описания архитектурыИсследования в этой области направлены главным образом на нахождение выразительной системы обозначений, понятий для представления архитектурных проектов и архитектурных стилей. В частности, много работ в этих исследованиях сфокусировано на обеспечении точного описания «склеивания» для объединяемых компонентов в большие системы.
T. Dean и J. Cordy [12] предлагают систему понятий, которая фокусируется на синтаксисе, графических аспектах различных архитектурных моделей. Ими предложен общий расширяемый язык для описания архитектуры ПО в форме диаграмм. Язык базируется на типовых узлах (задача, таблица, память с произвольным доступом, файл и т.п.) и связях (поток, сообщение, процедура, вызов и т.п.), использует формализм теории множеств.
В статье рассматривается только подход на уровне синтаксиса языка для описания структуры ПО, используются простые геометрические фигуры, такие как разного рода квадраты, круги и т.п. с соответствующей идентификацией и соединения в форме типового набора стрелок, идентифицирующих тип и направление связей (рис.1).
Рассмотрим пример языка описания архитектуры. На рис.2 показана архитектура канонической структуры компилятора, обычно используемая в курсах лекций для студентов. Это не полное представление реального компилятора, поскольку не представлен ни поток ошибок, ни множественный ввод файлов. Синтаксис языка основан на типовых направленных мультиграфах. Типовые направленные мультиграфы имеют типовые узлы и типовые ребра и допускают более чем одно ребро данного типа между узлами.
Использование языка, базирующегося на диаграммах, позволяет оставаться в согласии с традиционной практикой представления архитектуры. Синтаксический подход позволяет обосновать необходимость отдельных компонентов для системы в целом, с другой стороны – абстрагироваться от конкретных компонентов.
Следующий уровень формализации – переход к графовой модели с использованием понятий множеств и отношений. Элементы графа представляются, используя множества и отношения. Например, используются следующие обозначения множеств:
N – множество узлов системы; С – множество соединений в системе; V – множество переменных системы; MS – множество мест сообщений в системе.Узлы – это задачи и элементы памяти системы. Переменные элементы используются для управления отдельными системами. Переменные узлы используются в модели неполных соединений, и переменные соединители представляют собой ожидаемые соединения. Множество V идентифицирует переменные элементы N и C. Множество мест сообщений используется моделью произвольного количества сообщений соединителей сообщений. Места сообщений связывают пункты соединителей сообщений и задачи, к которым они присоединены. Элементы системы определяются как кортеж:
EL=src # N x C – узлы, которые являются источниками в бинарных отношениях;
dst # N x C – узлы, которые являются точками назначения в бинарных отношениях.
has # N x MS – узлы, которые имеют места сообщений.msg # MS x C – места сообщений, объединенные с соединителями сообщений.
Отношения src и dst используются в модели исходных точек и точек назначений в бинарных соединениях. Отношения has и msg образуют модель соединителей сообщений. Отношение has объединяет места сообщений с задачами. Отношение msg объединяет места сообщений с соединителями сообщений. Соединения системы определим как следующий кортеж:
Connections =Ожидаемые соединения представлены переменными. Переменный соединитель является членом области по крайней мере одного из отношений src и dst. Источник бинарных отношений – всегда есть задача. Таким образом кортеж (ВВ2, ВВА4) является частью отношения dst.
Соотношение этих двух уровней формализации – есть описание системы и ее модели. В модель системы вводятся на формальном уровне различного рода ограничения, присущие элементам системы и их связям. С помощью моделей и предложенного языка описания можно планировать варианты архитектуры ПО. Компилятор языка реализован на Prolog.
Работы [13,14] также посвящены языкам разработки архитектуры ПО и средствам разработки архитектуры систем, где дано определение языка описания архитектуры Rapide. В этом языке взаимодействие между компонентами может быть охарактеризовано в терминах модели событий. Они могут быть в дальнейшем использованы при анализе действующей системы для соответствия более глобальным правилам допустимого чередования событий. Rapide – это параллельный объектно-ориентированный язык описания событий специально спроектированный для макетирования архитектуры распределенных систем. Такие системы обычно состоят из множества компонентов, выполняющихся независимо под различными временными ограничениями. Rapide позволяет моделировать и производить анализ поведения архитектуры таких систем на ранней стадии системного проектирования процесса.
Два принципа стояли перед создателями языка: 1)обеспечить конструкции для определения исполняемых макетов архитектуры; 2)выбрать исполняемую модель, в которой параллельность, синхронизация, поток данных и временные свойства макета (прототипа) четко представлены. Oписывается частично упорядоченное множество событий исполняемой модели и основные принципы с примерами некоторых событийных функциональных возможностей для определения связи архитектур и взаимосвязи между архитектурами. В Rapide архитектура состоит из набора спецификаций (называемых интерфейсами) модулей и набора правил соединения, которые определяют прямое соединение между интерфейсами, и набора формальных ограничений, которые определяют допустимые или недопустимые соединения. Соединения определяют синхронное или асинхронное соединение данных между интерфейсами также в простой ответной исполняемой форме.
На рис.4 показана система модулей, соединенных вместе и образующих некоторую программную архитектуру. Параллелограммы представляют интерфейсы, тонкие линии – соединения, а параллелипиды – модули. Архитектура, таким образом, показана как множество интерфейсов и соединений. Система, показанная на рис.4, отличается от написанных программ , используя пакеты Ada или С++ классы, в которых модули взаимодействуют только тогда, когда имеются архитектурные соединения между их интерфейсами. В Rapide архитектура определяется до написания модулей.
Rapide состоит из пяти основных частей: языка типов для описания компонентов интерфейсов; языка архитектуры для описания потоков событий между компонентами; языка спецификаций для записи абстрактных ограничений по поведению компонентов; исполняемого языка для записи исполняемых модулей; языка шаблонов для описания шаблонов событий.
Системная компонента состоит из двух разделенных частей (см. рис.4): интерфейса, определяющего те черты, через которые она взаимодействует с другими компонентами, и модуля, который либо инкапсулирует исполняемый прототип компоненты, или иерархически определяет компонент, как архитектуру других компонентов. Интерфейсы компонент определены в языке типов. Модули могут быть определены в исполняемом языке (для общего использования) или в архитектурном языке (для иерархических архитектур).
Например, язык типов поддерживает как объектно-ориентированные и абстрактные стили типов данных определяемых интерфейсов, так и множественное наследование свойств старых интерфейсов при определении новых. Создание подтипов интерфейсов основано на идее подстановки. Существующая компонента может быть заменена новой, если тип новой компоненты является подтипом существующей компоненты. Автоматическая проверка правильности использования подтипов основана на форме интерфейсов (подобно структурной проверке типов) больше, чем использование типовых имен. Для более детального знакомства с языком типов см. работы [15-17].
Интерфейс определяет тип. Объекты (или величины) типов – есть модули, которые удовлетворяют интерфейсу. Неформально модуль удовлетворяет интерфейсу если он определяет все точки, декларированные в интерфейсе. Может быть много модулей с различным внутренним исполнением, которые удовлетворяют тому же самому интерфейсу.
Интерфейсные типы декларируются, используя следующий синтаксис: type_declaration ::= type identifier is interface_expression ‘;’ interface_type_expression ::= interface { interface_constituent } end [ interface ]Эти пять частей (или «подъязыков») удовлетворяют определенным требованиям совместимости (например, они имеют одинаковую область видимости, возможности, правила именования и внутреннюю исполняемую модель. Тем не менее Rapide определен в модульной манере так, что каждая из пяти его частей может быть изучена отдельно и каждая может быть изменена многими путями без требования изменения других.
В области описания ПО и систем хорошо известны такие языки как LOTOS [18] для моделирования протоколов передачи данных и Esterel [19] для моделирования синхронных систем. Это примеры событийно основанных реактивных языков. Они обеспечивают простые функциональные возможности для программирования поведения компонентов посредством переключений (или реагирования) на простые события или булевские комбинации событий.
Техника архитектурного анализа и развитие методов архитектурыИсследования в этой области развивают новую технику для определения и предсказания свойств различных архитектур.
Работы [20, 21] посвящены формальному подходу к моделированию архитектуры. Архитектура системы рассматривается как реагирующая модель. Эта мощная метафора была изобретена в области теории вычислительной техники Banаtre и Le Metayer [22, 23] и названа химической абстрактной машиной в работе G.Berry и G.Boundol [24] . Модели были введены в формальной работе на химической абстрактной машине. В работе рассматривается подход формальной спецификации и анализа архитектуры ПО, который основан на представлении програмной системы как химической, чьи реакции контролируются ясными правилами состояния. Подход формального описания программной архитектуры основан на действующей структуре, которая для некоторых аспектов описания архитектуры более доступен, по мнению авторов, чем другие структуры. Этому подходу свойственна семантическая точность, общность описания, общий базис для формального сравнения, восприимчивость к формальному анализу; показана ограниченность традиционных описаний вычислительных структур. Так, например, операционное описание, данное в терминах абстрактной последовательной машины, не применимо к параллельной архитектуре и наоборот. Аналогичная проблема возникает при функциональном описании с одной стороны и абстрактном описании базовых состояний абстрактной машины.
В работеV. Rajlich и J. Silva [25] вводится понятие ортогональной архитектуры ПО, состоящей из классов организованной в слои и вертикальные последовательности, и методология для трансформации одного вида программ, имеющих эту архитектуру в другой; рассматривается случай изучения развития области визуальных интерактивных средств. Под развитием ПО понимается процесс настройки программ для того, чтобы отвечать некоторому новому множеству требований. Для того, чтобы отвечать требованиям развития архитектура должна обладать следующими свойствами: быть интуитивно понятной; адаптируемой, т.е. способной к изменениям, в то время как общая структура системы остается неизменной; многократно используемой – архитектура может быть трансформируемой из одного множества спецификаций в другой. Архитектура системы напоминает реляционную решетку, где некоторые узлы могут не иметь супремум или инфимум. Разработан программный инструмент DEG для преобразования С++ программ согласно описываемой архитектуре. С++ программы редактируются, используя DEG в двух формах: диаграмма классов и исходном коде. Предлагаемая архитектура не является наилучшей из всех возможных, но отвечает требованиям развития и многократного использования элементов системы.
Регенерация архитектуры и перепроектированиеДля больших систем с продолжительным временем жизни возможность управлять, модифицировать исходный код ПО является критическим.
Исследования в этой области решают такие вопросы, как: • выделение архитектурных проектов из существующих систем; • унификация связанных архитектурных проектов;• абстракция, обобщение, конкретизация доменно-специфических компонентов и структур (термин домен относится к классу приложений);
• способность к взаимодействию – техника для определения не сочетающихся компонентов и переносимость программ (и данных) с одной ЭВМ на другую.
Возможность повторного использования программного кода, один из основополагающих принципов объектной идеологии, остается несбыточной мечтой разработчиков на протяжении уже двух десятков лет – с тех пор, как на рынке появились хорошие коммерческие версии объектно-ориентированных языков программирования. Особенно большие надежды возлагались на С++. Казалось, что компании выпустят на его основе множество типовых объектов и программы можно будет собирать из готовых блоков. Однако неосуществленная идея повторного использования объектов оказалась одним из самых больших разочарований объектно-ориентированного программирования. Случилось это потому, что в мире распространено большое число несовместимых платформ. Разработчикам крупных информационных систем требуются кирпичики, способные функционировать на разных операционных системах. Но подходящей объектной кросс-платформной технологии не нашлось. Язык Java пока не оправдывает надежд – он сложен. Java-приложения работают слишком медленно. Программисты опасаются, что из-за отсутствия независимого стандарта, как в случае с Microsoft Windows, развитие Java будет зависеть только от Sun. Кроме того, существует огромное число старых, но активно эксплуатируемых приложений для Unix и мейнфреймов, а переписывать их заново очень дорого.
В начале 90-х годов стала очевидной потребность в новой технологии создания распределенных приложений любого масштаба, независимых от платформы, способных работать в связке со старым ПО и легко наращиваемых путем добавления строительных блоков по принципу «подключи и работай». Такие блоки должны представлять собой небольшие, легко стыкующиеся друг с другом и допускающие интеграцию с Internet программные модули, которые могли бы выпускать разные компании. При этом желательно, чтобы работа этих модулей не зависела от конфигурации сети и конкретной клиент-серверной архитектуры.
Необходимо специально проектировать с самого начала ПО многократного использования для того, чтобы выполнить обещание многократного использования. Рассмотрим на частном примере основные черты программной архитектуры, обладающей свойством многократного применения.
Иерархическая ориентированная на специфические области архитектура, основанная на сочетаниях разделения по уровням совокупности логически связанных средств или понятий, потоков данных и рабочих областей, описывается в работе [26]. Предлагаемая программная архитектура DSSA ориентирована на приложения для широкого класса адаптивных интеллектуальнах систем: автономные роботы (промышленного и офисного применения), мониторинговые системы (медицинские, для энергетических обьектов и т.п.), компоненты ПО для связи и обмена информацией (е-mail manager, meeting manager и т.п.). Предложенная архитектура DSSA включает в себя:
• архитектуру ссылок, которая описывает общую интегрированную компьютерную систему, для важных классов;
• библиотеку компонентов, которая содержит ПО многократного использования;
• метод прикладной конфигурации для автоматического выделения и конфигурирования этих компонентов внутри архитектуры.
Литература1. D.Garlan, D.E.Perry. IEEE Transactions on Software Engineering. Vol. 21, No.4, 1995, pp.269-274.
2. S.R. McCammon. Applied Software Engineering: A Real-Time Simulator Case History. IEEE Transactions on Software Engineering. Vol. SE-1, No.4, 1975, pp.377-383.
3. IEEE, IEEE Standard VHDL Language Reference Manual, IEEE Standard 1076-1987, Mar. 1987.
4. D.E. Thomas and P.R. Moorby. The Verilog Hardware Description Language. New York: Kluwer-Academic, 1991.
5. R.P.Beck et al. Architectures for for large-scale reuse, AT&T Tech.J., Vol.71, No.6, 1992, pp.34-45.
6. R.Allen, D.Garlan. Beyond Definition/use: Architectural interconnection. Proc. ACM Interface Definition Language Workshop, SIGPLAN Notes, Vol.29, No.8, 1994.
7. D.E. Perry, A.L. Wolf. Foundations for the study of software architecture. ACM SIGSOFT Software Eng. Notes, Vol.17, No.4, 1992.
8. G. Abowd, R. Alen, D. Garlan. Using stile to give meaning to software architecture. Proceedings of SIGSOFT’93: Foundations of software engineering, Software engineering notes, Vol. 18, No. 5, 1993, pp.9-20.
9. R. Alen, D. Garlan. Formalizing architectural connection. Proceedings ICSE’16, May 1994.
10. P. Clements, L. Bass, R. Kazman, G. Abowd. Predicting software quality by architecture-level evaluation. Proceedings fifth international conference software quality, Austin, TX, 1995.
11. D. Garlan, R. Alen, J. Ockerbloom.Exploiting style in architectural design enviroments. Proceedings of SIGSOFT’94: Foundations of software engineering, New York: ACM Press, 1994.
12. T.R.Dean and J.R.Cordy. A Syntactic Theory of Software Architecture. IEEE Transaction on Software Engineering. Vol. 21, No.4, 1995, pp.269-274
13. M. Shaw, R. DeLine, D. Klein, T. Ross, D. Young, G. Zelesnik. Abstraction for Software Architecture and Tools to Support Them. IEEE Transactions on Software Engineering, Vol. 21, No. 4, 1995.
14. D. Luckham, L. Augustin, J. Kenney, J. Vera, D. Bryan, W. Mann. Specification and Analysis of System Architecture Using Rapide. . IEEE Transactions on Software Engineering, Vol. 21, No. 4, 1995, pp.336-355.
15.D.Katiyar, D.Luckham, J.Mitchell. A Type System for Prototyping Languages. Proc. 21st ACM Symp. Principles of Programming Languages, Portland, OR, 1994.
16.D.Katiyar, D.Luckham, J.Mitchell. Polymorphism and subtyping in interfaces. Proc. ACM Workshop on Interface Definition Languages, 1994, pp.22-34.
17. J.Mitchell, S.Meldal, N.Madhav. An extension of Standard ML Modules with Subtyping and inheritance. Proc. ACM Conf. POPL 1991.
18. T.Bolognesi and E.Brinksma, Introduction to the ISO specification language LOTOS, in The Formal description Technique LOTOS, van Eijk et al., Eds. Amsterdam, The Netherlands: North-Holland, 1989, pp.23-73.
19. G.Berry, P.Couronne and G.Gonthier, Synchronous programming of reactive systems: an introduction to Esterel, INRIA, Paris, Tech. Rep. 647, Mar. 1987.
20. R. Riemenschneider, M. Moriconi, X. Qian. Formal Approach to a Correct Refinement of Software Architectures. . IEEE Transactions on Software Engineering, Vol. 21, No. 4, 1995.
21. P. Inverardi, A. Wolf. Formal Specification and Analysis of Software Architectures Using the Chemical Abstract Machine Model. IEEE Transactions on Software Engineering, Vol. 21, No. 4, 1995
22. J.-P. Banatre, D. Le Metayer. The gamma model and its discipline of programming. Science of Comput. Programming, vol. 15, 1990, pp.55-77.
23. J.-P. Banatre, D. Le Metayer. Programming by multiset transformation.Commun. ACM, vol.36, 1993, pp.98-111.
24. G.Berry, G. Boundol. The chemical abstract machine. Theoretical Computer Science, vol. 96, 1992, pp.217-248.
25. V.Rajlich, J.H.Silva. Evaluation and Reuse of Orthogonal Architecture. IEEE Transactions on Software Engineering, Vol. 22, No. 2, 1996, pp.153-157.
26. B.Hayes-Roth, K. Pfleger and at all. A Domain-Specific Software Architecture for Adaptive Intelligent Systems. . IEEE Transactions on Software Engineering, Vol. 21, No. 4, 1995, pp.288-301.
 |
| Рис.1. Условные обозначения символов |
 |
| Рис.2. Каноническая структура компилятора |
 |
| Рис.3. Пример преобразования подсистемы |
 |
| Рис.4. Архитектура системы |