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

Скачать доклад: 12. Проектирование программного обеспечения

Проектирование программного обеспечения: понятие корректности, эталона и сложности программ; программные ошибки (24.1.).

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

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

Для установления корректности программ необходимы  2эталоны 0, которым они соответствуют, а также  2методы проверки  0соответствия программ эталонам и методы оценки степени корректности.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В сложных ПС используется три отличающихся типа модулей: - управляющие программы организации вычислительного процесса, расположенные на высших уровнях; они почти не выполняют вычислений, имеют на входе небольшое число преимущественно логических переменных и выдают управляющие воздействия на вызовы функциональных модулей (объем обычно невелик и составляет около 100 операторов на ассемблере); - основные функциональные программы - на средних уровнях; наиболее сложные для разработки (эти модули имеют в среднем 200..300 операторов ассемблера или около 50 операторов на языке высокого уровня, общее число глобальных переменных составляет в среднем около 20 на каждый модуль); - стандартные программы для вычисления различных функций на нижних уровнях; наиболее просты при разработке; предназначены для вычисления стандартных функций и решения типовых простейших задач (имеют обычно простую структуру без циклов, объем - в пределах 30..100 операторов на ассемблере, число переменных как на входе, так и на выходе, составляет 3..5, а число маршрутов исполнения программы не превышает 10).

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

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

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

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

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

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

Структура программных групп ., входящих в ПС реального времени, может быть отнесена к одному из двух видов. Первый вид структур близок к бинарному дереву, состоящему из 10..15 иерархических уровней; число модулей на каждом уровне увеличивается по мере снижения уровня, однако медленнее, чем в регулярном бинарном дереве. Структуры второго вида содержат один или несколько модулей, вызывающих последовательно большое число (5..10) модулей более низкого уровня.

Характеристики взаимодействия между модулями значительно различаются в зависимости от их расположения в структуре.

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

Функциональные программные модули  0характеризуются широким разнообразием характеристик взаимодействия. Число переменных, считываемых из памяти для обработки модулем, в среднем больше, чем число глобальных переменных.

Стандартные программные модули  0относительно редко вызывают другие программы (обычно такие программы только возвращают управление вызывающим программам).

Типичные ошибки в программных комплексах. . Статистические характеристики ошибок могут служить ориентиром для разработчиков при определении усилий на создание ПС. Характеристики ошибок в процессе проектирования ПС помогают: оценивать реальное состояние проекта и планировать трудоемкость и длительность до его завершения; рассчитывать необходимую эффективность средств оперативной защиты от невыявленных первичных ошибок; оценивать требующиеся ресурсы ЭВМ по памяти и производительности с учетом затрат на устранение ошибок; проводить исследования и осуществлять адекватный выбор показателей сложности компонент и ПС, а также некоторых других показателей качества.

Технологические ошибки  .документации и фиксирования программ в памяти ЭВМ составляют 5..10 % от общего числа ошибок, обнаруживаемых при отладке. Большинство их выявляется автоматически формализованными методами.

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

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

Алгоритмические ошибки  .значительно труднее поддаются обнаружению методами формализованного автоматического контроля. К ним следует отнести прежде всего ошибки, обусловленные некорректной постановкой функциональных задач, когда в спецификациях не полностью оговорены все условия, необходимые для получения правильного результата. Ошибки, обусловленные неполным учетом всех условий решения задач, являются наиболее частыми в этой группе и составляют до 70 % всех алгоритмических ошибок и около 30 % общего количества ошибок на начальных этапах проектирования.

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

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

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

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

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

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

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