Необходимость в технологии создания ПО
Лекция № 1. Введение.
Слово «технология» происходит от греческих слов «технос» - искусство, мастерство,- и «логос» - учение. В дословном переводе с греческого слово «технология» означает «учение о мастерстве». В русском языке (см. Словарь русского языка) это слово имеет два смысловых значения:
1. Совокупность знаний о способах обработки материалов, изделий, методах осуществления каких-либо производственных процессов. В этом значении слово используется в словосочетаниях «технология судостроения», «технология осушения болот» и им подобных.
2. Совокупность операций, осуществляемых определенным способом и в определенной последовательности, из которых складывается процесс обработки материала, изделия. В этом значении слово используется в словосочетания «разработка технологии производственного процесса», внедрение новой «технологии обработки данных».
В настоящее время «технологии программирования» ни в одном из приведенных смыслов пока не существует, хотя предпосылки для этого уже сложились.
Жизненный цикл ПО
Определение 2. Жизненный цикл программного обеспечения - это период времени от момента принятия решения о необходимости создания ПО и до момента его полного изъятия из эксплуатации.
Время жизни любой промышленной системы делится на 2 стадии: разработка и эксплуатация. Во время эксплуатации осуществляется сопровождение системы, то есть исправляются обнаруженные ошибки. В это же время происходит развитие (эволюция) программы.
Разработка промышленной системы должна выполняться в определенной последовательности, поэтому стадия разработки делится на этапы, и во время каждого этапа выполняются определенные процессы. По сложившейся практике (отраженной в стандартах!) стадия разработки состоит из следующих основных этапов, выполняемых в указанном порядке:
· определение целей и требований;
· проектирование;
· реализация;
· испытания.
Возможна и более мелкая детализация, однако мы этого делать не будем.
Понятно, что прежде, чем приступить к созданию программы, необходимо определить цели её разработки, а затем выработать требования к будущему программному продукту. Этот этап формализован относительно слабо и является в значительной степени неформальным. Тем не менее, результатом деятельности на этом этапе является документ, в котором изложены требования к будущей системе.
Этап проектирования обычно делят на 2 стадии: внешнее и внутреннее проектирование. На первой стадии определяют, что должен делать программный продукт. А на второй стадии уже разрабатывают то, как он будет это делать. Результатом деятельности на первой стадии является документ (возможно, не один), определяющий архитектуру системы и её взаимоотношение с внешним миром. В американской литературе этот документ называют «внешние спецификации».
На второй стадии проектирования разрабатывают уже детальный проект, описывающий реализацию архитектуры и внешних спецификаций. Если проводить аналогию с программированием функции, то на первом этапе определяется прототип, а на втором – её реализация. Можно провести аналогию и с программирование класса: на первом этапе разрабатывается интерфейс класса, а на втором – полная реализация методов класса.
На этапе реализации, естественно, выполняется программирование и отладка. Американцы называют процесс программирования – кодированием, отводя тем самым этому важнейшему этапу второстепенную роль. Результатом деятельности обычно является реализованный программный продукт с комплектом документации на него.
И, наконец, на этапе испытаний выполняются разнообразные проверки разработанной системы и исправление найденных ошибок. Результатом деятельности на этом этапе является готовая система, сдаваемая в экплуатацию.
Таким образом, если говорить о предмете изучения «технология программирования», то необходимо рассматривать три разных технологии: технологию проектирования, технологию программирования и технологию проверки программного продукта. В данном курсе технология проектирования рассматривается обзорно, а основное внимание уделяется технологии программирования и технологии проверки.
Можно провести аналогию с любой сферой человеческой деятельности. Например, в строительстве выполняется три разных вида работ: создается архитектурный проект, затем разрабатывается инженерный проект, после чего выполняется ещё и проект производства работ. И только потом приступают непосредственно к строительству. После строительства дом сдается в эксплуатацию. То же самое можно увидеть и а любой производственной сфере, выпускающей некоторые крупные изделия, например, автомобили или самолеты. Сначала автомобиль конструируется до детального уровня. По сделанному проекту автомобиль создается на заводе. Затем проводят его испытания, после чего начинают тиражирование данной модели. Каждая стадия создания автомобиля имеет собственную сложившуюся технологию, закрепленную в многочисленных стандартизирующих документах.
Модели жизненного цикла
Жизненный цикл можно изучать сам по себе, поэтому можно строить те или иные модели жизненного цикла, определяющие взаимосвязи и последовательность выполнения процессов, действий и задач на этапах разработки и эксплуатации. Модель жизненного цикла, с одной стороны, зависит от типа создаваемого продукта, а с другой стороны, определяет характер процесса создания ПО. В настоящее время общепринятыми являются две модели: каскадная и спиральная. Название каскадной модели по-английски звучит как waterfall model, что переводится как «водопадная модель». Изображение (рис.1) этапов и переходов от этапа к этапу напоминает водопад.
Рис. 1. Каскадная модель жизненного цикла.
Принципиальная особенность каскадной модели: переход к следующему этапу осуществляется после завершения работ на предыдущем этапе. Возвратов на пройденные этапы не предусматривается. Каждая стадия заканчивается получением некоторых результатов, которые служат исходными данными для следующего этапа. У такого подхода есть свои достоинства и недостатки. Достоинства:
· на каждом этапе формируется законченный набор проектной документации, отвечающей критериям полноты и согласованности;
· строгая последовательность этапов позволяет планировать сроки завершения работ и соответствующие затраты.
Каскадный этап хорошо зарекомендовал себя при разработке информационных систем, для которых в самом начале разработки можно точно и полно сформулировать требования к системе. К таким системам можно отнести, например, системы реального времени.
Однако реальный процесс разработки ПО часто не укладывается в такую жесткую схему. Процесс создания ПО является, как правило, итерационным: результаты очередного этапа вынуждают вернуться к предыдущему (или на ещё более раннюю стадию) и внести изменения и уточнения. Поэтому каскадная модель была усовершенствована именно в этом пункте: каскадная модель с промежуточным контролем (рис.2) – возврат на предыдущую стадию, если необходимо внести изменения.
Вендров[7]: «Основным недостатком каскадного подхода является существенное запаздывание с получением результатов и, как следствие, достаточно высокий риск создания системы, не удовлетворяющий требованиям пользователя». На самом деле первое влияет на второе, но никак не определяющим образом. Запаздывание – это недостаток опыта планирования работ в области разработки ПО. Неудовлетворение же потребностей пользователя вызвано самой каскадной моделью: на начальной стадии работ полностью и точно сформулировать требования к будущей системе часто не удается. Во-первых, сами пользователи не обладают достаточным опытом, чтобы точно сформулировать требования к системе; во-вторых, за время разработки могут произойти изменения во внешней среде, которые повлияют на требования к системе. Например, изменится операционная система, в которой должна будет работать будущая система. Однако сама сущность каскадной модели заключается именно в том, что требования и проектные решения, хотя и согласовываются с заказчиком, но в некоторый момент фиксируются в соответствующих документах и более уже не изменяются.
Рис. 2. Каскадная модель с обратной связью.
Практика разработки больших систем потребовала создания модели другого рода, которая отражала бы непрерывный процесс «продолжающейся разработки», придерживаясь в то же время традиционного деления на стадии разработки. Таким образом, была придумана спиральная модель (рис.3). Её особенностью является то, что процесс эволюции программы включается в цикл разработки. На каждом витке создается очередная версия системы.
Рис. 3. Спиральная модель разработки ПО.
Разработка «по спирали» отражает объективно существующий итерационный цикл создания многих видов программного обеспечения. Особенно это удобно, когда требуется разработать ПО нового типа, ранее не создававшегося. В этом случае первая версия (а возможно и вторая, и третья) представляет собой прототип системы, в котором могут отсутствовать многие функции. При итеративном способе разработки недостающую функциональность можно добавить на следующем витке. Главное же – как можно скорее предоставить пользователю работоспособный продукт, активизируя тем самым процесс уточнения и дополнения требований.
Основная проблема спиральной модели – определение момента завершения версии системы. Всегда существует опасность увлечься и добавлять все новые и новые функции. Поэтому необходимо ограничить время каждого этапа жизненного цикла. Никаких стандартов на продолжительность этапов не существует, поэтому план составляется на основе статистических данных, полученных в предыдущих проектах и личного опыта разработчиков. Кстати, это же касается и каскадной модели.
Упражнения к лекции 2.
2.1 Что такое информационная среда программы?
2.2 Что такое программное средство (ПС)?
2.3 Что такое ошибка в ПС?
2.4 Что такое надежность ПС?
2.5 Что такое технология программирования?
Литература к лекции 2.
2.1. И.Г.Гоулд, Дж.С.Тутилл. Терминологическая работа IFIP (Международная федерация по обработке информации) и ICC (Международный вычислительный центр) // Журн. вычисл. матем. и матем. физ., 1965, #2. - С. 377-386.
2.2. Г.Майерс. Надежность программного обеспечения. - М.: Мир, 1980.
2.3. Ian Sommerville. Software engineering. - Addison-Wesley Publishing Company, 1992.
2.4. Э. Дейкстра. Заметки по структурному программированию / У. Дал, Э. Дейкстра, К. Хоор. Структурное программирование. - М.: Мир, 1975. - С. 7-97.
2.5. Criteria for evaluation of software. - ISO TC97/SC7 #367 (Supersedes Document #327).
2.6. С.И. Ожегов. Словарь русского языка. - М.: Советская энциклопедия, 1975.
2.7. Ф.Я. Дзержинский, И.М. Калиниченко. Дисциплина программирования Д: концепция и опыт реализации методических средств программной инженерии. - М.: ЦНИИ информации и технико-экономических исследований по атомной науке и технике, 1988.
2.8. В. Турский. Методология программирования. - М.: Мир, 1981.
2.9. Г. Буч. Объектно-ориентированное проектирование с примерами применения. - М.: Конкорд, 1992.
2.10. Е.А. Жоголев. Система программирования с использованием библиотеки подпрограмм / Система автоматизация программирования. - М.: Физматгиз, 1961. - С. 15-52.
2.11. Ф.П. Брукс, мл. Как проектируются и создаются программные комплексы. - М.: Наука, 1979.
2.12. R.C. Holt. Structure of computer programs: A Survey // Proceedings of the IEEE, 1975, 63(6). - P. 879-893.
2.13. Дж. Хьюз, Дж. Мичтом. Структурный подход к программированию. - М.: Мир, 1980.
2.14. Е.А. Жоголев. Технологические основы модульного программирования // Программирование, 1980, #2. - С. 44-49.
2.15. Б. Боэм, Дж. Браун, Х. Каспар и др. Характеристики качества программного обеспечения. - М.: Мир, 1981.
2.16. В.В. Липаев. Качество программного обеспечения. - М.: Финансы и статистика, 1983.
2.17. Б. Шнейдерман. Психология программирования. - М.: Радио и связь, 1984.
2.18. Revised version of DP9126 - Criteria of the evaluation of software quality characteristics. ISO TC97/SC7 #610. Part 6.
2.19. В.Ш. Кауфман. Языки программирования. Концепции и принципы. - М.: Радио и связь, 1993.
2.20. Требования и спецификации в разработке программ. - М.: Мир, 1984.
2.21. В.Н. Агафонов. Спецификация программ: понятийные средства и их организация. - Новосибирск: Наука (Сибирское отделение), 1987.
2.22. В.В. Липаев, Е.Н Филиппов. Мобильность программ и данных в открытых информационных системах. - М.: Научная книга, 1997.
3. Лекция 3. ИСТОЧНИКИ ОШИБОК В ПРОГРАММНЫХ СРЕДСТВАХ
Интеллектуальные возможности человека, используемые при разработке программных систем. Понятия о простых и сложных системах, о малых и больших системах. Неправильный перевод информации из одного представления в другое - основная причина ошибок при разработке программных средств. Модель перевода и источники ошибок.
Модель перевода.
Чтобы понять природу ошибок при переводе рассмотрим модель [2.3, стр. 22-28], изображенную на рис.2.2. На ней человек осуществляет перевод информации из представления A в представление B. При этом он совершает четыре основных шага перевода:
Рис.2.2. Модель перевода.
· он получает информацию, содержащуюся в представлении A, с помощью своего читающего механизма R;
· он запоминает полученную информацию в своей памяти M;
· он выбирает из своей памяти преобразуемую информацию и информацию, описывающую процесс преобразования, выполняет перевод и посылает результат своему пишущему механизму W;
· с помощью этого механизма он фиксирует представление B.
На каждом из этих шагов человек может совершить ошибку раз-
ной природы. На первом шаге способность человека "читать между
строк" (способность, которая часто оказывается полезной, позволяя ему понимать текст, содержащий неточности или даже ошибки) может стать причиной ошибки в ПС. Ошибка возникает в том случае, когда при чтении документа A человек, пытаясь восстановить недостающую информацию, видит то, что он ожидает, а не то, что имел в виду автор документа A. В этом случае лучше было бы обратиться к автору документа за разъяснениями. При запоминании информации человек осуществляет ее осмысливание (здесь важен его уровень подготовки и знание предметной области, к которой относится документ A). И, если он поверхностно или неправильно поймет, то информация будет запомнена в искаженном виде. На третьем этапе забывчивость человека может привести к тому, что он может выбрать из своей памяти не всю преобразуемую информацию или не все правила перевода, в результате чего перевод будет осуществлен неверно. Это обычно происходит при большом объеме плохо организованной информации. И, наконец, на последнем этапе стремление человека быстрее зафиксировать информацию часто приводит к тому, что представление этой информации оказывается неточным, создавая ситуацию для последующей неоднозначной ее интерпретации.
Упражнения к лекции 3.
2.1. Что такое простая и сложная системы?
2.2. Что такое малая и большая системы?
Литература к лекции 3.
2.1. Э. Дейкстра. Заметки по структурному программированию / У. Дал, Э. Дейкстра, К. Хоор. Структурное программирование. - М.: Мир, 1975. - С. 7-19.
2.2. Е.А. Жоголев. Технологические основы модульного программирования. // Программирование, 1980, #2. - С. 44-49.
2.3. Г. Майерс. Надежность программного обеспечения. - М.: Мир, 1980.
4. Лекция 4. ОБЩИЕ ПРИНЦИПЫ РАЗРАБОТКИ ПРОГРАММНЫХ СРЕДСТВ
Специфика разработки программных средств. Жизненный цикл программного средства. Понятие качества программного средства. Обеспечение надежности - основной мотив разработки программного средства. Методы борьбы со сложностью. Обеспечение точности перевода. Преодоление барьера между пользователем и разработчиком. Обеспечение контроля правильности принимаемых решений.
Упражнения к лекции 4.
3.1. Что такое жизненный цикл программного средства (ПС)?
3.2. Что такое внешнее описание ПС?
3.3. Что такое сопровождение ПС?
3.4. Что такое качество ПС?
3.5. Что такое смежный контроль?
Литература к лекции 4.
Е.А. Жоголев. Введение в технологию программирования (конспект лекций). - М.: "ДИАЛОГ-МГУ", 1994.
М. Зелковец, А. Шоу, Дж. Гэннон. Принципы разработки программного обеспечения. - М.: Мир, 1982. - С. 11.
К. Зиглер. Методы проектирования программных систем. - М.: Мир, 1985. - С. 15-23.
Дж. Фокс. Программное обеспечение и его разработка. - М.: Мир, 1985. - С. 53-67, 125-130.
Ian Sommerville. Software Engineering. - Addison-Wesley Publishing Company, 1992. - P. 5-10.
Criteria for Evaluation of Software. ISO TC97/SC7 #383.
Revised version of DP9126 - Criteria of the Evaluation of Software Quality Characteristics. ISO TC97/SC7 #610. - Part 6.
Б. Боэм, Дж. Браун, Х. Каспар и др. Характеристики качества программного обеспечения. - М.: Мир, 1981. - С. 17-24.
В.В. Липаев. Качество программного обеспечения. - М.: Финансы и статистика, 1983. - С. 18-30.
Б. Шнейдерман. Психология программирования. - М.: Радио и связь, 1984. - С. 99-103.
Г. Майерс. Надежность программного обеспечения. - М.: Мир, 1980. - С. 32-48.
Д. Пойа. Как решать задачу. - М.: Наука, 1961.
В.В. Липаев, Б.А. Позин, А.А. Штрик. Технология сборочного программирования. – М.: Радио и связь, 1992.
5. Лекция 5. ВНЕШНЕЕ ОПИСАНИЕ ПРОГРАММНОГО СРЕДСТВА
Понятие внешнего описания, его назначение и роль в обеспечении качества программного средства. Определение требований к программному средству. Спецификация качества программного средства. Основные примитивы качества программного средства. Функциональная спецификация программного средства. Контроль внешнего описания.
Упражнения к лекции 5.
4.1. Что такое определение требований к программному средству (ПС)?
4.2. Что такое спецификации качества ПС?
4.3. Что такое устойчивость (robustness) ПС?
4.4. Что такое защищенность (defensiveness) ПС?
4.5. Что такое коммуникабельность (communicativeness) ПС?
4.6. Что такое функциональная спецификация ПС?
4.7. Что такое ручная имитация внешнего описания ПС?
Литература к лекции 5.
4.1. Ian Sommerville. Software Engineering. - Addison-Wesley Publishing Company, 1992.
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.
6. Лекция 6. РАЗРАБОТКА СТРУКТУРЫ ПРОГРАММЫ И МОДУЛЬНОЕ ПРОГРАММИРОВАНИЕ
Цель разработки структуры программы. Понятие программного модуля. Основные характеристики программного модуля. Методы разработки структуры программы. Спецификация программного модуля. Контроль структуры программы.
Упражнения к лекции 6.
6.1. Что такое программный модуль?
6.2. Что такое прочность программного модуля?
6.3. Что такое сцепление программного модуля?
Литература к лекции 6.
6.1. Дж.Хьюз, Дж.Мичтом. Структурный подход к программированию. М.: Мир, 1980. - С. 29-71.
6.2. В.Турский. Методология программирования. - М.: Мир, 1981. - С. 90-164.
6.3. Е.А.Жоголев. Технологические основы модульного программирования//Программирование,1980, #2. - С. 44-49.
6.4. R.C.Holt. Structure of Computer Programs: A Survey // Proceedings of the IEEE, 1975, 63(6). - P. 879-893.
6.5. Г.Майерс. Надежность программного обеспечения. М.: Мир, 1980. - С. 92-113.
6.6 Я.Пайл. АДА - язык встроенных систем. М.: Финансы и статистика, 1984. - С. 67-75.
6.7 М.Зелковец, А.Шоу, Дж.Гэннон. Принципы разработки программного обеспечения. М.: Мир, 1982. - С. 65-71.
6.8. А.Л.Фуксман. Технологические аспекты создания программных систем. М.: Статистика, 1979. С. 79-94.
7. Лекция 7. РАЗРАБОТКА ПРОГРАММНОГО МОДУЛЯ
Порядок разработки программного модуля. Структурное программирование и пошаговая детализация. Понятие о псевдокоде. Контроль программного модуля.
Упражнения к лекции 7.
7.1. Что такое структурное программирование?
7.2. Что такое пошаговая детализация программного модуля?
7.3. Что такое псевдокод?
Литература к лекции 7.
7.1. Г.Майерс. Надежность программного обеспечения. - М.: Мир, 1980. - С. 127-154.
7.2. Э.Дейкстра. Заметки по структурному программированию / У.Дал, Э.Дейкстра, К.Хоор. Структурное программирование. - М.: Мир, 1975. - С. 24-97.
7.3. Н.Вирт. Систематическое программирование. - М.: Мир, 1977. - С. 94-164.
8. Лекция 8. ДОКАЗАТЕЛЬСТВО СВОЙСТВ ПРОГРАММ
Понятие обоснования программ. Формализация свойств программ, триады Хоора. Правила для установления свойств оператора присваивания, условного и составного операторов. Правила для установления свойств оператора цикла, понятие инварианта цикла. Завершимость выполнения программы.
Пример доказательства свойства программы.
На основании доказанных правил верификации программ можно доказывать свойства программ, состоящих из операторов присваивания и пустых операторов и использующих три основные композиции структурного программирования. Для этого, анализируя структуру программы и используя заданные ее пред- и постусловия, необходимо на каждом шаге анализа применять подходящее правило верификации. В случае применения композиции повторения потребуется подобрать подходящий инвариант цикла.
В качестве примера докажем свойство (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.
Упражнения к лекции 8.
8.1. Что такое триада Хоора?
8.2. Что такое свойство программы?
8.3. Пусть заданы описания
const n= <конкретное целое значение>;
var k, m: integer;
x: array[1..n] of integer;
Доказать свойство программы:
{n>0}
m:= x[1]
k:=1;
ПОКА k<n ДЕЛАТЬ
k:= k+1;
ЕСЛИ x[k]<m ТО
m:= x[k]
ВСЕ ЕСЛИ
ВСЕ ПОКА;
{n>0 & m<= x[i] для всех i, 1<=i<= n}
Литература к лекции 8.
8.1. С.А. Абрамов. Элементы программирования. - М.: Наука, 1982. С. 85-94.
8.2. М. Зелковец, А. Шоу, Дж. Гэннон. Принципы разработки программного обеспечения. - М.: Мир, 1982. С. 98-105.
9. Лекция 9. ТЕСТИРОВАНИЕ И ОТЛАДКА ПРОГРАММНОГО СРЕДСТВА
Основные понятия. Стратегия проектирования тестов. Заповеди отладки. Автономная отладка и тестирование программного модуля. Комплексная отладка и тестирование программного средства.
Основные понятия.
Отладка ПС - это деятельность, направленная на обнаружение и исправление ошибок в ПС с использованием процессов выполнения его программ. Тестирование ПС - это процесс выполнения его программ на некотором наборе данных, для которого заранее известен результат применения или известны правила поведения этих программ. Указанный набор данных называется тестовым или просто тестом. Таким образом, отладку можно представить в виде многократного повторения трех процессов: тестирования, в результате которого может быть констатировано наличие в ПС ошибки, поиска места ошибки в программах и документации ПС и редактирования программ и документации с целью устранения обнаруженной ошибки. Другими словами:
Отладка = Тестирование + Поиск ошибок + Редактирование.
В зарубежной литературе отладку часто понимают [10.1-10.3] только как процесс поиска и исправления ошибок (без тестирования), факт наличия которых устанавливается при тестировании. Иногда тестирование и отладку считают синонимами [10.4,10.5]. В нашей стране в понятие отладки обычно включают и тестирование [10.6 -10.8], поэтому мы будем следовать сложившейся традиции. Впрочем, совместное рассмотрение в данной лекции этих процессов делает указанное разночтение не столь существенным. Следует, однако, отметить, что тестирование используется и как часть процесса аттестации ПС (см. лекцию 14).
Упражнения к лекции 9.
9.1. Что такое отладка программного средства?
9.2. Что такое тестирование программного средства?
9.3. Что такое автономная отладка программного средства?
9.4. Что такое комплексная отладка программного средства?
9.5. Что такое ведущий отладочный модуль?
9.6. Что такое отладочный имитатор программного модуля?
Литература к лекции 9.
9.1. Г. Майерс. Надежность программного обеспечения. - М.: Мир, 1980. - С. 171-262.
9.2. Д. Ван Тассел. Стиль, разработка, эффективность, отладка и испытание программ. - М.: Мир, 1985. - С. 179-295.
9.3. Дж. Хьюз, Дж. Мичтом. Структурный подход к программированию. - М.: Мир, 1980. - С. 254-268.
9.4. Дж. Фокс. Программное обеспечение и его разработка. - М.: Мир, 1985. - С. 227-241.
9.5. М. Зелковиц, А. Шоу, Дж. Гэннон. Принципы разработки программного обеспечения. - М.: Мир, 1982. - С. 105-116.
9.6. Ю.М. Безбородов. Индивидуальная отладка программ. - М.: Наука, 1982. - С. 9-79.
9.7. В.В. Липаев. Тестирование программ. - М.: Радио и связь, 1986. - С. 15-47.
9.8. Е.А. Жоголев. Введение в технологию программирования (конспект лекций). - М.: "ДИАЛОГ-МГУ", 1994.
9.9. Э. Дейкстра. Заметки по структурному программированию / У. Дал, Э. Дейкстра, К. Хоор. Структурное программирование. - М.: Мир, 1975. - С. 7-13.
10. Лекция 10. ОБЕСПЕЧЕНИЕ ФУНКЦИОНАЛЬНОСТИ И НАДЕЖНОСТИ ПРОГРАММНОГО СРЕДСТВА
Функциональность и надежность как обязательные критерии качества программного средства. Обеспечение завершенности программного средства. Защитное программирование и обеспечение устойчивости программного модуля. Виды защиты и обеспечение защищенности программного средства.
Защита от сбоев аппаратуры.
В настоящее время этот вид защиты является не очень злободневной задачей (с учетом уровня достигнутой надежности компьютеров). Но все же полезно знать ее решение. Это обеспечивается организацией т.н. «двойных или тройных просчетов». Для этого весь процесс обработки данных, определяемый ПС, разбивается по времени на интервалы так называемыми «опорными точками». Длина этого интервала не должна превосходить половины среднего времени безотказной работы компьютера. В начале каждого такого интервала во вторичную память записывается с некоторой контрольной суммой копия состояния изменяемой в этом процессе памяти («опорная точка»). Для того, чтобы убедиться, что обработка данных от одной опорной точки до следующей (т.е. один «просчет») произведена правильно (без сбоев компьютера), производится два таких «просчета». После первого «просчета» вычисляется и запоминается указанная контрольная сумма, а затем восстанавливается состояние памяти по опорной точке и делается второй «просчет». После второго «просчета» вычисляется снова указанная контрольная сумма, которая затем сравнивается с контрольной суммой первого «просчета». Если эти две контрольные суммы совпадают, второй просчет считается правильным, в противном случае контрольная сумма второго «просчета» также запоминается и производится третий «просчет» (с предварительным восстановлением состояния памяти по опорной точке). Если контрольная сумма третьего «просчета» совпадет с контрольной суммой одного из первых двух «просчетов», то третий просчет считается правильным, в противном случае требуется инженерная проверка компьютера.
Защита от защиты.
Защита от несанкционированного доступа может создать нежелательную ситуацию для самого владельца прав доступа к ресурсам ПС - он не сможет воспользоваться этими правами, если забудет (или потеряет) свой пароль («ключ»). Для защиты интересов пользователя в таких ситуациях и предназначена защита от защиты. Для обеспечения такой защиты ПС должно иметь привилегированного пользователя, называемого администратором ПС. Администратор ПС должен, в частности, отвечать за функционирование защиты ПС: именно он должен формировать контингент пользователей данного экземпляра ПС, предоставляя каждому из этих пользователей определенные права доступа к ресурсам ПС. В ПС должна быть привилегированная операция (для администратора), позволяющая временно снимать защиту от несанкционированного доступа для пользователя с целью фиксации требуемого пароля («замка»).
Упражнения к лекции 10.
10.1. Что такое защитное программирование?
10.2. Какие виды защиты программного средства от искажения информации Вы знаете?
10.3. Какие требования предъявляются к компьютеру, чтобы можно было обеспечить защиту программы от отказов другой программы в мультипрограммном режиме?
10.4. Что такое компьютерная подпись?
10.5. Что такое компьютерная печать?
Литература к лекции 10.
10.1. И.С. Березин, Н.П. Жидков. Методы вычислений, т.т. 1 и 2. - М.: Физматгиз, 1959.
10.2. Н.С. Бахвалов, Н.П. Жидков, Г.М.Кобельков. Численные методы. - М.: Наука, 1987.
10.3. Г. Майерс. Надежность программного обеспечения. - М.: Мир, 1980. С. 141-146.
10.4. А.Н. Лебедев. Защита банковской информации и современная криптография // Вопросы защиты информации, 2(29), 1995.
11. Лекция 11. ОБЕСПЕЧЕНИЕ КАЧЕСТВА ПРОГРАММНОГО СРЕДСТВА
Общий обзор. Реализация пользовательского интерфейса и обеспечение легкости применения программного средства. Обеспечение эффективности программного средства. Обеспечение сопровождаемости и управление конфигурацией программного средства. Аппаратно-операционные платформы и обеспечение мобильности программного средства.
Обеспечение мобильности.
Проблема мобильности возникает из-за того, что быстрое развитие компьютерной техники и аппаратных средств делает жизненный цикл многих больших программных средств (программных систем) намного продолжительнее периода «морально» оправданного существования компьютеров и аппаратуры, для которых первоначально создавались эти программные средства. Поэтому обеспечение критерия мобильности для таких ПС является весьма важной задачей.
Мобильность ПС определяется такими примитивами качества ПС как независимость от устройств, автономность, структурированность и модульность.
Если бы ПС обладало таками примитивами качества, как независимость от устройств и автономность, и его программы были бы представлены на машинно-независимом языке программирования, то перенос ПС в другую среду обеспечивался бы перетрансляцией (перекомпиляцией) его программ в этой среде. Однако трудно представить реальное ПС, обладающее таким качеством. Тем не менее, таким качеством могут обладать отдельные части программ ПС и даже весьма значительные. А это уже явный намек на то, каким путем следует добиваться мобильности ПС.
Если ПС зависит от устройств (аппаратуры), то в спецификации качества должна быть описана эта компьютерно-аппаратная среда (будем ее называть аппаратной платформой [12.6]). Избавится от этой зависимости можно за счет такого примитива качества ПС как автономность. Как правило, ПС строится в рамках некоторой операционной системы (ОС), которая может спрятать специфику аппаратной платформы и, тем самым, сделать ПС независимым от устройств. Но тогда ПС не будет обладать свойством автономности. В этом случае в спецификации качества должна быть описана эта программная среда, над которой строится ПС (будем эту среду называть операционной платформой [12.6]). Таким образом, мобильность ПС будет непосредственно связано с мобильностью используемой ОС: перенос ПС на другую аппаратную платформу осуществляется автоматически, если будет осуществлен перенос на эту платформу используемой ОС. Но обеспечение мобильности ОС является самостоятельной и довольно трудной задачей.
Таким образом, для обеспечения мобильности ПС нужно решить две задачи:
выделение по возможности наибольшей части программ ПС, обладающей свойствами независимости от устройств и автономности (другими словами, независимой от аппаратно-операционной платформы);
обеспечение сопровождаемости для остальных частей программ ПС.
Для решения этих задач целесообразно выбрать в качестве архитектуры ПС слоистую систему (см. рис. 12.1). Основной слой, реализующий основные функции ПС, должен быть независимым от аппаратно-операционной платформы. Выделяется также слой (часто называемый ядром ПС), который включает программные модули, зависящие от аппаратно-операционной платформы. Этот слой должен обеспечивать, в частности, доступ к внешней информационной среде ПС. Между этими слоями должен быть определен интерфейс, независимый от аппаратно-операционной платформы и обеспечивающий правила обращения из основного слоя к модулям ядра. Будем называть этот интерфейс системным. Использование графических пользовательских интерфейсов требует выделение еще одного программного слоя, зависящего от той части аппаратно-операционной платформы (графической пользовательской платформы), на которой строятся пользовательские интерфейсы. Будем называть этот слой оболочкой ПС. Между оболочкой и основным слоем также должен быть определен интерфейс, независимый от графической пользовательской платформы и обеспечивающий правила обращения из оболочки к модулям основного слоя.
 |
Рис. 12.1. Рекомендуемая архитектура мобильного ПС.
Модульность ПС позволяет сформировать указанные слои, выделяя программные модули с требуемыми свойствами и распределяя их между указанными слоями. Модульность и структурированность оболочки и ядра позволяют обеспечить эти слои свойством модифицируемости. При этом желательно, чтобы каждый модуль этих слоев был ориентирован на реализацию каких-либо функций управления четко выделенной компоненты аппаратно-операционной среды. Для этого используются такие методы как унификация интерфейсов, стандартизация протоколов и т.п. [12.6].
Упражнения к лекции 11.
11.1. Какие задачи приходиться решать при обеспечении коммуникабельности ПС?
11.2. Какие возможности предоставляет пользователю графический пользовательский интерфейс?
11.3. Как нужно действовать для обеспечения эффективности ПС?
11.4. Что такое инсталятор программного средства (ПС)?
11.5. Что такое управление конфигурацией ПС?
11.6. Что такое ядро ПС?
11.7. Что т