«Е.М.Лаврищева В.Н.Грищенко CБОРОЧНОЕ ПРОГРАММИРОВАНИЕ Основы индустрии программных продуктов Второе издание Дополненное и переработанное КИЕВ НАУКОВА ДУМКА 2009 2 УДК 519.681.2 Лаврищева Е.М., Грищенко В.Н. Сборочное ...»

НАЦИОНАЛЬНАЯ АКАДЕМИЯ НАУК

УКРАИНЫ

ИНСТИТУТ ПРОГРАММНЫХ СИСТЕМ

Е.М.Лаврищева

В.Н.Грищенко

CБОРОЧНОЕ

ПРОГРАММИРОВАНИЕ

Основы индустрии программных

продуктов

Второе издание

Дополненное и переработанное

КИЕВ

НАУКОВА ДУМКА

2009 2 УДК 519.681.2 Лаврищева Е.М., Грищенко В.Н.

Сборочное программирование. Основы индустрии программных продуктов: 2-изд. Дополненное и переработанное.–Киев: Наук. думка, 2009.– 372с.–ISВN 978-966-00-0848-1.

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

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

Для специалистов, занимающихся автоматизированным созданием программных систем из готовых ресурсов в разных предметных областях с использованием современных инструментально-технологических средств и сред, а также студентов и аспирантов вузов специальностей – прикладная математика и программная инженерия.

Ответственный редактор академик НАН Украины Ф. И. Андон Утверждено к печати ученым советом Института программных систем НАН Украины Научно-издательский отдел физико-математической и технической литературы Редактор М.К.Пунина ISВN 978-966-00-0848-1 © Е. М. Лаврищева, В.Н. Грищенко,

ОГЛАВЛЕНИЕ

СПИСОК СОКРАЩЕНИЙ ……………………………………………………………………. ПРЕДИСЛОВИЕ ……………………………………………...…….........………...…………...

Г л а в а 1. ПРОБЛЕМАТИКА СБОРОЧНОГО ПРОГРАММИРОВАНИЯ

ПРОГРАММНЫХ СИСТЕМ …...……

1.1. Основное содержание метода сборочного программирования ………...…

1.1.1. Ранние методы интеграции программных объектов …….............………….…...... 1.1.2. Современные методы интеграции программных объектов …….........………….... 1.2. Основные элементы и задачи сборочного программирования ….….........………….… 1.3. Определение интерфейса программных объектов …………...........…………………… 1.4. Представления знаний о предметных областях ……………….…….............……………

Г л а в а 2. ОБЩИЕ ВОПРОСЫ РЕАЛИЗАЦИИ МЕТОДА СБОРОЧНОГО

ПРОГРАММИРОВАНИЯ …………………………….….......………………………………... 2.1. Методы комплексирования программных объектов …………..……...........………….… 2.2. Средства автоматизации методов комплексирования ……..…….…...........………....… 2.3. Объекты сборочного программирования …………………..………............………....… 2.4. Основные модели программных систем (ПС) …………………………………………… 2.4.1. Модели сборочного программирования …………...………….................……….... 2.4.2. Базовые модели разработки современных ПС..…...………..................…………... Г л а в а 3. КОМПЛЕКСИРОВАНИЕ МОДУЛЕЙ ………….…….…...............……...….. 3.1. Определение модуля и его свойств …………………………………..............………....… 3.2. Определения типов связей модулей

3.3. Интерфейсы программ и их функции ……………………….……..............……………... 3.4. Модели комплексирования модулей …………………..............………………………..… 3.5. Типы данных языков программирования (ЯП) …………………………..............……..... 3.5.1. Простые типы данных ….…………………………………..................…………... 3.5.2. Структурные типы данных ……………………………..…

3.5.3. Сложные типы данных ………………………

3.6. Методы преобразования нерелевантных типов данных ………...............…………….... 3.6.1. Преобразование простых типов данных ……………………..................………….. 3.6.2. Преобразование структурных типов данных..…………

3.6.3. Изменение уровня структурирования данных ………

3.7. Вопросы определения интерфейса языков программирования и программ…...........…. 3.7.1. Подходы к реализации межъязыкового и межмодульного интерфейсов ……….. 3.7.2. Отечественные и зарубежные разработки интерфейса в 80-х годах …………. 3.7.3. Краткий обзор современных подходов к реализации интерфейсов языков 4.1. Определение модульной структуры программных агрегатов.…..…...............…………. 4.2. Типы программных агрегатов ……………………………………..…...........…………… 4.3. Матричное представление графов агрегата из модулей …….…..…..............…………... 4.4. Отношение достижимости для графов модульных структур.…..…............…………… 4.5. Операции построения модульных структур …..…………………................……………. 4.6. Процесс построения модульных структур …….….……..………..............……………... 4.6.1. Типы программных структур ……………………………….................………...…. 4.6.2. Метод реализации связей в модульной структуре …………..................………..... 4.6.3. Отладка и тестирование программ из модулей ………..…

5.1. Общие методы типизации и классификации программных компонентов....…………. 5.1.1. Подход к типизации компонентов …………..………..…

5.1.2. Классификационные признаки компонентов..……..…

5.1.3. Классификация компонентных моделей современных систем …........…………. 5.1.4. Основы классификации компонентов веб-приложений

5.2. Классификация компонентов повторного использования ……

5.3. Информационные ресурсы (ИР). Классификация и типизация ….................………….. 5.3.1. Типовая схема связи с менеджером ИР …………...…

5.3.2. Типовость структуры и интерфейса менеджера ИР.……

5.3.3. Аспекты применения менеджера ИР ……………………

5.4. Интеграция менеджеров ресурсов ………………………..............…..…………………... 5.5. Подход к стандартизации ресурсов Интернета …………………….............………....… Г л а в а 6. ОБЪЕКТНО-КОМПОНЕНТНЫЙ МЕТОД РАЗРАБОТКИ ПРОГРАММНЫХ СИСТЕМ ………………………………………………..……...

6.1. Аспекты теории объектного анализа ……….............………………………………….… 6.1.1. Формальные уровни абстрактного представления объектов модели....………..... 6.1.2. Функции и алгебра объектного анализа..……………..…..................………….… 6.2. Теория компонентного программирования ……...…..………..................…………….. 6.2.1. Основные понятия компонентного программирования …

6.2.2. Модель компонента и интерфейса ………………………

6.2.3. Модель компонентной среды ……………………..……

6.2.4. Внешняя и внутренняя компонентные алгебры …..……

6.2.5. Эволюция компонентов в компонентной алгебре................…………………….... 6.3. Формализованное представление компонентных систем…………….................…....… 6.4. Суть объектно-компонентного метода ………….……………

Г л а в а 7. МЕТОДЫ СБОРОЧНОГО ПОСТРОЕНИЯ ИНТЕГРИРОВАННЫХ

7.1. Особенности задания интерфейсов в интегрированных комплексах (ИК)....………….. 7.2. Методы и средства интеграции ИК …..………..……...........……………………………... 7.3. Логическое проектирование комплексов …

7.3.1. Анализ и выбор компонентов для создания ИК

7.3.2. Описание базы данных ИК …………………………...………..................……….... 7.3.3. Разработка модели сопряжения и управления объектами..............………………. 7.3.4. Создание среды функционирования ИК ……..………

7.4. Современные подходы к сборке разноязыковых компонентов …..…............………..... 7.4.1. Модели сборки компонентов в современных средах

7.4.2. Взаимодействие компонентов в среде Java ……...………

7.4.3. Обеспечение взаимодействия компонентов в MS.NET …

7.4.4. Анализ взаимодействия разноязыковых компонентов по Бею...........…………... 7.4.5. Стандарт ISO/IEC 11404–2007. Типы данных общего назначения.......……….... 7.5. Корректность сборки разноязыковых компонентов ….……............………………….…

Г л а в а 8. ОСНОВЫ ПОСТРОЕНИЯ ТЕХНОЛОГИЧЕСКИХ ЛИНИЙ И СРЕДСТВ

8.1. Сущность технологии сборочного программирования

8.2. Концепция построения технологических линий (ТЛ) изготовления программ ……… 8.3. Определение процессов и линий в классе функциональных задач СОД.……………… 8.4. Базовые модели функционально-ориентированных технологий ….............…………… 8.4.1. Модель оценки качества программ на ТЛ...........……....………………………….. 8.4.2. Модели представления проектных решений на ТЛ …..…

8.5.1. Технологический модуль сборки, тестирования модулей ПС..........……..……... 8.5.2. ТМ создания проблемно-ориентированного программного обеспечения…….. 8.5.3. Семантика процессов разработки ………………………………………

8.6. Современные подходы к созданию программ на линии …………............………………

Г л а в а 9. ВОПРОСЫ УПРАВЛЕНИЯ РАЗРАБОТКОЙ ПРОГРАММНЫХ

СИСТЕМ ПО ТЕХНОЛОГИИ СБОРОЧНОГО ПРОГРАММИРОВАНИЯ ……………

9.1. Инженерные методы и принципы планирования выполнения работ…………………. 9.2. Влияние сложности программ на ведение процесса разработки систем…………….. 9.3. Организация и управление коллективом разработчиков………………………………. 9.4 Управление качеством программ по технологическим линиям..…………………….... 9.6 Анализ моделей надежности для оценки программных систем……………………... 9.6.1. Типизация моделей надежности для класса программных систем……………... 9.6.2. Модели надежности марковского типа.................………………………………... 9.7. Подход к автоматизации оценки качества программных систем……………………... Г л а в а 1 0. ОСНОВНЫЕ ПОЛОЖЕНИЯ И ДИСЦИПЛИНЫ СБОРОЧНОГО 10.1. Роль стандартов и моделей жизненного цикла (ЖЦ) при изготовлении программных продуктов …………………………………………………………………………………..

10.1.1. Стандартная регламентация процессов ЖЦ …………………

10.1.2. Фундаментальные модели ЖЦ ……………………………. …..............………... 10.2. Система знаний ядра SWEBOK для организации изготовления ПС...........………….. 10.2.1. Разделы проектирования SWEBOK …...............………………………………... 10.2.2. Разделы управления в SWEBOK …..............…………………………………..… 10.3. Научно-технологические дисциплины для решения задач индустриального производства программ ……………...…………………..............……………………….. 10.3.1. Содержание научной дисциплины производства программных продуктов...... 10.3.2. Основы инженерии производства программных продуктов…..…................….. 10.3.3. Управление изготовлением программных продуктов …………………………. 10.3.4. Экономика измерения и оценки программных продуктов …................…….… 10.3.5. Основные аспекты индустрии программных продуктов...…….…................…. 10.4. Роль и место дисциплин программной инженерии в информатике …………............... ПРИЛОЖЕНИЕ 1. Онтологическая система «Онтоаспект» репозитария КПИ………….… ПРИЛОЖЕНИЕ 2. Алгоритм реализации веб-приложения на основе менеджеров информационных ресурсов.………...………….…

ПРИЛОЖЕНИЕ 3. Интерфейс взаимодействия программ в языках программирования Дельфи и Пaскаль ………………………………………………………………………………...

СПИСОК СОКРАЩЕНИЙ

АИС – автоматизированная информационная система АСНИ – автоматизированная система научных исследований АСУ – автоматизированная система управления БИМ – библиотека исходных модулей ВБМ – временная библиотека модулей ГКНТ – Государственный комитет по науке и технике ЖЦ – жизненный цикл ЕСКД – единая система конструкторской документации ЕСПД – единая система программной документации ИВ – информационный вектор ИК – интегрированный комплекс ИР – информационный ресурс ИС – информационная система КП – комплекс программ КТП – карта технологического процесса – личная библиотека МТЛ – модель технологической линии МТП – модель технологического процесса МЯИ – межъязыковый интерфейс ОКМ – объектно-компонентный метод ОМ – объектная модель ООП – объектно-ориентированный подход – программная инженерия ПК – программный компонент ПО – программное обеспечение ПП – программный продукт ППО – прикладное программное обеспечение ППП – пакет прикладных программ ПС – программная система ПТД – проектно-технологический документ ПрО – предметная область СА – системная архитектура САА – система алгоритмических алгебр САМП – система автоматизации модульного программирования САПР – система автоматизации проектирования СОД – система обработки данных СППО – система проблемно-ориентированного обеспечения ССПМ – система сборки программ из модулей ТД – технологический документ ТЛ – технологическая линия ТИ – технологический интерфейс ТМ – технологический модуль ТО – технологическая операция ТП – технологический процесс ТПР – технология подготовки разработки ТЗ – техническое задание ФА – функциональная архитектура ФОТ – функционально-ориентированная технология ЭПД – эксплуатационный документ ЯМК – язык модульного конструирования ЯОУ – язык описания модели управления ACM – Association for Computing Machinery CBD – Component-Based Development CMM – Capability Maturity Models DSL – Domain specific language SWEBOK – Software Engineering Body Knowledge

ПРЕДИСЛОВИЕ

Широкое распространение видов и типов новой компьютерной техники ставит перед специалистами важные задачи по эффективному её использованию при создании программных и прикладных систем массового применения.

Анализ потребности разных отраслей хозяйства и промышленности в программных системах (ПС) показывает, что на практике их требуется более 3, млн. различного наименования, назначения и сложности. Например, затраты на объем выпуска в 2005 г. составили 800 млн. дол. США, это на порядок меньше необходимого.

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

Повышению уровня качества автоматизации ПС, а также увеличению в 4–6 раз производительности труда программистов за последние годы способствовали:

– фундаментальные и прикладные научные исследования по созданию теоретических, прикладных и технологических основ индустрии разработки и производства ПС;

– разработка организационно-методических и стандартных руководств для управления коллективной разработкой программных проектов как инструментов эффективного создания типовых высокопроизводительных технологий производства ПС;

– практические разработки программных систем специального назначения, в том числе и бизнес-систем, в небольших и крупных коммерческих организациях;

– обучение студентов ВУЗов новым концепциям программной инженерии.

Один из путей решения первой задачи – совершенствование технологии программирования в целях перехода на промышленные методы создания ПС, которые характеризуются технологическими линиями (ТЛ) по производству программных продуктов (ПП), удовлетворяющих определенным экономическим критериям. Основная цель технологии программирования, представленной ТЛ, – четкая регламентация и организация работ по проектированию, разработке и изготовлению программных продуктов высокого качества и высокой производительности.

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

Иными словами, новыми тенденциями в современной технологии программирования являются:

– распространение на сферу программирования промышленных методов организации (планирование трудозатрат, определение трудоемкости, учет, контроль результатов труда и др.) проведения работ при изготовлении ПС;

– перенос акцента с процесса программирования ПС на более ранние процессы, обеспечивающие анализ автоматизируемой предметной области и формирование требований к создаваемому продукту;

– введение в практику разработки ПС таких понятий, как ТЛ, модель жизненного цикла (ЖЦ), технологическая карта, маршрут и т. п., являющихся основным фундаментом организации управления разработкой промышленных изделий.

Наиболее быстрый переход к промышленной организации разработки ПС может быть обеспечен путем систематизации и формализации сборочного программирования, основанного на многократном использовании КПИ как готовых наборов модулей для разных областей, по словам А.П.Ершова: «чистой экономии труда, которая должна составлять 2/3 годового производства программных средств.».

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

Монография состоит из десяти глав.

Первая глава содержит описание основных форм программирования (синтезирующего, конкретизирующего, сборочного, компонентного и др.) и описание проблем представления и реализации ПС в среде сборочного программирования.

Даны основные определения, сформулированы цели и задачи сборочного программирования, его место в современном процессе создания ПС.

Во второй главе проанализированы существующие методы разработки ПС сложной структуры, базирующиеся на концепции сборки (комплексирование, интеграция, композиция), определены объекты и основные модели сборочного программирования: модель информационного сопряжения модулей (экспорт и импорт данных); модель управления и выбора готовых ресурсов из разных источников (библиотек, системы Интернет и др.), необходимых для сборки. Дан анализ современных стилей программирования, поддерживающих парадигму сборки.

В третьей главе описаны задачи комплексирования модулей и определены формальные механизмы преобразования типов и структур передаваемых данных между программными объектами. На основе теории структурной организации данных К. Хоара и В. Вирта представлен алгебраический подход к определению и преобразованию типов данных, заданных в разных языках программирования (ЯП).

Такой подход основан на утверждениях, доказывающих необходимые и достаточные условия преобразования типов данных объектов, которые записаны в разных языках программирования (ЯП) и подлежат сборке в сложные ПС.

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

Пятая глава посвящена подходу к классификации и типизации компонентов и других программных ресурсов. Определены классификационные характеристики и признаки для класса программных и информационных ресурсов Интернета.

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

В шестой главе представлен новый объектно-компонентный метод создания ПС из готовых КПИ. Представлен теоретический фундамент объектного и компонентного программирования, включающий в себя базовую терминологию, модели (объектная и компонентная), внешнюю и внутреннюю компонентные алгебры. Приведены утверждения относительно алгебры компонентного программирования, показана коммутативность операций в ней и определено место алгебры в среде разработки ПС. Продемонстрировано применение концепции сборки разноязыковых компонентов в современных средах и системах: CORBA, JAVA, MS.NET и др.

Седьмая глава посвящена методам построения интегрированных комплексов программ, применяемых в процессе проектирования и сборки. Рассмотрен ряд готовых инструментальных систем, используемых при интеграции программ.

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

В восьмой главе сформулированы основные понятия технологии сборочного программирования: объект разработки, методы и инструменты разработки, методы организации и управления разработкой. Сформулирована задача, принципы и способы сборочного формирования конкретных технологических линий (ТЛ), реализующих задачи и функции СОД на производственной основе. Дано описание процессов и действий конкретно, созданных ТЛ применительно к производству по ним классов задач обработки данных, в том числе научно-исследовательских и математических.

В девятой главе подробно рассмотрены вопросы организации и управления разработками программ на основе ТЛ. Описаны методы планирования трудозатрат и трудоемкости, снижения сложности и управления качеством ПС на процессах ЖЦ. Приведена методика оценки показателей качества ПС. Дана характеристика моделей надежности и процесса тестирования ПС, обеспечивающего подготовку данных для определения надежности по оценочным моделям.

В десятой главе представлен системный анализ аспектов индустриального производства ПП (ЖЦ, разделы ядра знаний SWEBOK, РМВОК, стандарты качества и оценивания ПП). Рассмотрен базовый процесс инженерии производства компьютерных программ с использованием ядра SWEBOK, стандартов ЖЦ, инфраструктуры и менеджмента. Предложена система дисциплин (научная, инженерная, управленческая, экономическая), охватывающая основные аспекты в производственном цикле индустриального изготовления ПП.

Сформулированы теоретические основы и роль в пространстве задач информатики.

В приложении 1 приведена структура онтологической системы КПИ, в приложении 2 дан пример описания веб-приложения, а в приложении 3 – интерфейс компонентов в ЯП Паскаль и Дельфи.

Данное издание монографии переработано и дополнено. В нее включены основные направления становления и развития сборочного программирования с участием авторов. Идею сборки как конвейерного механизма фабрик программ предлагали В.М.Глушков и А.П.Ершов (1967г.). Далее (1985–1988гг.) формирование нового вида программирования, а именно сборочного, происходило при участии Е.Л.Ющенко. Средства сборки модулей, программ и компонентов развиваются и совершенствуются в настоящее время. Базовая концепция организации сборки разных видов и типов программных объектов – интерфейс, как связывающее звено разноязыковых программ в любых средах, – получила полную формализацию в языках описания интерфейса IDL (Interface Definition Language) и стандарта описания общих типов данных ISO/IEC 11404–1996, 2007 независимо от ЯП.

В монографию вошли новые результаты исследований и разработок, касающиеся развития процессов сборки применительно к компонентам для современных систем и сред, а также определения новой системы дисциплин программной инженерии, охватывающих все аспекты производственной деятельности по созданию программных продуктов. Научно-технической поддержкой парадигмы сборочного программирования являются результаты аспирантов и соискателей (с.н.с. Н.Т.Задорожная, Г.И.Коваль, Т.М.Коротун, О.А.Слабоспицкая), защитивших кандидатские диссертации в 2004–2008 гг., а также подготовленной к защите докторской диссертации В.Н.Грищенко и кандидатской диссертации C.Л.Поляничко (под руководством Е.М.Лаврищевой). К ним относятся ключевые основополагающие концепции теории сборки КПИ, управления программными проектами, инженерии тестирования и качества, оценивания процессов и продуктов, а также моделей представления знаний о КПИ.

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

Авторы благодарны академику НАН Украины Ф.И.Андону за полезные советы, замечания и поддержку в процессе подготовки новой редакции монографии, а также сотрудникам научного отдела Института программных систем (с.н.с. Л.П.Бабенко, Е.В.Карпусь, Г.И.Коваль, Л.И.Куцаченко и др.) за помощь в подготовке рукописи и реализации инструментально-технологических средств сборочного и компонентного программирования.

ПРОБЛЕМАТИКА СБОРОЧНОГО

ПРОГРАММИРОВАНИЯ ПРОГРАММНЫХ

СИСТЕМ

1.1. ОСНОВНОЕ СОДЕРЖАНИЕ МЕТОДА СБОРОЧНОГО

ПРОГРАММИРОВАНИЯ

Одна из главных задач современного программирования – создание теоретических и прикладных основ построения сложных программ из более простых программных элементов, которые записаны в современных ЯП. Фактически решение этой задачи осуществляется путем сборки, объединения или интеграции разнородных программных ресурсов, КПИ, включая модули и программы реализации некоторой предметной области (ПрО). Цель метода сборки – интеграция в новые программные структуры КПИ, программ, готовых ресурсов, накопленных в Интернете.

1.1.1. РАННИЕ МЕТОДЫ ИНТЕГРАЦИИ ПРОГРАММНЫХ ОБЪЕКТОВ

Интеграция программных структур сначала выполнялась с помощью готовых подпрограмм библиотек разного назначения путем их вставки в интегрируемую программную систему. Затем появлялись разные стили программирования (конкретизирующее, синтезирующее, композиционное и др.), которые решали проблему комплексирования программных объектов методами, близкими к сборке разнородных объектов (табл. 1.1). Они способствовали постепенному развитию индустриальных основ изготовления программных систем (ПС): КПИ, жизненный цикл (ЖЦ), измерение и оценивание работ на процессах ЖЦ и самого продукта на отдельные показатели качества. Позднее сформировались и другие стили программирования, которые используют готовые компоненты в процессе создания ПС методами сборочного типа – комплексирование, интеграция, композиция. К ним можно отнести: объектно-ориентированное, компонентное, генерирующее, аспектное, агентное и др.

Рассмотрим ранние методы программирования с элементами интеграции, комплексирования и синтеза.

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

программирование многопараметрическая техникой смешанных адаптации СУБД к (происходит от структура ПС. (СУБД, вычислений, оптимиза- условиям примененаличия некоторого ППП и т.п.) ционных преобразова- ния с помощью:

Синтезирующее Модель вычислений Метод доказательной Система ПРИЗ, в копрограммирование (Э.X.Тыугу [195]), генерации на основе торой по описанию (происходит от по- отображающая понятия управляющей про- модели вычислений становки задачи, и отношения ПрО в граммы, заданной по- выбирается путь и составляемой в виде виде модели програм- следовательностью строится программа программы ре- макроопределений. ния между объектами отдельных программ Композиционное Функции и операции Процесс композиции Система построения программирование композиции в логико- включает: в себя композиционных (композиция функций математической данные, функции, опе- программ программирование – это ориентированный вания разноязыковых реализует связь (происходит от Банка нагруженный граф, в модулей по схеме, разноязыковых модулей, программ, вершинах которого задающей их взаимо- модулей в ЯП ОС программных систем, находятся элементы связь по управлению и ЕС, через модулиКП и др.) банка, а дуги задают по данным, пре- посредники, обеспесвязи между ними и образуемым к релеван- чивающие необходирежим функцио- тным типам данных. мое преобразование При синтезирующем программировании строится модель программы по спецификации задачи, по которой будет синтезирована программа ее решения.

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

Композиционное функциональности и композиционности, который рассматривает программы как набор функций, строящихся из других функций с помощью специальных операций, названных композициями. На основе композиционного уточнения (експликации – explication) создана логико-математическая система композиционного построения программ, которая объединяет современные парадигмы программирования (структурное, функциональное, объектно-ориентированное и др.) в рамках единой концептуальной, экспликативной платформы. Ее основу составляют три типа объектов: сами объекты, методы композиции и средства построения из одних объектов других объектов или функций.

Сборочное программирование характеризуется сборочным построением программ из готовых «деталей», которыми являются программные объекты различной степени сложности. Элементы процесса сборки присутствуют во многих методах программирования: сверху–вниз, снизу–вверх и т. д.

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

Возникают вопросы: в чем суть сборочного программирования и что позволяет выделить его в виде отдельного метода. Для ответа на поставленный вопрос прежде всего отметим, что сборочное программирование:

– является одним из методов программирования и подчиняется общим закономерностям;

– представляет одну из форм повторного использования программных средств;

– качественно отличаться от процессов сборки в других методах.

Под методом сборки понимается способ сопряжения разноязыковых программных объектов в ЯП, основанный на теории спецификации, и отображения (mapping) типов и структур данных ЯП, представленных алгебраической системой.

Основу алгебраического формализма составляют типы данных, операции над ними и функции релевантного, эквивалентного преобразования одних типов в другие.

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

Методом, близким к сборке, является генерация разных объектов к одному общему выходному коду и среде функционирования. Понятие генерации программ возникло почти одновременно с понятием сборки, и на сегодняшний день оно получило новое развитие в связи с ориентацией на описание модели предметной области (домена) средствами языка DSL (Domain Specific Language), отображающими специфику этой области. Такое новое направление еще не имеет стандартных решений относительно самой проблемы постепенной трансформации описания в этом языке и выполнения инструментов генерации, отладки, интеграции и др. для получения конечной ПС.

Жизненный цикл программного продукта в сборочном программировании – это период времени между началом разработки и завершением его использования. Он характеризуется несколькими процессами, отражающими закономерности при разработке и применении программных средств. Различные подходы, методы, инструментальные средства могут вносить отличительные особенности в отдельные процессы, однако само содержание процессов жизненного цикла (ЖЦ) программного продукта (ПП) вполне определенное. Наиболее общими являются следующие процессы (рис 1.1).

Постановка задачи. На данном процессе формулируется задача, для решения которой необходимо разработать программный продукт. Определяются целесообразность разработки, ее стоимость, сфера применения, эффект от внедрения. Условие решаемой задачи оформляется в виде ее спецификации – технического задания, постановки задачи и т. д.

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

Постановка задачи Тестирование и отладка ПП Сборка сложных объектов Внедрение ПП Сопровождение ПП Рис.1.1. Схема представления методов разработки и использования ПС Проектирование и апробирование готовых ПП. Спецификации проектирования для вновь разрабатываемых компонентов ПП переводятся в тексты на языках программирования. Структуры данных конкретизируются и отображаются в реальную память. Исходные тексты переносятся на внешние носители информации. Готовые компоненты проверяются на выполнение функций в наборе исходных данных.

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

Сборка и тестирование сложных программных объектов. Осуществляется сборка готовых ПП из числа повторно используемых и вновь разрабатываемых методом комплексирования или интеграции. В результате создается интерфейсная среда, включающая в себя программы преобразования передаваемых данных и передач управлений соответствующим компонентам объекта сборки. Последний тестируется на множестве тестов, проверяющих созданные интерфейсы (правильность передач данных между объектами) и функционирование всего объекта. Неудовлетворительные результаты тестирования приводят к замене отдельных элементов или к исправлению в них типов и структур передаваемых данных. Эти действия вызывают выполнение указанных выше процессов ЖЦ. Результат данного процесса – опытный образец ПП.

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

Сопровождение. Этот процесс – последний в жизненном цикле и длится до завершения использования программного продукта. Окончание применения связано с:

– разработкой более качественного и совершенного ПП;

– завершением решаемой задачи и моральным старением самого ПП или операционной среды его функционирования.

В процессе сопровождения происходит устранение ранее не обнаруженных ошибок и изменение ПП, связанные с совершенствованием технологии его применения.

Использование конкретного метода программирования сказывается на длительности каждого процесса ЖЦ, его сложности и применяемых инструментальных средствах. В рассмотренных выше процессах ЖЦ создаваемого ПС явно не отражены процессы его документирования и изготовления. Это связано с тем, что технология программирования регламентирует постепенную разработку документации, ее корректировку во всех процессах проектирования и изготовления ПП. Поэтому к моменту изготовления и внедрения значительная часть документации уже подготовлена. В процессе изготовления осуществляется копирование носителей программ, доработка документации и подготовка носителей ПП. Применение инструментальных средств поддержки разработки упрощает процесс изготовления документации, и поэтому отпадает необходимость в выделении его как отдельного процесса в рамках технологии сборочного программирования.

ПС как форма представления знаний. Программные средства – это фактически один из способов представления знаний о решаемых задачах, конкретных предметных областях. С данной позиции рассмотрим более подробно процесс разработки и использования ПП.

При разработке баз знаний необходимо рассмотреть два ключевых вопроса:

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

Использование знаний связано с процессами внедрения (частично) и сопровождения ЖЦ ПП, т. е. его применения. Метод использования ПП – технология его применения. Результаты рассмотренного подхода к представлению знаний о повторно используемых ПС отражены на рис. 1.1. В частности, этой схеме удовлетворяют все три отмеченных выше виды программирования систем на основе готовых компонентов.

Отличие сборочного программирования от других методов. Главное отличие сборочного программирования от других методов повторного использования ПС состоит в наличии «устойчивой обратной связи», что отражено на рис. 1.2.

Жизненный цикл ПП Рис.1.2. Схема представления знаний в методе сборочного программирования «Обратная связь» означает, что в технологию использования разработанного ПП входят методы его применения при проектировании других ПС, где ПП входит как составной элемент. Термин «устойчивый» подчеркивает, что методы применения разработанных ПП в дальнейшей разработке ПС являются необходимым условием использования метода сборочного программирования.

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

Следовательно, изменяется и ЖЦ. Процесс проектирования включает выбор готовых ПП, которые полностью или частично решают поставленную задачу, и решение проблем интерфейсов между компонентами. Если требуется дополнительная разработка новых и сложных ПС, то формируется частная задача, решаемая с применением традиционных методов программирования. Процесс кодирования упрощается (отсутствует) при наличии готовых нескольких или всех необходимых компонентов. Основное внимание при этом уделяется комплексной отладке программных объектов, созданных из готовых компонентов. Главные направления процесса объединения накопленных в этих базах знаний разноплановых программных ресурсов – развивающиеся современные методы программирования.

1.1.2. СОВРЕМЕННЫЕ МЕТОДЫ ИНТЕГРАЦИИ ПРОГРАММНЫХ

ОБЪЕКТОВ

Наряду с рассмотренными методами интеграционного типа сформировались и другие, которые используют готовые компоненты в процессе создания ПС методами сборочного типа путем комплексирования, интеграции, композиции и др. К ним относятся современные широко применяемые подходы, а именно, объектно-ориентированный, компонентный, генерирующий, аспектный, агентный и др. (табл.1.2).

Рассмотрим современные виды программирования с элементами интеграции – комплексирование, синтез, генерация.

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

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

Класс - по сути дела это тип объекта, в котором кроме данных (свойств, параметров объекта), содержатся методы их обработки. Объект относительно своего класса является экземпляром. Класс определяет структуру и функциональность (поведение), одинаковую для всех экземпляров данного класса.

Один класс отличается от других набором поддерживаемых интерфейсов, т.е.

набором сообщений, которые посылаются объектам.

Экземпляр обладает состоянием, меняющимся в соответствии с поведением, заданным классом. Объекты могут обмениваться между собой сообщениями, по.

которым запускается соответствующий ему метод. Если метод для обработки сообщения не найден, то сообщение перенаправляется объекту-предку.

Основные принципы ООП такие:

наследование – механизм установления отношений «потомок–предок»

(возможность порождать один класс от другого с сохранением всех свойств и методов класса-предка);

инкапсуляция – свойство сокрытия реализации класса;

абстракция – описание взаимодействия объектов в терминах сообщений/событий;

полиморфизм – возможность замены объектов одного объекта другим объектом со сходной структурой.

Многие современные языки (Smalltalk, С++, Java, Python, PHP, Object Pascal, Delphi и др.) включили в себя понятие класса и другие принципы ООП.

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

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

анализ – создание объектной модели (ОМ) ПрО, в которой объекты отражают реальные ее сущности и операции над ними;

проектирование – уточнение ОМ с учетом описания требований для реализации конкретных задач системы;

программирование – реализация ОМ средствами С++, JAVA и др.

сопровождение – использование, развитие системы, внесение изменений, как в состав объектов, так и в методы их реализации;

модификация ПС – изменение системы в процессе ее сопровождения путем добавления новых функциональных возможностей, интерфейсов и операций.

Приведенные процессы могут выполняться итерационно друг за другом и с возвратом к предыдущему. На каждом из них может использоваться одна и та же система нотаций.

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

Результат процесса анализа ЖЦ – модель ПрО и набор других моделей (модель архитектуры, модель окружения и использования), полученных на процессах ЖЦ. Они отображают связи между объектами, их состояния и набор операций для динамического изменения состояния других объектов, а также взаимоотношения со средой. Объекты инкапсулируют информацию об их состоянии и ограничивают к ним доступ. Модель окружения и использования системы – это две взаимно дополняющие друг друга модели связи системы со средой.

Модель окружения системы – это статическая модель, которая описывает другие системы из пространства разрабатываемого ПО, а модель использования системы – это динамическая модель, которая определяет взаимодействие системы со своей средой.

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

Основные модели системной архитектуры такие:

– статическая модель описывает статическую структуру системы в терминах классов объектов и взаимоотношений между ними (обобщения, расширения, использования и др.);

– динамическая модель представляет динамическую структуру системы и взаимодействие между объектами системы в процессе выполнения.

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

Компонентно-ориентированная разработка (Component-Based Development – CBD). Это самостоятельная методология, появление которой наряду с модульной технологией связано с такими тенденциями в программировании [132, 133]:

– переход к распределенным вычислениям и обработке информации, при которых различные вычислительные процессы выполняются на разных компьютерах и средах, для их разработки применяются разные ЯП и механизмы взаимодействия между собою отдельных программных объектов;

– широкое распространение готовых компонентов разного назначения и их применение в процессе разработки новых ПС при условии соответствия определенным требованиям к структуре, интерфейсам и правилам интеграции;

– визуализация типовой структуры объектов и их интерфейсов, проверка возможности их применения в целях генерации и связывания в единое целое.

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

Особенность компонентной разработки – применение компонентов на всех процессах ЖЦ. Иными словами, все элементы и объекты компонентной разработки – это модули, компоненты, программы, данные и т.п., представляемые программными компонентами.

Использование компонентов в программировании имеет ряд преимуществ:

– снижение затрат на разработку ПС;

– сокращение времени разработки отдельных компонентов;

– улучшение показателей качества и надежности программ из компонентов;

– упрощение процедур и снижение затрат на поддержку и сопровождение программных продуктов;

– создание определенной инфраструктуры в разработке ПС, основанной на унификации и стандартизации компонентов в целях практического применения;

– создание рыночных компонентов за счет их стандартизации и ориентации на повторное использование.

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

В компонентной CBD разработке обеспечен механизм взаимодействия компонентов через контракт, в котором определены правила взаимодействия с другими компонентами, входящими в контейнер или каркас.

Интеграция (сборка) компонентов и их развертывание с среде не зависят от ЖЦ разработки компонентов. Замена любого компонента новым компонентом не должна приводить к перекомпиляции или перенастройке связей в ПС.

Интерфейс компонента может быть определен в виде спецификации точек доступа к компоненту, используя которые, клиент получает сервис в клиентсерверной среде. Так как интерфейс не предоставляет реализацию операций, то можно изменять реализацию без изменения интерфейса и таким образом улучшать исполнительные или функциональные свойства компонента без перестройки ПС в целом, а также прибавлять новые интерфейсы (и реализацию) без изменения существующей реализации ПС.

Семантика интерфейса может быть представлена с помощью контрактов, которые определяют внешние ограничения и поддерживают компонент-инвариант.

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

Контракты и интерфейс связаны между собою, но содержат разные сущности.

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

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

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

Артефактом может быть реальная порция информации, создаваемая при выполнении деятельности, связанной с разработкой ПС систем различного назначения, в частности промежуточные продукты процесса разработки ПС:

требования, постановки задач, заготовки программ, программы, комплексы, системы и т.п. Ими также могут быть: спецификации, модели, архитектура, каркас (framework) и т.п., а также готовые ПС.

Для объединения разных видов компонентов применяются шаблоны развертывания, которые сохраняются в скрытой части абстракции компонента. К спецификации компонента могут прибавляться новые шаблоны интеграции или изменяться старые. В некоторых классах КПИ параметры интеграции в новую среду включаются в интерфейс компонента, что сужает круг задач компонента для его повторного использования. Интеграция компонентов в архитектуру целевой ПС в CBSE состоит из нескольких типичных методов объединения, среди которых наибольшее распространение получили паттерны, каркасы и контейнеры [8, 26].

Паттерн – абстракция, которая содержит описание взаимодействий совокупности объектов, ролей участников и их ответственности. Он практически определяет повторяемое решение в проблеме объединения КПИ в программную структуру. Для каждого объединения определяется взаимодействие объектов при совместной кооперативной деятельности с заданием абстрактных участников, их ролей, распределения полномочий (или обязанностей). Паттерны классифицируются по трем уровням абстракции:

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

– средний уровень абстракции уточняет структуру, поведение отдельных подсистем и компонентов ПС, а также взаимодействие между ними;

– нижний уровень представляет собой абстракцию определенного вида (например, объединение компонентов по аналогии), которая зависит от выбранной парадигмы и ЯП.

Кроме паттернов, в сборочной стратегии широко используется каркас – типовая повторно возникающая ситуация на уровне модели ПС, которая определяет структуру проекта и имеет недоопределенные элементы, обозначенные пустыми слотами для расположения в них новых определенных компонентов. В этом смысле каркас становится КПИ со свойством экземпляризации и представленный высокоуровневой абстракциею проекта ПС, в которой отделены функции компонентов от задач управления ими. В бизнес-функциях каркас задает надежное управление ими. Каркас объединяет множество взаимодействующих между собою объектов в некоторую интегрированную среду, предназначенную для решения заданной конечной цели типа “белый” или “черный ящик”.

Каркас типа “белый ящик” включает в себя абстрактные классы для представления цели объекта и его интерфейсов. При реализации эти классы наследуются в конкретные классы с указанием соответствующих методов реализации, как это принято в OOП. Каркас типа «черный ящик» характеризуется тем, что в видимой, информационной, части имеется описание точек входа и выхода. Через эти точки можно входить и выходить из компонента не обязательно через конечный оператор. Таким образом, каркас определяет контекст интеграции отдельно построенных программных частей. Физически он реализуется с помощью одного или больше паттернов, которые в свою очередь выступают в роли инструкций по реализации проектных решений.

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

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

Схема модели компонентной системы представлена на рис. 1.3 [6].

Компонентные типы и контракты Здесь: 1 – компонент, имеющий функциональность; 2 – один или более интерфейсов, описанных внутри контракта; 3 – контрактное взаимодействие компонентов друг с другом; 4 – развертывание компонентов во время выполнения в заданной среде; 5 – разные типы компонентов системы; 6 – компонентная модель из множества типов компонентов, их интерфейсов; 7 – спецификаций шаблонов взаимодействия этих компонентов; 8 – компонентный каркас обеспечивает выполнение компонентной модели, множество сервисов.

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

Порождающее программирование. Данное программирование ориентировано на создание семейств программных систем путем трансформации описания членов семейства спецификациями высокого уровня типа языка DSL (Domain Specific Language) с отображением специфики предметной области в терминах соответствующей базовой терминологии. Результат последовательной трансформации генерируется и собирается в выходной код [142, 204].

Его основа – общая порождающая доменная модель GDM (Generative Domain Model) семейства систем. В ней содержатся:

– описание членов семейства в языках (DSL, RSL, CSP, Clear и др.);

– компоненты реализации функций членов семейства и их характеристики;

– знания о конфигурации (Configuration knowledge) в виде правил конструирования, вариантов оптимизации, сочетания и зависимости между членами семейства и др.;

– модель общих, изменяемых характеристик членов семейства и их взаимодействия;

– механизмы обеспечения изменчивости, синхронизации и безопасности как компонентов, так и членов семейства средствами описания связывающих аспектов.

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

Каждая модель члена семейства представляется в некотором конкретном синтаксисе, например DSL, XML, UML и др., которая трансформируется к выходному целевому представлению по следующей схеме (рис.1.4) [185]:

– преобразование исходной модели к промежуточному (объектному) виду;

– преобразование исходной модели в выходную (целевую);

– преобразование целевой модели в конкретный код.

Парсер конкретного синтаксиса Дерево абстрактного синтаксиса Дерево абстрактного синтаксиса Генерация выходного кода осуществляется такими способами:

– итеративным, при котором перечисляются все узлы исходной модели и они преобразуются в соответствующее представление целевой модели;

– шаблонным, позволяющим вставлять макросы, т.е. участки кода в любую часть заданного шаблона;

– поисковым, состоящим в нахождении места в исходной модели и ее преобразования.

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

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

Генерация исполняемого кода осуществляется посредством:

– использования шаблонов проектирования;

– сохранения сгенерированного и исправленного вручную (рукописного кода) в отдельных файлах;

– дизайна архитектуры системы, в которой определены сгенерированные артефакты;

– использования гибких методик склеивания сгенерированных и рукописных частей кода.

Интеграция (сборка) сгенерированного кода и рукописного состоит в написании вручную программ для незаполненных участков шаблона путем вставки.

Моделирование в UML. Основу составляет стандартный язык UML lkz моделирования программ. Язык предназначен для визуализации, спецификации, конструирования и документирования артефактов ПС. Описание программ в этом языке осушествляется с помощью стандартных диаграмм, словаря и механизмов расширения.

Словарь UML содержит три категории элементов: предметы (things), связи (relationships) и диаграммы (diagrams). Предметы имеют такие разновидности:

структурные ( use case, class, active class, interface, component, collobaration, node);

поведенческие ( interaction, state machine); групповые (package, model, subsystem, framework); аннотационные (note). Связи различаются как зависимые (dependency), ассоциативные (association) и те, которые обеспечивают обобщение (generalization).

В состав диаграмм входят: class, use case, object, sequence, component, colloboration, statechart, activity, deployment. Они используются для графического изображения соответствующих элементов ПС. Графические нотации – это наглядные структуры, которые задают представление предметов, связей и механизмов расширения языка UML. Механизмы расширения предназначены для уточнения синтаксиса и семантики языка и включаютв себя: стереотипы и констрейны. Метод UML включает в себя:

– формальную метамодель для описания синтаксиса и семантики, а также для унификации разных аспектов проектирования объектных приложений;

– совокупный набор нотаций графического представления объектов проектирования;

– множество разнообразных идиом для отображения конкретной модели ПС.

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

– создание среды разработки ПС в UML с помощью сценариев и шаблонов проектирования;

– проектирование модели интеграции ПС и системы образцов средствами UML;

– выбор метрик и методов оценивания показателей качества объектов в проектируемой системе;

– модификация моделей с учетом функциональных и нефункциональных требований к системе;

– изменение системы путем повторного использования КПИ и методик преобразования передаваемых данных;

– проверка поведения системы осуществляется после выполнения разного рода преобразований;

– обеспечение целостности модели путем внесения изменений в модель.

Иными словами, модели в UML, а также модели, спроектированные на языке SDL, трансформируются специальными утилитами для исполняемого кода.

Инсерционное программирование. Термин «инсерционное» происходит от английского insert – вставить, поместить, погрузить. Имеется в виду вставка в программу или среду объекта, называемого агентом. Агент обладает поведением и погружается в информационную среду, которая меняет ее поведение относительно других агентов этой среды [147, 148]. Описание инсерционной программы состоит в определении функции погружения, начального состояния среды и агента, погруженного в эту среду. Поведение среды меняется в результате воздействия на расположенные в ней объекты взаимодействующих агентов.

Основа инсерционного программирования – модель поведения агентов в средах, базирующихся на понятиях транзиционной системы, теории взаимодействующих процессов и отношений бисимуляционной эквивалентности агентов относительно среды. В отличие от агентного программирования, инсерционное программирование ориентируется исключительно на поведение агентов.

Представление состояний агентов и сред как структур данных, а также функций погружения осуществляется средствами алгебраического программирования АPS [147]. Инсерционная программа описывается на языке AL и имеет три уровня:

– описание поведения инициализированной многоуровневой среды с расположенными в ней агентами;

– задание функции, определяющей отношения переходов агентов;

– описание ядра функции погружения или развертывания агентной программы.

Инсерционными программами моделируются реальные системы с недетерминированным поведением агентов и сред. Реализация систем инсерционного программирования требует применения программ-симуляторов, а не интерпретаторов, а также постановки целей для получения конкретных результатов.

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

1.2. ОСНОВНЫЕ ЭЛЕМЕНТЫ И ЗАДАЧИ СБОРОЧНОГО

ПРОГРАММИРОВАНИЯ

Процесс сборки любых изделий характеризуется: комплектующими деталями и узлами, схемой сборки (взаимосвязями отдельных компонентов и правилами взаимодействия), сборочным конвейером (технологией сборки). Конкретизируем эти понятия с точки зрения метода сборочного программирования. При этом будем предполагать, что используются только готовые программные продукты [125, 133, 140].

Комплектующие элементы. Комплектующими в методе сборочного программирования являются простые программные элементы (модули, объекты, компоненты, сервисы и др. (табл.1.3).

Процедура, Идентификатор Непосредственное Библиотеки Программа Из них собираются программные объекты различной сложности и степени готовности: программы, комплексы, пакеты прикладных программ, программные системы и т.д.

Модуль – независимая функциональная часть программы, к которой можно обращаться как к самостоятельной единице через внешний интерфейс.

Объект – базовое понятие в объектно-ориентированном программировании, которое обладает свойствами наследования, инкапсуляции и полиморфизма.

Объединяет данные и операции (методы). Объекты взаимодействуют между собой через сообщения. Объекты с общими свойствами и методами образуют класс, являясь в нем экземплярами класса. В языке С++ имеется несколько библиотек классов общего применения.

Компонент – программный объект, который реализует некоторую функциональность и является базовым понятием компонентного программирования и компонентно-ориентированной разработки (component-based development – CBD).

Основная форма представления компонента – каркас и контейнер. Каркас – высокоуровневая абстракция, в которой функции отделены от задач управления.

Контейнер – оболочка, внутри которой реализованы функции в виде экземпляров компонентов, обеспечивает взаимодействие с сервером через стандартные интерфейсы (function, home interface). Экземпляры обращаются друг к другу через системные сервисы данного контейнера или другого.

Сервис – это программный ресурс, который реализует некоторую функцию, в том числе и бизнес функцию. Содержит независимый интерфейс с другими сервисами и ресурсами. Веб-сервис обеспечивает реализацию задач интеграции приложений разной природы и используется как провайдер. Совокупность взаимодействующих сервисов, веб-сервиса и их интерфейсов образует сервисноориентированную архитектуру (service oriented architecture), доступ к которым происходит через веб-языки и протоколы.

Результатом сборки может быть любой программный объект, за исключением элементарного элемента – модуля, компонента, сервиса и др. Однако для практического применения выбирается несколько базовых типов программных объектов, рассматривающихся как готовые компоненты, и результат использования метода сборочного программирования.

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

Важное условие сборки состоит в наличии большого числа разнообразных комплектующих, т.е. ПС, обеспечивающих решение широкого спектра задач из различных предметных областей.

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

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

Сборочный конвейер. Процесс сборки может производиться ручным, автоматизированным и автоматическим способами. Как правило, последний способ практически неосуществим, что связано с недостаточно формальным определением программных объектов и их интерфейсов. Ручной способ нецелесообразен, так как сборка готовых компонентов представляет собой большой объем действий, носящих скорее рутинный, чем творческий характер. Наиболее приемлемый – автоматизированный способ сборки в среде системы, которая по заданным спецификациям (моделям) программ осуществляет сборку с помощью стандартных правил сопряжения под управлением человека. Средства, поддерживающие данный способ сборки, называются инструментальными средствами сборочного программирования. К ним относятся средства комплексирования (объединения компонентов в более сложный объект); средства интерфейсов (реализация сопряжения объектов согласно их паспортам и стандартным правилам связи);

средства описания и использования моделей сборочного программирования (совокупность моделей сборки различных программных объектов).

Из рассмотренной схемы сборки выделим задачи сборочного программирования и условия его применения:

– выбор компонентов из числа готовых программных объектов для обеспечения процесса решения класса задач из определенной предметной области;

– проектирование структуры (моделей) создаваемого объекта, элементами которого являются готовые программные элементы, определенные на множестве данных выбранной предметной области;

– сборка согласно моделям программного продукта, реализующего функции, соответствующие целям и задачам автоматизируемой предметной области.

Необходимые условия применения данного метода программирования включают в себя:

– наличие большого числа разнообразных программных продуктов, как объектов сборки;

– паспортизация программных объектов сборки;

– наличие достаточно полного набора стандартных правил сопряжения и алгоритмов их реализации и средств автоматизации процесса сборки;

– создание технологий применения разработанных объектов для использования в более сложных программных продуктах.

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

Основной вопрос сборки – это реализация интерфейсов между отдельными модулями и/или компонентами, обеспечивающими их «стыковку» или связь.

1.3. ОПРЕДЕЛЕНИЕ ИНТЕРФЕЙСА ПРОГРАММНЫХ ОБЪЕКТОВ

Общее определение. Интерфейс – это связь двух отдельных сущностей. Виды интерфейсов: программные, аппаратные, языковые, пользовательские, цифровые и т.п. Программный (API) и/или аппаратный интерфейс (port) – это способы преобразования входных/выходных данных во время объединения компьютера с периферийным оборудованием. Языковый интерфейс определяет константы, переменные, параметры и структуры данных программы в некотором ЯП, которые передаются другим программам или модулям [116, 127, 132].

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

Когда один из элементов – программа, процедура или функция записаны на разных ЯП и, кроме того, если они располагаются на разных компьютерах, то возникают проблемы неоднородности представления типов данных параметров в этих ЯП, структур памяти платформ компьютеров, компиляторов и операционных сред их выполнения.

Понятие интерфейса, как самостоятельного объекта, сформировалось в связи со сборкой или объединением разноязыковых программ и модулей в одну монолитную систему на больших ЭВМ (mainframes), память которых позволяла получать программы соответственно до 100–200тыс. команд и более.

Интерфейс играет роль посредника по передаче информации от вызываемого модуля вызывающему, записанные на разных ЯП. В нем дано описание формальных и фактических параметров, произведена проверка соответствия передаваемых параметров (количества и порядка расположения), а также типов данных параметров. Если типы данных параметров оказывались не релевантными (например, передается целое, а результат функции – вещественное, или наоборот), то в посреднике необходимо произвести прямое и обратное преобразование передаваемых типов данных с учетом структуры памяти их компьютеров.

На рис.1.5. приведена схема некоторой программы С, в которой содержатся два оператора вызова – Call A ( ) и Call B ( ) с некоторыми параметрами, которые первоначально передаются интерфейсным посредникам A’ и B’. В них проводится преобразование данных к нужному виду модулей А, В и их передача для выполнения. После обработки этих данных результаты выполнения проходят данную схему в обратном порядке. Данные, полученные в модулях А и В, преобразуются в интерфейсных посредниках A’ и B’ к соответствующему виду их описания в программе С.

Рис. 1.5. Схема вызова модулей А и В через интерфейсы А` и B` Интерфейс, как способ передачи информации, используется в разных видах программирования с некоторыми особенностями и различиями. Приведем их.

Интерфейс и ООП Главный элемент ООП – класс. Интерфейс описывает поведение класса объектов. Класс поддерживает несколько интерфейсов, которые содержат операции. Интерфейс – это множество операций, которые используются для определения услуг класса или компонента (рис.1.6), именует это множество операций или определяет их сигнатуру и результирующие действия.

– защищенные, доступные классу и – частные, доступные классу.

Рис.1.6. Структура представления класса и интерфейса Если интерфейс реализуется с помощью класса, то он наследует все операции интерфейса. Одни и те же операции могут появляться в различных интерфейсах.

Если их сигнатуры совпадают, то они задают одну и ту же операцию, соответствующую поведению системы.

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

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

Сеть строится на основе стандартной семиуровневой модели открытых систем OSI (Open Systems Interconnection). Объекты этих уровней связываются между собой по горизонтали и вертикали. Запросы от приложений поступают на уровень представления данных этой модели для их кодирования (перекодирования) к виду используемой платформы. Открытые, распределенные системы предоставляют разным приложениям услуги по обработке интерфейсов, управлению удаленными объектами, обслуживанию очередей и запросов и т.п.

Интерфейс программных объектов может задаваться одним из способов:

– вызов удаленных процедур RPC (Remote Procedure Call) в системах ОNС SUN, OSF DSE [5, 133];

– связывание распределенных объектов и документов в системе DCOM;

– взаимодействие объектов, интерфейс которых описывается в языке IDL (Interface Definition Language) и обрабатывается брокером объектных запросов ORB (Object Request Broker) в системе CОRBA [166];

– удаленный вызов RMI (Remote Methods Invocation) в системе JAVA для объектов, описанных в языках JAVA, Паскаль, C++, C# [25, 191] и др.

RPC– вызов задает интерфейс удаленных компонентов в языках высокого или низкого уровней. На языке высокого уровня RPC–вызов передается с помощью сообщения, содержащего параметры для удаленной процедуры. В языке низкого уровня в сообщении указывается более подробная информация: тип протокола, размер буфера данных и т.п.

Взаимосвязь одного процесса с удаленно расположенным от него другим процессом (например, сервером) на другом компьютере можно выполнить также протоколами UDP или TCP/IP. В них посредник stub передает интерфейс от компонентов клиента серверу с параметрами, которые обеспечивают выполнение удаленной серверной процедуры.

Механизм посылки запроса в системе CORBA – это описание запроса в языке IDL для посредника stub/skeleton и передача его протоколом IIOP или GIOP брокеру ORB. Запрос обрабатывается в среде брокера через stub/ skeleton сервером объектного сервиса (Common Object Services) или общими средствами (Common Facilities) системы CORBA. Брокер реализован в разных распределенных системах (CORBA, COM, SOM, Nextstep и др.) и предназначен для обеспечения взаимодействия объектов, которые располагаются в разных сетевых средах.

Вызов метода RMI в системе JAVA выполняет виртуальная машина VM (virtual machine), которая интерпретирует byte–коды компонентов, созданных разными системами программирования с ЯП (JAVA, Pascal, С++) на компьютерах.

Функции RMI в этой системе аналогичны функциям брокера ORB.

Описание интерфейса объектов в распределенных средах В промежуточной среде рассмотренных систем реализуется два способа связывания объектов: на уровне ЯП через интерфейсы прикладного программирования и компиляторов IDL, которые генерируют клиентские и серверные stub. Интерфейсы определяются в IDL или APL, а динамический вызов осуществляет ORB для объекта-клиента и объекта-сервера. Эти интерфейсы имеют отдельную реализацию на ЯП и доступны из программ, записанных в разных ЯП. Компиляторы IDL, как часть промежуточного слоя, сами реализуют связывание с соответствующим языком программирования ЯП механизма ссылок.

Интерфейс в IDL или в API обеспечивает взаимодействие компонентов на основе описания их формальных и фактических параметров и порядка задания операций передачи параметров для получения результатов. Это описание – ничто иное, как спецификация интерфейсного посредника двух разноязыковых объектов, которые взаимодействуют между собой через механизм вызова интерфейса и могут выполняться на разных процессах сервера или клиента.

В функции интерфейсного посредника клиента входят:

– подготовка внешних параметров клиента для обращения к сервису сервера, – посылка параметров компонента серверу, его выполнение для получения результата или выдача сведений об ошибках.

Общие функции интерфейсного посредника сервера состоят в следующем:

– получение сообщения от клиента, запуск удаленной процедуры, вычисление результата и подготовка его для передачи клиенту;

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

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

Демаршалинг данных – это обратное преобразование данных (полученного результата) к виду передавшей клиентской программы. Если среди передаваемых параметров оператора вызова содержатся нерелевантные типы или структуры данных, которые не соответствуют параметрам вызванного объекта, то производится их преобразование. Стандарт ISO/IEC 11404–2007 регламентирует описание общих типов данных, которые могут использоваться любыми современными ЯП [133, 134].

К средствам преобразования данных и их форматов также относятся:

– стандарты кодировки данных (XDR – eXternal Data Representation, CDR – Common Representation Data [4]), NDR – Net Data Representation) и методы их преобразования;

– ЯП и механизмы обращения компонентов друг к другу;

– языки описания интерфейсов – RPC, IDL и RMI.

На каждой платформе компьютера используются соглашения о кодировке символов (например, ASCII), о форматах целых чисел и чисел с плавающей точкой (например, IEEE, VAX и др.). Для представления целых, как правило, используется дополнительный код, а для типов float и double – стандарт ANSI / IEEE и др.

Порядок расположения байтов зависит от структуры платформы (Big Endian или Little Endian) и от старшего к младшему байту и от младшего байта к старшему. Процессоры UltraSPARC и PowerPC поддерживают обе возможности.

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

XDR-стандарт содержит язык описания структур данных произвольной сложности и средства преобразования данных, передаваемых на платформы (Sun, VAX, IBM и др.). Программы, написанные в ЯП, могут использовать данные в XDR-формате, несмотря на то, что компиляторы выравнивают эти данные поразному в памяти машины. В XDR-стандарте целые числа с порядком "от младшего" приводятся к порядку байтов от «старшего» и обратно. Преобразование данных – это кодирование (code) или декодирование (decode) простых и сложных типов данных. Кодирование – это преобразование из локального представления в XDR-представление и запись в XDR-блок. Декодирование – это чтение данных из XDR-блока и преобразование в локальное представление заданной платформы.

Выравнивание данных – это размещение значений базовых типов с адреса, кратного действительному размеру в байтах (2, 4, 8, 16). Границы данных выравниваются по наибольшей длине (например, 16). Системные процедуры оптимизируют расположение полей памяти под сложные структуры данных и преобразуют их к формату принимающей платформы. Обработанные данные декодируются обратно к виду формата платформы, отправившей эти данные.

CDR-стандарт в среде CORBA обеспечивает преобразование данных в форматы передающей и принимающей платформ. Маршалинг данных выполняет интерпретатор Type Code и брокер ORB. Процедуры преобразования сложных типов включают в себя:

– дополнительные коды для представления целых чисел и чисел с плавающей точкой (стандарт ANSI / IEEE);

– схему выравнивания значений базовых типов в среде компилятора;

– базовые типы (signed и unsigned) языка IDL и плавающий тип двойной точности и др.

Преобразование данных выполняются процедурами encoder ( ) и decoder ( ) интерпретатора TypeCode, который используют базовые примитивы при выравнивании информации и помещении ее в буфер. Для сложного типа вычисляется размер и границы выравнивания, а также их размещение в таблице с индексами значений, используемых при инициализации ORB.

ХМL-стандарт предназначен для устранения неоднородности во взаимосвязях компонентов в разных ЯП с помощью XML-формата данных, учитывающего разные платформ и среды. Промежуточные среды (CORBA, DCOM, JAVA и др.) имеют в своем составе специальные функции, аналогичные XML и обеспечивают взаимосвязь разноязыковых программ. XML имеет различные системные поддержки: браузер – Internet Explorer для визуализации документов, объектная модель DOM (Document Object Model) для отображения XML– документов и интерфейс IDL в системе CORBA. Для перехода ПС к XML осуществляется переформатирование данных системы в формат XML и обратно.

Иными словами, XML – средство представления объектов для разных объектных моделей на единой основе. Он не зависит от платформы и среды модели взаимодействия компонентов прикладного уровня, упрощает обработку документов, работу с БД с помощью средств (XML-парсеры, DOM-интерфейсы, XSL-отображение XML в HTML и др.).

Общая схема связи ЯП в распределенной среде Характерная особенность ЯП в распределенных средах – неоднородность как в смысле представления типов данных, так и платформ компьютеров, где реализованы соответствующие системы программирования из множества языков L1,…, Ln. Причина неоднородности, как это указывалось выше, это различные способы передачи параметров объектам для разных сред, разнообразие объектных моделей, разных видов удаленного вызова модулей в современных ЯП (рис.1.7).

Системы программирования с ЯП имеют следующие особенности:

– различающиеся двоичные представления результатов компилирования для одного и того же ЯП на разных компьютерах;

– двунаправленность связей между ЯП и их зависимость от среды и платформы;

– отображение параметров вызовов объектов в операции методов;

– связь с разными ЯП через ссылки на указатели в компиляторах;

– связь ЯП через интерфейсы каждой пары модулей во множестве L1, …, Ln промежуточной среды.

Иными словами, связь между различными языками L1,…, Ln осуществляется через интерфейс каждой пары Li, Lj, взаимодействующих между собой с помощью соответствующих конструкций языка Li, операций интерфейса и наоборот.

Принципы взаимодействия ЯП в среде CORBA Основной принцип взаимодействия объектов в среде CORBA – это запрос от клиента для выполнения метода объекта через интерфейс. Взаимодействие ЯП производится путем отображения типов данных модулей в типы данных клиентских и серверных стабов (stub) средствами брокера ORB.

Для всех ЯП системы CORBA (С++, JAVA, Smalltalk, Visual C++, COBOL, Adaпредусмотрен общий механизм связи и расположения параметров для методов объектов в промежуточном слое [25, 166]. Связь между объектными моделями каждого ЯП системы СОМ и JAVA выполняет брокер ORB (рис.1.8).

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

В случае вхождения в состав модели CORBA объектной модели JAVA/RMI, вызов удаленного метода объекта осуществляется ссылками на объекты, задаваемые указателями на адреса памяти.

Интерфейс как объектный тип реализуется классами и предоставляет удаленный доступ к нему сервера. Компилятор JAVA создает байт-код, который интерпретируется виртуальной машиной, обеспечивающей переносимость байткодов и однородность представления данных на всех платформах среды СORBA.

1.4. ПРЕДСТАВЛЕНИЕ ЗНАНИЙ О ПРЕДМЕТНЫХ ОБЛАСТЯХ

Сложились устойчивые понятия о методах представления и использования знаний:

продукционные правила; фреймы; семантические сети; исчисление логики предикатов; нечеткие знания. Данные методы неприменимы в методе сборочного программирования, несмотря на то, что существуют языки представления знаний, которые одновременно являются и языками программирования (например, Пролог, Лисп и др.) В сборочном программировании знания о задачах предметной области встроены в алгоритмы самих модулей, компонентов, ПС и т.п. Промышленный подход к процессу сборки требует еще дополнительные знания, связанные с правилами их объединения в разные конфигурации для решения задач ПрО. Этот процесс соответствует выбору готовых деталей, стыковки их в некоторые мелкие технические узлы, а из них сборке в более крупные части изделия. Каждая деталь имеет конструкторскую документацию, включающую в себя документацию на комплектующие сборки и на результирующий продукт. Аналогично используются объекты и в сборочном программировании. Формой представления знаний об элементарных объектах является их описание в ЯП, а знаний о результатах сборки – более сложные структуры программ и ПС, приобретенные в процессе сборки.

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

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

Возвратимся к формам представления ПС как знаний. Знания об элементарных объектах сборки включают в себя спецификации, исходные тексты на ЯП, описания данных (при работе с внешними файлами и базами данных), процедуры на языках управления заданиями для вызова ПП и т. д. Дополнительные знания, полученные в процессе сборки, представляются в виде совокупности моделей и программных интерфейсов сопряжения отдельных компонентов.

Автоматизированный подход к сборке ПП позволяет упорядочить процесс приобретения новых знаний на основе применения специальных средств описания и обработки моделей, а также генерации интерфейсов согласно набору стандартных правил. Эти средства – основа создания технологий применения разработанных ПП для их использования в более сложных программных продуктах. Каждый ПП в рамках сборочного программирования (с соответствующими средствами автоматизации) создается на единой методологической основе и без существенных изменений может использоваться в других процессах сборки.

На современном этапе развития программирования в качестве базы знаний выступают репозитарии, каталоги информационных систем, ресурсы Интернета и др.

Их рассмотрению посвящены специальные разделы данной работы.

Представление знаний о готовых программных ресурсах. В настоящее время главные ресурсы – это КПИ и разные атрефакты проектирования, полученные на более ранних процессах ЖЦ при создании ПС. Они недостаточно используются, как готовые, и потому в рамках научного проекта института созданы новые подходы, модели и методы их системного описания и сохранения в репозитарии компонентов, упорядоченных по разным предметным областям ПИ.

Представленные знания обеспечивают более широкое их применение и дают значительное сокращение сроков и стоимости создания новых ПС.

Эти знания, заданные в репозитарии, обеспечивают сохранение, локализацию знаний о КПИ, их нахождение и контроль логической связанности, целостности и согласованности представленных в них знаний.

Для адекватного раскрытия семантики; описания разных параметров и аспектов функционирования КПИ разработана концепция многоаспектного представления знаний о КПИ в виде онтологической модели, как способа стандартизированного описания разных свойств и возможностей современных программных ресурсов, накопленных в разных хранилищах и библиотеках Интернета, в частности и в построенном нами репозитарии.

Данная модель практически реализована в диссертационной работе [19–21] и задается графовой структурой с концептами домена предметной области в вершинах и дугами, задающими отношениям между этими концептами. В КПИ концептами является информация о функциях, сервисах, интерфейсах, сценариях общения, вариантности развертки и т.п. На их основе можно провести аттестацию КПИ, изменить или добавить новы концепты, формулировать требования к новым ПС и по ним находить нужные КПИ, сопоставить найденные КПИ с теми, которые запрашивает пользователь и принимает решение о целесообразности их использования в новой разработке. В приложении 1 приведено краткое описание реализации онтологической модели на компьютере.

Вывод. В данной главе рассмотрен метод сборочного программирования на концептуальном уровне без конкретизации его составляющих. На общем уровне рассмотрена схема сборки программных объектов, компоновки и генерации разных программных ресурсов на основе модельного подхода. В последующих главах уточняется их содержание применительно к разным видам объектов (модулей и компонентов) и правила их сопряжения. Описывается несколько практических реализаций, приводятся методики применения данного метода, дано описание концепции развития и совершенствования сборки в среде компонентного и генерирующего программирования.

ОБЩИЕ ВОПРОСЫ РЕАЛИЗАЦИИ МЕТОДА

СБОРОЧНОГО ПРОГРАММИРОВАНИЯ

2.1. МЕТОДЫ КОМПЛЕКСИРОВАНИЯ ПРОГРАММНЫХ ОБЪЕКТОВ