ВВЕДЕНИЕ
Лекция 1. НАДЕЖНОЕ ПРОГРАММНОЕ СРЕДСТВО КАК ПРОДУКТ ТЕХНОЛОГИИ ПРОГРАММИРОВАНИЯ. ИСТОРИЧЕСКИЙ И СОЦИАЛЬНЫЙ КОНТЕКСТ ПРОГРАММИРОВАНИЯ
1.1. Программа как формализованное описание процесса обработки данных. Программное средство
1.2. Неконструктивность понятия правильной программы
1.3. Надежность программного средства
1.4. Технология программирования как технология разработки надежных программных средств
1.5. Технология программирования и информатизация общества
Литература к лекции 1
Лекция 2. ИСТОЧНИКИ ОШИБОК В ПРОГРАММНОМ СРЕДСТВЕ
2.1. Интеллектуальные возможности человека
2.2. Неправильный перевод как причина ошибок в программном средстве
2.3. Модель перевода
2.4. Основные пути борьбы с ошибками
Литература к лекции 2
Лекция 3. ОБЩИЕ ПРИНЦИПЫ РАЗРАБОТКИ ПРОГРАММНЫХ СРЕДСТВ
3.1. Специфика разработки программных средств
3.2. Жизненный цикл программного средства
3.3. Понятие качества программного средства
3.4. Обеспечение надежности - основной мотив разработки программных средств
3.5. Методы борьбы со сложностью
3.6. Обеспечение точности перевода
3.7. Преодоление барьера между пользователем и разработчиком
3.8. Контроль принимаемых решений
Литература к лекции 3
Лекция 4. ВНЕШНЕЕ ОПИСАНИЕ ПРОГРАММНОГО СРЕДСТВА
4.1. Назначение внешнего описания программного средства и его роль в обеспечении качества программного средства.
4.2. Определение требований к программному средству
4.3. Спецификация качества программного средства
4.4. Функциональная спецификация программного средства
4.5. Методы контроля внешнего описания программного средства
Литература к лекции 4
Лекция 5. МЕТОДЫ СПЕЦИФИКАЦИИ СЕМАНТИКИ ФУНКЦИЙ
5.1. Основные подходы к спецификации семантики функций
5.2. Метод таблиц решений
5.3. Операционная семантика
5.4. Денотационная семантика
5.5. Аксиоматическая семантика
5.6. Языки спецификаций
Литература к лекции 5
Лекция 6. АРХИТЕКТУРА ПРОГРАММНОГО СРЕДСТВА
6.1. Понятие архитектуры программного средства
6.2. Основные классы архитектур программных средств
6.3. Архитектурные функции
6.4. Контроль архитектуры программного средства
Литература к лекции 6
Лекция 7. РАЗРАБОТКА СТРУКТУРЫ ПРОГРАММЫ И МОДУЛЬНОЕ ПРОГРАММИРОВАНИЕ
7.1. Цель модульного программирования
7.2. Основные характеристики программного модуля
7.3. Методы разработки структуры программы
7.4. Контроль структуры программы
Литература к лекции 7
Лекция 8. РАЗРАБОТКА ПРОГРАММНОГО МОДУЛЯ
8.1. Порядок разработки программного модуля
8.2. Структурное программирование
8.3. Пошаговая детализация и понятие о псевдокоде
8.4. Контроль программного модуля
Литература к лекции 8
Лекция 9. ДОКАЗАТЕЛЬСТВО СВОЙСТВ ПРОГРАММ
9.1. Обоснования программ. Формализация свойств программ
9.2. Свойства простых операторов
9.3. Свойства основных конструкций структурного программирования
9.4. Завершимость выполнения программы
9.5. Пример доказательства свойства программы
Литература к лекции 9
Лекция 10. ТЕСТИРОВАНИЕ И ОТЛАДКА ПРОГРАММНОГО СРЕДСТВА
10.1. Основные понятия
10.2. Принципы и виды отладки
10.3. Заповеди отладки
10.4. Автономная отладка модуля
10.5. Комплексная отладка программного средства
Литература к лекции 10
Лекция 11. ОБЕСПЕЧЕНИЕ ФУНКЦИОНАЛЬНОСТИ И НАДЕЖНОСТИ ПРОГРАММНОГО СРЕДСТВА
11.1. Функциональность и надежность как обязательные критерии качества программного средства
11.2. Обеспечение завершенности программного средства
11.3. Обеспечение точности программного средства
11.4. Обеспечение автономности программного средства
11.5. Обеспечение устойчивости программного средства
11.6. Обеспечение защищенности программных средств
Литература к лекции 11
Лекция 12. ОБЕСПЕЧЕНИЕ КАЧЕСТВА ПРОГРАММНОГО СРЕДСТВА
12.1. Общая характеристика процесса обеспечения качества программного средства
12.2. Обеспечение легкости применения программного средства
12.3. Обеспечение эффективности программного средства
12.4. Обеспечение сопровождаемости программного средства
12.5. Обеспечение мобильности программного средства
12.6. Литература к лекции 12
Лекция 13. ДОКУМЕНТИРОВАНИЕ ПРОГРАММНЫХ СРЕДСТВ
13.1. Документация, создаваемая в процессе разработки программных средств.
13.2. Пользовательская документация программных средств.
13.3. Документация по сопровождению программных средств.
Литература к лекции 13.
Лекция 14. АТТЕСТАЦИЯ ПРОГРАММНОГО СРЕДСТВА
14.1. Назначение аттестации программного средства
14.2. Виды испытаний программного средства
14.3. Методы оценки качества программного средства
Литература к лекции 14
Лекция 15. ОЪЕКТНЫЙ ПОДХОД К РАЗРАБОТКЕ ПРОГРАММНЫХ СРЕДСТВ
15.1. Объекты и отношения в программировании. Сущность объектного подхода к разработке программных средств.
15.2. Объекты и субъекты в программировании.
15.3. Объектный и субъектный подходы к разработке программных средств.
15.4. Объектный подход к разработке внешнего описания и архитектуры программного средства.
13.5. Особенности объектно-ориентированного программирования.
Литература к лекции 15.
Лекция 16. КОМПЬЮТЕРНАЯ ПОДДЕРЖКА РАЗРАБОТКИ И СОПРОВОЖДЕНИЯ ПРОГРАММНЫХ СРЕДСТВ
16.1. Инструменты разработки программных средств.
16.2. Инструментальные среды разработки и сопровождения программных средств.
16.3. Инструментальные среды программирования.
16.4. Понятие компьютерной технологии разработки программных средств и ее рабочие места.
16.5. Инструментальные системы технологии программирования.
Литература к лекции 16.
Настоящее учебное пособие представляет собой расширение и новую редакцию конспекта лекций , читавшихся в течении ряда лет на факультете Вычислительной математики и кибернетики МГУ:
Е.А. Жоголев. Введение в технологию программирования (конспект лекций). - М.: "ДИАЛОГ-МГУ", 1994.
По содержанию оно полностью соответствует обновленной программе курса "Технология программирования", утвержденного для студентов программистских кафедр.
Хотя понятие технологии в русском языке имеет ясное определение, понятие технологии программирования требует некоторого уточнения прежде всего из-за необходимости определения, что следует считать продуктом этой технологии. Кроме того появление этого термина в русскоязычной научной литературе вызвано в значительной степени не всегда адекватным переводом иноязычной литературы по программированию, что привело к различным определениям (толкованиям) этого понятия. Это уточнение делается в первой лекции настоящего курса.
Тем не менее уже сейчас можно сказать (в соответствии с общепринятым в русском языке пониманием термина "технология"), что предметом настоящего курса лекций является изучение процессов, приводящих к созданию требуемого программного "продукта". В курсе обсуждаются вопросы, из каких процессов (которые можно назвать технологическими) состоит эта технология, на каких принципах они строятся, какие методы и инструментальные средства в них используются.
Содержание курса сложилось в результате критического анализа многих научных источников, часто противоречивших друг другу, с учетом опыта программирования автора настоящего курса, а также
результатов исследований, проведенных на кафедре системного программирования факультета ВМиК МГУ (в частности, по проблеме качества программного обеспечения). Расширение пособия по сравнению с ранее изданным было связано с включением в обновленную программу курса вопросов обеспечения качества программных продуктов и их документирования, объектного подхода к их разработке, компьютерной технологии и компьютерной поддержки разработки программных продуктов, а также социально-этических вопросов программирования.
Курс рассчитан на студентов, уже прослушавших общий курс по программированию и умеющих работать на компьютере. Его целью является помочь лицам, приступающим к разработке больших программных "продуктов", рационально организовать свой программистский труд.
Понятие информационной среды процесса обработки данных. Программа как формализованное описание процесса. Понятие о программном средстве. Понятие ошибки в программном средстве. Неконструктивность понятия правильной программы. Надежность программного средства. Технология программирования как технология разработки надежных программных средств. Роль в обществе компьютеров и программирования, информатизация общества. Взаимосвязь программирования и других областей знания. Применение, злоупотребление и границы компьютерной техники.
Целью программирования является описание процессов обработки данных (в дальнейшем - просто процессов). Согласно ИФИПа [1.1]: данные - это представление фактов и идей в формализованном виде, пригодном для передачи и переработке в некоем процессе, а информация - это смысл, который придается данным при их представлении. Обработка данных - это выполнение систематической последовательности действий с данными. Данные представляются и хранятся на т.н. носителях данных. Совокупность носителей данных, используемых при какой-либо обработке данных, будем называть информационной средой. Набор данных, содержащихся в какой-либо момент в информационной среде, будем называть состоянием этой информационной среды. Процесс можно определить как последовательность сменяющих друг друга состояний некоторой информационной среды.
Описать процесс - значит определить последовательность состояний заданной информационной среды. Если мы хотим, чтобы по заданному описанию требуемый процесс порождался автоматически на каком-либо компьютере, необходимо, чтобы это описание было формализованным. Такое описание называется программой. С другой стороны, программа должна быть понятной и человеку, так как и при разработке программ, и при их использовании часто приходится выяснять, какой именно процесс она порождает. Поэтому программа составляется на удобном для человека формализованном языке программирования, с которого она автоматически переводится на язык соответствующего компьютера с помощью другой программы, называемой транслятором. Человеку (программисту), прежде чем составить программу на удобном для него языке программирования, приходится проделывать большую подготовительную работу по уточнению постановки задачи, выбору метода ее решения, выяснению специфики применения требуемой программы, прояснению общей организации разрабатываемой программы и многое другое. Использование этой информации может существенно упростить задачу понимания программы человеком, поэтому весьма полезно ее как-то фиксировать в виде отдельных документов (часто не формализованных, рассчитанных только для восприятия человеком).
Обычно программы разрабатываются в расчете на то, чтобы ими могли пользоваться люди, не участвующие в их разработке (их называют пользователями). Для освоения программы пользователем помимо ее текста требуется определенная дополнительная документация. Программа или логически связанная совокупность программ на носителях данных, снабженная программной документацией, называется программным средством (ПС). Программа позволяет осуществлять некоторую автоматическую обработку данных на компьютере. Программная документация позволяет понять, какие функции выполняет та или иная программа ПС, как подготовить исходные данные и запустить требуемую программу в процесс ее выполнения, а также: что означают получаемые результаты (или каков эффект выполнения этой программы). Кроме того, программная документация помогает разобраться в самой программе, что необходимо, например, при ее модификации.
Таким образом, можно считать, что продуктом технологии программирования является ПС, содержащее программы, выполняющие требуемые функции. Здесь под "программой" часто понимают правильную программу, т.е. программу, не содержащую ошибок. Однако, понятие ошибки в программе трактуется в среде программистов неоднозначно. Согласно Майерсу [1.2] будем считать, что в программе имеется ошибка, если она не выполняет того, что разумно ожидать от нее пользователю. "Разумное ожидание" пользователя формируется на основании документации по применению этой программы. Следовательно, понятие ошибки в программе является существенно не формальным. В этом случае правильнее говорить об ошибке в ПС. Разновидностью ошибки в ПС является несогласованность между программами ПС и документацией по их применению. В работе [1.3] выделяется в отдельное понятие частный случай ошибки в ПС, когда программа не соответствует своей функциональной спецификации (описанию, разрабатываемому на этапе, предшествующему непосредственному программированию). Такая ошибка в указанной работе называется дефектом программы. Однако выделение такой разновидности ошибки в отдельное понятие вряд ли оправданно, так как причиной ошибки может оказаться сама функциональная спецификация, а не программа.
В связи с тем, что задание на ПС обычно формулируется не формально, а также из-за неформализованности понятия ошибки в ПС, нельзя доказать формальными методами (математически) правильность ПС. Нельзя показать правильность ПС и тестированием: как указал Дейкстра [1.4], тестирование может лишь продемонстрировать наличие в ПС ошибки. Поэтому понятие правильной ПС неконструктивно в том смысле, что после окончания работы над созданием ПС мы не сможем убедиться, что достигли цели.
Альтернативой правильного ПС является надежное ПС. Надежность ПС - это его способность безотказно выполнять определенные функции при заданных условиях в течение заданного периода времени с достаточно большой вероятностью [1.5]. При этом под отказом в ПС понимают проявление в нем ошибки [1.2]. Таким образом, надежная ПС не исключает наличия в ней ошибок - важно лишь, чтобы эти ошибки при практическом применении этого ПС в заданных условиях проявлялись достаточно редко. Убедиться, что ПС обладает таким свойством можно при его испытании путем тестирования, а также при практическом применении. Таким образом, фактически мы можем разрабатывать лишь надежные, а не правильные ПС.
Разрабатываемая ПС может обладать различной степенью надежности. Как измерять эту степень? Так же как в технике, степень надежности можно характеризовать [1.2] вероятностью работы ПС без отказа в течении определенного периода времени. Однако в силу специфических особенностей ПС определение этой вероятности наталкивается на ряд трудностей по сравнению с решением этой задачи в технике. Позже мы вернемся к более обстоятельному обсуждению этого вопроса.
При оценке степени надежности ПС следует также учитывать последствия каждого отказа. Некоторые ошибки в ПС могут вызывать лишь некоторые неудобства при его применении, тогда как другие ошибки могут иметь катастрофические последствия, например, угрожать человеческой жизни. Поэтому для оценки надежности ПС иногда используют дополнительные показатели, учитывающие стоимость (вред) для пользователя каждого отказа.