Структурное кодирование, критерии качества программных средств

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

Идеи структурного программирования появились в начале 70-годов в компании IBM, в их разработке участвовали известные ученые Э. Дейкстра, Х. Милс, Э. Кнут, С. Хоор.

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

Целью курсовой работы является: изучение структурного кодирования и выделение критериев качества ПС.

В соответствии с поставленной целью при выполнении работы возникают следующие задачи:

Изучение теоретических основ структурного кодирования,

Изучение и анализ методов структурирования программ и программных модулей,

Рассмотрение основных структурных блоков;

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

Рассмотрение факторов качества;

Рассмотрение процесса оценки качества ПС.

При написании работы автор опирался на труды отечественных и зарубежных ученых Ахо А., Ульман Дж., Братчиков И.Л., Гулидов А.И., Наберухин Ю.И., Дейкстра Э., Ершов А.П., Кнут Д., Майерс Г., Мендельсон Э., Рудаков А. В., Тыугу, Э.Х., Хьюз Дж., Мичтом Дж.

Предполагаемая практическая значимость курсовой работы заключается в том, что ее можно будет использовать в качестве источника получения теоретического материала по теме «структурное кодирование» и «контроль качества ПС».

1. Структурное кодирование

1.1 Сущность понятия

Структурное кодирование - это метод кодирования (программирования), предусматривающий создание понятных, простых и удобочитаемых программных модулей и программных комплексов на требуемых языках программирования.

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

1.2 Общая характеристика структурного кодирования

В теории схем программ было замечено, что некоторые случаи блок-схем легче поддаются анализу. Поэтому естественно было выделить такой класс блок-схем, что и сделали итальянские ученые С. Бем и К. Джакопини в 1966 г. Они доказали, что любую блок-схему можно привести к структурированному виду, использовав несколько дополнительных булевых переменных. Э. Дейкстра подчеркнул, что программы в таком виде, как правило, являются легче понимаемыми и модифицируемыми, так как каждый блок имеет один вход и один выход.

В качестве методики структурного программирования Э. Дейкстра предложил пользоваться лишь конструкциями цикла и условного оператора, изгоняя go to как концептуально противоречащее этому стилю.

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

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

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

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

Необходимой чертой хорошей реализации структурного стиля программирования является соблюдение согласованности, а в идеале и единства, следующих компонентов программы:

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

Для структурного стиля программирования требуется следующее. Задача разбивается на подзадачи, и таким образом выстраивается дерево вложенности подзадач. Информационное пространство структурируется в точном соответствии с деревом вложенности: для каждой подзадачи оно состоит из ее локальных объектов, определяемых вместе с подзадачей и для нее, и так называемых глобальных объектов, определяемых как информационное пространство непосредственно объемлющей подзадачи. Таким образом, информационное пространство всей задачи (подзадачи самого верхнего уровня) расширяется по мере перехода к подзадачам за счет их локальных объектов. Для различных дочерних подзадач одной подзадачи оно имеет общую часть - информационное пространство родительской подзадачи.

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

К структурным операторам добавляются либо циклы, либо рекурсии.

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

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

Структуры данных. Данные объединяются в логически связанные фрагменты, соответствующие структурам задачи либо вспомогательных конструкций, вводимых для ее решения.

Призраки. Часто даже сама программа не может быть объяснена через понятия, которые используются внутри нее. Еще чаще это происходит для ее связей с внешним миром. Понимание программы возможно лишь после сопоставления реальных внутрипрограммных объектов с идеальными внепрограммными. Эти идеальные внепрограммные объекты (призраки) часто не просто не нужны, но даже вредны для исполнения программы5) .

Первым обратил внимание на необходимость введения призраков для логического и концептуального анализа программ Г.С. Цейтин в 1971 г. В Америке это "независимо" открыли заново в 1979 г., хотя упомянутая статья Цейтина была опубликована на английском языке в общедоступном издании. Даже название сущностям было дано то же самое... Этому важнейшему и традиционно игнорируемому понятию посвящена отдельная лекция в курсе "Основания программирования".

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

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

Для структурного программирования весьма важно требование:

Все структуры подчиняются структуре информационного пространства.

Это общее требование конкретизируется в следующие.

Необходимо, чтобы структура управления программы была согласована со структурой ее информационного пространства. Каждой структуре управления соответствуют согласующиеся с ней структуры данных и часть информационного пространства. Это условие позволяет человеку легко отслеживать порядок выполнения конструкций в программе.

Подзадачи могут обмениваться данными только посредством обращения к объектам из общей части их информационных пространств (в современных языках чаще всего к глобальным).

Информационные потоки должны протекать согласно иерархии структур управления; мы должны четко видеть для каждого блока программы, что он имеет на входе и что дает на выходе. Таким образом, свойства каждого логически завершенного фрагмента программы должны ясно осознаваться и в идеале четко описываться в самом тексте программы и в сопровождающей ее документации6) .

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

Все призраки действуют на своем структурном месте и соответствуют идеальным сущностям, которые, согласно парадоксу изобретателя, должны вводиться для эффективного решения задачи.

Все подпорки строго локализованы в том месте, где их вынуждены ввести. Желательно даже обозначать их по-другому, чем идеальные сущности, например, оставляя мнемонические имена лишь для идеальных сущностей, а подпорки именовать джокерами типа x или i. Необходимо строго следить за тем, чтобы подпорки не искажали идеальную структуру программы.

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

1.3 Основные структуры

Структурное программирование - методология разработки программного обеспечения, в основе которой лежит представление программы в виде иерархической структуры блоков. Предложена в 70-х годах XX века Э. Дейкстрой, разработана и дополнена Н. Виртом.

В соответствии с данной методологией

Любая программа представляет собой структуру, построенную из трёх типов базовых конструкций:

последовательное исполнение - однократное выполнение операций в том порядке, в котором они записаны в тексте программы;

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

цикл - многократное исполнение одной и той же операции до тех пор, пока выполняется некоторое заданное условие (условие продолжения цикла).

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

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

Разработка программы ведётся пошагово, методом «сверху вниз».

Сначала пишется текст основной программы, в котором, вместо каждого связного логического фрагмента текста, вставляется вызов подпрограммы, которая будет выполнять этот фрагмент. Вместо настоящих, работающих подпрограмм, в программу вставляются «заглушки», которые ничего не делают. Полученная программа проверяется и отлаживается. После того, как программист убедится, что подпрограммы вызываются в правильной последовательности (то есть общая структура программы верна), подпрограммы-заглушки последовательно заменяются на реально работающие, причём разработка каждой подпрограммы ведётся тем же методом, что и основной программы. Разработка заканчивается тогда, когда не останется ни одной «затычки», которая не была бы удалена. Такая последовательность гарантирует, что на каждом этапе разработки программист одновременно имеет дело с обозримым и понятным ему множеством фрагментов, и может быть уверен, что общая структура всех более высоких уровней программы верна. При сопровождении и внесении изменений в программу выясняется, в какие именно процедуры нужно внести изменения, и они вносятся, не затрагивая части программы, непосредственно не связанные с ними. Это позволяет гарантировать, что при внесении изменений и исправлении ошибок не выйдет из строя какая-то часть программы, находящаяся в данный момент вне зоны внимания программиста.

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

На рисунке 1.1 изображена сеть с тремя типами узлов.

Рисунок 1.1 - Сеть с тремя типами узлов

Тип узла (а) называется процедурным, (б) - альтернативы и (в) - слияния. Дуги, соединяющие узлы сети, являются ориентированными, т.е. имеющими направление, указываемое имеющейся на них стрелкой.

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

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

Рисунок 1.2 - Элементарные блок-схемы

Композиция (а): <Процедура 1>

<Процедура 2>

Ветвление (б): если <условие>

<Процедура 1>

иначе

<Процедура 2>

Цикл I (в):пока <условие> делать

<Процедура>

Цикл II (г): делать

<Процедура>

пока <условие>

Эта совокупность структур управления является достаточной для построения любого алгоритма, но не всегда удобной. Поэтому, на практике используются и другие элементарные блок-схемы с обязательным свойством "один вход и один выход". Например, вариант блок-схемы ветвления, где

<Процедура 2> пуста: если <условие> <Процедура>

Но для нашего рассмотрения это не важно. Важно то, что любая <Процедура> любой элементарной структуры управления является либо базовым исполнителем, описание которого изначально определено, либо представима опять-таки элементарной структурой управления из их фиксированного набора, включающего 4 перечисленных типа. При этом структуру композиции не требуется "организовывать": она образуется при естественном (сверху вниз и слева направо) следовании инструкций программы.

2. Критерии качества ПС

2.1 Качество программного обеспечения

Качество программного обеспечения - характеристика программного обеспечения (ПО) как степени его соответствия требованиям. При этом требования могут трактоваться довольно широко, что порождает целый ряд независимых определений понятия. Чаще всего используется определение ISO 9001, согласно которому качество есть «степень соответствия присущих характеристик требованиям».

Качество кода может определяться различными критериями. Некоторые из них имеют значение только с точки зрения человека. Например, то, как отформатирован текст программы, совершенно не важно для компьютера, но может иметь серьёзное значение для последующего сопровождения. Многие из имеющихся стандартов оформления кода, определяющих специфичные для используемого языка соглашения и задающие ряд правил, улучшающих читаемость кода, имеют своей целью облегчить будущее сопровождение ПО, включающее отладку и обновление. Существуют и другие критерии, определяющие, «хорошо» ли написан код, например, такие, как структурированность - степень логического разбиения кода на ряд управляемых блоков.

Читаемость кода

Лёгкость поддержки, тестирования, отладки, исправления ошибок, изменения и портируемости

Низкая сложность кода

Низкое использование ресурсов: памяти и процессорного времени

Корректная обработка исключительных ситуаций

Малое число предупреждений при компиляции и линковке

Методы улучшения качества кода: рефакторинг.

2.2 Факторы качества

Фактор качества ПО - это нефункциональное требование к программе, которое обычно не описывается в договоре с заказчиком, но, тем не менее, является желательным требованием, повышающим качество программы.

Некоторые из факторов качества - таблица 2.1.

Таблица 2.1 - Факторы качества ПС

2.3 Показатели качества ПО в ГОСТ 28195 и ГОСТ Р ИСО/МЭК 9126

Показатели качества ПО устанавливают ГОСТ 28195 Оценка качества программных средств. Общие положения и ГОСТ Р ИСО/МЭК 9126 Информационная технология. Оценка программной продукции. Характеристика качества и руководства по их применению. Одновременное существование двух действующих стандартов, нормирующих одни и те же показатели, ставит вопрос об их гармонизации. Ниже кратко рассмотрим каждый из перечисленных стандартов.

ГОСТ Р ИСО/МЭК 9126 устанавливает шесть характеристик качества ПО. Под характеристикой качества ПО, согласно этому стандарту, понимается набор свойств (атрибутов) программной продукции, по которым ее качество оценивается или описывается. Определение качества и определенные в этом стандарте характеристики отражают представление пользователя о качестве ПО. Ниже приводятся существенное для оценки качества ПО обсуждение этих характеристик.

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

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

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

2. Надежность. Специфика ПО заключается в том, что оно не подвержено старению и износу, а отказы проявляются из-за ошибок в требованиях, проекте, реализации.

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

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

Практичность - набор атрибутов, относящихся к объему работ, требуемых для исполнения и индивидуальной оценки такого исполнения определенным или предполагаемым кругом пользователей.

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

Эффективность - набор атрибутов, относящихся к соотношению между уровнем качества функционирования ПО и объемом используемых ресурсов при установленных условиях.

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

Сопровождаемость - набор атрибутов, относящихся к объему работ, требуемых для проведения конкретных изменений (модификаций).

Мобильность - набор атрибутов, относящихся к способности ПО быть перенесенным из одного окружения в другое.

Все приведенные характеристики являются наборами атрибутов и, следовательно, должны уточняться на множестве соответствующих подхарактеристик. ГОСТ Р ИСО/МЭК 9126 не устанавливает соответствующих показателей, но в рекомендуемом приложении А к этому стандарту дается пример (качественная модель) таких подхарактеристик, называемых комплексными показателями. В качестве примера приведем комплексные показатели для некоторых характеристик.

2.4 Комплексные показатели для характеристик

Характеристика «Функциональные возможности»:

1. Пригодность - атрибут ПО, относящийся к наличию и соответствию набора функций конкретным задачам.

2. Правильность - атрибуты ПО, относящиеся к обеспечению правильности или соответствия результатов или эффектов.

3. Способность к взаимодействию - атрибуты ПО, относящиеся к способности его взаимодействовать с конкретными системами.

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

5. Защищенность - атрибуты ПО, относящиеся к его способности предотвращать несанкционированный доступ, случайный или преднамеренный, к программам и данным.

Характеристика «Эффективность»:

1. Характер изменения во времени - атрибуты ПО, относящиеся к временам отклика и обработки и к скорости выполнения его функций.

2. Характер изменения ресурсов - атрибуты ПО, относящиеся к объему используемых ресурсов и продолжительности такого использования при выполнении функций.

Приведенные комплексные показатели в свою очередь формируются на основе показателей нижележащего уровня. ГОСТ Р ИСО/МЭК 9126 не устанавливает этих показателей, так как современное состояние соответствующих моделей, терминов, определений не позволяет включить их в рассматриваемый международный стандарт.

В СССР действовал и продолжает действовать в РФ ГОСТ 28195-89. Этот стандарт устанавливает четырехуровневую модель оценки качества ПС. Характеристики верхних двух уровней (называемые фактор и критерий) устанавливаются в основном тексте документа. В таблице 2.1. показаны факторы и критерии качества ПО согласно ГОСТ 28195.

Таблица 2.2 - Факторы и критерии качества ПО согласно ГОСТ 28195

2.5 Основные критерии

кодирование программный обеспечение качество

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

В процессе оценки качества ПО на каждом уровне (кроме уровня оценочных элементов) проводятся вычисления показателей качества ПО, т.е. определение количественных значений абсолютных показателей (Pij, где j - порядковый номер показателя для i - го показателя вышестоящего уровня) и относительных показателей (Kij), являющихся функцией показателя Pij, и базового значения Pijбаз.

Критерий и метрика характеризуется двумя числовыми параметрами - количественным значением и весовыми коэффициентами (Vij). Сумма весовых коэффициентов показателей уровня (l) относящихся к i-му показателю вышестоящего уровня (l-1), есть величина постоянная. Сумма весовых коэффициентов (Vij) принимается равной 1.

Общая оценка качества ПО в целом формируется экспертами по набору полученных значений оценок факторов качества. Для оценки качества ПО различного назначения методом экспертного опроса составляется таблица базовых показателей качества ПО.

При сопоставление характеристик стандартов ГОСТ Р ИСО/МЭК 9126 и ГОСТ 28195 следует учесть несоответствие используемой терминологии. Например, подхарактеристика 1.4 ГОСТ Р ИСО/МЭК 9126 называется также, как критерий 6.2 ГОСТ 28195 - согласованность. Однако в первом документе имеется в виду согласованность ПО со стандартами и другими нормативными документами, а во втором - однозначное, непротиворечивое описание и использование тождественных объектов, функций, терминов, определений, идентификаторов и т.д. в различных частях программных документов и текста программы. Точное сопоставление характеристик и подхарактеристик первого из обсуждаемых стандартов с факторами и критериями второго оказывается, как правило, невозможным.

Таким образом, на сегодняшний день действуют два нормативных документа по оценке качества ПО - ГОСТ 28195 и ГОСТ Р ИСО/МЭК 9126. Первый содержит рекомендуемый (и возможно - неполный) перечень метрик, однако ориентирован на представление разработчика. Второй - более соответствует взглядам пользователя, но для его применения требуется разработка модели качества ПС, включающая метрики и методы оценивания и ранжирования с указанием применимости на стадиях ЖЦ продукта.

Заключение