Исторический и социальный контекст программирования. Источники ошибок в программном средстве: разработка и обеспечение надежности. Внешнее описание и понятие архитектуры, спецификация семантики функций. Объектный подход к разработке программных средств.
Поэтому программа составляется на удобном для человека формализованном языке программирования, с которого она автоматически переводится на язык соответствующего компьютера с помощью другой программы, называемой транслятором. Человеку (программисту), прежде чем составить программу на удобном для него языке программирования, приходится проделывать большую подготовительную работу по уточнению постановки задачи, выбору метода ее решения, выяснению специфики применения требуемой программы, прояснению общей организации разрабатываемой программы и многое другое. Программная документация позволяет понять, какие функции выполняет та или иная программа ПС, как подготовить исходные данные и запустить требуемую программу в процесс ее выполнения, а также: что означают получаемые результаты (или каков эффект выполнения этой программы). Таким образом, можно считать, что продуктом технологии программирования является ПС, содержащее программы, выполняющие требуемые функции. Здесь под "программой" часто понимают правильную программу, т.е. программу, не содержащую ошибок.Самообнаружение ошибки в программе означает, что программа содержит средства обнаружения отказа в процессе ее выполнения. Самоисправление ошибки в программе означает не только обнаружение отказа в процессе ее выполнения, но и исправление последствий этого отказа, для чего в программе должны иметься соответствующие средства. Обеспечение устойчивости программы к ошибкам означает, что в программе содержатся средства, позволяющие локализовать область влияния отказа программы, либо уменьшить его неприятные последствия, а иногда предотвратить катастрофические последствия отказа. Связано это, во-первых, с тем, что многие простые методы, используемые в технике в рамках этих подходов, неприменимы в программировании, например, дублирование отдельных блоков и устройств (выполнение двух копий одной и той же программы всегда будет приводить к одинаковому эффекту - правильному или неправильному). Но так как через этот документ передается от заказчика (пользователя) к разработчику основная информация относительно требуемого ПС, то формирование этого документа представляет собой довольно длительный и трудный итерационный процесс взаимодействия между заказчиком и разработчиком, с которого и начинается этап разработки требований к ПС [4.2].Для этого такую программу разрабатывают по частям, которые называются программными модулями [7.1, 7.2]. А сам такой метод разработки программ называют модульным программированием [7.3]. Это означает, что каждый программный модуль программируется, компилируется и отлаживается отдельно от других модулей программы, и тем самым, физически разделен с другими модулями программы.Таким является сцепление двух модулей, когда один из них имеет прямые ссылки на содержимое другого модуля (например, на константу, содержащуюся в другом модуле). Единственным видом сцепления модулей, который рекомендуется для использования современной технологией программирования, является параметрическое сцепление (сцепление по данным по Майерсу [7.5]) - это случай, когда данные передаются модулю либо при обращении к нему как значения его параметров, либо как результат его обращения к другому модулю для вычисления некоторой функции. Другими словами, каждый модуль может обращаться к подчиненным ему модулям, т.е. выражается через эти модули. На первый взгляд такой порядок разработки программы кажется вполне естественным: каждый модуль при программировании выражается через уже запрограммированные непосредственно подчиненные модули, а при тестировании использует уже отлаженные модули. Во-первых, для программирования какого-либо модуля совсем не требуется текстов используемых им модулей - для этого достаточно, чтобы каждый используемый модуль был лишь специфицирован (в объеме, позволяющем построить правильное обращение к нему), а для тестирования его возможно (и даже, как мы покажем ниже, полезно) используемые модули заменять их имитаторами (заглушками).Пусть P, Q и R - предикаты над информационной средой, а S1 и S2 - обобщенные операторы, обладающие соответственно свойствами {P}S{Q} и {Q}S2{R}. Так как по семантике составного оператора после выполнения оператора S1 будет выполняться оператор S2, то предикат Q будет истинен и перед выполнением оператора S2. Следовательно, после выполнения оператора S2 в силу его свойства будет истинен предикат R, а так как оператор S2 завершает выполнение составного оператора (в соответствии с его семантикой), то предикат R будет истинен и после выполнения данного составного оператора, что и требовалось доказать. Если же перед выполнением условного оператора предикат P будет ложен (а Q, по-прежнему, истинен), то выполнение условного оператора в соответствии с его семантикой сводится к выполнению оператора S2. P1=>P и Q=>Q1, и пусть для оператора S имеет место свойство {P}S{Q}.Тогда имеет место свойство {P1}S{Q1} .
План
СОДЕРЖАНИЕ
ВВЕДЕНИЕ
Лекция 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.
Лекция 17. ОБЯЗАННОСТИ И ОТВЕТСТВЕННОСТЬ ПРОГРАММИСТОВ. ИНТЕЛЛЕКТУАЛЬНАЯ СОБСТВЕННОСТЬ.
Вы можете ЗАГРУЗИТЬ и ПОВЫСИТЬ уникальность своей работы
