ТРПО_теория / Lect_trpo / lavrishcheva_petrukhin

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

Описание интерфейса в IDL-языке начинается с ключевого слова interface, за которым следует: идентификатор интерфейсного посредника, описание типов параметров и операций вызова объектов.

Общая структура описания интерфейса имеет вид interface A { ... }

interface B { ... } interface C: B,A { ... }.

Параметрами операций (op_dcl) в задании интерфейсов могут быть такими:

–тип данных (type_dcl);

–константа (const_dcl);

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

–атрибуты параметров (attr_dcl).

Описание типов данных начинается ключевым словом typedef, за которым следует базовый или конструируемый тип и его идентификатор. В качестве константы может быть некоторое значение типа данного или выражение, составленное из констант. Типы данных и констант могут быть: integer, boolean, string, float, char и др.

Описание операций op_dcl включает в себя:

–наименование операции интерфейса;

–список параметров (от нуля и более);

–типы аргументов и результатов, если они имеются (иначе - void);

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

Атрибуты параметров могут начинаться служебными словами: in – при отсылке параметра от клиента к серверу;

out – при отправке параметров-результатов отсервера к клиенту;

inout – при передаче параметров в оба направления (от клиента к серверу и обратно).

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

const long l=2 interface A {

void f (in float s [l]); } interface B {

const long l=3 } interface C: B, A { }.

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

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

151

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

Общая структура описания модуля в языке IDL с интерфейсом приведена ниже:

Regust Operations module CORBA { interface Reguest { Status add-arg (

in Identifier name, in Flags arg_flags

);

Status invoke (

in Flags invoke_flags // invocation flags );

Status send(

Status get_respouse (

out Flags response_flags // response flags );

};

};

Предложенный язык описания интерфейса объектов содержит средства общие с языком описания интефейсов IDL.

6.5. Инженерия приложений и предметной области

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

Прикладная инженерия – это инженерия ПИК и процесс создания ПС из готовых компонентов и ПИК.

Инженерия ПрО ориентирована на создание архитектуры ПрО - каркаса (фреймворка), представленной ПИК, компонентами многоразового применения из семейства программ ПрО и их интерфейсов.

Основными этапами инженерии ПрО являются:

–анализ ПрО и выявление объектов и отношений между ними;

–определение области действий объектов ПрО;

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

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

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

–генерация отдельного домена, члена семейства и ПС в целом.

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

152

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

Инженерия ПрО включает в себя следующие вспомогательные процессы:

–корректировка процессов для разработки решений на основе ПИК;

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

операций, выполняемых, как правило, вручную;

–разработка инфраструктуры ПИК – описание, хранение, поиск, оценивание и объединение готовых ПИК;

–создание репозитария ПИК и компонентов многоразового использования в классе задач ПрО (рис.6.2);

–обеспечение безопасности, защиты данных, изменений;

–обеспечение синхронизации и взаимодействия компонентов и ПИК.

РЕПОЗИТАРИЙ

ПрО

Рис.6.2. Структура репозитария в интегрированной среде ПрО

Архитектурное проектирование домена (Domain design) – это определение архитектуры домена на основе программных компонентов – специфичных активов/ ресурсов.

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

Технология доменной инженерии базируется на новом процессе в модели ЖЦ

(ISO/IEC 12207) и включает в себя стандартизированные подпроцессы:

– формировання ресурсров (Asset provision) – разработка или приобретение ресурсов (активов), которые могут использоваться при компоновки нових программных систем или подсистем.

– разработка базы ресурсов (asset–based development), в основе которой лежит концепция повторного использования (software reuse) – ПИК, обеспечивающая компоновку программных продуктов домена;

153

– сопровождение ресурсов (Asset maintenance) – модификация и эволюция модели, архитектуры и продуктов домена за счет готовых ресурсов типа ПИК.

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

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

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

6.6. Инженерия оценивания стоимости реализации ПрО из компонентов

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

Общую стоимость создания компонентной системы будем считать, состоящую из таких составных элементов:

С = С1 + С2 + С3 + С4 ,

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

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

Рассмотрим отдельно каждую составную единицу стоимости ПС.

Стоимость анализа функций ПрО имеет вид

где С2 (Fji ) – стоимость поиска ПИК для функции Fi , сформулированной на этапе анализа ПрО, N – количество новых компонентов и ПИК, C2(PFji) – стоимость разработки некоторых типичных программных компонентов,

1, когда j– компонент используется функцией Fi , 0, в противном случае.

154

Стоимость композиции компонентов определяется следующим образом:

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

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

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

Литература к теме 6.

1.Бабенко Л.П., Лаврищева Е.М. Основы программной инженерии (укр.).– Киев,

Знання. –2001.–269с.

2.Грищенко В.Н., Лаврищева Е.М. Методы и средства компонентного пограммирования//Кибернетика и системный анализ, 2003.– №1.– с.39–55.

3.Jacobson I., Griss M., Jonsson P. Software Reuse.–N.Y.:Adison Wesley, 1997.

4.Сrnkovik I, Larsson S., Stafford J. Component-Based Software Engineering: building systems from Components at 9th Conference and Workshops on Engineering of Computer – Based Systems.- Software Engineering Notes.-2002.- vol.27.-N 3.-c.47-50.

5.К.Чернецки, У.Айзенекер. Порождающее программирование. Методы, инструменты, применение.– Издательский дом «Питер».– Москва– Санкт-Петербург… Харьков,

Минск.– 2005.–730с.

6.Meyer B. On to Components. Computer. – vol. 32, N 1, January 1999. – pp.139–140.

7.Lowy J. COM and .NET Component Services. - O'Reilly, 2001. – 384 p.

8.Batory D., O'Malley S. The Design and Implementation of Hierarchical Software Systems with Reusable Components/ ACM Transactions on Software Engineering and Methodology.

– N 4, vol. 1, October 1992. – pp.355–398.

155

9.Weide B., Ogden W., Sweden S. Reusable Software Components/ Advances in Computers, vol. 33. – Academic Press, 1991. – pp.1–65.

10.Jacobson I., Griss M., Johnson P. Software Reuse: Architecture, Process and organization for Business Success – Addison Wesley, Reading , MA, May 1997.–501p.

156

Тема 7

МЕТОДЫ ВЕРИФИКАЦИИ И ТЕСТИРОВАНИЯ ПРОГРАММ И СИСТЕМ

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

Теоретические средства определяют процесс программирования и тестирования программного продукта. Это методы верификации и доказательства правильности составленной спецификации программ, метрики (Холстеда, цикломатичная сложность Маккейба и др.) измерения отдельных характеристик, и выступают они в роли формализованных элементов теории определения правильности и гарантии свойств конечного ПО. Например, концепция «чистая комната» базируется на некоторых формализмах доказательства и изучения свойств процессов кодирования и тестирования программ. Что касается тестирования, то это проверка спецификации нотаций программ, используемых при описании тестов и покрытия соответствующих критериев программ [1–7].

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

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

1. Формальное доказательство корректности программ осуществляется с помощью теоретических методов, основанные на задании формальных систем правил и утверждений, используемых при доказательстве правильности операторов программы и результатов их выполнения в режиме интерпретации [5, 8–11]. К средствам формальной проверки правильности относятся верификация и валидация ПС, которые вошли в состав регламентированных процессов ЖЦ стандарта ISO/IEC 12207.

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

3.Организационные аспекты проверки правильности.

Далее излагаются последовательно эти направления.

7. 1. Методы доказательства программ

Формальное математическое доказательство основывается на аксиомах, а сам процесс основывается на спецификации описания алгоритма доказываемой программы.

157

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

К методам проверки правильности программ относятся:

1)методы доказательство правильности программ;

2)верификация и аттестация программ.

7.1.1. Методы доказательства правильности программ

Эти методы появились в 80–е годы и разделяются на два класса:

1.Точные методы доказательства правильности программ.

2.Методы доказательства частичной правильности программ.

Наиболее известными точными методами доказательства программ являются метод рекурсивной индукции или индуктивных утверждений Флойда и Наура и метод структурной индукции Хоара и др. Эти методы основываются на утверждениях и пред и пост–условиях.

7.1.1.1. Общая характеристика формальных методов доказательства

Над этим направлением работали многие теоретики–программисты, некоторые из них, которые являются базовыми методами доказательства программ, кратко излагаются ниже.

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

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

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

158

каждого из них формулировалось утверждение с учетом условий ввода и вывода и соответствующих входных и выходных утверждений. Доказать истинность этих

Метод Хоара – это усовершенствованный метод Флойда, основанный на аксиоматическом описании семантики ЯП исходных программ. Каждая аксиома

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

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

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

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

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

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

В общем метод математической индукции разрешает доказать истинность некоторого предположения Р(n), в зависимости от параметра n, для всех n ≥ n0, и тем самым доказать случай Р (n0). Истинность Р(n) для любого значения n, доказывает Р(n+1) и тем самым доказательство истинности Р(n) для всех n ≥ n0.

159

Этот путь доказательства используется для утверждения А относительно программы, которая при своем выполнении достигает определенной точки. Проходя через эту точку n раз, можно получить справедливость утверждения А(n), если докажем:

1)что справедливо А(1) при первом проходе через заданную точку,

2)если справедливо А(n) (при n–проходах через заданную точку), то справедливо и А (n+1) при прохождении через заданную точку n+1 раз.

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

7.1.1.2 Модель формального доказательства конкретности программы

Сущность формального доказательства заключается в преобразовании кода программы к логической структуре [3, 6] Составляется описание утверждений, которые задают вход–выход программ с помощью логических операторов, а также комбинациями логических переменных (true/false), логическими операциями (конъюнкция, дизъюнкция и др.) и кванторами всеобщности и существования (табл.7.1.).