inżynieria oprogramowani18 KVG3PAZXXDXPPXZLMECNOODDW6EXTVFCPSK3G3I


Inżynieria oprogramowania - 18 Slide 1

Wytwarzanie systemów krytycznych

. Techniki programowania

stosowane przy budowaniu

krytycznych systemów

oprogramowania

Inżynieria oprogramowania - 18 Slide 2

Niezawodność oprogramowania

. Ogólnie, klienci oczekują, że oprogramowanie

będzie niezawodne. Jednakże w przypadku

aplikacji niekrytycznych klienci są zmuszeni do

zaakceptowania pewnych usterek

oprogramowania

. Niektóre aplikacje posiadają bardzo wysokie

wymagania jeśli chodzi o niezawodność, dlatego

też aby ją osiągnąć trzeba zastosować specjalne

metody programowania

Inżynieria oprogramowania - 18 Slide 3

Osiąganie niezawodności

. Unikanie usterek

. Oprogramowanie tworzone jest w taki sposób aby uniknąć

błędów człowieka, a co za tym idzie zminimalizować ryzyko

wystąpienia usterek w systemie

. Proces tworzenia zorganizowany jest w taki sposób, że usterki

oprogramowania wykrywane są i usuwane zanim

oprogramowanie zostanie dostarczone do klienta

. Tolerowanie usterek

. Oprogramowanie projektowane jest w taki sposób ażeby błędy

oprogramowania nie powodowały uszkodzenia systemu

Inżynieria oprogramowania - 18 Slide 4

Minimalizacja liczby usterek

. Obecne metody inżynierii oprogramowania umożliwiają

produkcję oprogramowania bezusterkowego

. Oprogramowanie bezusterkowe oznacza

oprogramowanie które dokładnie odpowiada swojej

specyfikacji. NIE oznacza to jednak, że oprogramowanie

zawsze działa poprawnie ponieważ błędy mogły

wystąpić na etapie specyfikacji

. Koszt produkcji oprogramowanie bezusterkowego jest

bardzo wysoki dlatego też tworzy się je tylko w

wyjątkowych sytuacjach.

Inżynieria oprogramowania - 18 Slide 5

Koszty usuwania usterek

Cost

per error

deleted

Few

Number of residual errors

Many Very

few

Koszt

usunięcia

jednego błędu

Liczba powstałych błędów

bardzo

mało

wiele mało

Inżynieria oprogramowania - 18 Slide 6

Tworzenie oprogramowanie

bezusterkowego

. Wymaga precyzyjnej (najlepiej formalnej) specyfikacji

. Wymaga organizacyjnego podejścia do utrzymania jakości w

procesie wytwarzania oprogramowania

. Istotą projektowania oprogramowania jest ukrywanie informacji i

enkapsulacja

. Należy wykorzystywać języki programowania z dobrze

zdefiniowanymi typami danych, umożliwiające kontrolę w

trakcie wykonywania

. Konstrukcje podatne na błędy nie powinny być stosowane

. Niezawodny i powtarzalny proces tworzenia

Inżynieria oprogramowania - 18 Slide 7

Programowanie strukturalne

. Pierwszy raz omawiane w latach siedemdziesiątych

. Programowanie bez instrukcji skoku (.goto.)

. Jedynymi strukturami sterującymi są pętle .while.

i instrukcje warunkowe .if.

. Projektowanie z góry w dół (top-down)

. Ważne ponieważ zainicjowało dyskusje na temat

programowania

. Prowadzi do powstawania programów łatwiejszych

do czytania i zrozumienia

Inżynieria oprogramowania - 18 Slide 8

Konstrukcje podatne na błędy

. Liczby zmiennoprzecinkowe

. Z natury niedokładne. Niedokładność może prowadzić do błędnych

porównań.

. Wskaźniki

. Wskaźniki odnoszące się do nieprawidłowych obszarów pamięci mogą

zniszczyć dane. Czynią program trudniejszym do zrozumienia a co za

tym idzie trudniejszym do edycji

. Dynamiczny przydział pamięci

. Przydzielanie pamięci programu w czasie jego wykonywania może być

powodem jej wyczerpania

. Równoległość

. Może prowadzić do subtelnych błędów czasowych z powodu

nieprzewidzianych zależności pomiędzy procesami współbieżnymi

Inżynieria oprogramowania - 18 Slide 9

Konstrukcje podatne na błędy

. Rekurencja

. Błędy w rekurencji mogą być powodem przepełnienia pamięci

. Przerwania

. Przerwania mogą być powodem wstrzymania wykonywania operacji

krytycznej i czynią program trudnym do zrozumienia. Są one

porównywalne z instrukcjami goto

. Dziedziczenie

. Kod związany z danym obiektem nie jest zlokalizowany w jednym

miejscu. Może to prowadzić do nieoczekiwanych zachowań i

problemów ze zrozumieniem

. Konstrukcje te nie muszą być unikane lecz powinny

być stosowane ze szczególna ostrożnością

Inżynieria oprogramowania - 18 Slide 10

Ukrywanie informacji

. Informacja powinna być eksponowana tylko dla tych części

programu, które potrzebują dostępu do danych informacji. Dotyczy

to tworzenia obiektów lub abstrakcyjnych typów danych które

posiadają stan i operacje

. Ukrywanie informacji pozwala uniknąć usterek z trzech powodów:

. prawdopodobieństwa przypadkowego zniszczenia informacji

. informacje są otoczone przez .ściany ogniowe. tak więc istnieje mniejsze

prawdopodobieństwo rozprzestrzenienia się problemu na inne części programu

. gdy informacje są zlokalizowane w jednym miejscu, istnieje mniejsze

prawdopodobieństwo, że programista popełni błąd i większe że recenzent odnajdzie

ten błąd

Inżynieria oprogramowania - 18 Slide 11

Procesy tworzenia niezawodnego

oprogramowania

. W celu zapewnienia minimalnej liczby usterek

oprogramowania należy zastosować dobrze

zdefiniowany, powtarzalny proces tworzenia

. Dobrze zdefiniowany powtarzalny proces nie zależy

od indywidualnych umiejętności ludzi

. W celu minimalizacji liczby usterek, proces powinien

obejmować weryfikację i zatwierdzanie

Inżynieria oprogramowania - 18 Slide 12

Czynności zatwierdzania

. Kontrola (inspekcja) wymagań

. Zarządzanie wymaganiami

. Weryfikacja modeli

. Kontrole projektu i kodu

. Analiza statyczna

. Planowanie i zarządzanie testowaniem

. Istotne jest również zarządzanie konfiguracją

Inżynieria oprogramowania - 18 Slide 13

Tolerowanie usterek

. W sytuacjach krytycznych, systemy oprogramowania

muszą tolerować usterki. Tolerancja usterek wymagana

jest tam gdzie istnieje wysoka dostępność wymagań lub

gdzie koszt awarii systemu może być bardzo wysoki

. Tolerowanie usterek oznacza, że system może

kontynuować swoje działanie pomimo usterek

oprogramowania

. Nawet jeśli system wydaje się być bezusterkowy, musi

również tolerować usterki ponieważ mogły wystąpić

błędy w fazie specyfikacji lub też zatwierdzanie mogło

być nieprawidłowe

Inżynieria oprogramowania - 18 Slide 14

Aspekty tolerowania usterek

. Wykrywanie usterek

. System musi wykryć, że usterka (nieprawidłowy stan systemu)

ma miejsce

. Ocena szkód

. Należy wykryć części systemu, na które awaria miała wpływ

. Odtwarzanie po usterkach

. System musi odtworzyć jakiś znany stan uznawany za

.bezpieczny.

. Naprawa usterek

. System musi być zmodyfikowany tak aby zapobiec powtórzeniu

się usterki. W wielu przypadkach usterki oprogramowania są

chwilowe, tak więc często nie trzeba nic naprawiać

Inżynieria oprogramowania - 18 Slide 15

Podejścia do tolerowania usterek

. Programowanie defensywne

. Programiści zakładają, że istnieją błędy w kodzie systemu i

dodają nadmiarowy kod, który ma sprawdzać stan systemu po

modyfikacjach i zapewniać, że zmiana stanu jest spójna

. Architektury tolerujące usterki

. Architektury systemów oprogramowania i sprzętu, które

zapewniają nadmiarowość sprzętową i programową oraz

realizują tolerowanie usterek. Zawierają sterownik tolerowania

usterek, który wykrywa problemy i wspomaga odtwarzanie po

usterkach

Inżynieria oprogramowania - 18 Slide 16

Obsługa wyjątków

. Wyjątek to błąd lub jakieś nieoczekiwane

zdarzenie jak np. awaria zasilania

. Konstrukcje obsługujące wyjątki pozwalają na

obsługę takich zdarzeń bez potrzeby

dodatkowych instrukcji sprawdzających wyjątki

. Wykorzystanie normalnych konstrukcji

sterujących do wykrywania wyjątków w

sekwencji zagnieżdżonych wywołań funkcji

wymaga dodania wielu dodatkowych instrukcji i

wprowadza znaczną nadmiarowość czasową

Inżynieria oprogramowania - 18 Slide 17

Programowanie z wyjątkami

. Wyjątki mogą być wykorzystywane jako

normalna technika programistyczna a nie tylko

jako sposób na odtwarzanie stanu systemu w

wyniku awarii

Inżynieria oprogramowania - 18 Slide 18

. Pewność systemu można osiągnąć poprzez

unikanie usterek i tolerowanie usterek

. Niektóre konstrukcje języków programowania

takie jak .goto., rekurencje czy wskaźniki są z

natury źródłem błęw

. Stosowanie dobrze zdefiniowanych typów danych

pozwala w wielu wypadkach na wykrywanie

potencjalnych usterek już w fazie kompilacji

Główne tezy



Wyszukiwarka

Podobne podstrony:
Inzynieria oprogramowania w ujeciu obiektowym UML wzorce projektowe i Java iowuje
ZadanieNaZaliczenie, WAT, semestr IV, Inżynieria oprogramowania
Rafał Polak 12k2 lab8, Inżynieria Oprogramowania - Informatyka, Semestr III, Systemy Operacyjne, Spr
zagadnienia egzaminacyjne z przedmiotu inżynieria oprogramowania zIO
Inżynieria oprogramowania Diagramy ERD
2006 06 Wstęp do Scrum [Inzynieria Oprogramowania]
sciąga moja, Informatyka SGGW, Semestr 4, Inżynieria oprogramowania, Od starszego rocznika
Tworzenie oprogramowania, Semestr 5, Inżynieria oprogramowania
2007 05 Mechanizm koncepcji w języku C nowe oblicze szablonów [Inzynieria Oprogramowania]
Inżynieria oprogramowania syllabus IV niestac 07 08, Prywatne, WAT, SEMESTR IV, IO, io, Materiały od
Rafał Polak 12k2 lab9, Inżynieria Oprogramowania - Informatyka, Semestr III, Systemy Operacyjne, Spr
inżynieria oprogramowani5s 3D2LFW6JYNMO6D276CSZQV5ONUNVXOTKWFXHA3A
inżynieria oprogramowani1 2EM7Y2ON72DKTCAQF3UOSCLXHY5636FZE7C7PUQ
inżynieria oprogramowani5 G46UQE27RE6UDINZWBW2TXNEOUUYOYV2MMVZ2NI
2008 06 Java Microedition – metody integracji aplikacji [Inzynieria Oprogramowania]
Inżynieria oprogramowania II
Opracowanie na Inżynierie Oprogramowania
Przykład diagramu sekwencji, Inżynieria oprogramowania
Inżynieria oprogramowania, Studia, Informatyka, Informatyka, Informatyka

więcej podobnych podstron