Softwarov´e inˇzen´yrstv´ı I N´avrh softwaru ˇ RNDr. Michal Zemliˇ cka, Ph.D. Vysok´ a ˇskola finanˇ cn´ı a spr´ avn´ı
Zimn´ı semestr 2013/2014
N´avrh softwaru – k ˇcemu to?
I
Udˇelat cokoliv vˇetˇs´ıho bez pl´anu je riskantn´ı z´aleˇzitost.
I
Velk´y program za n´as ˇz´adn´a ”neviditeln´a ruka softwaru”kvalitnˇe nevytvoˇr´ı.
I
Abychom mohli dobˇre pl´anovat, b´yv´a v´yhodn´e se pouˇcit s ˇc´ım uspˇeli ti pˇred n´ami.
I
Pod´ıv´ame se na hrub´y i jemnˇejˇs´ı n´avrh, na nˇekter´e architektonick´e prvky i na srovn´an´ı nˇekter´ych pˇr´ıstup˚ uk n´avrhu softwaru.
N´avrhov´y proces
Obecn´y model n´avrhu softwaru je orientovan´y graf. C´ılem tohoto procesu je vytvoˇren´ı dan´e struktury bez nekonsistenc´ı. N´aˇcrt/osnova neform´aln´ıho n´avrhu 6
aln´ı - Neform´ n´avrh 6 ?
alnˇejˇs´ı - Form´
y - Hotov´
n´avrh
n´avrh
6 ?
?
N´avrhov´e aktivity 1. Architekturn´ı n´ avrh. Identifikace a dokumentace subsyst´em˚ u a jejich vztah˚ u. 2. Abstraktn´ı specifikace. Pro kaˇzd´y subsyst´em je provedena abstraktn´ı specifikace sluˇzeb, kter´e podporuje, i omezen´ı, za kter´ych mus´ı fungovat. 3. N´ avrh rozhran´ı. Pro kaˇzd´y subsyst´em je navrˇzeno a zdokumentov´ano rozhran´ı k ostatn´ım ˇc´astem. 4. N´ avrh komponent. Sluˇzby jsou rozm´ıstˇeny do jednotliv´ych komponent a jsou vytvoˇrena rozhran´ı tˇechto komponent. 5. N´ avrh datov´ ych struktur. Podrobn´y n´avrh datov´ych struktur pouˇzit´ych k implementaci syst´emu. 6. N´ avrh algoritm˚ u. Podrobn´y n´avrh a popis algoritm˚ u pouˇzit´ych k poskytov´an´ı sluˇzeb.
Metody n´avrhu
I
Model toku dat. Syst´em je modelov´an pomoc´ı transformac´ı dat.
I
Entitnˇ e-relaˇ cn´ı model. Popisuje logick´e datov´e struktury.
I
Strukturovan´ y model. Dokumentuje syst´emov´e komponenty a jejich interakci. Objektovˇ e-orientovan´ y model. Mˇel by obsahovat:
I
I I I
model dˇediˇcnosti, model skl´ad´an´ı objekt˚ u a obvykle i model toho, jak jsou objekty vyuˇz´ıv´any jin´ymi objekty.
Popis n´avrhu 1. Grafick´e notace I
I I
Pouˇz´ıvaj´ı se k zobrazen´ı vztah˚ u mezi komponentami a k nav´az´an´ı syst´emu na re´aln´y svˇet, kter´y modeluje. Grafick´y pohled je abstraktn´ım pohledem. B´yvaj´ı velmi v´yhodn´e pro z´ısk´an´ı celkov´eho pˇrehledu.
2. Jazyky popisu programu (program description languages, PDL). Tyto jazyky vyuˇz´ıvaj´ı ˇr´ıd´ıc´ı a strukturn´ı konstrukty zaloˇzen´e na programovac´ıch jazyc´ıch, ale tak´e vysvˇetluj´ıc´ı text a nˇekdy t´eˇz dalˇs´ı typy pˇr´ıkaz˚ u. To umoˇzn ˇuje zachytit sp´ıˇse z´amˇer n´avrh´aˇre neˇz implementaˇcn´ı detaily. 3. Neform´aln´ı text. Mnoho z infomac´ı spojen´ych s n´avrhem nem˚ uˇze b´yt vyj´adˇreno form´alnˇe. Nˇekter´e z´amˇery mohou b´yt l´epe vyj´adˇreny textem.
N´avrhov´e startegie
1. Funkˇcn´ı/praktick´y n´avrh. Syst´em je navrˇzen z funkˇcn´ıho pohledu postupn´ym zjemˇ nov´an´ım shora dol˚ u. Z´astupci thoto pˇr´ıstupu jsou: I I I
Strukturovan´y n´avrh [1] SSADM [2, 4] postupn´e zjemˇ nov´an´ı [5, 6]
2. Objektovˇe orientovan´y n´avrh. Syst´em je nahl´ıˇzen jako kolekce objekt˚ u. OON vych´az´ı z myˇslenky skr´yv´an´ı infomace [3] a byl pops´ana mnoha autory.
Koheze
Koheze komponenty je m´ıra nebo bl´ızkost vztah˚ u mezi jej´ımi ˇc´astmi. Komponenta by mˇela realizovat jednu logickou funkci nebo jednu logickou entitu. Koheze je v´yznamnou charakteristikou, protoˇze znamen´a, ˇze jednotka implementuje jednu ˇc´ast ˇreˇsen´ı probl´emu.
Koheze (2) Constatnitne a Yourdon [1] rozliˇsuj´ı 7 u ´rovn´ı koheze s rostouc´ı silou: 1. N´ahodn´a koheze – ˇc´asti komponenty nejsou prov´az´any, jsou prostˇe zabaleny do jedn´e komponenty; 2. Logick´a asociace – ˇc´asti vykon´avaj´ıc´ı podobnou funkci jako oˇsetˇren´ı vstupu nebo tiskov´e v´ystupy jsou zabaleny dohromady; 3. Tempor´aln´ı koheze – vˇsechny ˇc´asti se aktivuj´ı ve stejnou dobu (napˇr´ıklad spuˇstˇen´ı nebo vypnut´ı) jsou zabaleny dohromady; 4. Procedur´aln´ı koheze – ˇc´asti komponenty tvoˇr´ı jednu ˇr´ıd´ıc´ı sekvenci; 5. Komunikaˇcn´ı koheze – vˇsechny ˇc´asti komponenty pracuj´ı nad stejn´ymi vstupn´ımi daty nebo produkuj´ı stejn´a v´ystupn´ı data; 6. Sekvenˇcn´ı koheze – v´ystup jedn´e ˇc´asti slouˇz´ı jako vstup pro nˇejak´e dalˇs´ı ˇc´asti; 7. Funkˇcn´ı koheze – kaˇzd´a ˇc´ast komponenty je potˇrebn´a pro v´ykon jedn´e funkce.
Koheze (3)
Popsan´e tˇr´ıdy nejsou striktnˇe definov´any. P˚ uvodn´ı dokument je funkˇcn´ı. M˚ uˇzeme tak pˇridat jeˇstˇe dalˇs´ı stupeˇ n: 8 Objektov´a koheze – kaˇzd´a operace prov´ad´ı funkcionalitu umoˇzn ˇuj´ıc´ı modifikovat, kontrolovat, nebo pouˇz´ıvat atributy objektu;
Adaptabilita
I
Adaptabilita n´avrhu je obecn´e oˇcek´av´an´ı toho, jak snadno jde n´avrh mˇenit.
I
Komponenty mus´ı b´yt volnˇe spojen´e.
I
Pro vysokou adaptabilitu je vhodn´e, aby komponenta byla samostatn´a (self-contained) – aby nebyla z´avisl´a na dalˇs´ıch, extern´ıch, komponent´ach. To je v rozporu s maxim´aln´ı znovupouˇzitelnost´ı a s t´ım, aby bylo jedno m´ısto opravy. N´avrh´aˇr tak mus´ı zvolit vhodn´y kompromis mezi znovupouˇzitelnost´ı a adaptabilitou.
N´avrh datov´ych tok˚ u (Data-Flow Design)
I
Ukazuje, jak data proch´azej´ı syst´emem a jak jsou transformov´ana jednotliv´ymi funkcemi syst´emu.
I
B´yv´a moˇzn´e odvodit tento model od modelu datov´ych tok˚ u z´ıskan´eho v anal´yze.
I
Diagramy datov´ych tok˚ u podporuj´ı hierarchick´e ˇclenˇen´ı. To usnadˇ nuje jejich n´avrh i porozumnˇen´ı v pˇr´ıpadˇe rozs´ahlejˇs´ıch model˚ u.
I
Grafick´e zobrazen´ı se v r˚ uzn´ych CASE n´astroj´ıch v´yraznˇe liˇs´ı; je tˇreba se nejdˇr´ıve ujistit, jak to je v dan´em syst´emu.
Syst´emy pracuj´ıc´ı v re´aln´em ˇcase
I
I
Na jejich pr´aci je kladen dalˇs´ı poˇzadavek: jednotliv´e funkce mus´ı b´yt vykon´any do urˇcit´e doby od vyvol´an´ı. 2 varianty: 1. tvrd´e syst´emy re´aln´eho ˇcasu (hard real-time systems) – ˇcasov´a omezen´ı mus´ı b´yt dorˇzena, jinak hroz´ı velk´y probl´em; 2. mˇekk´e syst´emy re´aln´eho ˇcasu (soft real-time systems) – ˇcasov´a omezen´ı je tˇreba dodrˇzet, ale obˇcasn´e m´ırn´e nedodrˇzen´ı nevad´ı, pokud se limity v souˇctu dodrˇz´ı.
Syst´emy pracuj´ıc´ı v re´aln´em ˇcase – d˚ usledky I
Pˇri poˇzadavku na kr´atkou odezvu funkce nelze spol´ehat na z´asah ˇclovˇeka – jednoduˇse za setinu sekundy reagovat nestihne (natoˇz aby si reakci rozmyslel).
I
V mnoha syst´emech re´aln´eho ˇcasu nelze pouˇz´ıt pevn´y disk ani jin´e periferie s promˇennou dobou odezvy. Toto je typick´e sp´ıˇse pro syst´emy ˇci funkce pracuj´ıc´ı v reˇzimu hard real-time.
I
I v syst´emech oznaˇcovan´ych jako hard real-time b´yvaj´ı ˇc´asti, pro kter´e ve skuteˇcnosti staˇc´ı podm´ınka soft real-time. Nˇekdy takov´e syst´emy obsahuj´ı i ˇc´asti, kter´e mohou fungovat jako d´avka (bˇeˇz´ı, dokud nedobˇehnou).
I
Hard real-time operace mohou m´ıt zak´az´anu alokaci pamˇeti (tedy ˇz´adn´a Java, C#, php nebo jin´e jazyky, kter´e si alokuj´ı nebo dokonce ˇcist´ı pamˇet’ ve vlastn´ı reˇzii).
Syst´emy pracuj´ıc´ı v re´aln´em ˇcase – pokraˇcov´an´ı Syst´emy pracuj´ıc´ı v re´aln´em ˇcase: I
nesm´ı vypadnout – je tˇreba je vyv´ıjet s v´yraznˇe vˇetˇs´ım d˚ urazem na spolehlivost;
I
mus´ı poˇc´ıtat to, co je od nich poˇzadov´ano (pokud m´ısto brzd vyvol´ame akceleraci, m˚ uˇze to pro mnoho lid´ı skonˇcit velmi ˇspatnˇe); nesm´ı ztr´acet pamˇet’ (mus´ı vydrˇzet v provozu bez restartu dlouhou dobu);
I
I
by mˇel poˇc´ıtat s probl´emy a m´ıt definovan´y bezpeˇcn´y stav, do kter´eho v pˇr´ıpadˇe probl´em˚ u pˇrejde.
Webov´e aplikace vykazuj´ı mnoh´e vlastnosti soft real-time – m˚ uˇze b´yt v´yhodn´e se pˇri jejich tvorbˇe ve svˇetˇe soft real-time inspirovat.
L. L. Constantine and E. Yourdon. Structured Design. Prentice-Hall, Englewood Cliffs, NJ, 1979. G. Cutts. Structured systems analysis and design methodology. In H.-J. Bullinger, editor, Information Technology for Organzational Systems, pages 363–370, Amsterdam, 1988. Elsevier. D. L. Parnas. Designing software for ease of extension and contraction. IEEE Transactions on Software Engineering, 5(2):128–138, 1979. P. Weaver. Practical SSADM, vesrion 4. Pitman, London, 1993. N. Wirth. program development by stepwise refinement. Communication of the ACM, 14(4):221–227, 1971.
N. Wirth. Systematic Programming: An Introduction. Prentice-Hall, Englewood Cliffs, NJ, 1976.
