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

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

Определить ООП можно и многими другими способами.

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

Компонентное программирование

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

Прототипное программирование

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

§ Вместо механизма описания классов и порождения экземпляров язык предоставляет механизм создания объекта (путём задания набора полей и методов, которые объект должен иметь) и механизм клонирования объектов.

§ Каждый вновь созданный объект является «экземпляром без класса». Каждый объект может стать прототипом -- быть использован для создания нового объекта с помощью операции клонирования. После клонирования новый объект может быть изменён, в частности, дополнен новыми полями и методами.

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

Визуальное программирование -- способ создания программы для ЭВМ путём манипулирования графическими объектами вместо написания её текста.

Необходимо различать:

§ графический язык программирования -- который прежде всего язык программирования (со своим синтаксисом)

§ визуальные средства разработки -- как правило, под ними подразумевают средства проектирования интерфейсов или какую либо CASE-систему для быстрой разработки приложений или SCADA-систему для программирования микроконтроллеров.

Языки визуального программирования могут быть дополнительно классифицированы в зависимости от типа и степени визуального выражения, на следующие типы:

§ языки на основе объектов, когда визуальная среда программирования предоставляет графические или символьные элементы, которыми можно манипулировать интерактивным образом в соответствии с некоторыми правилами;

§ языки, в интегрированной среде разработки которых на этапе проектирования интерфейса применяются формы, с возможностью настройкой их свойств. Примеры: Delphi и C++ Builder фирмы Borland, С#

§ языки схем, основанные на идее «фигур и линий», где фигуры (прямоугольники, овалы и т. п.) рассматриваются как субъекты и соединяются линиями (стрелками, дугами и др.), которые представляют собой отношения. Пример: UML.

Визуально-преобразованные языки являются невизуальными языками с наложенным визуальным представлением (например, среда Visual C++ для языка C++). Естественно-визуальные языки имеют неотъемлемое визуальное выражение, для которого нет очевидного текстового эквивалента (например, графический язык G в среде LabVIEW).

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

Графические, или визуальные, языки программирования

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

§ Дракон-схемы -- графический язык программирования, используется для программирования в ракетно-космической технике («Буран», «Морской старт», «Тополь»). Существует бесплатный Дракон-редактор. Этот язык имеет наиболее строгое теоретическое обоснование.

§ Язык последовательных функциональных схем SFC (Sequential Function Chart) -- графический язык программирования широко используется для программирования промышленных логических контроллеров PLC.

В SFC программа описывается в виде схематической последовательности шагов, объединённых переходами.

§ LD -- язык релейно-контактных схем

§ FBD -- язык Функциональных блоковых диаграмм.

§ Язык CFC (Continuous Flow Chart) -- ещё один высокоуровневый язык графического программирования. CFC -- это дальнейшее развития языка FBD. CFC был специально создан для проектирования систем управления непрерывными технологическими процессами.

§ G, язык, используемый в среде разработки LabVIEW

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

22. Массив и структура массива

Массивы предназначены для объединения множества однотипных переменных. Доступ к переменных массива осуществляется через индекс (номер в массиве). Массив объявляется с помощью оператора Dim.

Dim Array.l( 10 )

Вот так объявляется массив, состоящий из 11 переменных типа Long и имеющий имя Array. У вас может появится вопрос, почему 11 переменных, а не десять как задано в скобках? Дело в том, что нумерация начинается с нуля и поэтому получается что на самом деле в массиве на одну переменную больше чем задано.

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

Dim Array.l(10) ; Создание массива

Array(2)=100 ; Запись в массив

x=Array(2) ; Чтение из массива

Debug x ; Отображаем число из переменной "x" в отладочном окне

В этом примере создаётся массив с именем Array, а затем в переменную с номером 2, записывается число 100. После чего производится чтение из этой же переменной. Результат помещается в переменную с именем Х.

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

Dim Array.l(100)

For i=1 To 100

Array(i)=i

Next i

В этом примере создаётся массив с 101 переменной типа Long, а затем в цикле в этот массив записываются данные, в нашем случае число из переменной i

Выше переведены примеры одномерных массивов, но при необходимости можно использовать многомерный массив. Для этого, при объявлении нужно задать размерность много мерного массива.Например в этом примере создаётся 3-ёх мерный массив

Dim Array.l(10, 4, 8) ; Создание 3-ёх мерного массиваArray(2, 1, 1)=100 ; Запись в массивx=Array(2, 1, 1) ; Чтение из массиваDebug x ; Отображаем число из переменной "x" в отладочном окне

При необходимости, можно изменить размерность массива (количество переменных в массиве) после того как массив был создан. Это выполняется с помощью оператора ReDim.

Dim Array.l(10) ; Создание массива; Здесь находится код программы; Вдруг выяснилось что 11 переменных это мало, надо как минимум 21ReDim Array(20) ; Было 11 переменных в массиве, а стало 21.

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

Structure Proba x.l y.l Text.sEndStructure

Операторы Structure и EndStructure определяют начало и конец структуры. Между ними расположены переменные структуры Первые две переменные имеют тип Long, а последняя, тип String. Структуре присвоено имя Proba которое будет использоваться при её объявлении.

Следующий пример содержит работу со структурой

Structure Proba x.l y.l Text.sEndStructuretest.Proba ; Объявление структуры; Запись в структуруtest\x=10test\y=20test\Text="Строка текста"; Чтение из структуры и отображение данных в отладочном окнеDebug test\xDebug test\yDebug test\Text

В структурах допускаются вызовы других структур и статические (размер которых после объявления нельзя изменить) массивы переменных. Учтите, в структуре индексация массива начинается с нуля и чило элементов равно заданному. Другими словами если задан массив, равный 100, то к нему можно обращаться по индексам 0...99

Structure Proba x.l[100] ; Массив переменных z.POINT ; Объявление системной структуры с именем POINTEndStructuretext.Proba ; Объявление структуры; Запись в структуруFor i= 0 To 99 text\x[i]=iNext itext\z\x=1text\z\y=2; Чтение из структуры и отображение данных в отладочном окнеDebug "Чтение из массива"For i= 0 To 99 Debug text\x[i]Next iDebug ""Debug "Чтение из вложенной структуры POINT"Debug text\z\xDebug text\z\y

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

Structure Proba x.l y.l Text.sEndStructure; Создание массива с прикреплённой к нему структуройDim Array.Proba(2); Запись в структуру массиваArray(1)\x=1Array(1)\y=2Array(1)\Text="Текст"; Чтение из структуры массива и отображение данных в отладочном окнеDebug Array(1)\xDebug Array(1)\yDebug Array(1)\Text

23. Очередь и стек

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

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

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

В данной статье мы не будем трогать очередь с приоритетами, а лишь рассмотрим классическую очередь, т.е. первым пришел, первым ушел (FIFO - first in, first out).

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

Класс Queue находится в пространстве имен System.Collections, поэтому перед тем, как использовать его, желательно подключить это пространство, чтобы в дальнейшем не утруждать себя записями вида System.Collections.Queue:using System.Collections;

Сейчас можно смело работать с очередью. Для работы нам могут понадобиться следующие методы:

Enqueue() - помещает элемент в конец очереди

Dequeue() - достает из очереди первый элемент

В принципе этого вполне достаточно. У класса Queue есть еще несколько полезных методов:

Contains() - проверяет имеется ли данный объект в очереди

Count - свойство, содержащее количество элементов в очереди

Peek() - возвращает первый элемент в очереди, но не удаляет его

Рассмотрим пример: static void Main(string[] args) { Queue q = new Queue(3);

q.Enqueue(3); //помещаем в очередь тройку q.Enqueue(4); //помещаем в очередь четверку q.Enqueue(5); //помещаем в очередь пятерку

//наша очередь выглядит так: 5 4 3

Console.WriteLine("В очереди содержится " + q.Count + " объекта"); //выведет 3

Console.WriteLine("Первый элемент: " + q.Peek()); //выведет 3

Console.WriteLine((int)q.Dequeue() (int)q.Dequeue() - (int)q.Dequeue()); //3+4-5=2 }

Немного пояснений. Сперва мы создаем экземпляр класса Queue. После чего помещаем в очередь 3 элемента. В нашем случае это объекты типа int. Обратите внимание на очередность. Тройка заняла очередь первой, а пятерка последней. Далее мы узнаем, сколько элементов содержится в очереди. Узнаем, кто первый. Ну а далее мы извлекаем элементы из очереди и сразу выполняем простенькие расчеты. Приведение к типу int обязательно, т.к. в очереди хранятся объекты типа object вне зависимости от того, что в очередь было помещено.

Нужно помнить, что невозможно узнать, кто в очереди второй или третий, пока не "достать" из очереди соответствующее количество элементов. Если вам такая функция нужна, то скорее всего придется отказаться от использования класса Queue и реализовывать очередь самому, на основе массива или ArrayList-а (о нем будет рассказано в следующей статье).

Хочу так же обратить ваше внимание на то, что очередь не является типизированной, т.е. в ней могут содержаться объекты разных типов, так что нужно быть внимательными. Т.е. если мы сделаем так: q.Enqueue("строка"); //помещаем в очередь строку q.Enqueue(3); //помещаем в очередь тройку q.Enqueue(4); //помещаем в очередь четверку q.Enqueue(5); //помещаем в очередь пятерку

То наша программа "вылетит" с ошибкой, при попытке приведения типов.

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

Push() - помещает элемент в стек

Pop() - достает элемент из стека

Peek() - возвращает верхний элемент стека

Contains() - проверяет содержится ли элемент в стеке

Count - свойство содержащее количество объектов в очереди

Функции практически аналогичны функциям очереди. Я решил, что работу стека мы изучим на примере следующей задачи:

Пусть у нас имеется арифметическое выражение, поддерживающее 3 вида скобок: (), [], {}. Наша задача - проверить правильность расположения скобок в выражении.

Примеры:

{(5-[3+9])-4} - правильное выражение

{(5-[3+)9]-4} - неверное выражение

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

Приступим к реализации:

static void Main(string[] args) { string str; char c; Stack s = new Stack(); str=Console.ReadLine();

for (int i = 0; i < str.Length; i++) {

if ((str[i] == ?(?) || (str[i] == ?[?) || (str[i] == ?{?)) { //если это открывающая скобка, то s.Push(str[i]); //помещаем скобку в стек } else if ((str[i] == ?)?) || (str[i] == ?]?) || (str[i] == ?}?)) { //если это закрывающая скобка if (s.Count == 0) { //если стек путстой Console.WriteLine("Не хватает скобки"); break; }

c = (char)s.Pop(); //проверяем соответствие форм if (((c == ?{?) && (str[i] == ?}?)) || ((c == ?[?) && (str[i] == ?]?)) || ((c == ?(?) && (str[i] == ?)?))) { continue; } else { Console.WriteLine("Неверный тип скобки"); break; } } else { //если это другой символ continue; } }

if (s.Count > 0) { //в стеке остались скобки Console.WriteLine("Не хватает закрывающей скобки"); } }

Прокомментирую код. Сперва мы создаем 3 переменные: типа string (строка), сhar (символ), Stack (стек). После чего считываем строку с экрана (ее должен ввести пользователь). Далее в цикле for мы пробегаем по всем символам введенной строки. В принципе дальше все идет по алгоритму описанному выше. Повторяться не буду. Скажу лишь, что break прерывает цикл, а continue прерывает текущую итерацию и переходит к следующему шагу цикла. обратите внимание, что в конце стек должен быть пустым. Если он не пустой, значит открывающих скобок больше чем закрывающих.

Отмечу, что представленное выше решение не является оптимальным.

24. Односвязный и двусвязный список.

Односвязный список (Однонаправленный связный список)

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

Двусвязный список (Двунаправленный связный список)

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

25. Реентабельность

Реентабельность - это свойство, котоpое позволяет пpогpамме или какому-то ее фpагменту пpеpываться и выполняться с начала (вновь), Т.е. пpогpамма может пpеpывать сама себя.

26. Ошибка в ПО и надёжность ПО

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

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

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

В общем случае отказ программного обеспечения можно определить как:

· прекращение функционирования программы (искажения нормального хода ее выполнения, зацикливание) на время превышающее заданный порог;

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

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

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

Таблица 1. Категории тяжести ошибки в программном обеспечении, нарушение работоспособности которого не приводят к катастрофическим последствиям

№категории ошибки	Наименование категории тяжести ошибки	Описание последствий проявления ошибки
III	Критическая	проявление ошибки с высокой вероятностью влечет за собой прекращение функционирования программного обеспечения (его отказ)
II	Существенная	проявление ошибки влечет за собой снижение эффективности функционирования программного обеспечения и может вызвать прекращение функционирования программного обеспечения (его отказ)
I	Несущественная	проявление ошибки может повлечь за собой снижение эффективности функционирования программного обеспечения и практически не приводит к возникновению отказа в нем (вероятность возникновения отказа очень низкая)

В качестве показателя степени тяжести ошибки, позволяющего дать количественную оценку тяжести проявления последствий ошибки можно использовать условную вероятность отказа программного обеспечения при проявлении ошибки. Оценку степени тяжести ошибки как условной вероятности возникновения отказа, можно производить согласно ГОСТ 28195 - 89 «Оценка качества программных средств. Общие положения», используя метрики и оценочные элементы, характеризующие устойчивость программного обеспечения. При этом оценку необходимо производить для каждой ошибки в отдельности, а не для всего программного обеспечения.

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

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

Особенностью АСОИУ является также то, что не все отказы ее элементов проявляются явно и могут быть обнаружены визуально, как это происходит, например, при отказах двигателей или генераторов тока. Чтобы обнаружить отказы в АСОИУ, создают специальные средства контроля и диагностирования (СКД). От их характеристик зависит доля своевременно и достоверно обнаруживаемых отказов и, как следствие , уровень надежности и его количественные оценки.»

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

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

Современная теория надежности занимается в основном вопросами надежности техники, за более чем 50-летнюю историю своего развития она накопила большое количество полезных, проверенных на практике результатов. Казалось бы, это может служить залогом успешного и беспроблемного решения задачи обеспечения надежности АСОИУ. Однако это не так. В последние десятилетия проблема повышения надежности не только не ослабела, но, напротив, значительно обострилась. Это связано с действием ряда объективных факторов, обусловленных бурным техническим прогрессом в новой области техники - информатике и вычислительной технике. Одна из причин - непрерывный рост сложности аппаратуры, который значительно опережает рост качества элементной базы, хотя последний, по абсолютным оценкам, тоже настолько велик, что производит большое впечатление при сравнении с некоторыми другими областями техники.

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

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

Ненадежность техники оборачивается большими экономическими потерями. Так, по данным национального симпозиума США по вопросам надежности, стоимость эксплуатации многих систем превышает их покупную стоимость в 1,5-2 раза за один год работы и в 10-12 раз за весь период жизни. Однако это еще не все негативные последствия. Ненадежность вызывает недоверие к технике и, как следствие, снижение ее технической эффективности.

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

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

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

27. Отладка и тестирование

компьютерный программный отладка тестирование

ТЕСТИРОВАНИЕ И ОТЛАДКА ПРОГРАММНОГО СРЕДСТВА

Основные понятия. Стратегия проектирования тестов. Заповеди отладки. Автономная отладка и тестирование программного модуля. Комплексная отладка и тестирование программного средства.

Основные понятия

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

Отладка = Тестирование + Поиск ошибок + Редактирование.

В зарубежной литературе отладку часто понимают [1.1-1.3] только как процесс поиска и исправления ошибок (без тестирования), факт наличия которых устанавливается при тестировании. Иногда тестирование и отладку считают синонимами [1.4,1.5]. В нашей стране в понятие отладки обычно включают и тестирование [1.6 -1.8], поэтому мы будем следовать сложившейся традиции. Впрочем, совместное рассмотрение в данной лекции этих процессов делает указанное разночтение не столь существенным. Следует, однако, отметить, что тестирование используется и как часть процесса аттестации ПС .

Принципы и виды отладки программного средства

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

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



Рис. 1.1. Спектр подходов к проектированию тестов.

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

· на каждую используемую функцию или возможность - хотя бы один тест,

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

· на каждую особую (исключительную) ситуацию, указанную в спецификациях, - хотя бы один тест.

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

Оптимальную стратегию проектирования тестов можно конкретизировать на основании следующего принципа: для каждого программного документа (включая тексты программ), входящего в состав ПС, должны проектироваться свои тесты с целью выявления в нем ошибок. Во всяком случае, этот принцип необходимо соблюдать в соответствии с определением ПС и содержанием понятия технологии программирования как технологии разработки надежных ПС (см. лекцию 1). В связи с этим Майерс даже определяет разные виды тестирования [1.1] в зависимости от вида программного документа, на основании которого строятся тесты. В нашей стране различаются [1.8] два основных вида отладки (включая тестирование): автономную и комплексную отладку ПС. Автономная отладка ПС означает последовательное раздельное тестирование различных частей программ, входящих в ПС, с поиском и исправлением в них фиксируемых при тестировании ошибок. Она фактически включает отладку каждого программного модуля и отладку сопряжения модулей. Комплексная отладка означает тестирование ПС в целом с поиском и исправлением фиксируемых при тестировании ошибок во всех документах (включая тексты программ ПС), относящихся к ПС в целом. К таким документам относятся определение требований к ПС, спецификация качества ПС, функциональная спецификация ПС, описание архитектуры ПС и тексты программ ПС.

Заповеди отладки программного средства

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

Ниже приводятся рекомендации по организации отладки в форме заповедей [1.1, 1.8].

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

Заповедь 2. Хорош тот тест, для которого высока вероятность обнаружить ошибку, а не тот, который демонстрирует правильную работу программы.

Заповедь 3. Готовьте тесты как для правильных, так и для неправильных данных.

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

Заповедь 5. Каждый модуль подключайте к программе только один раз; никогда не изменяйте программу, чтобы облегчить ее тестирование.

Заповедь 6. Пропускайте заново все тесты, связанные с проверкой работы какой-либо программы ПС или ее взаимодействия с другими программами, если в нее были внесены изменения (например, в результате устранения ошибки).

Автономная отладка программного средства

При автономной отладке ПС каждый модуль на самом деле тестируется в некотором программном окружении, кроме случая, когда отлаживаемая программа состоит только из одного модуля. Это окружение состоит [1.8] из других модулей, часть которых является модулями отлаживаемой программы, которые уже отлажены, а часть - модулями, управляющими отладкой (отладочными модулями, см. ниже). Таким образом, при автономной отладке тестируется всегда некоторая программа (тестируемая программа), построенная специально для тестирования отлаживаемого модуля. Эта программа лишь частично совпадает с отлаживаемой программой, кроме случая, когда отлаживается последний модуль отлаживаемой программы. В процессе автономной отладки ПС производится наращивание тестируемой программы отлаженными модулями: при переходе к отладке следующего модуля в его программное окружение добавляется последний отлаженный модуль. Такой процесс наращивания программного окружения отлаженными модулями называется интеграцией программы [1.1]. Отладочные модули, входящие в окружение отлаживаемого модуля, зависят от порядка, в каком отлаживаются модули этой программы, от того, какой модуль отлаживается и, возможно, от того, какой тест будет пропускаться.

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

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

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

К достоинствам восходящего тестирования относятся:

· простота подготовки тестов,

· возможность полной реализации плана тестирования модуля.

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

Недостатками восходящего тестирования являются следующие его особенности:

· тестовые данные готовятся, как правило, не в той форме, которая рассчитана на пользователя (кроме случая, когда отлаживается последний, головной, модуль отлаживаемой программ);

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

· необходимость специального тестирования сопряжения модулей.

К достоинствам нисходящего тестирования относятся следующие его особенности:

· большинство тестов готовится в форме, рассчитанной на пользователя;

· во многих случаях относительно небольшой объем отладочного программирования (имитаторы модулей, как правило, весьма просты и каждый пригоден для большого числа, нередко - для всех, тестов);

· отпадает необходимость тестирования сопряжения модулей.

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

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

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

Часто применяют также комбинацию восходящего и нисходящего тестирования, которую называют методом сандвича [1.1]. Сущность этого метода заключается в одновременном осуществлении как восходящего, так и нисходящего тестирования, пока эти два процесса тестирования не встретятся на каком-либо модуле где-то в середине структуры отлаживаемой программы. Этот метод при разумном порядке тестирования позволяет воспользоваться достоинствами как восходящего, так и нисходящего тестирования, а также в значительной степени нейтрализовать их недостатки.

Весьма важным при автономной отладке является тестирование

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

Автономное тестирование модуля целесообразно осуществлять в четыре последовательно выполняемых шага [1.1].

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

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

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

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

Комплексная отладка программного средства

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

...