Ešte k objektovo-orientovanému návrhu ...

Kedy je návrh „modulárny“ ?

Kritériá:• modulárna

dekompozícia• modulárna

komponovateľnosť• modulárna

zrozumiteľnosť• modulárna spojitosť• modulárna ochrana

Pravidlá:• priame mapovanie• málo rozhraní• malé rozhrania• explicitné rozhrania• skrývanie informácií

1. Kde hľadať triedy (pre návrh) ?

• v analytických modeloch– odkiaľ sa vezmú tam ?

• zo špecifikácie požiadaviek, slovníka používateľov ... (podstatné mená)

• „Výťah musí zavrieť dvere pred tým, ako sa presunie na ďalšie poschodie.“

• je potrebné zvážiť, či ide skutočne o triedy

• nie všetky triedy je takto možné zachytiť

• štúdium príkladov (knihy, knižnice)• design patterns• vlastný rozum

Ideálna trieda...

• má jasne asociovaný ADT

• dá sa vyjadriť podstatným menom

• má objekty (aspoň 1) – ak nie ona, tak jej podtriedy

• má operácie – príkazy a dotazy

Chyby

• „Táto trieda vykonáva ...“ (tlačí výsledky, analyzuje vstup, ...)

• triedy s jednou funkciou

• spojenie viacerých abstrakcií do 1 triedy– príklad: NSText – trieda pre reprezentáciu

textového reťazca (s operáciami ako porovnanie, spájanie atď.), ktorá zároveň poskytuje operácie pre editovanie reťazca na obrazovke: rozdeliť na NSAttributedString a NSTextView

2. Ako navrhnúť rozhranie triedy ?(a) nemať mnoho argumentov v operáciách

– nonlinear_ode (• equation_count: in INTEGER;• epsilon: in out DOUBLE;• func: procedure (eq_count: INTEGER; a: DOUBLE; eps: DOUBLE; b: ARRAY [DOUBLE]; cm: pointer Libtype)

• left_count, coupled_count: in INTEGER;...)

• spolu 19 argumentov, z toho:– 4 „in out“– 3 polia, použité ako vstup aj výstup– 6 funkcií, každá s 6-7 argumentami, z ktorých sú 2-3

polia

Rozhranie triedy 2

• rozlišovať operands a optionsmy_document.print (printer_name, paper_size, color_or_not, postscript_level, print_resolution);

– operand – objekt, na ktorom operácia pracuje– option – spôsob vykonania operácie (existuje

preň default value)

• argumentami operácie majú byť len operands

Rozhranie triedy 3

• my_document.set_printing_size („A4“);• my_document.set_color ();• my_document.print ();

• možná optimalizácia – doplnková funkciaprint_with_size_and_printer (printer, size);

Rozhranie triedy 4

(b) Oddelenie príkazov od dotazov

(command-query separation)

Inými slovami, dotazy nemajú mať side efekty.

kontrapríklad: c = getc (fp);

3. Dobre použiť dedenie• nerobiť dedenie, pokiaľ nie je možné nejakým spôsobom

zdôvodniť, že objekt podtriedy je zároveň objektom nadtriedy

• kontrapríklad:– class CAR_OWNER extends CAR, PERSON;

• výber medzi klientom a dedením nie je vždy jednoznačný– rule of change – nepoužiť dedenie, ak sa objekty vo vzťahu môžu

meniť

– polymorphism rule – použiť dedenie, ak premenné všeobecnejšieho typu majú ukazovať na objekty (aj) konkrétnejšieho typu

• taxomania – zbytočné vytváranie podtried

Verifikácia a validácia

Definícia

• verifikácia – overenie správnosti produktu vzhľadom k formulovaným požiadavkám

• validácia – overenie správnosti produktu vzhľadom k reálnym požiadavkám

(validácia je v konečnom dôsledku to, čo je podstatné)

Kedy ?

• V & V sa robí v každej etape– pri špecifikácii požiadaviek– pri plánovaní– pri návrhu– pri implementácii– pri integrácii– pri odovzdávaní– pri údržbe– ...

• používa sa tiež pojem Quality Assurance, resp. Quality Control

Prehľad

• V&V– programu

• unit testing

• integration testing

• system testing

• acceptance testing

– iných produktov (dokumentov)

– vykonáva sa:• dynamicky (so spustením)

• staticky (bez spustenia)

Postup pri testovaní „so spustením“

1. vybrať dáta a stanoviť očakávané výsledky

2. spustiť program

3. porovnať výsledky s očakávanými

• min. body 2 a 3 môžu byť automatizované

Výber testovacích údajov

• Black-box (podľa špecifikácie)– na kód nehľadím, snažím sa vytvoriť vstupy,

ktoré budú mať vyššiu pravdepodobnosť odhalenia prípadnej chyby

• White-box (podľa kódu)– snažím sa vytvoriť vstupy, ktoré prejdú

všetkými časťami kódu

Exhaustívne testovanie ?

• v praxi ťažko uskutočniteľné– príklad: majme 6 vstupných parametrov, každý s 256

možnými hodnotami ...

– príklad: program s cyklom ...

• v prípade white-box testovania nemusí zaručovať bezchybnosť:if ((x+y+z)/3 == x) printf ("sú rovnaké");else printf ("nie sú rovnaké");

Výber hraničných hodnôt

• Rozdelíme množinu vstupných hodnôt na triedy ekvivalencie (na ktorých očakávame, že sa bude program správať rovnakým spôsobom)– kladné čísla vs. záporné čísla vs. nula– prázdne polia vs. viacprvkové polia– reťazce s medzerami vs. reťazce bez medzier– hľadaný prvok je v poli vs. nie je v poli

• Z každej triedy ekvivalencie vyberáme niekoľko prvkov.

• Sústreďujeme sa tiež na hraničné prvky (ležiace medzi triedami ekvivalencie)– príklad: vyhľadávanie v poli

• nulová vs. nenulová veľkosť (test: pre 0, 1, 2, n)• prvok nájdený vs. nenájdený (test: nenájdený,

nájdený na začiatku, v strede, na konci)

– príklad: výpočet dane• triedy ekvivalencie – pásma v príslušnej tabuľke

White-box testing

• vyberáme podmnožinu všetkých ciest– napr. pokrytie všetkých príkazov– pokrytie všetkých vetvení

Statická V & V programu

• inšpekcia kódu– hľadáme chyby, podozrivé miesta, fragmenty

nezodpovedajúce programovacím štandardom

– potrebujeme:• výslednú podobu kódu (musí byť kompilovateľný)

• špecifikáciu programu

• checklist častých chýb

– tím ľudí, aspoň 4

– prezentujúci prechádza cez program, ostatní členovia tímu vznášajú k nemu pripomienky

Integračné testovanie

a

b c d

e g

j k

f

h i

l m

• Nutný je inkrementálny prístup– zhora nadol

• skôr nájde chyby v celkovom návrhu

• už skoro je k dispozícii ako-tak chodiaci systém (je možná aj validácia)

• je potrebné vytvárať stubs pre volané moduly

– zdola nahor• spodné moduly sú najlepšie otestované (reuse)

Testovanie systému ako celku

• Celková funkčnosť (black-box)

• Záťažové testy

• Spoľahlivosť – štatistické testovanie– operačný profil– generovanie údajov– vyhodnotenie (MTTF, POFOD, ROCOF,

AVAIL...)

Akceptačné testovanie

• podobné systémovému testovaniu, ale v réžii zákazníka a na ním určených dátach

• po úspešnom akceptačnom testovaní je produkt odovzdaný

V & V dokumentov(Quality Review)

Príprava StretnutieProdukt

schválený

Opravachýb

ProduktvrátenýNeúspech

Plánovanie

Plánovanie

• výber produktov na QR– ak treba, kontrola po častiach

• určenie kritérií kvality produktov

• príklad kritérií kvality (produkt: používateľská príručka):– štandardné kritériá pre dokument (pravopis, gramatika, sloh)– je príručka konzistentná s logickým návrhom systému ?– je predpokladaná skupina čitateľov správne určená ?– je príručka písaná na správnej úrovni pre týchto čitateľov ?– môžu byť programy úspešne používané podľa pokynov v

príručke ?– sú všetky relevantné chybové správy popísané, a to v logickom

poradí ?– používa sa príručka ľahko ? má jasnú štruktúru ? sú informácie

prehľadne prezentované ? má príručka vhodný index ?

Príprava

• distribúcia materiálov členom tímu pre QR

• čítanie „doma“, poznačenie si chýb

Stretnutie

• diskusia

• schválenie zoznamu chýb

• poznámka: cieľom je identifikovať chyby, nie navrhovať riešenia

Príprava StretnutieProdukt

schválený

Opravachýb

ProduktvrátenýNeúspech

Plánovanie

Poznámky

• po stretnutí – vývoj už len v rámci riadenia zmien

• výsledky QR sa nemajú odraziť v hodnotení pracovníkov

• celý mechanizmus V&V má byť popísaný v projektovej príručke