5. Этап реализации

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

Этап реализации обладает собственной моделью, в которой присутствуют три сущности: тип реализации, адаптер и объект. Каждому типу этапа конструирования соответствует один тип реализации. Адаптер обозначает группу типов реализации и служит единицей развертывания (deployment). Объекты этапа реализации - это конкрентные объекты, о существовании которых известно заранее, Такие объекты обычно служат точками входа в систему и регистрируются, например в Naming

Service.

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

Перед тем как начать генерацию кода, пользователь должен выбрать целевой язык программирования, а также целевые технологии, например, пользователь может выбрать технологию технической поддержки интероперабельности - RMI, CORBA или DCOM. Эти решения определяют, что же будет сгенерировано. Текущая версия прототипа ограничена тем, что в качестве целевого языка используется Java, а в качестве технологии поддержки интероперабельности - CORBA.

В процессе генерации создаются следующие спецификации: IDL-интерфейсы (типы, factories), Java-классы (реализации типов, адаптеров, фабрик), make-файлы, а также происходит регистрация объектов в Naming Service и связывание с ними.

6. База метаданных

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

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

База метаданных реализована в объектной СУБД ObjectStore. Доступ к базе метаданных осуществляется при помощи Java-интерфейсов.

7. Родственные работы

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

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

В [22] рассмотрена структура репозитория спецификаций компонентов как информационно-поисковой системы. Проблема поиска компонентов рассматривается узко - для компонентов-функций, представляемых отношениями, содержащими все допустимые пары входных/выходных значений функций. Порядок на основе отношения уточнения, заданный на множестве функций, имеет свойства решетки. Решетка формируется посредством операций join и meet на отношениях, представляющих функции. Join (meet) представляют суммарную информацию (общую информацию), содержащуюся в таких отношениях.

В [23] предложен способ сопоставления сигнатур операций как механизм поиска специфкаций программных компонентов в их репозитории. Эту работу планируется расширить на случай представления спецификаций функций их пред- и пост- условиями.

Отношение подтипа в настоящей статье трактуется аналогично [24].

Проблема разрешения структурных конфликтов при компонентном проектировании близка проблеме разрешения конфликтов при интеграции схем баз данных. Существует два подхода к разрешению структурных конфликтов: использование предопределенных правил преобразования или языка высокого уровня для описания преобразований.

При использовании предопределенных правил преобразования [19] целью является автоматическое разрешение структурных конфликтов и генерация интеграционной схемы. Разработчик задает соответствие между элементами (классами, атрибутами) схем и соответствие между путями в схемах. Затем на основе предопределенных правил генерируется интеграционная схема (классы и функции преобразования значений между классами локальных и интеграционной схем). Основными преимуществами данного подхода являются простота аргументации и доказательность корректности применения данных правил. В частности, возможно доказать, что каждое правило сохраняет информацию, и что комбинация таких правил также сохраняет информацию. Основным недостатком этого подхода является фиксация используемых правил, что вызывает ограниченность выразительных возможностей данного подхода.

При использовании языка высокого уровня [20] разработчику предоставляется богатый язык для описания правил преобразования. Однако, каждая фунция разрешения конфликта должна быть запрограммированна и ее правильность доказана отдельно. Как и в предыдущем подходе, разработчик сам задает соответствие между элементами схем. Данный подход предоставляет пользователю более гибкие средства формирования интегрированной схемы, позволяющие разрешать любые конфликты.