НАДЕЖНОЕ ПРОГРАММНОЕ СРЕДСТВО КАК ПРОДУКТ ТЕХНОЛОГИИ ПРОГРАММИРОВАНИЯ. ИСТОРИЧЕСКИЙ И СОЦИАЛЬНЫЙ КОНТЕКСТ ПРОГРАММИРОВАНИЯ. ИСТОЧНИКИ ОШИБОК В ПРОГРАММНОМ СРЕДСТВЕ

СОДЕРЖАНИЕ

ВВЕДЕНИЕ
Лекция 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. ОБЯЗАННОСТИ И ОТВЕТСТВЕННОСТЬ ПРОГРАММИСТОВ. ИНТЕЛЛЕКТУАЛЬНАЯ СОБСТВЕННОСТЬ.


ВВЕДЕНИЕ

Хотя понятие технологии в русском языке имеет ясное определение, понятие технологии программирования требует некоторого уточнения прежде всего из-за необходимости определения, что следует считать продуктом этой технологии. Кроме того, появление этого термина в русскоязычной научной литературе вызвано в значительной степени не всегда адекватным переводом иноязычной литературы по программированию, что привело к различным определениям (толкованиям) этого понятия. Это уточнение делается в первой лекции настоящего курса.
Тем не менее, уже сейчас можно сказать (в соответствии с общепринятым в русском языке пониманием термина "технология"), что предметом настоящего курса лекций является изучение процессов, приводящих к созданию требуемого программного "продукта". В курсе обсуждаются вопросы, из каких процессов (которые можно назвать технологическими) состоит эта технология, на каких принципах они строятся, какие методы, и инструментальные средства в них используются.
Курс рассчитан на студентов, уже прослушавших общий курс по программированию и умеющих работать на компьютере. Его целью является помочь лицам, приступающим к разработке больших программных "продуктов", рационально организовать свой программистский труд.


Лекция 1. НАДЕЖНОЕ ПРОГРАММНОЕ СРЕДСТВО КАК ПРОДУКТ ТЕХНОЛОГИИ ПРОГРАММИРОВАНИЯ. ИСТОРИЧЕСКИЙ И СОЦИАЛЬНЫЙ КОНТЕКСТ ПРОГРАММИРОВАНИЯ
Понятие информационной среды процесса обработки данных. Программа как формализованное описание процесса. Понятие о программном средстве. Понятие ошибки в программном средстве. Неконструктивность понятия правильной программы. Надежность программного средства. Технология программирования как технология разработки надежных программных средств. Роль в обществе компьютеров и программирования, информатизация общества. Взаимосвязь программирования и других областей знания. Применение, злоупотребление и границы компьютерной техники.





Программа как формализованное описание процесса обработки данных. Программное средство.

Описать процесс - значит определить последовательность состояний заданной информационной среды. Если мы хотим, чтобы по заданному описанию требуемый… Обычно программы разрабатываются в расчете на то, чтобы ими могли пользоваться…





Неконструктивность понятия правильной программы.

В связи с тем, что задание на ПС обычно формулируется не формально, а также из-за неформализованности понятия ошибки в ПС, нельзя доказать…





Надежность программного средства.

Разрабатываемая ПС может обладать различной степенью надежности. Как измерять эту степень? Так же как в технике, степень надежности можно… При оценке степени надежности ПС следует также учитывать последствия каждого…





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

В литературе имеются и другие, несколько отличающиеся, определения технологии программирования. Эти определения обсуждаются в работе [1.7].… сопровождению и изъятию из обращения программных средств [1.7]. Именно… Не следует также путать технологию программирования с методологией программирования [1.8]. Хотя в обоих случаях…





Технология программирования и информатизация общества.

Сделаем краткую характеристику развития программирования по десятилетиям.
В 50-е годы мощность компьютеров была невелика (компьютеры первого поколения),… В 60-е годы можно было наблюдать бурное развитие и широкое использование языков программирования высокого уровня…

Литература к лекции 1.

1.1. И.Г.Гоулд, Дж.С.Тутилл. Терминологическая работа IFIP (Международная федерация по обработке информации) и ICC (Международный вычислительный центр)// Журн. вычисл. матем. и матем. физ., 1965, #2. - С. 377-386.
1.2. Г.Майерс. Надежность программного обеспечения. - М.: Мир, 1980.
1.3. Ian Sommerville. Software Engineering. - Addison-Wesley Publishing Company, 1992. - P.
1.4. Э. Дейкстра. Заметки по структурному программированию// У. Дал, Э. Дейкстра, К. Хоор. Структурное программирование. - М.: Мир, 1975. - С. 7-97.
1.5. Criteria for Evalution of Software. - ISO TC97/SC7 #367 (Supersedes Document #327).
1.6. С.И. Ожегов. Словарь русского языка. - М.: Советская энциклопедия, 1975.
1.7. Ф.Я. Дзержинский, И.М. Калиниченко. Дисциплина программирования Д: концепция и опыт реализации методических средств программной инженерии. - М.: ЦНИИ информации и технико-экономических исследований по атомной науке и технике, 1988. - С. 9-16.
1.8. В. Турский. Методология программирования. - М.: Мир, 1981.
1.9. Г. Буч. Объектно-ориентированное проектирование с примерами применения: пер. с англ. - М.: Конкорд, 1992.
1.10. Е.А. Жоголев. Система программирования с использованием библиотеки подпрограмм// Система автоматизация программирования. - М.: Физматгиз, 1961. С. 15-52.
1.11. Ф.П. Брукс, мл. Как проектируются и создаются программные комплексы/ Пер. с англ. А.П. Ершова. - М.: Наука, 1979.
1.12. R.C. Holt. Structure of Computer Programs: A Survey// Proceedings of the IEEE, 1975, 63(6). - P. 879-893.
1.13. Дж. Хьюз, Дж. Мичтом. Структурный подход к программированию. М.: Мир, 1980.
1.14. Е.А. Жоголев. Технологические основы модульного программирования//Программирование, 1980, #2. - С. 44-49.
1.15. Б. Боэм, Дж. Браун, Х. Каспар и др. Характеристики качества программного обеспечения. - М.: Мир, 1981.
1.16. В.В. Липаев. Качество программного обеспечения. - М.: Финансы и статистика, 1983.
1.17. Б. Шнейдерман. Психология программирования. - М.: Радио и связь, 1984.
1.18. Revised version of DP9126 - Criteria of the Evaluation of Software Quality Characteristics. ISO TC97/SC7 #610. - Part 6.
1.19. В.Ш. Кауфман. Языки программирования. Концепции и принципы. М.: Радио и связь, 1993.
1.20. Требования и спецификации в разработке программ: пер. с англ. - М.: Мир, 1984.
1.21. В.Н. Агафонов. Спецификация программ: понятийные средства и их организация. - Новосибирск: Наука (Сибирское отделение), 1987.


Лекция 2.



ИСТОЧНИКИ ОШИБОК В ПРОГРАММНЫХ СРЕДСТВАХ


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





Интеллектуальные возможности человека.

· способность к перебору,
· способность к абстракции,
· способность к математической индукции.






Неправильный перевод как причина ошибок в программных средствах.


Рис. 2.1. Грубая схема разработки и применения ПС.
На каждом из этих этапов перевод информации может быть осуществлен неправильно, например, из-за неправильного…





Модель перевода.


Рис.2.2. Модель перевода.
· он получает информацию, содержащуюся в представлении A, с помощью своего читающего механизма R;






Основные пути борьбы с ошибками.

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

Литература к лекции 2.

2.1. Э. Дейкстра. Заметки по структурному программированию// У. Дал, Э. Дейкстра, К. Хоор. Структурное программирование. - М.: Мир, 1975. - С. 7-19.
2.2. Е.А. Жоголев. Технологические основы модульного программирования. //Программирование, 1980, #2. - С. 44-49.
2.3. Г. Майерс. Надежность программного обеспечения. - М.: Мир, 1980. - С. 22-28.

Лекция 3. ОБЩИЕ ПРИНЦИПЫ РАЗРАБОТКИ ПРОГРАММНЫХ СРЕДСТВ
Специфика разработки программных средств. Жизненный цикл программного средства. Понятие качества программного средства. Обеспечение надежности - основной мотив разработки программного средства. Методы борьбы со сложностью. Обеспечение точности перевода. Преодоление барьера между пользователем и разработчиком. Обеспечение контроля правильности принимаемых решений.





Специфика разработки программных средств.

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





Жизненный цикл программного средства.

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





Понятие качества программного средства.

Совокупность свойств ПС, которая образует удовлетворительное для пользователя качество ПС, зависит от условий и характера эксплуатации этого ПС,… · функциональность,
· надежность,






Обеспечение надежности - основной мотив разработки программных средств.

· предупреждение ошибок;
· самообнаружение ошибок;
· самоисправление ошибок;






Методы борьбы со сложностью.

· обеспечения независимости компонент системы;
· использование в системах иерархических структур.
Обеспечение независимости компонент означает разбиение системы на такие части, между которыми должны остаться по…





Обеспечение точности перевода.

· Поймите задачу;
· Составьте план (включая цели и методы решения);
· Выполните план (проверяя правильность каждого шага);






Преодоление барьера между пользователем и разработчиком.

Как обеспечить, чтобы ПС выполняла то, что пользователю разумно ожидать от нее? Для этого необходимо правильно понять, во-первых, чего хочет пользователь, и, во-вторых, его уровень подготовки и окружающую его обстановку. Поэтому следует - привлекать пользователя в процессы принятия решений при разработке ПС, - тщательно освоить особенности его работы (лучше всего - побывать в его "шкуре").





Контроль принимаемых решений.

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


Литература к лекции 3.

3.1. Е.А. Жоголев. Введение в технологию программирования (конспект лекций). - М.: "ДИАЛОГ-МГУ", 1994.
3.2. М. Зелковец, А. Шоу, Дж. Гэннон. Принципы разработки программного обеспечения. - М.: Мир, 1982. - С. 11.
3.3. К. Зиглер. Методы проектирования программных систем. - М.: Мир, 1985. - С. 15-23.
3.4. Дж. Фокс. Программное обеспечение и его разработка. - М.: Мир, 1985. - С. 53-67, 125-130.
3.5. Ian Sommerville. Software Engineering. - Addison-Wesley Publishing Company, 1992. - P. 5-10.
3.6. Criteria for Evaluation of Software. ISO TC97/SC7 #383.
3.7. Revised version of DP9126 - Criteria of the Evaluation of Software Quality Characteristics. ISO TC97/SC7 #610. - Part 6.
3.8. Б. Боэм, Дж. Браун, Х. Каспар и др. Характеристики качества программного обеспечения. - М.: Мир, 1981. - С. 17-24.
3.9. В.В. Липаев. Качество программного обеспечения. - М.: Финансы и статистика, 1983. - С. 18-30.
3.10. Б. Шнейдерман. Психология программирования. - М.: Радио и связь, 1984. - С. 99-103.
3.11. Г. Майерс. Надежность программного обеспечения. - М.: Мир, 1980. С. 32 - 48.
3.12. Д. Пойа. Как решать задачу. - М.: Наука, 1961

Лекция 4. ВНЕШНЕЕ ОПИСАНИЕ ПРОГРАММНОГО СРЕДСТВА
Понятие внешнего описания, его назначение и роль в обеспечении качества программного средства. Определение требований к программному средству. Спецификация качества программного средства. Основные примитивы качества программного средства. Функциональная спецификация программного средства. Контроль внешнего описания.





Назначение внешнего описания программного средства и его роль в обеспечении качества программного средства.

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





Определение требований к программному средству.

Определение требований представляет собой смесь фрагментов на естественном языке, различных таблиц и диаграмм. Такая смесь, должна быть понятной… Неправильное понимание требований заказчиком, пользователями и разработчиками… Известны три способа определения требований к ПС [4.2]:






Спецификация качества программного средства.

Для конкретизации качества ПС по каждому из критериев используется стандартизованный набор достаточно простых свойств ПС [4.3-4.6], однозначно… Функциональность: завершенность.
Надежность: завершенность, точность, автономность, устойчивость, защищенность.






Функциональная спецификация программного средства.

Функциональная спецификация состоит из трех частей:
· описания внешней информационной среды, к которой должны применяться… · определение функций ПС, определенных на множестве состояний этой информационной среды (такие функции будем называть…





Методы контроля внешнего описания программного средства.

· статический просмотр,
· смежный контроль,
· пользовательский контроль,


Литература к лекции 4.

4.1. Ian Sommerville. Software Engineering. - Addison-Wesley Publishing Company, 1992. - P.
4.2. Г. Майерс. Надежность программного обеспечения. - М.: Мир, 1980. - С. 49-77.
4.3. Е.А. Жоголев. Введение в технологию программирования (конспект лекций). - М.: "ДИАЛОГ-МГУ", 1994.
4.4. Criteria for Evaluation of Software. ISO TC97/SC7 #383.
4.5. Revised version of DP9126 - Criteria of the Evaluation of Software Quality Characteristics. ISO TC97/SC7 #610. - Part 6.
4.6. Б. Боэм, Дж. Браун, Х. Каспар и др. Характеристики качества программного обеспечения. - М.: Мир, 1981. - С. 61-87.

Лекция 5. МЕТОДЫ СПЕЦИФИКАЦИИ СЕМАНТИКИ ФУНКЦИЙ
Основные подходы к спецификации семантики функций. Табличный подход, метод таблиц решений. Алгебраический подход: операционная, денотационная и аксиоматическая семантика.





Основные подходы к спецификации семантики функций.

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






Метод таблиц решений.

Верхняя часть этой таблицы определяет различные ситуации, в которых требуется выполнять некоторые действия (операции). Каждая строка этой части…
Переменные/условия
Ситуации (комбинации значений)
… Табл. 5.1. Общая схема таблиц решений.






Операционная семантика.

f1(x1, x2, ... , xk)= E1,
f2(x1, x2, ... , xk)= E2,
. . . . . . . . . . . . .






Денотационная семантика.

Основные идеи денотационной семантики проиллюстрируем на более простом случае, когда система равенств (5.3) является системой языковых уравнений:
… X1= phi[1,1]  phi[1,2]  ...  phi[1,k1],
X2= phi[2,1]  phi[2,2]  ...  phi[2,k2],






Аксиоматическая семантика.

Для интерпретации системы (5.1) вводится понятие аксиоматического описания (S,E) - логически связанной пары понятий: S - сигнатура используемых в… ti1 * ti2 * ... * tik -> ti0.
Такое аксиоматическое описание получит конкретную интерпретацию, если будут заданы конкретные типы данных ti=ti',…





Языки спецификаций.

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

Литература к лекции 5.

5.1. В.Н. Агафонов. Спецификация программ: понятийные средства и их организация. - Новосибирск: Наука (Сибирское отделение), 1987. - С. 30-73.
5.2. Ian Sommerville. Software Engineering. - Addison-Wesley Publishing Company, 1992. - P.
5.3. Д. Скотт. Теория решеток, типы данных и семантика// Данные в языках программирования. - М.: Мир, 1982. - С. 25-53.
5.4. К. Хоор. О структурной организации данных// У. Дал, Э. Дейкстра, К. Хоор. Структурное программирование. - М.: Мир, 1975. - С. 98-197.

Лекция 6. АРХИТЕКТУРА ПРОГРАММНОГО СРЕДСТВА
Понятие архитектуры и задачи ее описания. Основные классы архитектур программных средств. Взаимодействие между подсистемами и архитектурные функции. Контроль архитектуры программных средств.





Понятие архитектуры программного средства.

Основные задачи разработки архитектуры ПС:
· выделение программных подсистем и отображение на них внешних функций… · определение способов взаимодействия между выделенными программными подсистемами.






Основные классы архитектур программных средств.

Различают следующие основные классы архитектур программных средств [6.1]:
· цельная программа;
· комплекс автономно выполняемых программ;
· слоистая программная система;
· коллектив параллельно выполняемых программ.
Цельная программа представляет вырожденный случай архитектуры ПС: в состав ПС входит только одна программа. Такую архитектуру выбирают обычно в том случае, когда ПС должно выполнять одну какую-либо ярко выраженную функцию и ее реализация не представляется слишком сложной. Естественно, что такая архитектура не требует какого-либо описания (кроме фиксации класса архитектуры), так как отображение внешних функций на эту программу тривиально, а определять способ взаимодействия не требуется (в силу отсутствия какого-либо внешнего взаимодействия программы, кроме как взаимодействия ее с пользователем, а последнее описывается в документации по применению ПС).
Комплекс автономно выполняемых программ состоит из набора программ, такого, что:
· любая из этих программ может быть активизирована (запущена) пользователем;
· при выполнении активизированной программы другие программы этого набора не могут быть активизированы до тех пор, пока не закончит выполнение активизированная программа;
· все программы этого набора применятся к одной и той же информационной среде.
Таким образом, программы этого набора по управлению никак не взаимодействуют - взаимодействие между ними осуществляется только через общую информационную среду.
Слоистая программная система состоит из некоторой упорядоченной совокупности программных подсистем, называемых слоями, такой, что:
· на каждом слое ничего не известно о свойствах (и даже существовании) последующих (более высоких) слоев;
· каждый слой может взаимодействовать по управлению (обращаться к компонентам) с непосредственно предшествующим (более низким) слоем через заранее определенный интерфейс, ничего не зная о внутреннем строении всех предшествующих слоев;
· каждый слой располагает определенными ресурсами, которые он либо скрывает от других слоев, либо предоставляет непосредственно последующему слою (через указанный интерфейс) некоторые их абстракции.
Таким образом, в слоистой программной системе каждый слой
может реализовать некоторую абстракцию данных. Связи между слоями ограничены передачей значений параметров обращения каждого слоя к смежному снизу слою и выдачей результатов этого обращения от нижнего слоя верхнему. Недопустимо использование глобальных данных несколькими слоями.
В качестве примера рассмотрим использование такой архитектуры для построения операционной системы. Такую архитектуру применил Дейкстра при построении операционной системы THE [6.2]. Эта операционная система состоит из четырех слоев (см. рис. 6.1). На нулевом слое производится обработка всех прерываний и выделение центрального процессора программам (процессам) в пакетном режиме. Только этот уровень осведомлен о мультипрограммных аспектах системы. На первом слое осуществляется управление страничной организацией памяти. Всем вышестоящим слоям предоставляется виртуальная непрерывная (не страничная) память. На втором слое осуществляется связь с консолью (пультом управления) оператора. Только этот слой знает технические характеристики консоли. На третьем слое осуществляется буферизация входных и выходных потоков данных и реализуются так называемые абстрактные каналы ввода и вывода, так что прикладные программы не знают технических характеристик устройств ввода и вывода.
Прикладные программы
3: Управление входными и выходными потоками данных
2: Обеспечение связи с консолью оператора
1: Управление памятью
0: Диспетчеризация и синхронизация процессов
Компьютер
Рис. 6.1. Архитектура операционной системы THE.
Коллектив параллельно действующих программ представляет собой набор программ, способных взаимодействовать между собой, находясь одновременно в стадии выполнения. Это означает, что такие программы, во-первых, вызваны в оперативную память, активизированы и могут попеременно разделять по времени один или несколько центральных процессоров, а во-вторых, осуществлять между собой динамические (в процессе выполнения) взаимодействия, на базе которых производиться их синхронизация. Обычно взаимодействие между такими процессами производится путем передачи друг другу некоторых сообщений.
Простейшей разновидностью такой архитектуры является конвейер, средства для организации которого имеются в операционной системе UNIX [6.3]. Конвейер представляет собой последовательность программ, в которой стандартный вывод каждой программы, кроме самой последней, связан со стандартным вводом следующей программы этой последовательности (см. рис. 6.2). Конвейер обрабатывает некоторый поток сообщений. Каждое сообщение этого потока поступает на ввод первой программе, которая обработав его передает переработанное сообщение следующей программе, а сама начинает обработку очередного сообщения потока. Таким же образом действует каждая программа конвейера: получив сообщение от предшествующей программы и обработав его, она передает переработанное сообщение следующей программе, а последняя программа конвейера выводит результат работы всего конвейера (результирующее сообщение). Таким образом, в конвейере, состоящим из n программ, может одновременно находиться в обработке до n сообщений. Конечно, в силу того, что разные программы конвейера могут затратить на обработку очередных сообщений разные отрезки времени, необходимо обеспечить каким-либо образом синхронизацию этих процессов (некоторые процессы могут находиться в стадии ожидания либо возможности передать переработанное сообщение, либо возможности получить очередное сообщение).
Рис. 6.2. Конвейер параллельно действующих программ.
В общем случае коллектив параллельно действующих программ может быть организован в систему с портами сообщений.
Порт сообщений представляет собой программную подсистему, обслуживающую некоторую очередь сообщений: она может принимать на хранение от программы какое-либо сообщение, ставя его в очередь, и может выдавать очередное сообщение другой программе по ее требованию. Сообщение, переданное какой-либо программой некоторому порту, уже не будет принадлежать этой программе (и использовать ее ресурсы), но оно не будет принадлежать и никакой другой программе, пока в порядке очереди не будет передано какой-либо программе по ее запросу. Таким образом, программа, передающая сообщение не будет находиться в стадии ожидания пока программа, принимающая это сообщение, не будет готова его обрабатывать (если только не будет переполнен принимающий порт).
Пример программной системы с портами сообщений приведен на рис. 6.3. Порт U может рассматриваться как порт вводных сообщений для представленного на этом рисунке коллектива параллельно действующих программ, а порт W - как порт выводных сообщений для этого коллектива программ.
Рис. 6.3. Пример программной системы с портами сообщений.
Программные системы с портами сообщений могут быть как жесткой конфигурации, так и гибкой конфигурации. В системах с портами жесткой конфигурации с каждой программой могут быть жестко связаны один или несколько входных портов. Для передачи сообщения такая программа должна явно указать адрес передачи: имя программы и имя ее входного порта. В этом случае при изменении конфигурации системы придется корректировать используемые программы: изменять адреса передач сообщений. В системах с портами гибкой конфигурации с каждой программой связаны как входные, так и выходные виртуальные порты. Перед запуском такой системы должна производиться ее предварительная настройка с помощью специальной программной компоненты, осуществляющая совмещение каждого выходного виртуального порта с каким-либо входным виртуальным портом на основании информации, задаваемой пользователем. Тем самым при изменении конфигурации системы в этом случае не требуется какой-либо корректировки используемых программ - необходимые изменения должны быть отражены в информации для настройки. Однако в этом случае требуется иметь специальную программную компоненту, осуществляющую настройку системы.





Архитектурные функции.

Однако в ряде случаев для обеспечения взаимодействия между программными подсистемами может потребоваться создание дополнительных программных…





Контроль архитектуры программных средств.

Смежный контроль архитектуры ПС сверху - это ее контроль разработчиками внешнего описания: разработчиками спецификации качества и разработчиками… Ручная имитация архитектуры ПС производится аналогично ручной имитации…

Литература к лекции 6.

6.1. Г. Майерс. Надежность программного обеспечения. - М.: Мир, 1980. - С. 78-91.
6.2. E.W. Dijkstra. The Structure of the THE-Multiprogramming// Communications of the ACM. - 1968, 11(5). - Pp. 341-346.
6.3. М. Кристиан. Введение в операционную систему UNIX. - М.: Фи нансы и статистика, 1985. - С. 46-49.

Смотри в корень!

Козьма Прутков

Лекция 7. РАЗРАБОТКА СТРУКТУРЫ ПРОГРАММЫ И МОДУЛЬНОЕ ПРОГРАММИРОВАНИЕ
Цель разработки структуры программы. Понятие программного модуля. Основные характеристики программного модуля. Методы разработки структуры программы. Спецификация программного модуля. Контроль структуры программы.





Цель модульного программирования.

Модульное программирование является воплощением в процессе разработки программ обоих общих методов борьбы со сложностью (см. лекцию 3, п. 3.5): и…





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

· хороший модуль снаружи проще, чем внутри;
· хороший модуль проще использовать, чем построить.
Майерс [7.5] предлагает использовать более конструктивные характеристики программного модуля для оценки его…





Методы разработки структуры программы.

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





Контроль структуры программы.

· статический контроль,
· смежный контроль,
· сквозной контроль.


Литература к лекции 7.

7.1. Дж.Хьюз, Дж.Мичтом. Структурный подход к программированию. М.: Мир, 1980. - С. 29-71.
7.2. В.Турский. Методология программирования. - М.: Мир, 1981. - С. 90-164.
7.3. Е.А.Жоголев. Технологические основы модульного программирования//Программирование,1980, #2. - С. 44-49.
7.4. R.C.Holt. Structure of Computer Programs: A Survey//Proceedings of the IEEE, 1975, 63(6). - P. 879-893.
7.5. Г.Майерс. Надежность программного обеспечения. М.: Мир, 1980. - С. 92-113.
7.6. Я.Пайл. АДА - язык встроенных систем. М.: Финансы и статистика, 1984. - С. 67-75.
7.7. М.Зелковец, А.Шоу, Дж.Гэннон. Принципы разработки программного обеспечения. М.: Мир, 1982. - С. 65-71.
7.8. А.Л.Фуксман. Технологические аспекты создания программных систем. М.: Статистика, 1979. С. 79-94.

Лекция 8. РАЗРАБОТКА ПРОГРАММНОГО МОДУЛЯ
Порядок разработки программного модуля. Структурное программирование и пошаговая детализация. Понятие о псевдокоде. Контроль программного модуля.





Порядок разработки программного модуля.

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






Структурное программирование.

Рис. 8.1. Основные управляющие конструкции структурного программирования.
Основными конструкциями структурного программирования являются: следование,… обобщенного оператора может быть либо простой оператор используемого языка программирования (операторы присваивания,…





Пошаговая детализация и понятие о псевдокоде.

В качестве основного метода построения текста модуля современная технология программирования рекомендует пошаговую детализацию [8.1, 8.3, 8.5].… биении процесса разработки текста модуля на ряд шагов. На первом
шаге описывается общая схема работы модуля в обозримой линейной текстовой форме (т.е. с использованием очень крупных…





Контроль программного модуля.

· статическая проверка текста модуля;
· сквозное прослеживание;
· доказательство свойств программного модуля.


Литература к лекции 8.

8.1. Г.Майерс. Надежность программного обеспечения. - М.: Мир, 1980. - С. 127-154.
8.2. Э.Дейкстра. Заметки по структурному программированию// У.Дал, Э.Дейкстра, К.Хоор. Структурное программирование. - М.: Мир, 1975. - С. 24-97.
8.3. Н.Вирт. Систематическое программирование. - М.: Мир, 1977. - С. 94-164.

Лекция 9. ДОКАЗАТЕЛЬСТВО СВОЙСТВ ПРОГРАММ
Понятие обоснования программ. Формализация свойств программ, триады Хоора. Правила для установления свойств оператора присваивания, условного и составного операторов. Правила для установления свойств оператора цикла, понятие инварианта цикла. Завершимость выполнения программы.





Обоснования программ. Формализация свойств программ.

Одной из используемых в настоящее время концепций формальных обоснований программ является использование так называемых триад Хоора. Пусть S -… Простые примеры свойств программ:
(9.1) {n=0} n:=n+1 {n=1}, (9.2) {n<m} n:=n+k {n<m+k},






Свойства простых операторов.

Для пустого оператора справедлива
Теорема 9.1. Пусть P - предикат над информационной средой. Тогда имеет место свойство {P}{P}.
Доказательство этой теоремы очевидно: пустой оператор не изменяет состояние информационной среды (в соответствии со своей семантикой), поэтому его предусловие сохраняет истинность и после его выполнения.
Для оператора присваивания справедлива
Теорема 9.2. Пусть информационная среда IS состоит из переменной X и остальной части информационной среды RIS:
IS = {X, RIS}.
Тогда имеет место свойство
{Q(F(X, RIS), RIS)} X:= F(X, RIS) {Q(X, RIS)} ,
где F(X, RIS) - некоторая однозначная функция, Q - предикат.
Доказательство. Пусть до выполнения оператора присваивания был истинен предикат Q(F(X0, RIS0), RIS0), где {X0, RIS0} - некоторое произвольное состояние информационной среды IS, тогда после выполнения оператора присваивания будет истинен предикат Q(X, RIS), так как X получит значение F(X0, RIS0), а состояние RIS не изменяется данным оператором присваивания, и, следовательно, после выполнения этого оператора присваивания в этом случае
Q(X, RIS)=Q(F(X0, RIS0), RIS0).
В силу произвольности выбора состояния информационной среды теорема доказана.
Примером свойства оператора присваивания может служит пример 9.1.





Свойства основных конструкций структурного программирования.

Свойства следования выражает следующая
Теорема 9.3. Пусть P, Q и R - предикаты над информационной средой, а S1 и S2 -… {P}S{Q} и {Q}S2{R}.






Завершимость выполнения программы.

Теорема 9.7. Пусть F - целочисленная функция, зависящая от состояния информационной среды и удовлетворяющая следующим условиям:
(1) если для данного состояния информационной среды истинен предикат Q, то ее… (2) она убывает при изменении состояния информационной среды в результате выполнения оператора S.






Пример доказательства свойства программы.

На основании доказанных правил верификации программ можно доказывать свойства программ, состоящих из операторов присваивания и пустых операторов и использующих три основные композиции структурного программирования. Для этого анализируя структуру программы и используя заданные ее пред- и постусловия необходимо на каждом шаге анализа применять подходящее правило верификации. В случае применения композиции повторения потребуется подобрать подходящий инвариант цикла.
В качестве примера докажем свойство (9.4). Это доказательство будет состоять из следующих шагов.
(Шаг 1). n>0 => (n>0, p - любое, m - любое).
(Шаг 2). Имеет место
{n>0, p - любое, m - любое} p:=1 {n>0, p=1, m - любое}.
-- По теореме 9.2.
(Шаг 3). Имеет место
{n>0, p=1, m - любое} m:=1 {n>0, p=1, m=1}.
-- По теореме 9.2.
(Шаг 4). Имеет место
{n>0, p - любое, m - любое} p:=1; m:=1 {n>0, p=1, m=1}.
-- По теореме 9.3 в силу результатов шагов 2 и 3.
Докажем, что предикат p=m! является инвариантом цикла, т.е. {p=m!} m:=m+1; p:=p*m {p=m!}.
(Шаг 5). Имеет место {p=m!} m:=m+1 {p=(m-1)!}.
-- По теореме 9.2, если представить предусловие в виде {p=((m+1)-1)!}.
(Шаг 6). Имеет место {p=(m-1)!} p:=p*m {p=m!}.
-- По теореме 9.2, если представить предусловие в виде {p*m=m!}.
(Шаг 7). Имеет место инвариант цикл
{p=m!} m:=m+1; p:=p*m {p=m!}.
-- По теореме 9.3 в силу результатов шагов 5 и 6.
(Шаг 8). Имеет место
{n>0, p=1, m=1} ПОКА m /= n ДЕЛАТЬ
m:= m+1; p:= p*m
ВСЕ ПОКА {p= n!}.
-- По теореме 9.6 в силу результата шага 7 и имея в виду, что (n>0, p=1, m= 1)=>p=m!; (p=m!, m=n)=>p=n!.
(Шаг 9). Имеет место
{n>0, p - любое, m - любое} p:=1; m:=1;
ПОКА m /= n ДЕЛАТЬ
m:= m+1; p:= p*m
ВСЕ ПОКА {p= n!}.
-- По теореме 9.3 в силу результатов шагов 3 и 8.
(Шаг 10). Имеет место свойство (9.4) по теореме 9.5 в силу результатов шагов 1 и 9.

Литература к лекции 9.

9.1. С.А. Абрамов. Элементы программирования. - М.: Наука, 1982. С. 85-94.
9.2. М. Зелковец, А. Шоу, Дж. Гэннон. Принципы разработки программного обеспечения. - М.: Мир, 1982. С. 98-105.

Лекция 10. ТЕСТИРОВАНИЕ И ОТЛАДКА ПРОГРАММНОГО СРЕДСТВА
Основные понятия. Стратегия проектирования тестов. Заповеди отладки. Автономная отладка и тестирование программного модуля. Комплексная отладка и тестирование программного средства.





Основные понятия.

Отладка ПС - это деятельность, направленная на обнаружение и исправление ошибок в ПС с использованием процессов выполнения его программ. Тестирование ПС - это процесс выполнения его программ на некотором наборе данных, для которого заранее известен результат применения или известны правила поведения этих программ. Указанный набор данных называется тестовым или просто тестом. Таким образом, отладку можно представить в виде многократного повторения трех процессов: тестирования, в результате которого может быть констатировано наличие в ПС ошибки, поиска места ошибки в программах и документации ПС и редактирования программ и документации с целью устранения обнаруженной ошибки. Другими словами:
Отладка = Тестирование + Поиск ошибок + Редактирование.
В зарубежной литературе отладку часто понимают [10.1-10.3] только как процесс поиска и исправления ошибок (без тестирования), факт наличия которых устанавливается при тестировании. Иногда тестирование и отладку считают синонимами [10.4,10.5]. В нашей стране в понятие отладки обычно включают и тестирование [10.6 -10.8], поэтому мы будем следовать сложившейся традиции. Впрочем совместное рассмотрение в данной лекции этих процессов делает указанное разночтение не столь существенным. Следует однако отметить, что тестирование используется и как часть процесса аттестации ПС (см. лекцию 14).





Принципы и виды отладки.

Для оптимизации набора тестов, т.е. для подготовки такого набора тестов, который позволял бы при заданном их числе (или при заданном интервале… Рис. 10.1. Спектр подходов к проектированию тестов.
Оптимальная стратегия проектирования тестов расположена внутри интервала между этими крайними подходами, но ближе к…





Заповеди отладки.

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





Автономная отладка модуля.

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





Комплексная отладка программного средства.

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





Функциональность и надежность как обязательные критерии качества программного средства.

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





Обеспечение завершенности программного средства.

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





Обеспечение точности программного средства.

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





Обеспечение автономности программного средства.







Обеспечение устойчивости программного средства.

Применение защитного программирования модулей приводит снижению эффективности ПС как по времени, так и по памяти. Поэтому необходимо разумно…





Обеспечение защищенности программных средств.

· защита от сбоев аппаратуры;
· защита от влияния "чужой" программы;
· защита от отказов "своей" программы;


Литература к лекции 11.

11.1. И.С. Березин, Н.П. Жидков. Методы вычислений, т.т. 1 и 2. - М.: Физматгиз, 1959.
11.2. Н.С. Бахвалов, Н.П. Жидков, Г.М.Кобельков. Численные методы. - М.: Наука, 1987.
11.3. Г. Майерс. Надежность программного обеспечения. - М.: Мир, 1980. С. 127-154.
11.4. А.Н. Лебедев. Защита банковской информации и современная криптография//Вопросы защиты инф


К чему ищу так славу я? Известно, в славе нет блаженства, Но хочет все душа моя Во всем дойти до совершенства.

М.Ю.Лермонтов

Лекция 12. ОБЕСПЕЧЕНИЕ КАЧЕСТВА ПРОГРАММНОГО СРЕДСТВА





Общая характеристика процесса обеспечения качества программного средства.

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





Обеспечение легкости применения программного средства.

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





Обеспечение эффективности программного средства.

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





Обеспечение сопровождаемости.

· используйте в тексте модуля комментарии, проясняющие и объясняющие особенности принимаемых решений; по-возможности, включайте комментарии (хотя бы… · используйте осмысленные (мнемонические) и устойчиво различимые имена… · соблюдайте осторожность в использовании констант (уникальная константа должна иметь единственное вхождение в текст…





Обеспечение мобильности.

. . .

Литература к лекции 12.

12.1. Ian Sommerville. Software Engineering. - Addison-Wesley Publishing Company, 1992. P.
12.2. Г.Майерс. Надежность программного обеспечения. - М.: Мир, 1980. С. 127-154.
12.3. Д.Ван Тассел. Стиль, разработка, эффективность, отладка и испытание программ. - М.: Мир, 1985. С. 8-44, 117-178.
12.4. Документация пользователя программного обеспечения/Стандарт ANSI/IEEE 1063-1987.

Лекция 13. ДОКУМЕНТИРОВАНИЕ ПРОГРАММНЫХ СРЕДСТВ





Документация, создаваемая в процессе разработки программных средств.

Эту документацию можно разбить на две группы [13.1]:
· Документы управления разработкой ПС.
· Документы, входящие в состав ПС.






Пользовательская документация программных средств.

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





Документация по сопровождению программных средств.

Документация по сопровождению ПС можно разбить на две группы:
(1) документация, определяющая строение программ и структур данных ПС и… (2) документацию, помогающую вносить изменения в ПС.


Литература к лекции 13.

13.1. Ian Sommerville. Software Engineering. - Addison-Wesley Publishing Company, 1992. P.
13.2. ANSI/IEEE Std 1063-1988, IEEE Standard for Software User Documentation.
13.3. ANSI/IEEE Std 830-1984, IEEE Guide for Software Requirements Specification.
13.4. ANSI/IEEE Std 1016-1987, IEEE Recommended Practice for Software Design Description.
13.5. ANSI/IEEE Std 1008-1987, IEEE Standard for Software Unit Testing.
13.6. ANSI/IEEE Std 1012-1986, IEEE Standard for Software Verification and Validation Plans.
13.7. ANSI/IEEE Std 983-1986, IEEE Guide for Software Quality Assurance Planning.
13.8. ANSI/IEEE Std 829-1983, IEEE Standard for Software Test Documentation.

Лекция 14. АТТЕСТАЦИЯ ПРОГРАММНОГО СРЕДСТВА
Назначение аттестации программного средства. Испытания и оценка качества программного средства. Виды испытаний и методы оценки качества программного средства.





Назначение аттестации программного средства.

На основе информации, полученной во время испытаний ПС, прежде всего должно быть установлено, что ПС выполняет декларированные функции, а также…





Виды испытаний программного средства.

· испытания компонент ПС;
· системные испытания;
· приемо-сдаточные испытания;






Методы оценки качества программного средства.

· непосредственное измерение показателей примитива качества;
· обработка программ и документации ПС специальными программными инструментами… · тестирование программ ПС;


Литература к лекции 14.

14.1. Г.Майерс. Надежность программного обеспечния. - М.: Мир, 1980. - С. 174-175.
14.2. В.В.Липаев. Тестирование программ. - М.: Радио и связь, 1986. - С. 231-245.
14.3. Д.Ван Тассел. Стиль, разработка, эффективность, отладка и испытание программ. - М.: Мир, 1985. - С. 281-283.
14.4. Б.Шнейдерман. Психология программирования. - М.: Радио и связь, 1984. - С. 99-127.


Лекция 15.



ОЪЕКТНЫЙ ПОДХОД К РАЗРАБОТКЕ



ПРОГРАММНЫХ СРЕДСТВ

Сущность объектного подхода к разработке программных средств. Объектное моделирование как содержание этапа внешнего описания при объектном подходе. Особенности этапа конструирования программного средства при объектном подходе.





Объекты и отношения в программировании. Сущность объектного подхода к разработке программных средств.

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






Особенности объектного подхода к разработке внешнего описания программного средства.

Определение требований заключается в неформальном описании модельного мира, который пользователь собирается изучать или просто использовать с… Существенно изменяется содержание процесса спецификации требований: вместо… · объектной модели,






Особенности объектного подхода на этапе конструирования программного средства.

В процессе разработки объектной архитектуры ПС выделяются все объекты, с информационными моделями которых собирается непосредственно работать…







Особенности объектного подхода на этапе кодирования программного средства.

· инкапсуляции и абстракции данных,
· наследования,
· динамического полиморфизма.


Литература к лекции 15.

15.1. К. Фути, Н. Судзуки. Языки программирования и схемотехника СБИС. – М.: Мир, 1988. С. 85-98.
15.2. В. Даль. Толковый словарь русского языка. – М.: Советская энциклопедия, 1975
15.3. J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, W. Lorenzen. Objekt-Oriented Modeling and Design. – Prentice Hall. 1991.
15.4. Г.Буч. Объектно-ориентированное проектирование с примерами применения: пер. с англ. – М.: Конкорд, 1992.
15.5. М. Фаулер, К. Скотт. UML в кратком изложении. – М.: Мир, 1999.
15.6. Ф. Крачтен. Введение в RATIONAL UNIFIED PROCESS. – М.: Изд. Дом «Вильямс», 2002.
15.7. В.Ш.Кауфман. Языки программирования. Концепции и принципы. – М.: Радио и связь, 1993.
15.8. М. Бен-Ари. Языки программирования. Практический сравнительный анализ. – М.: Мир, 2000.
15.9. Э. Дейкстра. Заметки по структурному программированию / У. Дал, Э. Дейкстра, К. Хоор. Структурное программирование. – М.: Мир, 1975. – С. 7-97.

Лекция 16. КОМПЬЮТЕРНАЯ ПОДДЕРЖКА РАЗРАБОТКИ И СОПРОВОЖДЕНИЯ ПРОГРАММНЫХ СРЕДСТВ





Инструменты разработки программных средств.

ПС, предназначенное для поддержки разработки других ПС, будем называть программным инструментом разработки ПС, а устройство компьютера, специально… Инструменты разработки ПС могут использоваться в течении всего жизненного… редакторы,·






Инструментальные среды разработки и сопровождения программных средств.

Инструментальная среда не обязательно должна функционировать на том компьютере, на котором должно будет применяться разрабатываемое с помощью ее ПС.… Различают три основных класса [16.1] инструментальных средразработки и… среды программирования, ·






Инструментальные среды программирования.

Различают следующие классы инструментальных сред программирования (см. рис. 14.2): ·
среды общего назначения,·
языково-ориентированные среды.






Понятие компьютерной технологии разработки программных средств и ее рабочие места.

В настоящее время компьютерную технологию разработки ПС можно характеризовать [16.2] использованием·
программной поддержки для разработки графических требований и графических… автоматической генерации программ на каком-либо языке программирования или в машинном коде (частично или полностью),…





Инструментальные системы технологии программирования.

комплексность, ·
ориентированность на коллективную разработку, ·
технологическая определенность, ·


Литература к лекции 16.

16.1. Ian Sommerville. Software Engineering. - Addison-Wesley Publishing Company, 1992. P. 349-369.
16.2. CASE: Копьютерное проектирование программного обеспечения. - Издательство Московского университета, 1994.
16.3. Requirements for Ada Programming Support Enviroments. - USA: DoD, Stoneman, 1980.