Download
1 / 61
620 likes | 780 Views
Разработка на критични системи. Цели. Да обясни как възстановяването след грешки и избягването им допринася за разработката на надеждни с-ми. Да опише характеристиките на надежден софтуерен процес. Да направи въведение в техниките за избягване на грешки.
E N D
Цели • Да обясни как възстановяването след грешки и избягването им допринася за разработката на надеждни с-ми. • Да опише характеристиките на надежден софтуерен процес. • Да направи въведение в техниките за избягване на грешки. • Да опише механизмите за възстановяване след грешки и използването за това на разнообразие и излишък.
Теми • Надежден процес • Надеждно програмиране • Нечувствителност към грешки • Архитектури за възстановяване
Надеждност на софтуера • Като цяло, клиентите очакват целият софтуер да бъде надежден. Но за некритични приложения, те може да приемат и някои грешки. • Някои приложения имат много високи изисквания по отношение на надеждност и трябва да се използват специални софтуерни техники, за да се постигнат.
Достигане на надеждност • Избягване на грешки • С-мата е разработена по такъв начин, че се избягват човешки грешки и по този начин се минимизират грешките в с-мата • Процесът на разработка е така организиран, че грешките в системата се откриват и поправят преди доставката на клиента. • Откриване на грешките • Използват се техники за верификация и валидиране, за да се открият и премахнат грешките преди предаването на с-мата • Нечувствителност към грешки • С-мат е проектирана така, че софтуерна грешка да не води до срив на с-мата.
Разнообразие и излишък • Излишък Пази се повече от 1 версия на компонента така, че ако тя се скапе да има на разположение последната работеща версия • Разнообразие Една и съща функционалност се осъществява по различни начини, така че да не се сринат по един същ начин или в един и същ момент • Но, добавянето на разнообразие и излишък увеличава сложността и с това увеличава вероятността за грешки. • Някои инженери препоръчват простота и екстензивен V & V като по ефективен път за постигане на надеждност.
Примери за разнообразие и излишък • Излишък.Където е критична достъпността (напр. в с-ми за електронна търговия), компаниите обикновено поддържат бекъп сървъри и при срив превключват автоматично на тях. • Разнообразие.Могат да се реализират различни сървъри, които използват различни операционни с-ми (напр. Windows и Linux), за да бъде с-мата устойчива срещу външни атаки.
Софтуер без грешки • Съвременните методи на софтуерното инженерство позволяват производството на с-ми без грешки, като това важи най-малко за относително малки с-ми. • Софтуер без грешки означава, че софтуерът отговаря на спецификациите си. това не означава, че софтуерът винаги работи правилно, защото може да има грешки в спецификациите. • Разходите за производство на такъв софтуер са много високи. Това е изгодно само в изключителни ситуации. Често е по-евтино да се приемат грешки и да се плати за техните последствия.
Разработка на софтуер без грешки • Надежден софтуерен процес • Управление на качеството. • Формални спецификации • Статична верификация • Силно типизиране • Strong typing • Безопасно програмиране • Защитена информация (капсулиране)
Разходи за отстраняване на грешките a
Надеждни процеси • С цел да се осигури минимален брой грешки, е важно да имаме добре дефиниран, повторяем софтуерен процес. • Добре дефинираният повторяем процес е този, който не зависи изцяло от индивидуалните способности; а може да бъде изпълнен от различни хора. • Ясно е, че процесът трябва да изисква значителни усилия за V&V за откриване на грешките.
Характеристики на надеждния процес
Дейности по избягване и нечувствителност към грешки • Инспекция на изискванията • Управление на изискванията • Проверка на модела • Инспекция на проекта и на кода • Статичен анализ • Планиране и управление на тестовете • Управление на конфигурацията.
Надеждно програмиране • Да се използват програмни конструкции и техники, които допринасят за избягването на грешки и нечувствителност към такива. • Проектиране на прости решения • Защита на информацията от неправомерен достъп. • Минимизиране на използването на опасни програмни структури
Защита на информацията • Информацията трябва да е достъпна само за тези части от програмата, които имат нужда от нея. Това предизвиква създаването на обекти или абстрактни типове от данни, които поддържат състояние и имат операции в/у това състояние. • Това води до избягване на грешки по 3 причини: • намалява се вероятността от случайна повреда на информацията; • информацията е оградена от "защитни стени" което намалява вероятността от разпространение на проблемите; • тъй като информацията е локализирана, по-малко е вероятно разработчикът да направи грешки и е по-вероятно проверяващият да ги открие.
Безопасно програмиране • Дефектите в програмите са обикновено последица от грешки на програмиста. • Тези грешки възникват, защото хората често не могат да проследят връзките м/у променливите в програмата. • Някои програмни структури са по-предразположени към грешки от останалите, така че избягването им намалява грешките при програмирането.
Структурно програмиране • За първи път предложено през 1968 като подход, който прави програмите по-лесни за разбиране, с което се избягват програмните грешки. • Програмиране без goto • Цикъла Whileи операторът If са единствените управляващи структури. • Проектиране отгоре-надолу • Важна стъпка, която накара хората да се замислят и да дискутират въпросите на програмирането.
Структури предразположени към грешки • Числа с плаваща запетая Неточността им е присъща. Може да доведе до неправилни сравнения. • Указатели Указатели, които сочат към неправилно място в паметта могат да повредят данните. Използването на псевдоними може да направи програмите трудни за разбиране и промяна. • Динамично заемане на памет Заемането на памет по време на изпълнение може да предизвика препълване на паметта. • Паралелизъм Може да предизвика коварни грешки поради недовидяно взаимодействие м/у паралелните процеси. • Рекурсия Грешките тук могат да доведат до препълване на паметта.
Структури предразположени към грешки • Прекъсвания Те могат да причинят прекъсването на критични операции и правят програмата трудно разбираема. • Наследяване Кодът не е локализиран. Това може да доведе до неочаквано поведение, когато се правят промени и създава проблеми на разбирането. • Използване на псевдоними Използването на повече от 1 име за един и същ обект. • Масиви без граници Ако не се прави проверка на границите на масива, може да се получи препълване на буфер. • Обработка на входа по подразбиране Действие на въвеждане на данни, което се извършва независимо от входа на програмата.
Обработка на изключенията • Програмното изключение е грешка или неочаквано събитие като прекъсване на захранването. • Обработката на прекъсванията позволява такива събития да бъдат обработени без да се налага непрекъсната проверка на състоянието, за да се открие изключението. • Използването на нормални управляващи структури за откриване на изключението изисква много допълнителни оператори, което води до претрупване и е потенциално предразположено към грешки.
Термостат • Изключенията могат да се използват като нормална програмна техника, а не само като начин постигане на нечувствителност към грешки. • Пример. Термостат на фризер, който поддържа температурата в даден интервал. • Включва и изключва компресора на фризера. • Включва аларма, ако се надмине максимално разрешената температура. • Използва изключенията като нормална техника за програмиране.
Нечувствителност към грешки • Софтуерните с-ми трябва да могат да се възстановяват в критични ситуации. • Нечувствителността към грешки е нужно когато има изискване за достъпност или когато срив нас-мата има висока цена. • Нечувствителност към грешки означава, че с-мата може да продължи да работи въпреки появяването на грешка. • Дори когато за с-мата е било доказано, че отговаря на спецификацията си, тя трябва да е нечувствителна към грешки, защото може да има неточности в спецификацията или процесът на валидиране да е бил неправилен.
Действия за постигане на нечувствителност • Откриване на грешката С-мата трябва да открие, че настъпила грешка (неправилно състояние). • Оценка на вредите Трябва да се определят частите от системното състояние, засегнати от грешката. • Възстановяване С-мата трябва да се възстанови до познато безопасно състояние. • Поправка на грешката С-мата трябва да се промени, за да се предотврати ново появяване на грешката. Тъй като много софтуерни грешки са мимолетни, това често не е необходимо.
Откриване на грешката и оценка на вредите • Първият етап е да се определи, че се проявила или ще се прояви грешка ( грешно състояние на с-мата). • Откриването на грешка включва дефинирането на ограничения, на които трябва да отговарят всички допустими състояния и да се проверява състоянието за удовлетворяване на тези ограничения.
Откриване на грешката • Превантивно откриване Механизмът за откриване на грешката се включва преди да се извърши промяна на състоянието. Ако се открие грешно състояние, промяната не се извършва. • Ретроспективно откриване Механизмът за откриване на грешката се включва след промяната на състоянието. То се използва, когато неправилна последователност от правилни действия води до грешно състояние или когато превантивното откриване е твърде е ресурсоемко.
Разширение на с-мата от типове • Превантивното откриване на грешки в действителност разширява с-мата от типове, като до се добавят допълнителни ограничения като част от дефиницията на типа. • Тези ограничения се реализират чрез дефиниране на базови операции в дефиницията на класа.
Оценка на вредите • Анализира се системното с-яние, за да се прецени степента на увреждане предизвикано от срива на с-мата • Оценката трябва да провери, кои части от пространството на с-янието е било засегнато. • Обикновено се основава на "функции на валидност", които могат да се приложат за елементите на с-янието, за да оценят дали стойностите им са в зададен интервал.
Техники за оценка на вредата • При пренасяне на данни се използват контролни суми. • За проверка на интегритета на структурите от данни се използват допълнителни указатели. • За незавършващи процеси се използват наблюдаващи (Watch dog) таймери. Ако известно време няма отговор, се предполага, че има проблем.
Възстановяване от грешка и поправяне • Възстановяване напред Прилага поправките към повреденото състояние • Възстановяване назад Възстановява с-мното с-яние към познато безопасно с-яние • Възстановяването напред е обикновено специфично за приложението – изисква се познание на областта, за да се изчислят възможни корекции на с-янието. • Възстановяването назад е по=просто.Поддържат се подробност за безопасните с-яния и с някое от тях се замества повреденото състояние.
Възстановяване напред • Повреда на кодирани данни • Кодиращи техники, които добавят излишък, могат да се използват при поправяне на данни повредени по време на пренос. • Допълнителни указатели • Когато се използват допълнителни указатели в структурите данни (напр. дву-свързан списък), то повреденият списък или файлова с-ма може да се изгради наново, ако има достатъчен брой неповредени указатели. • Често се използват при баси от данни и файлови с-ми.
Възстановяване назад • Транзакциите са често използван метод. Промените не се прилагат докато не завърши изчислението. Ако се настъпи грешка, с-мата се оставя в с-янието преди транзакцията. • Периодични контролни точки позволяват с-мата да се върне в "добро" с-яние.
Безопасна процедура за сортировка • Операция за сортиране, която следи собственото си изпълнение и оценява, дали сортировката е била коректно изпълнена. • Тя поддържа копие на входните данни и ако възникне грешка последните не са повредени. • Основава се на идентифициране и обработка на изключения • Тя е възможна в този случай, защото се знае условието за 'правилна' сортировка. Но в много случаи е трудно да се напишат проверки за правилност.
Архитектура, нечувствителна към грешки • Защитното програмиране не може да се справя със с-ми, включващи взаимодействие м/у софтуера и хардуера • Неразбирането на изискванията може да доведе до това, че проверките и свързания с код са некоректни. • Когато с-мите имат силни изисквания за достъпност, може да се изисква специфична архитектура, проектирана да бъде нечувствителна към грешките. • Това важи из хардуера и софтуера.
Нечувствителност нас хардуера • Използва се троен излишък на модулите (TMR). • Иам3 идентични компоненти, които получават един и същ вход и изходите им се сравняват • Ако един изход е различен, той се отхвърля и се приема срив на компонентата. • Основава се на това, че повечето грешки са причинени от сривове в компонентите, не от проектни грешки и вероятността за едновременен срив на 2 компоненти е много ниска.
Избор на изхода • У-вото за сравняване на изходите е сравнително просто. • То сравнява входните (за него) сигнали и ако един е различен, го отхвърля. Изборът на истинския изход се решава от болшинството еднакви сигнали. • У-вот е свързано с управлението на грешките, което може да се опита да поправи грешащото у-во или да го изключи от с-мата.
Софтуерни архитектури, нечувствителни към грешки • Успехът TMR се базира на 2 предположения: • Хардуерните компоненти нямат общи проектни грешки; • Компонентите дефектират случайно и вероятността за едновременна грешка е много ниска. • Никое от тези предположения не е вярно за софтуера: • Не е възможно де се копира компонентата, тъй като тя може да има проектни грешки • Следователно едновременния отказ на компонентите е напълно възможен и неизбежен. • Следователно софтуерните с-ми трябва да са разнообразни (с различни компоненти).
