Inżynieria oprogramowania

Implementacja systemu

Slajd 2 z 22

Plan wykładu

• Ułatwienia implementacji
• Niezawodność oprogramowania
• Określenie niezawodności oprogramowania

Oszacowanie i podnoszenie niezawodności

• Techniki z natury niebezpieczne
• Zasada ograniczonego dostępu
• Mocna kontrola typów
• Charakterystyka środowisk

Slajd 3 z 22

Ułatwienia implementacji

Implementacja ulega znacznej automatyzacji wynikającej

ze stosowania:

• Języków wysokiego poziomu
• Gotowych elementów
• Narzędzi szybkiego wytwarzania aplikacji - RAD (ang. Rapid

Application Development)

• Generatorów kodu - są to najczęściej składowe narzędzi CASE,

które na podstawie opisu projektu automatycznie tworzą kod
programu; zwykle jest to szkielet programu, który następnie jest
uzupełniany przez programistów; typowe elementy kodu:

– skrypty tworzące relacje w bazie danych
– definicje struktur danych
– nagłówki procedur i funkcji
– definicje klas
– nagłówki metod

Slajd 4 z 22

Niezawodność

oprogramowania

Slajd 5 z 22

Niezawodność oprogramowania

Znaczenie niezawodności:

• Rosnące oczekiwania klientów

wynikające m.in. z coraz większej

powszechności wykorzystania oprogramowania oraz z wysokiej
niezawodności sprzętu; w kwestiach niezawodności
oprogramowanie znacznie ustępuje sprzętowi (być może wynika to
z mniejszej powtarzalności oraz dużej złożoności oprogramowania)

• Potencjalnie

duże koszty błędnych wykonań

(wysokie straty

finansowe wynikające z błędnego działania funkcji
oprogramowania, nawet zagrożenie dla życia)

• Nieprzewidywalność

efektów

oraz

trudność usunięcia błędów

w oprogramowaniu

• Często pojawia się konieczność

znalezienia kompromisu

pomiędzy efektywnością i niezawodnością

; teoretycznie łatwiej

jest jednak pokonać problemy zbyt małej efektywności niż zbyt
małej niezawodności.

Slajd 6 z 22

Niezawodność oprogramowania

Zwiększanie

niezawodności

Unikanie

błędów

Wykrywanie i usuwanie

błędów

Tolerowanie

błędów

Slajd 7 z 22

Określenie niezawodności

oprogramowania

Slajd 8 z 22

Określenie niezawodności

oprogramowania

Obserwacja liczby błędów podczas testów

statystycznych pozwala określać stopień
niezawodności oprogramowania

Miary niezawodności oprogramowania:

•

Prawdopodobieństwo błędnego wykonania

Prawdopodobieństwo błędnego wykonania

podczas

podczas

realizacji

realizacji

transakcji

transakcji (w niektórych systemach każde

błędne wykonanie powoduje zerwanie całej operacji;
miarą jest częstość występowania operacji, które nie
powiodły się wskutek błędów)

•

Częstotliwość występowania błędnych wykonań

Częstotliwość występowania błędnych wykonań (ilość
błędów w jednostce czasu; np. 0.1/h oznacza, że w ciągu

10 godzin

ilość spodziewanych błędnych wykonań

wyniesie

1

; miara stosowana w przypadku systemów, które

nie mają charakteru transakcyjnego.

Slajd 9 z 22

Określenie niezawodności

oprogramowania

•

Średni czas między błędnymi wykonaniami

Średni czas między błędnymi wykonaniami
(odwrotność poprzedniej miary)

•

Dostępność

Dostępność (prawdopodobieństwo, że w danej
chwili system będzie dostępny do użytkowania;
miarę tę można oszacować na podstawie

stosunku czasu, w którym system jest dostępny,
do czasu od wystąpienia błędu do powrotu do
normalnej sytuacji

; miara zależy nie tylko od

błędnych wykonań, ale także od szybkości
powrotu do normalnego działania)

Slajd 10 z 22

Oszacowanie i podnoszenie

niezawodności

Slajd 11 z 22

Oszacowanie i podnoszenie

niezawodności

Czasami (ale rzadko)

poziom niezawodności

(wartość pewnej

miary lub miar) jest określany

w wymaganiach klienta

Zwykle, jest on jednak wyrażony

w terminach jakościowych

,

co utrudnia obiektywną weryfikację

Informacja o niezawodności

jest przydatna również wtedy,

gdy klient nie określił jej jednoznacznie w
wymaganiach:

• częstotliwość występowania błędnych wykonań ma

podstawowy wpływ na koszt konserwacji

(znajomość

niezawodności pozwala oszacować m.in. liczbę personelu,
zgłoszeń tel. , ... dając łączny koszt serwisu)

• pozwala ocenić i poprawić proces wytwarzania

pod kątem

zminimalizowania łącznego kosztu

funkcjonowania firmy

Slajd 12 z 22

Oszacowanie i podnoszenie

niezawodności

Jeżeli podczas usuwania wykrytych błędów

nie wprowadza się nowych błędów,

to mamy

wzrost niezawodności

Szybszy wzrost niezawodności

można

osiągnąć jeżeli dane testowe są dobierane

nie

w pełni losowo

, lecz w kolejnych przebiegach

testuje się sytuacje, które dotąd nie były
testowane

Slajd 13 z 22

Unikanie błędów

Można przyjąć, że stworzenie bardziej złożonego systemu,

który nie zawiera błędów, jest praktycznie
niemożliwe

; trzeba natomiast starać się zmniejszać

prawdopodobieństwo wystąpienia błędu dzięki:

• unikaniu niebezpiecznych technik

(np. programowanie oparte na

wskaźnikach)

• stosowaniu

zasady ograniczonego dostępu

(reguły zakresu,

hermetyzacja, ...)

• językom z mocną kontrolą typów

i kompilatorom sprawdzających

zgodność typów

• dokładnemu i konsekwentnemu

specyfikowaniu interfejsów

pomiędzy modułami oprogramowania

• zwróceniu szczególnej uwagi na sytuacje skrajne

(puste zbiory,

pętle z graniczną ilością obiegów, wartości zerowe, niezainicjowane
zmienne, ...)

• wykorzystaniu

gotowych komponentów

(np. gotowych bibliotek

procedur lub klas) z zastosowaniem zasady ograniczonego zaufania

• minimalizawaniu

różnic pomiędzy modelem pojęciowym i

modelem implementacyjnym

• ...

Slajd 14 z 22

Właściwy styl programowania

(“złote myśli”)

• Używaj znaczących oraz unikaj podobnych nazw zmiennych
• Nie używaj tych samych zmiennych do różnych celów
• Dla jednoznaczności używaj nawiasów
• Pisz tylko jedną instrukcję kodu w wierszu i używaj wcięć
• Ucz się i używaj prostych cech języka
• Ucz się i wykorzystuj dostępne funkcje biblioteczne i

standardowe

• Dopóki program nie jest poprawny nie myśl o jego efektywności
• Nie poświęcaj czytelności kodu dla (często pozornych) zysków w

efektywności

• Unikaj trików językowych
• Nigdy nie ulepszaj programu jeśli nie musisz
• Komentuj to co istotne, ale unikaj zbędnych komentarzy
• Komentując odpowiadaj na pytania czytelnika
• Komentuj wszystkie niebanalne zmienne (pola)
• ...

Slajd 15 z 22

Techniki z natury

niebezpieczne

Slajd 16 z 22

Techniki z natury niebezpieczne

• Instrukcje typu

goto

goto (skocz do) oraz wykorzystanie

etykiet prowadzą zwykle do programów, których
działanie jest trudne do zrozumienia i prześledzenia

• Stosowanie

liczb ze zmiennym przecinkiem

liczb ze zmiennym przecinkiem,

których dokładność jest ograniczona i może być
przyczyną nieoczekiwanych błędów, najczęstsze
błędy pojawiają się podczas porównań

•

Wskaźniki i arytmetyka wskaźników

Wskaźniki i arytmetyka wskaźników: dają
możliwość dowolnej penetracji całej pamięci
operacyjnej i w przypadku popełnienia błędu
prowadzić mogą do zupełnie nieoczekiwanych
(losowych) zachowań, które ciężko jest diagnozować

Slajd 17 z 22

Techniki z natury niebezpieczne

•

Obliczenia równoległe

Obliczenia równoległe: mogą prowadzić do
złożonych zależności czasowych i tzw. pogoni
(wynik zależy od tego, który z procesów
szybciej dojdzie do pewnego punktu w
obliczeniach); z uwagi m.in. na niedeterminizm
zachowania bardzo trudne do testowania; np.
wątki są określane jako zatrute jabłko

•

Przerwania i wyjątki

Przerwania i wyjątki - wprowadzają również
pewien rodzaj równoległości; dodatkowo,
ryzyko przerwania operacji krytycznych
czasowo

Slajd 18 z 22

Techniki z natury niebezpieczne

•

Rekurencja

Rekurencja - może prowadzić do krytycznego zapętlenia albo
przepełnienia stosu wywołań; utrudnia śledzenie programu,

• Procedury i funkcje, które realizują wyraźnie odmienne

zadania w zależności od parametrów lub stanu zewnętrznych
zmiennych,

• Dynamiczna alokacja pamięci - stosowana bez zapewnienia

mechanizmu

zwalniana pamięci już niewykorzystywanej

zwalniana pamięci już niewykorzystywanej,

•

Zmienne globalne

Zmienne globalne

,

,

• Niewyspecyfikowane, nieoczekiwane efekty uboczne funkcji i

procedur,

• Przeciążanie operatorów - problemy z kolejnością wywołań

operatorów

Stosowanie powyższych technik wymaga

zachowania dużej ostrożności, ale w

niektórych

sytuacjach może być przydatne

lub wręcz

niezbędne

Slajd 19 z 22

Zasada ograniczonego

dostępu

Slajd 20 z 22

Zasada ograniczonego dostępu

• Podstawowa zasada stosowana do zachowania

bezpieczeństwa polega na ograniczeniu dostępu

tylko do tych informacji, które są niezbędne do

osiągnięcia określonych celów - natomiast

wszystko, co może być ukryte, powinno być

ukryte

• Programista nie powinien mieć żadnej możliwości

operowania na tej części oprogramowania lub

zasobów komputera, które nie dotyczą tego, co

aktualnie robi. Perspektywy (prawa dostępu)

programisty powinny być ograniczone tylko

do tego kawałka, który aktualnie programuje.

• Typowe języki programowania niestety nie w

pełni realizują te zasady

Slajd 21 z 22

Zasada ograniczonego dostępu

Zasada ograniczonego dostępu

realizowana poprzez

hermetyzację

(prywatne i chronione pola, zmienne,
metody)

Slajd 22 z 22

Mocna kontrola

typów

Slajd 23 z 22

Mocna kontrola typów

•

Typ jest formalnym ograniczeniem

narzuconym na budowę zmiennych lub obiektów;
typy określają również parametry i wyniki funkcji
i metod

•

Zasadniczym celem typów jest

kontrola

formalnej poprawności

programu

•

W językach z tzw. mocnym typowaniem

każdy

deklarowany byt programistyczny musi być
wyposażony w deklarację typu, przez którą
programista wyraża oczekiwania co do roli bytu w
programie

Slajd 24 z 22

Mocna kontrola typów

• Dzięki temu możliwe jest sprawdzenie, czy wszystkie

odwołania do określonej zmiennej w programie mają

kontekst, w jakim może być użyty typ
wykorzystany do jej definicji

• Mocna typologiczna kontrola poprawności

programów okazała się

cechą skutecznie

eliminującą błędy

popełniane przez programistów

• Według typowych szacunków,

po wyeliminowaniu

błędów syntaktycznych

programu nawet

do 80%

pozostałych błędów jest wychwytywane przez
mocną kontrolę typu

Slajd 25 z 22

Typowe środowiska implementacji

• Języki proceduralne

(C, Pascal)

• Języki obiektowe

(C++, Java)

• Relacyjne bazy danych
• Obiektowe bazy danych
• Obiektowo-relacyjne bazy danych
• Środowiska programistyczne programów

użytkowych

(np. Visual Basic dla Aplikacji w MS Excel)

• Narzędzia szybkiego wytwarzania aplikacji

W wielu projektach stosowane są

rozwiązania

hybrydowe

, wynikające np. z ograniczeń

narzuconych przez rozwiązania zastane w

organizacji

Slajd 26 z 22

Charakterystyka

środowisk

Slajd 27 z 22

Charakterystyka środowisk

Środowisko

Środowisko

języków proceduralnych

języków proceduralnych

(tradycyjne i wciąż

popularne środowisko implementacji)

• Grupy procedur - odpowiadają poszczególnym

funkcjonalnościom systemu

• Składy danych w projekcie odpowiadają strukturom

danych języka lub strukturom przechowywanym w pliku.

• Języki proceduralne dają niewielkie możliwości

ograniczenia dostępu do danych (składowe struktur
są dostępne wtedy, gdy dostępna jest cała struktura)

• Istnieje możliwość programowania w stylu

obiektowym, ale brakuje udogodnień takich jak klasy,
dziedziczenia, metody wirtualne.

Slajd 28 z 22

Charakterystyka środowisk

Środowisko

Środowisko języków obiektowych

• Z reguły niewystarczające w przypadku dużych

zbiorów przetwarzanych danych; wymagają
współpracy z bazą danych

• Większość języków obiektowych to języki

hybrydowe, powstające w wyniku dołożenia
cech obiektowości do języków proceduralnych
(klasycznym przypadkiem takiego rozwiązania jest
C++)

• Jak się wydaje, jedną z zalet języków hybrydowych

jest znacznie łatwiejsze ich wypromowanie
bazujące na znajomości ich przodków

Slajd 29 z 22

Charakterystyka środowisk

Relacyjne bazy danych

Relacyjne bazy danych

najlepiej rozwinięte środowiska baz danych,

pozwalające na wykorzystanie dużych zbiorów danych

Plusy:
• wielodostęp
• automatyczna weryfikacja więzów integralności
• prawa dostępu dla użytkowników
• wysoka niezawodność
• możliwość rozproszenia danych
Minusy
• skomplikowane odwzorowanie modelu pojęciowego
• mała efektywność dla pewnych zadań (kaskadowe

złączenia)

• ograniczenia w zakresie typów

Slajd 30 z 22

Charakterystyka środowisk

Obiektowe bazy danych

Obiektowe bazy danych

• Zaletą jest wyższy poziom abstrakcji, który umożliwia

stworzenie tej samej aplikacji w sposób bardziej
skuteczny, konsekwentny i jednorodny

• Zmniejszenie dystansu pomiędzy modelowaniem a

implementacją

• W stosunku do modelu relacyjnego, obiektowość

wprowadza więcej pojęć, które wspomagają procesy
myślowe

• Komercyjne produkty potencjalnie osiągnęły wystarczającą

dojrzałość, ale praktycznie nie zdobyły powszechnej
akceptacji niezbędnej do skutecznej rywalizacji

Slajd 31 z 22

Charakterystyka środowisk

Środowiska obiektowo-relacyjne

Środowiska obiektowo-relacyjne

• Sukces obiektowości spowodował zainteresowanie

wprowadzeniem cech takich jak klasy, metody,
dziedziczenia, abstrakcyjne typy danych, do
systemów relacyjnych (elementy obiektowości
wprowadzane są do większości systemów
znajdujących się na rynku)

• Podstawą takich rozwiązań jest zachowanie

sprawdzonych technologii relacyjnych (np. SQL) i
wprowadzanie na ich wierzchołku innych własności

• Obserwujemy, więc bardzo ostrożną ewolucję

systemów relacyjnych w kierunku obiektowości

Slajd 32 z 22

Charakterystyka środowisk

Środowiska programów użytkwych

Środowiska programów użytkwych

Przykładem może być MS Office (Excel)
• Zawiera pełny proceduralny język Visual Basic dla

Aplikacji

• Obejmuje rozbudowaną bibliotekę obiektów (większość

możliwości pakietu)

• Pozwala na nagrywanie makrodefinicji w stylu Visual

Basic

• Wizualne projektowania interfejsu użytkownika

(dialogi, menu i paski narzędziowe), umieszczanie pól
dialogowych na arkuszach, definiowanie reakcji na
zdarzenia

• Zawiera debugger

Slajd 33 z 22

O czym był wykład ?

• Ułatwienia implementacji
• Niezawodność oprogramowania
• Określenie niezawodności oprogramowania

Oszacowanie i podnoszenie niezawodności

• Techniki z natury niebezpieczne
• Zasada ograniczonego dostępu
• Mocna kontrola typów
• Charakterystyka środowisk