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

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

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í Kedy je návrh „modulárny“ ?

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 options my_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á funkcia print_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“ • vybrať dáta a stanoviť očakávané výsledky • spustiť program • 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

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)

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

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

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