Содержание к диссертации
Введение
Глава 1 Обратное проектирование в САПР встроенных систем 15
1.1. Модели прямого проектирования и их связь с обратным проектированием 17
1.2 Состави анализ исходных данных для ОПВС 19
1.2.1 Анализ фрагментов машинного кода 21
1.2.2 Анализ исходных текстов программ 27
1.2.3 Анализ схем 32
1.3 Инструментальные средства поддержки ОПВС 37
1.3.1 Дизассемблеры 37
1.3.2 Декомпиляторы 39
1.3.3 CASE-средства -. 41
1.4 Базовые положения подхода к проведению ОПВС 45
Выводы по первой главе 47
Глава 2 Разработка и исследование моделей поддержки процесса ОПВС 49
2.1 Разработка базовых сценариев обратного проектирования . 49
2,1.1 Сценарий анализа состояния разработки 51
2.1.2 Сценарий восстановления проектных решений 55
2.1.3 Сценарий поиска эффективного решения 59
2.1.4 Сценарий параметрической модификации 62
2.1.5 Перенос на другую платформу , 64
2. Г.б Перепроектирование системы 67
2.1.7 Классификация сценариев ОП 67
2.2 Разработка базовых моделей процесса ОП. 73
2.3 Разработка лингвистических моделей ". 89
2.3.1 Язык представления результатов агрегации 93
2.3.2 Язык представления укрупненных функциональных схем... 95
2.3.3 Язык шаблонов обратного проектирования 98
2.4 Разработка графовых моделей для представления продуктов ОП... 101
2.4.1 Разбиение графа на множество непересекающихся интервалов.. 102
2.4.2 Получение производных последовательностей 104
2.4.3 Классификация полученных последовательностей 105
2.5 Разработка моделей валидации 107
2.5.1 Функциональное тестирование. 108
2.5.2 Валидацияпо времени 109
2.5.3 Валидация по объему кода 111
2.5.4 Модель драйвера тестирования 112
2.6 Выводы по второй главе 114
Глава 3 Разработка и исследование моделей средств поддержки ОП ... 116
3.1 Разработка обобщенной структурно-функциональной схемы системы поддержки ОПВС 116
3.2 Алгоритмические модели основных преобразований процесса ОПВС 119
3.2.1 Дизассемблирование , 119
3.2.2 Структурный анализ 121
3.2.3 Анализ схем 125
3.2.4 Укрупнение алгоритмов и семантический анализ... 127
3.2.5 Оценка результатов и создание документации 131.
3.3 Модель оценки эффективности САОПВС 135
3.4 Выводы по третьей главе 140
Глава 4 Экспериментальные исследования разработанных моделей ... 142
4.1 Разработка спецификаций и гипертекстовой документации программного обеспечения ультразвукового расходомера — теплосчетчика 142
4.2 Поиск типовых решений на примере идентификации методов численного интегрирования 144
4.3 Построение модели для программы управления шаговым двигателем на базе МК РІС 16 161
4.4 Реконструкция ОС реального времени для МК Infenion С167.166
4.5 Выводы по четвертой главе 167
Заключение 169
Список сокращений принятых в диссертации 170
Литература
- Модели прямого проектирования и их связь с обратным проектированием
- Разработка базовых сценариев обратного проектирования
- Разработка обобщенной структурно-функциональной схемы системы поддержки ОПВС
- Разработка спецификаций и гипертекстовой документации программного обеспечения ультразвукового расходомера — теплосчетчика
Введение к работе
Актуальность проблемы. Жизненный цикл встроенных систем (ВС), наиболее распространенным представителем которых являются микропроцессорные системы (МПС) контроля и управления, включает в себя широкий спектр работ, имеющих характер продолжающейся разработки. К основным видам таких работ относятся: устранение неполадок, в том числе порожденных недостаточно качественными проектными решениями, модернизация, связанная со стремлением улучшить технико-экономические показатели ВС, адаптация к изменившимся условиям эксплуатации и т.п. В ходе этого процесса часто возникает задача анализа результатов реализации проекта и порождения таких артефактов проектирования, которые отсутствуют в документации, находящейся в распоряжении сопровождающих специалистов, и без которых не удается обеспечить целостность, согласованность и устойчивость проектных решений. Анализ результатов реализации с целью порождения артефактов проектирования назван в представленной работе термином «обратное проектирование встроенных систем» (ОПВС).
Основная часть функциональности большинства существующих встроенных систем сосредоточена в программном обеспечении (ПО). Согласно Б.У.Боэму стоимость внесения изменений в ПО с ростом его объема возрастает экспоненциально, причем для ВС значение коэффициента сложности разработки является максимальным. Это значение может быть снижено за счет использования средств автоматизации. Исследования В.В.Липаева показывают, что применение средств автоматизации проектирования программных систем дает наибольший эффект при создании систем реального времени, что определяется жесткими требованиями к параметрам функционирования таких систем и сложностью поведения внешней среды систем контроля и управления. Факторы, усложняющие прямое проектирование ПО ВС, при обратном проектировании обостряются. Это связано с двумя основными причинами. Во-первых, при прямом проектировании разработчик ПО всегда имеет доступ к спецификациям моделей поведения внешней среды, а при обратном проектировании такого доступа часто нет. Во-вторых, при порождении кода программ ВС активно используется хорошо структурированная система проектных решений, что декомпозирует сложные задачи на более простые и существенно упрощает процесс программирования. У специалиста по обратному проектированию обычно нет доступа к спецификациям проектных решений, и объем входных данных и неопределенностей, с которыми он имеет дело, многократно превышает то, с чем работает проектировщик ОПВС. Для того, чтобы средства автоматизации ОПВС успешно справлялись с указанными факторами сложности целесообразно наделить их следующими свойствами: а) возможность автоматизации наиболее трудоемких процессов ОПВС; б) поддержка интеграции артефактов обратного проектирования, полученных автоматическими анализаторами и человеком; в) иметь сквозной характер разработки, то есть возможность поддерживать различные этапы ОП и обеспечивать связь между ними; г) гетерогенность - универсальность по отношению к различным микропроцессорным архитектурам; д) возможн4сровдйЖЮВДИАЧ»Я(Л* Ік изме-
! -^ J
няющимся целям ОП и составу исходных данных; е) охватывать как программную, так и аппаратную составляющие.
К сожалению, в настоящее время не существует систем поддержки ОПВС, обладающих всеми перечисленными свойствами, что обуславливает актуальность задачи исследования принципов построения средств автоматизации обратного проектирования встроенных систем (СА ОПВС).
В центр этих исследований необходимо поставить проблемы создания моделей - логико-алгебраических, алгоритмических, графовых и лингвистических, на основе которых строится интегрированная система, позволяющая объединить как традиционные инструментальные средства (дизассемблеры, CASE-средства с поддержкой возвратного проектирования, кросс-средства, используемые в ходе прямого проектирования), так и специальные средства поддержки анализа программных и аппаратных средств ВС, и использовать их в задачах сопровождения и модификации МПС.
Область исследования - автоматизация обратного проектирования встроенных систем.
Обьеісг исследования - средства автоматизации обратного проектирования встроенных систем.
Предмет исследования - комплекс методов, моделей, технологии и программных средств, обеспечивающий эффективную автоматизацию процесса обратного проектирования встроенных систем.
Целью работы является разработка моделей процессов и артефактов обратного проектирования встроенных систем, технологии его осуществления и архитектурных решений соответствующих средств автоматизации. Для достижения этой цели необходимо решить следующие основные задачи.
-
Исследование существующих методов решения задач прямого и обратного проектирования встроенных систем, определение базовых положений подхода к проведению обратного проектирования.
-
Анализ и классификация основных целей обратного проектирования с точки зрения их влияния на технологию и трудоемкость проведения ОПВС.
-
Разработка базовой модели процесса обратного проектирования и ее модификаций для различных условий применения.
-
Разработка моделей артефактов обратного проектирования и процессов автоматизации его этапов.
-
Разработка базовых архитектурных решений средств автоматизации обратного проектирования и основ эффективной технологии его реализации на основе применения этих средств.
-
Экспериментальное исследование разработанных методов и моделей.
Методы исследования. В работе использованы методы анализа прецедентов при осуществлении разнообразных сценариев обратного проектирования, методы теоретического и экспериментального исследования механизмов обратного проектирования с привлечением логико-алгебраических и автоматно-лингвистических моделей, теории графов, а также методы макета-
рования и экспериментального исследования программных средств поддержки ОПВС.
Научная новизна проведенных исследований заключается в следующем;
-
Предложен подход к созданию средств автоматизации обратного проектирования встроенных систем, отличающийся от известных тем, что использует итерационную модель укрупнения алгоритмов, охватывающую различные уровни процесса укрупнения.
-
Разработанная общая модель процесса ОПВС в отличие от существующих моделей обратного проектирования имеет «сквозной» характер, интегрирует процессы анализа программных и аппаратных средств и позволяет проводить валидацию на каждом шаге повышения уровня абстракции артефактов обратного проектирования.
-
Для обеспечения возможности построения семейства конструктивных алгоритмических моделей, ориентированных на конкретные цели, построено отношение порядка в пространстве критериальных параметров «Степень модификации МПС - Требования к точности валидации».
-
Разработаны средства лингвистического обеспечения обратного проектирования, ориентированные на современные унифицированные лингвистические процессоры с поддержкой расширения спецификаций языка которые в отличие от существующих языковых средств охватывают аппаратную и программную составляющие встроенной системы.
-
Разработаны базовые алгоритмические и графовые модели процессов обратного проектирования, отличающиеся от известных большей конструктивностью в части автоматизации процесса повышения уровня абстрагирования проектных решений.
Практическая ценность. Практическую ценность представляют следующие результаты, полученные в рамках проводимых исследований:
-
Построен проект системы поддержки ОПВС, эксперименты с которым позволили добиться снижения стоимости внесения изменений в 1,7 - 3,5 раза за счет использования разработанных моделей средств автоматизации ОПВС. Изменение параметра эффективности в указанных пределах зависит от начальных условий, в которых приходится осуществлять анализ и модификацию, а также от целей обратного проектирования.
-
Разработана BNF-форма для языка шаблонов обратного проектирования, обеспечивающая автоматическое построение интерпретаторов с использованием инструментальных средств построения лингвистических процессоров.
-
Построен набор базовых шаблонов ОПВС.
4. Разработана модель оценки эффективности СА ОПВС, базирующаяся на
широко распространенных метриках Б.У. Боэма и М.Х. Холстеда.
Достоверность и эффективность. Достоверность полученных в диссер
тации результатов подтверждается результатами экспериментальных разра
боток. Эффективность подхода оценивается на основе широко распростра
ненных метрик МХХолстеда и Б.У.Боэма и в проведенных
экспериментальных исследованиях характеризуется значением степени сокращения затрат на модификацию ПО ВС, лежащим в пределах 1,7 - 3,5.
Внедрение результатов. Диссертационная работа является обобщением результатов, полученных автором в Ульяновском государственном техническом университете в процессе выполнения в 2000-2005 годах научно-исследовательских работ, в том числе: "Разработка спецификаций и гипертекстовой документации программного обеспечения ультразвукового расходомера - теплосчетчика" (Ульяновск, ООО «Тисса»), Методика ОПВС передана для использования на Ульяновский завод тяжелых станков (ОАО УЗТС), Ульяновский автомобильный завод (АО УАЗ), внедрена в учебном процессе двух специальностей УлГТУ.
Апробация работы. Основные научные и практические результаты исследований по теме диссертации докладывались на 4-ой международной конференции «Интерактивные системы: Проблемы человеко-компьютер-ного взаимодействия» (Ульяновск, 2001), на 6-ой международной конференции «Интерактивные системы: Проблемы человеко-компьютерного взаимодействия» (Ульяновск, 2005), на 6-ом международном симпозиуме «Интеллектуальные системы» (Москва, 2004), на международной конференции «Континуальные алгебраические логики, исчисления и нейроинформа-тика в науке и технике» (Ульяновск, 2005), на заседании кафедры «Вычислительная техника» (Ульяновск, 2005), на постоянно действующих городских семинарах «Встроенные системы» (Ульяновск).
Публикации. Материалы диссертации опубликованы в 10 работах. Из них 8 статей и 2 тезиса докладов научных конференций.
Структура и объем диссертации. Диссертация состоит из введения, четырех глав, заключения, списка используемой литературы, включающего 120 наименований, и приложения. Основная часть работы изложена на 180 страницах машинописного текста. Работа содержит 36 рисунков и 11 таблиц.
Модели прямого проектирования и их связь с обратным проектированием
Процесс проектирования ПО ВС представляет собой построение последовательности моделей ПО, каждая из которых уточняет или дополняет модели полученные ранее. Построение модели используется для получения окончательного результата - текста программы во входном языке ВС, используемой для ее выполнения.
В работе Ю.В. Капитоновой и А.А. Летичесвского [34] процесс проектирования программ представляется следующими основными этапами:
1. Построение главной функциональной модели средствами математической модели предметной области как функции теоретико-множественных структур данных;
2. Конструктиеизация функциональной модели, состоящая в нахождении какого-либо алгоритма вычисления функции;
3. Преобразование функциональной модели как поиск оптимального решения предложенного алгоритма;
4. Синтез процедурных представлений осуществляет переход к процедурной форме представления алгоритмов вычисления функций, составляющих главную функциональную модель;
5. Преобразование процедурных представлений во входной язык вычислительной системы.
Такое представление дает общее понятие о процессе проектирования ПО. Для каждого из перечисленных этапов могут применяться различные модели и методы, осуществляющие решение поставленных задач на каждом из этапов. В.В. Парфенов [66] предлагает вариант графического представления про цесса проектирования ПОВС, в котором отражаются его основные этапы (рис. 1.1).
Наиболее известными моделями процесса ПП на сегодняшний день являются RUP (Rational Unified Process) [6,7,8,64], методология ROOM (Realtime Object-Oriented Modeling) [117], метод OOSE (Object-Oriented Software Engineering) [111] и многие другие (более подробно обзор существующих моделей можно найти в работах Д.В. Кознова [39] и Е.З. Зиндера [30]).
В работе М.Ю. Гусенко [19] со ссылкой на БирнеЕ.А. (Byrne Е.А. [91]) предлагается общее графическое представление процесса ОП (рис. .1.2.), которое наглядно демонстрирует, как по мере осуществления реинжениринга (абстрагирования) уровень детализации описания программных функций уменьшается, что прямо противоположно направлению детализации, имеющему место при разработке программного обеспечения. Инструментальные средства (CASE-средства, RAD-средства, компиляторы с языков высокого уровня, компоновщики), поддерживающие процесс ПП, выполняя ряд последовательных преобразований, осуществляют процесс поэтапной детализации и получают в результате машинный код, который пред ставляет собой детализированную в терминах архитектуры модель абстракции высокого уровня.
Язык описания детализированной модели значительно отличается от языка описания, используемого на этапах проектирования задачи, что не позволяет реализовать процесс ОП тривиальным выполнением этапов ПП в обратном порядке и требует создания модели ОП.
В настоящей работе, посвященной проблемам восстановления проектных решений (артефактов проектирования), будем рассматривать процесс ОП именно как процесс поэтапного абстрагирования (stepwise abstraction), то есть отображения множества исходных данных более низкого уровня представления на множество данных более высокого уровня абстракции. Выявление состава исходных данных и подходов к их анализу является первостепенной задачей при исследовании процесса ОП; Рассмотрим известные к настоящему времени её решения.
Не зависимо от целей и задач анализа, процесс ОП начинается с этапа получения исходных данных, в качестве которых для встроенных систем обычно выступают [72]: Машинный код, как правило, представленный шестнадцатеричным дампом памяти; Исходные тексты программы на одном из языков высокого уровня; Эксплуатационная документация, в которую входят тексты описания функционирования микропроцессорной системы (МПС) на естественном языке, принципиальные схемы, представленные в графическом виде, списки, таблицы и т.п.
Состав исходных данных может меняться в зависимости от начальных условий, в которых приходится осуществлять ОП. Например, чаще всего, исходные тексты программ недоступны и их приходится получать как результат анализа машинных кодов, используя при этом технику декомпиля-ции [18-23,90,93,97,98]. В значительной степени затрудняет анализ отсутствие принципиальных схем МПС или эксплуатационной документации. Но даже если такая документация имеется, то, как указывается в [33], технические описания, входящие в состав этой документации, меньше всего ориентированы на техническое обслуживание и часто непригодны для ОП, которое, по сути дела, можно рассматривать как продолжающуюся исходную разработку [5].
Согласно [72], можно различать хорошо- и плохо документированные системы. К первым относятся системы, эксплуатация и ремонт которых дает минимум затрат, а все остальные системы считаются плоходокументирован-ными.
В настоящее время отсутствуют общепринятые походы к проведению ОП, особенно для встроенных систем (ВС), поэтому на начальном этапе требуется собрать и систематизировать всю имеющуюся информацию, а также соответствующим образом ее организовать.
Разработка базовых сценариев обратного проектирования
Анализ опыта ОП, изложенного в литературе, прежде всего в работах [46,72,74,81,93], а также экспериментирование с аппаратно-программными решениями ВС, проведенное в рамках данной работы, позволяет сделать вывод, что сценарий ОП существенно зависит от его целей и условий. В этой связи сформулируем основные проектные ситуации, в которых приходится выполнять ОП.
Можно выделить следующие цели ОП, классифицировав их по влиянию на существующую систему:
1. Анализ проектных решений:
a. Анализ состояния разработки - построение спецификаций с целью оценки сложности продолжения разработки или моди фикации системы;
b. Восстановление проектных решений - разработка тех арте фактов проектирования, на основе которых может быть полу чена исследуемая реализация;
c. Поиск эффективного решения - вскрытие системы или ее части с целью выявления и изучения таких проектных реше ний, которые обеспечивают конкурентные преимущества;
Целью такого анализа является формирование спецификаций, обеспечивающих продолжение разработки или ее частичную модификацию. Необходимость в осуществлении работ такого рода чаще всего возникает у руководителей предприятий, где по каким-либо причинам останавливается разработка существующего проекта (ушел ведущий программист; распался коллектив разработчиков; группа программистов, которая занималась этой задачей, переведена на другой более важный проект и т.п.) и нужно проанализировать текущее состояние для того чтобы оценить насколько сложно возобновить и продолжить разработку (чаще всего другому коллективу программистов) и стоит ли это делать вообще. В качестве исходных чаще выступают исходные тексты модулей программ, макет функционирующей системы, реже какая-либо проектная документация.
При разработке спецификаций производится общий анализ с целью выявления наиболее слабо проработанных модулей. Для слабо проработанных модулей проводится детальный анализ с целью формирования оценок качества и их совокупностей и степени различных рисков. В качестве основных критериев качества выбираются следующие: Реализация - степень реализации, выражаемая в процентах; Устойчивость — оценка устойчивости в смысле правильности реализации программных функций при самых различных исходных данных; в качестве факторов неустойчивости выступают проявление побочных эффектов, использование статических переменных вместо локальных, использование «хакерских» приемов программирования;
Сложность - оценка сложности модуля, исходя из которой определяется тщательность тестирования и валидация программного кода, а также возможная декомпозиция модулей.
Исходя из вышесказанного, сценарий процесса ОП можно представить диаграммой деятельности на рис, 2.1.
Приведенный сценарий можно разбить на три основных этапа: этап анализа требований к системе, этап анализа состояния разработки и этап срав нения полученных в результате анализа данных с предъявляемыми требованиями, с элементами валидации.
На первом этапе на основе доступной документации составляются требования к системе или к отдельной ее части. Если имеется техническое задание на разработку, то требования могут быть получены из него. Если же требования отсутствуют, то их нужно формировать вручную, выявляя из целей разработки, наблюдая за работой системы, используя информацию о похожих системах-прототипах, беседуя с эксплуатационщиками ВС и изучая модели ее функционирования и принципиальные схемы. Результатом такой работы должен стать перечень детальных требований к системе с указанием качественных и количественных характеристик для каждого пункта.
На втором этапе производится определение состояния разработки, прежде всего это относится к ПО, анализ которого можно разделить на статический и динамический. В результате статического анализа решается задача структуризации по исходным текстам системы, выявляется перечень модулей и функций и устанавливаются взаимосвязи между ними. Результатом статического анализа является построение дерева вызовов функций (ДВФ) и формирование гипертекстового справочника по функциям и структурам данных.
Организация справочника в виде гипертекста позволяет более четко и глубоко понять назначение всех функций и организацию всех структур данных. Создание такого справочника является очень полезным для дальнейшей разработки и использованию модулей и всех его компонент.
Разработка обобщенной структурно-функциональной схемы системы поддержки ОПВС
Система поддержки ОПВС (СП ОПВС) представляет собой инструмент, позволяющий проводить обратное проектирование в полуавтоматическом режиме. Широкий спектр вовлекаемых инструментальных средств заставляет строить СП ОПВС базируясь на принципах открытого межпрограммного интерфейса для возможности подключения и конфигурирования внешних программ.
Сформулируем общие требования к СП ОПВС:
1. Автоматизация наиболее трудоемких процессов ОП подразумевает возможность автоматического выполнения тех функций ОП, которые легко поддаются автоматизации (дизассемблирование, разбор элементарных идиом, автодокументирование и т.п.);
2. Работа в режиме человеко-компьютерного взаимодействия необходима для выполнения сложных операций, в которых задействован человек (дополнительное комментирование, анализ нестандарт ных фрагментов, семантический анализ, уточнение полученных моделей);
3. Возможность адаптации системы к изменяющимся условиям ОПВС состоит в возможности работы с различным набором исходных данных, различным сценариям и т.п.;
4. Возможность использования различных внешних инструментов и их конфигурирование, то есть возможность изменения состава инструментальных средств, являющихся внешними по отношению к СП ОПВС;
5. Генерация различных форм отчетов по результатам ОП — возможность настройки формата выходных результатов;
6. Гетерогенность - универсальность по отношению к входному языку системы;
7. Взаимодействие с базами данных, в которых хранится необходимая информация (шаблоны ОП, текущее состояние проекта, продукты валидации, системы команд, конфигурационные настройки);
8. Удобство использования характеристика, позволяющая снизить время осваивания системы за счет развитой системы помощи, интуитивно-понятных интерфейсов и экранных форм;
Рассмотрим модели, описанные во второй главе на примере конкретных технологических шагов, осуществляемых системой поддержки автоматизированного обратного проектирования.
В качестве основного примера будем использовать программу управления шаговым двигателем, листинг которой приведен в приложении, однако, если это будет необходимо для обеспечения целостности изложения материала, будем обращаться к фрагментам других программ.
Опираясь на требования, предъявленные к средствам дизассемблирования (1.3.1 «Дизассемблеры»), возможные сценарии поведения для этого этапа можно представить диаграммой деятельности, изображенной на рис. 3.2. Пример сформированного скрипта для управления процессом дизассемблирования приведен в «Приложение 5». Результат дизассемблирования приведен в «Приложение 3. Листинг 1».
В том случае, если исходные данные представляют собой шестнадцате-ричный дамп памяти, то наличие дизассемблера является обязательным. В ходе дизассемблирования решается задача структуризации программы. Результатом структуризации является выделение базовых элементов и компонентов программы. Обеспечение эффективности данного вида преобразований можно достичь с помощью управления следующими параметрами: Тип входного языка: платформа, архитектура, компилятор; Параметры анализатора машинного кода (распознавание библиотечных функций, функций уровня API, формирование имен переменных и т.п.); Различные формы представления результатов дизассемблирования. Для описания типов данных, на данном шаге можно ограничится лишь типами: 6awm(«Tdb»), слово(«Тё\») или двойное слово(«Тс1сі»).
Этап 2. Построение списка функций и ДВФ
Анализ полученного множества ARE позволяет построить список функций и определить их взаимосвязь. Результаты анализа также помещаются в ARE и помечаются типом «TFunc». Элементами подмножества relt в данном случае является перечень адресов вызовов этой функции. Если reli = 0, это означает, что это главная функция. Для всех остальных функций это множество должно быть не пустым.
Дерево вызовов функций представляет собой напрвленный граф, в котором вершины содержат функции, а дуги определяют порядок вызовов этих функций. Для представления такой структуры в восстанавливающей программе используется абстрактный тип данных (АТД) «Дерево» [86], в котором должны быть реализованы методы «Добавить новую вершину», «Добавить связь», «Удалить связь», «Удалить вершину». Пример ДВФ, полученный в результате структурного анализа приведен на рис. 3.4.
Этап 3. Распознавание элементарных идиом. Под элементарной идиомой будем понимать устоявшееся выражение языка, которое может быть преобразовано в эквивалентную запись более удобного вида. При этом должна сохраняться взаимнооднозначность преобразований.
Разработка спецификаций и гипертекстовой документации программного обеспечения ультразвукового расходомера — теплосчетчика
Техническое задание. 1. Наименование темы: "Разработка спецификаций и гипертекстовой документации программного обеспечения ультразвукового расходомера - теплосчетчика". 2. Цель работы: Анализ программ ультразвукового расходомера - теплосчетчика и разработка эксплуатационной документации для сопровождающего программиста. 3. Ожидаемые результаты работы: 1. Построенные схемы программы, отражающей связи модулей и процедур; 2. Сформированное описание программных функций модулей; 4. Научно-техническая и практическая ценность ожидаемых результатов работы: Создание условий для сопровождения и модификации программного обеспечения ультразвукового расходомера - теплосчетчика.
5. Содержание работы (основные этапы): Анализ программных функций и классификация процедур и модулей; Построение схемы программы, отражающей связи модулей и процедур. Формирование описания программных функций модулей.
Исходные данные: исходные тексты модулей программ (34 модуля с общим объемом в 15801 строк, в том числе 10362 операторных строк).
Технология: на первом этапе производится общий анализ с целью выявления наиболее слабо проработанных модулей. Для слабо проработанных модулей проводится детальный анализ с целью формирования оценок качества и их совокупностей и степени различных рисков. В качестве основных критериев качества выбираются следующие: Реализация - степень реализации, выражаемая в процентах; Устойчивость - оценка устойчивости в смысле правильности реализации программных функций при самых различных исходных данных; в качестве факторов неустойчивости выступают проявление побочных эффектов, использование статических переменных вместо локальных, использование «хакерских» приемов программирования; Стиль программирования - оценка адекватности программного кода методом обработки данных (легкость распознавания метода по исходному коду) и применение методов расширяющих повторное использование кода. Сложность — оценка сложности модуля, исходя из которой определяется тщательность тестирования и валидация программного кода, а также возможная декомпозиция модулей.
Результаты работы: проведен общий анализ ПО системы, в ходе которого выявлено назначение модулей системы и оценка каждого модуля по вышеперечисленным параметрам (табл. П1.1), построена схема программы, отражающая связи модулей (рис. Ш.1). Для модуля UI проведен детальный анализ (табл. Ш.2) и построена схема модуля, отражающая связь по данным и управлению (рис. П 1.4), сгенерирован гипертекстовый справочник по функциям и модулям системы.
По результатам анализа: Была получена оценка сложности доработки модуля-1Л, которая по оценке Боэма Б.У. [5] составила 8,69 человеко-месяцев; Проведена оценка технологии разработки ПО ультразвукового расходомера-теплосчетчика и рисков отклонения от традиционных технологий создания ПО встроенных систем; Сформулированы рекомендации по доработке ПО и внесению изменений в технологию проектирования.
В ходе эксперимента исследовался процесс идентификации типового ПР на примере возможных схем реализации алгоритмов численного интегрирования.
Исходными данными для эксперимента выступали наиболее известные реализации алгоритмов вычисления определенного интеграла (метод прямоугольников, метод Симпсона и метод Монте-Карло), полученные с помощью нескольких компиляторов с языка С (Microsoft Visual Studio, GNU С и Borland С) для различных платформ (І8086, Microchip и Infenion С166).
Цель эксперимента: показать возможность построения универсального шаблона» на основе которого можно автоматически идентифицировать отраженное в нем проектное решение и продемонстрировать работоспособность алгоритма распознавания в пределах заданной точности.
Похожие диссертации на Средства автоматизации обратного проектирования встроенных систем
