Программирование
Программа как описание процесса обработки данных. Неконструктивность понятия правильной программы. Надежность программного средства. Технология программирования как технология разработки надежных программных средств. Интеллектуальные возможности.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | курс лекций |
| Язык | русский |
| Дата добавления | 26.12.2008 |
| Размер файла | 168,3 K |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
ЗАМОК ДРАКОНА
Математика делает то, что можно, так, как нужно, тогда как информатика делает то, что нужно, так, как можно.
Программистский фольклор
Лекция 1.
НАДЁЖНОЕ ПРОГРАММНОЕ СРЕДСТВО КАК ПРОДУКТ ТЕХНОЛОГИИ ПРОГРАММИРОВАНИЯ. ИСТОРИЧЕСКИЙ И СОЦИАЛЬНЫЙ КОНТЕКСТ ПРОГРАММИРОВАНИЯ
Понятие информационной среды процесса обработки данных. Программа как формализованное описание процесса. Понятие о программном средстве. Понятие ошибки в программном средстве. Неконструктивность понятия правильной программы. Надежность программного средства. Технология программирования как технология разработки надежных программных средств. Роль в обществе компьютеров и программирования, информатизация общества. Взаимосвязь программирования и других областей знания. Применение, злоупотребление и границы компьютерной техники.
1. Программа как формализованное описание процесса обработки данных.
Программное средство
Целью программирования является описание процессов обработки данных (в дальнейшем -- просто процессов). Согласно ИФИПа [1]: данные -- это представление фактов и идей в формализованном виде, пригодном для передачи и переработке в некоем процессе, а информация -- это смысл, который придается данным при их представлении. Обработка данных -- это выполнение систематической последовательности действий с данными. Данные представляются и хранятся на т.н. носителях данных. Совокупность носителей данных, используемых при какой-либо обработке данных, будем называть информационной средой. Набор данных, содержащихся в какой-либо момент в информационной среде, будем называть состоянием этой информационной среды. Процесс можно определить как последовательность сменяющих друг друга состояний некоторой информационной среды.
Описать процесс -- означает определить последовательность состояний заданной информационной среды. Если мы хотим, чтобы по заданному описанию требуемый процесс порождался автоматически на каком-либо компьютере, необходимо, чтобы это описание было формализованным. Такое описание называется программой. С другой стороны, программа должна быть понятной и человеку, так как и при разработке программ, и при их использовании часто приходится выяснять, какой именно процесс она порождает. Поэтому программа составляется на удобном для человека формализованном языке программирования, с которого она автоматически переводится на язык соответствующего компьютера с помощью другой программы, называемой транслятором. Человеку (программисту), прежде чем составить программу на удобном для него языке программирования, приходится проделывать большую подготовительную работу по уточнению постановки задачи, выбору метода ее решения, выяснению специфики применения требуемой программы, прояснению общей организации разрабатываемой программы и многое другое. Использование этой информации может существенно упростить задачу понимания программы человеком, поэтому весьма полезно ее как-то фиксировать в виде отдельных документов (часто не формализованных, рассчитанных только для восприятия человеком).
Обычно программы разрабатываются в расчете на то, чтобы ими могли пользоваться люди, не участвующие в их разработке (их называют пользователями). Для освоения программы пользователем помимо ее текста требуется определенная дополнительная документация. Программа или логически связанная совокупность программ на носителях данных, снабженная программной документацией, называется программным средством (ПС). Программа позволяет осуществлять некоторую автоматическую обработку данных на компьютере. Программная документация позволяет понять, какие функции выполняет та или иная программа ПС, как подготовить исходные данные и запустить требуемую программу в процесс ее выполнения, а также: что означают получаемые результаты (или каков эффект выполнения этой программы). Кроме того, программная документация помогает разобраться в самой программе, что необходимо, например, при ее модификации.
2. Неконструктивность понятия правильной программы
Таким образом, можно считать, что продуктом технологии программирования является ПС, содержащее программы, выполняющие требуемые функции. Здесь под «программой» часто понимают правильную программу, т.е. программу, не содержащую ошибок. Однако понятие ошибки в программе трактуется в среде программистов неоднозначно. Согласно Майерсу [2] будем считать, что в программе имеется ошибка, если она не выполняет того, что разумно ожидать от нее пользователю. «Разумное ожидание» пользователя формируется на основании документации по применению этой программы. Следовательно, понятие ошибки в программе является существенно не формальным. В этом случае правильнее говорить об ошибке в ПС. Разновидностью ошибки в ПС является несогласованность между программами ПС и документацией по их применению. В работе [3] выделяется в отдельное понятие частный случай ошибки в ПС, когда программа не соответствует своей функциональной спецификации (описанию, разрабатываемому на этапе, предшествующему непосредственному программированию). Такая ошибка в указанной работе называется дефектом программы. Однако выделение такой разновидности ошибки в отдельное понятие вряд ли оправданно, так как причиной ошибки может оказаться сама функциональная спецификация, а не программа.
В связи с тем, что задание на ПС обычно формулируется не формально, а также из-за неформализованности понятия ошибки в ПС, нельзя доказать формальными методами (математически) правильность ПС. Нельзя показать правильность ПС и тестированием: как указал Дейкстра [4], тестирование может лишь продемонстрировать наличие в ПС ошибки. Поэтому понятие правильной ПС неконструктивно в том смысле, что после окончания работы над созданием ПС мы не сможем убедиться, что достигли цели.
3. 1.3. Надежность программного средства
Альтернативой правильного ПС является надежное ПС. Надежность ПС -- это его способность безотказно выполнять определенные функции при заданных условиях в течение заданного периода времени с достаточно большой вероятностью [5]. При этом под отказом в ПС понимают проявление в нем ошибки [2]. Таким образом, надежная ПС не исключает наличия в ней ошибок -- важно лишь, чтобы эти ошибки при практическом применении этого ПС в заданных условиях проявлялись достаточно редко. Убедиться, что ПС обладает таким свойством можно при его испытании путем тестирования, а также при практическом применении. Таким образом, фактически мы можем разрабатывать лишь надежные, а не правильные ПС.
Разрабатываемая ПС может обладать различной степенью надежности. Как измерять эту степень? Так же как в технике, степень надежности можно характеризовать [2] вероятностью работы ПС без отказа в течении определенного периода времени. Однако в силу специфических особенностей ПС определение этой вероятности наталкивается на ряд трудностей по сравнению с решением этой задачи в технике. Позже мы вернемся к более обстоятельному обсуждению этого вопроса.
При оценке степени надежности ПС следует также учитывать последствия каждого отказа. Некоторые ошибки в ПС могут вызывать лишь некоторые неудобства при его применении, тогда как другие ошибки могут иметь катастрофические последствия, например, угрожать человеческой жизни. Поэтому для оценки надежности ПС иногда используют дополнительные показатели, учитывающие стоимость (вред) для пользователя каждого отказа.
4. Технология программирования как технология разработки надежных программных средств
В соответствии с обычным значением слова «технология» [6] под технологией программирования будем понимать совокупность производственных процессов, приводящую к созданию требуемого ПС, а также описание этой совокупности процессов. Другими словами, технологию программирования мы будем понимать здесь в широком смысле как технологию разработки программных средств, включая в нее все процессы, начиная с момента зарождения идеи этого средства, и, в частности, связанные с созданием необходимой программной документации. Каждый процесс этой совокупности базируется на использовании каких-либо методов и средств, например, компьютер (в этом случае будем говорить об компьютерной технологии программирования).
В литературе имеются и другие, несколько отличающиеся, определения технологии программирования. Эти определения обсуждаются в работе [7]. Используется в литературе и близкое к технологии программирования понятие программной инженерии, определяемой как систематический подход к разработке, эксплуатации, сопровождению и изъятию из обращения программных средств [7]. Именно программной инженерии (Software Engineering) посвящена упомянутая работа [3]. Главное различие между технологией программирования и программной инженерией как дисциплинами для изучения заключается в способе рассмотрения и систематизации материала. В технологии программирования акцент делается на изучении процессов разработки ПС (технологических процессов) и порядке их прохождения - методы и инструментальные средства разработки ПС используются в этих процессах (их применение и образуют технологические процессы). Тогда как в программной инженерии изучаются прежде всего методы и инструментальные средства разработки ПС с точки зрения достижения определенных целей -- они могут использоваться в разных технологических процессах (и в разных технологиях программирования); как эти методы и средства образуют технологические процессы -- здесь вопрос второстепенный.
Не следует также путать технологию программирования с методологией программирования [8]. Хотя в обоих случаях изучаются методы, но в технологии программирования методы рассматриваются «сверху» (с точки зрения организации технологических процессов), а в методологии программирования методы рассматриваются «снизу» (с точки зрения основ их построения). В работе [9, стр. 25] методология программирования определяется как совокупность механизмов, применяемых в процессе разработки программного обеспечения и объединенных одним общим философским подходом.
Имея ввиду, что надежность является неотъемлемым атрибутом ПС, мы будем обсуждать технологию программирования как технологию разработки надёжных ПС. Это означает, что, во-первых, мы будем обсуждать все процессы разработки ПС, начиная с момента возникновения замысла ПС. Во-вторых, нас будут интересовать не только вопросы построения программных конструкций, но и вопросы описания функций и принимаемых решений с точки зрения их человеческого (неформального) восприятия, и, наконец, в качестве продукта технологии мы будем принимать надежную (а не правильную) ПС. Все это будет существенно влиять на выбор методов и инструментальных средств в процессах разработки ПС.
5. Технология программирования и информатизация общества
Технологии программирования играло разную роль на разных этапах развития программирования. По мере повышения мощности компьютеров и развития средств и методологии программирования росла и сложность решаемых на компьютерах задач, что привело к повышенному вниманию к технологии программирования. Резкое удешевление стоимости компьютеров и, в особенности, стоимости хранения информации на компьютерных носителях привело к широкому внедрению компьютеров практически во все сферы человеческой деятельности, что существенно изменило направленность технологии программирования. Человеческий фактор стал играть в ней решающую роль. Сформировалось достаточно глубокое понятие качества ПС, в котором акценты стали ставится не столько на его эффективности, сколько на удобстве работы с ним для пользователей (не говоря уже о его надежности). Широкое использование компьютерных сетей привело к интенсивному развитию распределенных вычислений, дистанционного доступа к информации и электронного способа обмена сообщениями между людьми. Компьютерная техника из средства решения отдельных задач все более превращается в средство информационного моделирования реального и мыслимого мира, способное просто отвечать людям на интересующие их вопросы. Начинается этап глубокой и полной информатизации (компьютеризации) человеческого общества. Все это ставит перед технологией программирования новые и достаточно трудные проблемы.
Сделаем краткую характеристику развития программирования по десятилетиям.
В 50-е годы мощность компьютеров (компьютеры первого поколения) была невелика, а программирование для них велось, в основном, в машинном коде. Решались, главным образом, научно-технические задачи (счёт по формулам), задание на программирование уже содержало, как правило, достаточно точную постановку задачи. Использовалась интуитивная технология программирования: почти сразу приступали к составлению программы по заданию, при этом часто задание несколько раз изменялось (что сильно увеличивало время и без того итерационного процесса составления программы), минимальная документация оформлялась уже после того, как программа начинала работать. Тем не менее, именно в этот период родилась фундаментальная для технологии программирования концепция модульного программирования [10] (для преодоления трудностей программирования в машинном коде). Появились первые языки программирования высокого уровня, из которых только ФОРТРАН пробился для использования в следующие десятилетия.
В 60-е годы можно было наблюдать бурное развитие и широкое использование языков программирования высокого уровня (АЛГОЛ 60, ФОРТРАН, КОБОЛ и др.), роль которых в технологии программирования явно преувеличивалась. Надежда на то, что эти языки решат все проблемы при разработки больших программ, не оправдалась. В результате повышения мощности компьютеров и накопления опыта программирования на языках высокого уровня быстро росла сложность решаемых на компьютерах задач, в результате чего обнаружилась ограниченность языков, проигнорировавших модульную организацию программ. И только ФОРТРАН, бережно сохранивший возможность модульного программирования, гордо прошествовал в следующие десятилетия (все его ругали, но его пользователи отказаться от его услуг не могли из-за грандиозного накопления фонда программных модулей, которые с успехом использовались в новых программах). Кроме того, было понято, что важно не только то, на каком языке мы программируем, но и то, как мы программируем [4]. Это было уже началом серьезных размышлений над методологией и технологией программирования. Появление в компьютерах 2-го поколения прерываний привело к развитию мультипрограммирования и созданию больших программных систем. Это стало возможным с использованием коллективной разработки, которая поставила ряд серьезных технологических проблем [11].
В 70-е годы получили широкое распространение информационные системы и базы данных. Этому способствовало очень важное событие, происшедшее в середине 70-ых годов: стоимость хранения одного бита информации на компьютерных носителях стала меньше, чем на традиционных. Интенсивно развивалась технология программирования [2, 8, 12, 13, 14]: обоснование и широкое внедрение нисходящей разработки и структурного программирования, развитие абстрактных типов данных и модульного программирования (в частности, возникновение идеи разделения спецификации и реализации модулей и использование модулей, скрывающих структуры данных), исследование проблем обеспечения надежности и мобильности ПС, создание методики управления коллективной разработкой ПС, появление инструментальных программных средств (программных инструментов) поддержки технологии программирования.
80-е годы характеризуются широким внедрением персональных компьютеров во все сферы человеческой деятельности и тем самым созданием обширного и разнообразного контингента пользователей ПС. Это привело к бурному развитию пользовательских интерфейсов и созданию четкой концепции качества ПС [5, 15, 16, 17, 18]. Появляются языки программирования (например, Ада), учитывающие требования технологии программирования [19]. Развиваются методы и языки спецификации ПС [1.20-1.21]. Выходит на передовые позиции объектный подход к разработке ПС [9]. Создаются различные инструментальные среды разработки и сопровождения ПС [3]. Развивается концепция компьютерных сетей.
90-е годы знаменательны широким охватом всего человеческого общества международной компьютерной сетью, персональные компьютеры стали подключаться к ней как терминалы. Это поставило ряд проблем регулирования доступа к компьютерно-сетевой информации (как технологического, так и юридического и этического характера). Остро встала проблема защиты компьютерной информации и передаваемых по сети сообщений. Стали бурно развиваться компьютерная технология (CASE-технология) разработки ПС и связанные с ней формальные методы спецификации программ. Начался решающий этап полной информатизации и компьютеризации общества.
ЛИТЕРАТУРА
И.Г. Гоулд, Дж.С. Тутилл. Терминологическая работа IFIP (Международная федерация по обработке информации) и ICC (Международный вычислительный центр) // Журн. вычисл. матем. и матем. физ., 1965, №2. -- с. 377-386.
Г. Майерс. Надежность программного обеспечения. -- М.: Мир, 1980.
Ian Sommerville. Software Engineering. -- Addison-Wesley Publishing Company, 1992.
Э. Дейкстра. Заметки по структурному программированию // У. Дал, Э. Дейкстра, К. Хоор. Структурное программирование. -- М.: Мир, 1975. -- с. 7-97.
Criteria for Evalution of Software. -- ISO TC97/SC7 #367 (Supersedes Document #327).
С.И. Ожегов. Словарь русского языка. -- М.: Советская энциклопедия, 1975.
Ф.Я. Дзержинский, И.М. Калиниченко. Дисциплина программирования Д: концепция и опыт реализации методических средств программной инженерии. -- М.: ЦНИИ информации и технико-экономических исследований по атомной науке и технике, 1988. -- с. 9-16.
В. Турский. Методология программирования. -- М.: Мир, 1981.
Г. Буч. Объектно-ориентированное проектирование с примерами применения: пер. с англ. -- М.: Конкорд, 1992.
Е.А. Жоголев. Система программирования с использованием библиотеки подпрограмм // Система автоматизация программирования. -- М.: Физматгиз, 1961. с. 15-52.
Ф.П. Брукс, мл. Как проектируются и создаются программные комплексы / Пер. с англ. А.П. Ершова. -- М.: Наука, 1979.
R.C. Holt. Structure of Computer Programs: A Survey // Proceedings of the IEEE, 1975, 63(6). -- p. 879-893.
Дж. Хьюз, Дж. Мичтом. Структурный подход к программированию. -- М.: Мир, 1980.
Е.А. Жоголев. Технологические основы модульного программирования // Программирование, 1980, №2. -- с.44-49.
Б. Боэм, Дж. Браун, Х. Каспар и др. Характеристики качества программного обеспечения. -- М.: Мир, 1981.
В.В. Липаев. Качество программного обеспечения. -- М.: Финансы и статистика, 1983.
Б. Шнейдерман. Психология программирования. -- М.: Радио и связь, 1984.
Revised version of DP9126 -- Criteria of the Evaluation of Software Quality Characteristics. ISO TC97/SC7 #610. -- Part 6.
В.Ш. Кауфман. Языки программирования. Концепции и принципы. М.: Радио и связь, 1993.
Требования и спецификации в разработке программ: пер. с англ. -- М.: Мир, 1984.
В.Н. Агафонов. Спецификация программ: понятийные средства и их организация. -- Новосибирск: Наука (Сибирское отделение), 1987.
ЗАМОК ДРАКОНА
Математика делает то, что можно, так, как нужно, тогда как информатика делает то, что нужно, так, как можно. Человеку свойственно ошибаться.
Сенека
Лекция 2.
ИСТОЧНИКИ ОШИБОК В ПРОГРАММНЫХ СРЕДСТВАХ
Интеллектуальные возможности человека, используемые при разработке программных систем. Понятия о простых и сложных системах, о малых и больших системах. Неправильный перевод информации из одного представления в другое -- основная причина ошибок при разработке программных средств. Модель перевода и источники ошибок.
1. Интеллектуальные возможности человека
Дейкстра [1] выделяет три интеллектуальные возможности человека, используемые при разработке ПС:
· способность к перебору,
· способность к абстракции,
· способность к математической индукции.
Способность человека к перебору связана с возможностью последовательного переключения внимания с одного предмета на другой с узнаванием искомого предмета. Эта способность весьма ограничена -- в среднем человек может уверенно (не сбиваясь) перебирать в пределах 1000 предметов (элементов). Человек должен научиться действовать с учетом этой своей ограниченности. Средством преодоления этой ограниченности является его способность к абстракции, благодаря которой человек может объединять разные предметы или экземпляры в одно понятие, заменять множество элементов одним элементом (другого рода). Способность человека к математической индукции позволяет ему справляться с бесконечными последовательностями.
При разработке ПС человек имеет дело с системами. Под системой будем понимать совокупность взаимодействующих (находящихся в отношениях) друг с другом элементов. ПС можно рассматривать как пример системы. Логически связанный набор программ является другим примером системы. Любая отдельная программа также является системой. Понять систему - значит осмысленно перебрать все пути взаимодействия между ее элементами. В силу ограниченности человека к перебору будем различать простые и сложные системы [2]. Под простой системой будем понимать такую систему, в которой человек может уверенно перебрать все пути взаимодействия между ее элементами, а под сложной системой -- такую систему, в которой он этого сделать не в состоянии. Между простыми и сложными системами нет чёткой границы, поэтому можно говорить и о промежуточном классе систем: к таким системам относятся программы, о которых программистский фольклор утверждает, что «в каждой отлаженной программе имеется хотя бы одна ошибка».
При разработке ПС мы не всегда можем уверенно знать обо всех связях между её элементами из-за возможных ошибок. Поэтому полезно уметь оценивать сложность системы по числу ее элементов: числом потенциальных путей взаимодействия между её элементами, т.е. n! , где n -- число её элементов. Систему назовём малой, если n < 7 (6! = 720 < 1000), систему назовём большой, если n > 7 . При n = 7 имеем промежуточный класс систем. Малая система всегда проста, а большая может быть как простой, так и сложной. Задача технологии программирования -- научиться делать большие системы простыми.
Полученная оценка простых систем по числу элементов широко используется на практике. Так, для руководителя коллектива весьма желательно, чтобы в нем не было больше шести взаимодействующих между собой подчиненных. Весьма важно также следовать правилу: «всё, что может быть сказано, должно быть сказано в шести пунктах или меньше». Этому правилу мы будем стараться следовать в настоящем пособии: всякие перечисления взаимосвязанных утверждений (набор рекомендаций, список требований и т.п.) будут соответствующим образом группироваться и обобщаться. Полезно ему следовать и при разработке ПС.
2. Неправильный перевод как причина ошибок в программных средствах
При разработке и использовании ПС мы многократно имеем дело [3] с преобразованием (переводом) информации из одной формы в другую (см. Рис. 1). Заказчик формулирует свои потребности в ПС в виде некоторых требований. Исходя из этих требований, разработчик создаёт внешнее описание ПС, используя при этом спецификацию (описание) заданной аппаратуры и, возможно, спецификацию базового программного обеспечения. На основании внешнего описания и спецификации языка программирования создаются тексты программ ПС на этом языке. По внешнему описанию ПС разрабатывается также и пользовательская документация. Текст каждой программы является исходной информацией при любом её преобразовании, в частности, при исправлении в ней ошибки. Пользователь на основании документации выполняет ряд действий для применения ПС и осуществляет интерпретацию получаемых результатов. Везде здесь, а также в ряде других процессах разработки ПС, имеет место указанный перевод информации.
Рис. 1. Грубая схема разработки и применения ПС.
На каждом из этих этапов перевод информации может быть осуществлён неправильно, например, из-за неправильного понимания исходного представления информации. Возникнув на одном из этапов ошибка в представлении информации распространяется на последующие этапы разработки и, в конечном счёте, окажется в самом ПС.
3. Модель перевода
Чтобы понять природу ошибок при переводе рассмотрим модель [3], изображённую на Рис. 2. На ней человек осуществляет перевод информации из представления A в представление B. При этом он совершает четыре основных шага перевода:
· он получает информацию, содержащуюся в представлении A, с помощью своего читающего механизма R;
· он запоминает полученную информацию в своей памяти M;
· он выбирает из своей памяти преобразуемую информацию и информацию, описывающую процесс преобразования, выполняет перевод и посылает результат своему пишущему механизму W;
· с помощью этого механизма он фиксирует представление B.
Рис. 2. Модель перевода.
На каждом из этих шагов человек может совершить ошибку разной природы. На первом шаге способность человека «читать между строк» (способность, позволяющая ему понимать текст, содержащий неточности или даже ошибки) может стать причиной ошибки в ПС. Ошибка возникает в том случае, когда при чтении документа A человек, пытаясь восстановить недостающую информацию, видит то, что он ожидает, а не то, что имел в виду автор документа A. В этом случае лучше было бы обратиться к автору документа за разъяснениями. При запоминании информации человек осуществляет её осмысливание (здесь важен его уровень подготовки и знание предметной области, к которой относится документ A). И, если он поверхностно или неправильно поймёт, то информация будет запомнена в искажённом виде. На третьем этапе забывчивость человека может привести к тому, что он может выбрать из своей памяти не всю преобразуемую информацию или не все правила перевода, в результате чего перевод будет осуществлён неверно. Это обычно происходит при большом объёме плохо организованной информации. И, наконец, на последнем этапе стремление человека поскорее зафиксировать информацию часто приводит к тому, что представление этой информации оказывается неточным, создавая ситуацию для последующей неоднозначной её интерпретации.
4. Основные пути борьбы с ошибками
Учитывая рассмотренные особенности действий человека при переводе можно указать следующие пути борьбы с ошибками:
· сужение пространства перебора (упрощение создаваемых систем),
· обеспечение требуемого уровня подготовки разработчика (это функции менеджеров коллектива разработчиков),
· обеспечение однозначности интерпретации представления информации,
· контроль правильности перевода (включая и контроль однозначности интерпретации).
ЛИТЕРАТУРА
Э. Дейкстра. Заметки по структурному программированию // У. Дал, Э. Дейкстра, К. Хоор. Структурное программирование. -- М.: Мир, 1975. -- с. 7-97.
Е.А. Жоголев. Технологические основы модульного программирования // Программирование, 1980, №2. -- с.44-49.
Г.Майерс. Надежность программного обеспечения. -- М.: Мир, 1980.
ЗАМОК ДРАКОНА
Лучшее - враг хорошего.
Народная мудрость
Лекция 3.
ОБЩИЕ ПРИНЦИПЫ РАЗРАБОТКИ ПРОГРАММНЫХ СРЕДСТВ
Специфика разработки программных средств. Жизненный цикл программного средства. Понятие качества программного средства. Обеспечение надёжности -- основной мотив разработки программного средства. Методы борьбы со сложностью. Обеспечение точности перевода. Преодоление барьера между пользователем и разработчиком. Обеспечение контроля правильности принимаемых решений.
1. Специфика разработки программных средств
Разработке программных средств присущ ряд специфических особенностей [1]:
· Прежде всего, следует отметить некоторое противостояние: неформальный характер требований к ПС (постановки задачи) и понятия ошибки в нем, но формализованный основной объект разработки -- программы ПС. Тем самым разработка ПС содержит определенные этапы формализации, а переход от неформального к формальному существенно неформален.
· Разработка ПС носит существенно творческий характер (на каждом шаге приходится делать какой-либо выбор, принимать какое-либо решение), а не сводится к выполнению какой-либо последовательности регламентированных действий. Тем самым эта разработка ближе к процессу проектирования каких-либо сложных устройств, но никак не к их массовому производству. Этот творческий характер разработки ПС сохраняется до самого ее конца.
· Следует отметить также особенность продукта разработки. Он представляет собой некоторую совокупность текстов (т.е. статических объектов), смысл же (семантика) этих текстов выражается процессами обработки данных и действиями пользователей, запускающих эти процессы (т.е. является динамическим). Это предопределяет выбор разработчиком ряда специфичных приемов, методов и средств.
· Продукт разработки имеет и другую специфическую особенность: ПС при своем использовании (эксплуатации) не расходуется и не расходует используемых ресурсов.
2. Жизненный цикл программного средства
Под жизненным циклом ПС понимают весь период его разработки и эксплуатации (использования), начиная от момента возникновения замысла ПС и кончая прекращением всех видов его использования [1, 2, 3, 4]. Жизненный цикл включает все процессы создания и использования ПС (software process).
Различают следующие стадии жизненного цикла ПС (см. Рис. 1): разработку ПС, производство программных изделий (ПИ) и эксплуатацию ПС.
Рис. 1. Стадии и фазы жизненного цикла ПС.
Стадия разработки (development) ПС состоит из этапа его внешнего описания, этапа конструирования ПС, этапа кодирования (программирование в узком смысле) ПС и этапа аттестации ПС. Всем этим этапам сопутствуют процессы документирования и управление (management) разработкой ПС. Этапы конструирования и кодирования часто перекрываются, иногда довольно сильно. Это означает, что кодирование некоторых частей программного средства может быть начато до завершения этапа конструирования.
Внешнее описание (Requirements document) ПС является описанием его поведения с точки зрения внешнего по отношению к нему наблюдателю с фиксацией требований относительно его качества. Внешнее описание ПС начинается с определения требований к ПС со стороны пользователей (заказчика).
Конструирование (design) ПС охватывает процессы: разработку архитектуры ПС, разработку структур программ ПС и их детальную спецификацию.
Кодирование (coding) -- создание текстов программ на языках программирования, их отладку с тестированием ПС.
На этапе аттестации ПС производится оценка качества ПС, после успешного завершения, которого разработка ПС считается законченной.
Программное изделие (ПИ) -- экземпляр или копия, снятая с разработанного ПС.
Изготовление ПИ -- это процесс генерации и/или воспроизведения (снятия копии) программ и программных документов ПС с целью их поставки пользователю для применения по назначению. Производство ПИ -- это совокупность работ по обеспечению изготовления требуемого количества ПИ в установленные сроки [1]. Стадия производства ПС в жизненном цикле ПС является, по существу, вырожденной (несущественной), так как представляет рутинную работу, которая может быть выполнена автоматически и без ошибок. Этим она принципиально отличается от стадии производства различной техники. В связи с этим в литературе эту стадию, как правило, не включают в жизненный цикл ПС.
Стадия эксплуатации ПС охватывает процессы хранения, внедрения и сопровождения ПС, а также транспортировки и применения (operation) ПИ по своему назначению. Она состоит из двух параллельно проходящих фаз: фазы применения ПС и фазы сопровождения ПС [4, 5].
Применение (operation) ПС -- это использование ПС для решения практических задач на компьютере путем выполнения ее программ.
Сопровождение (maintenance) ПС -- это процесс сбора информации о его качестве в эксплуатации, устранения обнаруженных в нем ошибок, его доработки и модификации, а также извещения пользователей о внесенных в него изменениях [1, 4, 5].
3. Понятие качества программного средства
Каждое ПС должно выполнять определенные функции, т.е. делать то, что задумано. Хорошее ПС должно обладать еще целым рядом свойств, позволяющим успешно его использовать в течении длительного периода, т.е. обладать определенным качеством. Качество ПС -- это совокупность его черт и характеристик, которые влияют на его способность удовлетворять заданные потребности пользователей [6]. Это не означает, что разные ПС должны обладать одной и той же совокупностью таких свойств в их высшей возможной степени. Этому препятствует тот факт, что повышение качества ПС по одному из таких свойств часто может быть достигнуто лишь ценой изменения стоимости, сроков завершения разработки и снижения качества этого ПС по другим его свойствам. Качество ПС является удовлетворительным, когда оно обладает указанными свойствами в такой степени, чтобы гарантировать успешное его использование.
Совокупность свойств ПС, которая образует удовлетворительное для пользователя качество ПС, зависит от условий и характера эксплуатации этого ПС, т.е. от позиции, с которой должно рассматриваться качество этого ПС. Поэтому при описании качества ПС должны быть, прежде всего, фиксированы критерии отбора требуемых свойств ПС. В настоящее время критериями качества ПС принято считать [6, 7, 8, 9, 10]:
· функциональность,
· надёжность,
· лёгкость применения,
· эффективность,
· сопровождаемость,
· мобильность.
Функциональность -- это способность ПС выполнять набор функций, удовлетворяющих заданным или подразумеваемым потребностям пользователей. Набор указанных функций определяется во внешнем описании ПС.
Надежность подробно обсуждалась в первой лекции.
Лёгкость применения -- это характеристики ПС, которые позволяют минимизировать усилия пользователя по подготовке исходных данных, применению ПС и оценке полученных результатов, а также вызывать положительные эмоции определённого или подразумеваемого пользователя.
Эффективность -- это отношение уровня услуг, предоставляемых ПС пользователю при заданных условиях, к объему используемых ресурсов.
Сопровождаемость -- это характеристики ПС, которые позволяют минимизировать усилия по внесению изменений для устранения в нём ошибок и по его модификации в соответствии с изменяющимися потребностями пользователей.
Мобильность -- это способность ПС быть перенесенным из одной среды (окружения) в другую, в частности, с одной ЭВМ на другую.
Функциональность и надёжность являются обязательными критериями качества ПС, причём обеспечение надёжности будет красной нитью проходить по всем этапам и процессам разработки ПС. Остальные критерии используются в зависимости от потребностей пользователей в соответствии с требованиями к ПС -- их обеспечение будет обсуждаться в подходящих разделах курса.
4. Обеспечение надёжности -- основной мотив разработки программных средств
Рассмотрим теперь общие принципы обеспечения надёжности ПС, что, как мы уже подчёркивали, является основным мотивом разработки ПС, задающим специфическую окраску всем технологическим процессам разработки ПС. В технике известны четыре подхода обеспечению надёжности [11]:
· предупреждение ошибок;
· самообнаружение ошибок;
· самоисправление ошибок;
· обеспечение устойчивости к ошибкам.
Целью подхода предупреждения ошибок -- не допустить ошибок в готовых продуктах, в нашем случае -- в ПС. Проведенное рассмотрение природы ошибок при разработке ПС позволяет для достижения этой цели сконцентрировать внимание на следующих вопросах:
· борьбе со сложностью;
· обеспечении точности перевода;
· преодоления барьера между пользователем и разработчиком;
· обеспечения контроля принимаемых решений.
Этот подход связан с организацией процессов разработки ПС, т.е. с технологией программирования. И хотя, как мы уже отмечали, гарантировать отсутствие ошибок в ПС невозможно, но в рамках этого подхода можно достигнуть приемлемого уровня надежности ПС.
Остальные три подхода связаны с организацией самих продуктов технологии, в нашем случае -- программ. Они учитывают возможность ошибки в программах. Самообнаружение ошибки в программе означает, что программа содержит средства обнаружения отказа в процессе ее выполнения. Самоисправление ошибки в программе означает не только обнаружение отказа в процессе ее выполнения, но и исправление последствий этого отказа, для чего в программе должны иметься соответствующие средства. Обеспечение устойчивости программы к ошибкам означает, что в программе содержатся средства, позволяющие локализовать область влияния отказа программы, либо уменьшить его неприятные последствия, а иногда предотвратить катастрофические последствия отказа. Однако, эти подходы используются весьма редко (может быть, относительно чаще используется обеспечение устойчивости к ошибкам). Связано это, во-первых, с тем, что многие простые методы, используемые в технике в рамках этих подходов, неприменимы в программировании, например, дублирование отдельных блоков и устройств (выполнение двух копий одной и той же программы всегда будет приводить к одинаковому эффекту -- правильному или неправильному). А, во-вторых, добавление в программу дополнительных средств приводит к её усложнению (иногда -- значительному), что в какой-то мере мешает методам предупреждения ошибок.
5. Методы борьбы со сложностью
Мы уже обсуждали в лекции 2 сущность вопроса борьбы со сложностью при разработке ПС. Известны два общих метода борьбы со сложностью систем:
· обеспечения независимости компонент системы;
· использование в системах иерархических структур.
Обеспечение независимости компонент означает разбиение системы на такие части, между которыми должны остаться по возможности меньше связей. Одним из воплощений этого метода является модульное программирование. Использование иерархических структур позволяет локализовать связи между компонентами, допуская их лишь между компонентами, принадлежащими смежным уровням иерархии. Этот метод, по существу, означает разбиение большой системы на подсистемы, образующих малую систему. Здесь существенно используется способность человека к абстрагированию.
6. Обеспечение точности перевода
Обеспечение точности перевода направлено на достижение однозначности интерпретации документов различными разработчиками, а также пользователями ПС. Это требует придерживаться при переводе определенной дисциплины. Майерс предлагает использовать общую дисциплину решения задач, рассматривая перевод как решение задачи [11]. Лучшим руководством по решению задач он считает книгу Пойа «Как решать задачу» [12]. В соответствии с этим весь процесс перевода можно разбить на следующие этапы:
· Поймите задачу;
· Составьте план (включая цели и методы решения);
· Выполните план (проверяя правильность каждого шага);
· Проанализируйте полученное решение.
7. Преодоление барьера между пользователем и разработчиком
Как обеспечить, чтобы ПС выполняла то, что пользователю разумно ожидать от нее? Для этого необходимо правильно понять, во-первых, чего хочет пользователь, и, во-вторых, его уровень подготовки и окружающую его обстановку. Поэтому следует -- привлекать пользователя в процессы принятия решений при разработке ПС, -- тщательно освоить особенности его работы (лучше всего -- побывать в его «шкуре»).
8. Контроль принимаемых решений
Обязательным шагом в каждом процессе (этапе) разработки ПС должна быть проверка правильности принятых решений. Это позволит обнаруживать и исправлять ошибки на самой ранней стадии после ее возникновения, что, во-первых, существенно снижает стоимость ее исправления и, во-вторых, повышает вероятность правильного ее устранения.
С учётом специфики разработки ПС необходимо применять везде, где это возможно,
· смежный контроль,
· сочетание как статических, так и динамических методов контроля.
Смежный контроль означает, проверку полученного документа лицами, не участвующими в его разработке, с двух сторон: во-первых, со стороны автора исходного для контролируемого процесса документа, и, во-вторых, лицами, которые будут использовать полученный документ в качестве исходного в последующих технологических процессах. Такой контроль позволяет обеспечивать однозначность интерпретации полученного документа.
Сочетание статических и динамических методов контроля означает, что нужно не только контролировать документ как таковой, но и проверять, какой процесс обработки данных он описывает. Это отражает одну из специфических особенность ПС (статическая форма, динамическое содержание).
ЛИТЕРАТУРА
Е.А. Жоголев. Введение в технологию программирования (конспект лекций). -- М.: «ДИАЛОГ-МГУ», 1994.
М. Зелковец, А. Шоу, Дж. Гэннон. Принципы разработки программного обеспечения. -- М.: Мир, 1982, с. 11.
К. Зиглер. Методы проектирования программных систем. -- М.: Мир, 1985, с. 15-23.
Дж. Фокс. Программное обеспечение и его разработка. -- М.: Мир, 1985, с. 53-67, 125-130.
Ian Sommerville. Software Engineering. -- Addison-Wesley Publishing Company, 1992.
Criteria for Evalution of Software. -- ISO TC97/SC7 #383.
Revised version of DP9126 -- Criteria for Evalution of Software Quality Characteristics. -- ISO TC97/SC7 #610. -- Part 6.
Б. Боэм, Дж. Браун, Х. Каспар и др. Характеристики качества программного обеспечения. -- М.: Мир, 1981.
В.В. Липаев. Качество программного обеспечения. -- М.: Финансы и статистика, 1983.
Б. Шнейдерман. Психология программирования. -- М.: Радио и связь, 1984. -- с. 99-103.
Г.Майерс. Надежность программного обеспечения. -- М.: Мир, 1980.
Д. Пойа. Как решать задачу. -- М.: Наука, 1961.
ЗАМОК ДРАКОНА
Не переходи мост, пока не дошел до него.
Народная пословица
Лекция 4.
ВНЕШНЕЕ ОПИСАНИЕ ПРОГРАММНОГО СРЕДСТВА
Понятие внешнего описания, его назначение и роль в обеспечении качества программного средства. Определение требований к программному средству. Спецификация качества программного средства. Основные примитивы качества программного средства. Функциональная спецификация программного средства. Контроль внешнего описания
1. Назначение внешнего описания программного средства и его роль в обеспечении качества программного средства
Разработчикам больших программных средств приходится решать весьма специфические и трудные проблемы, особенно, если это ПС должно представлять собой программную систему нового типа, в плохо компьютеризированной предметной области. Разработка ПС начинается с этапа формулирования требований к ПС, на котором, исходя из довольно смутных пожеланий заказчика, должен быть получен документ, достаточно точно определяющий задачи разработчиков ПС. Этот документ мы называем внешним описанием ПС (в литературе его часто называют спецификацией требований [1]).
Очень часто требования к ПС путают с требованиями к процессам его разработки (к технологическим процессам). Последние включать во внешнее описание не следует, если только они не связаны с оценкой качества ПС. В случае необходимости требования к технологическим процессам можно оформить в виде самостоятельного документа, который будет использоваться при управлении (руководстве) разработкой ПС.
Внешнее описание ПС играет роль точной постановки задачи, решение которой должно обеспечить разрабатываемое ПС. Более того, оно должно содержать всю информацию, которую необходимо знать пользователю для применения ПС. Оно является исходным документом для трех параллельно протекающих процессов: разработки текстов (конструированию и кодированию) программ, входящих в ПС, разработки документации по применению ПС и разработки существенной части комплекта тестов для тестирования ПС. Ошибки и неточности во внешнем описании, в конечном счете, трансформируются в ошибки самой ПС и обходятся особенно дорого, во-первых, потому, что они делаются на самом раннем этапе разработки ПС, и, во-вторых, потому, что они распространяются на три параллельных процесса. Это требует особенно серьезных мер по их предупреждению.
Исходным документом для разработки внешнего описания ПС являются определение требований к ПС. Но так как через этот документ передается от заказчика (пользователя) к разработчику основная информация относительно требуемого ПС, то формирование этого документа представляет собой довольно длительный и трудный итерационный процесс взаимодействия между заказчиком и разработчиком, с которого и начинается этап разработки требований к ПС [2]. Трудности, возникающие в этом процессе, связаны с тем, что пользователи часто плохо представляют, что им на самом деле нужно: использование компьютера в «узких» местах деятельности пользователей может на самом деле потребовать принципиального изменения всей технологии этой деятельности (о чем пользователи, как правило, и не догадываются). Кроме того, проблемы, которые необходимо отразить в определении требований, могут не иметь определенной формулировки [1], что приводит к постепенному изменению понимания разработчиками этих проблем. В связи с этим определению требований часто предшествует процесс системного анализа, в котором выясняется, насколько целесообразно и реализуемо «заказываемое» ПС, как повлияет такое ПС на деятельность пользователей и какими особенностями оно должно обладать. Иногда для прояснения действительных потребностей пользователей приходится разрабатывать упрощенную версию требуемого ПС, называемую прототипом ПС. Анализ «пробного» применения прототипа позволяет иногда существенно уточнить требования к ПС.
В определении внешнего описания легко бросаются в глаза две самостоятельные его части. Описание поведения ПС определяет функции, которые должна выполнять ПС, и потому его называют функциональной спецификацией ПС. Функциональная спецификация определяет допустимые фрагменты программ, реализующих декларированные функции. Требования к качеству ПС должны быть сформулированы так, чтобы разработчику были ясны цели [2], которые он должен стремиться достигнуть при разработке этого ПС. Эту часть внешнего описания будем называть спецификацией качества ПС (в литературе ее часто называют нефункциональной спецификацией [1], но она, как правило, включает и требования к технологическим процессам). Она, в отличие от функциональной спецификации, реализуется неформализованно и играет роль тех ориентиров, которые в значительной степени определяют выбор подходящих альтернатив при реализации функций ПС, а также определяет стиль всех документов и программ разрабатываемого ПС. Тем самым, спецификация качества играет решающую роль в обеспечении требуемого качества ПС.
Обычно разработка спецификации качества предшествует разработке функциональной спецификации ПС, так как некоторые требования к качеству ПС могут предопределять включение в функциональную спецификацию специальных функций, например, функции защиты от несанкционированного доступа к некоторым объектам информационной среды. Таким образом, структуру внешнего описания ПС можно выразить формулой:
Внешнее описание ПС = спецификация качества ПС + функциональная спецификация ПС
Таким образом, внешнее описание определяет, что должно делать ПС и какими внешними свойствами оно должно обладать. Оно не отвечает на вопрос, как должно быть устроено это ПС и как обеспечить требуемые его внешние свойства. Оно должно достаточно точно и полно определять задачи, которые должны решить разработчики требуемого ПС. В то же время оно должно быть понято представителем пользователем -- на его основании заказчиком достаточно часто принимается окончательное решение на заключение договора на разработку ПС. Внешнее описание играет большую роль в обеспечении требуемого качества ПС, так как спецификация качества ставит для разработчиков ПС конкретные ориентиры, управляющие выбором приемлемых решений при реализации специфицированных функций.
2. Определение требований к программному средству
Определение требования к ПС являются исходным документом разработки ПС -- заданием, выражающем в абстрактной форме потребности пользователя. Они в общих чертах определяют замысел ПС, характеризуют условия его использования. Неправильное понимание потребностей пользователя трансформируются в ошибки внешнего описания. Поэтому разработка ПС начинается с создания документа, достаточно полно характеризующего потребности пользователя и позволяющего разработчику адекватно воспринимать эти потребности.
Определение требований представляет собой смесь фрагментов на естественном языке, различных таблиц и диаграмм. Такая смесь, должна быть понятной пользователю, не знающего специальных программистских обозначений. Обычно в определении требований не содержится формализованных фрагментов, кроме случаев достаточно для этого подготовленных пользователей (например, математически) -- формализация этих требований составляет содержание дальнейшей работы коллектива разработчиков.
Неправильное понимание требований заказчиком, пользователями и разработчиками связано обычно с различными взглядами на роль требуемого ПС в среде его использования [1]. Поэтому важной задачей при создании определения требований является установление контекста использования ПС, включающего связи между этим ПС, аппаратурой и людьми. Лучше всего этот контекст в определении требований представить в графической форме (в виде диаграмм) с добавлением описаний сущностей используемых объектов (блоков ПС, компонент аппаратуры, персонала и т.п.) и характеристики связей между ними.
Известны три способа определения требований к ПС [2]:
· управляемый пользователем,
· контролируемый пользователем,
· независимый от пользователя.
В управляемой пользователем разработке определения требований к ПС определяются заказчиком, представляющим организацию пользователей. Это происходит обычно в тех случаях, когда организация пользователей (заказчик) заключает договор на разработку требуемого ПС с коллективом разработчиков и требования к ПС являются частью этого договора. Роль разработчика ПС в создании этих требований сводится, в основном, в выяснении того, насколько понятны ему эти требования с соответствующей критикой рассматриваемого документа. Это может приводить к созданию нескольких редакций этого документа в процессе заключения указанного договора.
В контролируемой пользователем разработке требования к ПС формулируются разработчиком при участии представителя пользователей. Роль пользователя в этом случае сводится к информированию разработчика о своих потребностях в ПС и контролю за тем, чтобы формулируемые требования действительно выражали его потребности в ПС. В конечном счёте разработанные требования, как правило, утверждаются представителем пользователя.
Подобные документы
Обоснование выбора программно-технических средств. Надежность программы и состав технических средств. Разработка структурной схемы программы, алгоритмического и программного интерфейса. Технология разработки интерфейса пользователя и программных модулей.
дипломная работа [3,2 M], добавлен 22.01.2013Характеристика этапов разработки программных средств. Спецификация, алгоритм, кодирование, отладка и тестирование. Создание справочной системы и установочного диска. Назначение программы, язык программирования. Технические требования к программе.
курсовая работа [1006,4 K], добавлен 19.12.2013Модульная структура программного продукта и типовые управляющие структуры алгоритмов обработки данных различных программных модулей в основе структурного программирования. Особенности пошаговой разработки программ. Основные типы базовых конструкций.
контрольная работа [163,7 K], добавлен 04.06.2013Возможности среды программирования delphi при разработке приложения с визуальным интерфейсом. Отладка программных модулей с использованием специализированных программных средств. Тестирование программного обеспечения. Оптимизация программного кода.
курсовая работа [974,0 K], добавлен 21.12.2016Порядок описание процесса разработки модели для разрешения задачи программирования с помощью средств языка программирования. Структуры данных и основные принципы их построения. Этапы компьютерного моделирования. Этапы и значение написания программы.
курсовая работа [19,5 K], добавлен 19.05.2011Программное обеспечение как продукт. Основные характеристик качества программного средства. Основные понятия и показатели надежности программных средств. Дестабилизирующие факторы и методы обеспечения надежности функционирования программных средств.
лекция [370,1 K], добавлен 22.03.2014Проектирование программы, реализующей синтаксический анализ простой программы на языке С: этапы создания, алгоритм ее функционирования, структура, технология обработки информации. Описание программных модулей, интерфейс; выбор инструментальных средств.
курсовая работа [1,6 M], добавлен 12.12.2011Язык разработки, среда реализации, инструменты разработки. Особенности виртуальной среды реализации программ и их учет в разработке программного продукта. Системные макросы и их применение в текстах разработки. Средства визуального программирования.
учебное пособие [1,7 M], добавлен 26.10.2013Технология и средства прикладного программирования. Физическая модель данных. Программа для управления базой данных. Добавление, удаление и редактирование информации. Трудоёмкость ведения базы данных взятых и оставшихся книг. Типы структуры данных.
курсовая работа [2,3 M], добавлен 14.04.2014Эффективные средства разработки программного обеспечения. Технология визуального проектирования и событийного программирования. Конструирование диалоговых окон и функций обработки событий. Словесный алгоритм и процедуры программы Borland Delphi 7 Studio.
дипломная работа [660,2 K], добавлен 21.05.2012
