Реферат: Программирование
З/>АМОК ДРАКОНАМатематика делает то, что можно, так, как нужно, тогдакак информатика делает то, что нужно, так, как можно.
Программистский фольклор
Лекция 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-технология) разработки ПС и связанныес ней формальные методы спецификации программ. Начался решающий этап полнойинформатизации и компьютеризации общества./>
ЛИТЕРАТУРА
1. И.Г. Гоулд, Дж.С.Тутилл.Терминологическая работа IFIP (Международная федерация по обработке информации)и ICC (Международный вычислительный центр) // Журн. вычисл. матем. и матем.физ., 1965, №2. — с. 377-386.
2. Г. Майерс. Надежность программного обеспечения.— М.: Мир, 1980.
3. IanSommerville. Software Engineering. — Addison-Wesley Publishing Company, 1992.
4. Э. Дейкстра. Заметки по структурномупрограммированию // У. Дал, Э. Дейкстра, К. Хоор. Структурное программирование.— М.: Мир, 1975. — с. 7-97.
5. Criteriafor Evalution of Software. — ISO TC97/SC7 #367 (Supersedes Document #327).
6. С.И. Ожегов. Словарь русского языка. — М.:Советская энциклопедия, 1975.
7. Ф.Я. Дзержинский,И.М. Калиниченко. Дисциплинапрограммирования Д: концепция и опыт реализации методических средствпрограммной инженерии. — М.: ЦНИИ информации и технико-экономическихисследований по атомной науке и технике, 1988. — с. 9-16.
8. В. Турский. Методология программирования. — М.:Мир, 1981.
9. Г. Буч. Объектно-ориентированноепроектирование с примерами применения: пер. с англ. — М.: Конкорд, 1992.
10. Е.А. Жоголев. Система программирования сиспользованием библиотеки подпрограмм // Система автоматизация программирования.— М.: Физматгиз, 1961. с. 15-52.
11. Ф.П. Брукс, мл. Как проектируются и создаютсяпрограммные комплексы / Пер. с англ. А.П. Ершова. — М.: Наука, 1979.
12. R.C.Holt.Structure of Computer Programs: A Survey // Proceedings of the IEEE, 1975, 63(6).— p. 879-893.
13. Дж. Хьюз, Дж.Мичтом. Структурныйподход к программированию.— М.: Мир, 1980.
14. Е.А. Жоголев. Технологические основы модульногопрограммирования // Программирование, 1980, №2. — с.44-49.
15. Б. Боэм, Дж.Браун, Х. Каспар и др. Характеристики качества программного обеспечения. — М.: Мир, 1981.
16. В.В. Липаев. Качество программного обеспечения. —М.: Финансы и статистика, 1983.
17. Б. Шнейдерман. Психология программирования. — М.:Радио и связь, 1984.
18. Revisedversion of DP9126 — Criteria of the Evaluation of Software QualityCharacteristics. ISOTC97/SC7 #610. — Part 6.
19. В.Ш. Кауфман. Языки программирования. Концепции ипринципы. М.: Радио и связь, 1993.
20. Требования испецификации в разработке программ: пер. с англ. — М.: Мир, 1984.
21. В.Н. Агафонов. Спецификация программ: понятийныесредства и их организация. — Новосибирск: Наука (Сибирское отделение), 1987.
ЗАМОКДРАКОНА
Математика делает то, что можно, так, как нужно, тогдакак информатика делает то, что нужно, так, как можно. Человеку свойственноошибаться.
Сенека
/>Лекция 2. ИСТОЧНИКИ ОШИБОК ВПРОГРАММНЫХ СРЕДСТВАХ
Интеллектуальные возможности человека,используемые при разработке программных систем. Понятия о простых и сложныхсистемах, о малых и больших системах. Неправильный перевод информации из одногопредставления в другое — основная причина ошибок при разработке программныхсредств. Модель перевода и источники ошибок.
1. Интеллектуальные возможности человекаДейкстра [1] выделяет три интеллектуальныевозможности человека, используемые при разработке ПС:
· способность к перебору,
· способность к абстракции,
· способность к математическойиндукции.
Способность человека к перебору связана свозможностью последовательного переключения внимания с одного предмета надругой с узнаванием искомого предмета. Эта способность весьма ограничена — всреднем человек может уверенно (не сбиваясь) перебирать в пределах 1000предметов (элементов). Человек должен научиться действовать с учетом этой своейограниченности. Средством преодоления этой ограниченности является егоспособность к абстракции, благодаря которой человек может объединять разныепредметы или экземпляры в одно понятие, заменять множество элементов однимэлементом (другого рода). Способность человека к математической индукциипозволяет ему справляться с бесконечными последовательностями.
При разработке ПС человек имеет дело ссистемами. Под системой будем понимать совокупность взаимодействующих(находящихся в отношениях) друг с другом элементов. ПС можно рассматривать какпример системы. Логически связанный набор программ является другим примеромсистемы. Любая отдельная программа также является системой. Понять систему — значит осмысленно перебрать все пути взаимодействия между ее элементами. В силуограниченности человека к перебору будем различать простые и сложные системы [2].Под простой системой будем понимать такую систему, в которой человек можетуверенно перебрать все пути взаимодействия между ее элементами, а под сложнойсистемой — такую систему, в которой он этого сделать не в состоянии. Междупростыми и сложными системами нет чёткой границы, поэтому можно говорить и опромежуточном классе систем: к таким системам относятся программы, о которыхпрограммистский фольклор утверждает, что «в каждой отлаженной программе имеетсяхотя бы одна ошибка».
При разработке ПС мы не всегда можемуверенно знать обо всех связях между её элементами из-за возможных ошибок.Поэтому полезно уметь оценивать сложность системы по числу ее элементов: числомпотенциальных путей взаимодействия между её элементами, т.е. n!, где n — числоеё элементов. Систему назовём малой, если n < 7 (6! = 720 <1000), систему назовём большой, если n > 7. При n = 7имеем промежуточный класс систем. Малая система всегда проста, а большая можетбыть как простой, так и сложной. Задача технологии программирования — научитьсяделать большие системы простыми.
Полученная оценка простых систем по числуэлементов широко используется на практике. Так, для руководителя коллективавесьма желательно, чтобы в нем не было больше шести взаимодействующих междусобой подчиненных. Весьма важно также следовать правилу: «всё, что может бытьсказано, должно быть сказано в шести пунктах или меньше». Этому правилу мыбудем стараться следовать в настоящем пособии: всякие перечислениявзаимосвязанных утверждений (набор рекомендаций, список требований и т.п.)будут соответствующим образом группироваться и обобщаться. Полезно емуследовать и при разработке ПС.
2. Неправильный перевод как причина ошибок в программныхсредствах/> <td/> />При разработкеи использовании ПС мы многократно имеем дело [3] с преобразованием (переводом)информации из одной формы в другую (см. Рис. 1). Заказчик формулирует своипотребности в ПС в виде некоторых требований. Исходя из этих требований,разработчик создаёт внешнее описание ПС, используя при этом спецификацию(описание) заданной аппаратуры и, возможно, спецификацию базового программногообеспечения. На основании внешнего описания и спецификации языкапрограммирования создаются тексты программ ПС на этом языке. По внешнему описаниюПС разрабатывается также и пользовательская документация. Текст каждойпрограммы является исходной информацией при любом её преобразовании, вчастности, при исправлении в ней ошибки. Пользователь на основании документациивыполняет ряд действий для применения ПС и осуществляет интерпретациюполучаемых результатов. Везде здесь, а также в ряде других процессах разработкиПС, имеет место указанный перевод информации.
Рис. 1.Грубая схема разработки и применения ПС.
На каждом из этих этапов перевод информацииможет быть осуществлён неправильно, например, из-за неправильного пониманияисходного представления информации. Возникнув на одном из этапов ошибка впредставлении информации распространяется на последующие этапы разработки и, вконечном счёте, окажется в самом ПС.
3. Модель переводаЧтобы понять природу ошибок при переводерассмотрим модель [3], изображённую на Рис. 2. На ней человек осуществляетперевод информации из представления A в представление B. При этом он совершаетчетыре основных шага перевода:
· он получает информацию, содержащуюсяв представлении A, с помощью своего читающего механизма R;
· он запоминает полученную информацию всвоей памяти M;
· он выбирает из своей памятипреобразуемую информацию и информацию, описывающую процесс преобразования,выполняет перевод и посылает результат своему пишущему механизму W;
·
/> <td/> />с помощью этого механизма онфиксирует представление B.
Рис. 2.Модель перевода.
На каждом из этих шагов человек можетсовершить ошибку разной природы. На первом шаге способность человека «читатьмежду строк» (способность, позволяющая ему понимать текст, содержащийнеточности или даже ошибки) может стать причиной ошибки в ПС. Ошибка возникаетв том случае, когда при чтении документа A человек, пытаясь восстановитьнедостающую информацию, видит то, что он ожидает, а не то, что имел в видуавтор документа A. В этом случае лучше было бы обратиться к автору документа заразъяснениями. При запоминании информации человек осуществляет её осмысливание(здесь важен его уровень подготовки и знание предметной области, к которойотносится документ A). И, если он поверхностно или неправильно поймёт, тоинформация будет запомнена в искажённом виде. На третьем этапе забывчивостьчеловека может привести к тому, что он может выбрать из своей памяти не всю преобразуемуюинформацию или не все правила перевода, в результате чего перевод будетосуществлён неверно. Это обычно происходит при большом объёме плохоорганизованной информации. И, наконец, на последнем этапе стремление человекапоскорее зафиксировать информацию часто приводит к тому, что представление этойинформации оказывается неточным, создавая ситуацию для последующейнеоднозначной её интерпретации.
4. Основные пути борьбы с ошибкамиУчитывая рассмотренные особенности действийчеловека при переводе можно указать следующие пути борьбы с ошибками:
· сужение пространства перебора(упрощение создаваемых систем),
· обеспечение требуемого уровняподготовки разработчика (это функции менеджеров коллектива разработчиков),
· обеспечение однозначности интерпретациипредставления информации,
· контроль правильности перевода(включая и контроль однозначности интерпретации).
ЛИТЕРАТУРА
22. Э. Дейкстра. Заметки по структурномупрограммированию // У. Дал, Э. Дейкстра, К. Хоор. Структурное программирование.— М.: Мир, 1975. — с. 7-97.
23. Е.А. Жоголев. Технологические основы модульногопрограммирования // Программирование, 1980, №2. — с.44-49.
24. Г.Майерс. Надежность программного обеспечения.— М.: Мир, 1980.
ЗАМОК ДРАКОНА
Лучшее — враг хорошего.
Народная мудрость
Лекция 3. ОБЩИЕ ПРИНЦИПЫРАЗРАБОТКИ ПРОГРАММНЫХ СРЕДСТВ
Специфика разработки программных средств.Жизненный цикл программного средства. Понятие качества программного средства.Обеспечение надёжности — основной мотив разработки программного средства.Методы борьбы со сложностью. Обеспечение точности перевода. Преодоление барьерамежду пользователем и разработчиком. Обеспечение контроля правильностипринимаемых решений.
1. Специфика разработки программных средствРазработке программных средств присущ рядспецифических особенностей [1]:
· Прежде всего, следует отметитьнекоторое противостояние: неформальный характер требований к ПС (постановкизадачи) и понятия ошибки в нем, но формализованный основной объект разработки —программы ПС. Тем самым разработка ПС содержит определенные этапы формализации,а переход от неформального к формальному существенно неформален.
· Разработка ПС носит существеннотворческий характер (на каждом шаге приходится делать какой-либо выбор,принимать какое-либо решение), а не сводится к выполнению какой-либопоследовательности регламентированных действий. Тем самым эта разработка ближек процессу проектирования каких-либо сложных устройств, но никак не к ихмассовому производству. Этот творческий характер разработки ПС сохраняется досамого ее конца.
· Следует отметить также особенностьпродукта разработки. Он представляет собой некоторую совокупность текстов (т.е.статических объектов), смысл же (семантика) этих текстов выражается процессамиобработки данных и действиями пользователей, запускающих эти процессы (т.е.является динамическим). Это предопределяет выбор разработчиком ряда специфичныхприемов, методов и средств.
· Продукт разработки имеет и другуюспецифическую особенность: ПС при своем использовании (эксплуатации) нерасходуется и не расходует используемых ресурсов.
2. Жизненный цикл программного средстваПод жизненным циклом ПС понимают весь периодего разработки и эксплуатации (использования), начиная от момента возникновениязамысла ПС и кончая прекращением всех видов его использования [1, 2, 3, 4].Жизненный цикл включает все процессы создания и использования ПС (softwareprocess).
Различают следующие стадии жизненного циклаПС (см. Рис. 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. Контроль принимаемых решений
Обязательным шагом в каждом процессе (этапе)разработки ПС должна быть проверка правильности принятых решений. Это позволитобнаруживать и исправлять ошибки на самой ранней стадии после ее возникновения,что, во-первых, существенно снижает стоимость ее исправления и, во-вторых,повышает вероятность правильного ее устранения.
С учётом специфики разработки ПС необходимоприменять везде, где это возможно,
· смежный контроль,
· сочетание как статических, так идинамических методов контроля.
Смежный контроль означает, проверкуполученного документа лицами, не участвующими в его разработке, с двух сторон:во-первых, со стороны автора исходного для контролируемого процесса документа,и, во-вторых, лицами, которые будут использовать полученный документ в качествеисходного в последующих технологических процессах. Такой контроль позволяетобеспечивать однозначность интерпретации полученного документа.
Сочетание статических и динамических методовконтроля означает, что нужно не только контролировать документ как таковой, нои проверять, какой процесс обработки данных он описывает. Это отражает одну изспецифических особенность ПС (статическая форма, динамическое содержание).
ЛИТЕРАТУРА
25. Е.А. Жоголев. Введение в технологиюпрограммирования (конспект лекций). — М.: «ДИАЛОГ-МГУ», 1994.
26. М. Зелковец, А.Шоу, Дж. Гэннон. Принципыразработки программного обеспечения. — М.: Мир, 1982, с. 11.
27. К. Зиглер. Методы проектирования программныхсистем. — М.: Мир, 1985, с. 15-23.
28. Дж. Фокс. Программное обеспечение и егоразработка. — М.: Мир, 1985, с. 53-67, 125-130.
29. IanSommerville. SoftwareEngineering.— Addison-Wesley Publishing Company, 1992.
30. Criteriafor Evalution of Software. — ISO TC97/SC7 #383.
31. Revisedversion of DP9126 — Criteria for Evalution of Software QualityCharacteristics. — ISO TC97/SC7 #610. — Part 6.
32. Б. Боэм, Дж.Браун, Х. Каспар и др. Характеристики качества программного обеспечения. — М.: Мир, 1981.
33. В.В. Липаев. Качество программного обеспечения. —М.: Финансы и статистика, 1983.
34. Б. Шнейдерман. Психология программирования. — М.:Радио и связь, 1984. — с. 99-103.
35. Г.Майерс. Надежность программного обеспечения.— М.: Мир, 1980.
36. Д. Пойа. Как решать задачу. — М.: Наука,1961.
ЗАМОКДРАКОНА
Не переходи мост, пока не дошел до него.
Народная пословица
Лекция 4. ВНЕШНЕЕ ОПИСАНИЕПРОГРАММНОГО СРЕДСТВАПонятие внешнего описания, его назначение ироль в обеспечении качества программного средства. Определение требований кпрограммному средству. Спецификация качества программного средства. Основныепримитивы качества программного средства. Функциональная спецификацияпрограммного средства. Контроль внешнего описания
1. Назначение внешнего описания программного средства и егороль в обеспечении качества программного средстваРазработчикам больших программных средствприходится решать весьма специфические и трудные проблемы, особенно, если этоПС должно представлять собой программную систему нового типа, в плохокомпьютеризированной предметной области. Разработка ПС начинается с этапаформулирования требований к ПС, на котором, исходя из довольно смутныхпожеланий заказчика, должен быть получен документ, достаточно точноопределяющий задачи разработчиков ПС. Этот документ мы называем внешнимописанием ПС (в литературе его часто называют спецификацией требований [1]).
Очень часто требования к ПС путают стребованиями к процессам его разработки (к технологическим процессам).Последние включать во внешнее описание не следует, если только они не связаны соценкой качества ПС. В случае необходимости требования к технологическимпроцессам можно оформить в виде самостоятельного документа, который будетиспользоваться при управлении (руководстве) разработкой ПС.
Внешнее описание ПС играет роль точнойпостановки задачи, решение которой должно обеспечить разрабатываемое ПС. Болеетого, оно должно содержать всю информацию, которую необходимо знатьпользователю для применения ПС. Оно является исходным документом для трехпараллельно протекающих процессов: разработки текстов (конструированию икодированию) программ, входящих в ПС, разработки документации по применению ПСи разработки существенной части комплекта тестов для тестирования ПС. Ошибки инеточности во внешнем описании, в конечном счете, трансформируются в ошибкисамой ПС и обходятся особенно дорого, во-первых, потому, что они делаются насамом раннем этапе разработки ПС, и, во-вторых, потому, что онираспространяются на три параллельных процесса. Это требует особенно серьезныхмер по их предупреждению.
Исходным документом для разработки внешнего описанияПС являются определение требований к ПС. Но так как через этот документпередается от заказчика (пользователя) к разработчику основная информацияотносительно требуемого ПС, то формирование этого документа представляет собойдовольно длительный и трудный итерационный процесс взаимодействия междузаказчиком и разработчиком, с которого и начинается этап разработки требованийк ПС [2]. Трудности, возникающие в этом процессе, связаны с тем, чтопользователи часто плохо представляют, что им на самом деле нужно:использование компьютера в «узких» местах деятельности пользователей может насамом деле потребовать принципиального изменения всей технологии этойдеятельности (о чем пользователи, как правило, и не догадываются). Кроме того,проблемы, которые необходимо отразить в определении требований, могут не иметьопределенной формулировки [1], что приводит к постепенному изменению пониманияразработчиками этих проблем. В связи с этим определению требований частопредшествует процесс системного анализа, в котором выясняется, насколькоцелесообразно и реализуемо «заказываемое» ПС, как повлияет такое ПС надеятельность пользователей и какими особенностями оно должно обладать. Иногдадля прояснения действительных потребностей пользователей приходитсяразрабатывать упрощенную версию требуемого ПС, называемую прототипом ПС. Анализ«пробного» применения прототипа позволяет иногда существенно уточнитьтребования к ПС.
В определении внешнего описания легкобросаются в глаза две самостоятельные его части. Описание поведения ПСопределяет функции, которые должна выполнять ПС, и потому его называют функциональнойспецификацией ПС. Функциональная спецификация определяет допустимые фрагментыпрограмм, реализующих декларированные функции. Требования к качеству ПС должныбыть сформулированы так, чтобы разработчику были ясны цели [2], которые ондолжен стремиться достигнуть при разработке этого ПС. Эту часть внешнегоописания будем называть спецификацией качества ПС (в литературе ее частоназывают нефункциональной спецификацией [1], но она, как правило, включает итребования к технологическим процессам). Она, в отличие от функциональнойспецификации, реализуется неформализованно и играет роль тех ориентиров,которые в значительной степени определяют выбор подходящих альтернатив приреализации функций ПС, а также определяет стиль всех документов и программ разрабатываемогоПС. Тем самым, спецификация качества играет решающую роль в обеспечениитребуемого качества ПС.
Обычно разработка спецификации качествапредшествует разработке функциональной спецификации ПС, так как некоторыетребования к качеству ПС могут предопределять включение в функциональнуюспецификацию специальных функций, например, функции защиты отнесанкционированного доступа к некоторым объектам информационной среды. Такимобразом, структуру внешнего описания ПС можно выразить формулой:
Внешнее описание ПС = спецификация качестваПС + функциональная спецификация ПС
Таким образом, внешнее описание определяет,что должно делать ПС и какими внешними свойствами оно должно обладать. Оно неотвечает на вопрос, как должно быть устроено это ПС и как обеспечить требуемыеего внешние свойства. Оно должно достаточно точно и полно определять задачи,которые должны решить разработчики требуемого ПС. В то же время оно должно бытьпонято представителем пользователем — на его основании заказчиком достаточночасто принимается окончательное решение на заключение договора на разработкуПС. Внешнее описание играет большую роль в обеспечении требуемого качества ПС,так как спецификация качества ставит для разработчиков ПС конкретные ориентиры,управляющие выбором приемлемых решений при реализации специфицированныхфункций.
2. Определение требований к программному средствуОпределение требования к ПС являютсяисходным документом разработки ПС — заданием, выражающем в абстрактной формепотребности пользователя. Они в общих чертах определяют замысел ПС,характеризуют условия его использования. Неправильное понимание потребностейпользователя трансформируются в ошибки внешнего описания. Поэтому разработка ПСначинается с создания документа, достаточно полно характеризующего потребностипользователя и позволяющего разработчику адекватно воспринимать этипотребности.
Определение требований представляет собойсмесь фрагментов на естественном языке, различных таблиц и диаграмм. Такаясмесь, должна быть понятной пользователю, не знающего специальныхпрограммистских обозначений. Обычно в определении требований не содержитсяформализованных фрагментов, кроме случаев достаточно для этого подготовленныхпользователей (например, математически) — формализация этих требований составляетсодержание дальнейшей работы коллектива разработчиков.
Неправильное понимание требованийзаказчиком, пользователями и разработчиками связано обычно с различнымивзглядами на роль требуемого ПС в среде его использования [1]. Поэтому важнойзадачей при создании определения требований является установление контекстаиспользования ПС, включающего связи между этим ПС, аппаратурой и людьми. Лучшевсего этот контекст в определении требований представить в графической форме (ввиде диаграмм) с добавлением описаний сущностей используемых объектов (блоковПС, компонент аппаратуры, персонала и т.п.) и характеристики связей между ними.
Известны три способа определения требованийк ПС [2]:
· управляемыйпользователем,
· контролируемыйпользователем,
· независимый отпользователя.
В управляемой пользователем разработкеопределения требований к ПС определяются заказчиком, представляющим организациюпользователей. Это происходит обычно в тех случаях, когда организацияпользователей (заказчик) заключает договор на разработку требуемого ПС сколлективом разработчиков и требования к ПС являются частью этого договора.Роль разработчика ПС в создании этих требований сводится, в основном, ввыяснении того, насколько понятны ему эти требования с соответствующей критикойрассматриваемого документа. Это может приводить к созданию нескольких редакцийэтого документа в процессе заключения указанного договора.
В контролируемой пользователем разработкетребования к ПС формулируются разработчиком при участии представителяпользователей. Роль пользователя в этом случае сводится к информированиюразработчика о своих потребностях в ПС и контролю за тем, чтобы формулируемыетребования действительно выражали его потребности в ПС. В конечном счётеразработанные требования, как правило, утверждаются представителемпользователя.
В независимой от пользователя разработкетребования к ПС определяются без какого-либо участия пользователя (на полнуюответственность разработчика). Это происходит обычно тогда, когда разработчикрешает создать ПС широкого применения в расчете на то, разработанное им ПСнайдет спрос на рынке программных средств.
С точки зрения обеспечения надежности ПСнаиболее предпочтительным является контролируемая пользователем разработка.
3. Спецификация качества программного средстваРазработка спецификации качества сводится,по существу, к построению своеобразной модели качества разрабатываемой ПС [2, 3].В этой модели должен быть перечень всех тех достаточно элементарных свойств,которые требуется обеспечить в разрабатываемом ПС и которые в совокупностиобразуют приемлемое для пользователя качество ПС. При этом каждое из этихсвойств должно быть в достаточной степени конкретизировано с учетом определениятребований к разрабатываемому ПС и возможности оценки его наличия уразработанного ПС или необходимой степени обладания им этим ПС.
Для конкретизации качества ПС по каждому изкритериев используется стандартизованный набор достаточно простых свойств ПС [3,4, 5, 6], однозначно интерпретируемых разработчиками. Такие свойства мы будемназывать примитивами качества ПС. Некоторые из примитивов могут использоватьсяпо нескольким критериям. Ниже приводится зависимость критериев качества отпримитивов качества ПС.
Функциональность: завершенность.
Надежность: завершенность, точность,автономность, устойчивость, защищенность.
Легкость применения:П-документированность, информативность (только применительно к документации поприменению), коммуникабельность, устойчивость, защищенность.
Эффективность: временнaяэффективность, эффективность по памяти, эффективность по устройствам.
Сопровождаемость. С данным критериемсвязано много различных примитивов качества. Однако их можно распределить подвум группам, выделив два подкритерия качества: изучаемость и модифицируемость.Изучаемость — это характеристики ПС, которые позволяют минимизировать усилия поизучению и пониманию программ и документации ПС. Модифицируемость — этохарактеристики ПС, которые упрощают внесение в него необходимых изменений идоработок.
Изучаемость: С-документированность,информативность (здесь применительно и к документации по сопровождению),понятность, структурированность, удобочитаемость.
Модифицируемость: расширяемость,структурированность, модульность.
Мобильность: независимость от устройств,автономность, структурированность, модульность.
Ниже даются определения используемыхпримитивов качества ПС [3, 4, 5].
Завершенность — свойство, характеризующее степеньобладания ПС всеми необходимыми частями и чертами, требующимися для выполнениясвоих явных и неявных функций.
Точность — мера, характеризующая приемлемостьвеличины погрешности в выдаваемых программами ПС результатах с точки зренияпредполагаемого их использования.
Автономность — свойство, характеризующееспособность ПС выполнять предписанные функции без помощи или поддержки другихкомпонент программного обеспечения.
Устойчивость — свойство, характеризующее способностьПС продолжать корректное функционирование, несмотря на задание неправильных(ошибочных) входных данных.
Защищенность — свойство, характеризующееспособность ПС противостоять преднамеренным или нечаянным деструктивным(разрушающим) действиям пользователя.
П-документированность — свойство,характеризующее наличие, полноту, понятность, доступность и наглядностьучебной, инструктивной и справочной документации, необходимой для примененияПС.
Информативность — свойство,характеризующее наличие в составе ПС информации, необходимой и достаточной дляпонимания назначения ПС, принятых предположений, существующих ограничений,входных данных и результатов работы отдельных компонент, а также текущегосостояния программ в процессе их функционирования.
Коммуникабельность — свойство,характеризующее степень, в которой ПС облегчает задание или описание входныхданных, а также обеспечивает выдачу полезных сведений в форме и с содержанием,простыми для понимания.
Временнaя эффективность — мера,характеризующая способность ПС выполнять возложенные на него функции заопределенный отрезок времени.
Эффективность по памяти — мера,характеризующая способность ПС выполнять возложенные на него функции приопределенных ограничениях на используемую память.
Эффективность по устройствам — мера,характеризующая экономичность использования устройств машины для решенияпоставленной задачи.
С-документировапнность — свойство,характеризующее с точки зрения наличия документации, отражающей требования к ПСи результаты различных этапов разработки данной ПС, включающие возможности,ограничения и другие черты ПС, а также их обоснование.
Понятность — свойство, характеризующее степень вкоторой ПС позволяет изучающему его лицу понять его назначение, сделанныедопущения и ограничения, входные данные и результаты работы его программ,тексты этих программ и состояние их реализации. Этот примитив качествасинтезирован нами из таких примитивов ИСО [4.4], как согласованность,самодокументированность, четкость и, собственно, понятность.
Структурированность — свойство,характеризующее программы ПС с точки зрения организации взаимосвязанных ихчастей в единое целое определенным образом (например, в соответствии спринципами структурного программирования).
Удобочитаемость — свойство, характеризующеелегкость восприятия текста программ ПС (отступы, фрагментация, формативность).
Расширяемость — свойство, характеризующееспособность ПС к использованию большего объема памяти для хранения данных илирасширению функциональных возможностей отдельных компонент.
Модульность — свойство, характеризующее ПС сточки зрения организации его программ из таких дискретных компонент, чтоизменение одной из них оказывает минимальное воздействие на другие компоненты.
Независимость от устройств — свойство, характеризующееспособность ПС работать на разнообразном аппаратном обеспечении (различныхтипах, марках, моделях ЭВМ).
4. Функциональная спецификация программного средстваС учетом назначения функциональнойспецификации ПС и тяжелых последствий неточностей и ошибок в этом документе,функциональная спецификация должна быть математически точной. Это не означает,что она должна быть формализована настолько, что по ней можно было быавтоматически генерировать программы, решающие поставленную задачу. А означает лишь,что она должна базироваться на понятиях, построенных как математическиеобъекты, и утверждениях, однозначно понимаемых разработчиками ПС. Достаточночасто функциональная спецификация формулируется на естественном языке. Тем неменее, использование математических методов и формализованных языков приразработке функциональной спецификации весьма желательно, поэтому этим вопросамбудет посвящена отдельная лекция.
Функциональная спецификация состоит из трехчастей:
· описания внешнейинформационной среды, к которой должны применяться программы разрабатываемойПС;
· определениефункций ПС, определенных на множестве состояний этой информационной среды(такие функции будем называть внешними функциями ПС);
· описаниенежелательных (исключительных) ситуаций, которые могут возникнуть привыполнении программ ПС, и реакций на эти ситуации, которые должны обеспечитьсоответствующие программы.
В первой части должны быть определены наконцептуальном уровне все используемые каналы ввода и вывода и всеинформационные объекты, к которым будет применяться разрабатываемое ПС, а такжесущественные связи между этими информационными объектами. Примером описанияинформационной среды может быть концептуальная схема базы данных или описаниесети датчиков и приборов, которой должна управлять разрабатываемая ПС.
Во второй части вводятся обозначения всехопределяемых функций, специфицируются все входные данные и результатывыполнения каждой определяемой функции, включая указание их типов и заданийвсех соотношений (или ограничений), которым должны удовлетворять эти данные ирезультаты. И, наконец, определяется семантика каждой из этих функций, чтоявляется наиболее трудной задачей функциональной спецификации ПС. Обычно этасемантика описывается неформально на естественном языке — примерно так, как этоделается при описании семантики многих языков программирования. Эта задачаможет быть в ряде случаев существенно облегчена при достаточно четком описаниивнешней информационной среды, если внешние функции задают какие-либо манипуляциис ее объектами.
В третьей части должны быть перечислены всесущественные с точки зрения внешнего наблюдателя (пользователя) случаи, когдаПС не сможет нормально выполнить ту или иную свою функцию (например, приобнаружении ошибки во время взаимодействия с пользователем, или при попыткеприменить какую-либо функцию к данным, не удовлетворяющим соотношениям,указанным в ее спецификации, или при получении результата, нарушающего заданноеограничение). Для каждого такого случая должна быть определена (описана)реакция ПС.
5. Методы контроля внешнего описания программного средстваРазработка внешнего описания обязательнодолжна завершаться проведением тщательного и разнообразного контроляправильности внешнего описания. Целью этого процесса является найти как можнобольше ошибок, сделанных на этом этапе. Учитывая, что результатом этого этапаявляется, как правило, еще неформализованный текст, то здесь на первый планвыступают психологические факторы контроля. Можно выделить следующие методыконтроля, применяемые на этом этапе:
· статическийпросмотр,
· смежный контроль,
· пользовательскийконтроль,
· ручная имитация.
Первый метод предполагает внимательноепрочтение текста внешнего описания разработчиком с целью проверка его полноты инепротиворечивости, а также выявления других неточностей и ошибок.
Смежный контроль спецификации качествасверху — это её проверка со стороны разработчика требований к ПС, а смежныйконтроль функциональной спецификации — это её проверка разработчикамитребований к ПС и спецификации качества. Смежный контроль внешнего описанияснизу — это его изучение и проверка разработчиками архитектуры ПС и текстовпрограмм, а также разработчиками документации по применению и разработчикамикомплекта тестов.
Пользовательский контроль внешнего описаниявыражает участие пользователя (заказчика) в принятии решений при разработкевнешнего описания и его контроле. Если разработка требований к ПС велась подуправлением пользователя, то пользовательский контроль внешнего описания, посуществу, означает его смежный контроль сверху. Однако, если представителюпользователя оказывается трудно самостоятельно разобраться во внешнем описании,создается специальная группа разработчиков, выполняющая роль пользователя (ивзаимодействующая с ним) для проведения такого контроля.
Ручная имитация выражает своеобразныйдинамический контроль внешнего описания, точнее говоря, функциональнойспецификации ПС. Для этого необходимо подготовить исходные данные (тесты) и наосновании функциональной спецификации осуществить имитацию поведения (работы)разрабатываемого ПС. При этом эту имитацию осуществляет специально назначенныйразработчик, выполняющий, по существу, роль будущих программ ПС. Разновидностьютакого контроля является имитация за терминалом. В этом случае данные вводятсяв компьютер человеком, играющего роль пользователя, и передаются с помощьюнесложной программы на другой терминал, за которым сидит разработчик,выполняющий роль программ ПС. Полученные результаты передаются через компьютерна первый терминал.
ЛИТЕРАТУРА
37. IanSommerville. SoftwareEngineering.— Addison-Wesley Publishing Company, 1992.
38. Г.Майерс. Надежность программного обеспечения.— М.: Мир, 1980. с. 49-77.
39. Е.А. Жоголев. Введение в технологию программирования(конспект лекций). — М.: «ДИАЛОГ-МГУ», 1994.
40. Criteriafor Evalution of Software. — ISO TC97/SC7 #383.
41. Revisedversion of DP9126 — Criteria for Evalution of Software Quality Characteristics. — ISO TC97/SC7#610. — Part 6.
42. Б. Боэм, Дж.Браун, Х. Каспар и др. Характеристики качества программного обеспечения. — М.: Мир, 1981.
ЗАМОК ДРАКОНА
Все, что вообще может быть сказано, должно быть сказаноясно, а о чем невозможно говорить, о том следует молчать.
Л.ВитгенштейнЛекция 5. МЕТОДЫ СПЕЦИФИКАЦИИСЕМАНТИКИ ФУНКЦИЙОсновные подходы к спецификации семантикифункций. Табличный подход, метод таблиц решений. Алгебраический подход:операционная, денотационная и аксиоматическая семантика.
1. Основные подходы к спецификации семантики функцийДля спецификации семантики функцийиспользуются следующие подходы: табличный, алгебраический и логический (1), атакже графический (5.2).
Табличный подход для определенияфункций хорошо известен еще со средней школы. Он базируется на использованиитаблиц. В программировании эти методы получили развитие в методе таблицрешений.
Алгебраический подход базируется наиспользовании равенств для определения функций. В этом случае для определениянекоторого набора функций строится система равенств вида:
/> L1 = R1,
(1) .…………
Ln<sub/>= Rn.
где Li и Ri, i = 1, ..., n, некоторыевыражения, содержащие предопределенные операции, константы, переменные, откоторых зависят определяемые функции (формальные параметры этих функций), ивхождения самих этих функций. Семантика определяемых функций извлекается врезультате интерпретации этой системы равенств. Эта интерпретация можетпроизводиться по-разному (базироваться на разных системах правил), чтопорождает разные семантики. В настоящее время активно исследуются операционная,денотационная и аксиоматическая семантики.
Третий подход, логический, базируется наиспользовании предикатов — функций, аргументами которых могут быть значенияразличных типов, а результатами которых являются логические значения (ИСТИНА и ЛОЖЬ). В этом случаенабор функций может определяться с помощью системы предикатов. Заметим, чтосистема равенств алгебраического подхода может быть задана с помощью следующейсистемы предикатов:
РАВНО(L1, R1),
(2) ……………….
РАВНО(Ln, Rn),
где предикат РАВНО истинен, если равны значения первогои второго его аргументов. Это говорит о том, что логический подход располагаетбольшими возможностями для определения функций, однако он требует отразработчиков ПС умения пользоваться методами математической логики, что, ксожалению, не для всех коллективов разработчиков оказывается приемлемым. Болееподробно этот подход в нашем курсе лекций мы рассматривать не будем.
Графический подход также известен еще сосредней школы. Но в данном случае речь идет не о задании функции с помощьюграфика, хотя при данном уровне развития компьютерной техники ввод в компьютертаких графиков возможен и они могли бы использоваться (с относительно небольшойточностью) для задания функций. В данном случае речь идет о графическом заданииразличных схем, выражающих сложную функцию через другие функции, связанными скакими-либо компонентами заданной схемы. Графическая схема может определятьситуации, когда для вычисления представляемой ею функции должны применятьсясвязанные с этой схемой более простые функции. Графическая схема можетдостаточно точно и формализовано определять часть семантики функции. Примеромтакой схемы может быть схема переходов состояний конечного автомата, такая, чтов каждом из этих состояний должна выполняться некоторая дополнительная функция,указанная в схеме.
2. Метод таблиц решенийМетод таблиц решений базируется наиспользовании таблиц следующего вида (см. Табл. 1).
Верхняя часть этой таблицы определяетразличные ситуации, в которых требуется выполнять некоторые действия(операции). Каждая строка этой части задаёт ряд значений некоторой указаннойпеременной или некоторого указанного условия в первом поле (столбце) этойстроки. Таким образом, первый столбец этой части представляет собой списокпеременных или условий, от значений которых зависит выбор определяемыхситуаций. В каждом следующем столбце указывается комбинация значений этихпеременных (условий), определяющая конкретную ситуацию. При этом последнийстолбец определяет ситуацию, отличную от предыдущих, т.е. для любых другихкомбинаций значений (будем обозначать их звездочкой *), отличных от первых,определяется одна и та же, (m+1)-ая, ситуация. Впрочем, в некоторых таблицахрешений этот столбец может отсутствовать. Эта часть таблицы решений аналогичнасоответствующей части таблицы, определяющей какую-либо функцию обычным способом- в ней задаются комбинации значений аргументов функции, которым ставится всоответствие значения этой функции.
Табл. 1.Общая схема таблиц решений
Переменные / условия Ситуации (комбинации значений)x1
a1,1
a1,2
...a1,m
*x2
a2,1
a2,2
...a2,m
* .….. .………………………………………….xn
an,1
an,2
...an,m
*S1
u1,1
u1,2
...u1,m
u1,m+1
S2
u2,1
u2,2
...u2,m
u1,m+1
.….. .…………………………………………s1k
uk,1
uk,2
...uk,m
uk,m+1
Действия Комбинации выполняемых действийНижняя часть таблицы решений определяетдействия, которые требуется выполнить в той или иной ситуации, определяемой вверхней части таблицы решений. Она также состоит из нескольких (k) строк,каждая из которых связана с каким-либо одним конкретным действием, указанным впервом поле (столбце) этой строки. В остальных полях (столбцах) этой строки(т.е., для ui j, i = 1, ..., m+1, j = 1, ..., k)указывается, следует ли (ui,j = '+') выполнять этодействие в данной ситуации или не следует (ui,j = '–').Таким образом, первый столбец нижней части этой таблицы представляет собойсписок обозначений действий, которые могут выполняться в той или иной ситуации,определяемой этой таблицей. В каждом следующем столбце этой части указываетсякомбинация действий, которые следует выполнить в ситуации, определяемой в томже столбце верхней части таблицы решений. Для ряда таблиц решений эти действиямогут выполняться в произвольном порядке, но для некоторых таблиц решений этотпорядок может быть предопределен, например, в порядке следованиясоответствующих строк в нижней части этой таблицы.
Табл. 2. Таблицарешений «Светофор у пешеходной дорожки».
Условия Ситуации Состояние светофора T = Tкр
Нет Нет Да * * * * *T = Tжёл
* * * Нет Да * * *T > Tзел
* * * * * Нет Да Да Появление привилегированной машины Нет Да * * * * Нет Да Включить – – – – – – + – Включить – + + – – – – – Включить – – – – + – – – T := 0 – + + – + – + – T := T+1 + – – + – + – + Освобождение пешеходной дорожки – – – + – – – – Пропуск пешеходов + + + – – – – – Пропуск машин – – – – – + + + Действия Комбинации выполняемых действийРассмотрим в качестве примера описаниеработы светофора у пешеходной дорожки. Переключение светофора в нормальныхситуациях должно производиться через фиксированное для каждого цвета числоединиц времени (Tкр — для красного цвета, Tжёл — дляжёлтого, Tзел — для зелёного). У светофора имеется счетчик такихединиц. При переключении светофора в счетчике устанавливается 0. Работасветофора усложняется необходимостью пропускать привилегированные машины (об ихпоявлении на светофор поступает специальный сигнал) с минимальной задержкой, нопри обеспечении безопасности пешеходов. Приведенная на Табл. 2 таблица решенийописывает работу такого светофора и порядок движения у него в каждую единицувремени. Звездочка (*) в этой таблице означает произвольное значениесоответствующего условия.
3. Операционная семантикаВ операционной семантике алгебраическогоподхода к описанию семантики функций рассматривается следующий частный случайсистемы равенств (1):
/> f1(x1,x2, ..., xk) = E1,
f2(x1,x2, ..., xk) = E2,
(3) .........……………
fn(x1, x2,…, xk) = En,
где в левых частях равенств явно указаныопределяемые функции с формальными параметрами, включающими (для простоты)обозначения всех входных данных x1, x2, ..., xk,а правые части представляют собой выражения, содержащие, вообще говоря,вхождения этих функций с аргументами, задаваемыми некоторыми выражениями,зависящими от входных данных x1, x2, ..., xk.
Операционная семантика интерпретирует этиравенства как систему подстановок. Под подстановкой
| s E | | T
выражения (терма) T ввыражение E вместо символа s (в частности, переменной) будем пониматьпереписывание выражения E с заменой каждого вхождения в него символа s навыражение T. Каждое равенств
fi(x1, x2, ..., xk) = Ei
задает в параметрической форме множествоправил подстановок вида
|x1, x2, ..., xkfi(T1, T2, ..., Tk) -> Ei | |T1, T2, ..., Tk
где T1, T2,..., TK — конкретные аргументы (значения или определяющие ихвыражения) данной функции. Это правило допускает замену вхождения левой егочасти в какое-либо выражение на его правую часть.
Интерпретация системы равенств (3) дляполучения значений определяемых функций в рамках операционной семантикипроизводится следующим образом. Пусть задан набор входных данных (аргументов) d1,d2, ..., dk. На первом шаге осуществляется подстановкаэтих данных в левые и правые части равенств с выполнением там, где этовозможно, предопределенных операций и с выписыванием получаемых в результатеэтого равенств. На каждом следующем шаге просматриваются правые частиполученных равенств. Если правая часть является каким-либо значением, то оно иявляется значением функции, указанной в левой части этого равенства. Впротивном случае правая часть является выражением, содержащим вхождениякаких-либо определяемых функций с теми или иными наборами аргументов. Если длятакого вхождения соответствующая функция с данным набором аргументов имеется влевой части какого-либо из полученных равенств, то либо вместо этого вхожденияподставляется значение правой части этого равенства, если оно уже вычислено, свыполнением, где это возможно, предопределённых операций. Либо не производитсяникаких изменений, если значение этой правой части ещё не вычислено. В том жеслучае, если эта функция с данным набором аргументов не является левой частьюникакого из полученных равенств, то формируется (и дописывается к имеющимся)новое равенство. Оно получается из исходного равенства для данной функции сподстановкой в него вместо параметров указанных аргументов этой функции. Этишаги осуществляются до тех пор, пока все определяемые функции не будут иметьвычисленные значения.
В качестве примера операционной семантикирассмотрим определение функции факториала F(n) = n! Она определяетсяследующей системой равенств:
F(0) = 1, F(n) = F(n–1)×n.
Для вычисления значения F(3) осуществляютсяследующие шаги: