Среда разработки
вычислительных комплексов различной проблемной ориентации
Н.Л. Макаров,
асс., makarov.nl@outlook.com,
С.И. Ротков,
зав. каф., д.т.н., проф., rotkov@nngasu.ru,
ННГАСУ, Н. Новгород
С.Г. Кузин,
к.т.н., доц., kuzins@mail.com,
ННГУ им.
Лобачевского, Н. Новгород
В докладе
рассматривается проблематика проектирования моделей данных и вычислительных
процессов, а также предлагается компьютерная технология поддержки процесса
автоматизированного решения достаточно широкого класса вычислительных
прикладных задач. Для этого формально определяется класс алгоритмических задач,
предлагается в качестве модельной поддержки оригинальная графовая
модель – ролевые диаграммы. Также предлагается оригинальные алгоритмы
трансформации таких диаграмм в структуру данных и сетевые модели вычислительных
процессов.
Article describe the problems of designing data models and
computational processes, and offers technology support for automated solutions
rather broad class of computing applications. For this purposes formally
defined class of algorithmic problems, it offers as model support the original
graph model –role diagram. It also offers the original transformation algorithms
for such diagrams in the data’s structure and network models of computational
processes.
Необходимость
использования моделей при разработке прикладных программ обусловлена тем, что
разработка программного обеспечения проходит через множество технологических
этапов, в зависимости от используемой технологии программирования, но все они
начинаются с составления технического задания (ТЗ). ТЗ согласуется между
заказчиком и исполнителем, после чего начинаются работы по воплощению
программного продукта в жизнь. И здесь важную роль играют
данные и их модели, а также процессы их обработки и их алгоритмические модели,
поскольку реализация программного продукта заключается в реализации тех
структур данных, которые будут воплощением этих моделей, а также реализации
алгоритмов в конечный программный продукт, состоящий в свою очередь из
подпрограмм, реализующих процессы обработки неких исходных данных.
Модельный подход к конструированию прикладных
программ плодотворно реализуется в рамках парадигмы объектно-ориентированного
программирования (ООП). В рамках этой парадигмы, модель прикладной программы представляется
как система взаимодействующих объектов, которая изоморфна системе
взаимодействующих подсистем, образующих реальный объект. Можно утверждать, что
ООП превращает компьютер в аналог реального объекта, поведение которого в
необходимой степени повторяет или отражает поведению объекта-прототипа.
При использовании ООП, модель реального объекта
часто представляется в виде нескольких графических диаграмм средствами
Унифицированного Языка Моделирования (UML). Каждая диаграмма
представляет одну из точек зрения на будущую прикладную программу. Существует
конвертер объектно-ориентированной модели реального объекта в компьютерный код
прикладной программы, превращающей компьютер в подобие реального объекта.
Компьютерный код программы записывается на некотором языке программирования
высокого уровня, например, С++.
С другой стороны, с момента создания вычислительных
машин, разработка программ велась в рамках алгоритмической парадигмы, когда
сама программа выступает в роле пошагового преобразователя входных данных в
результирующие данные.
Иначе
выражаясь, в ООП используется модель взаимодействия объектов, тогда как в
алгоритмической парадигме используется модель взаимодействия процессов. Как
следствие, алгоритмическая модель являет собой иерархию процедур, в совокупности
с алгоритмом обхода этой иерархии при обработке конкретного набора исходных
данных
Традиционная
технология изготовления вычислительных прикладных программ чревата
семантическим разрывом между понятийным описанием объекта предметной области,
которое использует профессиональный специалист (инженер проектировщик) в
процессе своей трудовой деятельности, и текстом прикладной программы, который
записывает программист на «понятном компьютеру языке». Это возникает в
результате того, что каждый специалист находится в собственной профессиональной
среде и оперирует своим набором понятий. Так, например, ТЗ составляется таким
образом, чтобы заказчик и исполнитель одинаково понимали, чего они хотят. После
утверждения ТЗ, исполнитель, в лице, профессионального специалиста,
перерабатывает текст ТЗ, декомпозируя и выделяя в нём: исходные данные,
желаемые результирующие данные и процессы преобразования исходных
в результирующие данные. Это он делает в терминологии, которая уже может быть
не ясна заказчику, но понятна программисту, который будет реализовывать
прикладную программу. Программист же, переводит полученные от проф. специалиста
модели в структуры данных и подпрограммы.
Можно увидеть,
что здесь описана элементарная цепочка из трёх элементов. Заказчик – профессиональный
специалист – программист. Каждый оперирует своими понятиями и это и есть
потенциальный семантический разрыв. Такой семантический разрыв между объектом
проектирования и кодом программы определяет потенциальную ненадежность
прикладной программы. Такая ненадежность возникает в результате непонимания
между профессионалом в предметной области – заказчиком прикладной программы и
программистом – конструктором этой программы.
Привлекательная
идея – автоматическая генерация кода прикладной программы на основании
понятийной модели объекта профессиональной области.
Подобная
постановка проблемы вызывает необходимость решения ряда связанных между собой
проблем:
·
Проектирование
профессионального языка, ориентированного на человека, описания объекта
заданной профессиональной области;
·
Проектирование
профессиональной, ориентированной на компьютер, базы данных – хранилища
компьютерных кодов объектов профессиональной области;
·
Проектирование
и изготовление базы программных модулей, поддерживающих компьютерный анализ и
синтез объектов профессиональной области;
·
Проектирование
конкретных сценариев, использующих программные модули, обеспечивающих решение
конкретных прикладных задач в заданной профессиональной области;
·
Разработка
и использование программного инструментария, обеспечивающего автоматическое
(полуавтоматическое) выполнение сценариев прокрутки программных модулей –
автоматическое (полуавтоматическое) решение прикладных задач.
На ранних
стадиях компьютеризации изготовление прикладной программы происходило следующим
образом:
1. Получение и осознание технического
задания на разработку программы;
2. Запись кода прикладной программы;
3. Тестирование полученного кода
посредством обработки программой конечного числа отладочных исходных данных.
Результаты
обработки отладочных исходных данных получались «вручную» и сравнивались с
результатами работы программы. В связи с этим, появится термин «коэффициент
надежности программы» как отношение числа отладочных данных к числу всех
данных, обрабатываемых программой. При этом чем выше сложность
программы, тем коэффициент её надежности становилась все меньше и меньше.
Помочь
может структурная блок-схема процедуры преобразования данных, которая является
моделью будущей компьютерной программы, реализующей преобразование исходных
данных в результирующие[2]. Существенно, что операторы
процедурного языка программирования являются текстовой записью структурных
блок-схем. Отсюда следует, что конвертация блок-схемы в компьютерный код
прикладной программы является формальной процедурой, которая может выполняться
программой – конвертером.
Такой
модельно-ориентированный подход к конструированию прикладной программы имеет
ряд преимуществ перед неструктурным программированием:
1. при
проектировании модели преобразования данных проблемный специалист мыслит в
терминах прикладной задачи т.к. не связан правилами синтаксиса и семантики того
или иного языка программирования;
2. проблемному
специалисту нет необходимости знать какой-либо язык программирования;
3. модель
преобразования данных может формальным образом конвертироваться в прикладную
программу, записанные на каком-либо языке программирования;
4. одна и та же модель может конвертироваться в тексты, записанные на
различных языках программирования (как на существующих, так и на будущих);
5. формальная
(автоматическая) конвертация модели преобразования данных в прикладную
программу даёт гарантию того, что получившаяся программа реализует именно тот
процесс, который задан на уровне модели.
К
сожалению, формализмы структурного программирования позволяли описывать только
структуры действия и не включали в себя формализмы инкапсуляции данных.
В
дальнейшем, были предприняты многочисленные попытки создать технологии
разработки надежного программного обеспечения. Предлагались, в основном, два
пути создания достаточно надежных программ:
1.
Создание средств апостериорного контроля правильности
работы готовой программы, т.е. верификация – автоматическая проверка
правильности созданной программы. Параллельно с созданием компьютерного кода на
специфическом логическом языке записывался алгоритм функционирования программы
в виде верификационных формул. Параллельно с выполнением компьютерного кода
специальный процессор вычислял верификационные формулы. В случае совпадения
результатов работа программы признавалась удовлетворительной. Очевидно, что
такой подход обеспечения надежности программы, по причине сложности и
неоднозначности записи верификационных формул, возможен лишь для частных
случаев;
2.
Создание априорно надежной программы или, выражаясь
иначе, модельный подход к разработке программного обеспечения основывается на
различных способах представления информации в человеческом мозгу и в памяти
компьютера. Абстрагирование процедуры обработки данных в рамках прикладной
задачи представляется в виде модели, использующей человеческие термины и
представления. Предполагается, что на этом уровне представляется надежная схема
обработки информации. Предполагается также, что существует формальная процедура
конвертации человеческой модели прикладной задачи в прикладную программу,
решающую эту прикладную задачу. Автоматическая конвертация модели позволяет
получить прикладную программу с надёжностью не ниже надежности модели
прикладной задачи.
В связи с
этим, были рассмотрены уже разрабатывающиеся технологии, в первую очередь это CASE-технология автоматного
программирования «Switch-технология», предложенная д. т. н. Шалыто А.А. В этой
технологии предлагается парадигма автоматного программирования, в рамках
которой построение и реализация алгоритма выполняется в виде конечного
автомата, базирующегося на понятии "состояние". В этой работе
указанный подход был использован применительно к системам логического
управления, в которых входные и выходные воздействия являются двоичными
переменными [3].
Также была
рассмотрена визуальная технология программирования Р-схемами,
разрабатываемая д. т. н. Вельбицким И.В. Предлагается
не писать, а рисовать программы на всем их жизненном цикле в виде графов,
состоящих только из горизонтальных и вертикальных линий. Вершина не имеет имени
и задает состояние программы или процесса ее разработки. Таким образом предлагается технология визуального программирования[4].
В данной же
работе предлагаются оригинальные алгоритмы проектирования моделей данных и
вычислительных процессов, а также формально определяется класс алгоритмических
задач. Сама предлагаемая технология позволяет проблемному специалисту для
каждой конкретной вычислительной задачи быстро собрать из типовых модулей
необходимый вычислительный комплекс, обеспечивающий компьютерное решение
поставленной задачи. Достоинствам такого подхода следует отнести возможность
оперативного расширения множества решаемых задач, за счет разработки
дополнительных функциональных модулей и простоты их включения в базу
программных модулей. Модельные и алгоритмические средства, рассматриваемые в
настоящей работе, поддерживают это направление и реализуют технологию
автоматизированной разработки вычислительных комплексов инструментальными
средствами конструктора программ[1].
Проблемно-ориентированный
вычислительный комплекс конструируется для решения любой вычислительной задачи
из множества задач, определенных для конкретной проблемной области.
Предполагается, что существует множество базисных программных модулей, из
которых проблемный специалист, не обладающий знаниями по программированию,
может собрать и выполнить на компьютере вычислительную схему любой прикладной
задачи в рамках этой проблемной области.
Проблемная
ориентация конкретного вычислительного комплекса определяется следующими
основными моделями:
§ информационно-алгоритмическая
модель функционального процессора, представляющая системную увязку данных и
обрабатывающих модулей, позволяющих решать все прикладные задачи конкретной
проблемной области;
§ модель
управления вычислительным процессом, представляющая все допустимые последовательности
обрабатывающих модулей, для решения прикладных задач конкретной проблемной
области;
§ грамматика
профессионального языка описания исходных данных;
§ модель
трансляции предложений профессионального языка в экземпляры табличной базы
данных.
Для того
чтобы задать понятие модели данных и вычислительного процесса, определяется и
рассматривается формализм ролевых диаграмм - модельное обеспечение
конструирования сложных программных систем. Ролевые диаграммы конструируются из
четырех типов кустов. Формализм ролевых диаграмм похож на графическую модель
данных, предлагавшимися разработчиками базы данных ИНЭС [4] и графическую
модель программы, предложенной Джексоном, автором одного из методов
структурного программирования [6]. Такие модели представляют, как устроена
совокупность данных или совокупность процессов, но не представляют семантику
этого устройства.
Каждый из
типов кустов ролевых диаграмм в дальнейшем трансформируется в сетевую модель
вычислительного процесса. Благодаря тому, что каждый тип куста ролевой
диаграммы однозначно соответствует типу дуги сетевой модели, может быть
произведена однозначная трансформация из ролевой диаграммы в сетевую модель.
Сетевая
модель представляет из себя двухполюсный граф,
отвечающий следующим критериям:
1. Имеется только
одна начальная вершина;
2. Имеется
только одна конечная вершина;
3. Из
начальной вершины выходит только одна дуга;
4. В
начальную вершину не входит ни одна дуга;
5. Из
конечной вершины не выходит ни одной дуги;
6. На дугах
расставлены команды из текущего функционального банка модулей;
7. Любой
путь в графе ведёт из начальной вершины в конечную вершину.
Такие
ограничения позволяют задавать рекурсивные сетевые модели, ссылающиеся друг на
друга. Для этого дополнительно вводится понятие главной сетевой модели.
Функциональный
банк модулей – это множество функциональных программных модулей. Для
эффективного использования этого «банка функциональных программных модулей»
необходимо предоставить в распоряжение каждого проблемного специалиста
модельное и инструментальное программное обеспечение позволяющие,
самостоятельно и независимо от программиста, эффективно создавать прикладные
программы для решения вычислительных задач в рамках заданной предметной
области.
Имея такой банк модулей и множество сетевых моделей, необходимо средство
интерпретации сетевых моделей, которое могло бы выстраивать траекторию
вычислительного процесса, проходя по сетевым моделям, начиная с главной и
спускаясь рекурсивно, если того требует процесс. В таком
интерпретаторе должен быть операционный процессор, последовательно проходя по
сетевой модели, дуга за дугой и считывая команды, располагаемые на дугах. Затем
считанные команды передаются в функциональный процессор, который вызывает
необходимый функциональный модуль из банка функциональных модулей.
1. Кузин
С.Г. Унификация проектирования сложных вычислительных комплексов. LAP Lambert Academic Publishing, 2012.
2. Дейкстра
Э. Дисциплина программирования. М.: Мир, 1978.
3. Шалыто А.А.
Switch-технология. Алгоритмизация и программирование задач логического
управления. СПб.: Наука. 1998.
4. Вельбицкий,
И.В. Визуальная технология программирования нового поколения для широкого
применения на базе стандарта ISO/IEC 8631 / И. В. Вельбицкий // Междунар. конф.
MEDIAS – 2010. Кипр, 2010.
5. Емельянов
Н.E. Введение в СУБД ИНЕС. М: Наука, 1988.
6. Орлов
С.А. Технология разработки программного обеспечения. М.: Питер, 2003.