CC BY
24
список литературы
1. Edmons, L.D. An Introduction to Space Radiation Effects on Microelectronics [Текст] / L.D. Edmons, C.E. Barnes, L.Z. Scheick. - Jet propulsion Laboratory, California Institute of Technology, 2000. -83 p.
2. Чумаков, А.И. Действие космической радиации на ИС [Текст] / А.И. Чумаков. -М.: Радио и связь, 2004. -320 с.
3. Hennessy, Lohn L. Computer architecture: a quantitative approach [Текст] / Lohn L. Hennessy, David A. Patterson. -Morgan Kaufmann Publishers, 2007. -676 c.
4. Глухих, М.И. Формализация представления отказоустойчивых систем при проектировании структуры системы [Текст] / М.И. Глухих // Информационно-управляющие системы. -2005. -№ 3. -C. 27-35.
5. Cai Yuan. Cache Size Selection for Performance, Energy and Reliability of Time-Constrained Systems
[Текст] / Yuan Cai, Marcus T. Schmitz, Alireza Ejlali [et al.] // Proc. of the 2006 Asia and South Pacific Design Automation Conf., Jan. 2006.
6. Asadi, G.-H. Balancing Performance and Reliability in the Memory Hierarchy [Текст] / G.-H. Asadi, V. S. Mehdi, B. Tahoori [et al.] // Proc. of the IEEE International Symp. on Performance Analysis of Systems and Software, 2005. -ISPASS 2005, IEEE Computer Society, March 2005.
7. Haverkort, Boudewijn R. Performability modelling tools and techniques [Текст] / Boudewijn R. Haverkort, Ignas G. Niemegeers. // Performance Evaluation. -Elsevier Science Publishers B. V. Amsterdam, The Netherlands. -March 1996. -Vol. 25. -Iss. 1.
8. Deavours, D.D. The Möbius framework and its implementation [Текст] / D.D. Deavours, G. Clark, T. Courtney [et al.] // IEEE Transactions on Software Engineering. -Oct. 2002. -№ 28(10). -P 956-969.
УДК 004.416.6
В.М. Ицыксон, А.В. Зозуля
формализм для описания частичных спецификаций
компонентов программного окружения
Разработка программного обеспечения в настоящее время является одной из самых быстро развивающихся отраслей. Успешность компании-разработчика зависит от множества факторов, таких, как
качество выпускаемого программного обеспечения;
обеспечиваемый уровень поддержки; своевременный выход новых версий продукта; поддержка большого числа программных и аппаратных платформ;
оперативность в переносе программного обеспечения на новые мобильные устройства и т. п.
Перечисленные выше свойства не могут обеспечиваться только талантливой командой разработчиков, требуется также наличие определенных технологий, позволяющих автоматизировать существенную часть процесса разработки и сопровождения программного обеспечения. Такие технологии базируются на использовании формальных моделей и методов, обеспечивающих
автоматизированный или автоматический анализ, синтез, трансформацию и оценку программных систем.
Одна из задач, часто встающая перед разработчиками, - перенос отлаженного корректно функционирующего программного кода в новые условия:
на новую операционную систему; в новую версию ранее использовавшейся библиотеки;
в новую библиотеку;
на новую аппаратную платформу
и т. п.
Особенность указанной ситуации заключается в том, что имеющаяся программная система прошла стадии разработки, тестирования, отладки, внедрения и обладает определенным уровнем качества. Переработка системы с заменой библиотечных вызовов, подключением новых компонентов приводит к появлению новой программной системы, для которой придется частично или полностью повторить стадии разработки,
тестирования, отладки и внедрения, чтобы достичь того же уровня качества. Такое повторение этапов для системы, уже обладающей определенным уровнем качества, обеспечение которого стоило определенных материальных затрат, часто является неоправданным. Особенно расточительным это выглядит, если обратить внимание на то, что в программной системе не появилось новой функциональности, просто она стала функционировать в новом окружении.
Один из подходов, позволяющих сократить расходы на реинжиниринг, - автоматизация пор-тирования приложений из одного окружения в другое с помощью формальных спецификаций окружений [6]. Основой технологии автоматизации портирования являются спецификации компонентов программного окружения, позволяющие на требуемом уровне детализации задавать семантические свойства исходного и целевого окружений. Важная особенность спецификаций окружений - необходимость задания лишь некоторых свойств окружений, непосредственно отвечающих за взаимодействие программы с библиотекой и абстрагирующихся от тонкостей реализации самой библиотеки. Такие спецификации будем называть частичными.
Данная статья посвящена разработке формализма частичных семантических спецификаций компонентов программного окружения для языка программирования Си, обеспечивающего задание необходимых для портирования свойств.
Требования к частичным спецификациям
Решение задачи автоматизированного переноса приложений из одного окружения в другое невозможно без наличия спецификаций исходного и целевого программных окружений. При этом уровень детализации описания должен быть, с одной стороны, достаточным для спецификации всех аспектов компонентов, необходимых для реинжиниринга, а, с другой стороны, достаточно высоким, чтобы абстрагироваться от ненужных при реинжиниринге подробностей.
Определим требования, предъявляемые к частичным спецификациям окружений. Для этого обратимся к рисунку, на котором схематично изображено взаимодействие программы с гипотетическим окружением - библиотекой ввода-вывода. Основные точки взаимодействия программы и библиотеки изображены дугами, а основные участники взаимодействия - геометрическими фигу-
рами. Исходя из семантики языка Си, частичные спецификации окружений должны обеспечивать задание следующих характеристик.
Описание заголовочных файлов библиотеки. Требуется для корректной модификации программы при переходе с одной библиотеки на другую.
Описание сигнатур функций библиотеки. Каждая сигнатура должна содержать название функции, описание принимаемых параметров, их типов и возвращаемого результата.
Описание ресурсов окружения (операционной системы). Ресурсы - объекты операционной системы, имеющие свой жизненный цикл [6, 8]. Манипуляция с ресурсами - один из побочных эффектов функционирования библиотеки, чрезвычайно важный для корректного проведения преобразования программы. На рисунке ресурсом, например, является файловый дескриптор f1.
Описание глобальных объектов. Еще одним способом взаимодействия программы и библиотеки является использование глобальных переменных. На примере, изображенном на рисунке, глобальная переменная errno используется для передачи кода ошибки между библиотекой и основной программой.
Задание семантической интерпретации значений объектов используемых типов. Семантика взаимодействия между программой и библиотекой (вызов функций с параметрами, получение результата, обращение к глобальной переменной) может определяться конкретными значениями переменных, параметров, возвращаемых значений, причем в разных библиотеках конкретные значения (или диапазоны значений) могут существенно отличаться. Требуется механизм, задающий интерпретацию значений типов, используемых при взаимодействии.
Описание абстрактных действий, выполняемых программой. Кроме манипулирования ресурсами, еще одним побочным эффектом вызова библиотечных функций является выполнение действий, реализующих функциональность библиотеки. Требуется механизм идентификации и параметризации таких действий для возможности сопоставления с действиями, выполняемыми другими библиотеками. Примеры действий (OPEN и READ) приведены на рисунке.
Описание поведения библиотечных функций. Для задания укрупненного алгоритма работы функций, реализующих функциональность библиотеки, требуется механизм спецификации
Взаимодействие программы с окружением
поведения, позволяющий манипулировать параметрами функций возвращаемым значением, их типами, глобальными объектами, ресурсами и действиями.
Описание инициализации и финализации окружения. Некоторые библиотеки имеют специальные функции для инициализации (загрузки) и финализации (выгрузки) библиотеки. Требование соответствующего механизма в частичных спецификациях обусловлено необходимостью корректной инициализации ресурсов, глобальных объектов, а также своевременным их освобождением.
Исходя из сформулированных требований, необходимо выбрать готовый формализм или разработать новый, наиболее пригодный для задания всех необходимых характеристик частичных спецификаций.
Существуюет несколько подходов к спецификации компонентов программного обеспечения:
• формальное описание сигнатур функций и модулей при помощи системы типов и эффектов И1;
• аппарат логических пред- и постусловий, Z-нотации [8];
• алгебры и исчисления процессов, язык LOTOS [7];
• конечные автоматы - языки SDL, ESTELLE [2, 10];
• темпоральные логики CTL, LTL [4];
• визуальные языки моделирования, например, язык UML [11];
• денотационная семантика [5].
Каждый из перечисленных подходов позволяет описать один или несколько аспектов выдвинутых требований, но не может покрыть все требования. Это, в первую очередь, связано с разнородностью объектов, предназначенных для спецификации. Например, темпоральные логики предназначены, в т. ч. для описания правил последовательности наступления событий в системе, но непригодны для спецификации поведения функций. Конечные автоматы могут применяться для описания жизненного цикла ресурсов, но неприменимы при задании семантики параметров функций.
В данной статье предлагается собственный формализм для задания частичных спецификаций программных окружений, базирующийся на некоторых перечисленных выше формализмах и позволяющий (в отличие от каждого из них в отдельности) задавать все требуемые свойства библиотеки. Для простоты и наглядности описаний примеры спецификаций будут приводиться на аннотирующем языке PanLang, специально предназначенном для описания семантики функций библиотек языка Си [6, 9].
Частичные спецификации программных окружений
Частичной спецификацией программного окружения будем называть следующую совокупность S:
S = (T, C, G, R, Ru, F, A, H, f, f), где C - конечное множество именованных констант; T - конечное множество семантических типов; G - конечное множество глобальных объектов; R - конечное множество типов ресурсов; Rv - конечное множество утилитарных ресурсов (Rv с R); F - конечное множество функций; A - конечное множество действий; H - конечное множество заголовочных файлов; f - функция инициализации программного окружения; ff -функция финализации программного окружения.
Детализируем определение каждого элемента спецификации.
Константы. Являются неотъемлемой частью любого программного окружения. При переносе кода между окружениями необходимо осуществить замену констант на семантически аналогичные. Очевидно, что константы связаны с типами тех переменных, значения которых они описывают. В общем случае константы могут быть представлены в виде интервальных значений. Константы могут использоваться как для задания значения переменных, так и для задания значений атрибутов ресурсов:
C = {(n, V,)}, где п. - имя константы; v - значение константы.
В листинге 1 приведен пример, демонстрирующий задание констант, используемых в дальнейшем для передачи параметров в функции окружения:
const O_RDONLY = 0; const O_WRONLY = 1; const O_RDWR = 2;
Листинг 1: Пример задания констант
Семантические типы. В различных окружениях переменные разных типов могут иметь одну и ту же семантику. При формировании спецификаций окружений такие переменные должны быть специфицированы одинаковым образом. Перенос кода между окружениями будет сопровождаться заменой специфицированных типов переменных. Обращение к переменным специфицированных типов может быть опосредовано либо функциями, либо с использованием константы. В этом случае и функции, и константы также должны быть описаны в спецификациях:
Т = {t.}; t = (n ^ Cr R\ где t .. - новый семантический тип; n - имя типа; tb - базовый (расширяемый) тип, где tb е Т и Т, где Т - множество типов языка Си; С,, - множе-
c ' Т
ство символических констант, связанных с типом; R - сюръективное отображение R: tb ^ СГ
Имя типа привносит семантику в описание переменной, ресурса или параметра функции. Для одного базового типа языка Си может быть объявлено несколько семантических типов в рамках одной спецификации. Важно также отметить, что одна и та же переменная может иметь несколько семантических значений. Например, в зависимости от успешности выполнения функции, в качестве результата возвращается либо идентификатор ресурса, либо код ошибки. В этом случае возвращаемое значение имеет два семантических значения: ресурс и код ошибки. В другом окружении аналогичная функция может возвращать ресурс и код ошибки через два разных аргумента. Поэтому в качестве базового типа может выступать уже ранее определенный в спецификации тип.
Множество именованных констант СТ и отображение R позволяют именовать отдельные значения или группы значений базового типа. На основании сопоставлений этих имен можно сопоставлять состояние различных переменных из разных окружений.
Рассмотрим примеры задания семантики типов переменных, хранящих дескрипторы соке-тов, в операционных системах Linux и Windows (листинг 2 и 3).
Данное описание вносит семантику для типов языка Си, означающую, что переменная типа int для Linux и переменная типа SOCKET для Windows, значение которой хранит возвращаемое значение функций socket, являются дескриптором сокета. При переносе приложения, содер-
type SOCKET_TYPE (int) { }
function SOCKET socket(...) {
Листинг 2: Описание типа сокета и функции, создающей сокет, в ОС Linux
type SOCKET_TYPE (SOCKET) { }
function SOCKET socket(...) {
Листинг 3: Описание типа сокета и функции, создающей сокет, в ОС Windows
type FILE_FLAGS (char*) { READ = "r"; WRITE = "w"; ALL = "rw";
Листинг 4: Описание семантики параметра mode функции fopen
type FILE_FLAGS (int) { READ = O_RDONLY; WRITE = O_WRONLY; ALL = O_RDWR;
}
Листинг 5: Описание семантики параметра flags функции open
жащего функции работы с сокетами между ОС, на основе подобных спецификаций возможно автоматическое преобразование соответствующих типов.
Следующие примеры демонстрируют описания семантики параметров функций открытия файлов из разных программных библиотек (листинг 4 и 5).
Данное описание вносит семантику для типов языка Си, означающую, что значение функции, переданной вторым параметром, является флагом режима работы с файлом. Кроме того, такое описание задает интерпретацию возможных значений переменных данного типа. Типы языка Си char*, int и значения "r", "w", "rw", O_RDONLY, O_WRONLY, O_RDWR являются зависимыми от окружения, в то же время семантика в виде имени типа и именованных констант возможных значений не зависит от конкретного окружения. На основе указанных спецификаций возможно автоматическое преобразование соответствующих типов и констант при смене библи-
отеки работы с файлами.
Глобальные объекты. Глобальные объекты -это специальные объекты окружения, изменение состояния которых может быть одним из побочных эффектов окружения. Глобальные объекты являются моделью глобальных переменных программ или глобальных ресурсов:
О = ((«, Ш,
где п. - имя объекта; t. - тип, t. е Ти Т и Я.
^ г 'г 'г с
Глобальные объекты объявляются и инициализируются в /., могут освобождаться в и доступны из всех функций окружения.
Ресурсы. Будем понимать под ресурсами объекты операционной системы (среды, платформы), имеющие свой жизненный цикл, существующие в операционной системе и управляющиеся посредством специальных системных (библиотечных) вызовов. К ресурсам относятся, например, файлы, потоки, дескрипторы, объекты в динамической памяти, семафоры, мьютек-сы, сокеты и т. п.
Работа с ресурсами - неотъемлемая часть практически любого приложения. Именно ресурсы обычно являются существенной частью программных окружений и платформ, между которыми требуется осуществить перенос. Любой ресурс обладает некоторым жизненным циклом: создание ресурса, изменение его состояния, оперирование ресурсом, освобождение. Жизненным циклом ресурса управляют соответствующие функции. Обычно для ресурсов характерно наличие атрибутов. Атрибут ресурса - изменяемое свойство ресурса, влияющее на логику выполнения операций над ним. Значениями атрибутов ресурса также управляют соответствующие функции. В качестве формализма для представления семантики, связанной с ресурсами, будет использоваться формализм расширенного детерминированного конечного автомата (Extended finite state machine, EFSM) [3].
Рассмотрим подробнее этот формализм. В расширенном автомате помимо состояний и переходов имеется конечное множество внутренних переменных, способных принимать различные значения. Полное состояние расширенного автомата включает текущее состояние управления и текущие значения всех переменных. Входные и выходные символы могут иметь параметры. Помимо символов, каждый переход помечен также охранным условием (guard condition) и действием. Охранное условие зависит от переменных и параметров символов и определяет дополнительное условие выполнения данного перехода. Для того чтобы переход выполнился, мало подать на вход автомата нужный символ, нужно еще использовать такие значения его параметров, чтобы охранное условие выполнилось. Действие (указывается перед выходным символом) определяет новые значения внутренних переменных и значения параметров реакции в зависимости от прежних значений переменных и значений параметров стимула. Пусть программа состоит из ресурсов и функций, изменяющих состояния ресурсов, значения атрибутов ресурсов и выполняющих действия над ресурсами. Для каждого ресурса определено конечное множество состояний (состояния могут быть параметризованы) и множество атрибутов. Для каждой функции определены входные и выходные состояния ресурсов, операции над ресурсами и изменения их атрибутов. Выходами управляет логическая функция от входных состояний и их параметров. Таким образом, исходный код программы
представляет собой сеть конечных автоматов. В общем случае эти конечные автоматы могут быть связанными, тогда в логических функциях переходов участвуют состояния иных ресурсов.
С точки зрения семантики для каждого ресурса необходимо определить: вид ресурса;
типы, которыми представлен ресурс; возможные состояния ресурса; начальное состояние; конечные состояния; атрибуты ресурса.
Для некоторых ресурсов необходимо выделять, какое из состояний ресурса является начальным, какие состояния являются конечными. Конечное состояние ресурса - такое состояние ресурса, после перехода в которое возможно корректное удаление самого ресурса. При реинжиниринге кода, содержащего операции с таким ресурсом, необходимо осуществить соответствующую кодогенерацию с целью соблюдения корректности удаления ресурса.
Функции для работы с ресурсами будем называть ресурсными функциями. С точки зрения семантики ресурсные функции дополнительно к существующей семантике могут: создавать или удалять ресурсы; переводить ресурсы из одного состояния в другое;
проверять состояния ресурсов; проверять и изменять значения атрибутов ресурса;
выполнять какое-либо действие с участием ресурса.
Важно отметить, что для некоторых состояний ресурса может не существовать функций, выполняющих какие-либо действия над ресурсом, находящемся в данном состоянии. Состояния ресурсов, для которых специфицирована хотя бы одна функция с некоторым действием, будем назвать ключевыми состояниями ресурса.
Среди ресурсов можно выделить особый тип ресурсов, не играющих ключевую роль в работе программы. Будем их называть утилитарными ресурсами. Такие ресурсы служат для настройки, инициализации, предварительной подготовки компонентов программного окружения и, как правило, являются частью только одного из окружений. В таком окружении ресурсные функции остальных ресурсов могут проверять состояние утилитарных ресурсов. При переносе кода между
окружениями необходимо учитывать такие ресурсы особенным образом.
Формальное описание ресурса можно представить так:
R = {(и, ^ Q, Qк, FR, Аю у, q0, QF)}, где и - имя ресурса; t - тип ресурса, t е Т; Q - конечное множество состояний ресурса; Qк -конечное множество ключевых состояний ресурса, Qк е Q; FR - конечное множество ресурсных функций; Ак - конечное множество атрибутов ресурса; у - функция переходов: Q х FR х Ак ^ & х х Л~ & е Q, А~ е AR; q - начальное состояние
ресурса, q0 е Q; Q, - конечные состояния ресурса,
Qf е Q.
Язык PanLang позволяет описывать программные ресурсы, использующиеся в окружениях, явным образом. Для каждого типа ресурса задаются имя и перечень состояний, в которых ресурс может находиться во время выполнения программы [9]. Для любого типа ресурса можно задавать произвольные атрибуты, а также дополнительные свойства.
Рассмотрим описания ресурса, соответствующего сокетам для ОС Linux и библиотеки WinSock ОС Windows (листинг 6 и 7).
resource SOCKET (SOCKET_TYPE) {
states CREATED, CONNECTED, LISTENING, BOUND, CLOSED; finit CLOSED;
attribute SHUTDOWN_HOW SHUTDOWN_TYPE;
}
type SHUTDOWN_HOW (int) { READ = SHUT_RD; WRITE = SHUT_WR; READ_WRITE = SHUT_RDWR;
}
Листинг 6: Описание ресурса для ОС Linux
resource SOCKET (SOCKET_TYPE) {
states CREATED, CONNECTED, LISTENING, BOUND, CLOSED; finit CLOSED;
attribute SHUTDOWN_HOW SHUTDOWN_TYPE;
}
type SHUTDOWN_HOW (int) { READ = SD_RECEIVE; WRITE = SD_SEND; READ_WRITE = SD_BOTH;
}
Листинг 7: Описание ресурса для ОС Windows
Из данных спецификаций видно, что описания ресурсов сокетов совпадают. Различия изолированы в описаниях типов SOCKET_TYPE и SHUTDOWN_HOW. Задача переноса кода между окружениями сводится к преобразованию типов переменных и констант, соответствующих данным типам.
Действия. Видимое поведение функции может быть как операцией над аргументами, так и действием с некоторым побочным эффектом (side effect). Побочный эффект функции - это модификация значений глобальных переменных, осуществление операций ввода/вывода, осу-
ществление операций с какими-либо ресурсами (файлы, динамическая память, потоки, объекты синхронизации и пр.). Поведение функции с побочным эффектом может быть не детерминировано на одном и том же наборе значений входных аргументов. Побочный эффект может быть не связан с ресурсом. Например, функция sleep (описана в unistd.h) задерживает выполнение потока или процесса. Для таких функций необходимо задание семантики, при помощи которой можно описать действие (action), выполняемое функцией. При переносе кода между окружениями, где функции имеют различные имена, типы, количе-
ство параметров, действия функций несут основную семантическую нагрузку и будут являются основным критерием их соответствия:
A = {(n, P)},
где n - имя действия; P -множество параметров действия.
В отличие от функций, действия не содержат операционной семантики, все элементы спецификации действий задаются декларативно. Действия с точки зрения семантики представляют собой одну неделимую операцию. Функция может выполнять несколько действий.
Язык PanLang содержит конструкции, позволяющие объявлять действия и использовать их в теле функции. Рассмотрим пример спецификаций функции unsigned sleep(unsigned int seconds) из библиотеки unistd.h ОС Linux и функции VOID WINAPI Sleep(DWORD dwMilliseconds) из библиотеки Winbase.h ОС Windows (листинг 8 и 9).
type SEC (unsigned int) { }
type SLEEP_TIME (SEC) { }
action SLEEP (SLEEP_TIME); function sleep (SLEEP_TIME t) { action SLEEP (t);
}
Листинг 8: Описание действий для ОС Linux
type MILISEC (DWORD) { }
type SLEEP_TIME (MILISEC) { }
action SLEEP (SLEEP_TIME); function Sleep (SLEEP_TIME t) { action SLEEP (t);
}
Листинг 9: Описание действий для ОС Windows
Из данных спецификаций видно, что описания функций совпадают. Действия SLEEP задают семантику для функций, благодаря которой возможно автоматическое сопоставление и замена одной функции на другую. Различия в спецификациях сосредоточены в описаниях типов SLEEP_TIME. В одном случае данный тип расширяет тип SEC, в другом - MILISEC. При автоматизированном переносе исходного кода между окружениями подобные различия
спецификаций преодолеваются путем генерации функций преобразования значений одного типа в другой. В данном случае функция преобразования будет тривиальной.
Функции. Являются основным составляющим каждого API. Необходимо формально описать видимое поведение функции, заключающееся в выполнении действий и изменении окружения. Изменять окружение функции могут с помощью аргументов, возвращаемых значений и оперируя с ресурсами. Видимое поведение функций необходимо специфицировать посредством операционной семантики, в то время как остальные аспекты спецификации задаются декларативно.
Таким образом, с точки зрения семантики для функции должны быть определены:
сигнатура, определяющая семантику аргументов функции и возвращаемого значения;
видимое поведение, описываемое алгоритмом, и заключающееся в модификации аргументов функции, формировании возвращаемого значения функции, модификации глобальных объектов, модификации ресурсов, в выполнении действий. Формальное определение:
F = n ^ B)
где n - имя функции; P. - конечное множество входных параметров функции; Pout - конечное множество выходных параметров функции; P. е P, Poute P, где P - конечное множество кортежей видов (n, t), (n, t, e), где n - имя параметра, t е T, e -выражение; B - укрупненный алгоритм функции.
В языке PanLang для каждой функции задается сигнатура, имя функции и описание поведения [9]. Сигнатура включает в себя имена и типы аргументов, а также тип результата. Секция поведения содержит последовательность операторов, описывающих поведение специфицируемой функции. Поддерживаются несколько групп операторов:
управление вычислительным процессом (конструкция ветвления if, оператор завершения программы);
модификация значений объектов (параметров функций, внутренних переменных, глобальных переменных и пр.)
работа с участками памяти; работа с ресурсами (создание и освобождение, проверка и изменение состояний, модификация значений атрибутов); действия и т. п.
type FILE_FLAGS (char*) { READ = "r"; WRITE = "w"; ALL = "rw";
resource FILE (FILE_TYPE) { states OPEN, CLOSED; finit CLOSED;
attribute FILE_FLAGS MODE;
}
function FILE fopen (FILE_NAME (char*), FILE_FLAGS mode) { f = new FILE(OPEN); attr(f, MODE) = mode; return f;
Листинг 10: Пример спецификации функции fopen
В качестве примера описания семантики функций рассмотрим спецификацию функции FILE *fopen(const char *restrict filename, const char *restrict mode) из библиотеки <stdio.h> (листинг 10).
Данная спецификация определяет семантику функции fopen - создание ресурса FILE с начальным состоянием OPEN, задание режима доступа к файлу.
Заголовочные файлы. В языке Си функции, типы и константы объявляются в заголовочных файлах. Спецификация окружения должна содержать перечень необходимых заголовочных файлов, достаточных для функционирования окружения (в т. ч. и для компиляции программы в окружении). Заголовочные файлы могут требоваться как для всех элементов спецификации, так и для конкретных элементов: функций, типов и пр.: H =
где h . - имя заголовочного файла.
Пример спецификации, задающей заголовочные файлы, требующиеся для описываемых функций, приведен листинге 11:
requires <stdio.h>; requires <stdlib.h>;
Листинг 11: Спецификация задания заголовочных файлов
При переносе исходного кода в новое окружение к существующим заголовочным файлам в код, затрагивающий специфицированную часть окружения, добавятся файлы, описанные в спецификации целевого окружения.
Применение разработанного формализма
Описанный формализм удовлетворяет всем поставленным требованиям, т. е. позволяет специфицировать структуру и видимое поведение программного окружения. Все способы взаимодействия программы и окружения описываются формально с использованием простого математического аппарата: теории множеств, конечных автоматов или простых императивных конструкций, сводящихся к выражениям логики первого порядка. Простота аппарата позволяет решать актуальные задачи реинжиниринга:
проверку совместимости двух окружений; генерацию функций или шаблонов функций для элементарных преобразований семантических типов;
формирование правил преобразования программы при реинжиниринге.
Для задания частичных спецификаций разработчик может использовать язык РапЬа^ с Си-подобным синтаксисом, позволяющий описывать все компоненты спецификаций в привычной для программиста форме [9]. Такие спецификации состоят из декларативных и императивных описаний и могут быть построены на основе анализа руководств по используемым библиотекам.
Представленный формализм для описания частичных спецификаций приложений является основой для системы портирования приложений из одного программного окружения в другое [6], разрабатываемой на кафедре компьютерных систем и программных технологий Снкт-Петербургского государственного политехнического университета.
Проведение реинжиниринга программных систем при переносе в новое программное окружение - непростая научно-техническая задача. В зависимости от сложности программного окружения, используемых в программной системе библиотечных функций, механизмов, применяемых разработчиком при проектировании программы, задача может решаться полностью автоматизировало, частично автоматизированно или вручную.
В статье отражены основные результаты исследования в области формализации частичных спецификаций программных компонентов, связанной с переносом программного кода между окружениями. Для описания поведения компонентов использован язык PanLang, являющийся мощным выразительным средством. Показаны возможности языка для специфицирования семантики компонентов.
Полученные результаты служат основой для
решения задачи автоматизации переноса приложений из одной среды в другую. При этом в отличие от других подходов не требуется явное алгоритмическое описание процесса трансформации, что позволяет автоматизировать широкий класс задач портирования.
Направления дальнейших исследований связаны с расширением спектра поддерживаемых способов взаимодействия программы и окружения и адаптацией формализма и сопутствующих алгоритмов к объектно-ориентированным языкам программирования (в первую очередь - С++, Java и С#). Отдельного рассмотрения заслуживает вопрос возможности создания абстрактных спецификаций, не привязанных к конкретному языку программирования, для решения задачи автоматизации межязыковой трансляции.
Работа выполнена в рамках госконтракта N° П2226 ФЦП «Научные и научно-педагогические кадры инновационной России на 2009-2013 гг.».
список литературы
1. Pierce, B.C. Types and Programming Languages [Текст] / B.C. Pierce. -Cambridge: The MIT Press, 2002. -645 p.
2. Budkowski, S. ISO Standardized Description Technique ESTELLE [Текст] / S. Budkowski, P. Dembinski, M.Diaz. ISO. - 1989. -P. 1-28.
3. Cheng, K-T. Automatic Functional Test Generation Using The Extended Finite State Machine Model [Текст]/ K.-T. Cheng, A.S. Krishnakumar // International Design Automation Conf. (DAC). ACM. -1993. -P. 86-91.
4. Eisner, C. Comparing Symbolic and Explicit Model Checking of a Software System [Текст] / C. Eisner, D. Peled // Proc. of the 9th International SPIN Workshop on Model Checking of Software. -London: Springer-Verlag, 2002. -P. 230-239.
5. Scott, D. Toward a Mathematical Semantics for Computer Languages [Текст] / D. Scott, C. Strachey // Programming Research Group Technical Monograph PRG-6. -Oxford: OUCL, 1971. -43 p.
6. Itsykson V. Automated Program Reengineering When Porting Software to a New Environment Described
by Partial Specifications [Текст] / V. Itsykson, A. Zozulya, M. Glukhikh // Proc. of 2nd Workshop Program Semantics, Specification and Verification. -St.Petersburg, 2011. -P. 111-119.
7. Turner, K.J. Template-based specification in LOTOS [Текст] / K.J. Turner. -Department of Computing Science and Mathematics, University of Stirling, Scotland, 1993.
8. Spivey, J.M. The Z Notation: A Reference Manual [Текст] / J.M. Spivey // Programming Research Group. -University of Oxford, 1992.
9. Ицыксон, В.М. Язык спецификаций поведения программных компонентов [Текст] / В.М. Ицыксон, М.И. Глухих // Научно-технические ведомости СПбГПУ Сер. Информатика. Телекоммуникации. Управление. -2010. -№ 3 -C. 63-71.
10. Кознов, Д.В. Языки визуального моделирования. Проектирование и визуализация программного обеспечения: Учеб. пособие [Текст] / Д.В. Кознов. -СПб.: Изд-во С.-Петерб. ун-та, 2004. -171 с.
11. Фаулер, М. UML. Основы [Текст] / М. Фаулер; Пер. с англ. -СПб.: Символ-Плюс, 2004. -3-е изд. -192 с.
