RU2306597C2 - Способ компоновки (сборки) программного обеспечения - Google Patents

Abstract

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

Description

Данное изобретение относится к способам компоновки (сборки) программного обеспечения (далее ПО).

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

- статическая сборка (static linking);

- динамическая сборка (dynamic linking) или динамическая компоновка (метод подключения к исполняемой программе стандартных функций и/или данных в момент обращения к ним с помощью вызова их из специальной библиотеки).

В общем случае ПО, разрабатываемое на сегодняшний день, в свой конечной рабочей фазе представляет собой машинный код (будь то процессорные директивы или команды какой-либо виртуальной машины). Этот код будем называть "черным ящиком". Если "черный ящик" содержит в себе ошибку, то общий путь ее нейтрализации сводится к следующим этапам:

1. Поиск или локализация проблемы. Эта операция может выполняться различными методами:

а. Анализ внешних данных системы: сообщения об ошибках, логи, записи в базе данных и т.д.

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

2. Устранение путем изменения "исходного кода".

3. Пересборка "черного ящика".

4. Перезапуск системы.

5. Получение подтверждения о том, что проблема устранена путем повторного тестирования.

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

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

Задачей данного изобретения является исключение выполнения пересборки "черного ящика" и/или перезапуска системы.

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

Краткое описание чертежей

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

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

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

На Фиг.3 показан классический пример фрагмента программы, написанной на языке С.

На Фиг.4 показана блок-схема матрицы указателей.

На Фиг.5 приведена диаграмма, в которой рассмотрен пример алгоритма, выполненный на неком абстрактном алгоритмическом языке программирования.

На Фиг.6 приведена блок-схема "управляющего" модуля.

На Фиг.7 приведена блок-схема алгоритма реализации требования, предъявляемого к "машинному коду" "программного модуля".

На Фиг.8 - блок-схема работы "прокси-функции".

На Фиг.9 приведена схема процесса загрузки модуля с номером М.

На Фиг.10 приведена схема-результат загрузки прокси-модуля с номером М.

На Фиг.11 приведена блок-схема алгоритма загрузки "управляющим" модулем "основных" модулей.

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

О сущности понятий, используемых в способе.

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

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

Рассмотрим пример, показанный на Фиг.3.

Это классический пример программы, написанной на языке С. Предлагаемый подход состоит в том, что данный исходный код (исходный код - это текст программы на алгоритмическом языке; в компьютере исходный текст либо непосредственно выполняется интерпретатором - транслятором, способным параллельно переводить и выполнять программу, написанную на алгоритмическом языке высокого уровня, либо предварительно переводится компилятором в стандартный загрузочный код, способный многократно исполняться в определенной вычислительной среде) рассматривается как две составляющие - "алгоритм" и "сущность". "Алгоритм" (в данном примере) - это вывод на консоль строки "Hello world". "Сущность" в данном случае подразумевается под некоторой функциональностью, которая реализовывает функцию printf. Как пример можно привести MSVCRT.DLL или LIBC библиотеки.

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

Эта модификация осуществляется с использованием матрицы и кодов основных модулей. Матрица может быть выполнена различными способами. Наиболее предпочтительный - таблицы "указателей на функции". Т.е. матрица представляет собой двумерный массив данных, количество строк в котором соответствует количеству "основных" модулей, при этом количество элементов в каждой строке совпадает с количеством функций алгоритма соответствующего модуля. Каждый элемент матрицы представляет собой указатель на соответствующую функцию соответствующего модуля (см. Фиг.4).

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

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

Соответственно, каким образом будет осуществляться передача управления той или иной функции данный способ никак не нормирует, поскольку это зависит от того, какой конкретно код какой конкретно машиной/процессором выполняется. Например, если это машинный код (инструкции процессора), то адрес функции ничто иное, как 4 байта (указатель на функцию в 32-битной системе или 8 байт 64-битной) и передача управления - ничто иное, как ассемблерная комманда call. "Сущности" же представляют собой машинный код, указатели на функции которого, так же как и в случае с алгоритмом, являются элементами матрицы, с той лишь разницей, что под этими элементами лежит черный ящик, алгоритм которого неизменяем. В то же время "сущности", будучи не более чем элементами матрицы, могут быть заменены. Исходный код выполняется в виде алгоритмического языка программирования. Основным требованием к исходному коду является наличие транслятора (программы, преобразующей текст, написанный на одном языке, в текст на другом языке) или компилятора (Компилятор - программа, преобразующая текст, написанный на алгоритмическом языке, в программу, состоящую из машинных команд. Компилятор создает законченный вариант программы на машинном языке.). К данному транслятору/компилятору предъявляются следующие требования:

- Транслятор/компилятор на основании данного исходного кода может собрать "программный модуль" (согласно ГОСТ 19781-90 программный модуль - это программа или функционально завершенный фрагмент программы, предназначенный для хранения; трансляции; объединения с другими программными модулями и загрузки в оперативную память).

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

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

На Фиг.5 приведена диаграмма, в которой рассмотрен пример алгоритма, выполненный на неком абстрактном алгоритмическом языке программирования.

На диаграмме представлен примитивный алгоритм, состоящий из двух функций, function 1, function 2, причем function 2 вызывает function 1 (строка 7). Предположим, что этот исходный код является базовым для сборки какого-то программного модуля.

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

На данном этапе метод не расходится с известными техническими решениями, за исключением того, что:

- Программный модуль должен быть "основным" модулем (описано ниже).

- Машинный код модуля должен быть собран таким образом, что вызов функции function 1, выполненный из функции function 2, не должен приводить к передаче управления функции function 1, а управление должно передаваться той функции, адрес которой в данный момент находится в соответствующем элементе матрицы. Например, предположим, что номер нашего модуля в системе - N, а номер функции function 1 в модуле - 1, тогда реализация лексемы строки 7 сводится к тому, что управление передается функции, адрес которой находится в матрице в N-ой строке, 1-ом столбце (см. схему на Фиг.7).

На этой схеме:

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

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

Например, при вызове функции function 1 модуля М будет вызвана функция, адрес которой находится в матрице указателей в строке М, первом столбце.

Это требование, предъявляемое к "машинному коду" "программного модуля" методом.

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

"Основной" модуль представляет собой "программный" модуль, полученный в результате трансляции/компиляции исходного кода алгоритма (см. Фиг.12). "Основной" модуль также содержит в себе "дополнительный функционал" и данные:

- уникальный идентификатор модуля (в пределах системы), необходимый управляющему модулю, для идентификации данного "основного модуля";

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

- указатель на матрицу, получаемый от "управляющего" модуля (Наличие матрицы подразумевает наличие "программного модуля", где эта матрица будет выполнена, физически создана. Этот модуль - "управляющий" модуль (см. Фиг.6). Те же модули (в приведенном примере он один), где непосредственно будет содержаться код выполненных функций алгоритма-скрипта, относятся к "основным" модулям).

На "Управляющий" модуль возлагаются следующие технические требования:

1. Хранение матрицы элементов.

2. "Управляющий" модуль реализует алгоритм загрузки "основных" модулей (см. схему на Фиг.11).

"Прокси-модуль" представляет собой ничто иное как "программный модуль" с тем же "набором" функций "основного" модуля, но реализация этих функций сводится не к выполнению их функциональности, а к делегированию исполнения соответствующей функции либо соответствующему основному модулю (модулям), или же какой-либо другой функциональности, реализующей данную функцию. Данные функции "прокси-модуля" будем называть "прокси-функциями" (см. схему на Фиг.8). Это означает что "прокси-модуль" должен "знать" (иметь ссылку на основной модуль) о существовании "основного" модуля (или их множестве, в общем случае). Необходимо отметить, что наличие "прокси-модулей" не является обязательной частью системы. Их присутствие, структура определяются непосредственно решаемой задачей. Их наличие является естественным и наиболее рациональным, на них налагаются определенные технические требования:

- реализуются функции "основного" модуля, как описано выше;

- реализуется так называемый "дополнительный функционал" и данные, которые выполнены в "основном" модуле (необходимо это для того, чтобы алгоритм загрузки "прокси-модуля" и "основного" модуля были абсолютно идентичны);

- "управляющий" модуль не делает разницы между "основными" и "прокси-модулями" (пояснено ниже).

Сущность способа сборки программного обеспечения

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

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

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

На первом этапе формирования двоичной матрицы в программном модуле, т.е. когда программа (система) запущена, выполняется загрузка "основных" модулей. Это означает, что существует список основных модулей, по которому выполняется загрузка каждого модуля в соответствии со схемой, показанной на Фиг.11. Данный список представляет собой ничто иное, как массив имен "основных" модулей. Как, где он (список) расположен, а также как инициируется загрузка, данный метод не рассматривает. Это может быть выполнено различными способами.

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

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

1. Локализация проблемы. Результатом анализа должен явиться вывод о том, какие именно функции какого модуля должны быть изменены для достижения положительного результата. Эта операция может выполняться различными методами:

а. Анализ внешних данных системы, как то: сообщения об ошибках, логи, записи в базе данных и т.д.

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

2. Далее модуль, содержащий ошибку, перегружается. (Сама система при этом не перестартовывается.) Алгоритм перезагрузки совпадает с алгоритмом загрузки, изображенным на схеме, показанной на Фиг.11. Схематично результат загрузки модуля с номером М показан на схеме, отраженной на Фиг.9.

3. При этом в роли "основного" модуля может выступать как сам "основной" модуль, так и соответствующий ему "прокси-модуль"; в этой связи будем различать два способа перезагрузки:

Способ А)

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

- Трансляция/Компиляция "основного" модуля.

- Перезагрузка "старого" модуля на "новый" "основной" модуль (см. схему на Фиг.11).

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

Способ Б)

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

а. Схематично результат загрузки модуля с номером М показан на Фиг.10

b. Здесь необходимо отметить, что:

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

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

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

iv. Для каждого "основного" модуля может быть один или множество "прокси-модулей".

с. Далее будем предполагать, что алгоритм "прокси-функции" в "прокси-модуле" реализован таким образом, что: (Фиг 6.)

i. Он (алгоритм) проверяет наличие скрипт-файла в "известном" каталоге файловой системы.

ii. В случае его наличия исполняет файл, используя "скрипт-машину" (интерпретатор).

iii. В случае отсутствия файла выполняется соответствующая функция "основного" модуля.

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

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

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

Пояснения к схеме на Фиг.9:

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

Заметим, что при таком подходе к разработке техническим результатом является сэкономленное на отладке время разработчика. Т.к. при:

- использовании Способа А) система не нуждалась в перезапуске,

- при использовании Способа Б) система не нуждалась как ни в пересборке, так и ни в перезапуске.

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

Claims (1)

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

Images