Разработка на критични системи
DESCRIPTION
Разработка на критични системи. Цели. Да обясни как възстановяването след грешки и избягването им допринася за разработката на надеждни с-ми. Да опише характеристиките на надежден софтуерен процес. Да направи въведение в техниките за избягване на грешки. - PowerPoint PPT PresentationTRANSCRIPT
Software Engineering, 7th edition. Chapter 20 Slide 1
Разработка на критични системи
Software Engineering, 7th edition. Chapter 20 Slide 2
Цели
Да обясни как възстановяването след грешки и избягването им допринася за разработката на надеждни с-ми.
Да опише характеристиките на надежден софтуерен процес.
Да направи въведение в техниките за избягване на грешки.
Да опише механизмите за възстановяване след грешки и използването за това на разнообразие и излишък.
Software Engineering, 7th edition. Chapter 20 Slide 3
Теми
Надежден процес Надеждно програмиране Нечувствителност към грешки Архитектури за възстановяване
Software Engineering, 7th edition. Chapter 20 Slide 4
Надеждност на софтуера
Като цяло, клиентите очакват целият софтуер да бъде надежден. Но за некритични приложения, те може да приемат и някои грешки.
Някои приложения имат много високи изисквания по отношение на надеждност и трябва да се използват специални софтуерни техники, за да се постигнат.
Software Engineering, 7th edition. Chapter 20 Slide 5
Достигане на надеждност
Избягване на грешки• С-мата е разработена по такъв начин, че се избягват
човешки грешки и по този начин се минимизират грешките в с-мата
• Процесът на разработка е така организиран, че грешките в системата се откриват и поправят преди доставката на клиента.
Откриване на грешките• Използват се техники за верификация и валидиране,
за да се открият и премахнат грешките преди предаването на с-мата
Нечувствителност към грешки• С-мат е проектирана така, че софтуерна грешка да не
води до срив на с-мата.
Software Engineering, 7th edition. Chapter 20 Slide 6
Разнообразие и излишък
ИзлишъкПази се повече от 1 версия на компонента така, че ако тя
се скапе да има на разположение последната работеща версия
РазнообразиеЕдна и съща функционалност се осъществява по
различни начини, така че да не се сринат по един същ начин или в един и същ момент
Но, добавянето на разнообразие и излишък увеличава сложността и с това увеличава вероятността за грешки.
Някои инженери препоръчват простота и екстензивен V & V като по ефективен път за постигане на надеждност.
Software Engineering, 7th edition. Chapter 20 Slide 7
Примери за разнообразие и излишък
Излишък. Където е критична достъпността (напр. в с-ми за електронна търговия), компаниите обикновено поддържат бекъп сървъри и при срив превключват автоматично на тях.
Разнообразие. Могат да се реализират различни сървъри, които използват различни операционни с-ми (напр. Windows и Linux), за да бъде с-мата устойчива срещу външни атаки.
Software Engineering, 7th edition. Chapter 20 Slide 8
Софтуер без грешки
Съвременните методи на софтуерното инженерство позволяват производството на с-ми без грешки, като това важи най-малко за относително малки с-ми.
Софтуер без грешки означава, че софтуерът отговаря на спецификациите си. това не означава, че софтуерът винаги работи правилно, защото може да има грешки в спецификациите.
Разходите за производство на такъв софтуер са много високи. Това е изгодно само в изключителни ситуации. Често е по-евтино да се приемат грешки и да се плати за техните последствия.
Software Engineering, 7th edition. Chapter 20 Slide 9
Разработка на софтуер без грешки
Надежден софтуерен процес Управление на качеството. Формални спецификации Статична верификация Силно типизиране Strong typing Безопасно програмиране Защитена информация (капсулиране)
Software Engineering, 7th edition. Chapter 20 Slide 10
Разходи за отстраняване на грешките
FewNumber of residual errors
Many Very few
Software Engineering, 7th edition. Chapter 20 Slide 11
Надеждни процеси
С цел да се осигури минимален брой грешки, е важно да имаме добре дефиниран, повторяем софтуерен процес.
Добре дефинираният повторяем процес е този, който не зависи изцяло от индивидуалните способности; а може да бъде изпълнен от различни хора.
Ясно е, че процесът трябва да изисква значителни усилия за V&V за откриване на грешките.
Software Engineering, 7th edition. Chapter 20 Slide 12
Характеристики на надеждния процес
Да може да се документира
Процесът трябва да има дефиниран модел, който задава дейностите в процеса и документацията, която трябва да се напише по време на тези дейности
Стандартизиран Трябва да има разбираемо множество от стандарти, които дефинират, как трябва да се произвежда софтуера и документацията.
Проверяем Процесът трябва да е разбираем от външни на процеса хора, които могат да проверяват дали се следват стандартите и да правят предложения за подобряване на процеса..
Разнообразен Процесът трябва да включва разнообразни и с излишък дейности по V&V.
Робаст Процесът трябва да е способен да се възстановява при несполуки в отделните дейности
Software Engineering, 7th edition. Chapter 20 Slide 13
Дейности по избягване и нечувствителност към грешки
Инспекция на изискванията Управление на изискванията Проверка на модела Инспекция на проекта и на кода Статичен анализ Планиране и управление на тестовете Управление на конфигурацията.
Software Engineering, 7th edition. Chapter 20 Slide 14
Надеждно програмиране
Да се използват програмни конструкции и техники, които допринасят за избягването на грешки и нечувствителност към такива.• Проектиране на прости решения• Защита на информацията от неправомерен
достъп.• Минимизиране на използването на опасни
програмни структури
Software Engineering, 7th edition. Chapter 20 Slide 15
Защита на информацията
Информацията трябва да е достъпна само за тези части от програмата, които имат нужда от нея. Това предизвиква създаването на обекти или абстрактни типове от данни, които поддържат състояние и имат операции в/у това състояние.
Това води до избягване на грешки по 3 причини:• намалява се вероятността от случайна повреда на
информацията;• информацията е оградена от "защитни стени" което
намалява вероятността от разпространение на проблемите;• тъй като информацията е локализирана, по-малко е
вероятно разработчикът да направи грешки и е по-вероятно проверяващият да ги открие.
Software Engineering, 7th edition. Chapter 20 Slide 16
Спецификация на опашка в Java
Software Engineering, 7th edition. Chapter 20 Slide 17
Декларация на Signal в Java
Software Engineering, 7th edition. Chapter 20 Slide 18
Безопасно програмиране
Дефектите в програмите са обикновено последица от грешки на програмиста.
Тези грешки възникват, защото хората често не могат да проследят връзките м/у променливите в програмата.
Някои програмни структури са по-предразположени към грешки от останалите, така че избягването им намалява грешките при програмирането.
Software Engineering, 7th edition. Chapter 20 Slide 19
Структурно програмиране
За първи път предложено през 1968 като подход, който прави програмите по-лесни за разбиране, с което се избягват програмните грешки.
Програмиране без goto Цикъла While и операторът If са единствените
управляващи структури. Проектиране отгоре-надолу Важна стъпка, която накара хората да се
замислят и да дискутират въпросите на програмирането.
Software Engineering, 7th edition. Chapter 20 Slide 20
Структури предразположени към грешки
Числа с плаваща запетаяНеточността им е присъща. Може да доведе до
неправилни сравнения. Указатели
Указатели, които сочат към неправилно място в паметта могат да повредят данните. Използването на псевдоними може да направи програмите трудни за разбиране и промяна.
Динамично заемане на паметЗаемането на памет по време на изпълнение може да
предизвика препълване на паметта. Паралелизъм
Може да предизвика коварни грешки поради недовидяно взаимодействие м/у паралелните процеси.
РекурсияГрешките тук могат да доведат до препълване на паметта.
Software Engineering, 7th edition. Chapter 20 Slide 21
Структури предразположени към грешки
ПрекъсванияТе могат да причинят прекъсването на критични операции и
правят програмата трудно разбираема. Наследяване
Кодът не е локализиран. Това може да доведе до неочаквано поведение, когато се правят промени и създава проблеми на разбирането.
Използване на псевдонимиИзползването на повече от 1 име за един и същ обект.
Масиви без границиАко не се прави проверка на границите на масива, може
да се получи препълване на буфер. Обработка на входа по подразбиране
Действие на въвеждане на данни, което се извършва независимо от входа на програмата.
Software Engineering, 7th edition. Chapter 20 Slide 22
Обработка на изключенията Програмното изключение е грешка или
неочаквано събитие като прекъсване на захранването.
Обработката на прекъсванията позволява такива събития да бъдат обработени без да се налага непрекъсната проверка на състоянието, за да се открие изключението.
Използването на нормални управляващи структури за откриване на изключението изисква много допълнителни оператори, което води до претрупване и е потенциално предразположено към грешки.
Software Engineering, 7th edition. Chapter 20 Slide 23
Изключения в Java 1
Software Engineering, 7th edition. Chapter 20 Slide 24
Изключения в Java 2
Software Engineering, 7th edition. Chapter 20 Slide 25
Термостат
Изключенията могат да се използват като нормална програмна техника, а не само като начин постигане на нечувствителност към грешки.
Пример. Термостат на фризер, който поддържа температурата в даден интервал.
Включва и изключва компресора на фризера. Включва аларма, ако се надмине максимално
разрешената температура. Използва изключенията като нормална техника
за програмиране.
Software Engineering, 7th edition. Chapter 20 Slide 26
Термостат 1
Software Engineering, 7th edition. Chapter 20 Slide 27
Термостат 2
Software Engineering, 7th edition. Chapter 20 Slide 28
Нечувствителност към грешки Софтуерните с-ми трябва да могат да се
възстановяват в критични ситуации. Нечувствителността към грешки е нужно когато
има изискване за достъпност или когато срив нас-мата има висока цена.
Нечувствителност към грешки означава, че с-мата може да продължи да работи въпреки появяването на грешка.
Дори когато за с-мата е било доказано, че отговаря на спецификацията си, тя трябва да е нечувствителна към грешки, защото може да има неточности в спецификацията или процесът на валидиране да е бил неправилен.
Software Engineering, 7th edition. Chapter 20 Slide 29
Действия за постигане на нечувствителност
Откриване на грешкатаС-мата трябва да открие, че настъпила грешка
(неправилно състояние). Оценка на вредите
Трябва да се определят частите от системното състояние, засегнати от грешката.
ВъзстановяванеС-мата трябва да се възстанови до познато безопасно
състояние. Поправка на грешката
С-мата трябва да се промени, за да се предотврати ново появяване на грешката. Тъй като много софтуерни грешки са мимолетни, това често не е необходимо.
Software Engineering, 7th edition. Chapter 20 Slide 30
Откриване на грешката и оценка на вредите
Първият етап е да се определи, че се проявила или ще се прояви грешка ( грешно състояние на с-мата).
Откриването на грешка включва дефинирането на ограничения, на които трябва да отговарят всички допустими състояния и да се проверява състоянието за удовлетворяване на тези ограничения.
Software Engineering, 7th edition. Chapter 20 Slide 31
Ограничения за инсулинова помпа
Software Engineering, 7th edition. Chapter 20 Slide 32
Откриване на грешката
Превантивно откриванеМеханизмът за откриване на грешката се
включва преди да се извърши промяна на състоянието. Ако се открие грешно състояние, промяната не се извършва.
Ретроспективно откриванеМеханизмът за откриване на грешката се
включва след промяната на състоянието. То се използва, когато неправилна последователност от правилни действия води до грешно състояние или когато превантивното откриване е твърде е ресурсоемко.
Software Engineering, 7th edition. Chapter 20 Slide 33
Превантивното откриване на грешки в действителност разширява с-мата от типове, като до се добавят допълнителни ограничения като част от дефиницията на типа.
Тези ограничения се реализират чрез дефиниране на базови операции в дефиницията на класа.
Разширение на с-мата от типове
Software Engineering, 7th edition. Chapter 20 Slide 34
PositiveEvenInteger 1
Software Engineering, 7th edition. Chapter 20 Slide 35
PositiveEvenInteger 2
Software Engineering, 7th edition. Chapter 20 Slide 36
Оценка на вредите
Анализира се системното с-яние, за да се прецени степента на увреждане предизвикано от срива на с-мата
Оценката трябва да провери, кои части от пространството на с-янието е било засегнато.
Обикновено се основава на "функции на валидност", които могат да се приложат за елементите на с-янието, за да оценят дали стойностите им са в зададен интервал.
Software Engineering, 7th edition. Chapter 20 Slide 37
Robust array 1
Software Engineering, 7th edition. Chapter 20 Slide 38
Robust array 2
Software Engineering, 7th edition. Chapter 20 Slide 39
При пренасяне на данни се използват контролни суми.
За проверка на интегритета на структурите от данни се използват допълнителни указатели.
За незавършващи процеси се използват наблюдаващи (Watch dog) таймери. Ако известно време няма отговор, се предполага, че има проблем.
Техники за оценка на вредата
Software Engineering, 7th edition. Chapter 20 Slide 40
Възстановяване напредПрилага поправките към повреденото състояние
Възстановяване назадВъзстановява с-мното с-яние към познато безопасно с-
яние Възстановяването напред е обикновено
специфично за приложението – изисква се познание на областта, за да се изчислят възможни корекции на с-янието.
Възстановяването назад е по=просто.Поддържат се подробност за безопасните с-яния и с някое от тях се замества повреденото състояние.
Възстановяване от грешка и поправяне
Software Engineering, 7th edition. Chapter 20 Slide 41
Повреда на кодирани данни• Кодиращи техники, които добавят излишък, могат да
се използват при поправяне на данни повредени по време на пренос.
Допълнителни указатели• Когато се използват допълнителни указатели в
структурите данни (напр. дву-свързан списък), то повреденият списък или файлова с-ма може да се изгради наново, ако има достатъчен брой неповредени указатели.
• Често се използват при баси от данни и файлови с-ми.
Възстановяване напред
Software Engineering, 7th edition. Chapter 20 Slide 42
Транзакциите са често използван метод. Промените не се прилагат докато не завърши изчислението. Ако се настъпи грешка, с-мата се оставя в с-янието преди транзакцията.
Периодични контролни точки позволяват с-мата да се върне в "добро" с-яние.
Възстановяване назад
Software Engineering, 7th edition. Chapter 20 Slide 43
Безопасна процедура за сортировка
Операция за сортиране, която следи собственото си изпълнение и оценява, дали сортировката е била коректно изпълнена.
Тя поддържа копие на входните данни и ако възникне грешка последните не са повредени.
Основава се на идентифициране и обработка на изключения
Тя е възможна в този случай, защото се знае условието за 'правилна' сортировка. Но в много случаи е трудно да се напишат проверки за правилност.
Software Engineering, 7th edition. Chapter 20 Slide 44
Safe sort 1
Software Engineering, 7th edition. Chapter 20 Slide 45
Safe sort 2
Software Engineering, 7th edition. Chapter 20 Slide 46
Архитектура, нечувствителна към грешки
Защитното програмиране не може да се справя със с-ми, включващи взаимодействие м/у софтуера и хардуера
Неразбирането на изискванията може да доведе до това, че проверките и свързания с код са некоректни.
Когато с-мите имат силни изисквания за достъпност, може да се изисква специфична архитектура, проектирана да бъде нечувствителна към грешките.
Това важи из хардуера и софтуера.
Software Engineering, 7th edition. Chapter 20 Slide 47
Нечувствителност нас хардуера
Използва се троен излишък на модулите (TMR). Иам3 идентични компоненти, които получават
един и същ вход и изходите им се сравняват Ако един изход е различен, той се отхвърля и се
приема срив на компонентата. Основава се на това, че повечето грешки са
причинени от сривове в компонентите, не от проектни грешки и вероятността за едновременен срив на 2 компоненти е много ниска.
Software Engineering, 7th edition. Chapter 20 Slide 48
Надеждност на хардуер с TMR
A2
A1
A3
Outputcomparator
Software Engineering, 7th edition. Chapter 20 Slide 49
Избор на изхода
У-вото за сравняване на изходите е сравнително просто.
То сравнява входните (за него) сигнали и ако един е различен, го отхвърля. Изборът на истинския изход се решава от болшинството еднакви сигнали.
У-вот е свързано с управлението на грешките, което може да се опита да поправи грешащото у-во или да го изключи от с-мата.
Software Engineering, 7th edition. Chapter 20 Slide 50
Софтуерни архитектури, нечувствителни към грешки
Успехът TMR се базира на 2 предположения:• Хардуерните компоненти нямат общи проектни
грешки;• Компонентите дефектират случайно и вероятността
за едновременна грешка е много ниска. Никое от тези предположения не е вярно за
софтуера:• Не е възможно де се копира компонентата, тъй като
тя може да има проектни грешки• Следователно едновременния отказ на компонентите
е напълно възможен и неизбежен. Следователно софтуерните с-ми трябва да са
разнообразни (с различни компоненти).
Software Engineering, 7th edition. Chapter 20 Slide 51
Проектиране на разнообразието
Проектират се различни версии на с-мата и се осъществяват по различни начини. Следователно има различен моменти на отказ.
Различни проектни подходи (напр. обектно-ориентиран и функционален)• Осъществяване на различни програмни езици;• Използване на различни средства и програмни среди;• Използване на различни алгоритми
Software Engineering, 7th edition. Chapter 20 Slide 52
Софтуерни аналогии на TMR
N-версии• Различни екипи осъществяват няколко версии по една
и съща спецификация. Всички версии работят едновременно и изходът се избира с болшинство.
• Това е на използвания подход, напр. в много от моделите на Airbus.
Блокове за възстановяване• Няколко явно различни версии на една и съща
спецификация са написват и изпълняват последователно.
• Използва се тест за приемливост, за да се избере валидния изход.
Software Engineering, 7th edition. Chapter 20 Slide 53
N-версии
Version 2
Version 1
Version 3
Outputcomparator
N-versions
Agreedresult
Faultmanager
Input
Software Engineering, 7th edition. Chapter 20 Slide 54
Сравнение на изходите
Както при хардуерните с-ми, модулът за сравнение е прост и използва същия механизъм за избор на изхода.
В с-мите с реално време трябва да има изискване, че всички версии изработват резултат в определен времеви интервал.
Software Engineering, 7th edition. Chapter 20 Slide 55
N-версии
Различните версии се проектират и разработват от различни екипи. Предполага се, че вероятността да допуснат едни и същи грешки е малка. Алгоритмите би трябвало, но не задължително, да са различни
Има емпирични данни, че екипите по-един същ начин схващат погрешно спецификациите и избират един и същ алгоритъм в техните с-ми.
Software Engineering, 7th edition. Chapter 20 Slide 56
Блокове за възстановяване
Acceptancetest
Algorithm 2
Algorithm 1
Algorithm 3
Recovery blocks
Test forsuccess
Re-testRetry
Re-test
Try algorithm1
Continue execution ifacceptance test succeedsSignal exception if allalgorithms fail
Acceptance testfails – retry
Software Engineering, 7th edition. Chapter 20 Slide 57
Блокове за възстановяване
Тук е задължително да се използва различен алгоритъм за всяка версия, така че се намалява вероятността за общи грешки.
Но проектирането на теста за приемане е труден и трябва да е независим от използваните изчисления.
Този подход има проблеми в с-мите с реално време поради последователното изпълнение на допълнителните версии.
Software Engineering, 7th edition. Chapter 20 Slide 58
Проблеми с проектирането на разнообразие
Културата на екипите е подобна, затова те общо взето подхождат към проблемите по един и същи начин.
Характерни грешки• Различните екипи правят същите грешки. Някои части
от осъществяването са по-трудни и затова е по-вероятно екипите там да допуснат грешка.
• Грешки в спецификацията:• Ако има грешки в спецификацията, тя се отразява във
всички версии.• Това може да се избегне в известна степен, като се
използват различни представяния на спецификацията.
Software Engineering, 7th edition. Chapter 20 Slide 59
Надеждност на спецификацията
И двата подхода са податливи на грешките в спецификацията. Ако спецификацията е грешна, то и с-мата ще е грешна.
Това също е и хардуерен проблем, но софтуерните спецификации са по-сложни и по трудни за валидиране.
Това може да се избегне в някои случаи, като от една потребителска спецификация се разработят няколко системни такива.
Software Engineering, 7th edition. Chapter 20 Slide 60
Надеждността на една с-ма може да бъде постигната чрез избягване на грешките, откриване на грешките и нечувствителност към грешките.
Използването на излишък и разнообразие е съществено за разработката на надеждни с-ми
Използването на добре дефиниран повторяем процес е важно за минимизирането на грешките в с-мата.
Някои програмни конструкции са предразположени към грешки – те трябва да се избягват, където е възможно.
Обобщение
Software Engineering, 7th edition. Chapter 20 Slide 61
Обобщение
В надеждните с-ми се използват изключения за поддръжка на управлението на грешките.
Четирите аспекта на нечувствителността към грешки са откриване на отказ, оценка на вредите, възстановяване и поправка.
N-версиите и блоковете за възстановяване са алтернативни подходи за нечувствителните към грешки архитектури.