ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ОБРАЗОВАНИЮ ГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ «САМАРСКИЙ ГОСУДАРСТВЕННЫЙ АЭРОКОСМИЧЕСКИЙ УНИВЕРСИТЕТ имени академика С. П. Королева (СГАУ)»

Л. С. ЗЕЛЕНКО ТЕХНОЛОГИИ ПРОГРАММИРОВАНИЯ И ПРОГРАММНАЯ ИНЖЕНЕРИЯ (Часть 2) Утверждено Редакционно-издательским советом университета в качестве учебного пособия

САМАРА Издательство СГАУ 2007

УДК 004.4 (075)

ББК

З 484

И нновационная образовательная программа «Развитие центра компетенции и подготовка специалистов мирового уровня в области аэрокосмических и геоинформационных технологий»

Рецензенты: д-р техн. наук, проф. М. А. Кораблин д-р техн. наук, проф. С. А. Прохоров

Л. С. Зеленко

З 484 Технологии программирования и программная инженерия (часть 2): учебное пособие/ Л. С. Зеленко. – Самара: Изд-во Самар. гос. аэрокосм. ун-та, 2007. - 96 с.: ил.

ISBN

В пособии подробно описываются принципы разработки сложных программных систем: от проектирования до тестирования и отладки. Особое внимание уделено основам тестирования программного обеспечения и разработке интерфейса. Также рассматриваются вопросы документирования программного обеспечения. Содержание учебного пособия является расширенным вариантом курса лекций, который читает автор на факультете информатики СГАУ.

Рекомендуется для использования в учебном процессе специальностей 010501 – «Прикладная математика и информатика», 010600 – «Прикладная математика и физика», 010400 – «Информационные технологии», а также студентам, обучающимся по специальностям, связанным с информатикой, информационными технологиями и разработкой прикладных программных систем.

УДК 004.4 (075)

ББК

ISBN © Зеленко Л.С., 2006 © Самарский государственный аэрокосмический университет, 2006

Оглавление

предисловие 4

предисловие 4

введение 5

введение 5

1 технологии отладки и тестирования программных систем 8

1 технологии отладки и тестирования программных систем 8

1.1 Понятие ошибки 8

1.1 Понятие ошибки 8

1.1.1 Типы ошибок в комплексах программ 8

1.1.2 Классификация ошибок 11

1.2 Когда следует прекращать тестирование программ 12

1.2 Когда следует прекращать тестирование программ 12

1.3 Технологии программирования: этапы развития и базовые методологии программирования 20

1.3 Технологии программирования: этапы развития и базовые методологии программирования 20

1.4 Иерархия понятий в технологии программирования 33

1.4 Иерархия понятий в технологии программирования 33

2 ОБЩИЕ ПРИНЦИПЫ РАЗРАБОТКИ сложных ПРОГРАММНЫХ систем 41

2 ОБЩИЕ ПРИНЦИПЫ РАЗРАБОТКИ сложных ПРОГРАММНЫХ систем 41

2.1 Особенности современных программных систем как объектов разработки 41

2.1 Особенности современных программных систем как объектов разработки 41

2.2 Показатели качества программных систем 43

2.2 Показатели качества программных систем 43

2.3 Проблемы разработки сложных программных систем 47

2.3 Проблемы разработки сложных программных систем 47

2.4 Структура сложных систем 50

2.4 Структура сложных систем 50

2.5 Основные подходы к созданию сложных программных систем 52

2.5 Основные подходы к созданию сложных программных систем 52

3 жизненный цикл программных систем 65

3 жизненный цикл программных систем 65

3.1 Стандарты и проблемы жизненного цикла ПО 66

3.1 Стандарты и проблемы жизненного цикла ПО 66

3.2 Жизненный цикл и этапы разработки программного обеспечения 69

3.2 Жизненный цикл и этапы разработки программного обеспечения 69

3.3 Модель жизненного цикла ПО 76

3.3 Модель жизненного цикла ПО 76

СПИСОК ЛИТЕРАТУРЫ 95

СПИСОК ЛИТЕРАТУРЫ 95

список терминов 97

список терминов 97

перечень ошибок 104

перечень ошибок 104

предисловие

Настоящее учебное пособие является продолжением расширенным вариантом курса лекций «Технологии программирования», который читается автором в течение последних лет на кафедрах информационных систем и технологий и программных систем СГАУ. Содержание курса сложилось в результате анализа многих научных источников, обобщения и методического осмысления опыта, который был накоплен специалистами по разработке программного обеспечения, а также с учетом опыта работы автора данного курса.

Появление в новом государственном образовательном стандарте (направления 510200 «Прикладная информатика и математика», 511900 «Информационные технологии», 552800 «Информатика и вычислительная техника») дисциплины «Технологии программирования» позволило в полном объеме рассмотреть все вопросы, связанные с разработкой сложных программных систем, до этого элементы технологий рассматривались лишь в курсе «Алгоритмические языки и программирование».

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

введение

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

Быстрое увеличение сложности и размеров современных комплексов программ при одновременном повышении ответственности выполняемых функций резко повысило требования со стороны пользователей к их качеству, надежности функционирования и безопасности применения. Разработку сложных программных систем уже невозможно было вести «по старинке», без использования эффективных инструментальных средств и средств автоматизации всех этапов разработки. Время талантливых одиночек прошло, в разработке стали принимать участие большие коллективы программистов, работу которых необходимо было рационально организовывать.

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

При индустриальном подходе к разработке и сопровождению ПО особый вес приобретают технологические характеристики разрабатываемых программ, для получения качественных программных продуктов необходимо руководствоваться следующими принципами [1]:

• эффективностью – результаты должны отвечать заданным требованиям и стандартам в условиях ограниченных ресурсов;

• практичностью – результаты должны иметь конкретных заказчиков;

• фундаментальностью – результаты должны базироваться на знаниях фундаментальных наук;

• наследуемостью – результаты должны обобщать накопленный опыт, исключая деятельность «c нуля»;

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

Начало работ в данной области относится к концу 60-х – началу 70-х годов, когда рост сложности программных систем (ПС) стал приводить к снижению качества их функционирования и появлению большого количества ошибок. Сложность ПС постоянно увеличивалась из-за:

• увеличения объемов кода (миллионы строк);

• увеличения количества связей между элементами систем;

• увеличения количества разработчиков (сотни человек);

• увеличения количества пользователей (сотни и тысячи).

Первые существенные результаты при решении данной проблемы были получены А. П. Ершовым, В. М. Глушковым, Е. А. Жоголевым, В. В. Липаевым, в работах которых описаны базовые методологии и технологии программирования того времени: структурное программирование и методология процедурной (алгоритмической) декомпозиции. К 90-м годам появилась новая парадигма в программировании, построенная на объектной декомпозиции предметной области, которая привела к методологии объектно-ориентированного анализа и проектирования. Появляется понятие программной инженерии как практического приложения научных знаний в проектировании и конструировании ПС, а также для создания документации, необходимой для их разработки, эксплуатации и сопровождения.

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

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

1. Технологии отладки и тестирования программных систем

Вводные слова про тестирование и отладку

1. Понятие ошибки

Как уже говорилось ранее, продуктом технологии программирования является ПС, содержащая программы, выполняющие требуемые функции. Здесь под «программой» часто понимают правильную программу, т.е. программу, не содержащую ошибок. Однако понятие ошибки в программе трактуется в среде программистов неоднозначно. Согласно Г. Майерсу [Искусство тестирования программ, стр. 10-13] будем считать, что в программе имеется ошибка (software error), если она не выполняет того, что разумно ожидать от нее пользователю. «Разумное ожидание» пользователя формируется на основании документации по применению этой программы. Следовательно, понятие ошибки в программе является существенно не формальным, тем более ошибок в документации бывает не меньше, а зачастую больше, чем в самих программах. В ПС программы и документация взаимно увязаны и образуют некоторую целостность, поэтому правильнее говорить об ошибке не в программе, а в ПС в целом.

Так как задание на ПС обычно формулируется не формально, а также из-за того, что понятия ошибки в ПС не формализовано, то нельзя доказать формальными методами (математически) правильность ПС. Нельзя показать правильность ПС и тестированием: как указал Дейкстра [1.4 Э. Дейкстра. Заметки по структурному программированию// У. Дал, Э. Дейкстра, К. Хоор. Структурное программирование. - М.: Мир, 1975. - С. 7-97.], тестирование может лишь продемонстрировать наличие в ПС ошибки. Поэтому понятие правильной ПС неконструктивно в том смысле, что после окончания работы над созданием ПС мы не сможем убедиться, что достигли цели.

1.1.1 Типы ошибок в комплексах программ

Для анализа методов проектирования надежного программного обеспечения необходимо выявить основные типы ошибок и характеристик их изменения в процессе отладки [Липаев Надежность… АСУ].

С точки зрения технологии разработки программ ошибки можно разделить на следующие типы:

• Программные, вызванные неправильной записью на языке программирования и ошибками трансляции;

• Алгоритмические, связанные с неполным формированием необходимых условий решения и некорректной постановкой задач;

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

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

Алгоритмические ошибки труднее поддаются обнаружению методами формального автоматического контроля, чем предыдущий тип ошибок. Трудоемкость их обнаружения и локализации определяется отсутствием строго формальных постановок задач, которые можно использовать в качестве эталона дл сравнения с ними результатов функционирования разработанных алгоритмов. К алгоритмическим относятся ошибки, обусловленные некорректной постановкой функциональных задач, когда не полностью оговорены условия, необходимые для получения правильного результата. Эти условия формируются и уточняются в процессе тестирования и выявления ошибок в результатах функционирования алгоритмов. Ошибки, обусловленные неполным учетом условий решения задач, составляют до 70% всех алгоритмических ошибок, или около 30% всех ошибок. К алгоритмическим относятся ошибки сопряжения функциональных подпрограмм, кроме того, алгоритмические ошибки проявляются в неполном учете диапазонов изменения переменных, в неправильной оценке точности используемых и получаемых дисциплин, в неправильном учете корреляции между различными переменными, в неадекватном представлении условий решения задач в виде схемы, подлежащих программированию. Процесс обнаружения и выявления таких ошибок во многом сливается с процессом уточнения постановки задачи и является, по существу, частью процесса разработки алгоритмов. Эти обстоятельства являются причиной того, что для исправления одной алгоритмической ошибки приходится в среднем исправлять около 14 операторов.

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

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

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

При автономной и в начале комплексной отладки доля системных ошибок невелика (примерно 10%), но она существенно возрастает (до 35-45%) на завершающих этапах комплексной отладки. В процессе эксплуатации системные ошибки являются преобладающими (до 80% всех ошибок). Следует также большое количество операторов при исправлении каждой ошибки (около 25 операторов на одну ошибку).