ˇ EDNA ´ SˇEK OBSAH PR ´ vod. Co je SW inzˇeny´rstvı´. Proces vy´voje SW 1. U
. . . . . . . . . . . . . . . . . . . 2
2. Modely SW procesu. Specifikace pozˇadavku˚ . . . . . . . . . . . . . . . . . . . .
12
3. DSP. Zı´ska´va´nı´ pozˇadavku˚ . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
4. Terminologie a notace objektoveˇ orientovane´ analy´zy . . . . . . . . . . . . . . . .
37
5. UML: diagramy trˇ´ıd a objektu˚, diagram komponent, diagram prˇ´ıpadu˚ pouzˇitı´, diagram spolupra´ce, sekvencˇnı´ a stavovy´ diagram . . . . . . . . . . . . . . . . . . . . . . . . . . 48 6. Objektoveˇ orientovana´ analy´za. Na´vrh architektury syste´mu
. . . . . . . . . . . . .
7. Objektoveˇ orientovany´ na´vrh a implementace. Na´vrhove´ vzory (design patterns)
57
. . . . .
70
8. Strukturovana´ analy´za . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
79
9. Modernı´ strukturovana´ analy´za. Strukturovany´ na´vrh. Vytva´rˇenı´ modulu˚
. . . . . . . .
91
. . . . . . . . . .
99
10. Na´vrh uzˇivatelske´ho rozhranı´. Architektonicke´ styly. Implementace
11. Prototypova´nı´. Programa´torsky´ styl a dokumentace ko´du. Optimalizace programu . . . . . 110 12. Verifikace a validace. Testova´nı´ jednotek. Integracˇnı´ testova´nı´ . . . . . . . . . . . . . 121 ´ drzˇba SW syste´mu˚. Metriky. Pra´ce v ty´mech. Konfiguracˇnı´ management. 13. Testova´nı´ syste´mu. U Eticke´ a pra´vnı´ aspekty tvorby SW . . . . . . . . . . . . . . . . . . . . . . . . 132 Pouzˇita´ literatura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
150
Za´klady softwarove´ho inzˇeny´rstvı´
2 KIV/ZSWI 2004/2005 Pr ˇedna ´s ˇka 1 Pozna ´mky k textu pr ˇedna ´s ˇek ==========================
Pokud bude v za ´pisu pr ˇedna ´s ˇek ne ˇco nesrozumitelne ´ nebo pokud najdete pr ˇeklepy apod., prosı ´m dejte mi to ve ˇde ˇt nejle ´pe e-mailem na adresu
. Ve ˇci, ktere ´ jsou uvedeny s pozna ´mkou typu ”pro zajı ´mavost”, nebudou vyz ˇadova ´ny u zkous ˇky, ale bylo by dobre ´ si je alespon ˇ pr ˇec ˇı ´st. Nejc ˇaste ˇjs ˇı ´ zkratky, pouz ˇite ´ v tomto textu: * * * *
DSP = dokument specifikace poz ˇadavku ˚ HW = hardware SW = software SWE (SW Engineering) = softwarove ´ inz ˇeny ´rstvı ´
Jak a proc ˇ vzniklo SW inz ˇeny ´rstvı ´ ================================= * prvnı ´ poc ˇı ´tac ˇe programova ´ny jednotlivci nebo maly ´mi ty ´my * c ˇasto VT vy ´poc ˇty, jazyky FORTRAN a assembler * pr ˇı ´chod poc ˇı ´tac ˇ˚ u III. generace (1965-1980) - integrovane ´ obvody (oproti poc ˇı ´tac ˇ˚ um sestaveny ´m z jednotlivy ´ch tranzistoru ˚ apod.) * o ne ˇkolik r ˇa ´du ˚ vy ´konne ˇjs ˇı ´, ve ˇts ˇı ´ pame ˇt’ apod. * moz ˇnosti novy ´ch aplikacı ´ (banky, pojis ˇt’ovny, letecke ´ spolec ˇnosti...) * vy ´sledne ´ aplikace o ne ˇkolik r ˇa ´du ˚ rozsa ´hlejs ˇı ´ nez ˇ pr ˇedchozı ´ SW syste ´my * vy ´sledek - du ˚lez ˇite ´ syste ´my c ˇasto le ´ta zpoz ˇde ˇnı ´, cena ne ˇkolikana ´sobek pu ˚vodnı ´ch pr ˇedpokladu ˚, chybovost atd. - termı ´n ”softwarova ´ krize” * uka ´zalo se, z ˇe zpu ˚soby vy ´voje pro male ´ SW projekty se nedajı ´ pouz ˇı ´t pro velke ´ projekty, zapotr ˇebı ´ nove ´ techniky a metody * termı ´n ”softwarove ´ inz ˇeny ´rstvı ´” navrz ˇen v 1968 na konferenci NATO o ”softwarove ´ krizi” * nejzna ´me ˇjs ˇı ´ pr ˇı ´pad syste ´mu OS/360 od IBM - jeden z prvnı ´ch velmi rozsa ´hly ´ch projektu ˚ operac ˇnı ´ho syste ´mu - na zac ˇa ´tku 200, maximum pr ˇes 1000 lidı ´ - vı ´ce o ne ˇm na ZOS * Brooks na za ´klade ˇ zkus ˇenostı ´ napsal knihu ”The Mythical Man Month” (Brooks 1975) * te ´ma - proc ˇ je obtı ´z ˇne ´ vytva ´r ˇet velke ´ SW syste ´my * Brooks napr ˇ. tvrdı ´, z ˇe programa ´tor ˇi jsou schopni napsat jenom cca 1000 r ˇa ´dku ˚ odlade ˇne ´ho ko ´du za rok (tj. v pru ˚me ˇru cca 5.5 r ˇa ´dku za den) * Brooks vs. odpove ˇdi na DOTAZ - jak je to moz ˇne ´? * velke ´ projekty (= stovky programa ´toru ˚ ) jsou ´ uplne ˇ jine ´ nez ˇ male ´ projekty - zkus ˇenosti z maly ´ch projektu ˚ se nedajı ´ na velke ´ pr ˇene ´st * velke ´ projekty - dlouhou dobu spotr ˇebuje: - pla ´nova ´nı ´ jak rozde ˇlit projekt do modulu ˚ - specifikace c ˇinnosti a rozhranı ´ modulu ˚ - zı ´ska ´nı ´ pr ˇedstavy o interakci modulu ˚ - to vs ˇechno pr ˇed tı ´m, nez ˇ zac ˇne vlastnı ´ psanı ´ programu (”ko ´dova ´nı ´”) * na ´sleduje ko ´dova ´nı ´ a odlade ˇnı ´ jednotlivy ´ch modulu ˚ * integrace (sestavenı ´) modulu ˚ do vy ´sledne ´ho syste ´mu * vy ´sledny ´ syste ´m je tr ˇeba otestovat (i kdyz ˇ jednotlive ´ moduly odlade ˇny, po sestavenı ´ c ˇa ´stı ´ obvykle nefunguje napoprve ´) * tato posloupnost se nazy ´va ´ ”vodopa ´dovy ´ model” vy ´voje SW: 1. Pla ´nova ´nı ´ 2. Ko ´dova ´nı ´
zswi/p1proc.d
zswi/p1proc.d
3. ledna 2005
3. Test modulu ˚ 4. Test syste ´mu 5. Nasazenı ´ (Jes ˇte ˇ se k tomu vra ´tı ´me; ted’ zmin ˇuji pouze pro informaci.) * Brooks odhadl, z ˇe - 1/3 celkove ´ pra ´ce je pla ´nova ´nı ´ - 1/6 ko ´dova ´nı ´ - 1/4 testova ´nı ´ modulu ˚ - 1/4 testova ´nı ´ syste ´mu * jiny ´mi slovy - ko ´dova ´nı ´ je ta nejsnazs ˇı ´ c ˇa ´st - obtı ´z ˇne ´ je: . rozde ˇlit projekt do modulu ˚ . zajistit, aby modul A spra ´vne ˇ komunikoval s modulem B * tj. pokud 1 programa ´tor pı ´s ˇe maly ´ program, zu ˚sta ´va ´ mu ta nejjednodus ˇs ˇı ´ c ˇa ´st (jeho efektivita je take ´ vys ˇs ˇı ´, podle souc ˇasny ´ch me ˇr ˇenı ´ cca 20 r ˇa ´dku ˚/den) * ve ˇts ˇina ´ uloh, ktere ´ jste zatı ´m r ˇes ˇili, byly male ´ ´ ulohy * cı ´lem tohoto pr ˇedme ˇtu je zı ´skat za ´kladnı ´ pr ˇedstavu i o ostatnı ´ch c ˇa ´stech procesu vy ´voje SW Pozna ´mka (co se mı ´nı ´ pojmy software, SW syste ´m a SW produkt) * ve ˇts ˇina lidı ´ si pod pojmem SW pr ˇedstavuje pouze programy, pro praxi pr ˇ´ ılis ˇ omezujı ´cı ´ pohled * SW = programy + dokumentace + konfigurac ˇnı ´ data * SW syste ´m sesta ´va ´ obvykle z ne ˇkolika programu ˚, konfigurac ˇnı ´ch souboru ˚, syste ´move ´ dokumentace (popisuje strukturu syste ´mu) a uz ˇivatelske ´ dokumentace (vysve ˇtluje, jak syste ´m pouz ˇı ´vat) * SW produkt = SW, ktery ´ se da ´ prodat za ´kaznı ´kovi * existujı ´ 2 za ´kladnı ´ typy SW produktu ˚: - genericke ´ produkty . vyvı ´jen napr ˇ. na za ´klade ˇ analy ´zy potr ˇeb trhu . samostatne ´ syste ´my proda ´vane ´ na otevr ˇene ´m trhu kaz ˇde ´mu, kdo je schopen si je koupit (shrink-wrapped SW) . napr ˇ. operac ˇnı ´ syste ´my, textove ´ procesory, kreslı ´cı ´ programy, databa ´ze, pr ˇekladac ˇe programovacı ´ch jazyku ˚ atd. - produkty vyvı ´jene ´ na zaka ´zku (customised products) . SW vyvı ´jeny ´ pro konkre ´tnı ´ho za ´kaznı ´ka na za ´klade ˇ jeho poz ˇadavku ˚ . napr ˇ. informac ˇnı ´ syste ´m pro konkre ´tnı ´ firmu, r ˇı ´dı ´cı ´ syste ´my pro elektronicka ´ zar ˇı ´zenı ´ apod. - nejpodstatne ˇjs ˇı ´ rozdı ´l - kdo urc ˇuje specifikaci [] Co je SW inz ˇeny ´rstvı ´? ..................... * pojem software - viz pozna ´mka vy ´s ˇe * pojem inz ˇeny ´rstvı ´ (engineering) - slovnı ´kova ´ definice je: prakticka ´ aplikace teorie, metod a na ´stroju ˚ pr ˇi na ´vrhu stroju ˚, mostu ˚ apod. - prakticke ´ r ˇes ˇenı ´ je ale tr ˇeba najı ´t, i kdyz ˇ odpovı ´dajı ´cı ´ teorie (jes ˇte ˇ) neexistuje - proble ´my je tr ˇeba r ˇes ˇit v ra ´mci dany ´ch financ ˇnı ´ch a organizac ˇnı ´ch omezenı ´ * SW inz ˇeny ´rstvı ´ je aplikace inz ˇeny ´rsky ´ch metod na software - zaby ´va ´ vs ˇemi aspekty tvorby SW: specifikacı ´, vy ´vojem, testova ´nı ´m, ´ udrz ˇbou, managementem, atd. pr ˇedevs ˇı ´m rozsa ´hly ´ch SW syste ´mu ˚, vy ´vojem teorie, metod a na ´stroju ˚ pro vy ´voj SW
3
Za´klady softwarove´ho inzˇeny´rstvı´
4
Definice z IEEE Standard Computer Dictionary (1990): Aplikace systematicke ´ho, disciplinovane ´ho, me ˇr ˇitelne ´ho pr ˇı ´stupu na vy ´voj a ´ udrz ˇbu software; jiny ´mi slovy, aplikace inz ˇeny ´rsky ´ch principu ˚ na software. * rozdı ´ly mezi SW inz ˇeny ´rstvı ´m (SWE) a informatikou (computer science, CS): - CS se zaby ´va ´ algoritmy, zpu ˚sobem pra ´ce atd. poc ˇı ´tac ˇ˚ u a SW syste ´mu ˚ existuje exaktnı ´ popis - SWE r ˇes ˇı ´ prakticke ´ proble ´my tvorby SW . pr ˇı ´lis ˇ sloz ˇite ´, c ˇasto nutne ´ pouz ˇı ´vat ad hoc metody . na rozdı ´l od CS se v SWE ve ˇts ˇinou nedozvı ´te porovna ´nı ´ jednotlivy ´ch metod apod. - porovna ´nı ´ je obtı ´z ˇne ´ a drahe ´ (dokonce c ˇı ´m da ´l draz ˇs ˇı ´) . c ˇasto poskytuje obecne ´ koncepce, je na uz ˇivateli, aby je naplnil jednotlivinami Ale zpa ´tky k Brooksove ˇ knı ´z ˇce: Proc ˇ Mythical Man Month ....................... * dodnes ˇka mu ˚z ˇeme najı ´t ru ˚zna ´ vyja ´dr ˇenı ´ na ´roc ˇnosti vy ´voje SW v ”c ˇlove ˇkome ˇsı ´cı ´ch” (resp. ”c ˇlove ˇkorocı ´ch”) = poc ˇet lidı ´*c ˇas * titul Brooksovy knihy vycha ´zı ´ z tvrzenı ´, z ˇe c ˇas a poc ˇet lidı ´ nejsou zame ˇnitelne ´ * pokud projekt trva ´ 15 lidem 2 roky, nenı ´ moz ˇne ´, aby 15*24=360 lidem trval me ˇsı ´c (a asi ani to, aby 60 lidem trval 6 me ˇsı ´cu ˚) * je to ze 3 du ˚vodu ˚: 1) pra ´ce nenı ´ plne ˇ paralelizovatelna ´ - dokud nenı ´ dokonc ˇeno pla ´nova ´nı ´ a dokud nenı ´ urc ˇeno rozde ˇlenı ´ syste ´mu do modulu ˚ a definova ´no rozhranı ´ modulu ˚, nemu ˚z ˇeme zac ˇı ´t s ko ´dova ´nı ´m - napr ˇ. pro dvoulety ´ projekt mu ˚z ˇe pla ´nova ´nı ´ trvat 8 me ˇsı ´cu ˚ 2) abychom plne ˇ vyuz ˇili velky ´ poc ˇet programa ´toru ˚, musı ´me syste ´m rozde ˇlit na velky ´ poc ˇet c ˇa ´stı ´ (aby kaz ˇdy ´ programa ´tor me ˇl pra ´ci) - kaz ˇdy ´ podsyste ´m ale mu ˚z ˇe potencia ´lne ˇ komunikovat se vs ˇemi ostatnı ´mi => poc ˇet uvaz ˇovany ´ch interakcı ´ mezi podsyste ´my roste s druhou mocninou poc ˇtu podsyste ´mu ˚ 3) lade ˇnı ´ a testova ´nı ´ syste ´mu jsou obtı ´z ˇne ˇ paralelizovatelne ´ - 10 lidı ´ nenajde chybu 10x rychleji nez ˇ 1 - skutec ˇne ˇ spotr ˇebovany ´ c ˇas za ´visı ´ na poc ˇtu chyb a obtı ´z ˇnosti jejich hleda ´nı ´ Brooks shrnul svou zkus ˇenost do tzv. Brooksova za ´kona: ”Pr ˇida ´nı ´m lidı ´ ke zpoz ˇde ˇne ´mu projektu projekt jes ˇte ˇ vı ´ce zpozdı ´me.” (Adding manpower to a late software project makes it later.) * proc ˇ? - pr ˇidanı ´ lide ´ se musejı ´ s projektem sezna ´mit, coz ˇ zabere c ˇas i sta ´vajı ´cı ´m lidem (mı ´sto aby programovali, uc ˇı ´ nove ´ c ˇleny ty ´mu) - pra ´ce musı ´ by ´t pr ˇerozde ˇlena tak, aby to odpovı ´dalo ve ˇts ˇı ´mu poc ˇtu c ˇlenu ˚ ty ´mu (pr ˇerozde ˇlenı ´ pra ´ce zabere c ˇas, take ´ tı ´m pr ˇijdeme o c ˇa ´st jiz ˇ ude ˇlane ´ pra ´ce) Struktura ty ´mu .............. * male ´ skupiny programa ´toru ˚ (do 10 lidı ´) jsou obvykle organizova ´ny celkem neforma ´lne ˇ - vedoucı ´ skupiny se spoluu ´c ˇastnı ´ vy ´voje - ve skupine ˇ se mu ˚z ˇe najı ´t ”technicky ´ vedoucı ´” skupiny, ktery ´ urc ˇuje technicke ´ sme ˇr ˇova ´nı ´ - pra ´ce je diskutova ´na skupinou jako celkem (demokraticke ´ konsensua ´lnı ´ rozhodova ´nı ´), pra ´ce je rozde ˇlova ´na podle schopnostı ´ a zkus ˇenostı ´ * velke ´ projekty - velke ´ ty ´my (OS/360 - ve s ˇpic ˇce pr ˇes 1000 lidı ´) * jak ty ´m strukturovat? * hodne ˇ du ˚lez ˇita ´ kvalita lidı ´
zswi/p1proc.d
zswi/p1proc.d
3. ledna 2005
* je zna ´mo (Sackman et al 1968), z ˇe s ˇpic ˇkovı ´ programa ´tor ˇi jsou 10x vy ´konne ˇjs ˇı ´ nez ˇ s ˇpatnı ´ programa ´tor ˇi (ve skutec ˇnosti me ˇr ˇenı ´ probı ´halo ve skupine ˇ zkus ˇeny ´ch programa ´toru ˚; Sommerville uva ´dı ´ rozdı ´l az ˇ 25x) * proble ´m - pokud potr ˇebuji 200 programa ´toru ˚, te ˇz ˇko zame ˇstna ´m 200 ˇpic s ˇkovy ´ch - jsem nucen zame ˇstnat lidi ru ˚zny ´ch kvalit * ve velky ´ch projektech je du ˚lez ˇita ´ tzv. ”architektura ´lnı ´ koherence” * nejle ´pe aby jeden c ˇlove ˇk me ˇl pod kontrolou na ´vrh (design) syste ´mu * jinak mu ˚z ˇe vzniknou slepenice, ktera ´ se nikomu nebude lı ´bit * kombinace mys ˇlenky ”ne ˇkter ˇı ´ programa ´tor ˇi jsou mnohem leps ˇı ´ nez ˇ jinı ´” a ”potr ˇeba architektura ´lnı ´ koherence” (Mills asi 1970) - organizace ty ´mu typu ”chirurgicky ´ ty ´m” (surgical team) - vy ´konny ´ programa ´tor = s ˇe ´f ty ´mu, me ˇl by mı ´t moz ˇnost 100% pracovat na na ´vrhu a ko ´dova ´nı ´ - ostatnı ´ c ˇlenove ´ ty ´mu mu poma ´hajı ´, aby se nemusel zaby ´vat rutinnı ´mi ve ˇcmi - pro 10 c ˇlenny ´ ty ´m napr ˇ. tyto role: . s ˇ´ efprograma ´tor - navrhuje architekturu a pı ´s ˇe ko ´d . kopilot - poma ´ha ´ s ˇe ´fprograma ´torovi a slouz ˇı ´ coby hla ´sna ´ trouba . administra ´tor - management lidı ´, pene ˇz, prostoru, zar ˇı ´zenı ´ atd. . redaktor - rediguje dokumentaci, kterou musı ´ psa ´t s ˇe ´fprograma ´tor . sekreta ´r ˇky - administra ´tor i redaktor je potr ˇebujı ´ . archiva ´r ˇ (program clerk) - archivuje ko ´d i dokumentaci . toolsmith - vytva ´r ˇı ´ jake ´koli na ´stroje, ktere ´ s ˇe ´fprograma ´tor potr ˇebuje . tester - testuje ko ´d s ˇe ´fprograma ´tora . jazykovy ´ pra ´vnı ´k (language lawyer) - externista, ktery ´ mu ˚z ˇe ˇ´ s efprograma ´torovi poradit s programovacı ´m jazykem (modernı ´ programovacı ´ jazyky jsou jednodus ˇs ˇı ´ nez ˇ PL/1 - v souc ˇasnosti asi nebude zapotr ˇebı ´ jazykovy ´ pra ´vnı ´k, ale znalec knihoven by se mohl uplatnit) - dnes uz ˇ je mnoho uvedeny ´ch fcı ´ automatizovatelny ´ch - je moz ˇny ´ mens ˇı ´ ty ´m, ale za ´kladnı ´ mys ˇlenka sta ´le platı ´ * co kdyz ˇ ma ´me ve ˇts ˇı ´ projekt? - musı ´me organizovat jako hierarchii - na nejniz ˇs ˇı ´ ´ urovni mnoho maly ´ch ty ´mu ˚, kaz ˇdy ´ veden s ˇe ´fprograma ´torem - skupiny ty ´mu ˚ musejı ´ by ´t koordinova ´ny managerem - ze zkus ˇenosti vyply ´va ´, z ˇe kaz ˇdy ´ c ˇlove ˇk, ktere ´ho r ˇı ´dı ´te, va ´s stojı ´ 10% c ˇasu => manager na plny ´ ´ uvazek pro kaz ˇdou skupinu 10 ty ´mu ˚ - tito manaz ˇer ˇi musejı ´ by ´t r ˇı ´zeni... az ˇ 3 ´ urovne ˇ Pozna ´mka (rizika chirurgicke ´ho ty ´mu pro s ˇkolnı ´ ´ ulohy): Ustanovenı ´ efektivnı ´ho chirurgicke ´ho ty ´mu vyz ˇaduje talentovane ´ho programa ´tora (ktery ´ch je ma ´lo) a c ˇas (ktery ´ nema ´te) a i pote ´ ma ´ urc ˇita ´ rizika (ty ´kajı ´ se zejme ´na rolı ´ ostatnı ´ch c ˇlenu ˚ ty ´mu). Proto chirurgicky ´ ty ´m nedoporuc ˇuji napr ˇ. pro r ˇes ˇenı ´ za ´poc ˇtovy ´ch ´ uloh. [] * Brooks popisuje pozorova ´nı ´, z ˇe vy ´s ˇe uvedeny ´m stromem neprocha ´zejı ´ dobr ˇe ˇpatne s ´ zpra ´vy (tzv. ”bad news diode”) - z ˇa ´dny ´ s ˇe ´fprograma ´tor ani manager nebude chtı ´t r ˇı ´ci nadr ˇı ´zene ´mu, z ˇe ma ´ zpoz ˇde ˇnı ´ 4 me ˇsı ´ce a deadline nenı ´ moz ˇne ´ stihnout (nositele ´ s ˇpatny ´ch zpra ´v obvykle nejsou vı ´ta ´ni) - vy ´sledek - vrcholovy ´ management se obtı ´z ˇne ˇ dozvı ´da ´ o skutec ˇne ´m stavu projektu Role zkus ˇenosti ............... * pro projekt je du ˚lez ˇite ´ mı ´t zkus ˇene ´ na ´vrha ´r ˇe * Brooks ukazuje, z ˇe ve ˇts ˇina chyb nenı ´ v ko ´du, ale v na ´vrhu - programa ´tor ˇi spra ´vne ˇ naprogramujı ´ to, co se jim r ˇeklo, ale co se jim r ˇeklo (ne ˇkdy ani ner ˇeklo), je chybne ˇ * proto navrhuje mı ´sto klasicke ´ho vodopa ´dove ´ho modelu: - napsat hlavnı ´ program, ktery ´ bude volat top-level procedury (ktere ´ jsou na zac ˇa ´tku pra ´zdne ´) - postupne ˇ pr ˇida ´vat moduly do cele ´ho syste ´mu
5
Za´klady softwarove´ho inzˇeny´rstvı´
6
- vy ´sledek - testova ´nı ´ integrace syste ´mu se de ˇje kontinua ´lne ˇ, chyby v na ´vrhu se projevı ´ dr ˇı ´ve * ne ˇjaka ´ (mala ´) zkus ˇenost ty ´mu je nebezpec ˇna ´ - viz tzv. efekt druhe ´ho syste ´mu (second systems effect) - prvnı ´ produkt ty ´mu obvykle by ´va ´ minima ´lnı ´, protoz ˇe na ´vrha ´r ˇi majı ´ obavy, aby produkt vu ˚bec vytvor ˇili - produkt pracuje, na c ˇleny ty ´mu to ude ˇla ´ dojem - pr ˇi vytva ´r ˇenı ´ druhe ´ho syste ´mu zahrnou vs ˇe, co pr ˇi vytva ´r ˇenı ´ prvnı ´ho produktu vynechali => vy ´sledek - druhy ´ syste ´m je nafoukly ´, nevy ´konny ´ atd. - pr ˇi vytva ´r ˇenı ´ tr ˇetı ´ho syste ´mu uz ˇ si ope ˇt da ´vajı ´ pozor
Pr ˇı ´klad (v OS): * prvnı ´ syste ´m se sdı ´lenı ´m c ˇasu CTSS - minima ´lnı ´ funkc ˇnost * na ´slednı ´k MULTICS - pr ˇı ´lis ˇ ambicio ´znı ´, verze kterou se po letech podar ˇilo dokonc ˇit se pr ˇı ´lis ˇ neujala * tr ˇetı ´ syste ´m UNIX - pec ˇlivy ´ vy ´be ˇr vlastnostı ´, ´ uspe ˇs ˇne ˇjs ˇı ´. ”No Silver Bullet” .................. * Brooks napsal take ´ du ˚lez ˇity ´ c ˇla ´nek nazvany ´ ”No Silver Bullet” (1986) (legendy tvrdı ´, z ˇe vlkodlaka lze zastr ˇelit pouze str ˇı ´brnou kulkou) * tvrdı ´, z ˇe z ˇa ´dna ´ technologie nebo technika managementu nezpu ˚sobı ´ do 10 let r ˇa ´dove ´ zleps ˇenı ´ produktivity vy ´voje SW - a me ˇl pravdu * ru ˚ zne ´ ve ˇci, ktere ´ byly povaz ˇova ´ny za ”silver bullet”: - leps ˇı ´ vysokou ´rovn ˇove ´ jazyky - objektove ˇ orientovane ´ programova ´nı ´ - ume ˇla ´ inteligence a expertnı ´ syste ´my - graficke ´ programova ´nı ´ - verifikace programu ˚ - prostr ˇedı ´ pro tvorbu programu ˚ * spı ´s ˇe se zda ´, z ˇe budou postupna ´ vyleps ˇenı ´ (Konec povı ´da ´nı ´ o Brooksove ˇ knı ´z ˇce.)
Softwarovy ´ proces ================= * SW proces = mnoz ˇina aktivit a (mezi)vy ´sledku ˚ (artefaktu ˚), jejichz ˇ vy ´sledkem je SW produkt * existujı ´ ru ˚zne ´ SW procesy - velka ´ ru ˚znorodost vytva ´r ˇene ´ho SW => pro ru ˚zne ´ typy syste ´mu ˚ vhodne ´ rozdı ´lne ´ procesy - do ´ uvahy je tr ˇeba vzı ´t ru ˚zne ´ schopnosti (znalosti, dovednosti) zu ´c ˇastne ˇny ´ch lidı ´ . napr ˇı ´klad pro Boehmu ˚v spira ´lovy ´ model potr ˇebujeme lidi, kter ˇı ´ majı ´ dostatek zkus ˇenostı ´ pro prova ´de ˇnı ´ analy ´zy rizik * nicme ´ne ˇ ve vs ˇech SW procesech se objevujı ´ 4 za ´kladnı ´ aktivity: - specifikace SW = urc ˇenı ´ poz ˇadovane ´ funkc ˇnosti a definice omezenı ´ - vy ´voj SW = tvorba SW spln ˇujı ´cı ´ho specifikaci - validace SW = ove ˇr ˇenı ´, z ˇe SW de ˇla ´, co poz ˇaduje za ´kaznı ´k - evoluce SW = pr ˇizpu ˚sobenı ´ SW me ˇnı ´cı ´m se poz ˇadavku ˚m za ´kaznı ´ka * ru ˚ zne ´ SW procesy organizujı ´ tyto 4 aktivity ru ˚zny ´m zpu ˚sobem (ru ˚zne ´ c ˇasova ´nı ´ apod.) Modely SW procesu ................. * model neboli paradigma SW procesu = zobecne ˇny ´ popis procesu, resp. popis procesu z urc ˇite ´ho pohledu
zswi/p1proc.d
zswi/p1proc.d
3. ledna 2005
7
* nynı ´ uvedeme nejpouz ˇı ´vane ˇjs ˇı ´ obecne ´ modely SW procesu * vodopa ´dovy ´ model (waterfall model) - vy ´s ˇe uvedene ´ 4 aktivity cha ´pe jako samostatne ´ fa ´ze procesu - po splne ˇnı ´ se fa ´ze ukonc ˇı ´ a pr ˇecha ´zı ´ se na dals ˇı ´ * evoluc ˇnı ´ vy ´voj - aktivity specifikace, vy ´voje a validace jsou smı ´s ˇeny - ze specifikace je velmi rychle vyvinut prvotnı ´ syste ´m - na za ´klade ˇ poz ˇadavku ˚ za ´kaznı ´ka je syste ´m da ´le upravova ´n - pak mu ˚z ˇe by ´t syste ´m pr ˇeda ´n nebo reimplementova ´n strukturovane ˇjs ˇı ´m zpu ˚ sobem (pro snazs ˇı ´ ´ udrz ˇbu) * forma ´lnı ´ transformace - na poc ˇa ´tku je vytvor ˇena abstraktnı ´ forma ´lnı ´ (matematicka ´) specifikace syste ´mu - tato specifikace je postupne ˇ transformova ´na do funkc ˇnı ´ho programu - transformace zachova ´vajı ´ spra ´vnost, tj. na konci vı ´me, z ˇe program odpovı ´da ´ specifikaci * sestavenı ´ syste ´mu ze znovupouz ˇitelny ´ch (reusable) komponent - pr ˇedpokla ´da ´, z ˇe c ˇa ´sti syste ´mu jiz ˇ existujı ´ - vy ´voj syste ´mu se zame ˇr ˇuje na integraci te ˇchto c ˇa ´stı ´ (mı ´sto toho, aby se vyvı ´jely znovu) * iterativnı ´ modely - inkrementa ´lnı ´ vy ´voj a spira ´love ´ modely - hybridnı ´ modely, umoz ˇn ˇujı ´ pouz ˇı ´t ru ˚zne ´ pr ˇı ´stupy pro ru ˚zne ´ c ˇa ´sti syste ´mu Neexistuje ne ˇjaky ´ ”nejspra ´vne ˇjs ˇı ´” model, ru ˚zne ´ modely jsou vhodne ´ pro ru ˚zne ´ situace. V praxi se nejc ˇaste ˇji pouz ˇı ´vajı ´ SW procesy zaloz ˇene ´ na vodopa ´dove ´m modelu a evoluc ˇnı ´m vy ´voji. Forma ´lnı ´ metody byly v ne ˇkolika projektech ´ uspe ˇs ˇne ˇ pouz ˇity, zatı ´m ale nejsou pr ˇı ´lis ˇ rozs ˇı ´r ˇene ´ - rozs ˇı ´r ˇenı ´ lze c ˇekat spı ´s ˇe v budoucnu pro vy ´voj distribuovany ´ch syste ´mu ˚. Ve ˇts ˇina SW procesu ˚ zatı ´m nenı ´ explicitne ˇ orientova ´na na vyva ´r ˇenı ´ syste ´mu ˚ z existujı ´cı ´ch komponent; i v tom se da ´ oc ˇeka ´vat zme ˇna. Zajı ´mave ´ jsou hybridnı ´ modely, protoz ˇe umoz ˇn ˇujı ´ realizovat podsyste ´my podle nejvhodne ˇjs ˇı ´ho modelu (odpovı ´dajı ´ potr ˇebe ˇ tvorby velmi rozsa ´hly ´ch syste ´mu ˚). Vodopa ´dovy ´ model vy ´voje SW .......................... * nejstars ˇı ´ publikovany ´ model (Royce 1970)
analýza domény & def. požadavků
návrh systému a návrh SW
implementace & testování jednotek
integrace & testování systému
provoz a údržba
Za ´kladnı ´ aktivity jsou: * analy ´za dome ´ny, zı ´ska ´va ´nı ´ (sbe ˇr) a definice poz ˇadavku ˚ - analy ´za dome ´ny = sezna ´menı ´ s s ˇirs ˇı ´m (napr ˇ. obchodnı ´m) kontextem syste ´mu . pojem ”dome ´na” zde znamena ´ obor, ktere ´ho se proble ´m ty ´ka ´ - zı ´ska ´va ´nı ´ poz ˇadavku ˚ = konzultacı ´ s uz ˇivateli syste ´mu se zjistı ´ cı ´le, poz ˇadovane ´ sluz ˇby a omezenı ´ kladena ´ na syste ´m - definice poz ˇadavku ˚ = vy ´s ˇe uvedene ´ cı ´le, sluz ˇby atd. jsou podrobne ˇ definova ´ny v dokumentu specifikace poz ˇadavku ˚ (DSP), ktery ´ slouz ˇı ´ jako specifikace vytva ´r ˇene ´ho syste ´mu * na ´vrh syste ´mu a na ´vrh SW (angl. system & software design) - na ´vrh syste ´mu rozde ˇlı ´ celkove ´ poz ˇadavky na poz ˇadavky na HW a poz ˇadavky na SW, urc ˇı ´ celkovou architekturu syste ´mu - na ´vrh SW zahrnuje identifikaci a popis za ´kladnı ´ch abstrakcı ´ a jejich vztahu ˚ (c ˇasto pomocı ´ graficke ´ notace, napr ˇ. UML)
Za´klady softwarove´ho inzˇeny´rstvı´
8
zswi/p1proc.d
* implementace a testova ´nı ´ modulu ˚ - design je realizova ´n jako mnoz ˇina modulu ˚, tr ˇı ´d, pr ˇı ´padne ˇ programu ˚ - testova ´nı ´ jednotek = ove ˇr ˇenı ´, z ˇe kaz ˇdy ´ modul odpovı ´da ´ specifikaci modulu * integrace a testova ´nı ´ syste ´mu - jednotlive ´ moduly jsou sestaveny do vy ´sledne ´ho syste ´mu - ´ uplny ´ syste ´m je otestova ´n na shodu se specifikacı ´ - po otestova ´nı ´ je syste ´m pr ˇeda ´n za ´kaznı ´kovi * provoz a ´ udrz ˇba - nejdels ˇı ´ fa ´ze z ˇivotnı ´ho cyklu - syste ´m se prakticky pouz ˇı ´va ´ - ´ udrz ˇba = oprava chyb programu a designu, ktere ´ nebyly odhaleny v pr ˇedchozı ´ch fa ´zı ´ch + rozs ˇir ˇova ´nı ´ syste ´mu podle novy ´ch poz ˇadavku ˚ + zleps ˇova ´nı ´ implementace Pozna ´mka (pojem ´ udrz ˇba) Pojmem ”u ´drz ˇba” (angl. maintenance) se v SW inz ˇeny ´rstvı ´ nemı ´nı ´ administrace syste ´mu, ale zme ˇny software vynucene ´ provozem syste ´mu. [] Teoreticky by dals ˇı ´ fa ´ze procesu neme ˇla zac ˇı ´t, dokud nenı ´ pr ˇedchozı ´ fa ´ze dokonc ˇena; v praxi: * be ˇhem designu jsou odhaleny proble ´my s poz ˇadavky, be ˇhem ko ´dova ´nı ´ proble ´my s designem apod. * proto SW proces nenı ´ linea ´rnı ´ sekvence - ve skutec ˇnosti se musı ´me vracet (na obra ´zku naznac ˇeno c ˇerchovane ˇ) - ve ˇts ˇinou se vracı ´me o 1 fa ´zi - ´ udrz ˇba zpu ˚sobuje zme ˇny v urc ˇite ´ fa ´zi, da ´le se pokrac ˇuje podle vodopa ´dove ´ho modelu * vy ´s ˇe zmı ´ne ˇne ´ iterace jsou drahe ´ a pracne ´ (zahrnujı ´ pr ˇepracova ´nı ´ a schvalova ´nı ´ dokumentu ˚) * v praxi proto c ˇasto dojde po ne ˇkolika iteracı ´ch ke zmraz ˇenı ´ pr ˇı ´slus ˇne ´ c ˇa ´sti vy ´voje (napr ˇ. zmraz ˇenı ´ specifikace) a pr ˇejde se na dals ˇı ´ fa ´zi - proble ´my jsou tı ´m ”odloz ˇeny na pozde ˇji”, c ˇili fakticky ignorova ´ny - zmraz ˇenı ´ poz ˇadavku ˚ c ˇasto vede k tomu, z ˇe syste ´m nede ˇla ´, co uz ˇivatel chce - zmraz ˇenı ´ designu obvykle vede ke s ˇpatne ˇ strukturovany ´m syste ´mu ˚m (proble ´my designu se pak pr ˇi implementaci obcha ´zejı ´ ru ˚zny ´mi triky, ktere ´ ztı ´z ˇı ´ dals ˇı ´ vy ´voj - ”informac ˇnı ´ sklero ´za”) Proble ´my vodopa ´dove ´ho modelu: * rozde ˇlenı ´ projektu do fa ´zı ´ je ma ´lo flexibilnı ´ - je obtı ´z ˇne ´ reagovat na zme ˇny poz ˇadavku ˚ ze strany za ´kaznı ´ka - proto je vodopa ´dovy ´ model vhodny ´ pouze, pokud je proble ´m dobr ˇe zna ´my ´ (= jsme schopni zı ´skat korektnı ´ specifikaci) - proble ´my s vodopa ´dovy ´m modelem vedly k formulaci alternativnı ´ch modelu ˚
Pozna ´mka (odlis ˇnosti v literatur ˇe) Protoz ˇe SW inz ˇeny ´rstvı ´ je relativne ˇ mlady ´ obor, najdeme v ru ˚zne ´ literatur ˇe popisujı ´cı ´ tote ´z ˇ te ´ma znac ˇne ´ odlis ˇnosti (vyjma oblastı ´, ktere ´ jsou jiz ˇ standardizova ´ny). Napr ˇ. porovnejte prvnı ´ zmı ´nku o vodopa ´dove ´m modelu uvedenou v souvislosti s Brooksovo knihou s vy ´s ˇe uvedeny ´m a s na ´sledujı ´cı ´m obra ´zkem:
system requirements architectural detailed specification analysis design design
coding and debugging
unit testing
system testing
maintenance
retire
zswi/p1proc.d
3. ledna 2005
9
Rozde ˇlenı ´ do jednotlivy ´ch fa ´zı ´ mu ˚z ˇeme nazvat ru ˚zne ˇ, principy ovs ˇem zu ˚sta ´vajı ´ tyte ´ˇ z. [] Evoluc ˇnı ´ modely vy ´voje SW ......................... * za ´kladnı ´ mys ˇlenka: - vytvor ˇit poc ˇa ´tec ˇnı ´ implementaci - vystavit jı ´ komenta ´r ˇ˚ um uz ˇivatele - postupne ˇ vyleps ˇovat pr ˇes meziverze dokud nedostaneme adekva ´tnı ´ vy ´sledek * fa ´ze specifikace, vy ´voje a validace neprobı ´hajı ´ vz ˇdy sekvenc ˇne ˇ, ale mohou probı ´hat i paralelne ˇ, mezi fa ´zemi je zpe ˇtna ´ vazba * existujı ´ 2 za ´kladnı ´ typy modelu ˚ evoluc ˇnı ´ho vy ´voje SW: 1. model vy ´zkumnı ´k (exploratory development, tj. pru ˚zkumny ´ vy ´voj) - cı ´lem je spolupracovat se za ´kaznı ´kem na zjis ˇte ˇnı ´ jeho poz ˇadavku ˚, abychom mu nakonec dodali poz ˇadovany ´ syste ´m - vy ´voj obvykle zac ˇı ´na ´ dobr ˇe srozumitelny ´mi c ˇa ´stmi syste ´mu - syste ´m se vyvı ´jı ´ pr ˇida ´va ´nı ´m novy ´ch vlastnostı ´ navrhovany ´ch za ´kaznı ´kem 2. model prototyp (throw-away prototyping, tj. doslova tvorba prototypu, ktery ´ bude zahozen) - cı ´lem je leps ˇı ´ pochopenı ´ za ´kaznı ´kovy ´ch poz ˇadavku ˚ a v du ˚sledku vytvor ˇenı ´ leps ˇı ´ definice poz ˇadavku ˚ na syste ´m - tvorba prototypu se zame ˇr ˇuje na ty c ˇa ´sti poz ˇadavku ˚ za ´kaznı ´ka, ktery ´m moc nerozumı ´me
sběr a analýza požadavků
rychlý návrh prototypu návrh
vyhodnocení prototypu
specifikace požadavků
implementace integrace
návrh a implementace systému
* vy ´hody evoluc ˇnı ´ho vy ´voje SW - c ˇasto vede efektivne ˇji nez ˇ vodopa ´dovy ´ model k syste ´mu spln ˇujı ´cı ´mu bezprostr ˇednı ´ poz ˇadavky za ´kaznı ´ka - specifikace mu ˚z ˇe by ´t vytva ´r ˇena postupne ˇ - za ´kaznı ´k vidı ´, z ˇe se ne ˇco de ˇje (na rozdı ´l od vodopa ´du, kde produkt vidı ´ az ˇ na konci) * proble ´my: - proces nenı ´ viditelny ´: manaz ˇer ˇi nemohou me ˇr ˇit postup vy ´voje (na rozdı ´l napr ˇ. od vodopa ´dove ´ho modelu) - syste ´my vyva ´r ˇene ´ evoluc ˇne ˇ jsou c ˇasto s ˇpatne ˇ strukturovane ´ . neusta ´le ´ zme ˇny vedou k porus ˇenı ´ struktury syste ´mu . vy ´voj dals ˇı ´ch verzı ´ se postupne ˇ sta ´va ´ obtı ´z ˇne ˇjs ˇı ´ = draz ˇs ˇı ´ - prototypova ´nı ´ mu ˚z ˇe vyz ˇadovat specia ´lnı ´ na ´stroje a techniky . vy ´stup mu ˚z ˇe by ´t problematicky ´, napr ˇ. nekompatibilnı ´ s jiny ´mi na ´stroji a technikami * tj. vhodne ´ bud’ pro male ´ syste ´my (do 100 000 r ˇa ´dku ˚ ko ´du), nebo pro str ˇedne ˇ velke ´ syste ´my (do 500 000 r ˇa ´dku ˚ ) s kra ´tkou dobou z ˇivota * ve velky ´ch syste ´mech by evoluc ˇnı ´ vy ´voj pu ˚sobil zr ˇetelne ´ proble ´my, ale je moz ˇne ´ pouz ˇı ´t smı ´s ˇeny ´ pr ˇı ´stup: - s ˇpatne ˇ srozumitelne ´ c ˇa ´sti - throw-away prototyping => zpr ˇesne ˇnı ´ DSP - dobr ˇe srozumitelne ´ c ˇa ´sti - vodopa ´dovy ´ model - uz ˇivatelske ´ rozhranı ´ - model vy ´zkumnı ´k
Za´klady softwarove´ho inzˇeny´rstvı´
10 Forma ´lnı ´ modely vy ´voje SW .........................
* urc ˇity ´m zpu ˚sobem podobne ´ vodopa ´dove ´mu modelu * na poc ˇa ´tku je vytvor ˇena specifikace poz ˇadavku ˚ * ta je zpr ˇesne ˇna do podrobne ´ forma ´lnı ´ specifikace syste ´mu (pojmem forma ´lnı ´ se zde mı ´nı ´ ”matematicka ´”) * postupne ´ zpr ˇesn ˇova ´nı ´ specifikace forma ´lnı ´mi transformacemi * konec ˇny ´m vy ´sledkem ma ´ by ´t spustitelny ´ program
definice požadavků
formální T1 specifikace
formální transformace T2 T3 R1 R2 R3
T4 spustitelný program
* v kaz ˇde ´m kroku se pr ˇida ´vajı ´ podrobnosti, ale mu ˚z ˇeme doka ´zat, z ˇe odpovı ´da ´ reprezentaci syste ´mu z pr ˇedchozı ´ho kroku * pokud neude ˇla ´me chybu, pak vy ´sledek (dokazatelne ˇ) odpovı ´da ´ specifikaci * proces designu, implementace a testova ´nı ´ jednotek je tedy nahrazen forma ´lnı ´mi transformacemi * doka ´zat korespondenci transformacı ´ je obtı ´z ˇne ´ a lze pr ˇi tom ude ˇlat chybu * proto jsou v praxi mnohem oblı ´bene ˇjs ˇı ´ forma ´lnı ´ metody, pro ktere ´ existuje podpu ˚rny ´ SW - model checkers, theorem provers (”dokazovac ˇe hypote ´z”) * pr ˇı ´klady metod forma ´lnı ´ho vy ´voje SW: Cleanroom (IBM cca 1987), metody zaloz ˇene ´ na jazycı ´ch B a Z * pr ˇı ´klad c ˇ´ asti jednoduche ´ forma ´lnı ´ specifikace v modula ´rnı ´m specifikac ˇnı ´m jazyce zaloz ˇene ´m na tempora ´lnı ´ch logika ´ch: module Prˇ´ıkladCˇ´ıtacˇe EXTENDS Naturals VARIABLES cnt, Cˇ´ıtacˇ. retval Na´vratova´ hodnota. ∆
TypeInvariantC = cnt ∈ Nat ∆
InitC = cnt = 0
Novy´ cˇ´ıtacˇ se nastavı´ na nulu.
INTERFACE ∆
cntget = Zveˇtsˇ´ı cˇ´ıtacˇ a vracı´ jeho pu˚vodnı´ hodnotu. ∧ cnt’ = cnt + 1 Zveˇtsˇ´ıme cˇ´ıtacˇ ∧ retval’ = cnt a nastavı´me na´vratovou hodnotu. THEOREM SpecC ⇒ 2TypeInvariantC
Typova´ spra´vnost specifikace.
* vyuz ˇitı ´ zejme ´na tam, kde je tr ˇeba doka ´zat za ´kaznı ´kovi bezpec ˇnost, spolehlivost syste ´mu apod. * cena vy ´voje srovnatelna ´ s jiny ´mi pr ˇı ´stupy Nevy ´hody: * vyz ˇaduje specializovane ´ znalosti - vy ´be ˇr transformace vyz ˇaduje urc ˇitou zkus ˇenost, ktera ´ se lis ˇı ´ od klasicke ´ho programova ´nı ´ * ne ˇkdy vyz ˇaduje transformaci do specia ´lnı ´ho programovacı ´ho jazyka (c ˇasto c ˇı ´m niz ˇs ˇı ´ programovacı ´ jazyk, tı ´m obtı ´z ˇne ˇjs ˇı ´ pr ˇevod) * z uvedeny ´ch du ˚vodu ˚ se v praxi pr ˇı ´lis ˇ nepouz ˇı ´va ´
Vy ´voj orientovany ´ na znovupouz ˇitelne ´ komponenty ............................................... * ve ve ˇts ˇine ˇ SW projektu ˚ se stane, z ˇe vy ´voja ´r ˇi znajı ´ design nebo ko ´d podobny ´ tomu, ktery ´ se poz ˇaduje
zswi/p1proc.d
zswi/p2xp.d
3. ledna 2005
11
* vezmou, upravı ´ a zac ˇlenı ´ do sve ´ho syste ´mu * de ˇje se neza ´visle na modelu vy ´voje SW * v poslednı ´ch letech se objevuje novy ´ zpu ˚sob vy ´voje - component-based SWE * vy ´voj se spole ´ha ´ na velkou mnoz ˇinu SW komponent a ne ˇjaky ´ ra ´mec pro jejich integraci - komponentou mu ˚z ˇe by ´t napr ˇ. knihovnı ´ fce, tr ˇı ´da, podsyste ´m, aplikace (napr ˇ. Mozilla pro prohlı ´z ˇenı ´ na ´pove ˇdy) - ra ´mec - napr ˇ. pr ˇı ´kazove ´ jazyky (Tcl/tk), distribuovane ´ objektove ´ architektury (CORBA, JavaBeans) apod. * komponentove ˇ orientovany ´ proces vy ´voje postupne ˇ: - specifikace poz ˇadavku ˚ - analy ´za komponent - modifikace poz ˇadavku ˚ - design syste ´mu s vyuz ˇitı ´m komponent - vy ´voj a integrace - validace syste ´mu * zatı ´mco prvnı ´ a poslednı ´ fa ´ze obdobna ´ jako v ostatnı ´ch procesech, ostatnı ´ fa ´ze se lis ˇı ´ * analy ´za komponent - podle specifikace poz ˇadavku ˚ vyhleda ´va ´me komponenty, ktere ´ specifikaci spln ˇujı ´ - obvykle jı ´ ale nespln ˇujı ´ pr ˇesne ˇ, resp. poskytujı ´ pouze c ˇa ´st poz ˇadovany ´ch funkcı ´ - vy ´sledkem je informace o komponenta ´ch * modifikace poz ˇadavku ˚ - analyzujeme poz ˇadavky a modifikujeme je tak, aby odra ´z ˇely dostupne ´ komponenty - pokud modifikace nenı ´ moz ˇna ´, vra ´tı ´me se k analy ´ze komponent se snahou najı ´t alternativnı ´ r ˇes ˇenı ´ * design syste ´mu s vyuz ˇitı ´m komponent - be ˇhem te ´to fa ´ze je navrz ˇen ra ´mec syste ´mu nebo se vyuz ˇije uz ˇ existujı ´cı ´ ra ´mec - pokud neexistuje poz ˇadovana ´ komponenta, musı ´ se navrhnout * vy ´voj a integrace - vytvor ˇı ´me komponenty, ktere ´ nema ´me (a nemu ˚z ˇeme koupit atd.) - komponenty jsou integrova ´ny do syste ´mu * tento model vy ´voje SW omezuje mnoz ˇstvı ´ SW, ktery ´ musı ´me vyvinout => snı ´z ˇenı ´ ceny a omezenı ´ nebezpec ˇı ´, z ˇe nastanou potı ´z ˇe * obvykle take ´ rychleji zı ´ska ´me vy ´sledny ´ SW * nevy ´hody: - kompromisy vu ˚c ˇi poz ˇadavku ˚m jsou nevyhnutelne ´ => syste ´m nakonec nemusı ´ spln ˇovat poz ˇadavky za ´kaznı ´ka - vy ´voj nenı ´ zcela v nas ˇich ruka ´ch, protoz ˇe nove ´ verze komponent vyvı ´jı ´ ne ˇkdo jiny ´ nez ˇ my (vy ´voj mu ˚z ˇe by ´t ukonc ˇen, nove ´ verze komponenty nemusejı ´ by ´t kompatibilnı ´ se stary ´mi verzemi) => ´ udrz ˇba syste ´mu se mu ˚z ˇe prodraz ˇit - ra ´mce a knihovny komponent by ´vajı ´ tak rozsa ´hle ´, z ˇe sezna ´menı ´ s nimi mu ˚z ˇe vyz ˇadovat ne ˇkolik me ˇsı ´cu ˚ (ve velky ´ch organizacı ´ch by ´vajı ´ urc ˇeni specializovanı ´ pracovnı ´ci)
❉
Za´klady softwarove´ho inzˇeny´rstvı´
12
zswi/p2xp.d
KIV/ZSWI 2004/2005 Pr ˇedna ´s ˇka 2 Du ˚ vody proc ˇ (ve ˇts ˇinou) nefunguje vodopa ´dovy ´ model (Parnas a Clemens, 1986): * uz ˇivatele ´ syste ´mu zr ˇı ´dka ve ˇdı ´ co pr ˇesne ˇ chte ˇjı ´ a co ve ˇdı ´ neume ˇjı ´ vyja ´dr ˇit, * i kdybychom mohli vyja ´dr ˇit vs ˇechny poz ˇadavky, na ne ˇktere ´ datily pr ˇijdeme az ˇ ve fa ´zi implementace, * i kdybychom znali vs ˇechny detaily, jako lide ´ neumı ´me s tak sloz ˇity ´mi ve ˇcmi nakla ´dat, * i kdybychom s nimi ume ˇli nakla ´dat, vne ˇjs ˇı ´ sı ´ly vedou ke zme ˇna ´m poz ˇadavku ˚, ne ˇktere ´ z nich vedou ke zrus ˇenı ´ platnosti dr ˇı ´ve ˇjs ˇı ´ch rozhodnutı ´. Iterativnı ´ modely vy ´voje SW --------------------------* vs ˇechny dr ˇı ´ve uvedene ´ modely SW procesu majı ´ sve ´ vy ´hody a nevy ´hody * pro tvorbu ve ˇts ˇiny velky ´ch syste ´mu ˚ je potr ˇeba pouz ˇı ´vat ru ˚zne ´ pr ˇı ´stupy pro ru ˚zne ´ c ˇa ´sti (napr ˇ. podsyste ´my) => hybridnı ´ modely * pokud se poz ˇadavky vyvı ´jejı ´ => nutnost iterace c ˇa ´stı ´ procesu * model by me ˇl vy ´s ˇe uvedene ´ potr ˇeby odra ´ˇ zet - proto uvedu 2 modely navrz ˇene ´ specia ´lne ˇ pro iterativnı ´ procesy vy ´voje - inkrementa ´lnı ´ vy ´voj SW (Lehman 1969, Mills 1980) - spira ´lovy ´ model vy ´voje (Boehm 1988) a WinWin spira ´lovy ´ model (Boehm a Bose, 1994) Inkrementa ´lnı ´ vy ´voj ................... * c ˇesky c ˇasto nazy ´va ´n ”pr ˇı ´ru ˚stkovy ´ model” * byl navrz ˇen jako zpu ˚ sob, jak omezit pr ˇepracova ´va ´nı ´ c ˇa ´stı ´ v du ˚sledku zme ˇn poz ˇadavku ˚ (inkrement = maly ´ pr ˇı ´davek) * ne ˇkdy umoz ˇn ˇuje za ´kaznı ´kovi odloz ˇit rozhodnutı ´ o detailnı ´ch poz ˇadavcı ´ch, dokud nezı ´ska ´ zkus ˇenost se syste ´mem * proces vypada ´ v za ´sade ˇ takto: - definujı ´ se pr ˇehledove ´ poz ˇadavky - poz ˇadavky se pr ˇir ˇadı ´ jednotlivy ´m inkrementu ˚m - navrhne se architektura syste ´mu - opakovane ˇ pro kaz ˇdy ´ inkrement, dokud nevytvor ˇı ´me fina ´lnı ´ syste ´m: vyvineme a validujeme inkrement, integrujeme inkrement a validujeme syste ´m.
definice požadavků
rychlé iterace, každý inkrement schválen klientem
přiřazení požadavků inkrementům
architektura systému
návrh implementace integrace
provoz
* na zac ˇa ´tku za ´kaznı ´k identifikuje pr ˇehledove ˇ sluz ˇby, ktere ´ od syste ´mu poz ˇaduje * urc ˇı ´, ktere ´ sluz ˇby jsou pro ne ˇj nejdu ˚ lez ˇite ˇjs ˇ´ ı a ktere ´ jsou nejme ´ne ˇ du ˚lez ˇite ´ * pak je definova ´na mnoz ˇina inkrementu ˚, kaz ˇdy ´ inkrement poskytuje podmnoz ˇinu celkove ´ funkc ˇnosti * alokace sluz ˇeb do inkrementu ˚ za ´visı ´ na priorite ˇ sluz ˇby * nejdu ˚lez ˇite ˇjs ˇı ´ sluz ˇby majı ´ by ´t za ´kaznı ´kovi pr ˇeda ´ny jako prvnı ´ * v dals ˇı ´m kroku jsou detailne ˇ specifikova ´ny poz ˇadavky na prvnı ´ inkrement * inkrement je vytvor ˇen nejvhodne ˇjs ˇı ´m procesem; be ˇhem vy ´voje nejsou akceptova ´ny zme ˇny poz ˇadavku ˚ na vytva ´r ˇeny ´ inkrement * spolu s prvnı ´m inkrementem mohou by ´t implementova ´ny spolec ˇne ´ sluz ˇby syste ´mu (ne ˇkdy lze spolec ˇne ´ sluz ˇby vytva ´r ˇet take ´ inkrementa ´lne ˇ)
zswi/p2xp.d
3. ledna 2005
* paralelne ˇ s vy ´vojem mu ˚z ˇe probı ´hat analy ´za poz ˇadavku ˚ pro dals ˇı ´ inkrementy * po dokonc ˇenı ´ inkrementu mu ˚z ˇe by ´t tento pr ˇeda ´n za ´kaznı ´kovi, ktery ´ ho mu ˚z ˇe pouz ˇı ´vat - zı ´ska ´ tı ´m c ˇa ´st funkc ˇnosti syste ´mu * mu ˚z ˇe se syste ´mem experimentovat, coz ˇ mu pomu ˚z ˇe upr ˇesnit poz ˇadavky na dals ˇı ´ inkrementy nebo na nove ˇjs ˇı ´ verze pr ˇedane ´ho inkrementu * pro vy ´voj jednotlivy ´ch inkrementu ˚ se mohou pouz ˇı ´vat ru ˚zne ´ procesy - napr ˇ. pokud ma ´ inkrement dobr ˇe definovanou specifikaci => vodopa ´dovy ´ model - pokud specifikace nejasna ´ => evoluc ˇnı ´ model Vy ´hody inkrementa ´lnı ´ho pr ˇı ´stupu: * za ´kaznı ´ci nemusejı ´ c ˇekat na dokonc ˇenı ´ cele ´ho syste ´mu, aby z ne ˇj ne ˇco me ˇli * poc ˇ´ atec ˇnı ´ inkrementy jim mohou pomoci zı ´skat zkus ˇenost pro definici dals ˇı ´ch inkrementu ˚ * je mens ˇı ´ riziko celkove ´ho neu ´spe ˇchu projektu; i kdyz ˇ ne ˇktere ´ inkrementy mohou by ´t problematicke ´, je pravde ˇpodobne ´, z ˇe ve ˇts ˇina jich bude ´ uspe ˇs ˇne ˇ pr ˇeda ´na za ´kaznı ´kovi * protoz ˇe za ´kaznı ´kovi pr ˇeda ´va ´me jako prvnı ´ nejprioritne ˇjs ˇı ´ inkrementy, budou nejdu ˚lez ˇite ˇjs ˇı ´ c ˇa ´sti syste ´mu nejle ´pe otestova ´ny; jiny ´mi slovy za ´kaznı ´ka pravde ˇpodobne ˇ nepotka ´ hava ´rie nejdu ˚lez ˇite ˇjs ˇı ´ c ˇa ´sti syste ´mu Potı ´z ˇe inkrementa ´lnı ´ho modelu: * inkrementy by me ˇly by ´t relativne ˇ male ´ (do 20 000 r ˇa ´dek ko ´du), na druhou stranu by kaz ˇdy ´ inkrement me ˇl poskytovat ne ˇjakou navenek viditelnou funkc ˇnost - proto mu ˚z ˇe by ´t obtı ´z ˇne ´ namapovat poz ˇadavky za ´kaznı ´ka na inkrementy spra ´vne ´ velikosti * ve ˇts ˇina syste ´mu ˚ obsahuje mnoz ˇinu za ´kladnı ´ch sluz ˇeb, ktere ´ jsou vyz ˇadova ´ny ru ˚ zny ´mi c ˇa ´stmi syste ´mu, poz ˇadavky vs ˇak nejsou specifikova ´ny detailne ˇ, dokud se nedostaneme k jejich vy ´voji => je obtı ´z ˇne ´ identifikovat sluz ˇby potr ˇebne ´ pro vs ˇechny inkrementy - proto je pro ve ˇts ˇı ´ projekty vhodne ´ doplnit o fa ´zi analy ´zy * v souc ˇasnosti nejzna ´me ˇjs ˇı ´ metodika - Extreme Programming (Beck 1999) - metodika uzra ´la v ra ´mci syste ´mu pro vy ´platy ve firme ˇ Chrysler (1996) - vy ´voj maly ´ch inkrementu ˚, zataz ˇenı ´ za ´kaznı ´ka do procesu, pru ˚be ˇz ˇne ´ vyleps ˇova ´nı ´ ko ´du... Pozna ´mka (metodika Extreme Programming, XP) [zdroje: Beck 1999, Benda 2004] * v souc ˇasnosti nejzna ´me ˇjs ˇı ´ agilnı ´ metodika - autor jı ´ doporuc ˇuje pro pr ˇı ´pady, kdy poz ˇadavky na SW jsou va ´gnı ´ nebo se rychle me ˇnı ´ - pouz ˇitelna ´ pro male ´ ty ´my (2-10 lidı ´) ˇivotnı Z ´ cyklus v XP vypada ´ pr ˇibliz ˇne ˇ na ´sledovne ˇ: * pru ˚ zkum - v idea ´lnı ´m pr ˇı ´pade ˇ kra ´tky ´ - za ´kaznı ´k popı ´s ˇe pr ˇı ´pady pouz ˇitı ´ vytva ´r ˇene ´ho syste ´mu (use cases, v terminologii Extreme Programming jsou nazy ´va ´ny ”stories”) - vy ´voja ´r ˇi na za ´klade ˇ pr ˇı ´padu ˚ pouz ˇitı ´ odhadnou, jak dlouho bude vy ´voj trvat (pokud to pro ne ˇktery ´ pr ˇı ´pad pouz ˇitı ´ nelze odhadnout, je nutne ´ ho pr ˇepsat, rozde ˇlit, zkusit naprogramovat apod.) - vy ´voja ´r ˇi hledajı ´ alternativy pro architekturu syste ´mu (pomocı ´ prototypu ˚), identifikace rizik * pla ´nova ´nı ´ dals ˇı ´ verze - za ´kaznı ´k si vybere nejmens ˇı ´ a pro ne ˇj nejcenne ˇjs ˇı ´ mnoz ˇinu pr ˇı ´padu ˚ pouz ˇitı ´, kterou bude chtı ´t implementovat v prvnı ´ verzi - dohodnutı ´ termı ´nu pro dokonc ˇenı ´ prvnı ´ verze (me ˇlo by by ´t mezi 2-6 me ˇsı ´ci) . kra ´tke ´ cykly poskytujı ´ vc ˇas zpe ˇtnou vazbu za ´kaznı ´kovi, mu ˚z ˇe urc ˇit nebo zme ˇnit poz ˇadavky pro dals ˇı ´ cyklus - rozde ˇlenı ´ c ˇasu do 1-4 ty ´dennı ´ch iteracı ´, kaz ˇda ´ iterace ma ´ implementovat funkc ˇnost pro mnoz ˇinu pr ˇı ´padu ˚ pouz ˇitı ´
13
Za´klady softwarove´ho inzˇeny´rstvı´
14
zswi/p2xp.d
. kostra cele ´ho syste ´mu (architektura) musı ´ by ´t implementova ´na v prvnı ´ iteraci => je nutne ´ prove ´st odpovı ´dajı ´cı ´ vy ´be ˇr pr ˇı ´padu ˚ pouz ˇitı ´ * kaz ˇda ´ iterace: - rozde ˇlenı ´ pr ˇı ´padu ˚ pouz ˇitı ´ na ´ ulohy, rozde ˇlenı ´ ´ uloh mezi programa ´tory - vy ´be ˇr ´ ulohy (ve ˇts ˇinou jeden programa ´tor implementuje jeden pr ˇı ´pad pouz ˇitı ´) - vytvor ˇenı ´ testu ˚ jednotek . v XP se napr ˇed vytva ´r ˇejı ´ testy, pak teprve ko ´d, ktery ´ je testova ´n (napr ˇ. ke kaz ˇde ´ tr ˇı ´de ˇ mu ˚z ˇe existovat metoda ”test”, ktera ´ jı ´ otestuje) . testy by me ˇly prove ˇr ˇit ves ˇkerou logiku budoucı ´ho ko ´du . pr ˇi psanı ´ testu ˚ se c ˇasto vynor ˇujı ´ alternativy na ´vrhu . ne ˇkdy se uka ´z ˇe potr ˇeba globa ´lnı ´ zme ˇny v syste ´mu - refactoring problematicke ´ho ko ´du sme ˇrem k ve ˇts ˇı ´ jednoduchosti - na ´vrh a ko ´dova ´nı ´ . na ´vrh i ko ´d by me ˇly by ´t co nejjednodus ˇs ˇı ´ (pouze nynı ´ poz ˇadovane ´ vlastnosti, z ˇa ´dne ´ pr ˇedpoklady do budoucnosti - protoz ˇe poz ˇadavky za ´kaznı ´ka se budou me ˇnit) . ko ´d je povaz ˇova ´n za dokonc ˇeny ´, pokud vs ˇechny testy probe ˇhnou ´ uspe ˇs ˇne ˇ . jednoduchost na ´vrhu a testy zjednodus ˇujı ´ budoucı ´ pr ˇepracova ´nı ´ ko ´du - integrace syste ´mu, testy jednotek . dokonc ˇena ´ funkc ˇnost je integrova ´na do syste ´mu . spustı ´ se automaticke ´ testy jednotek pro cely ´ syste ´m, tı ´m zjistı ´me zda jsme omylem nezasa ´hli do funkc ˇnosti syste ´mu - funkc ˇnı ´ testy . majı ´ za ´be ˇr do vı ´ce podsyste ´mu ˚, ne ˇkdy majı ´ i manua ´lnı ´ podobu (testova ´nı ´ funkc ˇnosti syste ´mu z pohledu za ´kaznı ´ka) např. 90 dní
průzkum výjezdní zasedání
případy použití
plánování další verze
plán
složitý kód
globální změny jednoduchý kód
iterace
např. 2 týdny
plánování iterace
release
testy jednotek
další verze
návrh a kódování integrace funkční testy
* zaha ´jenı ´ projektu mu ˚z ˇe pr ˇedcha ´zet vy ´jezdnı ´ zaseda ´nı ´ (Off Site) - c ˇa ´st za ´kaznı ´ku ˚, manageru ˚, programa ´toru ˚ a testeru ˚ se sejde (napr ˇ. na ne ˇkolik dnı ´) na jednom mı ´ste ˇ a dohaduje se o co jde (rozsah projektu...) * v XP je ves ˇkery ´ ko ´d povinne ˇ psa ´n ve dvojicı ´ch (pa ´rove ´ programova ´nı ´) - jeden c ˇlen ty ´mu ko ´duje, druhy ´ mu ˚z ˇe pr ˇemy ´s ˇlet strategic ˇte ˇji (napr ˇ. doplne ˇnı ´ chybe ˇjı ´cı ´ch testu ˚ , zda by se proble ´m nevyr ˇes ˇil pr ˇepracova ´nı ´m c ˇa ´sti syste ´mu apod.) - ma ´ vy ´hodu v kontrole (kolega si c ˇasto vs ˇimne chyby kterou ude ˇla ´m) => vy ´sledkem kvalitne ˇjs ˇı ´ ko ´d - snadne ˇjs ˇı ´ pr ˇeda ´va ´nı ´ zkus ˇenostı ´ novy ´m c ˇlenu ˚ m ty ´mu apod. - nevy ´hoda: ve ˇts ˇı ´ ´ uroven ˇ hluku (pokud jsou ty ´my v jedne ´ mı ´stnosti) * proble ´my XP: - za ´kaznı ´k i management musı ´ by ´t ochoten pr ˇistoupit na neobvykle ´ podmı ´nky - po skonc ˇenı ´ projektu nezu ˚ stane dokumentace (pouze pr ˇ´ ıpady pouz ˇitı ´ a dokumentace v ko ´du) [] Dals ˇı ´ agilnı ´ metodiky jsou napr ˇ. DSDM, Scrum, FDD (viz http://www.agilealliance.org).
Spira ´lovy ´ model SW procesu .......................... [zdroj: Boehm 1988] * spira ´lovy ´ model SW procesu pu ˚vodne ˇ navrhl Boehm (1988) * mı ´sto sekvence (kde se chte ˇ nechte ˇ ne ˇkdy musı ´me vracet) je proces reprezentova ´n spira ´lou
zswi/p2xp.d
3. ledna 2005
15
* kaz ˇda ´ otoc ˇka spira ´ly reprezentuje fa ´zi SW procesu, napr ˇ.: - nejvnitr ˇne ˇjs ˇı ´ - vs ˇeobecny ´ za ´me ˇr, studie proveditelnosti - druha ´ - definice poz ˇadavku ˚ - tr ˇetı ´ - na ´vrh (design) syste ´mu - c ˇtvrta ´ - vytvor ˇenı ´ vs ˇech programu ˚
cena analýza rizik
Vyhodnocení
Určení záměrů, alternativ a jejich omezení
a snížení rizik
analýza rizik
analýza rizik analýza rizik závazek
POSOUZENÍ
posouzení
plán požadavků
základní idea činnosti plán životního cyklu plán vývoje
Plánování
(prototyp)
plán integrace a testování
(prototyp)
(prototyp)
(prototyp)
simulace, modely, benchmarky
požadavky
validace požadavků
návrh (design) produktu
podrobný návrh kódování
test jednotek ověření a validace návrhu
plánování další fáze
acceptační test provoz
integrační test
Vývoj & ověření
* kaz ˇda ´ otoc ˇka spira ´ly je rozde ˇlena do 4 sektoru ˚ (sektory nemusejı ´ trvat stejnou dobu): * urc ˇenı ´ za ´me ˇru ˚ pro souc ˇasnou fa ´zi projektu (= otoc ˇku spira ´ly) - definujeme za ´me ˇry dane ´ fa ´ze projektu (funkc ˇnost, vy ´konnost apod.) - urc ˇı ´me alternativnı ´ moz ˇnosti realizace za ´me ˇru ˚ (napr ˇ. design A, design B, pouz ˇitı ´ existujı ´cı ´ komponenty, na ´kup komponent) - identifikujeme omezenı ´ dany ´ch alternativ (cena, c ˇasovy ´ pla ´n, pr ˇenositelnost) - vyhodnotı ´me alternativy vzhledem k za ´me ˇru ˚ m a omezenı ´m - c ˇasto se uka ´z ˇe nejistota, ktera ´ je zdrojem rizik - riziko = ne ˇco co se mu ˚z ˇe nepove ´st . napr ˇ. pokud se rozhodneme pro novy ´ programovacı ´ jazyk, je riziko, z ˇe dostupne ´ pr ˇekladac ˇe jsou nespolehlive ´ nebo negenerujı ´ efektivnı ´ ko ´d (pr ˇı ´klad - Corel a Java) . rizika mohou vyu ´stit do proble ´mu ˚ typu pr ˇekroc ˇenı ´ deadline nebo pr ˇekroc ˇenı ´ rozpoc ˇtu projektu - pokud vyplynula rizika, me ˇli bychom se jimi v dals ˇı ´ fa ´zi zaby ´vat * vyhodnocenı ´ a snı ´z ˇenı ´ rizik - pro kaz ˇde ´ z identifikovany ´ch rizik je provedena detailnı ´ analy ´za a kroky ke snı ´z ˇenı ´ rizika - mu ˚z ˇe zahrnovat prototypova ´nı ´, simulace, vypracova ´nı ´ dotaznı ´ku ˚ apod. - napr ˇ. pokud je riziko, z ˇe jsou nespra ´vne ˇ definova ´ny poz ˇadavky, mu ˚z ˇe by ´t vytvor ˇen prototyp c ˇa ´sti syste ´mu * vy ´voj a validace - prova ´dı ´me vy ´voj a ove ˇr ˇenı ´ produktu dals ˇı ´ ´ urovne ˇ - pouz ˇity ´ model SW procesu je urc ˇen zby ´vajı ´cı ´mi riziky . napr ˇ. pokud je hlavnı ´m rizikem integrace podsyste ´mu ˚, mu ˚z ˇe by ´t nejvhodne ˇjs ˇı ´ vodopa ´dovy ´ model (viz pr ˇı ´klad na vy ´s ˇe uvedene ´m obra ´zku) . pokud je hlavnı ´m rizikem nevhodne ´ uz ˇivatelske ´ rozhranı ´, mu ˚z ˇe by ´t nejpr ˇime ˇr ˇene ˇjs ˇı ´m modelem evoluc ˇnı ´ prototypova ´nı ´ . pokud je hlavnı ´m proble ´mem bezpec ˇnost, mu ˚z ˇe by ´t zvolen vy ´voj zaloz ˇeny ´ na forma ´lnı ´ch transformacı ´ch
Za´klady softwarove´ho inzˇeny´rstvı´
16
zswi/p2xp.d
* pla ´nova ´nı ´ - napla ´nujeme dals ˇı ´ fa ´zi projektu (organizace, poz ˇadavky na zdroje, rozde ˇlenı ´ pra ´ce, c ˇasovy ´ pla ´n, vy ´stupy) - kaz ˇda ´ otoc ˇka je zakonc ˇena posouzenı ´m vs ˇech produktu ˚ vytvor ˇeny ´ch v pr ˇedchozı ´m cyklu, pla ´nu ˚ pro dals ˇı ´ cyklus a potr ˇebny ´ch zdroju ˚ . cı ´lem je aby byly vs ˇechny zu ´c ˇastne ˇne ´ strany srozume ˇny s pla ´ny na dals ˇı ´ fa ´zi . vy ´sledkem napr ˇ.: 15 lidı ´ na 12 me ˇsı ´cu ˚ + za ´kladnı ´ pla ´n z ˇivotnı ´ho cyklu pro alternativu, ktera ´ se vynor ˇı ´ . mu ˚z ˇe urc ˇit i rozde ˇlenı ´ projektu do inkrementu ˚ nebo do neza ´visle vyvı ´jeny ´ch komponent * vy ´s ˇe uvedeny ´ obra ´zek je pouze pr ˇı ´klad, jaky ´m zpu ˚sobem lze spira ´lovy ´ model implementovat - spira ´lovy ´ model je cha ´pa ´n jako ”genera ´tor modelu ˚ SW procesu”, s jeho pomocı ´ vytva ´r ˇı ´me podrobne ˇjs ˇı ´ model SW procesu (napr ˇı ´klad model uvedeny ´ na obra ´zku, ale konkre ´tnı ´ obsah jednotlivy ´ch otoc ˇek mu ˚z ˇe vypadat i jinak) Rozdı ´ly oproti pr ˇedchozı ´m modelu ˚m: * na rozdı ´l od pr ˇedchozı ´ch modelu ˚ explicitne ˇ uvaz ˇuje rizika projektu - z toho plyne i hlavnı ´ proble ´m modelu - je za ´visly ´ na zkus ˇenosti vy ´voja ´r ˇ˚ u identifikovat zdroje rizik * v modelu nenajdeme pevne ´ fa ´ze jako je specifikace nebo design - model je obecne ˇjs ˇı ´, mu ˚z ˇe zahrnovat ostatnı ´ modely SW procesu: - v jedne ´ otoc ˇce mu ˚z ˇe by ´t pouz ˇito prototypova ´nı ´, abychom vyr ˇes ˇili nejistotu v poz ˇadavcı ´ch, a tı ´m redukovali rizika - v dals ˇı ´ otoc ˇce mu ˚z ˇe by ´t na ´sledova ´no klasicky ´m vodopa ´dovy ´m vy ´vojem atd. * model je aplikovatelny ´ i na jine ´ typy projektu ˚ * model s ˇiroce zna ´my ´, ale me ´ne ˇ pouz ˇı ´va ´n nez ˇ klasicky ´ vodopa ´dovy ´ model (za ´kaznı ´ci jsou zvyklı ´ na vodopa ´dovy ´ model, je to pr ˇedpoklad mnoha zada ´nı ´) Pu ˚ vodnı ´ c ˇla ´nek o spira ´love ´m modelu doporuc ˇuje na ´sledujı ´cı ´ Risk Management Plan, ktery ´ lze pouz ˇı ´vat i samostatne ˇ mimo spira ´lovy ´ model: 1. 2. 3. 4. 5.
najde ˇte 10 nejve ˇts ˇı ´ch rizik projektu, pro r ˇes ˇenı ´ kaz ˇde ´ho rizika navrhne ˇte pla ´n, seznam rizik, pla ´ny a vy ´sledky aktualizujte kaz ˇdy ´ me ˇsı ´c, v me ˇsı ´c ˇnı ´ zpra ´ve ˇ o pru ˚be ˇhu projektu (pla ´n vs. pokrok) uved’te stav rizik, zahajte vc ˇas na ´pravne ´ akce.
WinWin spira ´lovy ´ model ...................... [zdroje: Boehm a Ross 1989, Boehm a Bose, 1994] * pu ˚ vodnı ´ spira ´lovy ´ model neposkytuje podrobnosti pro prvnı ´ kvadrant - hlavne ˇ ner ˇı ´ka ´, odkud se vezmou ”za ´me ˇry pro souc ˇasnou fa ´zi projektu” - proto byl pu ˚vodnı ´ model modifikova ´n (Boehm a Bose, 1994) - novy ´ model je postaven na tzv. win-win pr ˇı ´stupu: snaha, aby vs ˇechny zu ´c ˇastne ˇne ´ strany (za ´kaznı ´ci, vy ´voja ´r ˇi, vedoucı ´ atd.) byly ”vy ´herci” . tj. aby tvorba produktu nedegradovala na hru s nulovy ´m souc ˇtem (vy ´hra-prohra, kde napr ˇ. dodavatel vyhraje na ´ ukor za ´kaznı ´ka nebo naopak) . v nejhors ˇı ´m pr ˇı ´pade ˇ vy ´sledek prohra-prohra, napr ˇ. dodavatel prode ˇla ´ a za ´kaznı ´k nezı ´ska ´ produkt, ktery ´ potr ˇebuje
win−win rozšíření
2. identifikuj podmínky pro výhru každého hráče
3. urovnej podmínky pro výhru
uči záměry, omezení
1. identifikuj hráče dalšího cyklu
a alternativy další úrovně
7. kontrola, závazek 6. validuj definice produktu a procesu
5. definuj produkt a proces další úrovně
4. vyhodnoť alternativy produktu a procesu, analyzuj, vyhodnoť a vyřeš rizika prohry (win−lose, lose−lose)
původní spirálový model
zswi/p2xp.d
3. ledna 2005
* v nove ´m modelu je zahrnuta snaha vyrovnat se s konfliktnı ´mi za ´jmy - napr ˇ. za ´kaznı ´k: mı ´t produkt co nejdr ˇı ´ve, zaplatit za ne ˇj co nejme ´ne ˇ - vy ´voja ´r ˇi: odborny ´ ru ˚st, pracovnı ´ a platove ´ podmı ´nky, preference pro pouz ˇı ´vane ´ na ´stroje, odloz ˇit psanı ´ dokumentace apod. - nadr ˇı ´zenı ´: zisk, nepr ˇekroc ˇenı ´ rozpoc ˇtu, z ˇa ´dna ´ pr ˇekvapenı ´
* pr ˇi pozornosti vu ˚c ˇi za ´jmu ˚m a oc ˇeka ´va ´nı ´m jednotlivy ´ch hra ´c ˇ˚ u mu ˚z ˇeme c ˇasto (ale ne vz ˇdy!) vytva ´r ˇet situace typu vy ´hra-vy ´hra: 1. identifikace klı ´c ˇovy ´ch hra ´c ˇ˚ u - do ´ uvah musı ´me zahrnout vs ˇechny hra ´c ˇe podstatne ´ pro dany ´ cyklus projektu (napr ˇ. nadr ˇı ´zene ´ uz ˇivatelu ˚ apod.) 2. pochopenı ´ za ´jmu ˚ kaz ˇde ´ho hra ´c ˇe (motivac ˇnı ´ analy ´za, obvykle nejobtı ´z ˇne ˇjs ˇı ´ c ˇa ´st - motivace jiny ´ch lidı ´ budou totiz ˇ odlis ˇne ´ od nas ˇich) 3. urovna ´nı ´ podmı ´nek pro vy ´hru, r ˇes ˇenı ´ konfliktu ˚ - napr ˇ. za ´kaznı ´ci ve ˇts ˇinou neodhadnou, co je snadne ´ nebo obtı ´z ˇne ´ naprogramovat => majı ´ nerealisticka ´ oc ˇeka ´va ´nı ´; v tomto pr ˇı ´pade ˇ: . vhodne ´ pouz ˇı ´t dobr ˇe kalibrovany ´ model pro odhad ceny a trva ´nı ´ vy ´voje . nabı ´dnout novou alternativu typu vy ´hra-vy ´hra, napr ˇ. ”vs ˇechny poz ˇadovane ´ funkce sice nenı ´ moz ˇne ´ vyvinout za 12 me ˇsı ´cu ˚, ale mu ˚z ˇeme pracovat podle pr ˇı ´ru ˚stkove ´ho modelu a za 12 me ˇsı ´cu ˚ splnit vas ˇe nejdu ˚lez ˇite ˇjs ˇı ´ poz ˇadavky” Ostatnı ´ c ˇa ´sti jsou stejne ´ jako u pu ˚vodnı ´ho spira ´love ´ho modelu.
* uvedli jsme za ´kladnı ´ modely SW procesu (vodopa ´dovy ´ az ˇ spira ´love ´) - vodopa ´dovy ´ model - za ´kladnı ´ model, konzistentnı ´ se strukturovany ´m programova ´nı ´m shora dolu ˚; vhodny ´ pokud jsou zna ´me ´ poz ˇadavky (napr ˇ.: operac ˇnı ´ syste ´my, pr ˇekladac ˇe apod.) - evoluc ˇnı ´ vy ´voj - pokud c ˇa ´sti poz ˇadavku ˚ nejsou zr ˇejme ´, napr ˇ. uz ˇivatelske ´ rozhranı ´ (”nevı ´m co chci, ale pozna ´m to, az ˇ to uvidı ´m”) - forma ´lnı ´ metody - pokud musı ´m dokazatelne ˇ splnit specifikaci, ma ´m podpu ˚rne ´ na ´stroje a ty ´m sezna ´meny ´ s forma ´lnı ´mi metodami - komponentove ˇ orientovany ´ vy ´voj - ma ´me-li vhodne ´ komponenty - inkrementa ´lnı ´ vy ´voj - potr ˇebujeme omezit pr ˇepracova ´va ´nı ´, doda ´va ´me syste ´m po c ˇa ´stech - spira ´lovy ´ model - vhodne ´ pro sloz ˇite ´ inovativnı ´ projekty vytva ´r ˇene ´ uvnitr ˇ organizace, zahrnuje pr ˇedchozı ´ modely jako specia ´lnı ´ pr ˇı ´pady (nemusı ´ by ´t SW) - win-win spira ´lovy ´ - jako spira ´lovy ´, ale vhodne ´ pro projekty na zaka ´zku. * hlavnı ´m ´ uc ˇelem modelu ˚ je urc ˇit spra ´vne ´ por ˇadı ´ kroku ˚ pr ˇi vy ´voji SW a urc ˇit krite ´ria pro pr ˇechod k dals ˇı ´mu kroku * tj. model SW procesu odpovı ´da ´ na ota ´zky: - co budeme de ˇlat pr ˇı ´s ˇte ˇ? - jak dlouho to ma ´me de ˇlat? * v dals ˇı ´m povı ´da ´nı ´ se sezna ´mı ´me s ne ˇktery ´mi metodologiemi - metodologie = jak prove ´st pr ˇı ´slus ˇnou fa ´zi - uz ˇ na zac ˇa ´tku bylo r ˇec ˇeno, z ˇe za ´kladnı ´ aktivity SW procesu jsou 1. analy ´za dome ´ny a definice poz ˇadavku ˚ , 2. design syste ´mu a design SW, 3. implementace a testova ´nı ´ modulu ˚, 4. integrace a testova ´nı ´ syste ´mu - jako prvnı ´ metodologii pro (1) Analy ´za dome ´ny a definice poz ˇadavku ˚ =================================== * v te ´to fa ´zi definujeme: - jake ´ sluz ˇby jsou od syste ´mu poz ˇadova ´ny - jaka ´ jsou omezenı ´ vy ´voje a vy ´sledne ´ho produktu * chyby v te ´to fa ´zi SW procesu nevyhnutelne ˇ vedou k proble ´mu ˚m pr ˇi designu a implementaci! Pozna ´mka (cena zme ˇn): Studie potvrzujı ´ intuitivne ˇ zr ˇejmou ve ˇc, z ˇe zme ˇny v poc ˇa ´tec ˇnı ´ch stadiı ´ch projektu jsou podstatne ˇ levne ˇjs ˇı ´ (10x az ˇ 200x) nez ˇ pozde ˇji. Tj. c ˇı ´m pozde ˇji defekt detekujeme, tı ´m vı ´ce c ˇasu i pene ˇz na ´s bude sta ´t jeho oprava (viz obra ´zek).
17
Za´klady softwarove´ho inzˇeny´rstvı´
zswi/p2xp.d
cena
18
analýza architektura implementace test systému analýza
architektura implementace test systému
údržba
Napr ˇ. defekt analy ´zy poz ˇadavku ˚, jehoz ˇ oprava by na ´s sta ´la 1000 Kc ˇ be ˇhem fa ´ze analy ´zy poz ˇadavku ˚, na ´s mu ˚z ˇe sta ´t 25 000 Kc ˇ be ˇhem za ´ve ˇrec ˇne ´ho testova ´nı ´ syste ´mu (vı ´ce u velky ´ch syste ´mu ˚ , me ´ne ˇ u maly ´ch syste ´mu ˚). Proto je zdrava ´ snaha vyr ˇes ˇit proble ´my tak brzy, jak to jen jde. [] Pozna ´mka pro zajı ´mavost (cena zme ˇn a metodika Extreme Programming) Autor metodiky XP tvrdı ´, z ˇe pec ˇlivy ´m dodrz ˇova ´nı ´m pravidel XP je moz ˇne ´ cenu zme ˇn snı ´z ˇit takto:
d
cena změny
kla
ře
íp
n dič
tra
o dp
XP
čas Nanes ˇte ˇstı ´ je to pouze autoru ˚ v odhad - zatı ´m nevı ´m o z ˇa ´dny ´ch me ˇr ˇenı ´ch, ktere ´ by to potvrzovaly. [] Pr ˇi specifikaci poz ˇadavku ˚ na rozsa ´hle ´ syste ´my obvykle rozlis ˇujeme 4 fa ´ze: * studie proveditelnosti (feasibility study) - odhad, zda poz ˇadavky za ´kaznı ´ka mohou by ´t splne ˇny za pomocı ´ existujı ´cı ´ch HW a SW technologiı ´ v ra ´mci dany ´ch rozpoc ˇtovy ´ch omezenı ´ - studie proveditelnosti ma ´ by ´t rychla ´ a levna ´, vy ´sledkem, zda pr ˇikroc ˇı ´me k podrobne ˇjs ˇı ´ analy ´ze * zjis ˇte ˇnı ´ a analy ´za poz ˇadavku ˚ - zjis ˇt’ujeme poz ˇadavky na novy ´ syste ´m pozorova ´nı ´m existujı ´cı ´ch syste ´mu ˚ , diskusı ´ s potencia ´lnı ´mi uz ˇivateli a se za ´stupci zadavatele - mu ˚z ˇe zahrnovat vy ´voj modelu ˚ a prototypu ˚ * specifikace poz ˇadavku ˚ - vy ´sledkem je dokument specifikace poz ˇadavku ˚ (DSP) - poz ˇadavky obvykle uvedeny ve dvou ´ urovnı ´ch podrobnosti: . za ´kaznı ´k potr ˇebuje vysokou ´rovn ˇovy ´ popis svy ´ch poz ˇadavku ˚ (”user requirements”) . vy ´voja ´r ˇi potr ˇebujı ´ podrobne ˇjs ˇı ´ specifikaci syste ´mu (”system requirements”) * validace poz ˇadavku ˚ - kontrola poz ˇadavku ˚ - zda jsou realisticke ´, konzistentnı ´ a ´ uplne ´ - be ˇhem te ´to fa ´ze nacha ´zı ´me chyby v DSP => DSP musı ´me opravit - v pru ˚ be ˇhu te ´to i pr ˇedchozı ´ch fa ´zı ´ se mohou objevit nove ´ poz ˇadavky => dtto
zswi/p2xp.d
3. ledna 2005 feasibility study feasibility report
requirements elicitation and analysis system models
requirements specification user and system requirements
19
requirements validation requirements document
Studie proveditelnosti ---------------------* pro vs ˇechny nove ´ syste ´my by SW proces me ˇl zac ˇı ´nat studiı ´ proveditelnosti * snaz ˇı ´ se zodpove ˇde ˇt na ´sledujı ´cı ´ ota ´zky: - pr ˇispe ˇje syste ´m k celkovy ´m za ´me ˇru ˚ m organizace? - lze syste ´m implementovat za pomocı ´ existujı ´cı ´ch HW a SW technologiı ´? - bude moz ˇne ´ syste ´m integrovat s jiz ˇ existujı ´cı ´mi syste ´my? - bude vy ´voj syste ´mu financ ˇne ˇ efektivnı ´ (tj. neprode ˇla ´me na tom?), resp. lze syste ´m realizovat v ra ´mci dany ´ch rozpoc ˇtovy ´ch omezenı ´? * vstupem je obecny ´ popis + jaky ´m zpu ˚ sobem ma ´ by ´t v organizaci vyuz ˇı ´va ´n * vy ´stupem je zpra ´va, ktera ´ doporuc ˇuje nebo nedoporuc ˇuje pokrac ˇovat ve vy ´voji * obecne ´ fa ´ze - identifikace potr ˇebny ´ch informacı ´, zı ´ska ´nı ´ informacı ´, vytvor ˇenı ´ zpra ´vy Musı ´me najı ´t informac ˇnı ´ zdroje - manaz ˇery, koncove ´ uz ˇivatele, lidi, kter ˇı ´ znajı ´ podobne ´ syste ´my apod., budeme se jich pta ´t: * jake ´ jsou proble ´my se souc ˇasny ´m procesem zpracova ´nı ´ informacı ´, jak je ma ´ novy ´ syste ´m pomoci r ˇes ˇit? * lze pr ˇena ´s ˇet informace z a do jiny ´ch informac ˇnı ´ch syste ´mu ˚, ktere ´ organizace jiz ˇ provozuje? * co musı ´ by ´t v syste ´mu podporova ´no a co nemusı ´? * je zapotr ˇebı ´ technologie, ktera ´ jes ˇte ˇ nebyla pouz ˇita? Vy ´sledna ´ studie by: * me ˇla obsahovat doporuc ˇenı ´, zda pokrac ˇovat ve vy ´voji * mu ˚ˇ ze navrhnout zme ˇny rozsahu, rozpoc ˇtu a c ˇasove ´ho pla ´nu syste ´mu * mu ˚z ˇe navrhnout dals ˇı ´ vysokou ´rovn ˇove ´ poz ˇadavky na syste ´m Analy ´za dome ´ny a zjis ˇte ˇnı ´ poz ˇadavku ˚ ----------------------------------* za pomocı ´ zadavatele se seznamujeme s aplikac ˇnı ´ dome ´nou a zjis ˇt’ujeme, jake ´ sluz ˇby ma ´ syste ´m poskytovat - aplikac ˇnı ´ dome ´na = obor, ze ktere ´ho proble ´m pocha ´zı ´ * je to obtı ´z ˇne ´, protoz ˇe: - zadavatel obvykle ve skutec ˇnosti nevı ´ pr ˇesne ˇ, co od syste ´mu poz ˇaduje, resp. je pro ne ˇj obtı ´z ˇne ´ to vyja ´dr ˇit; mu ˚z ˇe take ´ mı ´t nerealisticke ´ poz ˇadavky, protoz ˇe nezna ´ cenu jejich realizace - zadavatel vyjadr ˇuje poz ˇadavky ve vlastnı ´ch termı ´nech a s implicitnı ´ znalostı ´ vlastnı ´ pra ´ce (aplikac ˇnı ´ dome ´ny); vy musı ´te pochopit poz ˇadavky i bez te ´to zkus ˇenosti - ru ˚ znı ´ za ´stupci zadavatele majı ´ ru ˚ zne ´ poz ˇadavky, ktere ´ vyjadr ˇujı ´ ru ˚zny ´m zpu ˚sobem; vy musı ´te urc ˇit vs ˇechny zdroje poz ˇadavku ˚, najı ´t spolec ˇne ´ c ˇa ´sti a c ˇa ´sti, ktere ´ jsou v konfliktu - poz ˇadavky mohou ovlivn ˇovat politicke ´ faktory; napr ˇı ´klad konkre ´tnı ´ manaz ˇer ˇi mohou mı ´t specificke ´ poz ˇadavky, ktere ´ by pomohly posı ´lit jejich vliv v organizaci - prostr ˇedı ´, ve ktere ´m se prova ´dı ´ analy ´za, se pru ˚be ˇz ˇne ˇ me ˇnı ´ - du ˚lez ˇitost jednotlivy ´ch poz ˇadavku ˚ se mu ˚z ˇe zme ˇnit; nove ´ poz ˇadavky mohou pr ˇicha ´zet od za ´stupcu ˚ zadavatele, kter ˇı ´ do toho pr ˇedtı ´m neme ˇli co mluvit. Obecny ´ model analy ´zy poz ˇadavku ˚ vypada ´ takto: * porozume ˇnı ´ aplikac ˇnı ´ dome ´ne ˇ - analytik musı ´ pochopit aplikac ˇnı ´ dome ´nu - napr ˇ. pokud r ˇes ˇı ´ informac ˇnı ´ syste ´m supermarketu, musı ´ ve ˇde ˇt jak
Za´klady softwarove´ho inzˇeny´rstvı´
20
fungujı ´ supermarkety * sbe ˇr poz ˇadavku ˚ - analytik zjis ˇt’uje poz ˇadavky na syste ´m od za ´stupcu ˚ zadavatele * klasifikace poz ˇadavku ˚ - nestrukturovanou mnoz ˇinu poz ˇadavku ˚ se snaz ˇı ´me logicky uspor ˇa ´dat * r ˇes ˇenı ´ konfliktu ˚ - pokud je vı ´ce zadavatelu ˚, ne ˇktere ´ poz ˇadavky budou vza ´jemne ˇ v rozporu; rozpory poz ˇadavku ˚ musı ´me vyhledat a vyr ˇes ˇit * urc ˇenı ´ priorit - konzultacı ´ se zadavatelem bychom me ˇli urc ˇit nejdu ˚lez ˇite ˇjs ˇı ´ poz ˇadavky * kontrola poz ˇadavku ˚ - musı ´me zjistit, zda jsou poz ˇadavky ´ uplne ´, konzistentnı ´ a zda odpovı ´dajı ´ tomu, co zadavatel od syste ´mu chce Ve skutec ˇnosti je to ope ˇt iterativnı ´ proces, kde se musı ´me vracet.
Specifikace poz ˇadavku ˚ --------------------Nejdr ˇ´ ıve si uvedeme za ´kladnı ´ klasifikaci typu ˚ poz ˇadavku ˚ (funkc ˇnı ´, mimofunkc ˇnı ´ a dome ´nove ´); pote ´ se budeme zaby ´vat uz ˇivatelsky ´mi a syste ´movy ´mi poz ˇadavky a zpu ˚sobem jejich specifikace. Nakonec uvedeme, jak by me ˇl vypadat dokument specifikace poz ˇadavku ˚. Typy poz ˇadavku ˚ .............. Poz ˇadavky na syste ´m lze rozde ˇlit do na ´sledujı ´cı ´ch tr ˇı ´d: * funkc ˇnı ´ poz ˇadavky * mimofunkc ˇnı ´ poz ˇadavky * dome ´nove ´ poz ˇadavky * funkc ˇnı ´ poz ˇadavky (functional requirements) - popisujı ´ funkce nebo sluz ˇby, ktere ´ jsou od syste ´mu oc ˇeka ´va ´ny - napr ˇı ´klad poz ˇadavky na univerzitnı ´ knihovnı ´ syste ´m: . uz ˇivatele ´ by me ˇli mı ´t moz ˇnost prohleda ´vat poc ˇa ´tec ˇnı ´ mnoz ˇinu databa ´zı ´ nebo jejı ´ podmnoz ˇinu . syste ´m by me ˇl poskytovat uz ˇivatelu ˚m vhodne ´ prohlı ´z ˇec ˇe pro c ˇtenı ´ dokumentu ˚ v ´ uloz ˇis ˇti dokumentu ˚ * mimofunkc ˇnı ´ poz ˇadavky (non-functional requirements) - nety ´kajı ´ se funkcı ´ syste ´mu, ale vlastnostı ´ jako je spolehlivost, c ˇas odpove ˇdi a obsazene ´ mı ´sto na disku nebo v pame ˇti - c ˇasto kritic ˇte ˇjs ˇı ´ nez ˇ jednotlive ´ funkc ˇnı ´ poz ˇadavky, napr ˇ. pokud je ˇı r ´dı ´cı ´ syste ´m letadla nespolehlivy ´, je nepouz ˇitelny ´ - ne ˇkdy se mimofunkc ˇnı ´ poz ˇadavky ty ´kajı ´ SW procesu, napr ˇ. v procesu musı ´ by ´t pouz ˇit urc ˇity ´ standard pro r ˇı ´zenı ´ jakosti (ISO 9000), design musı ´ by ´t vytvor ˇen urc ˇity ´m CASE na ´strojem, pro implementaci musı ´ by ´t pouz ˇit dany ´ programovacı ´ jazyk, produkt musı ´ by ´t doda ´n do urc ˇite ´ho data apod. - ne ˇkdy jsou poz ˇadavky dane ´ vne ˇjs ˇı ´mi faktory, napr ˇ. legislativnı ´ poz ˇadavky (syste ´m musı ´ by ´t navrz ˇen v souladu se za ´konem na ochranu osobnı ´ch informacı ´ apod.) - napr ˇı ´klad na ´sledujı ´cı ´ c ˇa ´sti specifikace definujı ´ mimofunkc ˇnı ´ poz ˇadavky: . 3.6.6 Ves ˇkera ´ komunikace mezi uz ˇivatelem a syste ´mem by me ˇla by ´t vyja ´dr ˇitelna ´ ve znakove ´ sade ˇ ISO 8859-2. (Definuje omezenı ´ na ´vrhu uz ˇivatelske ´ho rozhranı ´, tj. nenı ´ funkce, ale omezenı ´ => mimofunkc ˇnı ´ poz ˇadavek) . 3.6.8 Proces vy ´voje syste ´mu a vs ˇechny dokumenty majı ´ odpovı ´dat softwarove ´mu procesu definovane ´mu ve standardu XYZ. (Mimofunkc ˇnı ´ poz ˇadavek ty ´kajı ´cı ´ se SW procesu.) . 3.6.9 Syste ´m nema ´ opera ´toru ˚m syste ´mu poskytovat z ˇa ´dne ´ osobnı ´ informace o za ´kaznı ´cı ´ch krome ˇ jme ´na a c ˇı ´sla za ´kaznı ´ka. (Poz ˇadavek dany ´ vne ˇjs ˇı ´mi faktory, napr ˇ. pr ˇijatelnostı ´ syste ´mu pro ver ˇejnost.)
zswi/p2xp.d
zswi/p2xp.d
3. ledna 2005
* c ˇaste ´ proble ´my mimofunkc ˇnı ´ch poz ˇadavku ˚ - obecne ˇ definovane ´ mimofunkc ˇnı ´ poz ˇadavky jsou obtı ´z ˇne ˇ ove ˇr ˇitelne ´, takz ˇe mohou pu ˚sobit neshody po doda ´nı ´ syste ´mu za ´kaznı ´kovi . pr ˇı ´klad obecne ´ definice: Syste ´m ma ´ by ´t snadno pouz ˇitelny ´ a nebezpec ˇı ´ chyb uz ˇivatelu ˚ by me ˇlo by ´t minimalizova ´no. . pr ˇı ´klad ove ˇr ˇitelne ´ definice: Zkus ˇene ´ ´ uc ˇetnı ´ by me ˇly by ´t schopny pouz ˇı ´vat vs ˇechny funkce syste ´mu po tr ˇı ´dennı ´m zas ˇkolenı ´. Poc ˇet chyb po zas ˇkolenı ´ by neme ˇl pr ˇesa ´hnout dve ˇ za den. . mnoho poz ˇadavku ˚ je obtı ´z ˇne ´ definovat me ˇr ˇitelny ´m zpu ˚sobem, ne ˇkdy to ani nejde (napr ˇ. udrz ˇovatelnost syste ´mu) - mimofunkc ˇnı ´ poz ˇadavky mohou by ´t v konfliktu, napr ˇ.: . syste ´m pro r ˇı ´zenı ´ sondy ma ´ by ´t vytvor ˇen v jazyce Ada . maxima ´lnı ´ velikost syste ´mu ma ´ by ´t 4 MB (bude instalova ´n v ROM) . je zapotr ˇebı ´ vyr ˇes ˇit - urc ˇit jiny ´ jazyk nebo zve ˇts ˇit pame ˇt’ Pozna ´mka (pr ˇı ´klad mimofunkc ˇnı ´ch poz ˇadavku ˚ a jejich metrik) --------------------------------------------------------------------rychlost pru ˚chodnost, napr ˇ. poc ˇet transakcı ´ za sekundu c ˇas odpove ˇdi na poz ˇadavek uz ˇivatele nebo na uda ´lost (pru ˚me ˇrny ´, maxima ´lnı ´) c ˇas pr ˇekreslenı ´ obrazovky --------------------------------------------------------------------velikost velikost v pame ˇti, na disku, napr ˇ. v KB --------------------------------------------------------------------snadnost pouz ˇitı ´ doba potr ˇebna ´ pro zas ˇkolenı ´ doba trva ´nı ´ typicke ´ ´ ulohy rozsah na ´pove ˇdy soulad se standardem pro GUI --------------------------------------------------------------------spolehlivost poc ˇet hava ´riı ´ za c ˇasovou jednotku pru ˚me ˇrna ´ doba mezi hava ´riemi pravde ˇpodobnost nedostupnosti poc ˇet chyb/1000 r ˇa ´dek ko ´du --------------------------------------------------------------------robustnost doba zotavenı ´ po hava ´rii doba opravy po hava ´rii pravde ˇpodobnost pos ˇkozenı ´ dat pr ˇi hava ´rii pr ˇijatelne ´ chova ´nı ´ pr ˇi degradaci syste ´mu --------------------------------------------------------------------pr ˇenositelnost velikost ko ´du za ´visle ´ho na platforme ˇ (napr ˇ. v %) poc ˇet cı ´lovy ´ch platforem --------------------------------------------------------------------kapacita napr ˇ. poc ˇet za ´kaznı ´ku ˚ , ktery ´ syste ´m zvla ´dne --------------------------------------------------------------------[] Pozna ´mka (pojem ”robustnı ´”) Pojem ”robustnı ´” = schopny ´ rozumne ˇ zvla ´dnout chybove ´ stavy (fc ˇnosti, meznı ´ za ´te ˇˇ ze apod. [] * dome ´nove ´ poz ˇadavky (domain requirements) - vyply ´vajı ´ z aplikac ˇnı ´ dome ´ny, nikoli ze specificky ´ch poz ˇadavku ˚ zadavatele - mohou by ´t funkc ˇnı ´ nebo mimofunkc ˇnı ´ - napr ˇ. c ˇa ´st specifikace ze syste ´mu pro automaticke ´ zastavenı ´ vlaku, pr ˇejede-li c ˇervenou: Zpomalenı´ vlaku bude vypocˇteno jako D = Dc + D∆ , kde D∆ = 9.81 ms2 · gradient ; hodnota α je zna´ma´ pro ru˚zne´ typy vlaku. α - proble ´my s dome ´novy ´mi poz ˇadavky: . specialiste ´ rozumı ´ dome ´ne ˇ natolik dobr ˇe, z ˇe je nenapadne dome ´nove ´ poz ˇadavky specifikovat explicitne ˇ . vy ´voja ´r ˇi o nich nemusejı ´ ve ˇde ˇt nebo jim rozume ˇt
21
Za´klady softwarove´ho inzˇeny´rstvı´
22
Dals ˇı ´ rozde ˇlenı ´ vyply ´va ´ z rozdı ´lne ´ ´ urovne ˇ popisu - pro ru ˚zne ´ c ˇtena ´r ˇe: * uz ˇivatelska ´ specifikace poz ˇadavku ˚ (user requirements specification) - vysokou ´rovn ˇovy ´ popis funkc ˇnı ´ch a mimofunkc ˇnı ´ch poz ˇadavku ˚ za ´kaznı ´ka - musı ´ by ´t srozumitelne ´ pro uz ˇivatele, kter ˇı ´ nemajı ´ technicke ´ znalosti (manaz ˇery klienta a dodavatele, koncove ´ uz ˇivatele) * syste ´mova ´ specifikace poz ˇadavku ˚ (system requirements specification) - podrobne ˇjs ˇı ´ specifikace uz ˇivatelsky ´ch poz ˇadavku ˚ pro vy ´voja ´r ˇe dodavatele - ma ´ by ´t pr ˇesna ´ . mu ˚z ˇe slouz ˇit jako za ´klad kontraktu mezi za ´kaznı ´kem a dodavatelem . slouz ˇı ´ jako vy ´chozı ´ bod pro design syste ´mu Pr ˇı ´klad (uz ˇivatelska ´ specifikace poz ˇadavku ˚): 1. Syste ´m musı ´ poskytnout zpu ˚sob reprezentace externı ´ch dokumentu ˚ a moz ˇnost jejich prohlı ´z ˇenı ´. Pr ˇı ´klad (syste ´mova ´ specifikace poz ˇadavku ˚): 1.1 Uz ˇivateli bude poskytnuta moz ˇnost definovat typy externı ´ch dokumentu ˚. 1.2 Kaz ˇdy ´ typ externı ´ho dokumentu bude na obrazovce reprezentova ´n urc ˇitou ikonou. 1.3 Uz ˇivateli bude poskytnuta moz ˇnost definovat pro typ externı ´ho dokumentu vlastnı ´ ikonu. 1.4 Uz ˇivateli bude poskytnuta moz ˇnost sdruz ˇit typ externı ´ho dokumentu s prohlı ´z ˇec ˇem. 1.5 Pokud uz ˇivatel vybere ikonu reprezentujı ´cı ´ externı ´ dokument, vy ´sledkem bude spus ˇte ˇnı ´ prohlı ´z ˇec ˇe sdruz ˇene ´ho s typem externı ´ho dokumentu pro dokument reprezentovany ´ vybranou ikonou. Zdu ˚vodne ˇnı ´: Je pravde ˇpodobne ´, z ˇe nove ´ dokumenty budou distribuova ´ny ve forma ´tech, ktere ´ zatı ´m nejsou zna ´me ´. []
Doporuc ˇenı ´: * zave ´st si standardnı ´ forma ´t a dodrz ˇovat ho; napr ˇ. zvy ´raznit poc ˇa ´tec ˇnı ´ poz ˇadavek (1.), k poz ˇadavku pr ˇipojit zdu ˚vodne ˇnı ´ - zdu ˚ vodne ˇnı ´ je du ˚lez ˇite ´ ve chvı ´li, kdy je navrz ˇena zme ˇna poz ˇadavku zna ´me du ˚vod pu ˚vodnı ´ verze * pouz ˇı ´vat jazyk konzistentnı ´m zpu ˚sobem, hlavne ˇ rozlis ˇit nutne ´ poz ˇadavky od preferencı ´ (napr ˇ. pojem ”bude” bude vz ˇdy znamenat nutny ´ poz ˇadavek, zatı ´mco pojem ”me ˇl by” bude vz ˇdy znamenat z ˇa ´doucı ´ chova ´nı ´) * nepouz ˇı ´vat z ˇargon Pr ˇı ´klad: 1. Syste´m musı´ poskytnout zpu˚sob reprezentace externı´ch dokumentu˚ a mozˇnost jejich prohlı´zˇenı´. 1.1 Uzˇivateli bude poskytnuta mozˇnost definovat typy externı´ch dokumentu˚. 1.2 Kazˇdy´ typ externı´ho dokumentu bude na obrazovce reprezentova´n urcˇitou ikonou. 1.3 . . . Zdu˚vodneˇnı´: Je pravdeˇpodobne´, zˇe nove´ dokumenty budou distribuova´ny ve forma´tech, ktere´ zatı´m nejsou zna´me´.
❉
zswi/p3req.d
zswi/p3req.d
3. ledna 2005
KIV/ZSWI 2004/2005 Pr ˇedna ´s ˇka 3 Dokument specifikace poz ˇadavku ˚ ============================= Ve skutec ˇnosti se mu ˚z ˇeme setkat se 2 druhy dokumentu ˚ specifikujı ´cı ´ch poz ˇadavky: 1. dokument specifikujı ´cı ´ poz ˇadavky na syste ´m (angl. Concept of Operations, ConOps document; pouz ˇı ´vajı ´ se jes ˇte ˇ dals ˇı ´ na ´zvy) - vysokou ´rovn ˇovy ´ popis poz ˇadavku ˚ z hlediska zadavatele (musı ´ se vyjadr ˇovat v termı ´nech zadavatele, protoz ˇe ho budou c ˇı ´st take ´ za ´stupci zadavatele) - krome ˇ seznamu poz ˇadavku ˚ obsahuje informace o celkovy ´ch za ´me ˇrech syste ´mu, cı ´love ´m prostr ˇedı ´, omezenı ´ch, pr ˇedpokladech a mimofunkc ˇnı ´ch poz ˇadavcı ´ch - mu ˚z ˇe obsahovat modely kontextu syste ´mu, pr ˇı ´pady pouz ˇitı ´, toky informacı ´ a pra ´ce apod. - slouz ˇı ´ pro validaci syste ´movy ´ch poz ˇadavku ˚ 2. dokument specifikujı ´cı ´ poz ˇadavky na software (angl. Software Requirements Specification, SRS) - v c ˇes ˇtine ˇ termı ´n Dokument specifikace poz ˇadavku ˚ (DSP) - podrobna ´ specifikace poz ˇadavku ˚ na software, odvozena ´ z poz ˇadavku ˚ na syste ´m - pr ˇedpokla ´da ´ se, z ˇe c ˇtena ´r ˇi uz ˇ majı ´ pone ˇtı ´ o SW inz ˇeny ´rstvı ´ => jazyk mu ˚z ˇe by ´t pr ˇesne ˇjs ˇı ´, notace podrobne ˇjs ˇı ´ - me ˇl by obsahovat specifikaci uz ˇivatelsky ´ch i syste ´movy ´ch poz ˇadavku ˚ . uz ˇivatelske ´ i syste ´move ´ poz ˇadavky mohou by ´t sdruz ˇeny v jednom popisu . c ˇasto leps ˇı ´ uve ´st uz ˇivatelske ´ poz ˇadavky v ´ uvodu k syste ´movy ´m poz ˇadavku ˚m . pokud by byl rozsah dokumentu neu ´me ˇrny ´, je moz ˇne ´ vytvor ˇit syste ´move ´ poz ˇadavky jako samostatne ´ dokumenty - obsahuje oficia ´lnı ´ vyja ´dr ˇenı ´ o tom, co se od vyvı ´jene ´ho syste ´mu oc ˇeka ´va ´ => pro produkty vyvı ´jene ´ na zaka ´zku mu ˚z ˇe slouz ˇit jako za ´klad kontraktu . uvnitr ˇ organizace mu ˚z ˇe hra ´t roli za ´kaznı ´ka napr ˇ. obchodnı ´ odde ˇlenı ´, vy ´zkumne ´ odde ˇlenı ´ apod. . pro genericke ´ produkty mu ˚z ˇe by ´t vy ´hodne ´ najmout si kvalifikovane ´ho uz ˇivatele Ru ˚ zne ´ velke ´ organizace definovaly vlastnı ´ standardy a doporuc ˇenı ´ pro strukturu obou typu ˚ dokumentu ˚, napr ˇ. IEEE std 1362-1998 (struktura ConOps) a IEEE std 830-1998 (struktura DSP). Napr ˇ. struktura podle IEEE/ANSI 830 (”IEEE Guide to Software Requirements Specifications”) vypada ´ zjednodus ˇene ˇ takto: Table of Contents // obsah 1. Introduction // ´ uvod 1.1 Purpose of the requirements document // ´ uc ˇel DSP 1.2 Scope of the product // rozsah produktu 1.3 Definitions, acronyms and abbreviations // definice, zkratky 1.4 References // odkazy 1.5 Overview of the remainder of the document // pr ˇehled zbytku DSP 2. General description // obecny ´ popis 2.1 Product perspective (independent/part of) // kontext produktu 2.2 Product functions // funkce produktu 2.3 User characteristics // charakteristiky uz ˇivatelu ˚ 2.4 General constraints // obecna ´ omezenı ´ 2.5 Assumptions and dependencies // pr ˇedpoklady a za ´vislosti 3. Specific requirements (functional, non-functional and interface requirements) // specificke ´ poz ˇadavky .... // (nenı ´ std. struktura) 4. Appendices // pr ˇı ´lohy 5. Index // rejstr ˇı ´k Ve skutec ˇnosti bude informace v DSP za ´viset na vyvı ´jene ´m produktu a na modelu SW procesu, takz ˇe je nutne ´ si obecny ´ model pr ˇizpu ˚sobit. Pozna ´mka: Ne vs ˇechny instituce dokumentujı ´ a udrz ˇujı ´ poz ˇadavky na vyvı ´jeny ´ SW. Zejme ´na
23
Za´klady softwarove´ho inzˇeny´rstvı´
24
v maly ´ch firma ´ch se silnou vizı ´ je spra ´va poz ˇadavku ˚ c ˇasto povaz ˇova ´na za zbytec ˇnou rez ˇii. Pokud ovs ˇem dostatec ˇne ˇ naroste ba ´ze uz ˇivatelu ˚ a produkt se vyvı ´jı ´, pak nutnost vyhodnocovat navrhovane ´ zme ˇny vede k potr ˇebe ˇ zjistit pu ˚ vodnı ´ poz ˇadavky, ktere ´ urc ˇovaly vlastnosti produktu. [] Doporuc ˇenı ´: pro praxi si navrhne ˇte vlastnı ´ forma ´t a pouz ˇı ´vejte ho pro vs ˇechny DSP - snı ´z ˇı ´ se tı ´m pravde ˇpodobnost, z ˇe na ne ˇco zapomenete. Pozna ´mka (osnova DSP na stra ´nka ´ch pr ˇedme ˇtu ZSWI) * na stra ´nka ´ch ZSWI je vystavena osnova DSP (soubor pro MS Word) * osnova je odvozena ´ ze standardu IEEE 830 * tento soubor mu ˚z ˇete vyuz ˇı ´t - pr ˇed odevzda ´nı ´m z ne ˇj zrus ˇte na ´pove ˇdu [] DSP by me ˇl spln ˇovat na ´sledujı ´cı ´ body (vy ´be ˇr z [Heiniger1980], [Pressmann] a [SWEBOOK2001]): * DSP by me ˇl specifikovat pouze externı ´ chova ´nı ´ syste ´mu - tj. snaha vylouc ˇit z DSP na ´vrh SW do te ´ mı ´ry, do jake ´ je to moz ˇne ´ - ne ˇkdy jsou ale poz ˇadavky a design neodde ˇlitelne ´, napr ˇ. syste ´m mu ˚z ˇe komunikovat s jiny ´m syste ´mem, z c ˇehoz ˇ vyply ´vajı ´ poz ˇadavky na design * DSP by by ´t strukturova ´n tak, aby v ne ˇm bylo snadne ´ prova ´de ˇt zme ˇny - popis by me ˇl by ´t lokalizovany ´ a volne ˇ va ´zany ´ * DSP by me ˇl specifikovat omezenı ´ implementace * DSP by me ˇl charakterizovat pr ˇijatelne ´ odpove ˇdi na nez ˇa ´doucı ´ uda ´losti * DSP by me ˇl zaznamenat pr ˇedstavu o z ˇivotnı ´m cyklu syste ´mu
Zpu ˚ soby specifikace poz ˇadavku ˚ ----------------------------Popı ´s ˇeme si zatı ´m: * * * *
pr ˇirozeny ´ jazyk (a ne ˇkolik doporuc ˇenı ´) formula ´r ˇe pr ˇı ´pady pouz ˇitı ´ pseudoko ´dy a specifikace rozhranı ´.
Pr ˇirozeny ´ jazyk ............... * poz ˇadavky jsou obvykle popsa ´ny pr ˇirozeny ´m jazykem - vy ´hodou srozumitelnost pro uz ˇivatele i pro vy ´voja ´r ˇe * pr ˇirozeny ´ jazyk ma ´ v urc ˇity ´ch pr ˇı ´padech sve ´ nevy ´hody - nejednoznac ˇnost popisu - sloz ˇite ´ koncepce (napr ˇ. algoritmy) je obtı ´z ˇne ´ popsat pr ˇesne ˇ - pr ˇ´ ılis ˇ flexibilnı ´ - stejna ´ ve ˇc se da ´ r ˇı ´ci mnoha ru ˚zny ´mi zpu ˚soby; jak c ˇtena ´r ˇ zjistı ´, z ˇe se poz ˇadavky lis ˇı ´ a c ˇı ´m? - neexistuje jednoduchy ´ zpu ˚sob modularizace - jak zjistı ´te du ˚sledek zme ˇny poz ˇadavku ˚, tj. ktery ´ch vs ˇech dals ˇı ´ch poz ˇadavku ˚ se zme ˇna dotkne? * pouz ˇitı ´ pr ˇirozene ´ho jazyka je nevyhnutelne ´ (jedine ´, c ˇemu rozumı ´ vs ˇichni), proto je tr ˇeba pouz ˇı ´vat jazyk jednodus ˇe, ve ˇdome ˇ a snaz ˇit se vyhnout be ˇz ˇny ´m pr ˇı ´c ˇina ´m chybne ´ interpretace * pr ˇı ´klad problematicke ´ definice: Pokud uz ˇivatel zada ´ jme ´no dels ˇı ´, nez ˇ je s ˇı ´r ˇka formula ´r ˇe, jeho pokrac ˇova ´nı ´ se zobrazı ´ na na ´sledujı ´cı ´ obrazovce. (Nejednoznac ˇne ´: zobrazı ´ se na na ´sledujı ´cı ´ obrazovce pokrac ˇova ´nı ´ jme ´na, nebo formula ´r ˇe?) * proto je tr ˇeba se snaz ˇit vyhnout: - dlouhy ´m souve ˇtı ´m s mnoha vedlejs ˇı ´mi ve ˇtami - pouz ˇı ´va ´nı ´ termı ´nu ˚ s ne ˇkolika pr ˇijatelny ´mi vy ´znamy - prezentaci ne ˇkolika poz ˇadavku ˚ jako jedine ´ho poz ˇadavku - nekonzistenci v pouz ˇ´ ıva ´nı ´ termı ´nu ˚, napr ˇ. pouz ˇı ´va ´nı ´ synonym.
zswi/p3req.d
zswi/p3req.d
3. ledna 2005
Pozna ´mka (me ˇr ˇenı ´ kvality DSP) V ne ˇktery ´ch pr ˇı ´padech (velmi rozsa ´hle ´ projekty) se pouz ˇı ´vajı ´ metriky me ˇr ˇı ´cı ´ kvalitu DSP. Me ˇr ˇit lze velikost a c ˇitelnost textu (de ´lka ve ˇt apod.), strukturu textu (hloubku struktury a de ´lka c ˇa ´stı ´). Slaba ´ mı ´sta specifikace lze najı ´t hleda ´nı ´m vy ´skytu neurc ˇity ´ch slov nebo fra ´zı ´ (ne ˇkolik, pr ˇedevs ˇı ´m) apod. [] * proto v syste ´movy ´ch specifikacı ´ch snaha pr ˇidat strukturu, ktera ´ pomu ˚z ˇe omezit nejednoznac ˇnosti * uvedeme zatı ´m pouze 2 moz ˇnosti: - formula ´r ˇe - pseudoko ´dy Formula ´r ˇe ......... * pr ˇirozeny ´ jazyk je pr ˇı ´lis ˇ flexibilnı ´, proto se ne ˇkdy pr ˇida ´va ´ (vynucuje) struktura pomocı ´ formula ´r ˇ˚ u - pro vyja ´dr ˇenı ´ poz ˇadavku ˚ definujete jeden nebo vı ´ce typu ˚ formula ´r ˇ˚ u - formula ´r ˇ by me ˇl obsahovat: . popis specifikovane ´ funkce nebo entity . popis vstupu ˚ a odkud se berou . popis vy ´stupu ˚ a kam putujı ´ . jake ´ dals ˇı ´ entity specifikovana ´ funkce nebo entita pouz ˇı ´va ´ . pr ˇı ´padne ´ vstupnı ´ a vy ´stupnı ´ podmı ´nky (pre-conditions a post-conditions), tj. co platı ´ pr ˇi vstupu do funkce a co pr ˇi vy ´stupu z nı ´ . pokud vznikajı ´ postrannı ´ efekty, pak jejich popis Pr ˇı ´klad syste ´move ´ specifikace funkce pro vkla ´da ´nı ´ prvku do diagramu, zapsana ´ ve forme ˇ formula ´r ˇe: -------------------------------------------------------------------Funkce: Vloz ˇ prvek do diagramu. Popis: Vloz ˇı ´ prvek do existujı ´cı ´ho diagramu. Uz ˇivatel urc ˇı ´ typ prvku a jeho pozici. Vstupy: Typ prvku, Pozice prvku, Identifika ´tor diagramu. Zdroje: Typ prvku a Pozici prvku zada ´ uz ˇivatel, Identifika ´tor diagramu zı ´ska ´me z databa ´ze diagramu ˚. Vy ´stupy: Identifika ´tor diagramu. ´loz U ˇis ˇte ˇ: Databa ´ze diagramu ˚. Pr ˇi dokonc ˇenı ´ operace je proveden COMMIT. Vyz ˇaduje: Diagram odpovı ´dajı ´cı ´ vstupnı ´mu Identifika ´toru diagramu. Vstupnı ´ podmı ´nka: Diagram je otevr ˇen a zobrazen na obrazovce uz ˇivatele. Vy ´stupnı ´ podmı ´nka: Diagram je nezme ˇne ˇn krome ˇ pr ˇida ´nı ´ prvku urc ˇene ´ho typu na urc ˇenou pozici. Vedlejs ˇı ´ efekty: Nejsou. -----------------------------------------------------------------------
Pr ˇı ´pady pouz ˇitı ´ ............... * use-cases [Jacobson at al. 1993] * pouz ˇı ´vajı ´ se zejme ´na pro popis kontextu syste ´mu a pro popis funkc ˇnı ´ch poz ˇadavku ˚ * za ´klad ne ˇktery ´ch metodik, napr ˇ. sbe ˇr poz ˇadavku ˚ v RUP, XP apod.
25
Za´klady softwarove´ho inzˇeny´rstvı´
26
* pr ˇı ´pady pouz ˇitı ´ jsou souc ˇa ´stı ´ graficke ´ notace UML (Unified Modeling Language) pro popis objektove ˇ orientovany ´ch modelu ˚ syste ´mu - stejny ´ typ diagramu je moz ˇne ´ pouz ˇı ´t pro popis chova ´nı ´ syste ´mu, podsyste ´mu nebo tr ˇı ´dy - podpora v modernı ´ch CASE na ´strojı ´ch * pr ˇı ´pad pouz ˇitı ´ reprezentuje vne ˇjs ˇı ´ pohled na syste ´m, modeluje zamy ´s ˇlene ´ fce syste ´mu a jeho vztah k okolı ´ * uz ˇivatele ´ a dals ˇı ´ syste ´my, ktere ´ mohou se SW syste ´mem interagovat, se nazy ´vajı ´ akte ´r ˇi (angl. actors), c ˇesky ne ˇkdy aktor ˇi nebo herci - v diagramu jsou akte ´r ˇi reprezentova ´ni jako pana ´c ˇci, na ´zev akte ´ra ma ´ by ´t uveden pod figurkou - akte ´r definuje koherentnı ´ mnoz ˇinu rolı ´, kterou uz ˇivatele ´ syste ´mu mohou hra ´t pr ˇi interakci se SW syste ´mem - akte ´rem nemusı ´ by ´t c ˇlove ˇk, mu ˚z ˇe to by ´t i jiny ´ syste ´m * tr ˇı ´dy interakce nazy ´va ´me ”pr ˇı ´pady pouz ˇitı ´” (angl. use cases) - v diagramu jsou zakresleny jako pojmenovana ´ elipsa, na ´zev mu ˚z ˇe by ´t umı ´ste ˇn v elipse nebo pod nı ´ - navenek se projevı ´ posloupnostı ´ zpra ´v vyme ˇne ˇny ´ch mezi syste ´mem a jednı ´m nebo vı ´ce akte ´ry * ´ uc ˇast akte ´ra na pr ˇı ´padu pouz ˇitı ´ se nazy ´va ´ ”asociace” a znac ˇı ´ se c ˇarou spojujı ´cı ´ akte ´ra s pr ˇı ´padem pouz ˇitı ´
Use Case Actor * akte ´r ˇi reprezentujı ´ uz ˇivatele syste ´mu, jejich znalost na ´m pomu ˚z ˇe urc ˇit hranici syste ´mu a co ma ´ syste ´m de ˇlat * na za ´klade ˇ potr ˇeb akte ´ru ˚ vytvor ˇı ´me pr ˇı ´pady pouz ˇitı ´ (uvidı ´me da ´le jak) * tı ´m zajistı ´me, z ˇe vytva ´r ˇeny ´ syste ´m bude spln ˇovat potr ˇeby uz ˇivatelu ˚
Uživatel knihovny
Výpůjčka knihy
* pouz ˇitı ´ pro modelova ´nı ´ kontextu syste ´mu - ma ´me-li jaky ´koli syste ´m, ne ˇktere ´ ve ˇci jsou uvnitr ˇ a ne ˇktere ´ vne ˇ - napr ˇ. telefonnı ´ sı ´t’ . uvnitr ˇ telefony, dra ´ty, ´ ustr ˇedny, ´ uc ˇtova ´nı ´ apod. . vne ˇ uz ˇivatele ´ sı ´te ˇ - kontext syste ´mu tvor ˇı ´ vs ˇe, co je vne ˇ syste ´mu a se syste ´mem interaguje - zakreslı ´me ohranic ˇenı ´m cele ´ho syste ´mu c ˇarou a urc ˇenı ´m akte ´ru ˚, kter ˇı ´ s nı ´m interagujı ´
Volání Telefonní účastník
Příjem hovoru Telefonní síť
* pouz ˇitı ´ pro modelova ´nı ´ poz ˇadavku ˚ na syste ´m - diagram pr ˇı ´padu ˚ pouz ˇitı ´ mu ˚z ˇe by ´t startovacı ´ bod pro uz ˇivatele i vy ´voja ´r ˇe - na zac ˇa ´tku potr ˇebujeme ve ˇde ˇt, co vs ˇechno ma ´ syste ´m de ˇlat, pozde ˇji k tomu pr ˇida ´va ´me podrobnosti - notace umoz ˇn ˇuje rozlis ˇit pr ˇı ´pady pouz ˇitı ´ na podpr ˇı ´pady pouz ˇı ´vane ´ ostatnı ´mi pr ˇı ´pady pouz ˇitı ´ a vytva ´r ˇet varianty, zava ´de ˇt vztahy zobecne ˇnı ´ a specializace akte ´ru ˚ (pozde ˇji uvedu podrobne ˇji).
zswi/p3req.d
zswi/p3req.d
3. ledna 2005
Pseudoko ´dy .......... * ne ˇkdy je funkce specifikova ´na jako posloupnost jednodus ˇs ˇı ´ch akcı ´, por ˇadı ´ je podstatne ´ * v pr ˇirozene ´m jazyce bychom obtı ´z ˇne ˇ vyjadr ˇovali napr ˇ. vnor ˇene ´ podmı ´nky nebo smyc ˇky * pak mu ˚z ˇe by ´t vhodne ´ doplnit specifikaci popisem v pseudoko ´du * pseuko ´d - jazyk s abstraktnı ´mi konstrukcemi, ktere ´ pra ´ve ˇ potr ˇebujeme (sekvence jednoduchy ´ch pr ˇı ´kazu ˚, iterace, ve ˇtvenı ´): - vnor ˇenı ´ konstrukcı ´ je vyja ´dr ˇeno odsazenı ´m - vyhy ´ba ´me se syntakticky ´m konstrukcı ´m cı ´love ´ho programovacı ´ho jazyka (ktere ´ by na ´s zbytec ˇne ˇ omezovaly a sva ´de ˇly k programova ´nı ´) - popisujeme poz ˇadovany ´ za ´me ˇr, nikoli jak bude v cı ´love ´m jazyce implementova ´n - na druhou stranu musı ´ umoz ˇn ˇovat te ´me ˇr ˇ automatickou konverzi do ko ´du (pokud pr ˇı ´lis ˇ vysoka ´ ´ uroven ˇ, nemusı ´me postr ˇehnout proble ´my ve specifikaci) Pr ˇı ´klad (c ˇa ´st popisu c ˇinnosti bankomatu): ------------------------------------------------------------------Pr ˇec ˇti kartu Vypis ˇ vy ´zvu: ”Prosı ´m zadejte PIN” Pr ˇec ˇti zadane ´_PIN Opakuj nejvy ´s ˇe 3x Pr ˇec ˇti zadane ´_PIN Jestliz ˇe zadane ´_PIN je PIN_karty pak opust’ smyc ˇku Jestliz ˇe zadane ´_PIN nenı ´ PIN_karty pak ... ------------------------------------------------------------------Pozna ´mka pro zajı ´mavost (pseudoko ´dy niz ˇs ˇı ´ ´ urovne ˇ) * ne ˇkter ˇı ´ autor ˇi (napr ˇ. Sommerville) doporuc ˇujı ´ pouz ˇı ´vat pseudoko ´d odvozeny ´ z konkre ´tnı ´ho programovacı ´ho jazyka, napr ˇ. z Javy nebo Pascalu - vy ´sledkem c ˇasto zbytec ˇne ˇ detailnı ´ specifikace, mı ´sto popisu za ´me ˇru urc ˇuje implementaci (= omezuje jı ´) - notace je srozumitelna ´ pouze lidem se znalostı ´ programovacı ´ho jazyka (uz ˇivatel by me ˇl specifikaci poz ˇadavku ˚ pokud moz ˇno rozume ˇt) - c ˇasto me ´ne ˇ pr ˇehledna ´ Pr ˇı ´klad (pseudoko ´d odvozeny ´ z Javy): ------------------------------------------------------------------class Bankomat { public static void main(String args[]) throws Neplatna ´Karta { try { tatoKarta.pr ˇec ˇti(); obrazovka.vy ´zva(”Prosı ´m zadejte PIN”); PIN = kla ´vesnice.pr ˇec ˇtiPIN(); pokusu ˚ = 1; while (!tatoKarta.PIN.rovno(PIN) & pokusu ˚ < 3) { obrazovka.vy ´zva(”Chybne ´ PIN - prosı ´m zadejte znovu”); pokusu ˚ = pokusu ˚ + 1; PIN = kla ´vesnice.pr ˇec ˇtiPIN(); } if (!tatoKarta.PIN.rovno(PIN)) throw new Neplatna ´Karta(”Chybne ´ PIN”); // Zde bychom jiz ˇ me ˇli mı ´t platne ´ PIN. ... ------------------------------------------------------------------[]
27
Za´klady softwarove´ho inzˇeny´rstvı´
28
Pozna ´mka (dals ˇı ´ pouz ˇitı ´ pseudoko ´du ˚) Podrobne ˇjs ˇı ´ pr ˇı ´klady pseudoko ´du ˚ uvedu pr ˇi popisu strukturovane ´ analy ´zy, kde se pseudoko ´dy pouz ˇı ´vajı ´ pro specifikaci tzv. procesu ˚; s pseudoko ´dy se potka ´me take ´ v te ´matu ko ´dova ´nı ´. [] * formula ´r ˇe vs. pseudoko ´d - formula ´r ˇe - celkova ´ specifikace syste ´mu - pseudoko ´d - r ˇı ´dı ´cı ´ sekvence, rozhranı ´ Specifikace rozhranı ´ .................... * pokud musı ´ novy ´ syste ´m komunikovat s dals ˇı ´mi syste ´my, musı ´ by ´t pr ˇesne ˇ specifikova ´no softwarove ´ nebo komunikac ˇnı ´ rozhranı ´ * specifikace rozhranı ´ me ˇla by by ´t souc ˇa ´stı ´ DSP, pokud je rozsa ´hla ´, tak v pr ˇı ´loze; me ˇla by by ´t vytvor ˇena brzy * 2 typy rozhranı ´, ktere ´ musejı ´ by ´t definova ´ny: - procedura ´lnı ´ rozhranı ´ - existujı ´cı ´ podsyste ´my poskytujı ´ mnoz ˇinu sluz ˇeb, ktere ´ jsou pr ˇı ´stupne ´ prostr ˇednictvı ´m vola ´nı ´ procedur rozhranı ´ - popis pr ˇeda ´vany ´ch dat . popis struktury dat - pro popis se pouz ˇı ´vajı ´ datove ´ modely, nejzna ´me ˇjs ˇı ´ jsou ERA diagramy . popis reprezentace dat, napr ˇ. ”datum je reprezentova ´n jako r ˇete ˇzec ...” * klasicky ´m pr ˇı ´kladem specifikace procedura ´lnı ´ho rozhranı ´ je popis knihovnı ´ch procedur nebo tr ˇı ´d programovacı ´ho jazyka - v klasicky ´ch jazycı ´ch napr ˇ. prototyp procedury nebo fce, popis vstupnı ´ch/vy ´stupnı ´ch parametru ˚, popis c ˇinnosti, na ´vratova ´ hodnota - objektovy ´ch jazycı ´ch napr ˇ. obecny ´ popis tr ˇı ´dy, popis konstruktoru ˚, popis metod
Zjednodus ˇeny ´ pr ˇı ´klad - definice rozhranı ´ s tiskovy ´m serverem: -------------------------------------------------------------------interface PrintServer { // definuje rozhranı ´ s tiskovy ´m serverem void initialize (Printer p); // inicializace tiska ´rny void print (Printer p, PrintDoc d); // tisk dokumentu PrintQueue queryPrintQueue (Printer p); // obsah tiskove ´ fronty void cancelPrintJob (Printer p, PrintDoc d); // zrus ˇenı ´ tisku dokumentu } //PrintServer -------------------------------------------------------------------* krome ˇ pr ˇirozene ´ho jazyka, formula ´r ˇ˚ u, pr ˇı ´padu ˚ pouz ˇitı ´ a pseudoko ´du ˚ se pro specifikaci poz ˇadavku ˚ jes ˇte ˇ pouz ˇı ´vajı ´ - graficke ´ notace - napr ˇ. ostatnı ´ diagramy UML (zatı ´m jsme vide ˇli pr ˇı ´pady pouz ˇitı ´) - forma ´lnı ´ (matematicka ´) specifikace (hodne ˇ jednoduchy ´ pr ˇı ´klad: konec ˇny ´ automat; ten lze zna ´zornit take ´ v UML)
Proces specifikace poz ˇadavku ˚ ---------------------------Na minule ´ pr ˇedna ´s ˇce jsme si uva ´de ˇli obecny ´ model fa ´ze specifikace poz ˇadavku ˚. Za nejdu ˚lez ˇite ˇjs ˇı ´ fa ´ze mu ˚z ˇeme povaz ˇovat: * sbe ˇr poz ˇadavku ˚ - od koho poz ˇadavky zı ´skat a jak * klasifikace poz ˇadavku ˚, detekce a r ˇes ˇenı ´ konfliktu ˚ (ne ˇkdy se nazy ´va ´ ”analy ´za poz ˇadavku ˚”, ale tento na ´zev se take ´ pouz ˇı ´va ´ v trochu jine ´m vy ´znamu, proto se mu vyhy ´ba ´m) * specifikace poz ˇadavku ˚ (ConOps a DSP) * validace poz ˇadavku ˚ (validace = ove ˇr ˇenı ´, kontrola).
zswi/p3req.d
zswi/p3req.d
3. ledna 2005
Ve skutec ˇnosti to nemusı ´ by ´t proces podle vodopa ´dove ´ho modelu, lze pouz ˇı ´t i spira ´lovy ´ model. Jednotlive ´ aktivity se opakujı ´, dokud nevznikne pr ˇijatelny ´ DSP. [Dokreslit obra ´zek: spira ´lovy ´ model podle SWEBOOK2001, p. 16] Pozna ´mka (na ´sledne ´ fa ´ze SW procesu) V maly ´ch syste ´mech mu ˚z ˇeme z DSP pokrac ˇovat pr ˇı ´mo tvorbou na ´vrhu syste ´mu. Pokud je syste ´m rozsa ´hly ´, jsou ne ˇkdy zapotr ˇebı ´ dals ˇı ´ (napr ˇ. 2-3) cykly analy ´zy, ktere ´ pr ˇida ´vajı ´ dals ˇı ´ podrobnosti a interpretujı ´ dome ´nove ´ poz ˇadavky pro vy ´voja ´r ˇe (aby byli schopni dome ´nove ´ poz ˇadavky spra ´vne ˇ interpretovat). Pote ´ je vy ´voj pr ˇeda ´n na ´vrha ´r ˇ˚ um. []
Sbe ˇr poz ˇadavku ˚ -------------* tato fa ´ze se zaby ´va ´ zdroji poz ˇadavku ˚ a zpu ˚sobem jejich zı ´ska ´va ´nı ´ * zdroje poz ˇadavku ˚ - je zapotr ˇebı ´ je identifikovat a vyhodnotit jejich vliv na syste ´m (pr ˇı ´klady zdroju ˚ poz ˇadavku ˚ : celkova ´ motivace syste ´mu, dome ´nove ´ znalosti, zadavatele ´ syste ´mu, provoznı ´ prostr ˇedı ´, prostr ˇedı ´ organizace) * pokud byly identifikova ´ny zdroje poz ˇadavku ˚, analytik nebo analytici zjis ˇt’ujı ´ poz ˇadavky na syste ´m od za ´stupcu ˚ zadavatele - je zapotr ˇebı ´ poc ˇı ´tat s tı ´m, z ˇe uz ˇivatele ´ mohou mı ´t potı ´z ˇe sve ´ poz ˇadavky vyja ´dr ˇit, mohou opomenout du ˚lez ˇite ´ informace, nebo nemusı ´ chtı ´t spolupracovat - je obtı ´z ˇne ´, i kdyz ˇ jsou zadavatele ´ dostupnı ´ a ochotnı ´ spolupracovat * existuje mnoho technik, z nich nejdu ˚lez ˇite ˇjs ˇı ´: - interview = pr ˇedem pr ˇipraveny ´ rozhovor - pr ˇ´ ıpady pouz ˇitı ´ - definice pr ˇı ´padu ˚ pouz ˇitı ´ se sce ´na ´r ˇi jejich pru ˚be ˇhu - tvorba prototypu ˚ - od papı ´rovy ´ch modelu ˚ obrazovek po SW prototypy; pomu ˚z ˇe uz ˇivateli le ´pe pochopit, jaka ´ informace se od ne ˇj poz ˇaduje - pozorova ´nı ´ pracı ´ u za ´kaznı ´ka pr ˇı ´padne ˇ ´ uc ˇast analytiku ˚ dodavatele na pracı ´ch u za ´kaznı ´ka (relativne ˇ drahe ´) - analy ´za existujı ´cı ´ho SW syste ´mu Da ´le struc ˇne ˇ popı ´s ˇeme interview a podrobne ˇji sbe ˇr poz ˇadavku ˚ na za ´klade ˇ pr ˇı ´padu ˚ pouz ˇitı ´. Interview ......... * nejc ˇaste ˇji forma zı ´ska ´va ´nı ´ poz ˇadavku ˚ - pr ˇedem pr ˇipraveny ´ rozhovor, ktery ´ vede modera ´tor (klade ota ´zky, da ´va ´ slovo) * nedoporuc ˇuje se trva ´nı ´ dels ˇı ´ nez ˇ 2 hodiny na setka ´nı ´ * doporuc ˇuje se pr ˇedem si pr ˇipravit sce ´na ´r ˇ - ktere ´ okruhy se budou probı ´rat, v jake ´m por ˇadı ´, sce ´na ´r ˇ se snaz ˇit nena ´silne ˇ dodrz ˇovat * napr ˇ. cı ´lene ´ interview ma ´ strukturu: - modera ´tor shrne ´ uc ˇel interview a jeho strukturu - posloupnost ota ´zek k jednotlivy ´m bodu ˚m - za ´ve ˇrec ˇne ´ shrnutı ´ + ove ˇr ˇenı ´, z ˇe informace byly spra ´vne ˇ pochopeny * ota ´zky by me ˇly by ´t otevr ˇene ´ - pr ˇ´ ıklady otevr ˇeny ´ch ota ´zek: . Co ma ´ syste ´m r ˇes ˇit? Jak to r ˇes ˇı ´te nynı ´? . Kdo bude uz ˇivatelem syste ´mu? . Je ne ˇco dals ˇı ´ho, na co bych se va ´s me ˇl zeptat? - pr ˇ´ ıklady uzavr ˇeny ´ch ota ´zek: . Je 50 poloz ˇek pr ˇime ˇr ˇene ´ mnoz ˇstvı ´? . Potr ˇebujete ve ˇts ˇı ´ formula ´r ˇ? * c ˇemu je vhodne ´ se vyhnout: - nenı ´ dobre ´ chtı ´t po uz ˇivatelı ´ch popis pr ˇı ´lis ˇ sloz ˇity ´ch aktivit (lide ´
29
Za´klady softwarove´ho inzˇeny´rstvı´
30
de ˇlajı ´ spoustu ve ˇcı ´, ktere ´ neume ˇjı ´ popsat, napr ˇ. zavazujı ´ si tkanic ˇky) - je dobre ´ se vyhnout ota ´zka ´m zac ˇı ´najı ´cı ´m ”Proc ˇ”, mohou vyprovokovat obranny ´ postoj
Sbe ˇr poz ˇadavku ˚ na za ´klade ˇ pr ˇı ´padu ˚ pouz ˇitı ´ (use-cases) ..................................................... * pro ve ˇts ˇinu lidı ´ je jednodus ˇs ˇı ´ zacha ´zet s pr ˇı ´pady z rea ´lne ´ho z ˇivota nez ˇ s abstraktnı ´m popisem - napr ˇ. doka ´z ˇı ´ pochopit a okomentovat sce ´na ´r ˇ toho, jak budou interagovat se SW syste ´mem - pr ˇi zı ´ska ´va ´nı ´ poz ˇadavku ˚ toho mu ˚z ˇeme vyuz ˇı ´t pro definici skutec ˇny ´ch poz ˇadavku ˚ * pr ˇehled vy ´voje modelu pr ˇı ´padu ˚ pouz ˇitı ´: - na za ´klade ˇ poz ˇadavku ˚ za ´kaznı ´ka najdeme akte ´ry a pr ˇı ´pady pouz ˇitı ´, struc ˇne ˇ je popı ´s ˇeme - model by me ˇl by ´t pr ˇezkouma ´n za ´kaznı ´kem . zda jsme nas ˇli vs ˇechny akte ´ry a pr ˇı ´pady pouz ˇitı ´ . zda dohromady poskytuje, co za ´kaznı ´k chce . v iterativnı ´m procesu vy ´voje pak mu ˚z ˇeme urc ˇit priority pr ˇı ´padu ˚ pouz ˇitı ´ a v kaz ˇde ´ iteraci vybrat mnoz ˇinu pr ˇı ´padu ˚ pouz ˇitı ´ pro podrobne ˇjs ˇı ´ specifikaci - specifikovat podrobne ˇ posloupnost uda ´lostı ´ pro kaz ˇdy ´ pr ˇı ´pad pouz ˇitı ´ - model mu ˚z ˇeme strukturovat - ´ uplny ´ model je pr ˇezkouma ´n, slouz ˇı ´ jako za ´klad dohody mezi vy ´voja ´r ˇi a za ´kaznı ´kem o tom, co ma ´ syste ´m de ˇlat Hleda ´nı ´ akte ´ru ˚ a pr ˇı ´padu ˚ pouz ˇitı ´: * da ´le uvedu konkre ´tnı ´ metodiku, pocha ´zejı ´cı ´ z RUP (Rational Unified Process) - vhodna ´ pro str ˇednı ´ a velke ´ syste ´my - c ˇasto se pouz ˇı ´va ´, protoz ˇe notace pr ˇı ´padu ˚ pouz ˇitı ´ je souc ˇa ´stı ´ UML a ma ´ podporu v CASE na ´strojı ´ch * svola ´me pracovnı ´ setka ´nı ´ pro hleda ´nı ´ pr ˇı ´padu ˚ pouz ˇitı ´ * je to brainstorming, potr ˇebujeme lidi ru ˚zny ´ch znalostı ´ a zkus ˇenostı ´ * je dobre ´, aby skupina byla mala ´ (< 10 lidı ´), polovina vy ´voja ´r ˇi a polovina za ´stupci za ´kaznı ´ka * prostr ˇednı ´kem mezi nimi modera ´tor - jako katalyza ´tor pro mys ˇlenky a pr ˇa ´nı ´ Postup: * * * * * *
identifikace akte ´ru ˚ identifikace pr ˇı ´padu ˚ pouz ˇitı ´ vytvor ˇenı ´ popisu pro kaz ˇdy ´ pr ˇı ´pad pouz ˇitı ´ popis toku uda ´lostı ´ pro kaz ˇdy ´ pr ˇı ´pad pouz ˇitı ´ strukturova ´nı ´ pr ˇı ´padu ˚ pouz ˇitı ´ identifikace analyticky ´ch tr ˇı ´d atd.
Postupne ˇ probereme: * identifikace akte ´ru ˚ - pokusı ´me se identifikovat, kdo nebo co bude pouz ˇı ´vat syste ´m - zac ˇneme konkre ´tnı ´mi lidmi, pak zkusı ´me identifikovat roli, kterou hrajı ´ pr ˇi interakci se syste ´mem (postup od konkre ´tnı ´ho k abstraktnı ´mu) - tı ´m zı ´ska ´me jme ´na akte ´ru ˚ - vz ˇdy zaznamenat popis - body zachycujı ´cı ´ roli vzhledem k syste ´mu, odpove ˇdnost - ”akte ´r ˇi” jsou i dals ˇı ´ syste ´my, se ktery ´mi na ´s ˇ syste ´m komunikuje (ikonka pana ´c ˇka pro akte ´ra je zde pone ˇkud mimo) - te ´to fa ´zi se nemusı ´me snaz ˇit akte ´ra ne ˇjak omezovat nebo strukturovat - na co se pta ´t: . kdo bude syste ´m pouz ˇı ´vat? . z jaky ´ch dals ˇı ´ch syste ´mu ˚ bude na ´s ˇ syste ´m pr ˇijı ´mat informace? . do jaky ´ch dals ˇı ´ch syste ´mu ˚ bude na ´s ˇ syste ´m doda ´vat informace? . kdo syste ´m spous ˇtı ´?
zswi/p3req.d
zswi/p3req.d
3. ledna 2005 . kdo udrz ˇuje informace o uz ˇivatelı ´ch?
- nakreslete obla ´c ˇek - po obou strana ´ch sloupec pana ´c ˇku ˚ , u kaz ˇde ´ho pana ´c ˇka jme ´no role Pozna ´mka: * mnoho akte ´ru ˚ mu ˚z ˇe mı ´t svou pevne ˇ danou pozici, napr ˇ. r ˇeditel * ne ˇkdy mu ˚z ˇe pozice odpovı ´dat vı ´ce rolı ´m, napr ˇ. sekreta ´r ˇka na KIV mu ˚z ˇe mı ´t zodpove ˇdnost za evidenci DP, za pr ˇide ˇlova ´nı ´ pr ˇı ´stupu do laborator ˇı ´ apod. => mu ˚z ˇou by ´t dva akte ´r ˇi syste ´mu * ne ˇkdy mu ˚z ˇeme dostat na ´vrh ”Me ˇla by tam by ´t taky Helenka” - pak je tr ˇeba urc ˇit jejı ´ roli nebo role - jme ´no akte ´ra by me ˇla by ´t role - pta ´me se: co je role Helenky? kdo jes ˇte ˇ mu ˚z ˇe zasta ´vat tuto roli? proc ˇ ma ´ Helenka tuto roli? [] Prakticke ´ triky: * pta ´me se, zda ne ˇco chybı ´ * navrhujeme s ˇpatna ´ r ˇes ˇenı ´, zbytek ty ´mu va ´s mu ˚z ˇe opravit a vysve ˇtlit, jake ´ jsou skutec ˇne ´ role v syste ´mu * vz ˇdycky pr ˇijme ˇte vs ˇechny na ´vrhy - je to brainstorming, tj. kritika ho spolehlive ˇ znic ˇı ´ (neakte ´ry, pr ˇı ´lis ˇ obecne ´ akte ´ry jako ”uz ˇivatel” a vı ´cena ´sobne ´ vy ´skyty akte ´ru ˚ mu ˚z ˇeme vyrus ˇit pozde ˇji) Pokud se mnoz ˇina akte ´ru ˚ jevı ´ jako ´ uplna ´, je c ˇas zac ˇı ´t s pr ˇı ´pady pouz ˇitı ´. * identifikace pr ˇı ´padu ˚ pouz ˇitı ´ - smaz ˇte z tabule velky ´ obla ´c ˇek a zac ˇne ˇte s definicı ´ pr ˇı ´padu ˚ pouz ˇitı ´ - pro kaz ˇdy ´ na ´vrh nakreslete elipsu, popis ˇte jı ´ a ude ˇlejte c ˇa ´ry nebo ˇipky k akte s ´ru ˚m (pr ˇedstavujı ´ pr ˇeda ´vane ´ zpra ´vy) - popiskou pr ˇı ´padu pouz ˇitı ´ mu ˚z ˇe by ´t cela ´ ve ˇta (zkra ´tit se mu ˚z ˇe pozde ˇji) - moz ˇno vycha ´zet z ruc ˇnı ´ho postupu zpracova ´nı ´ entit, jako napr ˇ. jak se zpracova ´va ´ objedna ´vka (abychom le ´pe vizualizovali, mu ˚z ˇeme si ne ˇkam jinam nakreslit sche ´ma/pla ´nek za ´kaznı ´kova obchodu apod.) - zatı ´m se nesnaz ˇte strukturovat, i kdyz ˇ pr ˇı ´pady pouz ˇitı ´ budou mı ´t spolec ˇne ´ c ˇa ´sti (zatı ´m toho o internı ´ struktur ˇe pr ˇı ´padu ˚ pouz ˇitı ´ vı ´me pr ˇı ´lis ˇ ma ´lo)
Výpůjční služby
Uživatel knihovny
Administrace uživatelů
Dodavatel
Zaměstnanec
Katalogizace
- po definici revize . podı ´vejme se na kaz ˇde ´ho akte ´ra - co je jeho ´ ulohou v syste ´mu? . podı ´vejme se na kaz ˇdy ´ pr ˇı ´pad pouz ˇitı ´ - je zr ˇejme ´, co akte ´r dosa ´hne pr ˇı ´padem pouz ˇitı ´?
31
Za´klady softwarove´ho inzˇeny´rstvı´
32
. je pr ˇı ´pad pouz ˇitı ´ ´ uplny ´ nebo je to jenom ve ˇts ˇı ´ c ˇa ´st ne ˇc ˇeho jine ´ho? - kaz ˇdy ´ akte ´r by me ˇl mı ´t alespon ˇ jeden pr ˇı ´pad pouz ˇitı ´ . pokud ne, mu ˚z ˇe by ´t akte ´r dals ˇı ´ vy ´skyt jine ´ho akte ´ra, tj. duplika ´t . nebo nenı ´ pr ˇı ´my ´m uz ˇivatelem syste ´mu . pokud diskuse neuka ´z ˇe nutnost zachova ´nı ´ akte ´ra, zrus ˇı ´me ho * vytvor ˇenı ´ popisu pro kaz ˇdy ´ pr ˇı ´pad pouz ˇitı ´ - zpracujte pr ˇı ´pad pouz ˇitı ´ jeden po druhe ´m, nejle ´pe na samostatne ´ c ˇtvrtky - nakreslete elipsu a popisku pro pr ˇı ´pad pouz ˇitı ´ - poz ˇa ´dejte skupinu o pomoc s vytvor ˇenı ´m struc ˇne ´ho popisu pr ˇı ´pad pouz ˇitı ´ (1-3 ve ˇty) - ne ˇkdy mu ˚z ˇe by ´t uz ˇitec ˇne ´ nakreslit akte ´ry spojene ´ s pr ˇı ´padem pouz ˇitı ´ - spodnı ´ polovinu papı ´ru ponechte pra ´zdnou pro dals ˇı ´ krok Pozna ´mka: Zde se ve ˇts ˇinou uka ´z ˇe, z ˇe ve ˇci, ktere ´ se zda ´ly by ´t jasne ´, ve skutec ˇnosti vu ˚ bec jasne ´ nejsou - mohou se objevit nove ´ pr ˇı ´pady pouz ˇitı ´ a ne ˇktere ´ stare ´ mohou zaniknout. [] * popis toku uda ´lostı ´ pro kaz ˇdy ´ pr ˇı ´pad pouz ˇitı ´ - ope ˇt probı ´ra ´me pr ˇı ´pad pouz ˇitı ´ jeden po druhe ´m - budeme hledat 5 az ˇ 10 za ´kladnı ´ch kroku ˚ (tı ´m r ˇı ´ka ´me ´ uroven ˇ podrobnosti) - za ´pis kroku ˚ v por ˇadı ´, c ˇı ´slujeme 1, 2, 3, ... - pak kroky projdeme, identifikujeme alternativnı ´ kroky, c ˇı ´slujeme napr ˇ. A1, A2..., nebo a) b) ... - nesnaz ˇı ´me se r ˇes ˇit, jak bude vypadat ko ´d (smyc ˇky apod.), ale poznamena ´me si vs ˇechny nejasnosti (musı ´me je vyr ˇes ˇit pr ˇed vytvor ˇenı ´m DSP) * vytvor ˇte dopln ˇkovou specifikaci - pro funkc ˇnı ´ poz ˇadavky, ktere ´ se nety ´kajı ´ z ˇa ´dne ´ho pr ˇı ´padu pouz ˇitı ´ - pro mimofunkc ˇnı ´ poz ˇadavky - mohou se ty ´kat vlastnosti konkre ´tnı ´ho pr ˇ´ ıpadu pouz ˇitı ´ nebo obecne ´ vlastnosti syste ´mu * pro dals ˇı ´ zacha ´zenı ´ je du ˚lez ˇite ´, co chceme dosa ´hnout: - ne ˇktere ´ projekty pouz ˇı ´vajı ´ pr ˇı ´pady pouz ˇitı ´ pouze neforma ´lne ˇ pro sbe ˇr poz ˇadavku ˚, poz ˇadavky ale zapisujı ´ a uchova ´vajı ´ jiny ´m zpu ˚sobem - ne ˇktere ´ projekty mohou pokrac ˇovat dals ˇı ´mi fa ´zemi: . vytvor ˇı ´me podrobne ˇjs ˇı ´ specifikaci pr ˇı ´padu ˚ pouz ˇitı ´ . pr ˇı ´pady pouz ˇitı ´ a akte ´ry strukturujeme (do pr ˇı ´padu pouz ˇitı ´ mu ˚z ˇeme doplnit sekvenci akcı ´ z jine ´ho pr ˇı ´padu pouz ˇitı ´ apod.) . z chova ´nı ´ pr ˇı ´padu ˚ pouz ˇitı ´ uz ˇ mu ˚z ˇeme identifikovat tzv. analyticke ´ tr ˇı ´dy atd. - konkre ´tnı ´ volba za ´visı ´ na velikosti projektu, dostupny ´ch na ´strojı ´ch atd.
Klasifikace poz ˇadavku ˚, detekce a r ˇes ˇenı ´ konfliktu ˚ ------------------------------------------------V te ´to fa ´zi se zaby ´va ´me na ´sledujı ´cı ´mi c ˇinnostmi: * nestrukturovanou mnoz ˇinu poz ˇadavku ˚ se snaz ˇı ´me logicky uspor ˇa ´dat * rozlis ˇı ´me funkc ˇnı ´, mimofunkc ˇnı ´ a dome ´nove ´ poz ˇadavky, uz ˇivatelske ´ a syste ´move ´ - potr ˇebujeme je odde ˇlit v DSP * detekujeme a r ˇes ˇı ´me konflikty mezi poz ˇadavky. Klasifikace a uspor ˇa ´da ´nı ´ poz ˇadavku ˚ .................................. Poz ˇadavky mohou by ´t klasifikova ´ny podle ru ˚zny ´ch krite ´riı ´, napr ˇ. na: * poz ˇadavky na funkce a mimofunkc ˇnı ´ poz ˇadavky (viz minula ´ pr ˇedna ´s ˇka) * podle priority, napr ˇ. na nutne ´, z ˇa ´doucı ´, vhodne ´, volitelne ´ (c ˇasto je zapotr ˇebı ´ vzı ´t v ´ uvahu take ´ cenu vy ´voje) * podle rozsahu; napr ˇ. ne ˇktere ´ mimofunkc ˇnı ´ poz ˇadavky jsou globa ´lnı ´, zatı ´mco ne ˇktere ´ poz ˇadavky na funkce je moz ˇne ´ zme ˇnit, aniz ˇ by me ˇly vliv na ostatnı ´ fce syste ´mu
zswi/p3req.d
zswi/p3req.d
3. ledna 2005
* podle pravde ˇpodobnosti zme ˇny na trvale ´ a nesta ´le ´ poz ˇadavky; pro vy ´voja ´r ˇe mu ˚z ˇe by ´t snazs ˇı ´ reagovat na zme ˇnu, pokud v DSP oznac ˇı ´me poz ˇadavek jako nesta ´ly ´ Da ´le uvedu ne ˇkolik pr ˇı ´kladu ˚, jaky ´m zpu ˚sobem je moz ˇne ´ nestrukturovane ´ poz ˇadavky uspor ˇa ´dat. Nejprve pr ˇı ´klad nestrukturovane ´ho poz ˇadavku: 2.2.15 Zobrazova ´nı ´ mr ˇı ´z ˇky. 2.2.15.1 Aby bylo moz ˇne ´ umist’ovat entity do diagramu, uz ˇivatel mu ˚z ˇe zapnout zobrazova ´nı ´ mr ˇı ´z ˇky bud’ v centimetrech nebo v palcı ´ch, a to pomocı ´ volby na r ˇı ´dı ´cı ´m panelu. Na poc ˇa ´tku se mr ˇı ´z ˇka nezobrazuje. Mr ˇı ´z ˇka mu ˚z ˇe by ´t vypnuta a zapnuta kdykoli be ˇhem relace a kdykoli mu ˚z ˇe by ´t pr ˇepnuta mezi centimetry nebo palci. Moz ˇnost zobrazovat mr ˇı ´z ˇku bude i pro zmens ˇene ´ pohledy, ale poc ˇet r ˇa ´dku ˚ mr ˇı ´z ˇky bude omezen tak, aby mr ˇı ´z ˇka pr ˇi prohlı ´z ˇenı ´ zmens ˇene ´ho obra ´zku nerus ˇila. [] Prvnı ´ ve ˇta sme ˇs ˇuje 3 typy poz ˇadavku ˚: 1. Koncepc ˇnı ´ funkc ˇnı ´ poz ˇadavek - editor ma ´ poskytovat mr ˇı ´z ˇku. 2. Mimofunkc ˇnı ´ poz ˇadavek - jednotky mr ˇı ´z ˇky. 3. Mimofunkc ˇnı ´ poz ˇadavek na UI - mr ˇı ´z ˇku bude zapı ´nat a vypı ´nat uz ˇivatel. Vy ´s ˇe uvedena ´ specifikace ma ´ navı ´c na ´sledujı ´cı ´ potı ´z ˇe: * je neu ´plna ´ - chybı ´ inicializac ˇnı ´ informace - jakou jednotku bude mr ˇı ´z ˇka pouz ˇı ´vat po zapnutı ´? * sme ˇˇ suje uz ˇivatelske ´ a syste ´move ´ poz ˇadavky * zdu ˚ vodne ˇnı ´ poz ˇadavku nenı ´ vyde ˇleno Pr ˇı ´klad uz ˇivatelske ´ specifikace - pr ˇepsa ´nı ´ s vynecha ´nı ´m detailu ˚: 2.2.15 Mr ˇı ´z ˇka editoru. 2.2.15.1 Editor bude poskytovat moz ˇnost zobrazit mr ˇı ´z ˇku, tj. matrici horizonta ´lnı ´ch a vertika ´lnı ´ch c ˇar zobrazeny ´ch na pozadı ´ editoru. Mr ˇı ´z ˇka bude pasivnı ´ a urc ˇova ´nı ´ pozice jednotlivy ´ch elementu ˚ bude za ´lez ˇitostı ´ uz ˇivatele. Zdu ˚vodne ˇnı ´: Mr ˇı ´z ˇka uz ˇivateli pomu ˚z ˇe le ´pe rozmist’ovat elementy diagramu. I kdyz ˇ aktivnı ´ mr ˇı ´z ˇka (tj. takova ´, kde se elementy ”pr ˇilepujı ´” k c ˇara ´m mr ˇı ´z ˇky) mu ˚z ˇe by ´t uz ˇitec ˇna ´, je takove ´ umist’ova ´nı ´ nepr ˇesne ´. Umı ´ste ˇnı ´ entit urc ˇı ´ nejle ´pe uz ˇivatel. [] * du ˚lez ˇite ´ uva ´de ˇt zdu ˚vodne ˇnı ´ - pokud dojde ke zme ˇne ˇ poz ˇadavku ˚, mu ˚z ˇeme urc ˇit, co vedlo k pu ˚vodnı ´mu poz ˇadavku Dals ˇı ´ pr ˇı ´klad - podrobne ˇjs ˇı ´ uz ˇivatelska ´ specifikace: 2.2.456 Pr ˇida ´nı ´ prvku do diagramu. 2.2.456.1 Editor bude poskytovat moz ˇnost vloz ˇit do diagramu prvek urc ˇene ´ho typu. 2.2.456.2 Pro vloz ˇenı ´ prvku bude pouz ˇita na ´sledujı ´cı ´ posloupnost akcı ´: 1. Uz ˇivatel vybere typ prvku, ktery ´ ma ´ by ´t vloz ˇen. 2. Uz ˇivatel pr ˇesune kurzor pr ˇibliz ˇne ˇ na pozici, kam ma ´ by ´t prvek vloz ˇen a signalizuje, z ˇe prvek ma ´ by ´t na pozici vloz ˇen. 3. Uz ˇivatel by me ˇl prvek posunout na jeho konec ˇnou pozici. Zdu ˚vodne ˇnı ´: Umı ´ste ˇnı ´ prvku ˚ urc ˇı ´ nejle ´pe uz ˇivatel. [] * popis obsahuje seznam akcı ´ uz ˇivatele (ne ˇkdy nezbytne ´), neobsahuje ale implementac ˇnı ´ detaily (napr ˇ. jak se posouvajı ´ symboly). Detekce a r ˇes ˇenı ´ konfliktu ˚ ..........................
33
Za´klady softwarove´ho inzˇeny´rstvı´
34
* pokud zjistı ´me konflikt (viz take ´ validace poz ˇadavku ˚), musı ´me r ˇes ˇit - konflikt mu ˚z ˇe nastat napr ˇ. pokud dva uz ˇivatele ´ poz ˇadujı ´ vza ´jemne ˇ nesluc ˇitelne ´ vlastnosti nebo mezi poz ˇadovany ´mi schopnostmi a dany ´mi omezenı ´mi - ve ve ˇts ˇine ˇ pr ˇı ´padu ˚ nenı ´ vhodne ´, aby rozhodli vy ´voja ´r ˇi - c ˇasto je du ˚lez ˇite ´, aby konkre ´tnı ´ rozhodnutı ´ bylo moz ˇne ´ vysledovat zpe ˇt ke konkre ´tnı ´mu za ´stupci zadavatele (viz take ´ da ´le - spra ´va poz ˇadavku ˚)
Specifikace poz ˇadavku ˚ --------------------Po uspor ˇa ´da ´nı ´ poz ˇadavky specifikujeme v DSP (viz vy ´s ˇe). Po specifikaci na ´sleduje validace (ove ˇr ˇenı ´) poz ˇadavku ˚.
Validace poz ˇadavku ˚ -----------------* vstupem ´ uplny ´ DSP * musı ´me zjistit, zda jsou poz ˇadavky ´ uplne ´, konzistentnı ´ a zda odpovı ´dajı ´ tomu, co zadavatel od syste ´mu chce * co vs ˇechno je tr ˇeba kontrolovat: - platnost poz ˇadavku ˚ . uz ˇivatel si myslı ´, z ˇe syste ´m ma ´ poskytovat urc ˇite ´ funkce, ale podrobne ˇjs ˇı ´ analy ´za mu ˚z ˇe uka ´zat ne ˇco jine ´ho . ru ˚ znı ´ uz ˇivatele ´ majı ´ ru ˚zne ´ poz ˇadavky, bude kompromis platny ´? - konzistenci - poz ˇadavky v dokumentu nesme ˇjı ´ by ´t v konfliktu, tj. nesme ˇjı ´ by ´t ru ˚zne ´ popisy nebo ru ˚zna ´ omezenı ´ stejne ´ fce - ´ uplnosti poz ˇadavku ˚ - definova ´ny by me ˇly by ´t vs ˇechny fce a omezenı ´ syste ´mu - kontrola realizovatelnosti - zda mu ˚z ˇe by ´t syste ´m implementova ´n, zda mu ˚z ˇe by ´t implementova ´n s dany ´mi prostr ˇedky a v dane ´m c ˇase - ove ˇr ˇitelnost - syste ´move ´ poz ˇadavky by me ˇly by ´t napsa ´ny tak, aby byly ove ˇr ˇitelne ´ (us ˇetr ˇı ´me si dohadova ´nı ´ se za ´kaznı ´kem pr ˇi pr ˇeda ´va ´nı ´ produktu) - sledovatelnost pu ˚vodu poz ˇadavku - abychom doka ´zali odhadnout dopad zme ˇny Pouz ˇitelne ´ metody: * * * *
pr ˇezkouma ´nı ´ (reviews) prototypova ´nı ´ tvorba testu ˚ automaticka ´ analy ´za konzistence.
* pr ˇezkouma ´nı ´ (reviews) - poz ˇadavky jsou systematicky zkontrolova ´ny ty ´mem - manua ´lnı ´ proces, vı ´ce c ˇtena ´r ˇ˚ u od za ´kaznı ´ka i od kontraktora - mu ˚z ˇe by ´t forma ´lnı ´ nebo neforma ´lnı ´ . nejc ˇaste ˇji forma ´lnı ´ pr ˇezkouma ´nı ´ DSP = vy ´vojovy ´ ty ´m prova ´zı ´ klienta syste ´movy ´mi poz ˇadavky, vysve ˇtluje du ˚sledky kaz ˇde ´ho poz ˇadavku, pr ˇitom kontroluje konzistenci, ´ uplnost atd. (konkre ´tnı ´ technika - viz ”Inspekce ko ´du” v pr ˇedna ´s ˇce o testova ´nı ´) . neforma ´lnı ´ = diskuse poz ˇadavku ˚ s tolika za ´stupci za ´kaznı ´ka, s kolika je to moz ˇne ´ * prototypova ´nı ´ - za ´kaznı ´kovi pr ˇedvedeme spustitelny ´ model syste ´mu, mu ˚z ˇe zjistit, zda odpovı ´da ´ poz ˇadavku ˚m - napr ˇ. chova ´nı ´ uz ˇivatelske ´ho rozhranı ´ za ´kaznı ´k nejle ´pe pochopı ´ pomocı ´ prototypu - nevy ´hodou prototypu ˚ - pozornost uz ˇivatele budou odva ´de ˇt kosmeticke ´ za ´lez ˇitosti nebo omezenı ´ prototypu - proto je v podobny ´ch pr ˇı ´padech doporuc ˇova ´no se SW prototypu ˚m vyhnout a pouz ˇı ´t napr ˇ. papı ´rovy ´ model obrazovek * generova ´nı ´ testovacı ´ch pr ˇı ´padu ˚ - pokud vytvor ˇı ´me testy poz ˇadavku ˚, c ˇasto odhalı ´me proble ´my; pokud je obtı ´z ˇne ´ vytvor ˇit test, bude poz ˇadavek obtı ´z ˇne ˇ implementovatelny ´ * automaticka ´ analy ´za konzistence - pokud byly poz ˇadavky specifikova ´ny
zswi/p3req.d
zswi/p3req.d
3. ledna 2005 jako model ve forma ´lnı ´ nebo strukturovane ´ notaci, mu ˚z ˇeme konzistenci modelu zkontrolovat automaticky.
Spra ´va poz ˇadavku ˚ ---------------* poz ˇadavky na velky ´ syste ´m se neusta ´le me ˇnı ´ (du ˚vody byly uva ´de ˇny pru ˚be ˇz ˇne ˇ) * spra ´va c ˇili management poz ˇadavku ˚ je proces r ˇı ´zenı ´ zme ˇn syste ´movy ´ch poz ˇadavku ˚ * z hlediska vy ´voje se poz ˇadavky de ˇlı ´ na trvale ´ a nesta ´le ´ poz ˇadavky - trvale ´ poz ˇadavky . relativne ˇ stabilnı ´, jsou odvozeny ze za ´kladnı ´ funkce organizace nebo z aplikac ˇnı ´ dome ´ny . napr ˇ. v nemocnici budeme mı ´t vz ˇdy pacienty, le ´kar ˇe a sestry; v bance budeme mı ´t vz ˇdy klienty, ´ uc ˇty apod. - nesta ´le ´ poz ˇadavky . pravde ˇpodobne ˇ se zme ˇnı ´ be ˇhem vy ´voje nebo po uvedenı ´ syste ´mu do provozu . napr ˇ. nemocnice - pravde ˇpodobne ˇ se zme ˇnı ´ syste ´m plateb od zdravotnı ´ch pojis ˇt’oven . nebo banka - me ˇnı ´ se podmı ´nky pro zı ´ska ´nı ´ ´ uve ˇru apod. * management poz ˇadavku ˚ by me ˇl zac ˇı ´t pla ´nova ´nı ´m, v ne ˇm se rozhodne - zpu ˚ sob identifikace poz ˇadavku ˚ - kaz ˇdy ´ poz ˇadavek by me ˇl mı ´t jedinec ˇny ´ identifika ´tor, napr ˇ. c ˇı ´slo, abychom ho mohli odkazovat (kr ˇı ´z ˇove ´ reference apod.) - proces zme ˇny poz ˇadavku ˚ - definujeme proces, abychom se ke zme ˇna ´m poz ˇadavku ˚ chovali konzistentnı ´m zpu ˚sobem - viz nı ´z ˇe - sledovatelnost - ktere ´ vztahy mezi poz ˇadavky navza ´jem atd. budeme uchova ´vat a jak (c ˇı ´m vı ´ce, tı ´m draz ˇs ˇı ´) . zdroj poz ˇadavku - kdo poz ˇadavek navrhl, du ˚vod; abychom se mohli ”zdroje” zeptat na podrobnosti . vztahy mezi poz ˇadavky v DSP; pro urc ˇenı ´ kolika poz ˇadavku ˚ se zme ˇna dotkne . vztahy mezi poz ˇadavky a designem syste ´mu; pro urc ˇenı ´ dopadu zme ˇny na syste ´movy ´ design a implementaci - jake ´ na ´stroje se pouz ˇijı ´ pro uchova ´va ´nı ´ informacı ´ o poz ˇadavcı ´ch (male ´ projekty - postac ˇujı ´ obvykle ´ prostr ˇedky jako textove ´ a tabulkove ´ procesory, databa ´ze; velke ´ projekty - CASE na ´stroje)
Sledovatelnost poz ˇadavku ˚ ........................ Sledovatelnost poz ˇadavku ˚ (traceability) znamena ´ moz ˇnost sledovat poz ˇadavky zpe ˇt k jejich zdroji (napr ˇ. z DSP zpe ˇt k poz ˇadavku v ConOps dokumentu, ze ktere ´ho vyply ´va ´), dopr ˇedu k na ´vrhu nebo SW artefaktu, ktery ´ ho implementuje (napr ˇ. z DSP k digramu tr ˇı ´d nebo ke komponente ˇ), nebo pr ˇı ´padne ˇ za ´vislosti poz ˇadavku ˚ mezi sebou navza ´jem. * jedna moz ˇnost - matice za ´vislostı ´ poz ˇadavku ˚ - mapuje napr ˇ. vza ´jemne ´ za ´vislosti poz ˇadavku ˚ - prvky - jak za ´visı ´ poz ˇadavek v r ˇa ´dku na poz ˇadavcı ´ch dany ´ch sloupcem - U (Uses) - poz ˇadavek v r ˇa ´dku pouz ˇı ´va ´ moz ˇnosti dane ´ poz ˇadavkem - R (Relates) - ne ˇjaky ´ slabs ˇı ´ vztah, napr ˇ. oba c ˇa ´sti stejne ´ho podsyste ´mu Id poz ˇ. 1.1 1.2 1.3 1.4 1.5 1.1 . U R . . 1.2 . . U . . 1.3 R . . . . * matice za ´vislosti lze pouz ˇı ´vat pr ˇi male ´m mnoz ˇstvı ´ poz ˇadavku ˚, ale pokud je poz ˇadavku ˚ mnoho, byla by jejı ´ ´ udrz ˇba draha ´ * pak by za ´vislosti me ˇla zachycovat pr ˇı ´mo databa ´ze poz ˇadavku ˚ - souc ˇa ´st CASE na ´stroju ˚ pro spra ´vu poz ˇadavku ˚ Pozna ´mka (na ´stroje pro spra ´vu poz ˇadavku ˚) Modernı ´ na ´stroje pro spra ´vu poz ˇadavku ˚ c ˇasto umı ´ vygenerovat matici nebo graf
35
Za´klady softwarove´ho inzˇeny´rstvı´
36
za ´vislostı ´, graficky zna ´zornit propagaci zme ˇn, generovat zpra ´vy o stavu poz ˇadavku ˚, generovat DSP podle zvolene ´ho standardu apod. [] Proces zme ˇny poz ˇadavku ˚ ...................... * vs ˇechny navrhovane ´ zme ˇny poz ˇadavku ˚ by me ˇly podle ´hat procesu o tr ˇech za ´kladnı ´ch krocı ´ch: - analy ´za proble ´mu a specifikace zme ˇny - analy ´za zme ˇny a urc ˇenı ´ jejı ´ ceny - implementace zme ˇny * analy ´za proble ´mu a specifikace zme ˇny - identifikujeme proble ´m ne ˇktere ´ho poz ˇadavku nebo dostaneme na ´vrh zme ˇny - zjis ˇt’ujeme, zda je proble ´m nebo zme ˇna poz ˇadavku platna ´ - vy ´sledkem mu ˚z ˇe by ´t podrobne ˇjs ˇı ´ na ´vrh zme ˇny poz ˇadavku * analy ´za zme ˇny a urc ˇenı ´ jejı ´ ceny - zjistı ´me du ˚sledky zme ˇny (k tomu se na ´m hodı ´ mı ´t informace o za ´vislosti poz ˇadavku ˚ atd.) - urc ˇı ´me, jakou zme ˇnu DSP, pr ˇı ´padne ˇ i designu a implementace by bylo tr ˇeba prove ´st - odhadneme cenu zme ˇny, pr ˇı ´padne ˇ odhad nove ´ho termı ´nu dokonc ˇenı ´ - po dokonc ˇenı ´ analy ´zy padne rozhodnutı ´, zda budeme pokrac ˇovat realizacı ´ zme ˇny (Pr ˇijdeme za za ´kaznı ´kem: Sta ´lo by to X, budete to chtı ´t ted’ nebo pozde ˇji?) * implementace zme ˇny - modifikujeme DSP, pr ˇı ´padne ˇ design a implementaci Prakticka ´ pozna ´mka: Pokud je poz ˇadavek na zme ˇnu urgentnı ´, je tlak na to prove ´st zme ˇnu nejdr ˇı ´ve v implementaci, a pak zpe ˇtne ˇ modifikovat DSP. To nevyhnutelne ˇ vede k tomu, z ˇe se DSP a implementace rozejdou: na zac ˇlene ˇnı ´ zme ˇny do DSP se bud’ zapomene, nebo je DSP zme ˇne ˇn nekonzistentne ˇ se zme ˇnou implementace.
❉
zswi/p4oo.d
zswi/p4oo.d
3. ledna 2005
KIV/ZSWI 2004/2005 Pr ˇedna ´s ˇka 4 ´vod do OO terminologie U ======================= I should mention that I was the one who made up the unfortunate term ”object-oriented” in the mid60s (I should have called it something else). In any case, I have some strong ideas about what this term means and should mean. --Alan Kay, 02/2004 Za poc ˇa ´tek objektove ˇ orientovane ´ho programova ´nı ´ se povaz ˇuje vznik jazyka Simula67 (Norwegian Computing Centre, asi 1967). Prvnı ´m c ˇiste ˇ objektove ˇ orientovany ´m jazykem byl jazyk Smalltalk-80, vyvinuty ´ v Xerox PARC (spolu s prvnı ´m osobnı ´m poc ˇı ´tac ˇem, prvnı ´m okennı ´m prostr ˇedı ´m, mys ˇı ´, Ethernetem atd.). ˇiste C ˇ objektove ˇ orientovany ´ jazyk = vs ˇechno je objekt, vc ˇetne ˇ za ´kladnı ´ch datovy ´ch typu ˚ a r ˇı ´dı ´cı ´ch konstrukcı ´. Pozde ˇji se objevily dals ˇı ´ OO jazyky (C++, Objective C, Eiffel, Python, Java (c ˇti [dz ˇava]), C# (c ˇti [sı ´ s ˇarp] nebo c ˇesky [cis])... Objektova ´ orientovanost se postupne ˇ rozs ˇı ´r ˇila do vs ˇech fa ´zı ´ vy ´voje SW vznikly a sta ´le jes ˇte ˇ vznikajı ´ objektove ˇ orientovane ´ metodiky pro analy ´zu, na ´vrh, implementaci, testova ´nı ´, zpe ˇtne ´ inz ˇeny ´rstvı ´ (reverse engineering) a pr ˇepracova ´nı ´ ko ´du (refactoring) atd. V dals ˇı ´m textu si nejprve uvedeme za ´kladnı ´ motivaci, terminologii a pote ´ metodiku OO analy ´zy a na ´vrhu. Proc ˇ objektove ˇ orientovane ´ programova ´nı ´? ........................................ Vy ´voj na ´stroju ˚ pro tvorbu SW (napr ˇ. programovacı ´ch jazyku ˚) odra ´z ˇı ´ nutnost vytva ´ˇ ret a zacha ´zet se sta ´le rozsa ´hlejs ˇı ´mi celky. Nema ´me-li k dispozici pr ˇime ˇˇ renou technologii, nazy ´va ´me takovy ´ stav ”krize”; r ˇes ˇenı ´m krize je zme ˇna paradigmatu (napr ˇ. postupne ˇ rozs ˇı ´r ˇenı ´ strukturovane ´ho, objektove ˇ orientovane ´ho a komponentove ˇ orientovane ´ho programova ´nı ´). * historicky prvnı ´ programovacı ´ jazyky (asseblery a FORTRAN) byly nestrukturovane ´ - za ´kladnı ´ r ˇı ´dı ´cı ´ konstrukcı ´ byl skok - pr ˇı ´kaz GOTO (spustı ´ prova ´de ˇnı ´ instrukcı ´ od zadane ´ho na ´ve ˇs ˇtı ´) - srozumitelnost silne ˇ klesa ´ s velikostı ´ projektu - proto snaha vne ´st strukturu - tzv. strukturovane ´ programova ´nı ´
32132 EPS=EPS*ABS(H3) 32134 IF DETA>EPS THEN GOTO 32142 32136 FOR I=1 TO NEQUA 32138 Y[I]=Y0[I]:NEXT I 32140 X=X0: GOTO 32150 32142 IF LAST=0 THEN GOTO 32148 32144 IF STAR<=0 THEN GOTO 32162 32146 STP=H:GOTO 32162 32148 IF EPS=0 THEN GOTO 32054 32150 H=(DETA/EPS)0.2*0.8*H 32152 IF ABS(H)>=1.0E−05 THEN GOTO 32156 32154 H=1.0E−05*(H/ABS(H)) 32156 STP=H 32158 STAR=−1 32160 GOTO 32046
a) nestrukturovaný kód v jazyku BASIC
A:=1; B:=1; for I:=2 to N do begin C:=A+B; A:=B; B:=C end;
b) strukturovaný kód v jazyku Pascal
* strukturovane ´ programova ´nı ´ podporujı ´ vs ˇechny modernı ´ imperativnı ´ programovacı ´ jazyky - ve strukturovane ´m ko ´du snadne ˇji vidı ´me, ktere ´ c ˇa ´sti jednoho podprogramu se k sobe ˇ vztahujı ´ a jak - s rostoucı ´ velikostı ´ programu ˚ ale ope ˇt proble ´m: pr ˇı ´lis ˇ mnoho ve ˇcı ´ a vztahu ˚, ktere ´ musı ´me bra ´t do ´ uvahy najednou . ”ve ˇci” = podprogramy, funkce a data . ”vza ´jemne ´ vztahy” = ktere ´ podprogramy na sobe ˇ za ´visejı ´, jake ´ pouz ˇı ´vajı ´ datove ´ struktury - proto sdruz ˇova ´nı ´ souvisejı ´cı ´ch podprogramu ˚ a dat do modulu ˚ tak, aby zme ˇna jednoho modulu me ˇla minima ´lnı ´ dopad na obsah ostatnı ´ch modulu ˚
37
Za´klady softwarove´ho inzˇeny´rstvı´
38 = data
= procedura/funkce
a) jeden celek
b) totéž rozděleno do modulů
* strukturovane ˇ navrz ˇene ´ syste ´my se ale c ˇasem obtı ´z ˇne ˇ udrz ˇujı ´ - pr ˇi strukturovane ´m programova ´nı ´ se zaby ´va ´me zvla ´s ˇt’ funkcemi a zvla ´s ˇt’ daty . fce jsou aktivnı ´, majı ´ chova ´nı ´ . data jsou pasivnı ´, jsou zpracova ´va ´na funkcemi . proble ´m: fce musejı ´ zna ´t strukturu dat . pokud se zme ˇnı ´ struktura dat (zme ˇna poz ˇadavku ˚), je tr ˇeba zme ˇnit vs ˇechny fce pracujı ´cı ´ s datovou strukturou . pokud ma ´me zpracova ´vat podobna ´ data, do vs ˇech fcı ´ musı ´me pr ˇidat podmı ´nky . tı ´m vzru ˚sta ´ ”entropie” (neuspor ˇa ´danost) SW; pokud dosa ´hne urc ˇite ´ho limitu, cena modifikacı ´ naroste tak, z ˇe je ekonomicky neobhajitelne ´ syste ´m nada ´le udrz ˇovat => je nutne ´ syste ´m pr ˇestrukturovat * souvisejı ´cı ´ proble ´m: se ´manticka ´ mezera mezi externı ´m a internı ´m pohledem na syste ´m (tj. mezi aplikac ˇnı ´ dome ´nou a vytva ´r ˇeny ´m syste ´mem) - potr ˇebujeme, aby mala ´ zme ˇna poz ˇadavku ˚ vedla k male ´ zme ˇne ˇ syste ´mu . pozorova ´nı ´: ”co” ma ´ syste ´m de ˇlat se me ˇnı ´ me ´ne ˇ, nez ˇ ”jak” to ma ´ syste ´m de ˇlat . r ˇes ˇenı ´ - mapova ´nı ´ mezi skutec ˇnostı ´, konceptua ´lnı ´m modelem a syste ´mem by me ˇlo by ´t co nejjednodus ˇs ˇı ´ (napr ˇ. faktura -> datovy ´ typ ”faktura”) * dals ˇı ´ proble ´m - znovupouz ˇitelnost ko ´du v dals ˇ´ ıch aplikacı ´ch - proc ˇ knihovny procedura ´lnı ´ch programovacı ´ch jazyku ˚ (C, Pascal, FORTRAN...) obsahujı ´ pouze fce pome ˇrne ˇ nı ´zke ´ ´ urovne ˇ? - v klasicky ´ch procedura ´lnı ´ch jazycı ´ch nelze vysokou ´rovn ˇovou funkc ˇnost snadno pr ˇene ´st z jednoho kontextu do druhe ´ho - nutno vytva ´r ˇet znovu - r ˇes ˇenı ´: principy abstrakce, zapouzdr ˇenı ´ a de ˇdic ˇnosti podporovane ´ programovacı ´m jazykem = objektove ˇ orientovane ´ programova ´nı ´ (viz da ´le) * dals ˇı ´ krok po OO stejny ´m sme ˇrem bude pravde ˇpodobne ˇ komponentove ˇ orientovane ´ programova ´nı ´ a objektove ˇ orientovane ´ aplikac ˇnı ´ ra ´mce
Za ´kladnı ´ koncepce OO technologie -------------------------------* pojem ”objektove ˇ orientovany ´” znamena ´ pr ˇibliz ˇne ˇ to, z ˇe SW je organizova ´n jako mnoz ˇina objektu ˚, ktere ´ spolu komunikujı ´ - objekty sluc ˇujı ´ data a nad nimi pracujı ´cı ´ fce => zme ˇny budou le ´pe lokalizova ´ny - tı ´m, z ˇe proble ´m strukturujeme do objektu ˚ existujı ´cı ´ch v aplikac ˇnı ´ dome ´ne ˇ => mens ˇı ´ se ´manticka ´ mezera mezi aplikac ˇnı ´ dome ´nou a modelem - ne ˇktere ´ objekty mohou slouz ˇit jako znovupouz ˇitelne ´ komponenty (napr ˇ. univerza ´lnı ´ kontejner) - pokud cely ´ vy ´voj probı ´ha ´ objektove ˇ orientovany ´m (da ´le jen ”OO”) zpu ˚sobem, mu ˚z ˇeme pro vs ˇechny fa ´ze vy ´voje pouz ˇı ´vat stejnou terminologii a grafickou notaci (i kdyz ˇ objekty budou na ru ˚zne ´ ´ urovni obecnosti/abstrakce) * na zac ˇa ´tku analy ´za poz ˇadavku ˚ = zaby ´va ´ se vytva ´r ˇenı ´m konceptua ´lnı ´ho modelu studovane ´ho syste ´mu * pr ˇi postupu k implementaci zjemn ˇujeme pr ˇedchozı ´ model pr ˇida ´va ´nı ´m detailu ˚ a novy ´ch objektu ˚ poskytujı ´cı ´ch funkc ˇnost * protoz ˇe informace je ukryta v objektech, mu ˚z ˇe by ´t rozhodnutı ´ o konkre ´tnı ´ realizaci dat odloz ˇeno az ˇ na implementaci * v ne ˇktery ´ch pr ˇı ´padech mu ˚z ˇeme obdobne ˇ odloz ˇit rozhodnutı ´ o distribuci objektu ˚ a zda budou sekvenc ˇnı ´ nebo paralelnı ´ - mu ˚z ˇe za ´viset na prostr ˇedı ´, kde budou be ˇz ˇet * napr ˇ. v analy ´ze poz ˇadavku ˚ modelujeme syste ´m jako mnoz ˇinu interagujı ´cı ´ch objektu ˚ aplikac ˇnı ´ dome ´ny, tj. entit a operacı ´ sdruz ˇeny ´ch s r ˇes ˇeny ´m proble ´mem (napr ˇ. nemocnice: pacienti, sestry, le ´kar ˇi, vy ´kony...) * v OO na ´vrhu vytva ´r ˇı ´me OO model SW syste ´mu, ktery ´ bude poz ˇadavky identifikovane ´ v analy ´ze implementovat
zswi/p4oo.d
zswi/p4oo.d
3. ledna 2005
- ne ˇktere ´ objekty aplikac ˇnı ´ dome ´ny budou odpovı ´dat objektu ˚m implementace, ale pr ˇi postupu k implementaci je tr ˇeba vytva ´r ˇet dals ˇı ´ objekty * pr ˇi OO implementaci realizujeme syste ´m v OO jazyce jako je napr ˇ. Java Pozna ´mka (modelovacı ´ jazyk UML) Podobne ˇ jako se v elektrotechnice pouz ˇı ´vajı ´ sche ´mata, pouz ˇı ´vajı ´ se pr ˇi na ´vrhu SW syste ´mu ˚ modely. Ru ˚zne ´ modely zachycujı ´ ru ˚zne ´ klı ´c ˇove ´ vlastnosti studovane ´ho syste ´mu a vynecha ´vajı ´ detaily (podobne ˇ jako el. sche ´mata vynecha ´vajı ´ velikost a rozmı ´ste ˇnı ´ prvku ˚ ). Te ´me ˇr ˇ vs ˇechny modely majı ´ ne ˇjakou grafickou notaci s textovy ´m popisem. Pro popis objektove ˇ orientovany ´ch modelu ˚ budeme pouz ˇı ´vat notaci UML (Unified Modeling Language, 1996), ktera ´ se stala de-facto standardem pro modelova ´nı ´ OO syste ´mu ˚. UML podporuje mnoho CASE na ´stroju ˚ (Rational Rose, Together, MagicDraw, Fujaba...). Pr ˇed vznikem UML existovalo nejme ´ne ˇ 50 ru ˚zny ´ch notacı ´, ne ˇktere ´ z nich mu ˚z ˇete jes ˇte ˇ najı ´t napr ˇ. v novy ´ch pr ˇekladech stars ˇı ´ literatury. [] V literatur ˇe existujı ´ urc ˇite ´ neshody v tom, co pr ˇesne ˇ znamena ´ pojem ”objektove ˇ orientovany ´”, nicme ´ne ˇ ve ˇts ˇina autoru ˚ se shoduje na te ˇchto za ´kladnı ´ch principech: 1. 2. 3. 4.
abstrakce zapouzdr ˇenı ´ de ˇdic ˇnost polymorfismus
Abstrakce ......... [Rumbaugh: OMT, Sigfied: Understanding OOSE, Cox: OOP] * abstrakce = zame ˇr ˇenı ´ se na podstatne ´ vlastnosti entity a zanedba ´nı ´ detailu ˚, ktere ´ jsou pro dany ´ ´ uc ˇel nepodstatne ´ - pr ˇi OO modelova ´nı ´ umoz ˇn ˇuje zame ˇr ˇit se nejprve na to, co objekt je a co de ˇla ´ - detaily (napr ˇ. na ´vrh a implementaci) doplnı ´me, az ˇ budeme proble ´mu le ´pe rozume ˇt - nakonec se sice musı ´me detaily zaby ´vat, ale mu ˚z ˇeme je napr ˇ. vhodne ˇ uspor ˇa ´dat za pouz ˇitı ´ vrstvene ´ abstrakce (vrstvena ´ abstrakce = vysokou ´rovn ˇova ´ abstrakce je popsa ´na pomocı ´ nı ´zkou ´rovn ˇovy ´ch abstrakcı ´) Zapouzdr ˇenı ´ ........... [Gosling-McGilton: The Java Language Environment. 1996] * zapouzdr ˇenı ´ (encapsulation) = entita ma ´ dobr ˇe definovane ´ rozhranı ´ a ukrytou vnitr ˇnı ´ reprezentaci * v OO r ˇes ˇenı ´ proble ´mu je jednotkou zapouzdr ˇenı ´ objekt - zver ˇejn ˇuje rozhranı ´ - mnoz ˇinu nabı ´zeny ´ch operacı ´ - skry ´va ´ implementaci - objekt mu ˚z ˇeme pouz ˇı ´vat podle jeho specifikace neza ´visle na vnitr ˇnı ´ implementaci (ktera ´ se mu ˚z ˇe zme ˇnit) veřejné rozhraní atributy metody
skrytá implementace
a) objekt
b) vyvolání operace zasláním stimulu
Pr ˇı ´klad: Pr ˇı ´kladem zapouzdr ˇenı ´ v rea ´lne ´m sve ˇte ˇ je napr ˇ. auto: ovla ´da ´ se pomocı ´ volantu, spojky, brzdy, plynu atd. - te ´me ˇr ˇ vs ˇechna auta ovla ´da ´me podobne ˇ
39
Za´klady softwarove´ho inzˇeny´rstvı´
40
zswi/p4oo.d
neza ´visle na jejich vnitr ˇnı ´ implementaci. Objekt ...... * objekt je entita, ktera ´ ma ´ jedinec ˇnou identitu, stav a mnoz ˇinu operacı ´, ktere ´ pracujı ´ se stavem (me ˇnı ´ stav, zjis ˇt’ujı ´ stav, vyvolajı ´ urc ˇite ´ chova ´nı ´) * identita objektu trva ´ po celou dobu existence objektu, pomocı ´ nı ´ se na objekt odkazujeme * stav objektu je reprezentova ´n mnoz ˇinou atributu ˚ objektu * operace sdruz ˇene ´ s objektem poskytujı ´ sluz ˇby jiny ´m objektu ˚m (klientu ˚m) * klienti vyvolajı ´ operaci zasla ´nı ´m stimulu (stimuly se c ˇasto nazy ´vajı ´ ”zpra ´vy”, i kdyz ˇ nemusejı ´ nutne ˇ ne ´st informaci) Pr ˇı ´klad (objekty na vysoke ´ ´ urovni abstrakce): Objekty mohou odpovı ´dat objektu ˚m rea ´lne ´ho sve ˇta. Objektem na urc ˇite ´ ´ urovni abstrakce mu ˚z ˇe by ´t napr ˇ. ”Honza Voma ´c ˇka”, jeho atributy budou napr ˇ. ”ve ˇk 18 let”, ”vy ´s ˇka 177 cm”, operacemi mu ˚z ˇe by ´t ”jez”, ”pij” apod. [] Tr ˇı ´da ..... * tr ˇı ´da objektu popisuje skupinu objektu ˚ stejnou strukturou (atributy), chova ´nı ´m (operacemi), vztahy k ostatnı ´m objektu ˚m a vy ´znamem - objekty dane ´ tr ˇı ´dy majı ´ obdobny ´ vy ´znam - napr ˇ. i kdyz ˇ ku ˚n ˇ i sta ´j majı ´ atributy ”sta ´r ˇı ´” a ”cena”, pravde ˇpodobne ˇ budou patr ˇit do ru ˚zny ´ch tr ˇı ´d - sdruz ˇova ´nı ´m objektu ˚ do tr ˇı ´d abstrahujeme spolec ˇne ´ vlastnosti objektu ˚ * objekty stejne ´ tr ˇı ´dy = instance tr ˇı ´dy * atributy i operace objektu ˚ jsou deklarova ´ny jejich tr ˇı ´dou * v OO jazycı ´ch se objekty vytva ´r ˇejı ´ podle definice tr ˇı ´dy Pr ˇı ´klad (tr ˇı ´da na vysoke ´ ´ urovni abstrakce): Objekty ”Honza Voma ´c ˇka” a ”Kater ˇina Drsna ´” mohou by ´t instancemi tr ˇı ´dy ˇlove C ˇk. I kdyz ˇ se ”Kater ˇina Drsna ´” vda ´ a bude mı ´t nove ´ jme ´no, jejı ´ identita se tı ´m nezme ˇnı ´ (identita je neza ´visla ´ na stavu objektu). [] * notace pro tr ˇı ´dy a instance v UML: - tr ˇ´ ıdy - zna ´zorn ˇujı ´ se jako obde ´lnı ´k se jme ´nem tr ˇı ´dy (jme ´no tuc ˇne ˇ a vycentrovat) a dve ˇma volitelny ´mi sekcemi . str ˇednı ´ sekce = atributy objektu (”attributes”) . spodnı ´ sekce = operace objektu (”operations”) - instance - podobne ˇ, jme ´no ve tvaru: ”objekt” : ”Tr ˇı ´da” (podtrz ˇene ´), lze zkra ´tit i jen na ”objekt” nebo : ”Tr ˇı ´da” (viz obra ´zek) . pr ˇı ´padne ˇ atributy, ktere ´ na ´s zajı ´majı ´, a jejich hodnota
Person name: string address: string dateOfBirth: date ... eat () drink () a) třída
osoba p1: Person name = "Honza Vomáčka" address = "Neurcitá 32, Plzeň" dateOfBirth = 1.4.1990
: Person name = "Jana Vomáčková" address = "Neurčitá 32, Plzeň" dateOfBirth = 24.12.1999
b) instance třídy
* termı ´n ”operace” se pouz ˇı ´va ´ pro akci, termı ´n ”metoda” pro implementaci operace * v OO jazycı ´ch se metody se spous ˇte ˇjı ´ zasla ´nı ´m zpra ´vy bud’ samotne ´ tr ˇı ´de ˇ, aby vytvor ˇila objekt, nebo jiz ˇ vytvor ˇene ´mu objektu * zpra ´vu zas ˇleme / metodu vyvola ´me napr ˇ.
zswi/p4oo.d
3. ledna 2005
41
adresa ´t_zpra ´vy.metoda(argumenty);
// Java, C#
[ adresa ´t_zpra ´vy metoda argumenty ]
// Objective C
nebo
* v ne ˇktery ´ch distribuovany ´ch syste ´mech je zasla ´nı ´ zpra ´vy implementova ´no pr ˇı ´mo odesla ´nı ´m textove ´ zpra ´vy - pr ˇı ´jemce ve zpra ´ve ˇ najde poz ˇadovanou operaci a data, podle na ´zvu operace urc ˇı ´ metodu, vyvola ´ ji a pr ˇeda ´ jı ´ data * pokud objekty koexistujı ´ ve stejne ´m programu, vyvola ´nı ´ metod je implementova ´no obdobne ˇ jako vola ´nı ´ procedury v Pascalu nebo v C komunikace je synchronnı ´ * pokud jsou objekty implementova ´ny pomocı ´ paralelnı ´ch procesu ˚ nebo vla ´ken, mu ˚z ˇe by ´t operace asynchronnı ´ => volajı ´cı ´ mu ˚z ˇe pokrac ˇovat, zatı ´mco se sluz ˇba vykona ´va ´, popı ´s ˇeme pozde ˇji De ˇdic ˇnost ......... * angl. inheritance * ne ˇktere ´ tr ˇı ´dy budou mı ´t spolec ˇne ´ vlastnosti ˇena budou mı * napr ˇ. tr ˇı ´dy Muz ˇ a Z ´t mnoho spolec ˇny ´ch vlastnostı ´ (operace ”jez” a ”pij”, atributy ”jme ´no”, ”adresa”, ”datum narozenı ´”) * spolec ˇne ´ vlastnosti mu ˚z ˇeme sdı ´let tak, z ˇe je vyjmeme a vloz ˇı ´me do samostatne ´ tr ˇı ´dy Osoba (pouz ˇı ´vajı ´ se termı ´ny generalizace, zobecne ˇnı ´) - ostatnı ´ tr ˇı ´dy tyto spolec ˇne ´ vlastnosti (atributy a operace) mohou sdı ´let mechanismem de ˇde ˇnı ´ ˇena mu - ve tr ˇı ´da ´ch Muz ˇ a Z ˚z ˇeme popsat jenom nove ´ vlastnosti - pokud je zapotr ˇebı ´ modifikovat spolec ˇne ´ chova ´nı ´, stac ˇı ´ zme ˇnit v definici Osoby * ne ˇkdy prova ´dı ´me specializaci existujı ´cı ´ tr ˇı ´dy - najdeme tr ˇı ´du, ktera ´ poskytuje operace a atributy potr ˇebne ´ pro novou tr ˇı ´du, nova ´ tr ˇı ´da je zde ˇdı ´ a pr ˇida ´ nove ´ vlastnosti - napr ˇ. specializacı ´ tr ˇı ´dy Zame ˇstnanec mu ˚z ˇe by ´t Programa ´tor, ktery ´ bude mı ´t dals ˇı ´ atributy (”programovacı ´ jazyk”) a operace (”programuj”) * zobecn ˇova ´nı ´m a specializacı ´ vznika ´ hierarchie tr ˇı ´d - pr ˇedkove ´, nadtr ˇı ´dy (ancestors, super-classes) - jsou obecne ˇjs ˇı ´, jednodus ˇs ˇı ´ - potomci, podtr ˇı ´dy (descendants, sub-classes) - specializovane ˇjs ˇı ´, sloz ˇite ˇjs ˇı ´ * v UML se de ˇdic ˇnost zna ´zorn ˇujeme s ˇipkou, ktera ´ vede k rodic ˇovske ´ tr ˇı ´de ˇ - tr ˇi tec ˇky (...) znamenajı ´, z ˇe c ˇa ´st modelu nenı ´ zobrazena - zna ´zorne ˇny jsou dve ˇ varianty pro kreslenı ´ s ˇipek
Shape
OpenShape
Line
Spline
Shape
Box
Circle
ClosedShape
OpenShape
ClosedShape ...
Line
Spline
Box
...
Center Radius
Center Radius
a) shared target style
Circle
b) separate target style
draw()
...
* pr ˇedkove ´ vytvor ˇenı ´ pouze pro ´ uc ˇel de ˇde ˇnı ´ ostatnı ´mi se nazy ´vajı ´ abstraktnı ´ tr ˇı ´dy - nevytva ´r ˇejı ´ se z nich instance - v UML se na ´zev abstraktnı ´ tr ˇı ´dy zobrazuje kurzı ´vou * de ˇdic ˇnost mu ˚z ˇe by ´t jednoducha ´ a vı ´cena ´sobna ´ (multiple inheritance) - jednoducha ´ = kaz ˇda ´ tr ˇı ´da de ˇdı ´ pouze z jedne ´ rodic ˇovske ´ tr ˇı ´dy - vı ´cena ´sobna ´ = tr ˇı ´da mu ˚z ˇe mı ´t vı ´ce nez ˇ jednoho rodic ˇe . vı ´cena ´sobna ´ de ˇdic ˇnost zvys ˇuje sloz ˇitost hierarchie tr ˇı ´d, pravde ˇpodobnost koncepc ˇnı ´ch chyb, je obtı ´z ˇne ˇ srozumitelna ´ atd., proto jı ´ mnoho OO jazyku ˚ nepodporuje (napr ˇ. Java; toto omezenı ´ je moz ˇne ´ v pr ˇı ´pade ˇ potr ˇeby obejı ´t vytva ´r ˇenı ´m tzv. sloz ˇeny ´ch tr ˇı ´d)
Za´klady softwarove´ho inzˇeny´rstvı´
42
zswi/p4oo.d
. v UML vı ´cena ´sobnou de ˇdic ˇnost zna ´zorn ˇujeme:
Plavidlo
Vozidlo
Obojživelné vozidlo
* ne ˇkdy musı ´me hierarchii tr ˇı ´d pr ˇestrukturovat, abychom zı ´skali vhodnou tr ˇı ´du, ze ktere ´ bychom mohli de ˇdit - napr ˇı ´klad v na ´sledujı ´cı ´m obra ´zku ma ´me hierarchii tr ˇı ´d s vlastnostmi ”a”, ”abc”, ”abcd”, ”abce” a potr ˇebujeme tr ˇı ´du s vlastnostmi ”abf” - ze souc ˇasne ´ hierarchie tr ˇı ´d nenı ´ moz ˇne ´ takovou tr ˇı ´du zı ´skat de ˇde ˇnı ´m, musı ´me pr ˇestrukturovat
má: a b c
máme:
potřebujeme:
ClassA a
ClassX a b f
ClassBC b c
dotaneme: ClassA a ClassB b
přestrukturování
ClassD d
ClassE e
má: a b c d
má: a b c e
ClassC c
ClassD d
má: a b f ClassF f
ClassE e
* ve vy ´s ˇe uvedene ´m obra ´zku take ´ uka ´zka UML notace pro pozna ´mky: - obde ´lnı ´k s pr ˇehnuty ´m pravy ´m hornı ´m rohem, pr ˇipojen pr ˇerus ˇovanou c ˇarou * pouz ˇitı ´ de ˇdic ˇnosti v praxi: - sdı ´lenı ´ ko ´du - pr ˇi na ´vrhu mohu sdı ´let ko ´d mezi podobny ´mi tr ˇı ´dami - mohu si pr ˇizpu ˚sobit existujı ´cı ´ tr ˇı ´du (napr ˇ. z minule ´ho projektu) - koncepc ˇnı ´ zjednodus ˇenı ´ - zmens ˇenı ´ poc ˇtu neza ´visly ´ch vlastnostı ´ syste ´mu * tradic ˇnı ´ pravidla pro pouz ˇitı ´ de ˇdic ˇnosti: - nova ´ tr ˇı ´da musı ´ obsahovat vs ˇechny atributy pu ˚ vodnı ´ tr ˇı ´dy, lze pr ˇida ´vat nove ´ atributy - nova ´ tr ˇı ´da musı ´ rozume ˇt stejny ´m zpra ´va ´m jako pu ˚vodnı ´ tr ˇı ´da, lze pr ˇida ´vat nove ´ operace - implementace metody mu ˚z ˇe by ´t v podtr ˇı ´de ˇ zme ˇne ˇna, neme ˇl by se ale zme ˇnit jejı ´ vy ´znam (pak uz ˇ by nebylo c ˇiste ´ zobecne ˇnı ´/specializace) * nespra ´vne ´ pouz ˇitı ´ de ˇdic ˇnosti - pokud mezi tr ˇı ´dami nenı ´ vztah zobecne ˇnı ´/specializace ale napr ˇ. vztah kompozice (okno nenı ´ specializace domu, ale du ˚m mu ˚z ˇe krome ˇ jine ´ho obsahovat okna) - jiny ´mi slovy: de ˇdic ˇnost bychom neme ˇli pouz ˇı ´vat pouze jako mechanismus pro ”vypu ˚jc ˇenı ´ si” ko ´du bez ohledu na cokoli, protoz ˇe tı ´m zaneseme do modelu konceptua ´lnı ´ proble ´my a do ko ´du skryte ´ pr ˇedpoklady Polymorfismus ............. * pokud bychom v klasicke ´m procedura ´lnı ´m programovacı ´m jazyku potr ˇebovali vytisknout dva geometricke ´ obrazce (reprezentovane ´ datovy ´mi strukturami typu ”c ˇtverec” a ”obde ´lnı ´k”), nejspı ´s ˇe bychom pro to me ˇli k dispozici samostatne ´ procedury: tiskni_c ˇtverec(a); tiskni_troju ´helnı ´k(b); * v OO jazycı ´ch najdeme mechanismus polymorfismu = moz ˇnost zası ´lat stejnou
zswi/p4oo.d
3. ledna 2005
zpra ´vu ru ˚zny ´m objektu ˚m, ktere ´ na ni odpovı ´ kaz ˇdy ´ svy ´m zpu ˚sobem - napr ˇ. ve vy ´s ˇe uvedene ´m pr ˇı ´pade ˇ mu ˚z ˇe kaz ˇdy ´ objekt mı ´t metodu ”vytiskni_se”, vyvola ´me: a.vytiskni_se; b.vytiskni_se;
// vytiskne se c ˇtverec // vytiskne se troju ´helnı ´k
- pr ˇı ´jemce zpra ´vy mu ˚z ˇe patr ˇit do libovolne ´ tr ˇı ´dy implementujı ´cı ´ metodu ”vytiskni_se”, vysı ´lajı ´cı ´ nemusı ´ zna ´t konkre ´tnı ´ tr ˇı ´du pr ˇı ´jemce - pokud bychom me ˇli napr ˇ. seznam skla ´dajı ´cı ´ se ze c ˇtvercu ˚ a troju ´helnı ´ku ˚, mohli bychom napsat ne ˇco jako: foreach anObject in list anObject.vytiskni_se;
// projdi vs ˇechny objekty v seznamu ”list” // vyvolej jejich metodu ”vytiskni_se”
- napr ˇı ´klad kaz ˇdy ´ objekt mu ˚z ˇe mı ´t metodu ”uloz ˇ se do souboru” apod. - zvy ´s ˇenı ´ flexibility * ve ˇts ˇinou se polymorfismus omezuje (omezeny ´ polymorfismus) - napr ˇı ´klad zpra ´vu ”vykresli se na obrazovku” ma ´ smysl posı ´lat pouze graficky ´m objektu ˚m (c ˇa ´ra, obde ´lnı ´k...)
Paralelnı ´ objekty ................. * objekty koncepc ˇne ˇ z ˇa ´dajı ´ o provedenı ´ sluz ˇby zasla ´nı ´m ”zpra ´vy”, v tom nenı ´ explicitnı ´ poz ˇadavek na se ´riove ´ vykona ´va ´nı ´ - napr ˇ. pokud bychom chte ˇli vytisknout soubor (a.printFile(f)), bylo by pr ˇirozene ´, kdyby volajı ´cı ´ nemusel c ˇekat na dokonc ˇenı ´ tisku - obecny ´ model dovoluje objektu ˚m be ˇz ˇet paralelne ˇ (napr ˇ. na stejne ´m poc ˇı ´tac ˇi nebo jako distribuovane ´ objekty na ru ˚ zny ´ch strojı ´ch) - kdyby se ale jednalo napr ˇ. o zavr ˇenı ´ dver ˇı ´ vy ´tahu (a.closeDoors), mohlo by mı ´t paralelnı ´ provedenı ´ nepr ˇı ´jemne ´ du ˚ sledky - ve ˇts ˇinou pr ˇedpokla ´da ´me na ´vrat ve chvı ´li, kdy je to bezpec ˇne ´ - v UML se paralelismus operace oznac ˇuje pr ˇipojenı ´m vlastnosti { concurrency = concurrent }
Printer printFile() {concurrent}
* ve ˇts ˇina jazyku ˚ implementuje vyvola ´nı ´ metody stejne ˇ jako vola ´nı ´ fce, tj. volajı ´cı ´ objekt je pozastaven do dokonc ˇenı ´ operace * ne ˇktere ´ jazyky (napr ˇ. Java) umoz ˇn ˇujı ´ vytva ´r ˇet paralelne ˇ be ˇz ˇı ´cı ´ objekty * existujı ´ dva druhy implementace paralelne ˇ be ˇz ˇ´ ıcı ´ch objektu ˚: - servery - objekt je implementova ´n jako paralelne ˇ be ˇz ˇı ´cı ´ proces, metody odpovı ´dajı ´ operacı ´m . metoda se spustı ´ jako odpove ˇd’ na pr ˇı ´chozı ´ poz ˇadavek, mu ˚z ˇe be ˇz ˇet paralelne ˇ s metodami sdruz ˇeny ´mi s ostatnı ´mi objekty . po dokonc ˇenı ´ se objekt pozastavı ´ a c ˇeka ´ na dals ˇı ´ zpra ´vu = poz ˇadavek - aktivnı ´ objekty - stav objektu se mu ˚z ˇe me ˇnit internı ´ operacı ´ samotne ´ho objektu . proces pr ˇedstavujı ´cı ´ objekt be ˇz ˇı ´ neusta ´le nebo svu ˚j stav upravuje v urc ˇity ´ch intervalech, napr ˇ. v RT syste ´mu zjis ˇt’uje stav okolı ´ . napr ˇ. v Jave ˇ - udrz ˇuje informaci o pozici letadla pomocı ´ satelitnı ´ho navigac ˇnı ´ho syste ´mu: class Transponder extends Thread { Position currentPosition; Coords c1, c2; Satellite sat1, sat2; Navigator navigator; public Position givePosition() {
43
Za´klady softwarove´ho inzˇeny´rstvı´
44
zswi/p4oo.d
return currentPosition; } public void run() { // zavola ´ se po vytvor ˇenı ´ vla ´ken while (true) { c1 = sat1.position(); c2 = sat2.position(); currentPosition = navigator.compute(c1, c2); } } } //Transponder
Modelovacı ´ jazyk UML ==================== * modelova ´nı ´ = na ´vrh aplikace pr ˇed ko ´dova ´nı ´m * model hraje stejnou roli pr ˇi vy ´voji SW jako studie a projektova ´ dokumentace pr ˇi stavbe ˇ domu - tj. slouz ˇı ´ pro vizualizaci na ´vrhu, kontrolu a dokumentaci pr ˇed zaha ´jenı ´m realizace (ko ´dova ´nı ´) * model abstrahuje za ´kladnı ´ detaily skutec ˇnosti nebo vytva ´r ˇene ´ho syste ´mu * standardnı ´ notace pro OO modelova ´nı ´ je UML * UML definuje 12 typu ˚ diagramu ˚ rozde ˇleny ´ch do 3 kategoriı ´: - struktura ´lnı ´ diagramy (diagram tr ˇı ´d, diagram objektu ˚, diagram komponent a diagram nasazenı ´ - vs ˇechny popisujı ´ statickou strukturu syste ´mu) - diagramy chova ´nı ´ (diagram pr ˇı ´padu ˚ pouz ˇitı ´ - ne ˇktere ´ metodiky ho pouz ˇı ´vajı ´ pro sbe ˇr poz ˇadavku ˚, diagram spolupra ´ce a sekvenc ˇnı ´ diagram - pro popis komunikace, stavovy ´ diagram a diagram c ˇinnostı ´) - diagramy pro spra ´vu a strukturova ´nı ´ modelu ˚ (balı ´c ˇky, podsyste ´my a modely) Diagram tr ˇı ´d a diagram objektu ˚ -----------------------------* diagram tr ˇı ´d ukazuje tr ˇı ´dy a vztahy mezi nimi (zobecne ˇnı ´, asociace, agregace...) - vztahy zobecne ˇnı ´ (de ˇdic ˇnosti) uz ˇ byly popsa ´ny, uka ´z ˇeme si dals ˇı ´ typy vztahu ˚ Asociace ........ * asociace r ˇı ´ka ´, z ˇe objekty ktere ´ jsou instancemi jedne ´ tr ˇı ´dy, mohou mı ´t vztah s objekty jine ´ nebo stejne ´ tr ˇı ´dy * napr ˇ. objekty tr ˇı ´dy Zame ˇstnanec budou mı ´t asociaci k objektu ˚m tr ˇı ´dy Odde ˇlenı ´ * v UML se zna ´zorn ˇujı ´ plnou c ˇarou mezi tr ˇı ´dami, u c ˇa ´ry volitelne ˇ na ´zev vztahu - u na ´zvu volitelne ˇ maly ´ c ˇerny ´ troju ´helnı ´c ˇek ukazujı ´cı ´, ktery ´m sme ˇrem se ma ´ na ´zev vztahu c ˇı ´st - asociace mu ˚z ˇe by ´t i rekurzivnı ´
Zaměstnanec
Je−členem
Oddělení
Zaměstnanec
nadřízený
podřízený Řídí
Ředitel
Řídí
- konce asociace mohou by ´t volitelne ˇ popsa ´ny rolemi ve vztahu . role popisujı ´cı ´ vzda ´lene ´ konce asociacı ´ stejne ´ tr ˇı ´dy majı ´ by ´t jedinec ˇne ´ . u rekurzivnı ´ch vztahu ˚ (nadr ˇı ´zeny ´ r ˇı ´dı ´ podr ˇı ´zene ´ho) by role me ˇla by ´t uvedena vz ˇdy . pojmenova ´nı ´ rolı ´ uz ˇitec ˇne ´, pokud je vı ´ce nez ˇ jedna asociace mezi stejny ´m pa ´rem tr ˇı ´d * pokud ma ´ asociace vlastnosti jako atributy, operace a dals ˇı ´ asociace, mu ˚z ˇeme pro nı ´ vytvor ˇit tzv. asociac ˇnı ´ tr ˇı ´du (analogie ”asociativnı ´ho indika ´toru typu” v ERA diagramech)
zswi/p4oo.d
3. ledna 2005
45
- pr ˇ´ ıklad: za ´kaznı ´k nakoupil zboz ˇı ´ . asociace ”nakoupil” sdruz ˇuje za ´kaznı ´ky a poloz ˇky zboz ˇı ´ . pokud bychom chte ˇli uchovat informaci o datu na ´kupu atd., nepatr ˇı ´ ani k za ´kaznı ´kovi, ani ke zboz ˇı ´
Zákazník
Nákup
Zboží
Nákup datum
* vs ˇechny dosavadnı ´ asociace byly bina ´rnı ´, tj. do vztahu vstupovaly dve ˇ strany - bina ´rnı ´ asociace jsou zdaleka nejc ˇaste ˇjs ˇı ´, obc ˇas se mu ˚z ˇe vyskytnout terna ´rnı ´ atd. - n-a ´rnı ´ asociaci mu ˚z ˇeme zna ´zornit pomocı ´ pra ´zdne ´ho kosoc ˇtverce - na ´sledujı ´cı ´ obra ´zek ukazuje terna ´rnı ´ asociaci, ktera ´ je za ´roven ˇ asociac ˇnı ´ tr ˇı ´dou:
Salesman Customer
Item Purchase
* asociace je velmi obecny ´ typ vztahu, v UML se c ˇasto pouz ˇı ´va ´ pro oznac ˇenı ´, z ˇe ne ˇktery ´ atribut je asociovany ´ objekt nebo z ˇe implementace ne ˇktere ´ metody za ´visı ´ na asociovane ´m objektu - v poc ˇa ´tec ˇnı ´ch fa ´zı ´ch na ´vrhu je vhodne ´ nezahrnovat asociace, ktere ´ bezprostr ˇedne ˇ nepotr ˇebujeme - v konec ˇny ´ch fa ´zı ´ch na ´vrhu je dobre ´ konkretizovat (napr ˇ. vyja ´dr ˇit vztah agregace a kompozice) Agregace ........ * jednou z nejc ˇaste ˇjs ˇı ´ch bina ´rnı ´ch asociacı ´ je agregace * objekt je vytvor ˇen z dals ˇı ´ch objektu ˚ = je agrega ´tem mnoz ˇiny objektu ˚ - napr ˇ. objekt Sta ´do je agrega ´tem Ovcı ´, Les je agrega ´tem Stromu ˚, Rodina ˇena a mnoz bude agrega ´tem objektu typu Muz ˇ, objektu typu Z ˇiny objektu ˚ Dı ´te ˇ - nebo Pr ˇedme ˇt se mu ˚z ˇe skla ´dat z Pr ˇedna ´s ˇek, Cvic ˇenı ´, Za ´poc ˇtove ´_u ´lohy, Zkous ˇky atd. * agregace je vı ´ce nez ˇ pouze souc ˇet svy ´ch c ˇa ´stı ´, vznika ´ ne ˇco nove ´ho (agrega ´t) - agrega ´t mu ˚z ˇe vystupovat v ne ˇktery ´ch operacı ´ch jako samostatna ´ jednotka - c ˇa ´sti mohou existovat samostatne ˇ, mohou by ´t souc ˇa ´stı ´ dals ˇı ´ch agregacı ´ * v UML se agregace zna ´zorn ˇuje pra ´zdny ´m kosoc ˇtvercem na strane ˇ agrega ´tu:
N−úhelník
Obsahuje
vrchol
Bod
Kompozice ......... * kompozice je silna ´ asociace - souc ˇa ´st na ´lez ˇı ´ pra ´ve ˇ jednomu sloz ˇene ´mu objektu - souc ˇa ´st nemu ˚z ˇe existovat samostatne ˇ (polı ´c ˇko nemu ˚z ˇe existovat bez s ˇachovnice) - pr ˇi za ´niku celku tedy zaniknou i jeho c ˇa ´sti - v UML se kompozice zna ´zorn ˇuje plny ´m kosoc ˇtvercem nebo graficky ´m vnor ˇenı ´m:
Za´klady softwarove´ho inzˇeny´rstvı´
46
Chessboard
1
64
Chessboard Square
game: Square64
zswi/p4oo.d Chessboard game: Square [64]
- kompozice je jediny ´ vztah, ktery ´ smı ´me modelovat ”pohr ˇbenı ´m” objektu ˚ jako atributu ˚ jine ´ho objektu (objekt silne ˇ patr ˇı ´ jedine ´ tr ˇı ´de ˇ) . krome ˇ tohoto pr ˇı ´padu se reference na objekty nemajı ´ vyskytovat jako atributy objektu ˚, ale majı ´ by ´t vz ˇdy modelova ´ny jako pr ˇı ´slus ˇne ´ asociace * v jednom diagramu mohou vystupovat ru ˚zne ´ typy vztahu ˚:
1
*
3 1
2..*
1..* *
1
*
[na pr ˇedna ´s ˇce bude uveden konkre ´tnı ´ pr ˇı ´klad] * v pr ˇı ´kladu uvedena take ´ na ´sobnost (kardinalita) vztahu = poc ˇet elementu ˚, ktere ´ mohou vstoupit do vztahu; uva ´dı ´ se intervalem nebo vy ´c ˇtem - intervalem: 0..1 = z ˇa ´dny ´ nebo jeden, 1..* jeden a vı ´ce, * je tote ´z ˇ co 0..* - vy ´c ˇtem: 1..3,7,10 - pokud na ´sobnost nenı ´ uvedena, nelze o nı ´ nic pr ˇedpokla ´dat (krome ˇ kompozice, kde plny ´ kosoc ˇtverec za ´roven ˇ znac ˇ´ ı na ´sobnost 1)
Rozhranı ´ a jeho realizace ......................... * specifikace atributu ˚ a operacı ´ ve tr ˇı ´de ˇ:
Class Name
ExampleClass
attribute attribute: type attribute: type [ multiplicity ] attribute: type = init_value ...
size boundingBox: Rectangle colors: Color [3] userName: String = "root" ...
operation() operation(arg_list) operation(arg_list): return_type ...
hide() display(win: Window) setColor(c: Color): Boolean ...
- specifikace atributu ˚: : [ ] = <poc ˇa ´tec ˇnı ´ hodnota> - specifikace operacı ´: ( <seznam parametru ˚> ) : kde parametr ma ´ tvar: <parametr> : = <default.hodnota> - defaultnı ´ je ”in”; volba ”in”, ”out” nebo ”inout” zvy ´razne ˇne ˇ - typy jsou za ´visle ´ na implementac ˇnı ´m jazyce - pr ˇed atributem nebo operacı ´ mu ˚z ˇe by ´t uvedena . ”+” public = viditelne ´ (pr ˇı ´stupne ´) pro vs ˇechny tr ˇı ´dy . ”#” protected = viditelne ´ pouze uvnitr ˇ tr ˇı ´dy a pro potomky . ”-” private = viditelne ´ pouze uvnitr ˇ tr ˇı ´dy, nenı ´ viditelne ´ ani pro potomky . ”˜” package = viditelne ´ pouze uvnitr ˇ balı ´c ˇku * rozhranı ´ (interface) je specifikace navenek viditelny ´ch operacı ´ tr ˇı ´dy, komponenty apod. - specifikuje pouze rozhranı ´ pro operace bez jejich implementace - nemu ˚z ˇe mı ´t atributy, stav nebo asociace - dva zpu ˚ soby zakreslenı ´: . podobne ˇ jako tr ˇı ´da, nad jme ´nem rozhranı ´ klı ´c ˇove ´ slovo <> . c ˇa ´st s atributy mu ˚z ˇeme vynechat (je vz ˇdy pra ´zdna ´) . pokud tr ˇı ´da rozhranı ´ realizuje (tj. pokud implementuje vs ˇechny operace
zswi/p5uml.d
3. ledna 2005
47
rozhranı ´), zna ´zorn ˇujeme to pr ˇerus ˇovanou s ˇipkou s troju ´helnı ´kovou hlavou, ktera ´ sme ˇr ˇuje od tr ˇı ´dy k rozhranı ´ - rozhranı ´ se mu ˚z ˇe kreslit take ´ jako krouz ˇek spojeny ´ plnou c ˇarou s tr ˇı ´dou, ktera ´ ho implementuje, pod krouz ˇkem na ´zev rozhranı ´
«interface»
Table putElement(Object) removeElement(Object) getElements()
HashTable
HashTable Table
* rozhranı ´ majı ´ v mnoha OO jazycı ´ch pr ˇı ´mou realizaci (v Jave ˇ klı ´c ˇova ´ slova interface a implements) - stejne ´ rozhranı ´ mohou implementovat jinak nepr ˇı ´buzne ´ tr ˇı ´dy Stereotypy .......... * vy ´s ˇe uvedene ´ klı ´c ˇove ´ slovo <> je pr ˇı ´klad tzv. stereotypu - stereotyp = rozs ˇı ´r ˇenı ´ UML o nove ´ prvky, ktere ´ majı ´ stejnou podobu jako prvky existujı ´cı ´, ale odlis ˇny ´ ´ uc ˇel - klı ´c ˇove ´ slovo stereotypu se pı ´s ˇe nad jme ´no prvku, napr ˇ. nad jme ´no tr ˇı ´dy do francouzsky ´ch uvozovek (= znaky ”guillemotleft” a ”guillemotright”), pokud tyto nejsou k dispozici, pak mezi dvojice znaku ˚ << a >>
❉
Za´klady softwarove´ho inzˇeny´rstvı´
48 KIV/ZSWI 2004/2005 Pr ˇedna ´s ˇka 5 Diagramy tr ˇı ´d (pokrac ˇova ´nı ´) ===========================
Pozna ´mka (atribut patr ˇı ´cı ´ tr ˇı ´de ˇ) * atributy a operace patr ˇı ´cı ´ tr ˇı ´de ˇ (nikoli instanci tr ˇı ´dy) se zna ´zorn ˇujı ´ podtrz ˇenı ´m - odpovı ´dajı ´ staticky ´m atributu ˚m a metoda ´m v jazycı ´ch C++, Java a C#.
Window size: Area defaultSize: Area visibility: Boolean = true create() hide() show()
[] Pozna ´mka (na ´zvy asociacı ´ a na ´zvy rolı ´) * na ´zvy rolı ´ podstatna ´ jme ´na, napr ˇ. zame ˇstnavatel, manager, zame ˇstnanec, adresa pro fakturaci apod. - pr ˇed jme ´no role mu ˚z ˇeme pr ˇipojit indika ´tor viditelnosti, ve ˇts ˇinou se pouz ˇı ´va ´ ’+’ (asociace je ve sme ˇru k roli viditelna ´) * na ´zvy asociacı ´ by ´vajı ´ slovesa, napr ˇ. zame ˇstna ´va ´, r ˇı ´dı ´, pracuje pro apod. - asociace je tr ˇeba nazy ´vat konkre ´tne ˇ a vyhy ´bat se pr ˇı ´lis ˇ obecny ´m na ´zvu ˚m jako napr ˇ. ma ´, je souc ˇa ´stı ´ apod. (leps ˇı ´ je ”uc ˇitel uc ˇı ´ pr ˇedme ˇt” nez ˇ ”uc ˇitel ma ´ pr ˇedme ˇt”) - neumı ´me-li asociaci rozumne ˇ pojmenovat, mu ˚z ˇeme tote ´z ˇ vyja ´dr ˇit pr ˇime ˇr ˇeny ´m jme ´nem role (asociaci pak nemusı ´me pojmenova ´vat) . napr ˇı ´klad mı ´sto ”poc ˇı ´tac ˇ ma ´ monitor” pojmenujeme roli monitoru - monitor je ”zobrazovacı ´ zar ˇı ´zenı ´” * pokud jsou mezi stejny ´mi tr ˇı ´dami dve ˇ asociace, znamena ´ to, z ˇe objekt dane ´ tr ˇı ´dy mu ˚ˇ ze by ´t pomocı ´ kaz ˇde ´ z nich spojen s jiny ´m objektem (instance asociace se nazy ´va ´ ”link” - uvidı ´me je napr ˇ. v diagramech objektu ˚) - pak musı ´me asociace rozlis ˇit na ´zvem asociace nebo na ´zvem role [] Uspor ˇa ´da ´nı ´ .......... * pokud je na ´sobnost ve ˇts ˇı ´ nez ˇ 1, pak mnoz ˇina prvku ˚ mu ˚z ˇe by ´t neuspor ˇa ´dana ´ nebo uspor ˇa ´dana ´ - nenı ´-li v diagramu uvedeno jinak, je mnoz ˇina neuspor ˇa ´dana ´ - pokud je uspor ˇa ´dana ´, uva ´dı ´me to klı ´c ˇovy ´m slovem {ordered} Pru ˚chodnost ........... * pru ˚chodnost (navigability) r ˇı ´ka ´, z ˇe se pomocı ´ asociace mu ˚z ˇeme dostat z dane ´ tr ˇı ´dy do cı ´le - zna ´zorn ˇuje se s ˇipkou sme ˇr ˇujı ´cı ´ k cı ´li - pro ve ˇts ˇı ´ pr ˇehlednost se v CASE na ´strojı ´ch pro asociace s pru ˚chodnostı ´ obe ˇma sme ˇry c ˇasto potlac ˇuje zobrazenı ´ s ˇipek (tj. s ˇipky se zobrazujı ´ pouze pro asociace s pru ˚chodnostı ´ jednı ´m sme ˇrem)
zswi/p5uml.d
zswi/p5uml.d
3. ledna 2005
49
Address
Customer
+street: String +town: String +PSC: Number billingAddress 1
+name: String +id: Number customer 1
Kvalifikovane ´ asociace ...................... * kvalifika ´tor je jeden nebo vı ´ce atributu ˚, jejichz ˇ hodnoty slouz ˇı ´ pro urc ˇenı ´ mnoz ˇiny instancı ´, se kterou je objekt sdruz ˇen pomocı ´ asociace - kvalifika ´tor musı ´ rozde ˇlovat instance do disjunktnı ´ch mnoz ˇin - v UML se zobrazuje jako maly ´ obde ´lnı ´c ˇek pr ˇipojeny ´ ke konci asociace, je umı ´ste ˇn u zdrojove ´ho konce asociace (kvalifika ´tory nepatr ˇı ´ ke tr ˇı ´de ˇ, ale k asociaci) . atributy kvalifika ´toru se zna ´zorn ˇujı ´ uvnitr ˇ obde ´lnı ´c ˇku (ve stejne ´m tvaru jako atributy tr ˇı ´dy) . na ´sobnost umı ´ste ˇna ´ u cı ´love ´ho konce asociace znac ˇı ´, jak velka ´ bude mnoz ˇina cı ´lovy ´ch instancı ´ (moz ˇne ´ kardinality)
Banka
0..1
čísloÚčtu *
Klient
Pokud je na jednom konci asociace vı ´ce symbolu ˚ (tzv. ozdob), napr ˇ. oznac ˇenı ´ pro kompozici i pro pru ˚chodnost, zobrazujı ´ se v tomto por ˇadı ´: navigac ˇnı ´ ˇipka, symbol agregace/kompozice, kvalifika s ´tor. Omezenı ´ ....... * omezenı ´ (constraint) je se ´manticky ´ vztah mezi prvky, ktery ´ musı ´ by ´t splne ˇn, aby byl model platny ´ (tj. musı ´ ho spln ˇovat kaz ˇda ´ implementace modelu) - v UML mu ˚z ˇeme specifikovat pomocı ´ podmı ´nky zapsane ´ v {} - mu ˚z ˇe se ty ´kat libovolne ´ho elementu, napr ˇ. tr ˇı ´dy, asociace, atributu tr ˇı ´dy - pokud se ty ´ka ´ jednoho prvku, kreslı ´ se u prvku - pokud se ty ´ka ´ dvou prvku ˚, pr ˇerus ˇovana ´ s ˇipka nebo c ˇa ´ra spojujı ´cı ´ prvky * napr ˇı ´klad na ´sledujı ´cı ´ asociace ma ´ omezenı ´ {xor}, tj. bankovnı ´ ´ uc ˇet mu ˚z ˇe by ´t bud’ osobnı ´, nebo firemnı ´
Je−členem
Osoba Účet
{xor}
Firma
Osoba
{subset}
Komise
Je−předsedou
Pozna ´mka (properties) Pro zmatenı ´ ver ˇejnosti se v UML stejny ´m zpu ˚sobem zna ´zorn ˇujı ´ i libovolne ´ dals ˇı ´ vlastnosti, ktere ´ nemajı ´ graficke ´ vyja ´dr ˇenı ´. Napr ˇı ´klad operace mu ˚z ˇe mı ´t vlastnost {query} znac ˇı ´cı ´, z ˇe operace neme ˇnı ´ stav syste ´mu nebo {concurrency=cuncurrent} znac ˇı ´cı ´ paralelnı ´ vykona ´va ´nı ´. Konce asociace mohou mı ´t vyznac ˇeno napr ˇ. {frozen}, tj. po vytvor ˇenı ´ a inicializaci objektu u konce asociace nebude moz ˇne ´ pr ˇida ´vat, rus ˇit nebo me ˇnit spojenı ´ tvor ˇı ´cı ´ tuto asociaci. [] Prakticka ´ pozna ´mka (diagram tr ˇı ´d) Pr ˇi na ´vrhu syste ´mu obvykle vytva ´r ˇı ´me vı ´ce diagramu ˚ tr ˇı ´d, kaz ˇdy ´ z nich zachycuje jeden aspekt staticke ´ho pohledu na syste ´m - obsahuje pouze prvky potr ˇebne ´ pro pochopenı ´ pr ˇı ´slus ˇne ´ho aspektu. Kaz ˇdy ´ diagram by me ˇl proto mı ´t
Za´klady softwarove´ho inzˇeny´rstvı´
50
zswi/p5uml.d
jme ´no, ktere ´ vypovı ´da ´ o jeho ´ uc ˇelu. ´plny U ´ staticky ´ pohled na syste ´m je tedy tvor ˇen vs ˇemi diagramy tr ˇı ´d spolec ˇne ˇ. []
Diagramy objektu ˚ ................ * instance mı ´sto tr ˇı ´d, ukazuje stav syste ´mu v dane ´m c ˇasove ´m okamz ˇiku * pouz ˇı ´va ´ se pome ˇrne ˇ zr ˇı ´dka, vhodne ´ pro vysve ˇtlenı ´ maly ´ch c ˇa ´stı ´ syste ´mu se sloz ˇity ´mi (zejme ´na rekurzivnı ´mi) vztahy
Employee +worker *
rektor
+manager 0..1
Manages
děkan_FE vedoucí_KIV
děkan_FAV vedoucí_KKY
děkan_PF vedoucí_KMA
* instancı ´ asociace je ”link” (propojenı ´) - link je n-tice (nejc ˇaste ˇji dvojice) odkazu ˚ na objekty - zna ´zorn ˇuje se c ˇarou (podobne ˇ jako asociace) Pozna ´mka pro zajı ´mavost (UML a diagramy objektu ˚) V diagramech tr ˇı ´d je dovoleno uva ´de ˇt objekty a jejich vztahy (pouz ˇı ´va ´ se pr ˇedevs ˇı ´m pro uvedenı ´ pr ˇı ´kladu ˚ datovy ´ch struktur, viz vy ´s ˇe). Z hlediska UML je diagram objektu ˚ takovy ´ diagram tr ˇı ´d, ve ktere ´m nejsou uvedeny z ˇa ´dne ´ tr ˇı ´dy, ale pouze instance (tj. v UML neexistuje samostatny ´ typ diagramu ”diagram tr ˇı ´d”). [] Balı ´c ˇky (packages) .................. * slouz ˇı ´ pro zjednodus ˇenı ´ sloz ˇity ´ch diagramu ˚ - sdruz ˇujı ´ mnoz ˇinu libovolny ´ch prvku ˚ diagramu (uvnitr ˇ balı ´c ˇku ˚ mohou by ´t dals ˇı ´ balı ´c ˇky) - kaz ˇdy ´ prvek mu ˚z ˇe by ´t nejvy ´s ˇe v jednom balı ´c ˇku * zakreslujı ´ se jako obde ´lnı ´ky s maly ´m drz ˇa ´tkem na leve ´ hornı ´ strane ˇ - prvky obsaz ˇene ´ v balı ´c ˇku lze kreslit bud’ do balı ´c ˇku, nebo je moz ˇne ´ nakreslit strom obsahu balı ´c ˇku - viditelnost prvku ˚ vne ˇ balı ´c ˇku je moz ˇne ´ oznac ˇit obvykly ´m zpu ˚sobem (napr ˇ. ’+’ pro ”public”)
UML Editor
UML Editor
Controller UML Elements Graphics Core
Controller
UML Elements
Graphics Core
Pozna ´mka pro zajı ´mavost (oznac ˇenı ´ vnor ˇeny ´ch podtr ˇı ´d) V diagramu tr ˇı ´d se pro oznac ˇenı ´ vnor ˇeny ´ch podtr ˇı ´d pouz ˇı ´va ´ stejna ´ notace jako pro oznac ˇenı ´ stromu obsahu balı ´c ˇku, tj. krouz ˇek s kr ˇı ´z ˇkem:
zswi/p5uml.d
3. ledna 2005
DeclaringClass
NestedClass
[] * za ´vislosti mezi balı ´c ˇky je moz ˇne ´ zna ´zornit pr ˇerus ˇovanou c ˇarou s otevr ˇenou ˇipkou (A za s ´visı ´ na B jako s ˇipku od A k B) - balı ´c ˇek A za ´visı ´ na balı ´c ˇku B, pokud zme ˇny v B mohou zpu ˚sobit zme ˇny v A - notace pro za ´vislost se pouz ˇı ´va ´ i jinde, napr ˇ. tr ˇı ´da za ´visı ´ na rozhranı ´
UML Elements
Core
* specia ´lnı ´m druhem balı ´c ˇku z hlediska UML je podsyste ´m - podsyste ´m ´ uplne ˇ zapouzdr ˇuje svu ˚ j obsah (tj. sve ´ chova ´nı ´ zpr ˇı ´stupn ˇuje pouze prostr ˇednictvı ´m rozhranı ´ podsyste ´mu) - tj. dokud zu ˚stane stejne ´ rozhranı ´, obsah podsyste ´mu se mu ˚z ˇe libovolne ˇ me ˇnit - zna ´zorn ˇuje se jako balı ´c ˇek, v prave ´m hornı ´m rohu velke ´ho obde ´lnı ´ka je ”vidlic ˇka”
Subsystem A
Subsystem B
Subsystem C
Diagram komponent ----------------* diagram komponent je fyzicka ´ analogie diagramu tr ˇı ´d - komponenta zapouzdr ˇuje implementaci a zver ˇejn ˇuje mnoz ˇinu rozhranı ´ - komponenta mu ˚z ˇe by ´t implementova ´na napr ˇ. jednı ´m nebo vı ´ce spustitelny ´mi soubory, zdrojovy ´mi texty nebo objektovy ´mi moduly, knihovnami, pr ˇı ´kazovy ´mi soubory apod. * komponenta se zna ´zorn ˇuje jako obde ´lnı ´k, po jeho strane ˇ dva mens ˇı ´ obde ´lnı ´c ˇky - prvky se zna ´zorn ˇujı ´ umı ´ste ˇne ´ uvnitr ˇ komponenty - diagram komponent zna ´zorn ˇuje take ´ za ´vislosti komponent (pr ˇerus ˇovana ´ s ˇipka od za ´visle ´ho obvykle k rozhranı ´ jine ´ komponenty)
Gemini system
ILibGM
CtScan.java
Za ´kladnı ´ rozdı ´l mezi balı ´c ˇkem a komponentou: balı ´c ˇek je c ˇiste ˇ koncepc ˇnı ´ mechanismus pro organizaci modelu ˚ v UML, zatı ´mco komponenty existujı ´ skutec ˇne ˇ.
Nynı ´ pr ˇejdeme od staticke ´ho popisu syste ´mu k diagramu ˚m popisujı ´cı ´m chova ´nı ´ syste ´mu nebo jeho c ˇa ´stı ´. Nebudu samozr ˇejme ˇ popisovat vs ˇechny typy diagramu ˚ (na to je UML pr ˇı ´lis ˇ rozsa ´hle ´), ale popı ´s ˇu nejdu ˚ lez ˇite ˇjs ˇı ´ diagramy pro analy ´zu a na ´vrh. Diagramy pr ˇı ´padu ˚ pouz ˇitı ´ -----------------------* popisujı ´, co syste ´m de ˇla ´ z hlediska vne ˇjs ˇı ´ho pozorovatele (nikoli jak to de ˇla ´ - k tomu slouz ˇı ´ jine ´ typy diagramu ˚, napr ˇ. stavovy ´ diagram, viz da ´le)
51
Za´klady softwarove´ho inzˇeny´rstvı´
52
zswi/p5uml.d
* vs ˇechny diagramy pr ˇı ´padu ˚ pouz ˇitı ´ obsahujı ´ - akte ´ry (nejc ˇaste ˇji zna ´zorne ˇni jako pana ´c ˇci, ale pouz ˇı ´vajı ´ se i jine ´ ikony) . akte ´r = cokoli co potr ˇebuje komunikovat se syste ´mem . pr ˇedstavuje roli nebo mnoz ˇinu rolı ´ uz ˇivatele pr ˇi komunikaci s entitou - pr ˇı ´pady pouz ˇitı ´ (zna ´zorne ˇny elipsou) . pr ˇedstavujı ´ dialog nebo transakci vykona ´vanou syste ´mem, podsyste ´mem nebo tr ˇı ´dou - asociace (c ˇa ´ry mezi akte ´ry a pr ˇı ´pady pouz ˇitı ´ zna ´zorn ˇujı ´cı ´ komunikaci) . spojuje akte ´ry s pr ˇı ´pady pouz ˇitı ´ . konce asociace mohou mı ´t oznac ˇenı ´ na ´sobnosti
1
Zákazník
*
Zadání objednávky
* pr ˇı ´pady pouz ˇitı ´ mohou by ´t spojeny se sce ´na ´r ˇi - sce ´na ´r ˇ = pr ˇı ´klad co se stane pokud ne ˇkdo komunikuje se syste ´mem - sce ´na ´r ˇ je posloupnost kroku ˚ (v diagramu je nezobrazujeme) - popisuje se obyc ˇejny ´m textem, stavovy ´m automatem apod. . napr ˇ. bankomat - akte ´r vloz ˇı ´ kartu, zada ´ PIN, zada ´ typ operace, zada ´ c ˇa ´stku, bankomat pr ˇeda ´ penı ´ze, pr ˇeda ´ c ˇa ´stku, vra ´tı ´ kartu * diagram pr ˇı ´padu ˚ pouz ˇitı ´ mu ˚z ˇe da ´le obsahovat - zobecne ˇnı ´ pr ˇı ´padu ˚ pouz ˇitı ´ a akte ´ru ˚ - vztahy ”include” (zahrnout, vloz ˇit) a ”extend” (rozs ˇı ´r ˇit) - balı ´c ˇky sdruz ˇujı ´cı ´ prvky modelu do ve ˇts ˇı ´ch celku ˚ - pozna ´mky * zobecne ˇnı ´ pr ˇı ´padu ˚ pouz ˇitı ´ a akte ´ru ˚ (generalization) - ukazuje ˇ ze jeden pr ˇı ´pad pouz ˇitı ´ nebo akte ´r je zobecne ˇnı ´m jine ´ho (podobne ˇ jako rodic ˇovska ´ tr ˇı ´da je zobecne ˇnı ´m svy ´ch potomku ˚) - zna ´zorn ˇuje se s ˇipkou s troju ´helnı ´kovou hlavou
Pay Insurance Bill
Pay Bill
Administrator
User
* vztah ”zahrnout, vloz ˇit” (include) - rozloz ˇenı ´ pr ˇı ´padu pouz ˇitı ´ na c ˇa ´sti, uz ˇitec ˇne ´ pokud stejnou c ˇa ´st mu ˚z ˇeme pouz ˇı ´t ve vı ´ce pr ˇı ´padech pouz ˇitı ´ (napr ˇ. ”pr ˇevod c ˇa ´stky” mu ˚z ˇe by ´t souc ˇa ´stı ´ pr ˇı ´padu pouz ˇitı ´ ”platba za sluz ˇbu” i ”platba za zboz ˇı ´”) - vkla ´dany ´ pr ˇı ´pad nemu ˚z ˇe existovat samostatne ˇ, je vz ˇdy souc ˇa ´stı ´ jine ´ho - notace pr ˇerus ˇovana ´ c ˇa ´ra oznac ˇena ´ klı ´c ˇovy ´m slovem <>
Supply Customer Data
«include» Place Order Salesman
«include»
«include»
Arrange Payment Order Product
* vztah ”rozs ˇı ´r ˇit” (extend) - oznac ˇuje z ˇe ba ´zovy ´ pr ˇı ´pad pouz ˇitı ´ mu ˚z ˇe by ´t upraven podle obsahu jine ´ho, tı ´m vznikne varianta (rozs ˇı ´r ˇenı ´) ba ´zove ´ho pr ˇ´ ıpadu - pouz ˇı ´va ´ se pokud jsou c ˇa ´sti pr ˇı ´padu pouz ˇitı ´ volitelne ´, pouz ˇı ´vajı ´ se zr ˇı ´dka apod. - notace pr ˇerus ˇovana ´ c ˇa ´ra oznac ˇena ´ <<extend>>, s ˇipka k ba ´zove ´mu pr ˇı ´padu pouz ˇitı ´ . v ba ´zove ´m pr ˇı ´padu pouz ˇitı ´ se uvedou ”body rozs ˇı ´r ˇenı ´”, tj. kdy se pouz ˇije
zswi/p5uml.d
3. ledna 2005
53
rozs ˇı ´r ˇeny ´ pr ˇı ´pad . ”body rozs ˇı ´r ˇenı ´” majı ´ nejc ˇaste ˇji podobu obyc ˇejne ´ho textu
Clinic Request Treatment Extension points more treatment
Patient
Doctor
«extend» Hospitalization
* ne ˇkdy se v diagramu uva ´dı ´ hranice syste ´mu = obde ´lnı ´k odde ˇlujı ´cı ´ syste ´m od externı ´ch akte ´ru ˚, na ´zev syste ´mu se uva ´dı ´ uvnitr ˇ obde ´lnı ´ku * diagramy pr ˇı ´padu ˚ pouz ˇitı ´ se - pro sbe ˇr poz ˇadavku ˚ - pro komunikaci s klienty - pro generova ´nı ´ testovacı ´ch pouz ˇitı ´ mu ˚z ˇe by ´t odrazovy ´m sce ´na ´r ˇe
pouz ˇı ´vajı ´: jsou jim srozumitelne ´ pr ˇı ´padu ˚ - mnoz ˇina sce ´na ´r ˇ˚ u spojena ´ s pr ˇı ´padem mu ˚stkem pro vytvor ˇenı ´ testovacı ´ch pr ˇı ´padu ˚ pro
* nejbe ˇz ˇne ˇjs ˇı ´ modely: - model kontextu syste ´mu nebo podsyste ´mu, tj. urc ˇenı ´ co lez ˇı ´ uvnitr ˇ syste ´mu (zna ´zorn ˇujeme ohranic ˇenı ´m syste ´mu, viz vy ´s ˇe), popis akte ´ru ˚ a jejich rolı ´ - modelova ´nı ´ poz ˇadavku ˚ - popis kontraktu mezi syste ´mem a akte ´ry
Diagramy spolupra ´ce ------------------* diagramy spolupra ´ce (collaboration diagrams) popisujı ´ spolupra ´ci mezi objekty nebo jejich rolemi - mohou by ´t pr ˇipojeny napr ˇ. k pr ˇı ´padu pouz ˇitı ´ jako jeho popis . popisujı ´ ktere ´ objekty nabı ´zejı ´ chova ´nı ´ popisovane ´ pr ˇı ´padem pouz ˇitı ´ . jak objekty pr ˇı ´pad pouz ˇitı ´ vykona ´vajı ´ - mohou mı ´t i vys ˇs ˇı ´ ´ uroven ˇ podrobnosti, lze je pouz ˇı ´t napr ˇ. pro popis chova ´nı ´ operacı ´ tr ˇı ´dy apod. * v diagramu spolupra ´ce se vyskytujı ´ - objekty ´ uc ˇastnı ´cı ´ se interakce, pr ˇı ´padne ˇ role objektu ˚ v interakci - spojenı ´ pro pr ˇenos zpra ´vy - kreslı ´ se jako plna ´ c ˇa ´ra . c ˇasto se kreslı ´ s s ˇipkou ukazujı ´cı ´ pru ˚chodnost (v pr ˇı ´kladech jı ´ neuva ´dı ´m) - zpra ´vy (stimuly) - kreslı ´ se jako s ˇipec ˇka blı ´zko c ˇa ´ry . s ˇipec ˇka s plnou hlavou znamena ´ vola ´nı ´ procedury, volajı ´cı ´ pokrac ˇuje az ˇ po na ´vratu z procedury - kaz ˇda ´ zpra ´va ma ´ por ˇadove ´ c ˇı ´slo, konc ˇı ´cı ´ dvojtec ˇkou . zpra ´vy na nejvys ˇs ˇı ´ ´ urovni jsou c ˇı ´slova ´ny postupne ˇ 1, 2, 3 atd. . zpra ´vy na dals ˇı ´ ´ urovni vnor ˇenı ´ be ˇhem stejne ´ho vola ´nı ´ 1.1, 1.2, 1.3 atd. - za por ˇadovy ´m c ˇı ´slem mu ˚z ˇe by ´t uvedeno: zpra ´va(argumenty) nebo pr ˇı ´padne ˇ na ´vratova ´_hodnota := zpra ´va(argumenty) . popisuje zaslanou zpra ´vu, jejı ´ argumenty a na ´vratovou hodnotu
:Lecturer
:UserInterface 1: namesOfTeachers()
1.i.1: name()
:Course
:Student 1.1 *[i:=1..n]:getLecturer()
* v diagramu spolupra ´ce lze zna ´zornit take ´ iterace a podmı ´nky - iterace - jako por ˇadı ´ zpra ´vy uvedeme hve ˇzdic ˇku (pokud nechceme uva ´de ˇt
Za´klady softwarove´ho inzˇeny´rstvı´
54
podrobnosti) nebo napr ˇ. *[i := 1..n] (pokud chceme iteraci popsat) - podmı ´ne ˇna ´ zpra ´va - jako prefix uvedeme podmı ´nku. napr ˇ. [x>0] . co ma ´ by ´t uvnitr ˇ hranaty ´ch za ´vorek UML nespecifikuje; obvykle se pouz ˇı ´va ´ pseudoko ´d nebo syntaxe cı ´love ´ho programovacı ´ho jazyka . napr ˇı ´klad: 4[x<0]: display(x) - zpra ´vy je moz ˇne ´ take ´ ”c ˇı ´slovat” identifika ´torem * obde ´lnı ´c ˇky v diagramech spolupra ´ce jsou bud’ objekty (na ´zev je podtrz ˇeny ´) nebo role (na ´zev nenı ´ podtrz ˇeny ´) - plny ´ za ´pis objektu ”objekt/role : Tr ˇı ´da”, plny ´ za ´pis role ”/role : Tr ˇı ´da” * lze kombinovat se vztahy z diagramu tr ˇı ´d, napr ˇ. zobecne ˇnı ´, agregace apod.
1: print (info) : PrintDevice
: Generator
: LaserPrinter
: LinePrinter
Pomocı ´ diagramu ˚ spolupra ´ce se obvykle zna ´zorn ˇujı ´ jednoduche ´ posloupnosti zpra ´v. Pro sloz ˇite ˇjs ˇı ´ chova ´nı ´ se obvykle pouz ˇı ´vajı ´ (vy ´znamove ˇ ekvivalentnı ´) sekvenc ˇnı ´ diagramy, ve ktery ´ch se le ´pe zobrazujı ´ c ˇasove ´ za ´vislosti.
Sekvenc ˇnı ´ diagramy -----------------* sekvenc ˇnı ´ diagramy (sequence diagrams) - popisujı ´ stejnou informaci jako diagramy spolupra ´ce, ale soustr ˇedı ´ se na c ˇasove ´ za ´vislosti - v ne ˇktery ´ch metodika ´ch (napr ˇ. OOSE) se k pr ˇı ´padu ˚m pouz ˇitı ´ vytva ´r ˇejı ´ sekvenc ˇnı ´ diagramy mı ´sto diagramu ˚ spolupra ´ce * sekvenc ˇnı ´ diagramy zna ´zorn ˇujı ´ akte ´ry, objekty v syste ´mu, se ktery ´mi interagujı ´, a posloupnost vyme ˇne ˇny ´ch zpra ´v - c ˇas plyne shora dolu ˚, pro kaz ˇdy ´ objekt svisla ´ pr ˇerus ˇovana ´ ”c ˇa ´ra z ˇivota” (lifeline) reprezentujı ´cı ´ c ˇas, kdy objekt existuje a hraje urc ˇitou roli, doba aktivity objektu se zna ´zorn ˇuje ´ uzky ´m obde ´lnı ´kem - horizonta ´lnı ´ uspor ˇa ´da ´nı ´ nenı ´ podstatne ´ a ma ´ by ´t zvoleno s ohledem na srozumitelnost diagramu - vlevo od diagramu sloupec popisujı ´cı ´ interakci s okolnı ´m sve ˇtem (”hranice syste ´mu”) obj1:TřídaA
poznámky (neformální konvence)
obj2:TřídaB
obj3:TřídaA
a) vyvolání operace b) asynchronní komunikace c) návrat z volání operace
* ˇ sipky podle typu komunikace: - vola ´nı ´ procedury nebo jiny ´ vnor ˇeny ´ tok r ˇı ´zenı ´ (tj. vne ˇjs ˇı ´ sekvence mu ˚z ˇe pokrac ˇovat az ˇ po dokonc ˇenı ´ vnitr ˇnı ´ sekvence) - plna ´ s ˇipka, viz (a) - asynchronnı ´ komunikace - s ˇipka tvor ˇena ´ c ˇarami, viz (b) - na ´vrat z procedury - pr ˇerus ˇovana ´ s ˇipka, viz (c) . pokud r ˇı ´zenı ´ toku procedura ´lnı ´ (viz ”na ´vrh mechanismu r ˇı ´zenı ´”), mu ˚z ˇeme vynechat s ˇipku pro na ´vrat z procedury - stejne ´ tr ˇi typy s ˇipek lze pouz ˇı ´t i v diagramech spolupra ´ce - horizonta ´lnı ´ s ˇipka = atomicke ´ zasla ´nı ´ zpra ´vy - s ˇipka sme ˇr ˇujı ´cı ´ s ˇikmo dolu ˚ = be ˇhem zasla ´nı ´ zpra ´vy mu ˚z ˇe nastat dals ˇı ´ uda ´lost, napr ˇ. zasla ´nı ´ zpra ´vy opac ˇny ´m sme ˇrem - vlevo od diagramu by ´va ´ posloupnost akcı ´ okomentova ´na napr ˇ. pseudoko ´dem * pr ˇı ´klad - dva telefonnı ´ ´ uc ˇastnı ´ci a ´ ustr ˇedna:
zswi/p5uml.d
zswi/p5uml.d
3. ledna 2005 caller
exchange
55 callee
lift receiver dial tone dials(371234567) ringing tone
phone rings answer phone
stop ringing tone
stop ringing
phones connected
phones connected
* dals ˇı ´ moz ˇnosti (uva ´dı ´m pouze pro zajı ´mavost) - zpra ´va mu ˚z ˇe zapr ˇı ´c ˇinit vznik nebo za ´nik objektu (s ˇipka sme ˇr ˇuje k symbolu objektu resp. symbolu za ´niku objektu X); objekt mu ˚z ˇe prove ´st autodestrukci - neexistuje-li objekt po celou dobu pokrytou diagramem, c ˇa ´ra z ˇivota zac ˇı ´na ´ a konc ˇı ´ na mı ´ste ˇ vzniku a za ´niku objektu (objekt se kreslı ´ na jejı ´ zac ˇa ´tek) - c ˇa ´ra z ˇivota se mu ˚z ˇe rozde ˇlit na dve ˇ pro zna ´zorne ˇnı ´ podmı ´nky (podmı ´nka se uva ´dı ´ v hranaty ´ch za ´vorka ´ch), c ˇa ´ry se pozde ˇji mohou ope ˇt spojit - podmı ´nkou se mohou oznac ˇovat i zpra ´vy obj1:ClassA
obj3:ClassC do(x)
obj2:ClassB
[x=0]
[x>0]
Zatı ´mco sekvenc ˇnı ´ diagramy se pouz ˇı ´vajı ´ pro vyja ´dr ˇenı ´ c ˇasovy ´ch za ´vislostı ´, diagramy spolupra ´ce slouz ˇı ´ spı ´s ˇe pro zna ´zorne ˇnı ´ struktury syste ´mu a vztahu mezi instancemi.
Stavove ´ diagramy ---------------* typicky se pouz ˇı ´vajı ´ pro popis chova ´nı ´ instance tr ˇı ´dy, ne ˇkdy take ´ pro pr ˇı ´pady pouz ˇitı ´ nebo pro cely ´ syste ´m nebo podsyste ´m - popisujı ´ moz ˇne ´ posloupnosti stavu ˚ , ktery ´mi objekt procha ´zı ´ v du ˚ sledku reakcı ´ na uda ´losti (uda ´lostı ´ mu ˚z ˇe by ´t napr ˇ. vyvola ´nı ´ operace, uplynutı ´ c ˇasu apod.) - oproti klasicky ´m ”plochy ´m” stavovy ´m diagramu ˚m umoz ˇn ˇujı ´ stavove ´ diagramy v UML strukturova ´nı ´ (ktere ´ nebudu pr ˇı ´lis ˇ podrobne ˇ popisovat, ale pro rozsa ´hlejs ˇı ´ diagramy je nutne ´) * stav = situace be ˇhem z ˇivota objektu, kdy objekt spln ˇuje ne ˇjakou podmı ´nku, prova ´dı ´ ne ˇjakou akci nebo c ˇeka ´ na uda ´lost * uda ´lost = vy ´skyt stimulu, ktery ´ mu ˚z ˇe spustit pr ˇechod do jine ´ho stavu * pr ˇechod = zme ˇna stavu zpu ˚ sobena ´ uda ´lostı ´; novy ´ stav za ´visı ´ na pu ˚vodnı ´m stavu a na uda ´losti * stavovy ´ diagram je graf, kde - uzly grafu = stavy, zna ´zorne ˇny jako obde ´lnı ´ky s kulaty ´mi rohy, uvnitr ˇ volitelne ˇ c ˇa ´st s na ´zvem stavu a s posloupnostı ´ akcı ´ . entry/akce - akce prova ´de ˇna ´ pr ˇi vstupu do stavu . do/akce - akce prova ´de ˇna ´ be ˇhem stavu . exit/akce - akce prova ´de ˇna ´ pr ˇi opus ˇte ˇnı ´ stavu . mohou by ´t uvedeny dals ˇı ´ uz ˇivatelem definovane ´ akce
Zadávání hesla entry / vypni zobrazování znaků exit / zapni zobrazování znaků character / zpracuj znak help / zobraz nápovědu
Za´klady softwarove´ho inzˇeny´rstvı´
56
zswi/p6ooa.d
- orientovane ´ hrany grafu = pr ˇechody mezi stavy . popis hrany = uda ´lost, ktera ´ zpu ˚sobı ´ pr ˇechod a akce provedene ´ jako du ˚ sledek pr ˇechodu ve tvaru: uda ´lost/akce, pr ˇı ´padne ˇ uda ´lost[podmı ´nka]/akce . uda ´lost ma ´ tvar: jme ´no_uda ´losti(parametry)
State1 do/activity1
event(attrib)[condition]/action
State2 do/activity2
- poc ˇa ´tec ˇnı ´ stav - zna ´zorne ˇn jako c ˇerne ´ kolec ˇko - koncovy ´ stav - zna ´zorne ˇn jako c ˇerne ´ kolec ˇko v krouz ˇku (”by ´c ˇı ´ oko”)
afer(5 sec)/fail
press key[key!=tab] Rejecting
Getting Login submit
[not valid] /show error message
press tab
press shift_tab Getting Password
Validating [valid]/start session do/validate
entry / set echo invisible exit / set echo normal
submit
press key[key!=shift_tab]
* c ˇinnost v dane ´m stavu lze popsat ope ˇt pomocı ´ stavove ´ho automatu - vnor ˇenı ´ - poc ˇa ´tec ˇnı ´ a koncovy ´ pseudostav je zna ´zorne ˇn stejne ˇ jako poc ˇa ´tec ˇnı ´ a koncovy ´ stav
Zadávání hesla
Start entry / vypni echo
znak(z)
Zadávání hesla entry / znak.zpracuj(z)
[znak.Enter()]
Konec entry / zapni echo
znak(z)
Pozna ´mka (volne ˇ s ˇı ´r ˇeny ´ na ´stroj Fujaba) Stavove ´ diagramy lze vytva ´r ˇet i ve volne ˇ s ˇı ´r ˇene ´m na ´stroji Fujaba, ktery ´ z nich umı ´ vygenerovat ko ´d v jazyku Java. To se mu ˚z ˇe hodit napr ˇ. pro implementaci sı ´t’ovy ´ch protokolu ˚ apod. []
❉
zswi/p6ooa.d
3. ledna 2005
KIV/ZSWI 2004/2005 Pr ˇedna ´s ˇka 6 Objektove ˇ-orientovane ´ metody vy ´voje SW ====================================== * mezi 1989 a 1994 bylo navrz ˇeno cca 40 novy ´ch objektovy ´ch metodik, napr ˇ. OMT (Rumbaugh et al. 1991), OOSE (Jacobson 1992), OOD (Booch 1994) atd. * metody me ˇly tolik spolec ˇne ´ho, z ˇe se tr ˇi klı ´c ˇovı ´ autor ˇi Booch, Jacobson a Rumbaugh a rozhodli sve ´ na ´vrhy integrovat do jedne ´ metodiky (v ra ´mci firmy Rational Software Corporation) - metodika nazva ´na ”Rational Unified Process”(R), da ´le jen RUP - v RUP se pouz ˇı ´va ´ stejny ´mi autory navrz ˇena ´ notace UML - firma vyda ´va ´ ´ uplny ´ popis procesu ve forme ˇ HTML - tento popis je odkazova ´n z my ´ch stra ´nek o ZSWI - dnes je to dnes jeden z nejzna ´me ˇjs ˇı ´ch SW procesu ˚, ale pouz ˇı ´vajı ´ se i dals ˇı ´ (OPEN Process, OOSP apod.) - je zaloz ˇen na dlouhodoby ´ch zkus ˇenostech autoru ˚ - iterativnı ´ vy ´voj, prototypova ´nı ´ * dals ˇı ´ dostupny ´ pr ˇı ´klad - metodika GRAPPLE uvedena ´ v knize [Schmuller: Myslı ´me v jazyku UML. Grada 2001] od kapitoly 15. * ve ˇts ˇina metodik je velmi rozsa ´hly ´ch, viz popis RUP * popı ´s ˇu pouze aktivity, ktere ´ najdete ve ve ˇts ˇine ˇ OO procesu ˚, budu vycha ´zet hlavne ˇ z RUP (a inspirovat se jeho bezprostr ˇednı ´mi pr ˇedchu ˚dci, tj. metodikami Booche, Jacobsona a Rumbaugha) * nelze aplikovat mechanicky, pro vlastnı ´ pouz ˇitı ´ je tr ˇeba upravit
Pr ˇehled kroku ˚ OO vy ´voje SW -------------------------* vy ´voj syste ´mu znamena ´ vytva ´r ˇenı ´ modelu ˚, model = abstrakce r ˇes ˇene ´ho proble ´mu * nejprve musı ´me porozume ˇt r ˇes ˇene ´mu proble ´mu (bez toho nema ´me co modelovat) * model obvykle nevytvor ˇı ´me napoprve ´ spra ´vne ˇ, je zapotr ˇebı ´ vı ´ce iteracı ´ * postupne ˇ mu ˚z ˇeme pr ˇida ´vat podrobnosti (atributy, metody, na ´sobnost, pru ˚chodnost...) * vy ´voj obvykle probı ´ha ´ v na ´sledujı ´cı ´ch krocı ´ch: - sbe ˇr poz ˇadavku ˚ - zjistı ´me, jake ´ poz ˇadavky na syste ´m ma ´ uz ˇivatel; vy ´sledkem model uz ˇivatelsky ´ch poz ˇadavku ˚, napr ˇ. ve forme ˇ pr ˇı ´padu ˚ pouz ˇitı ´, rozhranı ´ pr ˇ´ ıpadu ˚ pouz ˇitı ´ a dome ´novy ´ch objektu ˚ (dome ´na = skutec ˇny ´ sve ˇt, ze ktere ´ho proble ´m pocha ´zı ´) - analy ´za poz ˇadavku ˚ - strukturova ´nı ´ syste ´mu z logicke ´ho hlediska, pr ˇedpokla ´da ´me idea ´lnı ´ technologii; vy ´sledkem analyticky ´ model = abstrakce popisujı ´cı ´ co ma ´ syste ´m de ˇlat (tj. zatı ´m ner ˇı ´ka ´, jak to bude syste ´m de ˇlat) - na ´vrh architektury syste ´mu - syste ´m je rozde ˇlen do podsyste ´mu ˚, provede se za ´kladnı ´ rozhodnutı ´ ty ´kajı ´cı ´ se komunikace mezi podsyste ´my, ukla ´da ´nı ´ dat apod.; vy ´stupem je architektura = popis prvku ˚ (objektu ˚, komponent, ra ´mcu ˚), ze ktery ´ch bude SW vytvor ˇen a popis interakce mezi te ˇmito prvky - na ´vrh (design) syste ´mu - adaptace modelu vytvor ˇene ´ho v analy ´ze pro realizaci ve skutec ˇne ´m sve ˇte ˇ; napr ˇ. pr ˇida ´ny tr ˇı ´dy zapouzdr ˇujı ´cı ´ datove ´ struktury jako tabulky, seznamy, stromy apod. Implementace by me ˇla by ´t uz ˇ pr ˇ´ ımoc ˇara ´ a te ´me ˇr ˇ mechanicka ´. Pr ˇechod mezi analy ´zou a na ´vrhem syste ´mu pozna ´me podle toho, z ˇe se model zac ˇne ty ´kat implementac ˇnı ´ho prostr ˇedı ´ (zac ˇneme bra ´t v ´ uvahu vlastnosti cı ´love ´ho jazyka apod.). * pr ˇi OO vy ´voji se pro sbe ˇr poz ˇadavku ˚ , analy ´zu i na ´vrh pouz ˇı ´vajı ´ stejne ´ na ´stroje (v nas ˇem pr ˇı ´pade ˇ pr ˇedevs ˇı ´m UML diagramy), ale na ru ˚zne ´ ´ urovni abstrakce - pro jednotlive ´ profese SW ty ´mu (analytici, vy ´voja ´r ˇi, management) jsou take ´ urc ˇeny ru ˚zne ´ ´ urovne ˇ obecnosti modelu ˚
57
Za´klady softwarove´ho inzˇeny´rstvı´
58
Pozna ´mka (objektove ´ a strukturovane ´ metodiky) Krome ˇ objektovy ´ch metodik existujı ´ i tzv. strukturovane ´ metodiky vy ´voje SW, ktere ´ vı ´ceme ´ne ˇ odpovı ´dajı ´ strukturovane ´mu programova ´nı ´ (o nich budeme hovor ˇit pozde ˇji, i kdyz ˇ historicky OO metodika ´m pr ˇedcha ´zely). Vy ´hodou strukturovany ´ch metodik je, z ˇe poc ˇa ´tec ˇnı ´ modely jsou c ˇasto srozumitelne ˇjs ˇı ´ pro za ´kaznı ´ky. [] V te ´to pr ˇedna ´s ˇce uvedu pome ˇrne ˇ podrobne ˇ postup OO analy ´zy a na ´vrhu, ale nebude zde uveden z ˇa ´dny ´ rozsa ´hlejs ˇı ´ pr ˇı ´klad. Podrobne ´ pr ˇı ´klady (vc ˇetne ˇ naprogramova ´nı ´) mu ˚z ˇete nale ´zt na WWW stra ´nka ´ch pr ˇedme ˇtu OOP doc. Herouta: http://www.kiv.zcu.cz/˜herout/vyuka/oop/zajimave.html K dispozici je jednoducha ´ uka ´zkova ´ aplikace ilustrujı ´cı ´ za ´kladnı ´ vztahy mezi ˇerpacı tr ˇı ´dami (de ˇdic ˇnost, asociace) a rozsa ´hlejs ˇı ´ uka ´zka aplikace ”C ´ stanice”. Sbe ˇr poz ˇadavku ˚ .............. Pr ˇehled: * vstupem je definice proble ´mu * provedeme dome ´novou analy ´zu a navrhneme za ´kladnı ´ dome ´nove ´ tr ˇı ´dy * provedeme sbe ˇr poz ˇadavku ˚, nejc ˇaste ˇji se pouz ˇı ´vajı ´ pr ˇı ´pady pouz ˇitı ´ (use cases) * na zac ˇa ´tku by me ˇla by ´t struc ˇna ´ definice proble ´mu vytvor ˇena ´ za ´kaznı ´kem pr ˇı ´padne ˇ vy ´voja ´r ˇsky ´m ty ´mem s pomocı ´ za ´kaznı ´ka - o definici proble ´mu nemu ˚z ˇeme pr ˇedpokla ´dat, z ˇe je bez chyb, tj. v dals ˇı ´ch krocı ´ch se bude me ˇnit, rozs ˇir ˇovat a zpr ˇesn ˇovat - pokud ude ˇla ´te pr ˇesne ˇ to, o co si za ´kaznı ´k r ˇekne, ale nenaplnı ´te tı ´m jeho skutec ˇne ´ potr ˇeby, bude znac ˇne ˇ nespokojeny ´ - pokud definici proble ´mu vytva ´r ˇı ´ za ´kaznı ´k, bude pravde ˇpodobne ˇ smı ´s ˇena ´ s na ´vrhem Pr ˇı ´klad (pone ˇkud zjednodus ˇeny ´ oproti realite ˇ): Vytvor ˇte software pro sı ´t’ bankomatu ˚ Nas ˇ´ ı Banky. Bankomaty budou komunikovat s centra ´lnı ´m poc ˇı ´tac ˇem banky, ktery ´ transakce autorizuje a provede zme ˇny na ´ uc ˇtu. Software centra ´lnı ´ho poc ˇı ´tac ˇe doda ´ banka. Syste ´m vyz ˇaduje uchova ´va ´nı ´ za ´znamu ˚ o c ˇinnosti a zabezpec ˇenı ´. [] * provedeme dome ´novou analy ´zu, cı ´lem maxima ´lnı ´ porozume ˇnı ´ dome ´ne ˇ aplikace - napr ˇ. sezna ´mı ´me se s c ˇinnostı ´ bankomatu ˚, jejich zabezpec ˇenı ´m apod. * navrhneme za ´kladnı ´ dome ´nove ´ tr ˇı ´dy, tj. tr ˇı ´dy reprezentujı ´cı ´ objekty relevantnı ´ v aplikac ˇnı ´ dome ´ne ˇ (napr ˇ. organizac ˇnı ´ jednotky - katedry a fakulty, role - student, uc ˇitel, ´ ur ˇednı ´k atd.) je vhodne ´ mı ´t pro sbe ˇr poz ˇadavku ˚ - sledujeme podstatna ´ jme ´na v definici proble ´mu, ve ˇci a mı ´sta v aplikac ˇnı ´ dome ´ne ˇ, pro kaz ˇde ´ vytvor ˇı ´me pr ˇedbe ˇz ˇnou tr ˇı ´du (tr ˇı ´da je zatı ´m popsa ´na pouze jme ´nem); slovesa zaznamena ´me, aby c ˇasem mohla by ´t operacemi - eliminujeme nepotr ˇebne ´ a chybne ´ pr ˇedbe ˇz ˇne ´ tr ˇı ´dy . tr ˇı ´dy, ktere ´ nejsou pro aplikaci relevantnı ´, zrus ˇı ´me . pokud pr ˇedbe ˇz ˇna ´ tr ˇı ´da popisuje jednotlivy ´ objekt (napr ˇ. jme ´no, ve ˇk apod.) a nemusı ´ existovat samostatne ˇ, prohla ´sı ´me jı ´ za atribut . pokud pr ˇedbe ˇz ˇna ´ tr ˇı ´da popisuje c ˇinnost objektu, prohla ´sı ´me jı ´ za operaci (napr ˇ. telefonnı ´ spojenı ´ mu ˚z ˇe by ´t posloupnost akcı ´ uvnitr ˇ telefonnı ´ sı ´te ˇ, akte ´ry jsou telefonnı ´ ´ uc ˇastnı ´ci) . mezi pr ˇedbe ˇz ˇny ´mi tr ˇı ´dami by se neme ˇly objevovat implementac ˇnı ´ konstrukce (napr ˇ. seznam, pole, strom, tabulka apod.) Zda bude pr ˇedbe ˇz ˇny ´ objekt zachova ´n za ´visı ´ na typu aplikace, kterou vyvı ´jı ´me. Napr ˇ. pokud vyra ´bı ´me telefony, bude ”telefonnı ´ spojenı ´” souc ˇa ´stı ´ dynamicke ´ho
zswi/p6ooa.d
zswi/p6ooa.d
3. ledna 2005
59
modelu aplikace (viz vy ´s ˇe). Pokud naopak prova ´dı ´me ´ uc ˇtova ´nı ´ telefonnı ´ch hovoru ˚ , bude tote ´z ˇ du ˚lez ˇita ´ tr ˇı ´da nas ˇeho modelu (s atributy jako je datum a c ˇas, trva ´nı ´ spojenı ´ apod.). V te ´to poc ˇa ´tec ˇnı ´ fa ´zi se zatı ´m nesnaz ˇı ´me tr ˇı ´dy strukturovat, protoz ˇe bychom mohli podve ˇdome ˇ potlac ˇit ne ˇktere ´ podstatne ´ podrobnosti. Napr ˇı ´klad pokud bychom vytva ´r ˇeli syste ´m pro katalogizaci knihovny, vznikajı ´ na ´m tr ˇı ´dy pro ru ˚ zne ´ typy objektu ˚ (knihy, c ˇasopisy, klasicke ´ desky, CD, ...). Strukturova ´nı ´ do kategoriı ´ provedeme pozde ˇji vyhleda ´nı ´m podobnostı ´ a rozdı ´lu ˚ mezi za ´kladnı ´mi tr ˇı ´dami. Pr ˇı ´klad: Pr ˇedbe ˇz ˇne ´ tr ˇı ´dy vyply ´vajı ´cı ´ z definice proble ´mu: software, bankomat, centra ´lnı ´ poc ˇı ´tac ˇ, banka, transakce, ´ uc ˇet, za ´znam o c ˇinnosti, zabezpec ˇenı ´. Pr ˇedbe ˇz ˇne ´ tr ˇı ´dy vyply ´vajı ´cı ´ z aplikac ˇnı ´ dome ´ny: klient, platebnı ´ karta, stvrzenka, vy ´plata. Eliminujeme va ´gnı ´ tr ˇı ´dy: software, zabezpec ˇenı ´. [] * provedeme sbe ˇr poz ˇadavku ˚ - jak budou potencia ´lnı ´ uz ˇivatele ´ vyuz ˇı ´vat syste ´m, nejc ˇaste ˇji na za ´klade ˇ pr ˇı ´padu ˚ pouz ˇitı ´ - urc ˇenı ´ akte ´ru ˚ - tj. uz ˇivatelu ˚ a spolupracujı ´cı ´ch syste ´mu ˚ . prima ´rnı ´ uz ˇivatele ´, tj. ti, kdo vyuz ˇ´ ıvajı ´ hlavnı ´ fce syste ´mu . sekunda ´rnı ´ uz ˇivatele ´, tj. ti, kdo syste ´m administrujı ´ a udrz ˇujı ´ . externı ´ HW nebo SW syste ´my, se ktery ´mi bude navrhovany ´ syste ´m komunikovat - identifikace pr ˇı ´padu ˚ pouz ˇitı ´ (metodika viz konec 3. pr ˇedna ´s ˇky); souhrn pr ˇ´ ıpadu ˚ pouz ˇitı ´ by me ˇl pokry ´vat vs ˇechny moz ˇne ´ zpu ˚soby vyz ˇitı ´ syste ´mu - struc ˇny ´ popis ´ uc ˇelu pr ˇı ´padu pouz ˇitı ´ (cca odstavec) - rozloz ˇenı ´ pr ˇı ´padu pouz ˇitı ´ na kroky . za ´kladnı ´ posloupnost aktivit, tj. kroky akte ´ra a odpove ˇdi syste ´mu . alternativnı ´ posloupnosti aktivit - pr ˇ´ ıpady pouz ˇitı ´ a akte ´ry strukturujeme pomocı ´ extend a include . hleda ´me posloupnosti kroku ˚ spolec ˇne ´ pro vı ´ce pr ˇı ´padu ˚ pouz ˇitı ´ - pokud je pr ˇı ´padu ˚ pouz ˇitı ´ velke ´ mnoz ˇstvı ´, seskupı ´me je do balı ´c ˇku ˚ tak, aby balı ´c ˇek pr ˇedstavoval vysokou ´rovn ˇovou oblast funkc ˇnosti syste ´mu * pr ˇı ´pady pouz ˇitı ´, ktere ´ lze snadno pr ˇehle ´dnout, protoz ˇe se nety ´kajı ´ prima ´rnı ´ch funkcı ´ syste ´mu: - start a ukonc ˇenı ´ syste ´mu - administrace syste ´mu, napr ˇ. pr ˇida ´va ´nı ´ novy ´ch uz ˇivatelu ˚, za ´lohova ´nı ´ dat apod. - funkc ˇnost potr ˇebna ´ pro modifikaci chova ´nı ´ syste ´mu; napr ˇ. z informac ˇnı ´ho syste ´mu potr ˇebujeme vytva ´r ˇet nove ´ typy vy ´stupu ˚ Pr ˇı ´klad:
Bankomat
Klient
Výběr hotovosti
Centrální počítač
Pr ˇı ´pad pouz ˇitı ´: Vy ´be ˇr pene ˇz z bankomatu. Akte ´r ˇi: Klient, Centra ´lnı ´ poc ˇı ´tac ˇ Struc ˇny ´ popis: Za ´kaznı ´k vloz ˇı ´ kartu a poz ˇa ´da ´ o vy ´be ˇr urc ˇite ´ c ˇa ´stky. Bankomat mu po potvrzenı ´ centra ´lnı ´m poc ˇı ´tac ˇem poz ˇadovanou c ˇa ´stku vyda ´. Popis jednotlivy ´ch kroku ˚ za ´kladnı ´ho sce ´na ´r ˇe: 1. 2. 3. 4. 5.
Klient vloz ˇı ´ kartu. Bankomat kartu pr ˇec ˇte a zjistı ´ jejı ´ se ´riove ´ c ˇı ´slo. Bankomat poz ˇa ´da ´ uz ˇivatele o zada ´nı ´ PIN; uz ˇivatel zada ´ ”1234”. Bankomat ove ˇr ˇı ´ c ˇı ´slo karty a PIN u centra ´lnı ´ho poc ˇı ´tac ˇe. Bankomat poz ˇa ´da ´ o zada ´nı ´ velikosti c ˇa ´stky; uz ˇivatel zada ´ 1000 Kc ˇ Bankomat poz ˇa ´da ´ centra ´lnı ´ poc ˇı ´tac ˇ o provedenı ´ transakce; centra ´lnı ´ poc ˇı ´tac ˇ transakci provede a vra ´tı ´ novy ´ zu ˚statek ´ uc ˇtu. 6. Bankomat vyda ´ c ˇa ´stku, vytiskne stvrzenku a vra ´tı ´ kartu.
Za´klady softwarove´ho inzˇeny´rstvı´
60
Alternativnı ´ sce ´na ´r ˇe: A1. Uz ˇivatel vloz ˇı ´ kartu. Bankomat kartu pr ˇec ˇte a zjistı ´ jejı ´ se ´riove ´ c ˇı ´slo. A2. Bankomat poz ˇa ´da ´ uz ˇivatele o zada ´nı ´ PIN; uz ˇivatel zada ´ ”9999”. A3. Bankomat se pokusı ´ ove ˇr ˇit c ˇı ´slo karty a PIN u centra ´lnı ´ho poc ˇı ´tac ˇe; centra ´lnı ´ poc ˇı ´tac ˇ je odmı ´tne. A4. Bankomat ozna ´mı ´, z ˇe PIN bylo chybne ´, a vyzve uz ˇivatele, aby ho zadal znovu; uz ˇivatel zada ´ ”1234”, coz ˇ bankomat ´ uspe ˇs ˇne ˇ ove ˇr ˇı ´ u centra ´lnı ´ho poc ˇı ´tac ˇe. A5. Bankomat poz ˇa ´da ´ o zada ´nı ´ velikosti c ˇa ´stky; uz ˇivatel zada ´ 1000 Kc ˇ. A6. Bankomat poz ˇa ´da ´ centra ´lnı ´ poc ˇı ´tac ˇ o provedenı ´ transakce; centra ´lnı ´ poc ˇı ´tac ˇ transakci odmı ´tne pro nı ´zky ´ zu ˚statek na ´ uc ˇtu. A7. Bankomat vytiskne stvrzenku a vra ´tı ´ kartu. Jak vidı ´me, vy ´sledkem je pouze soubor pr ˇı ´kladovy ´ch sce ´na ´r ˇ˚ u, ktery ´ v z ˇa ´dne ´m pr ˇı ´pade ˇ nenı ´ ´ uplnou specifikacı ´ syste ´mu. []
Analy ´za ....... Pr ˇehled kroku ˚ OO analy ´zy: * vstupem je popis pr ˇı ´padu ˚ pouz ˇitı ´ a dome ´nove ´ tr ˇı ´dy * pr ˇı ´pady pouz ˇitı ´ zjemnı ´me sme ˇrem k implementaci pomocı ´ dynamicky ´ch modelu ˚, nejc ˇaste ˇji sekvenc ˇnı ´ch diagramu ˚ (synchronnı ´ chova ´nı ´) nebo pomocı ´ stavovy ´ch diagramu ˚ a diagramu ˚ spolupra ´ce (asynchronnı ´ chova ´nı ´) * vytvor ˇı ´me diagram analyticky ´ch tr ˇı ´d * chova ´nı ´ popsane ´ v pr ˇı ´padech pouz ˇitı ´ distribuujeme na objekty - rozebı ´ra ´me jeden pr ˇı ´pad pouz ˇitı ´ po druhe ´m - popı ´s ˇeme, ktery ´ objekt je zodpove ˇdny ´ za ktere ´ chova ´nı ´ v pr ˇı ´padu pouz ˇitı ´ - nı ´z ˇe uvedu 2 pr ˇı ´klady - pomocı ´ CRC karet a pomocı ´ sekvenc ˇnı ´ch diagramu ˚ * v ne ˇktery ´ch metodika ´ch je oblı ´bena ´ technika pouz ˇitı ´ tzv. CRC karet (z angl. Class/Responsibilities/Collaborators) - pro tr ˇı ´dy vytvor ˇı ´me kartic ˇky, nahoru napı ´s ˇeme jme ´no tr ˇı ´dy, vlevo zodpove ˇdnost tr ˇı ´dy, vpravo spolupracujı ´cı ´ tr ˇı ´dy - pr ˇi pru ˚chodu sce ´na ´r ˇem pr ˇida ´va ´me nove ´ odpove ˇdnosti existujı ´cı ´m tr ˇı ´da ´m; pokud neumı ´me, rozde ˇlı ´me existujı ´cı ´ tr ˇı ´du na dve ˇ nebo zaloz ˇı ´me novou - nevy ´hoda CRC karet - vazby mezi tr ˇı ´dami nejsou zna ´zorne ˇny graficky * pro projekt str ˇednı ´ velikosti zı ´ska ´me 30 az ˇ 100 tr ˇı ´d
Pr ˇı ´klad: tr ˇı ´da: Centra ´lnı ´ poc ˇı ´tac ˇ -----------------------odpove ˇdnost: spolupracuje s: -------------------------* ove ˇr ˇı ´ c ˇı ´slo karty a PIN * bankomat * provede transakci * vra ´tı ´ novy ´ zu ˚statek ´ uc ˇtu [] * pro podrobne ˇjs ˇı ´ popis chova ´nı ´ mu ˚z ˇeme pouz ˇı ´t dynamicke ´ modely UML - nejprve rozebereme za ´kladnı ´ sekvenci z pr ˇı ´padu pouz ˇitı ´ - alternativnı ´ sekvence ve ˇts ˇinou popisuje reakci na chyby, zac ˇlenı ´me pozde ˇji - opravujeme seznam tr ˇı ´d
zswi/p6ooa.d
zswi/p6ooa.d
3. ledna 2005
61
Pr ˇı ´klad (sekvenc ˇnı ´ diagram pro pr ˇı ´pad pouz ˇitı ´ ”Vy ´be ˇr pene ˇz z bankomatu”)
klient
bankomat
centrální počítač
vloží kartu vyžádá PIN zadá PIN ověř kartu a PIN OK
vyžádá zadání částky zadá částku
zpracuj transakci zůstatek na účtu
vydá částku vrátí kartu
[] * konstrukce diagramu tr ˇı ´d: - na poc ˇa ´tku je tr ˇı ´da popsa ´na pouze na ´zvem - zkontrolujeme, zda nenı ´ jiny ´m na ´zvem pro existujı ´cı ´ tr ˇı ´du (ponecha ´me ten na ´zev, ktery ´ objekt popisuje nejle ´pe), zda nenı ´ role (jme ´no tr ˇı ´dy ma ´ popisovat jejı ´ esenci, nikoli pouze roli, kterou hraje v sekvenc ˇnı ´m diagramu apod.) - ke tr ˇı ´de ˇ najdeme logicke ´ atributy = informace, ktera ´ se nebude pouz ˇı ´vat samostatne ˇ, ale je silne ˇ sva ´za ´na s objektem (napr ˇ. jme ´no, ve ˇk, adresa budou atributy ne ˇjake ´ Osoby) * tr ˇı ´dy mu ˚z ˇeme rozde ˇlit podle na ´sledujı ´cı ´ch stereotypu ˚: - vs ˇechno s c ˇı ´m akte ´r ˇi pr ˇı ´mo komunikujı ´, budou hranic ˇnı ´ tr ˇı ´dy; mu ˚z ˇeme je zjistit napr ˇ. z popisu pr ˇı ´padu pouz ˇitı ´ . nejc ˇaste ˇjs ˇı ´ hranic ˇnı ´ tr ˇı ´dy: formula ´r ˇe, komunikac ˇnı ´ protokoly, rozhranı ´ pro tiska ´rnu . v UML mu ˚z ˇeme hranic ˇnı ´ tr ˇı ´dy oznac ˇovat stereotypem <> nebo nı ´z ˇe uvedenou znac ˇkou (pr ˇı ´padne ˇ obe ˇma zpu ˚soby za ´roven ˇ) - informace, kterou syste ´m udrz ˇuje dels ˇı ´ dobu, skryjeme v entitnı ´ch objektech; entitnı ´ objekty c ˇasto odpovı ´dajı ´ objektu ˚m rea ´lne ´ho sve ˇta . typicky ´ pr ˇı ´klad: Student, Fakulta, Pr ˇedme ˇt apod. . entitnı ´ objekty samy od sebe neiniciujı ´ komunikaci . v UML stereotyp <<entity>> - chova ´nı ´ v syste ´mu koordinujı ´ r ˇı ´dı ´cı ´ tr ˇı ´dy . napr ˇ. tr ˇı ´dy obsahujı ´cı ´ r ˇı ´dı ´cı ´ logiku, pouz ˇı ´vajı ´cı ´ nebo nastavujı ´cı ´ obsah entitnı ´ch tr ˇı ´d . obvykle se ty ´kajı ´ realizace jedine ´ho pr ˇı ´padu pouz ˇitı ´ . pokud je chova ´nı ´ jednoduche ´, nemusejı ´ by ´t r ˇ´ ıdı ´cı ´ tr ˇı ´dy zapotr ˇebı ´ . v UML stereotyp <>
a) hraniční třída
b) entiní třída
boundary class
entity class
c) řídící třída control class
Pr ˇı ´klad (ope ˇt bankomat): ´c Entitnı ´mi objekty budou v nas ˇem pr ˇı ´kladu Klient a U ˇet. Vy ´be ˇr pene ˇz musı ´ by ´t ove ˇr ˇen centra ´lnı ´m poc ˇı ´tac ˇem, ktery ´ vystupuje jako akte ´r. Komunikace s tı ´mto akte ´rem probı ´ha ´ prostr ˇednictvı ´m tzv. ATM sı ´te ˇ, jejı ´z ˇ rozhranı ´ (ATM Network Interface) bude hranic ˇnı ´m objektem. Hranic ˇnı ´mi objekty uz ˇivatelske ´ho rozhranı ´ budou kla ´vesnice, obrazovka, c ˇtec ˇka platebnı ´ch karet, vy ´dejnı ´ automat bankomatu, tiska ´rna stvrzenek apod. Pro hranic ˇnı ´ objekty pr ˇedstavujı ´cı ´ uz ˇivatelske ´ rozhranı ´ bychom v te ´to fa ´zi me ˇli vytvor ˇit na ´c ˇrtek nebo prototyp, ktery ´ by si uz ˇivatel mohl vyzkous ˇet.
Za´klady softwarove´ho inzˇeny´rstvı´
62 stvrzenky
zswi/p6ooa.d
čtečka karet
výdej hotovosti
obrazovka
5
6
7
8
9
0
1
2
3
4
Cancel
Enter
Pozor: zatı ´m pouze zı ´ska ´va ´me poz ˇadavky na uz ˇivatelske ´ rozhranı ´, nede ˇla ´me na ´vrh. [] * Constantine a Lockwood (1999) r ˇı ´kajı ´, z ˇe prototyp uz ˇivatelske ´ho rozhranı ´ ma ´ by ´t abstraktnı ´ - pr ˇı ´lis ˇ konkre ´tnı ´ (”hezky vypadajı ´cı ´”) prototypy odva ´de ˇjı ´ pozornost od principia ´lnı ´ch proble ´mu ˚ - abstraktnı ´ modely dovolujı ´ najı ´t rychleji dobre ´ r ˇes ˇenı ´, protoz ˇe na ´s nezate ˇz ˇujı ´ podrobnostmi * vytva ´r ˇı ´me pr ˇedbe ˇz ˇne ´ asociace mezi tr ˇı ´dami - pr ˇedstavujı ´ vztah mezi instancemi, ktery ´ ne ˇjakou dobu pr ˇetrva ´va ´ (napr ˇ. Osoba pracuje pro Firmu); objekty o sobe ˇ navza ´jem ”ve ˇdı ´” - asociace mohou odpovı ´dat fyzicke ´mu umı ´ste ˇnı ´ nebo vztahu vlastnictvı ´ (ma ´ spojenı ´ s, je souc ˇa ´stı ´, je obsaz ˇen v, patr ˇı ´), r ˇı ´zenı ´ a komunikaci (r ˇı ´dı ´, komunikuje s) - asociace me ˇly by by ´t pojmenova ´ny ´ uc ˇelem asociace - na poc ˇa ´tku se nesnaz ˇı ´me rozlis ˇit asociace a agregace, neuva ´dı ´me na ´sobnosti ani pru ˚ chodnost Pr ˇı ´klad (ope ˇt bankomat) Pr ˇedbe ˇz ˇne ´ asociace mezi vytvor ˇeny ´mi tr ˇı ´dami: Vlastní
Klient Tiskne
Stvrzenka
Vydává
Banka
Vlastní
Spravuje
Účet
Výplata Přistupuje k
Bankomat
Zadána na
Transakce
Autorizuje
Platební karta
Přijímá
* zrus ˇı ´me nepotr ˇebne ´ nebo nespra ´vne ´ asociace - v te ´to fa ´zi zrus ˇı ´me asociace, ktere ´ nejsou podstatne ´ pro r ˇes ˇeny ´ proble ´m, jsou redundantnı ´ nebo ktere ´ pr ˇedstavujı ´ popis implementace . napr ˇı ´klad asociace ”je prarodic ˇem” lze popsat pomocı ´ dvou asociacı ´ ”je rodic ˇ” (ne ˇkdy ale mu ˚z ˇou by ´t i odvozene ´ asociace uz ˇitec ˇne ´!) - zrus ˇı ´me pr ˇedbe ˇz ˇne ´ asociace, pr ˇedstavujı ´cı ´ jednora ´zove ´ akce; napr ˇ. bankomat sice pr ˇijı ´ma ´ platebnı ´ karty, ale mezi bankomatem a platebnı ´ kartou neexistuje trvaly ´ (struktura ´lnı ´) vztah; tj. ve vy ´s ˇe uvedene ´m pr ˇı ´kladu zrus ˇı ´me pr ˇedbe ˇz ˇne ´ asociace (v obra ´zku jsou zrus ˇene ´ asociace s ˇkrtnuty) - vyhy ´ba ´me se asociacı ´m mezi dve ˇma r ˇı ´dı ´cı ´mi objekty a mezi hranic ˇnı ´m a ˇı r ´dı ´cı ´m objektem, protoz ˇe oba typy vztahu ˚ trvajı ´ kra ´tkou dobu . vztahy, ktere ´ nepr ˇetrva ´vajı ´, mu ˚z ˇeme modelovat jako za ´vislosti - vyhy ´ba ´me se terna ´rnı ´m a vys ˇs ˇı ´m asociacı ´m, ve ˇts ˇinou je lze pr ˇestrukturovat na bina ´rnı ´ asociace nebo pr ˇı ´padne ˇ popsat asociac ˇnı ´ tr ˇı ´dou . napr ˇı ´klad Firma vypla ´cı ´ Plat Osobe ˇ lze pr ˇestrukturovat: Firma zame ˇstna ´va ´ Osobu, Plat mu ˚z ˇe by ´t atributem asociace ”zame ˇstna ´va ´”
zswi/p6ooa.d
3. ledna 2005
63
Vlastní
Klient Vlastní
Banka
Spravuje
Účet
Přistupuje k
Zadána na
Bankomat
Transakce
Autorizuje
Platební karta
* vytva ´r ˇı ´me agregace a kompozice - agregace, pokud objekt je souc ˇa ´stı ´ jine ´ho nebo objekt je podr ˇı ´zeny ´ jine ´mu, napr ˇ. pokud se ne ˇktere ´ operace nad celkem provedou nad vs ˇemi c ˇa ´stmi - kompozice, pokud je silne ´ vlastne ˇnı ´ (strom souc ˇa ´stı ´, souc ˇa ´sti nelze sdı ´let) a stejna ´ doba z ˇivota * hleda ´me prima ´rnı ´ atributy objektu ˚ a asociacı ´ - hleda ´me zatı ´m pouze nejdu ˚ lez ˇite ˇjs ˇı ´ logicke ´ atributy, relevantnı ´ pro aplikaci - jsou to navenek viditelne ´ vlastnosti jednotlivy ´ch objektu ˚, jako je jme ´no, rychlost, barva apod. Vydává Vlastní
Klient +jméno +adresa
Banka
Vlastní
Spravuje
+název
Účet +typ účtu +částka +limit na výběr
Přistupuje k
Bankomat
Transakce Zadána na
+dostupná hotovost
+druh +datum a čas +částka
Autorizuje
Platební karta +PIN
* vytva ´r ˇı ´me hierarchii de ˇdic ˇnosti, mu ˚z ˇeme postupovat dve ˇma sme ˇry - zdola nahoru, tj. zobecne ˇnı ´m - hleda ´me tr ˇı ´dy se spolec ˇny ´mi vlastnostmi, ktere ´ vyjmeme do nadtr ˇı ´dy (napr ˇ. Be ˇz ˇny ´ ´ uc ˇet a Spor ˇı ´cı ´ ´ uc ˇet) - shora dolu ˚, tj. specializacı ´ - existujı ´cı ´ tr ˇı ´dy zjemnı ´me pomocı ´ podtr ˇı ´d - vytvor ˇena ´ hierarchie by neme ˇla by ´t zbytec ˇne ˇ hluboka ´ (zvla ´s ˇte ˇ v pr ˇı ´pade ˇ, z ˇe cı ´lovy ´ jazyk nebude OO) - pokud chceme vyuz ˇı ´t polymorfismus, vedeme asociaci k rodic ˇovske ´ tr ˇı ´de ˇ
Banka
Spravuje
Spořící účet
Účet Běžný účet
* testujeme dostupnost vu ˚c ˇi dotazu ˚ m - je pro tr ˇı ´du moz ˇne ´ zı ´skat hodnotu nebo hodnoty, ktere ´ potr ˇebuje? - pokud chybı ´ cesta, je pravde ˇpodobne ˇ zapotr ˇebı ´ pr ˇidat asociaci * vy ´sledne ´ diagramy specifikujı ´ strukturu syste ´mu, ale nikoli du ˚ vody, ktere ´ na ´s k nı ´ vedly; ty bychom me ˇli take ´ zdokumentovat Cı ´lem analy ´zy je dostatec ˇne ˇ popsat proble ´m a aplikac ˇnı ´ dome ´nu bez za ´vislosti na konkre ´tnı ´ implementaci (i kdyz ˇ v praxi nenı ´ moz ˇne ´ tento cı ´l vz ˇdycky splnit). Analy ´za nenı ´ v z ˇa ´dne ´m pr ˇı ´pade ˇ jednoducha ´ sekvence akcı ´ s jasny ´m koncem, ale
Za´klady softwarove´ho inzˇeny´rstvı´
64
iterativnı ´ proces, ke ktere ´mu se musı ´me vracet po ve ˇts ˇinu doby vy ´voje ˇasto by syste ´mu. C ´va ´ citova ´n vy ´rok: ... analysis is frustrating, full of complex interpersonal relationships, indefinite, and difficult. In a word, it is fascinating. Once hooked, the old easy pleasures of system building are never again enough to satisfy you. [Tom DeMarco, 1978]
Na ´vrh architektury syste ´mu -------------------------* architektura SW syste ´mu = vysokou ´rovn ˇovy ´ design SW - v anglic ˇtine ˇ se pouz ˇı ´vajı ´ na ´zvy system architecture, design, high-level design, top-level design, system design apod. - architektura slouz ˇı ´ jako ra ´mec pro podrobne ˇjs ˇı ´ na ´vrh rozsa ´hle ´ho syste ´mu - popisuje organizaci syste ´mu do podsyste ´mu ˚, alokaci podsyste ´mu ˚ na HW a SW komponenty - architektura syste ´mu se navrhuje bud’ po analy ´ze (tj. pr ˇed podrobny ´m na ´vrhem), nebo se jejı ´ na ´vrh pr ˇekry ´va ´ s podrobny ´m designem . pokud na ´sleduje po analy ´ze, umoz ˇnı ´ rozde ˇlit navrhovany ´ syste ´m do podsyste ´mu ˚, jejichz ˇ na ´vrh pak mu ˚z ˇe probı ´hat neza ´visle - jak zdu ˚razn ˇuje mnoho autoru ˚, dobr ˇe navrz ˇena ´ architektura je podmı ´nkou pro vc ˇasne ´ odlade ˇnı ´ a pro udrz ˇovatelnost produktu Na ´vrh architektury SW syste ´mu obvykle probı ´ha ´ v te ˇchto krocı ´ch: * * * * *
rozde ˇlenı ´ syste ´mu do podsyste ´mu ˚ rozde ˇlenı ´ do vrstev a oddı ´lu ˚ (partitions) na ´vrh topologie syste ´mu identifikace paralelismu, alokace na uzly a volba komunikace volba zpu ˚sobu r ˇı ´zenı ´ atd.
Rozde ˇlenı ´ syste ´mu do podsyste ´mu ˚ ............................... * rozde ˇlenı ´ syste ´mu do podsyste ´mu ˚ prova ´dı ´me pro vs ˇechny ve ˇts ˇı ´ aplikace - podsyste ´m bude obsahovat aspekty syste ´mu s ne ˇjaky ´mi podobny ´mi vlastnostmi (podobna ´ funkc ˇnost, stejne ´ fyzicke ´ umı ´ste ˇnı ´ apod.) - napr ˇı ´klad kosmicka ´ lod’ bude obsahovat podsyste ´my pro podporu z ˇivotnı ´ch funkcı ´, pro navigaci, pro r ˇı ´zenı ´ motoru ˚, pro r ˇı ´zenı ´ experimentu ˚ apod. - nebo operac ˇnı ´ syste ´m bude obsahovat podsyste ´my pro pla ´nova ´nı ´ procesu ˚, spra ´vu pame ˇti, syste ´m souboru ˚ apod. - podsyste ´mu ˚ by neme ˇlo by ´t moc (i pro velke ´ syste ´my cca do 20) * podsyste ´m mu ˚z ˇeme nejsna ´ze identifikovat pomocı ´ sluz ˇeb, ktere ´ poskytuje - sluz ˇba = mnoz ˇina fcı ´, ktere ´ majı ´ stejny ´ za ´kladnı ´ ´ uc ˇel - napr ˇ. souborovy ´ syste ´m poskytuje mnoz ˇinu pr ˇı ´buzny ´ch sluz ˇeb, jejichz ˇ za ´kladnı ´m ´ uc ˇelem je poskytnout pr ˇı ´stup k souboru ˚m - hranice podsyste ´mu bychom me ˇli volit tak, aby ve ˇts ˇina komunikace probı ´hala uvnitr ˇ podsyste ´mu (mezi mnoz ˇinou objektu ˚ nebo modulu ˚ tvor ˇı ´cı ´ch podsyste ´m) * vztah mezi dve ˇma podsyste ´my mu ˚z ˇe by ´t klient-poskytovatel (client-supplier) nebo peer-to-peer - vztah klient-poskytovatel - klient vola ´ poskytovatele, ktery ´ vykona ´ ne ˇjakou sluz ˇbu a pos ˇle odpove ˇd’; poskytovatel nemusı ´ zna ´t rozhranı ´ klienta - vztah peer-to-peer - kaz ˇdy ´ podsyste ´m mu ˚z ˇe volat druhy ´, tj. oba musejı ´ zna ´t rozhranı ´ toho druhe ´ho . vztah peer-to-peer je komplikovane ˇjs ˇ´ ı, mohou v ne ˇm vznikat obtı ´ˇ zne ˇ srozumitelne ´ komunikac ˇnı ´ cykly => snaz ˇı ´me se o vztah klient-poskytovatel, kdekoli je to moz ˇne ´ * dekompozice syste ´mu do podsyste ´mu ˚ - za ´kladnı ´ rozde ˇlenı ´ do horizonta ´lnı ´ch vrstev nebo vertika ´lnı ´ch oddı ´lu ˚
zswi/p6ooa.d
zswi/p6ooa.d
3. ledna 2005
65
Rozde ˇlenı ´ do vrstev ................... * vrstvene ´ syste ´my = uspor ˇa ´dana ´ mnoz ˇina virtua ´lnı ´ch sve ˇtu ˚ - kaz ˇdy ´ sve ˇt je vystave ˇn z prvku ˚ niz ˇs ˇı ´ho sve ˇta a poskytuje stavebnı ´ prvky vys ˇs ˇı ´mu sve ˇtu - mezi vrstvami vztah klient-poskytovatel - niz ˇs ˇı ´ vrstvy (poskytovatele ´) poskytujı ´ sluz ˇby vys ˇs ˇı ´m vrstva ´m (klientu ˚m) - znalost je jednosme ˇrna ´, tj. podsyste ´m zna ´ jednu nebo vı ´ce vrstev pod sebou, ale nezna ´ vrstvy nad sebou * objekty ve stejne ´ vrstve ˇ mohou by ´t neza ´visle ´, ale mezi objekty v ru ˚zny ´ch vrstva ´ch obvykle existuje korespondence (napr ˇ. poskytujı ´ obdobne ´ sluz ˇby na ru ˚zny ´ch ´ urovnı ´ch abstrakce) Pr ˇı ´klad (interaktivnı ´ graficky ´ syste ´m) * v interaktivnı ´m graficke ´m syste ´mu - aplikace pracuje s okny - okna jsou implementova ´na pomocı ´ graficky ´ch operacı ´ typu ”nakresli c ˇa ´ru” nebo ”vybarvi obde ´lnı ´k” - graficke ´ operace jsou implementova ´ny pomocı ´ operacı ´ nad jednotlivy ´mi pixely * kaz ˇda ´ vrstva mu ˚z ˇe mı ´t svou vlastnı ´ mnoz ˇinu tr ˇı ´d a operacı ´, je implementova ´na pomocı ´ tr ˇı ´d a operacı ´ niz ˇs ˇı ´ vrstvy
Application
Version management
Windows graphics
Object management Database system
Screen Graphics Pixel Graphics
Operating system
7 6 5 4 3 2 1
Application layer Presentation layer Session layer Transport layer Network layer Data link layer Physical layer
[] vrstvene ´ architektury dvou typu ˚ , a to uzavr ˇene ´ a otevr ˇene ´ - uzavr ˇene ´ (striktne ˇ vrstvene ´) - vrstva je implementova ´na pouze pomocı ´ prostr ˇedku ˚ nejbliz ˇs ˇı ´ niz ˇs ˇı ´ vrstvy . omezuje za ´vislosti mezi vrstvami = princip skry ´va ´nı ´ informacı ´ . dovoluje snadne ˇjs ˇı ´ zme ˇny rozhranı ´ - zme ˇna ovlivnı ´ jen nejbliz ˇs ˇı ´ vys ˇs ˇı ´ vrstvu . napr ˇı ´klad sı ´t’ove ´ modely, jako je sedmivrstvy ´ ISO/OSI model, jsou uzavr ˇene ´ - otevr ˇene ´ - mu ˚z ˇe pouz ˇı ´vat prostr ˇedky ktere ´koli niz ˇs ˇı ´ vrstvy . omezuje potr ˇebu definovat obdobne ´ operace v kaz ˇde ´ vrstve ˇ, ko ´d mu ˚z ˇe by ´t kompaktne ˇjs ˇı ´ a efektivne ˇjs ˇı ´ . zme ˇna podsyste ´mu mu ˚z ˇe ovlivnit kteroukoli vys ˇs ˇı ´ vrstvu - obtı ´z ˇna ´ ´ udrz ˇba . napr ˇı ´klad graficke ´ syste ´my (zme ˇnu pixelu lze vyvolat z ktere ´koli vrstvy) - oba typy architektury jsou uz ˇitec ˇne ´, pr ˇi na ´vrhu je nutne ´ volit mezi modularitou a efektivitou * specifikace proble ´mu obvykle definuje pouze svrchnı ´ vrstvu (= poz ˇadovany ´ syste ´m) * spodnı ´ vrstva je da ´na dostupny ´mi zdroji (HW, OS, knihovny) * pokud je velky ´ rozdı ´l, je pr ˇi na ´vrhu zapotr ˇebı ´ pr ˇidat mezilehle ´ vrstvy pro pr ˇemoste ˇnı ´ pr ˇı ´padne ´ konceptua ´lnı ´ mezery - male ´ syste ´my cca 3 vrstvy, pro velke ´ syste ´my obvykle postac ˇuje 5-7 vrstev (i pro nejsloz ˇite ˇjs ˇı ´ syste ´my je podezr ˇele ´ vı ´ce nez ˇ 10 vrstev) Pozna ´mka (doporuc ˇenı ´ z RUP) pokud ma ´me 0 - 10 10 - 50 25 - 150 100-1000 []
tr ˇı ´d tr ˇı ´d tr ˇı ´d tr ˇı ´d
pak vrstvenı ´ nenı ´ zapotr ˇebı ´ 2 vrstvy 3 vrstvy 4 vrstvy
Za´klady softwarove´ho inzˇeny´rstvı´
66
* nenı ´-li prostr ˇedı ´ pr ˇenositelne ´, povaz ˇuje se za vhodne ´ vytvor ˇit alespon ˇ jednu vrstvu mezi aplikacı ´ a sluz ˇbami poskytovany ´mi OS nebo HW (vrstva poskytuje logicke ´ sluz ˇby a mapuje je na fyzicke ´) - pr ˇepsa ´nı ´m te ´to vrstvy mu ˚z ˇeme syste ´m pr ˇene ´st na jinou platformu
Rozde ˇlenı ´ do oddı ´lu ˚ ................... * oddı ´ly (partitions) rozde ˇlujı ´ syste ´m vertika ´lne ˇ na neza ´visle ´ nebo slabe ˇ sva ´zane ´ podsyste ´my, kaz ˇdy ´ z nich poskytuje jiny ´ typ sluz ˇeb
Printer CD ROM Network driver driver driver
- napr ˇı ´klad operac ˇnı ´ syste ´m obsahuje ovladac ˇe pro jednotlive ´ typy zar ˇı ´zenı ´ - podsyste ´my mohou o sobe ˇ navza ´jem ne ˇco ve ˇde ˇt, ale protoz ˇe tato znalost nenı ´ velka ´, nevznikajı ´ podstatne ´ za ´vislosti mezi oddı ´ly - napr ˇ. v operac ˇnı ´m syste ´mu podsyste ´m pro pla ´nova ´nı ´ procesu ˚ a spra ´vu pame ˇti, pla ´nova ´nı ´ procesu ˚ ne ˇkdy potr ˇebuje ve ˇde ˇt, kolik je dostupne ´ pame ˇti apod. * syste ´m mu ˚z ˇe by ´t postupne ˇ dekomponova ´n do podsyste ´mu ˚ pomocı ´ vrstev a oddı ´lu ˚ (vrstvy mu ˚z ˇeme de ˇlit na oddı ´ly a naopak oddı ´ly do vrstev) - ve ve ˇts ˇine ˇ velky ´ch syste ´mu ˚ sme ˇs vrstev a oddı ´lu ˚ - pr ˇı ´klad:
Application GML API Configuration Manager
Simulator Interface GML Core
Thread Scheduler
Synchronization Layer POSIX.1 Interface Operating System
Topologie syste ´mu ................. * pote ´ co byly identifikova ´ny za ´kladnı ´ podsyste ´my, me ˇli bychom urc ˇit toky dat - ne ˇkdy mohou data te ´ci mezi vs ˇemi podsyste ´my, v praxi jen zr ˇı ´dka - ve ˇts ˇinou jednodus ˇs ˇı ´ uspor ˇa ´da ´nı ´ (jednoducha ´ roura - napr ˇ. pr ˇekladac ˇ, hve ˇzda napr ˇ. hlavnı ´ syste ´m r ˇı ´dı ´ podr ˇı ´zene ´) apod. - konkre ´tnı ´ pr ˇı ´klady uka ´z ˇeme pozde ˇji (v kapitole o architektonicky ´ch stylech) Identifikace paralelismu ........................ * dals ˇı ´m ´ ukolem je identifikovat, ktere ´ podsyste ´my majı ´ pracovat paralelne ˇ a u ktery ´ch se paralelnı ´ be ˇh vyluc ˇuje - paralelnı ´ podsyste ´my mohou by ´t implementova ´ny ru ˚zny ´mi HW jednotkami nebo ru ˚zny ´mi procesy nebo vla ´kny OS (c ˇasto za ´visı ´ na zada ´nı ´, napr ˇ. bankomaty musı ´ be ˇz ˇet navza ´jem neza ´visle => samostatne ´ HW jednotky) - podsyste ´my, kde nenı ´ moz ˇny ´ paralelnı ´ be ˇh, mohou by ´t napr ˇ. souc ˇa ´stı ´ stejne ´ho procesu * identifikace inherentnı ´ho paralelismu - jako vodı ´tko se pouz ˇı ´va ´ dynamicky ´ model - dva objekty jsou inherentne ˇ paralelnı ´, pokud mohou pr ˇijı ´mat uda ´losti ve stejne ´m c ˇase bez vza ´jemne ´ komunikace - inherentne ˇ paralelnı ´ objekty nemohou by ´t souc ˇa ´stı ´ stejne ´ho vla ´kna r ˇı ´zenı ´ - napr ˇı ´klad r ˇı ´zenı ´ kr ˇı ´del letadla a r ˇı ´zenı ´ motoru musı ´ probı ´hat paralelne ˇ nebo pr ˇı ´padne ˇ neza ´visle (lze implementovat neza ´visly ´m HW, cena vza ´jemne ´ komunikace bude mala ´)
zswi/p6ooa.d
zswi/p6ooa.d
3. ledna 2005
* definice paralelnı ´ch ´ uloh - vla ´kno r ˇı ´zenı ´ - mnoz ˇina objektu ˚ si navza ´jem pr ˇeda ´va ´ r ˇı ´zenı ´ tak, z ˇe v jednom c ˇase je aktivnı ´ pouze jeden objekt; r ˇı ´zenı ´ zu ˚sta ´va ´ objektu, dokud ten nepos ˇle zpra ´vu jine ´mu objektu - ru ˚zna ´ vla ´kna r ˇı ´zenı ´ mohou be ˇz ˇet navza ´jem paralelne ˇ
Alokace podsyste ´mu ˚ na poc ˇı ´tac ˇe nebo procesory ............................................. * alokace podsyste ´mu ˚ na poc ˇı ´tac ˇe nebo procesory vyz ˇaduje na ´sledujı ´cı ´ kroky: - odhad poz ˇadavku ˚ na HW zdroje - rozhodnutı ´, zda budeme podsyste ´m implementovat jako HW nebo jako SW - alokace na poc ˇı ´tac ˇe nebo procesory (jednotky) - urc ˇenı ´ propojenı ´ fyzicky ´ch jednotek * provedeme odhad poz ˇadavku ˚ na HW zdroje - hruby ´ odhad potr ˇebne ´ vy ´poc ˇetnı ´ sı ´ly mu ˚z ˇeme prove ´st napr ˇ. na za ´klade ˇ poz ˇadovane ´ho poc ˇtu transakcı ´ za sekundu a doby zpracova ´nı ´ jedne ´ transakce (ve ˇts ˇinou odhad na za ´klade ˇ experimentu ˚) - pokud je zapotr ˇebı ´ ve ˇts ˇı ´ vy ´konnost nez ˇ mu ˚z ˇe poskytnout jeden CPU, pr ˇida ´me dals ˇı ´ procesory, pr ˇı ´padne ˇ implementujeme HW * rozhodnutı ´, zda podsyste ´m bude implementova ´n HW nebo SW - HW mu ˚z ˇeme povaz ˇovat za ”zatuhlou” optimalizovanou formu SW - k implementaci v HW vedou dva hlavnı ´ du ˚vody: . existuje HW, ktery ´ poskytuje pr ˇesne ˇ poz ˇadovanou funkc ˇnost . HW implementace poskytne vys ˇs ˇı ´ vy ´konnost nez ˇ SW implementace na obecne ´m CPU (napr ˇ. na signa ´love ´m procesoru pobe ˇz ˇı ´ algoritmus rychleji) - nevy ´hoda - HW r ˇes ˇenı ´ nenı ´ flexibilnı ´ * alokace ´ uloh na fyzicke ´ jednotky (poc ˇı ´tac ˇe nebo procesory) - vyz ˇaduje-li ´ uloha ve ˇts ˇı ´ vy ´kon, poskytneme jı ´ vı ´ce CPU - urc ˇite ´ ´ ulohy vyz ˇadujı ´ konkre ´tnı ´ fyzicke ´ umı ´ste ˇnı ´, napr ˇ. kaz ˇdy ´ bankomat ma ´ vlastnı ´ SW, aby mohl (omezene ˇ) pracovat, i kdyz ˇ je sı ´t’ nefunkc ˇnı ´ - podsyste ´my, ktere ´ nejvı ´ce komunikujı ´, by me ˇly by ´t pr ˇir ˇazeny stejne ´ jednotce * po urc ˇenı ´ druhu a relativnı ´ho poc ˇtu fyzicky ´ch jednotek urc ˇujeme propojenı ´ mezi jednotkami - vybereme topologii (propojenı ´ mohou odpovı ´dat asociacı ´m v objektove ´m modelu, pr ˇı ´padne ˇ (pro strukturovane ´ metody na ´vrhu) toku dat v DFD) - urc ˇı ´me obecne ´ poz ˇadavky na mechanismy a komunikac ˇnı ´ protokoly (napr ˇı ´klad pru ˚ chodnost nebo spolehlivost)
Datova ´ ´ uloz ˇis ˇte ˇ ............... * internı ´ a externı ´ ´ uloz ˇis ˇte ˇ dat majı ´ dobr ˇe definovane ´ rozhranı ´, proto mohou slouz ˇit jako c ˇista ´ hranice odde ˇlujı ´cı ´ podsyste ´my - napr ˇı ´klad ´ uc ˇetnı ´ syste ´m mu ˚z ˇe pouz ˇı ´vat relac ˇnı ´ databa ´zi pro komunikaci mezi podsyste ´my - nebo aplikace pro zpracova ´nı ´ obrazu mu ˚z ˇe pouz ˇı ´vat soubor - matici pixelu ˚ * soubory - jsou levne ´, jednoduche ´ a permanentnı ´, ale majı ´ nı ´zkou ´ uroven ˇ abstrakce, tj. v aplikaci je nutny ´ dals ˇı ´ ko ´d pro pra ´ci s nimi - soubory jsou vhodne ´ pro data, ktera ´ jsou objemna ´, ale za ´roven ˇ obtı ´z ˇne ˇ strukturovatelna ´ v termı ´nech DB syste ´mu ˚ - take ´ pro data, ktera ´ majı ´ malou informac ˇnı ´ hustotu, nebo data, ktera ´ jsou uchova ´va ´na kra ´tkou dobu * databa ´ze - silne ˇjs ˇı ´ prostr ˇedek - spolec ˇne ´ rozhranı ´ pro mnoz ˇinu aplikacı ´ pomocı ´ standardnı ´ho pr ˇı ´stupove ´ho jazyka (SQL) - vy ´hodne ´ pro data, ke ktery ´m bude pr ˇistupovat vı ´ce uz ˇivatelu ˚, pr ˇı ´padne ˇ vı ´ce programu ˚, a pro data, ktera ´ mohou by ´t efektivne ˇ spravova ´na pr ˇı ´kazy DB jazyka
67
Za´klady softwarove´ho inzˇeny´rstvı´
68
- poskytujı ´ dals ˇı ´ vlastnosti jako podporu transakcı ´, zotavenı ´ po hava ´rii apod. - nevy ´hody: . vys ˇs ˇı ´ rez ˇie . nedostatec ˇna ´ podpora pro sloz ˇite ˇjs ˇı ´ datove ´ struktury (relac ˇnı ´ databa ´ze pr ˇedpokla ´dajı ´ velke ´ mnoz ˇstvı ´ dat s relativne ˇ jednoduchou strukturou) . c ˇasto nenı ´ moz ˇna ´ c ˇista ´ integrace s programovacı ´m jazykem (SQL je neprocedura ´lnı ´, zatı ´mco aplikaci vytva ´r ˇı ´me v procedura ´lnı ´m nebo OO jazyce)
Vy ´be ˇr mechanismu r ˇı ´zenı ´ ....................... * tr ˇi zpu ˚soby r ˇı ´zenı ´ v souvislosti s externı ´mi uda ´lostmi, a to sekvenc ˇnı ´ syste ´m r ˇı ´zeny ´ procedura ´lne ˇ, sekvenc ˇnı ´ syste ´m r ˇı ´zeny ´ uda ´lostmi, paralelnı ´ syste ´m - dopln ˇuje struktura ´lnı ´ modely architektury * syste ´my r ˇı ´zene ´ procedura ´lne ˇ - be ˇh je r ˇı ´zen programovy ´m ko ´dem - procedura z ˇa ´da ´ o vstup napr ˇ. z kla ´vesnice a pozastavı ´ se (blokuje se) - po pr ˇı ´chodu be ˇh pokrac ˇuje v procedur ˇe, ktera ´ o vstup z ˇa ´dala - napr ˇı ´klad te ´me ˇr ˇ vs ˇechny znakove ˇ orientovane ´ aplikace v MS DOSu a v Linuxu - vy ´hoda - jednoducha ´ implementace - nevy ´hoda - obtı ´z ˇne ´ zpracova ´nı ´ asynchronnı ´ch uda ´lostı ´ (program musı ´ poz ˇa ´dat o vstup)
Main Sub 1
Sub 2
Sub 3
* syste ´my r ˇı ´zene ´ uda ´lostmi - be ˇh syste ´mu r ˇı ´dı ´ dispec ˇer poskytovany ´ podsyste ´mem, programovacı ´m jazykem nebo OS - s jednotlivy ´mi uda ´lostmi jsou sva ´za ´ny procedury aplikace - syste ´m ne ˇkdy poskytuje frontu uda ´lostı ´, nove ˇ pr ˇı ´chozı ´ uda ´losti se r ˇadı ´ do fronty, ze ktere ´ dispec ˇer vybere na ´sledujı ´cı ´ uda ´lost a zavola ´ odpovı ´dajı ´cı ´ proceduru (”callback”) - procedura po skonc ˇenı ´ obsluhy uda ´losti vracı ´ r ˇı ´zenı ´ dispec ˇeru - ve skutec ˇnosti simuluje spolupracujı ´cı ´ vla ´kna uvnitr ˇ ´ ulohy, ale na rozdı ´l od skutec ˇne ´ho paralelismu dlouho trvajı ´cı ´ procedura zablokuje celou aplikaci - napr ˇı ´klad te ´me ˇr ˇ vs ˇechny GUI (MS Windows, X Window), simulace apod. - jednoducha ´ obsluha novy ´ch typu ˚ uda ´lostı ´ - obtı ´z ˇe implementace - procedury se vracejı ´, proto nemu ˚z ˇeme stav syste ´mu uchova ´vat v loka ´lnı ´ch prome ˇnny ´ch (musı ´me pouz ˇı ´t globa ´lnı ´ prome ˇnne ´) * paralelnı ´ syste ´my - r ˇı ´zenı ´ ne ˇkolik neza ´visle be ˇz ˇı ´cı ´ch objektu ˚ - uda ´losti pr ˇicha ´zejı ´ objektu ˚ m jako zpra ´vy - objekt mu ˚z ˇe c ˇekat na vstup, zatı ´mco ostatnı ´ pokrac ˇujı ´ v c ˇinnosti Pr ˇı ´klad architektury (tr ˇı ´vrstva ´ architektura) Mnoho souc ˇasny ´ch aplikacı ´ je strukturova ´no tak, aby od sebe byly odde ˇleny databa ´ze, vlastnı ´ aplikace a uz ˇivatelske ´ rozhranı ´:
uživatelské rozhraní
[]
aplikační logika
databáze
zswi/p6ooa.d
zswi/p7ood.d
3. ledna 2005
69
V praxi je du ˚lez ˇite ´, aby pro kaz ˇdy ´ projekt existovala osoba, ktera ´ je zodpove ˇdna ´ za architekturu syste ´mu (s ˇe ´f-architekt). Ve ˇts ˇinou to by ´va ´ vedoucı ´ ty ´mu.
❉
Za´klady softwarove´ho inzˇeny´rstvı´
70 KIV/ZSWI 2004/2005 Pr ˇedna ´s ˇka 7
V klasicke ´m z ˇivotnı ´m cyklu vy ´voje SW pod pojem ”na ´vrh” spadajı ´ dve ˇ aktivity, ktere ´ jsou umı ´ste ˇny mezi analy ´zou poz ˇadavku ˚ a ko ´dova ´nı ´m programu: * na ´vrh architektury syste ´mu - rozde ˇluje syste ´m do podsyste ´mu ˚ c ˇi komponent; o na ´vrhu architektury jsme mluvili na minule ´ pr ˇedna ´s ˇce * podrobny ´ na ´vrh syste ´mu - kaz ˇda ´ souc ˇa ´st syste ´mu je popsa ´na natolik podrobne ˇ, aby to postac ˇovalo pro ko ´dova ´nı ´ V dals ˇı ´m textu se budeme ve ˇnovat podrobne ´mu objektove ˇ orientovane ´mu na ´vrhu a jeho implementaci. Objektove ˇ orientovany ´ na ´vrh --------------------------Pr ˇehled: * vstupem jsou analyticke ´ tr ˇı ´dy pr ˇedstavujı ´cı ´ role, ktere ´ mohou by ´t pokryty jednou nebo vı ´ce tr ˇı ´dami na ´vrhu; analyticka ´ tr ˇı ´da se v na ´vrhu mu ˚z ˇe sta ´t jednou tr ˇı ´dou, c ˇa ´stı ´ tr ˇı ´dy, agregovanou tr ˇı ´dou, skupinou spr ˇı ´zne ˇny ´ch tr ˇı ´d, asociacı ´, naopak asociace tr ˇı ´dou apod. * vytvor ˇenı ´ na ´vrhovy ´ch tr ˇı ´d (design classes) * definice operacı ´ * definice asociacı ´, agregacı ´ a kompozic * pro analyticke ´ tr ˇı ´dy budeme vytva ´r ˇet jednu nebo vı ´ce na ´vrhovy ´ch tr ˇı ´d - na ´vrh hranic ˇnı ´ch tr ˇı ´d . pokud jsou k dispozici na ´stroje pro na ´vrh GUI, pak jedna hranic ˇnı ´ tr ˇı ´da bude odpovı ´dat jednomu oknu nebo formula ´r ˇi . jednu tr ˇı ´du pro kaz ˇde ´ API nebo protokol - entitnı ´ (datove ´) tr ˇı ´dy . jsou c ˇasto pasivnı ´ a perzistentnı ´, musı ´me pro ne ˇ vybrat zpu ˚sob implementace: v souboru, v relac ˇnı ´ databa ´zi (z perzistentnı ´ch tr ˇı ´d vytvor ˇı ´me tabulky atd.); nejsou-li tr ˇı ´dy perzistentnı ´, pak budou implementova ´ny v pame ˇti - r ˇı ´dı ´cı ´ tr ˇı ´dy . obsahujı ´ aplikac ˇnı ´ logiku * vypln ˇova ´nı ´ tr ˇı ´d 1: definice operacı ´ - standardnı ´ konstruktory se pr ˇedpokla ´dajı ´ => z na ´vrhu je vynecha ´va ´me - operace, ktere ´ c ˇtou a nastavujı ´ ver ˇejne ´ atributy, se (ve ˇts ˇinou) pr ˇedpokla ´dajı ´ - hleda ´me operace - prvnı ´m vodı ´tkem mu ˚z ˇe by ´t jiz ˇ vytvor ˇeny ´ seznam sloves - dals ˇı ´ zpu ˚sob - zı ´skat operace z popisu interakce objektu ˚ . nakreslı ´me diagramy spolupra ´ce nebo sekvenc ˇnı ´ diagramy (resp. upravı ´me diagramy zı ´skane ´ ve fa ´zi analy ´zy, doplnı ´me zası ´lane ´ zpra ´vy) . z nich zjistı ´me, jake ´ stimuly musı ´ by ´t objekt schopen pr ˇijmout, navrhneme odpovı ´dajı ´cı ´ operace - dals ˇı ´ moz ˇnosti, co mu ˚z ˇe by ´t operace: . inicializace nove ˇ vytvor ˇene ´ instance vc ˇetne ˇ propojenı ´ s asociovany ´mi objekty . pr ˇı ´padne ´ vytvor ˇenı ´ kopie instance (pokud je zapotr ˇebı ´) . pr ˇı ´padny ´ test na ekvivalenci instancı ´ (pokud je zapotr ˇebı ´) - operace popı ´s ˇeme: na ´zev, parametry, na ´vratova ´ hodnota, kra ´tky ´ popis, viditelnost - pokud je algoritmus sloz ˇity ´, popı ´s ˇeme metodu (= implementaci operace) nebo nakreslı ´me stavovy ´ diagram objektu nebo operace; napr ˇ. stavovy ´ diagram pro bankomat:
zswi/p7ood.d
zswi/p7ood.d
3. ledna 2005
71 [chybné PIN]
Uvítací obrazovka
vložení karty
do/ zobraz uvítání
Karta vložena
[čitelná karta]
do/ přečti kartu [nečitelná karta]
Zadání PIN
ověření PIN
do/ získej PIN
[PIN OK]
cancel
Nečitelná karta
Zrušení transakce
do/ zpráva o nečitelné kartš
do/ zpráva o zrušení transakce
cancel
Transakce
Vydání karty do/ vydej kartu
- za ´kladnı ´ krite ´rium: kaz ˇda ´ metoda by me ˇla de ˇlat jednu ve ˇc dobr ˇe * vypln ˇova ´nı ´ tr ˇı ´d 2: definice atributu ˚ - pr ˇi hleda ´nı ´ atributu ˚ mu ˚z ˇeme vycha ´zet z logicky ´ch atributu ˚ (produkt analy ´zy) popisujı ´cı ´ch, co je potr ˇebne ´ pro uchova ´nı ´ stavu objektu - dals ˇı ´ moz ˇnost - jake ´ atributy jsou tr ˇeba pro implementaci operacı ´ - atributy v na ´vrhu majı ´ by ´t ”jednoduche ´” (int, boolean, float, ...) nebo majı ´ mı ´t se ´mantiku hodnoty (tj. by ´t nezme ˇnitelne ´, napr ˇ. String) . jinak pouz ˇijeme asociaci - atributy popı ´s ˇeme: jme ´no, typ, poc ˇa ´tec ˇnı ´ hodnota, viditelnost . me ˇli bychom se snaz ˇit o skry ´va ´nı ´ informacı ´ - soukrome ´ atributy (viditelne ´ pouze pro potomky = protected ”#”) - ove ˇr ˇı ´me, z ˇe vs ˇechny atributy jsou potr ˇebne ´ - pokud zjistı ´me, z ˇe se atributy a operace de ˇlı ´ do dvou tr ˇı ´d, ktere ´ spolu pr ˇı ´lis ˇ nesouvisejı ´, pak se pravde ˇpodobne ˇ jedna ´ o dve ˇ ru ˚zne ´ tr ˇı ´dy - me ˇli bychom tr ˇı ´du rozde ˇlit * definice asociacı ´, agregacı ´ a kompozic - stejne ˇ jako v analy ´ze, ma ´me ale podrobne ˇjs ˇı ´ informace o chova ´nı ´ - navı ´c mu ˚z ˇeme pr ˇidat tzv. pru ˚chodnost (navigability) - od ktere ´ho ke ktere ´mu objektu budeme chtı ´t snadno pr ˇecha ´zet . oznac ˇuje se s ˇipkou v asociac ˇnı ´m vztahu
Polygon
1
Contains
3..*
Point
* pokud tr ˇı ´da obsahuje vı ´ce nez ˇ cca 10 atributu ˚ , 10 asociacı ´ nebo 20 operacı ´, pak asi nenı ´ dobr ˇe navrz ˇena ´ a potr ˇebuje rozde ˇlit * definice zobecne ˇnı ´ (hierarchie de ˇdic ˇnosti) - stejne ˇ jako v analy ´ze, tj. spolec ˇne ´ vlastnosti vyjmeme do nadtr ˇı ´d - pokud ma ´ ne ˇktera ´ tr ˇı ´da sjednocenı ´ atributu ˚ svy ´ch podtr ˇı ´d (mı ´sto pru ˚niku), zr ˇejme ˇ spolu podtr ˇı ´dy ve skutec ˇnosti nemajı ´ nic spolec ˇne ´ho - hierarchie by me ˇla by ´t vyva ´z ˇena ´, tj. neme ˇly by by ´t tr ˇı ´dy, pro ktere ´ je hierarchie neobvykle plocha ´ nebo naopak hluboka ´ * kontrola modelu - ove ˇr ˇit realizace pr ˇı ´padu ˚ pouz ˇitı ´, v na ´vrhu na ´m nesmı ´ chybe ˇt chova ´nı ´ potr ˇebne ´ pro ne ˇktery ´ pr ˇı ´pad pouz ˇitı ´ * volitelne ˇ vytva ´r ˇenı ´ balı ´c ˇku ˚ - bud’ pro leps ˇı ´ srozumitelnost (strukturova ´nı ´), nebo pro izolaci c ˇa ´stı ´, ktere ´ se budou c ˇaste ˇji me ˇnit (pr ˇı ´padne ˇ obojı ´) - do balı ´c ˇku vkla ´da ´me funkc ˇne ˇ pr ˇı ´buzne ´ tr ˇı ´dy; napr ˇ. pokud by zme ˇna chova ´nı ´ jedne ´ tr ˇ´ ıdy zpu ˚sobila zme ˇnu chova ´nı ´ druhe ´, jsou tr ˇı ´dy funkc ˇne ˇ pr ˇı ´buzne ´ - tr ˇı ´dy uvnitr ˇ balı ´c ˇku mohou by ´t ver ˇejne ´ (public) nebo soukrome ´ (private) . ver ˇejna ´ tr ˇı ´da mu ˚z ˇe mı ´t asociace s libovolnou jinou tr ˇı ´dou; ver ˇejne ´ tr ˇı ´dy tvor ˇı ´ rozhranı ´ balı ´c ˇku . soukroma ´ tr ˇı ´da mu ˚z ˇe by ´t asociova ´na pouze se tr ˇı ´dami uvnitr ˇ stejne ´ho balı ´c ˇku - pokud ma ´ tr ˇı ´da v jednom balı ´c ˇku asociaci se tr ˇı ´dou v jine ´m balı ´c ˇku, pak balı ´c ˇky na sobe ˇ navza ´jem za ´visejı ´ - modeluje se vztahem za ´vislosti (pr ˇerus ˇovana ´ s ˇipka)
Za´klady softwarove´ho inzˇeny´rstvı´
72
- v jednom diagramu mu ˚z ˇeme zakreslit i za ´vislosti mezi tr ˇı ´dami apod. Zpracování objednávek
Rozhraní systému objednávek
Registrace objednávek
Evidence zboží
Objednávka
Druh zboží
Registrace zboží
* tı ´m konc ˇı ´ na ´vrh a mu ˚z ˇeme pr ˇejı ´t k implementaci
Objektove ˇ orientovana ´ implementace ---------------------------------Pozna ´mka: Obra ´zky v te ´to c ˇa ´sti nejsou platne ´ UML, ale snaz ˇı ´ se naznac ˇit zpu ˚sob implementace na ´vrhu. Kostru implementace v objektove ˇ orientovane ´m programovacı ´m jazyce mu ˚z ˇeme snadno vytvor ˇit z diagramu tr ˇı ´d:
Class1 var1: type = value ... op1(param: type): type ... public class Class1 { // konstruktory public Class1() {}; public Class1(type param) { setVar1(param) }; // ver ˇejne ´ operace get a set, soukroma ´ prome ˇnna ´ private type var1 = value; public type getVar1() { return var1; } public void setVar1(type param) { var1 = param; } // operace pro kaz ˇdou metodu public type op1(type param) { ... } } * pr ˇevod asociacı ´ - asociace nejsou pr ˇı ´mo podporova ´ny OO programovacı ´mi jazyky - pokud je na ´sobnost 1 a pru ˚chodnost jen jednı ´m sme ˇrem (tj. jednı ´m sme ˇrem pr ˇı ´stup podstatne ˇ c ˇaste ˇji), implementujeme asociaci jako odkaz na objekt (referenci objektu, v ne ˇktery ´ch jazycı ´ch jako ukazatel na objekt)
Class1
1
1
Class2
- pokud je na ´sobnost 1 a pru ˚chodnost obe ˇma sme ˇry - implementujeme jako vza ´jemne ´ odkazy - pokud je na ´sobnost 1:M - mnoz ˇinu odkazu ˚ udrz ˇujeme napr ˇ. ve stromu apod.
Class1
Class2
Set
- pokud je k asociaci pr ˇida ´n nebo z nı ´ odebra ´n link, je tr ˇeba upravit oba odkazy - pokud jsou zme ˇny asociacı ´ c ˇaste ˇjs ˇı ´ nez ˇ vyhleda ´va ´nı ´, je vhodna ´ implementace pomocı ´ asociac ˇnı ´ho objektu (asociac ˇnı ´ho objekt implementuje napr ˇ. hashovanou tabulku, prvek tabulky obsahuje dvojici (ObjA, ObjB))
zswi/p7ood.d
zswi/p7ood.d
3. ledna 2005
person1
73
Works for
person2 person3
companyA
companyB
person4
- asociace M:N nemohou by ´t pr ˇir ˇazeny jako atribut ani jednomu konci, tj. pro ne ˇ musı ´me take ´ vytvor ˇit asociac ˇnı ´ tr ˇı ´du - terna ´rnı ´ a vys ˇs ˇı ´ asociace bud’ rozloz ˇı ´me na bina ´rnı ´ (pokud to jde), nebo ope ˇt vytvor ˇı ´me asociac ˇnı ´ tr ˇı ´du (N-a ´rnı ´ asociace nas ˇte ˇstı ´ nejsou v praxi c ˇaste ´) * pr ˇevod agrega ´tu ˚ a kompozic - agrega ´ty implementujeme stejne ˇ jako asociace, oznac ˇenı ´ v diagramu je pouze ”komenta ´r ˇ” ukazujı ´cı ´, z ˇe vztah je bliz ˇs ˇı ´ nez ˇ u ostatnı ´ch asociacı ´ - kompozice = existenc ˇnı ´ za ´vislost souc ˇa ´stı ´ . v destruktoru zrus ˇı ´me souc ˇa ´sti . pokud majı ´ souc ˇa ´sti stejnou dobu z ˇivota, vytvor ˇı ´me je v konstruktoru * de ˇdic ˇnost se na konstrukce OO programovacı ´ho jazyka mapuje pr ˇı ´moc ˇar ˇe, napr ˇı ´klad v jazyku Java: public class Podtr ˇı ´da extends Nadtr ˇı ´da { ... }
Implementace objektove ´ho na ´vrhu v neobjektove ´m jazyce ----------------------------------------------------Vy ´s ˇe uvedene ´ koncepce lze implementovat i v neobjektove ´m jazyce, jako je napr ˇ. C nebo Pascal - implementace ovs ˇem nebude tak pr ˇı ´moc ˇara ´. Nı ´z ˇe uvedeny ´m zpu ˚sobem byly implementova ´ny ne ˇktere ´ SW syste ´my pr ˇed pr ˇı ´chodem spolehlivy ´ch pr ˇekladac ˇ˚ u jazyka C++. Implementace probı ´ha ´ v na ´sledujı ´cı ´ch krocı ´ch: * pr ˇeklad tr ˇı ´d do datovy ´ch struktur * vytvor ˇenı ´ konstruktoru ˚ * implementace metod Pr ˇeklad tr ˇı ´d do datovy ´ch struktur ................................. * tr ˇı ´du obvykle implementujeme jako blok atributu ˚ - typ ”struct” v jazyku C, typ ”record” v Pascalu, napr ˇı ´klad: ˇa struct C ´ra { int x1, y1; int x2, y2; }; - prome ˇnna ´ reprezentujı ´cı ´ objekt musı ´ by ´t reprezentova ´na ukazatelem na za ´znam, aby odkaz bylo moz ˇne ´ pr ˇeda ´vat a sdı ´let, napr ˇ.: ˇa struct C ´ra *c ˇa ´ra; Vytvor ˇenı ´ konstruktoru ˚ ...................... * objekty mohou by ´t alokova ´ny staticky nebo dynamicky (na hromade ˇ) - staticky - pro globa ´lnı ´ objekty, pokud pr ˇedem vı ´me, jaky ´ poc ˇet objektu ˚ dane ´ho typu bude zapotr ˇebı ´ - dynamicky (pomocı ´ ”malloc()” v C nebo ”new” v Pascalu) - pokud uz ˇ nenı ´
Za´klady softwarove´ho inzˇeny´rstvı´
74
zapotr ˇebı ´, musı ´ by ´t explicitne ˇ dealokova ´n (”free()” v C, dispose v Pascalu) ˇa struct C ´ra *create_c ˇa ´ra(int x1, int y1, int x2, int y2) { ˇa struct C ´ra *c ˇa ´ra; ˇa ˇa c ˇa ´ra = (struct C ´ra*) malloc(sizeof(struct C ´ra)); c ˇa ´ra->x1 = x1; c ˇa ´ra->y1 = y1; c ˇa ´ra->x2 = x2; c ˇa ´ra->y2 = y2; return c ˇa ´ra; } Metody ...... * pro pojmenova ´nı ´ metod se obvykle pouz ˇı ´va ´ konvence, ktera ´ popisuje, ktere ´ tr ˇı ´de ˇ metoda patr ˇı ´ (jme ´no tr ˇı ´dy + dve ˇ podtrz ˇı ´tka + jme ´no metody) * kaz ˇde ´ metode ˇ je tr ˇeba pr ˇedat odkaz na objekt, nad ktery ´m je operace prova ´de ˇna (”self” nebo ”this” v OO jazycı ´ch); konvence je pr ˇeda ´vat ”self” jako prvnı ´ argument ˇa ˇa void C ´ra__posun(struct C ´ra *self, int posun_x, int posun_y) { self->x1 += posun_x; self->y1 += posun_y; self->x2 += posun_x; self->y2 += posun_y; } De ˇdic ˇnost ......... V neobjektove ´m jazyce je nejleps ˇı ´ se de ˇdic ˇnosti vyhnout, tj. pr ˇestrukturovat diagram tr ˇı ´d nebo jeho c ˇa ´sti tak, aby de ˇdic ˇnost nebyla zapotr ˇebı ´. Abychom se de ˇdic ˇnosti vyhnuli, mu ˚z ˇeme take ´ pouz ˇı ´t na ´sledujı ´cı ´ dve ˇ moz ˇnosti: 1. ”zde ˇde ˇnou” operaci implementujeme znovu jako samostatnou metodu - v tomto pr ˇı ´pade ˇ ovs ˇem docha ´zı ´ k duplikaci ko ´du 2. mı ´sto de ˇde ˇnı ´ z nadtr ˇı ´dy jsou ”de ˇde ˇne ´” atributy a operace implementova ´ny samostatny ´m objektem - podtr ˇı ´da bude obsahovat odkaz na tento novy ´ objekt a vs ˇechny ”de ˇde ˇne ´” operace deleguje tomuto nove ´mu objektu Pozna ´mka pro zajı ´mavost (implementace de ˇdic ˇnosti v neobjektove ´m jazyce) Pokud musı ´me implementovat de ˇdic ˇnost a potr ˇebujeme polymorfismus, pak se tr ˇı ´dy implementujı ´ pomocı ´ dvou za ´znamu ˚: * prvnı ´ za ´znam obsahuje atributy objektu (podobne ˇ jako ve vy ´s ˇe uvedene ´m pr ˇı ´kladu) - jako prvnı ´ poloz ˇku navı ´c obsahuje ukazatel na druhy ´ za ´znam, obsahujı ´cı ´ odkazy na metody tr ˇı ´dy (tento druhy ´ za ´znam je sdı ´len vs ˇemi instancemi tr ˇı ´dy) - poc ˇa ´tec ˇnı ´ poloz ˇky prvnı ´ho za ´znamu jsou v potomkovi stejne ´ho typu a ve stejne ´m por ˇadı ´ jako v nadtr ˇı ´de ˇ (to umoz ˇn ˇuje, aby nad nimi pracovaly i metody nadtr ˇı ´dy) struct Shape { /* abstraktnı ´ tr ˇı ´da Shape (c ˇesky ”tvar”) */ struct ShapeClass *class; /* odkazy na metody tr ˇı ´dy */ int x, y; /* umı ´ste ˇnı ´ tvaru */ }; struct Line { /* konkre ´tnı ´ tr ˇı ´da Line (c ˇesky ”c ˇa ´ra”) */ struct LineClass *class; /* odkaz na metody tr ˇı ´dy */ int x, y; /* opakuje atributy z abstraktnı ´ tr ˇı ´dy */
zswi/p7ood.d
zswi/p7ood.d
3. ledna 2005 int x2, y2;
/* nove ´ atributy */
}; * pro zjis ˇte ˇnı ´ skutec ˇny ´ch metod ma ´me druhou datovou strukturu, obsahujı ´cı ´ ukazatele na metody dane ´ tr ˇı ´dy: struct ShapeClass { void (*move)(int x, int y); void (*scale)(int newsize); };
/* pr ˇesun objektu */ /* zme ˇna velikosti objektu */
struct LineClass { void (*move)(int x, int y); /* pr ˇesun objektu */ void (*scale)(int newsize); /* zme ˇna velikosti objektu */ void (*setColor)(int color); /* nova ´ metoda - zme ˇna barvy objektu */ }; - vytvor ˇı ´me a inicializujeme prome ˇnnou, obsahujı ´cı ´ odkazy na metody: struct LineClass LineClass = { Shape__move, /* de ˇdı ´me po rodic ˇovi */ Line__scale, /* pr ˇekrytı ´ metody vlastnı ´ metodou */ Line__setColor /* nova ´ metoda */ }; - metodu bychom pak mohli vyvolat na ´sledovne ˇ: line->class->scale(5); /* vyvola ´nı ´ metody */ * konstruktor tr ˇı ´dy ”Line” by mohl vypadat takto: struct Line *create_line(int x1, int y1, int x2, int y2) { struct Line *line; line = malloc(sizeof(struct Line)); line->class = &LineClass; line->x = x1; line->y = y1; line->x2 = x2; line->y2 = y2; return line; } * pouz ˇitı ´: struct Line *line = create_line(1, 1, 2, 2); /* vyvola ´nı ´ konstruktoru */ []
Na ´vrhove ´ vzory -------------* ”vzory” (patterns) jsou r ˇes ˇenı ´ proble ´mu ˚ , ktere ´ se pr ˇi vytva ´r ˇenı ´ SW syste ´mu ˚ c ˇasto opakujı ´ * vzory existujı ´ na ru ˚ zny ´ch ´ urovnı ´ch: - na ´vrhove ´ vzory - dokumentujı ´ r ˇes ˇenı ´ proble ´mu ˚ na ´ urovni na ´vrhu - analyticke ´ vzory - dokumentujı ´ r ˇes ˇenı ´ dome ´novy ´ch proble ´mu ˚ (o nich zde nebudeme z c ˇasovy ´ch du ˚vodu ˚ mluvit) - architektonicke ´ vzory - r ˇes ˇenı ´ proble ´mu ˚ vysokou ´rovn ˇove ´ho na ´vrhu V na ´sledujı ´cı ´m textu uvedu ne ˇkolik c ˇasto pouz ˇı ´vany ´ch na ´vrhovy ´ch vzoru ˚. Termı ´n na ´vrhove ´ vzory (design patterns) byl zaveden stejnojmennou knihou, ktera ´ byla pr ˇeloz ˇena take ´ do c ˇes ˇtiny:
75
Za´klady softwarove´ho inzˇeny´rstvı´
76
zswi/p7ood.d
Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides: Design Patterns. Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995. (c ˇesky ´ pr ˇeklad: Na ´vrh programu ˚ pomocı ´ vzoru ˚. Grada 2003.) Co je na ´vrhovy ´ vzor ................... Jako pr ˇı ´klad pro ilustraci uvedu trojici tr ˇı ´d nazy ´vany ´ch Model/View/Controller (MVC) pro na ´vrh interaktivnı ´ch aplikacı ´. * mys ˇlenka pocha ´zı ´ z prostr ˇedı ´ jazyka Smalltalk (Goldbergova ´ a Robson 1983) * funkc ˇnost aplikace rozde ˇlı ´me na 3 typy objektu ˚, mezi objekty je vztah vydavatel-pr ˇedplatitel (publisher-subscriber) - ”model” je objekt aplikace, zapouzdr ˇuje data, ktera ´ majı ´ by ´t zobrazena - ”view” (c ˇesky ”na ´hled”) je prezentace modelu na obrazovce . ve chvı ´li, kdy dojde ke zme ˇne ˇ stavu modelu, ozna ´mı ´ to model vs ˇem ”view”, ktere ´ na ne ˇm za ´visejı ´; view zjistı ´ od modelu nove ´ hodnoty a zna ´zornı ´ je . zpu ˚sobu ˚ prezentace mu ˚z ˇe by ´t vı ´ce, je moz ˇne ´ ho zme ˇnit napr ˇ. na kola ´c ˇovy ´ graf nebo tabulku, aniz ˇ by to ovlivnilo model nebo controller - ”controller” definuje zpu ˚sob, jak uz ˇivatelske ´ rozhranı ´ reaguje na vstup . zpu ˚sob reakce na uz ˇivatelsky ´ vstup je moz ˇne ´ zme ˇnit, aniz ˇ by to ovlivnilo model nebo view; napr ˇı ´klad mı ´sto kla ´vesovy ´ch zkratek pouz ˇijeme vy ´be ˇr z menu View
Model a=30% b=40% c=50%
model queries and updates
model methods
model edits
view modification messages Controller
a
b
c
user inputs
* v tomto pr ˇı ´kladu je vide ˇt ne ˇkolik dals ˇı ´ch na ´vrhovy ´ch vzoru ˚: - na ´vrhovy ´ vzor vydavatel-pr ˇedplatitel (angl. publisher-subscriber nebo subject-observer) . vydavatel = instance, v nı ´z ˇ mu ˚z ˇe uda ´lost vzniknout . pr ˇedplatitel = instance, ktera ´ ma ´ za ´jem reagovat na urc ˇitou uda ´lost . pr ˇedplatitel si u vydavatele zaregistruje metodu, ktera ´ ma ´ by ´t v du ˚sledku uda ´losti vyvola ´na . pr ˇedplatitelu ˚ mu ˚z ˇe by ´t i vı ´ce . nastane-li uda ´lost, vydavatel vyvola ´ registrovane ´ metody pr ˇedplatitelu ˚ - vztah mezi ”view” a ”controller” je pr ˇı ´klad na ´vrhove ´ho vzoru ”stategie” atd.
Itera ´tor ........ * jeden z nejjednodus ˇs ˇı ´ch a nejc ˇaste ˇji pouz ˇı ´vany ´ch na ´vrhovy ´ch vzoru ˚ je itera ´tor * proble ´m: agregovany ´ objekt (jako je napr ˇ. seznam) by me ˇl umoz ˇn ˇovat procha ´zenı ´, aniz ˇ by k tomu uz ˇivatel musel zna ´t vnitr ˇnı ´ strukturu agrega ´tu (ktera ´ se mu ˚z ˇe zme ˇnit) - itera ´tor udrz ˇuje informaci o aktua ´lnı ´m objektu v agrega ´tu, umı ´ se posunout na na ´sledujı ´cı ´ prvek agrega ´tu a prvek poskytnout uz ˇivateli - modernı ´ OO programovacı ´ jazyky obsahujı ´ podporu itera ´toru ˚; napr ˇ. v jazyce Java se pouz ˇı ´va ´ rozhranı ´ Iterator: public interface Iterator { boolean hasNext(); // Vracı ´ ”true” pokud jsou dals ˇı ´ prvky. Object next(); // Vracı ´ dals ˇı ´ prvek agrega ´tu. }
zswi/p7ood.d
3. ledna 2005
77
- v Jave ˇ poskytujı ´ itera ´tor tr ˇı ´dy Set, List, Map, atd.; lze psa ´t napr ˇ. for (Iterator e = v.iterator(); e.hasNext();) { System.out.println(e.next()); } Na ´vs ˇte ˇvnı ´k .......... * pr ˇedstavme si program, ktery ´ vytva ´r ˇı ´ strukturu objektu ˚, nad ktery ´mi se prova ´de ˇjı ´ dals ˇı ´ operace - napr ˇı ´klad pr ˇekladac ˇ vytva ´r ˇı ´ syntakticky ´ strom odpovı ´dajı ´cı ´ zdrojove ´mu programu - nebo forma ´tovacı ´ program vytva ´r ˇı ´ strom objektu ˚ odpovı ´dajı ´cı ´ struktur ˇe vstupnı ´ho textu * nad strukturou objektu ˚ budeme chtı ´t prova ´de ˇt ru ˚zne ´ operace - napr ˇı ´klad pr ˇekladac ˇ - kontrola syntakticke ´ spra ´vnosti, optimalizace, generova ´nı ´ ko ´du, me ˇr ˇenı ´ vlastnostı ´ zdrojove ´ho textu apod.
Statement TypeCheck() EmitCode() PrettyPrint()
Block
For
Do
While
If
Expression
TypeCheck() EmitCode() PrettyPrint()
TypeCheck() EmitCode() PrettyPrint()
TypeCheck() EmitCode() PrettyPrint()
TypeCheck() EmitCode() PrettyPrint()
TypeCheck() EmitCode() PrettyPrint()
TypeCheck() EmitCode() PrettyPrint()
Unary
Binary
TypeCheck() EmitCode() PrettyPrint()
TypeCheck() EmitCode() PrettyPrint()
- pokud potr ˇebujeme nad objekty struktury prova ´de ˇt mnoho ru ˚zny ´ch operacı ´, bylo by leps ˇı ´, kdybychom nove ´ operace mohli pr ˇida ´vat samostatne ˇ a kdyby pu ˚vodnı ´ strom objektu ˚ byl neza ´visly ´ na operacı ´ch, ktere ´ nad nı ´m budou prova ´de ˇny (abychom pro kaz ˇdy ´ typ prvku nemuseli implementovat vs ˇechny operace - obtı ´z ˇne ˇjs ˇı ´ udrz ˇovatelnost) * ˇ res ˇenı ´ - pr ˇı ´buzne ´ operace kaz ˇde ´ tr ˇı ´dy zabalı ´me do samostatne ´ho objektu, nazy ´vane ´ho na ´vs ˇte ˇvnı ´k (visitor) - pr ˇi pru ˚chodu stromem objektu ˚ pr ˇeda ´va ´me na ´vs ˇte ˇvnı ´ka jednotlivy ´m prvku ˚m - navs ˇtı ´veny ´ prvek pos ˇle na ´vs ˇte ˇvnı ´kovi poz ˇadavek, v na ´zvu volane ´ metody je zako ´dova ´na tr ˇı ´da prvku, prvek pr ˇeda ´ sa ´m sebe jako argument - napr ˇı ´klad TypeCheckVisitor bude pr ˇi procha ´zenı ´ stromu objektu ˚ volat jejich metody Accept() . metoda Accept() vyvola ´ odpovı ´dajı ´cı ´ metodu na ´vs ˇte ˇvnı ´ka, napr ˇ. objekt tr ˇı ´dy If vyvola ´ VisitIf, objekt tr ˇı ´dy While vyvola ´ VisitWhile apod. . na ´vs ˇte ˇvnı ´k mu ˚z ˇe pr ˇi pru ˚ chodu strukturou akumulovat stav, c ˇı ´mz ˇ eliminujeme potr ˇebu globa ´lnı ´ch prome ˇnny ´ch
StatementVisitor TypeCheckVisitor VisitIf(If) VisitDo(Do) VisitWhile(While)
...
VisitIf(If) VisitDo(Do) VisitWhile(While) ...
CodeEmitVisitor VisitIf(If) VisitDo(Do) VisitWhile(While)
...
- jiny ´mi slovy - definujete dve ˇ hierarchie tr ˇı ´d, jednu pro objekty, nad ktery ´mi se prova ´de ˇjı ´ operace (If, While...) a jednu pro na ´vs ˇte ˇvnı ´ky, kter ˇı ´ prova ´de ˇjı ´ operace nad objekty (TypeCheckVisitor, CodeEmitVisitor,
Za´klady softwarove´ho inzˇeny´rstvı´
78
zswi/p8dfd.d
PrettyPrintVisitor...) - krome ˇ na ´vs ˇte ˇvnı ´ka a struktury objektu ˚ hraje v syste ´mu c ˇasto roli jes ˇte ˇ klient, ktery ´ napr ˇ. vyvola ´ vytvor ˇenı ´ hierarchie objektu ˚ a z ˇa ´da ´ zpracova ´nı ´ te ´to hierarchie
Client ObjectStructure
Visitor
Jedina ´c ˇek (singleton) ..................... * v ne ˇktery ´ch pr ˇı ´padech potr ˇebujeme tr ˇı ´du, ktera ´ bude mı ´t jedinou instanci - napr ˇ. pokud cely ´ syste ´m sdı ´lı ´ jednoho spra ´vce oken, jednu tiskovou frontu - tr ˇı ´da mu ˚z ˇe zajistit, z ˇe bude vytvor ˇena jejı ´ jedina ´ instance, na ´sledujı ´cı ´m zpu ˚ sobem: . skryjeme konstruktor tr ˇı ´dy (bude protected) . pro vytvor ˇenı ´ instance poskytneme operaci tr ˇı ´dy . pokud instance existuje, vra ´tı ´ ji; pokud neexistuje, vytvor ˇı ´ a vra ´tı ´ ji public class Singleton { protected static Singleton instance = null; private Singleton() {} public static Singleton instance() { if (instance == null) instance = new Singleton(); return instance; } } * klienti si vytvor ˇı ´ instanci pomocı ´ Singleton.instance() * pozor, jedina ´c ˇek de facto zava ´dı ´ globa ´lnı ´ prome ˇnne ´ (i kdyz ˇ s moz ˇnostı ´ vytva ´r ˇet potomky apod.), proto by jeho pouz ˇitı ´ me ˇlo by ´t uva ´z ˇene ´ Vy ´s ˇe uvedena ´ kniha (Design patterns) uva ´dı ´ katalog 23 za ´kladnı ´ch na ´vrhovy ´ch vzoru ˚, se ktery ´mi se mu ˚z ˇete c ˇasto setkat, proto jı ´ doporuc ˇuji k prostudova ´nı ´.
❉
zswi/p8dfd.d
3. ledna 2005
KIV/ZSWI 2004/2005 Pr ˇedna ´s ˇka 8 Strukturovana ´ analy ´za a na ´vrh syste ´mu ===================================== * strukturovane ´ metodiky pro analy ´zu a na ´vrh syste ´mu historicky pr ˇedcha ´zely objektovy ´m metodika ´m - objektove ˇ-orientovany ´ vy ´voj - data a nad nimi pracujı ´cı ´ funkce cha ´peme jako objekty - strukturovane ´ - na funkce a na data se zame ˇr ˇujı ´ vı ´ceme ´ne ˇ odde ˇlene ˇ . odpovı ´da ´ strukturovane ´mu programova ´nı ´ . funkce jsou aktivnı ´ a majı ´ chova ´nı ´ . data jsou pasivnı ´, ovlivne ˇna funkcemi . fce syste ´mu postupne ˇ rozde ˇlujeme shora dolu ˚ na c ˇa ´sti, nejc ˇaste ˇji pomocı ´ diagramu ˚ datovy ´ch toku ˚ (data-flow diagrams) * dnes se vs ˇeobecne ˇ da ´va ´ pr ˇednost OO metodika ´m, ale strukturovane ´ metodiky mohou sta ´le jes ˇte ˇ poslouz ˇit v na ´sledujı ´cı ´ch pr ˇı ´padech: - male ´ programy (ne ˇkolik set r ˇa ´dek ko ´du): pr ˇı ´lis ˇ jednoduche ´, aby se vyplatilo vytva ´r ˇet tr ˇı ´dy - programy s kra ´tkou dobou z ˇivota, napr ˇ. prototypy, ktere ´ budou zahozeny (pokud cı ´lem nenı ´ zı ´skat pr ˇedstavu o vytva ´r ˇeny ´ch tr ˇı ´da ´ch): ope ˇt se nemusı ´ vypla ´cet vytva ´r ˇet tr ˇı ´dy - pokud se pravde ˇpodobne ˇ bude me ˇnit funkc ˇnost, ale ne data: v OO pr ˇı ´stupu by funkc ˇnost byla rozprostr ˇena mezi vı ´ce objektu ˚, proto mu ˚z ˇe by ´t vy ´hodne ˇjs ˇı ´ strukturovany ´ pr ˇı ´stup (pokud se naopak budou me ˇnit data, je OO pr ˇı ´stup vy ´hodne ˇjs ˇı ´, protoz ˇe zme ˇny jsou zapouzdr ˇeny do jednotlivy ´ch objektu ˚) * vy ´hoda strukturovany ´ch metodik - metodiky mohou by ´t jednodus ˇs ˇı ´, vytva ´r ˇene ´ modely mohou by ´t srozumitelne ´ za ´kaznı ´kovi => za ´kaznı ´k se sna ´ze ´ uc ˇastnı ´ strukturovane ´ analy ´zy - na ´vrh syste ´mu mu ˚z ˇe by ´t i rychlejs ˇı ´ (nevytva ´r ˇı ´me pr ˇı ´davnou strukturu tr ˇı ´d) * nevy ´hody strukturovany ´ch metodik - jsou povaz ˇova ´ny za nemodernı ´ - vy ´sledny ´ syste ´m se ve ˇts ˇinou hu ˚r ˇe udrz ˇuje * podobne ˇ jako u objektove ´ analy ´zy a na ´vrhu se vytva ´r ˇejı ´ modely = abstrakce klı ´c ˇovy ´ch vlastnostı ´ studovane ´ho syste ´mu - model slouz ˇı ´ jako vstup do dals ˇı ´ch fa ´zı ´ SW procesu: . model kontextu syste ´mu - urc ˇuje hranice vytva ´r ˇene ´ho syste ´mu . modely strukturovane ´ analy ´zy: diagramy datovy ´ch toku ˚, datovy ´ slovnı ´k, ERA diagramy, specifikace c ˇinnostı ´ procesu ˚ . modely strukturovane ´ho na ´vrhu: strukturogramy (structure charts) - na jejich za ´klade ˇ mu ˚z ˇeme zaha ´jit ko ´dova ´nı ´ - vytva ´r ˇenı ´ modelu mu ˚z ˇe mı ´t podporu CASE na ´stroju ˚ (editor modelu ˚, c ˇa ´stec ˇna ´ kontrola modelu, automaticka ´ tvorba dokumentace) Pozna ´mka pro zajı ´mavost (CASE na ´stroje podporujı ´cı ´ strukturovane ´ metodiky) Srovna ´nı ´ ne ˇktery ´ch CASE na ´stroju ˚ podporujı ´cı ´ch strukturovane ´ metodiky mu ˚z ˇete najı ´t napr ˇ. v c ˇla ´nku V. ˇ Repy: Programova ´nı ´ ve velke ´m, Softwarove ´ noviny 5/2003. [] Model kontextu syste ´mu ---------------------* jiz ˇ ´ uplne ˇ na zac ˇa ´tku zı ´ska ´va ´nı ´ poz ˇadavku ˚ je tr ˇeba urc ˇit hranice syste ´mu, tj. co bude tvor ˇit syste ´m a co bude okolı ´ syste ´mu * v ne ˇktery ´ch pr ˇı ´padech nemusı ´ by ´t ´ uplne ˇ zr ˇejme ´: napr ˇ. evidence pr ˇı ´jmu dr ˇeva v papı ´rne ˇ = va ´ha, termina ´ly pro vstup informacı ´ o objemu a kvalite ˇ dr ˇeva, databa ´ze... * zvolenou hranici c ˇasto urc ˇujı ´ netechnicke ´ faktory, napr ˇ. jı ´ urc ˇı ´me tak, abychom me ˇli co nejvı ´ce ve ˇcı ´ pod kontrolou * po definici hranic urc ˇı ´me kontext a za ´vislosti syste ´mu na okolı ´ * obvykle zna ´zorn ˇujeme nakreslenı ´m jednoduche ´ho diagramu kontextu (context
79
Za´klady softwarove´ho inzˇeny´rstvı´
80
diagram) - hranice vytva ´r ˇene ´ho syste ´mu je zna ´zorne ˇna kolec ˇkem s vepsany ´m na ´zvem syste ´mu - lide ´, organizace nebo jine ´ syste ´my, se ktery ´mi na ´s ˇ syste ´m komunikuje, se zna ´zorn ˇujı ´ pojmenovany ´m obde ´lnı ´kem; ve strukturovane ´ analy ´ze se nazy ´vajı ´ termina ´tory (majı ´ stejny ´ vy ´znam jako akte ´r ˇi v OO analy ´ze) - vstupujı ´cı ´ a vystupujı ´cı ´ data jsou zna ´zorne ˇna s ˇipkami mezi syste ´mem a termina ´torem - napr ˇı ´klad model kontextu syste ´mu pro bankomat:
účetní systém pobočky
záznam o přístupu
číslo účtu, transakce zůstatek
bankomat
kód ba
databáze použití (log)
nky, čís
PIN, požadovaná operace, částka
peníze, stvrzenka, zprávy
lo karty
kreditní karta
klient
Diagramy datovy ´ch toku ˚ ---------------------* angl. data-flow diagram, DFD, ale ne ˇkdy take ´ data-flow graph, work flow diagram, function model, bubble chart, process model... * souc ˇa ´stı ´ ru ˚zny ´ch strukturovany ´ch metod cca 1955-1990 (ale i ne ˇktery ´ch OO metodik, napr ˇ. OMT), v literatur ˇe uz ˇı ´va ´ny ru ˚ zne ´ notace * DFD jsou jednoduche ´ a intuitivnı ´ (je moz ˇne ´ je vysve ˇtlit za ´kaznı ´kovi) * lze je pouz ˇı ´t pro modelova ´nı ´ toku dat SW syste ´mem, ale take ´ modelova ´nı ´ toku dat a fyzicky ´ch pr ˇedme ˇtu ˚ (materia ´lu) v organizaci * my budeme pr ˇedevs ˇı ´m modelovat tok dat SW syste ´mem * data jsou zpracova ´va ´na posloupnostı ´ kroku ˚ (kroky prova ´de ˇjı ´ lide ´, funkce programu) * za ´kladnı ´ notace pro DFD: - externı ´ entita neboli termina ´tor . producent nebo konzument dat (zac ˇı ´na ´ nebo konc ˇı ´ v ne ˇm tok dat) . je mimo hranice modelovane ´ho syste ´mu . mu ˚z ˇe by ´t osoba, jiny ´ syste ´m, hardware apod. . zna ´zorne ˇna obde ´lnı ´kem s na ´zvem uvnitr ˇ - proces . prova ´dı ´ transformaci dat . zna ´zorne ˇn kolec ˇkem (bublinou), je vhodne ´ bubliny c ˇı ´slovat a nutne ´ konkre ´tne ˇ pojmenovat - sloveso + podstatne ´ jme ´no (”ove ˇr ˇ telefonnı ´ c ˇı ´slo”) - tok dat . reprezentuje ”data v pohybu” . zna ´zorne ˇn s ˇipkou, s ˇipka ukazuje sme ˇr toku dat; datovy ´ prvek ma ´ by ´t pojmenova ´n - pame ˇt’ (datovy ´ sklad) . ´ uloz ˇis ˇte ˇ dat pro pouz ˇitı ´ jednı ´m nebo vı ´ce procesy, pracujı ´cı ´mi v ru ˚zny ´ch c ˇasovy ´ch obdobı ´ch . zna ´zorne ˇn dvojitou c ˇarou . pokud je vyjı ´ma ´na pouze jedna datova ´ poloz ˇka, nemusı ´me oznac ˇovat datovy ´ tok
Název externí entity a) externí entita
Jméno procesu b) proces
jméno datového prvku
Název úložiště dat
c) tok dat
d) úložiště dat
* DFD mu ˚z ˇe by ´t pouz ˇit pro reprezentaci syste ´mu libovolne ´ ´ urovne ˇ abstrakce - zac ˇı ´na ´me na DFD ´ urovne ˇ 0 = fundamenta ´lnı ´ model syste ´mu, je vlastne ˇ tote ´z ˇ co jiz ˇ popsany ´ model kontextu syste ´mu
zswi/p8dfd.d
zswi/p8dfd.d
3. ledna 2005
81
- cely ´ SW syste ´m je zakreslen jako jedna bublina, ma ´ jeden nebo vı ´ce vstupu ˚ a vy ´stupu ˚ - napr ˇı ´klad vizualizace snı ´mku ˚ z tomografu: . vstupem je mnoz ˇina 2D r ˇezu ˚ te ˇlem pacienta . vy ´stupem je 2D pohled na snı ´mek
Tomograph
CT scan
2D image
Visualisation
User
- syste ´m mu ˚z ˇeme rozde ˇlit do mens ˇı ´ch c ˇa ´stı ´ a zna ´zornit na ve ˇts ˇı ´ ´ urovni podrobnosti:
CT List of Tomograph scan Contour contours Detection
Contour Corresp.
Contours, corresp.
Triangle mesh
Contour Tiling
2D image Mesh Reduction
User
* vy ´hodna ´ vlastnost DFD - model mu ˚z ˇe by ´t postupne ˇ zjemn ˇova ´n - napr ˇ. fundamenta ´lnı ´ model syste ´mu ”Monitor kvality oleje” ma ´ vstup ”obra ´zek sejmuty ´ CCD kamerou mikroskopu”, vy ´stupem je rozhodnutı ´, zda je tr ˇeba olej vyme ˇnit:
L0 DFD:
CCD camera
raw image
Oil Quality OK/swap decision Monitoring
User
- zjemnı ´me model syste ´mu . najdeme kandida ´ty procesu ˚ , datovy ´ch toku ˚ a pame ˇtı ´ . vs ˇechny s ˇipky, bubliny a ´ uloz ˇis ˇte ˇ smysluplne ˇ pojmenujeme . musı ´ by ´t udrz ˇena ”kontinuita toku dat”, tj. pu ˚vodnı ´ vstupy a vy ´stupy musejı ´ zu ˚stat zachova ´ny . pokud je DFD nepr ˇehledny ´, pr ˇekreslı ´me ho - napr ˇ. vy ´s ˇe uvedeny ´ syste ´m rozde ˇlı ´me do c ˇtyr ˇ transformacı ´:
red plane L1 DFD:
CCD camera
raw image
input process green plane
process binarised image red plane detect OK/swap particles process green plane
binarised image
- v dals ˇı ´m kroku postupujeme ve zjemn ˇova ´nı ´ bublinu po bubline ˇ (tec ˇkova ´nı ´m jsem naznac ˇil obsah bublin z L1 DFD):
User
Za´klady softwarove´ho inzˇeny´rstvı´
82
threshold
Threshold Selection sample
Threshold
Noise image Filtering red plane
raw image
Input Process
Binarisation
binarised image
particle OK or swap edges Particle decision User Merge Detection
Threshold threshold Selection
CCD camera
Threshold
sample
green plane
Noise image Filtering
Binarisation
binarised image
- vytvor ˇene ´ DFD by neme ˇly by ´t pr ˇı ´lis ˇ velke ´ - me ˇly by se bez proble ´mu ˚ vejı ´t na papı ´r velikosti A4 Co zkontrolovat: * c ˇerne ´ dı ´ry - bubliny, ktere ´ majı ´ vstup, ale nemajı ´ vy ´stup * sponta ´nnı ´ genera ´tory - majı ´ vy ´stup, ale z ˇa ´dny ´ vstup; jediny ´ rozumny ´ pr ˇı ´pad tohoto typu je genera ´tor na ´hodny ´ch c ˇı ´sel * neoznac ˇene ´ procesy a datove ´ toky - c ˇasty ´m du ˚ vodem pro vy ´skyt je to, z ˇe analytik nenı ´ schopen najı ´t pro ne ˇ rozumny ´ na ´zev, napr ˇ. protoz ˇe sdruz ˇujı ´ nesouvisejı ´cı ´ procesy/toky dat (pak je r ˇes ˇenı ´m proces nebo datovy ´ tok rozde ˇlit) Pozna ´mka (rozs ˇı ´r ˇenı ´ DFD) Vy ´s ˇe uvedena ´ za ´kladnı ´ varianta DFD je vhodna ´ pro modelova ´nı ´ syste ´mu ˚, ktere ´ jsou r ˇı ´zeny datovy ´mi vstupy a kde se nezpracova ´vajı ´ te ´me ˇr ˇ z ˇa ´dne ´ vne ˇjs ˇı ´ uda ´losti. Zcela jinak je tomu v RT syste ´mech; pro takova ´ pouz ˇitı ´ byla navrz ˇena cela ´ r ˇada rozs ˇı ´r ˇenı ´ za ´kladnı ´ho DFD. Tok r ˇı ´zenı ´ se ve ˇts ˇinou zna ´zorn ˇuje pr ˇerus ˇovanou s ˇipkou a r ˇı ´dı ´cı ´ proces jako bublina zakreslena ´ pr ˇerus ˇovanou c ˇarou. Napr ˇı ´klad v na ´sledujı ´cı ´m DFD je r ˇı ´dı ´cı ´m procesem ”r ˇı ´zenı ´ vy ´tahu”: požadavky pasažér
požadavky na cílové stanice indikace cílových stanic
zapamatuj a zobraz požadavky
plánuj pohyb výtahu cílová stanice
stav výtahu snímač polohy dveří motor dveří výtahu
zavřené otevřít zavřít
plán cílových stanic
patro, stav dveří, pohyb řízení výtahu
přet patro
snímač přetížení
í
ížen
nahoru dolů stop
snímač patra motor výtahu
[] * v dals ˇı ´m kroku potr ˇebujeme - vytvor ˇit definici dat - specifikovat logiku procesu ˚ . na konec ˇne ´ ´ urovni zjemne ˇnı ´ dopln ˇujeme popis specifikacı ´ procesu bud’ v pr ˇirozene ´m jazyce, nebo v pseudoko ´du
zswi/p8dfd.d
zswi/p8dfd.d
3. ledna 2005
83
Datovy ´ slovnı ´k -------------* v DFD - s ˇipky reprezentujı ´ tok dat - pame ˇt’ je mnoz ˇina datovy ´ch poloz ˇek - je tr ˇeba mı ´t metodu reprezentace obsahu dat v datovy ´ch tocı ´ch a pame ˇtech - pro popis se pouz ˇı ´va ´ datovy ´ slovnı ´k = seznam datovy ´ch prvku ˚ s definicemi Du ˚ lez ˇitost popisu dat viz ”rozhovor s mart’anem” (Yourdon 1989): M: Co je to vlastne ˇ jme ´no? Z: To je, jak se navza ´jem nazy ´va ´me. M: (zmatene ˇ): Znamena ´ to, z ˇe se nazy ´va ´te jinak, kdyz ˇ jste s ˇt’astnı ´ nez ˇ kdyz ˇ ma ´te vztek? Z: (trochu pr ˇekvapene ˇ, z ˇe M je snad mimozems ˇt’an): Ne, jme ´no je por ˇa ´d stejne ´. M: (konec ˇne ˇ pochopil): Aha, rozumı ´m, u na ´s ma ´me to same ´. Moje jme ´no je 3.1415. Z: Ale to je pr ˇece c ˇı ´slo, ne jme ´no. atd.; v praxi c ˇasto za ´kaznı ´k povaz ˇuje analytika za mart’ana. Napr ˇ. pr ˇi urc ˇenı ´ ”co je to jme ´no” se mu ˚z ˇete setkat s proble ´my: * musı ´ mı ´t kaz ˇdy ´ kr ˇestnı ´ jme ´no a pr ˇı ´jmenı ´? Co je ”kr ˇestnı ´ jme ´no” a co je ”pr ˇı ´jmenı ´” napr ˇ. pro jme ´no ”Ing. Tran Quoc Trung”? * jake ´ znaky mohou by ´t souc ˇa ´stı ´ jme ´na? Co ”Kropa ´c ˇkova ´-Jouzova ´” nebo ”D’Arcy”? * jak budeme zacha ´zet s dodatky typu ”Jir ˇı ´ Stivı ´n III.”? * proto vytva ´r ˇı ´me forma ´lne ˇjs ˇı ´ definici datove ´ho slovnı ´ku * popisovana ´ data jednoducha ´ nebo sloz ˇena ´ - jednoducha ´ - zna ´me ´ typy dat, je tr ˇeba zadat obor hodnot, pr ˇı ´p. pouz ˇite ´ jednotky, pr ˇı ´p. pr ˇesnost - sloz ˇena ´ - popı ´s ˇeme odkazem na jednoduche ´ poloz ˇky Notace podle Yourdona (1989): * netermina ´lnı ´ symboly uva ´dı ´m maly ´mi pı ´smeny symbol = + () {}
vy ´znam pr ˇı ´klad vysve ˇtlenı ´ skla ´da ´ se z X = Y X se skla ´da ´ a Z = X + Y Z se skla ´da ´ mu ˚z ˇe by ´t vynecha ´no Z = X + (Y) Z se skla ´da ´ opakova ´nı ´ Z = { X } Z se skla ´da ´ - pokud je nutne ´ urc ˇit dolnı ´ resp. hornı ´ mez zapisuje se pr ˇed resp. za sloz ˇene ´ za ´vorky: Z = 1{X} Z se skla ´da ´ Z = {X}1 Z se skla ´da ´ Z = 1{X}10 Z se skla ´da ´ [] jedna z moz ˇnostı ´ Z = [ X | Y ] Z se skla ´da ´ ** komenta ´r ˇ *toto je komenta ´r ˇ* @ klı ´c ˇova ´ poloz ˇka @ c ˇa ´st sloz ˇene ´ho klı ´c ˇe
z Y z X a Y z X a pr ˇı ´padne ˇ Y z libovolne ´ho poc ˇtu X poc ˇtu opakova ´nı ´, z jednoho nebo vı ´ce X z 0 nebo jednoho X z 1 nebo 2 nebo ... 10 X bud’ z X nebo z Y
Jme ´no by mohlo by ´t definova ´no na ´sledovne ˇ: jme ´no = (tituly) + @<2>kr ˇestnı ´_jme ´no + (@<3>prostr ˇednı ´_jme ´no) + @<1>pr ˇı ´jmenı ´ + (ve ˇdecka ´_hodnost) tituly = {titul} titul = [ Pan | Panı ´ | Dr. | Ing. | RNDr. | MUDr. | JUDr. | Prof. | Doc. ] ve ˇdecka ´_hodnost = [ CSc. | DrSc. ] kr ˇestnı ´_jme ´no = platne ´_jme ´no prostr ˇednı ´_jme ´no = platne ´_jme ´no pr ˇı ´jmenı ´ = platne ´_jme ´no platne ´_jme ´no = velke ´_pı ´smeno + { pı ´smeno } pı ´smeno = [ velke ´_pı ´smeno | male ´_pı ´smeno ] velke ´_pı ´smeno = *velka ´ pı ´smena c ˇeske ´ abecedy* ´ | B | C | C ˇ | ... | Z | Z ˇ ] [ A | A male ´_pı ´smeno = *mala ´ pı ´smena c ˇeske ´ abecedy* [ a | a ´ | b | c | c ˇ | ... | z | z ˇ ]
Za´klady softwarove´ho inzˇeny´rstvı´
84 []
Vs ˇe, co se neda ´ popsat vy ´s ˇe uvedeny ´m zpu ˚sobem, uvedeme jako komenta ´r ˇ: - vy ´znam datove ´ho prvku v kontextu aplikace (pokud je stejny ´ jako na ´zev, pak se uva ´dı ´ pra ´zdny ´ komenta ´r ˇ ”**”) - z c ˇeho se prvek skla ´da ´, pokud je sloz ˇen ze smysluplny ´ch elementu ˚ - rozsah hodnot, pokud element nelze da ´le dekomponovat; pr ˇı ´padne ˇ pr ˇesnost jako poc ˇet vy ´znamny ´ch c ˇı ´slic za desetinnou c ˇa ´rkou Pr ˇı ´klady: vy ´s ˇka
= *vy ´s ˇka pacienta pr ˇi pr ˇijetı ´ do nemocnice* *jednotka: cm; rozsah: 10-250*
hmotnost = *hmotnost pacienta pr ˇi pr ˇijetı ´ do nemocnice* *jednotka: kg; rozsah: 1-200; pr ˇesnost: 0.1 kg* datum-narozenı ´ = ** *jednotka: poc ˇet dnı ´ od 1.1.1900; rozsah: 0-73000* [] * kaz ˇda ´ s ˇipka v DFD by me ˇla mı ´t popis v datove ´m slovnı ´ku * ve velky ´ch syste ´mech mu ˚z ˇe mı ´t datovy ´ slovnı ´k ne ˇkolik tisı ´c poloz ˇek * pro definici, kontrolu konzistence a ´ uplnosti je vhodne ´ pouz ˇı ´vat na ´stroje, jsou souc ˇa ´stı ´ DB syste ´mu ˚, notace se mu ˚z ˇe pone ˇkud lis ˇit * je velmi z ˇa ´doucı ´ udrz ˇet co nejmens ˇı ´ mı ´ru redundance kvu ˚li lokalizaci zme ˇn * pro pr ˇı ´padna ´ synonyma vz ˇdy pouze jednu definici za ´kaznı ´k = jme ´no + adresa + kategorie klient = za ´kaznı ´k *synonymum pro ”za ´kaznı ´k”* * kdybychom uvedli dve ˇ (stejne ´) definice, je nebezpec ˇı ´, z ˇe pr ˇi zme ˇne ˇ jednu z nich zapomeneme opravit * ne ˇkter ˇı ´ autor ˇi doporuc ˇujı ´ zvy ´raznit to, z ˇe se jedna ´ o synonymum uvedenı ´m hve ˇzdic ˇky ve vs ˇech vy ´skytech (napr ˇ. klient*), definici bychom zapsali takto: klient* = za ´kaznı ´k ERA diagramy -----------* v c ˇes ˇtine ˇ take ´ entitne ˇ-relac ˇnı ´ diagramy, E-R diagramy, v angl. nejc ˇaste ˇji entity-relationship diagrams (E-R diagrams, ERD) * popisujı ´ strukturu uchova ´vany ´ch dat na vysoke ´ ´ urovni abstrakce * za ´klady Chen 1976, pozde ˇji vy ´voj ru ˚zny ´mi sme ˇry - existuje mnoho notacı ´, zde uvedeme pouze za ´kladnı ´ notaci Pozna ´mka pro zajı ´mavost (ERA diagramy a diagram tr ˇı ´d v UML) Notace pro diagramy tr ˇı ´d v UML se historicky vyvinula z notace pro ERA diagramy, tj. podobnost mezi nimi nenı ´ na ´hodna ´. [] * pr ˇi vytva ´r ˇenı ´ syste ´mu si klademe ota ´zky: - ktere ´ ´ udaje musı ´me uchova ´vat v syste ´mu? - jaky ´ je vza ´jemny ´ vztah ´ udaju ˚? * zakreslujeme nejc ˇaste ˇji pomocı ´ ERA diagramu, napr ˇ.: - student volı ´ pr ˇedme ˇty, pr ˇedme ˇty uc ˇı ´ a cvic ˇı ´ uc ˇitele ´ - pr ˇehledne ˇ mu ˚z ˇeme nakreslit na ´sledovne ˇ:
zswi/p8dfd.d
zswi/p8dfd.d
3. ledna 2005
STUDENT
lectures
enrolls in
COURSE
85 TEACHER
leads labs
kde: * obde ´lnı ´kem zakreslujeme typy objektu ˚ (datove ´ entity) - pr ˇedstavuje mnoz ˇinu navza ´jem rozlis ˇitelny ´ch objektu ˚ rea ´lne ´ho sve ˇta * kosoc ˇtvercem zakreslujeme mnoz ˇinu vztahu ˚ (relace) - relace = mnoz ˇina vztahu ˚ , ktere ´ si syste ´m musı ´ zapamatovat (nelze je odvodit) - mezi dve ˇma entitami mu ˚z ˇe by ´t vı ´ce relacı ´
treats DOCTOR
PATIENT invoices
- relace charakterizova ´na aritou = poc ˇet objektu ˚ ´ uc ˇastnı ´cı ´ch se vztahu - nejc ˇaste ˇji se rozlis ˇuje 1:1, 1:N, M:N
CUSTOMER
1
N
purchases
ITEM
- nepovinny ´ (volitelny ´) vztah = nemusı ´ nastat
EMPLOYEE
1
is parent of
0, N
CHILD
- mu ˚z ˇeme popsat i rekurzivnı ´ vztah 1
MODULE
consists of
N
* atributy - popisujı ´ entity; entita popsa ´na pomocı ´ jednoho nebo vı ´ce atributu ˚ - atributy se ty ´kajı ´ vs ˇech instancı ´ entity - v ERA diagramu se ne ˇkdy zna ´zorn ˇujı ´ maly ´m pojmenovany ´m kolec ˇkem name
CUSTOMER
address customer-id
* ne ˇkdy mu ˚z ˇeme zjistit, z ˇe ru ˚ zne ´ entity jsou ve skutec ˇnosti pouze odlis ˇne ´ formy za ´kladnı ´ entity - napr ˇı ´klad vs ˇichni zame ˇstnanci majı ´ jme ´no, adresu, rodne ´ c ˇı ´slo - sta ´lı ´ zame ˇstnanci majı ´ navı ´c me ˇsı ´c ˇnı ´ plat a osobnı ´ ohodnocenı ´ - briga ´dnı ´ci majı ´ navı ´c hodinovou mzdu - jiny ´mi slovy nadtyp je popsa ´n atributy, ktere ´ se ty ´kajı ´ vs ˇech podtypu ˚ - analytik mu ˚z ˇe zna ´zornit pomocı ´ nepojmenovane ´ho kosoc ˇtverce s pr ˇes ˇkrtnutı ´m vztahu k nadtypu:
WORKER
EMPLOYEE
HOLIDAY WORKER
Za´klady softwarove´ho inzˇeny´rstvı´
86
* ne ˇkdy zjistı ´me, z ˇe potr ˇebujeme uchova ´vat take ´ informaci o relaci - pr ˇı ´klad: za ´kaznı ´k nakoupil zboz ˇı ´ . relace ”nakoupil” sdruz ˇuje za ´kaznı ´ka a jednu nebo vı ´ce poloz ˇek zboz ˇı ´ . pokud bychom chte ˇli uchovat informaci o datu na ´kupu, tato informace nepatr ˇı ´ ani k za ´kaznı ´kovi, ani ke zboz ˇı ´ . zavedeme ”nakoupil”, ma ´ fci typu objektu (tj. ma ´ atributy) a za ´roven ˇ vztahu (spojuje za ´kaznı ´ka s poloz ˇkami zboz ˇı ´) - nazy ´va ´ se asociativnı ´ indika ´tor typu objektu nebo pru ˚nikovy ´ typ - zna ´zorn ˇuje se na ´sledovne ˇ:
CUSTOMER
ITEM
PURCHASE
* ERA diagramy vstup pro na ´vrh databa ´ze, napr ˇ. ”pame ˇtı ´” v DFD * zde byly uvedeny pouze za ´klady notace, podrobne ˇjs ˇı ´ popis viz napr ˇ.: Jaroslav Pokorny ´: Konstrukce databa ´zovy ´ch syste ´mu ˚. ˇVUT 1999 Vydavatelstvı ´ C
Specifikace c ˇinnosti procesu ˚ ---------------------------* zjemn ˇova ´nı ´m DFD na ´m vznikl rozklad proble ´mu na elementa ´rnı ´ procesy komunikujı ´cı ´ pomocı ´ datovy ´ch toku ˚ * nynı ´ potr ˇebujeme specifikovat, co se de ˇje v elementa ´rnı ´m procesu * pro specifikace procesu ˚ se pouz ˇı ´vajı ´ na ´sledujı ´cı ´ na ´stroje: - pseudoko ´dy nebo jejich graficky ´ ekvivalent - rozhodovacı ´ tabulky - rozhodovacı ´ stromy - konec ˇny ´ automat (mu ˚z ˇeme pouz ˇı ´t konvenci stavove ´ho diagramu z UML) Pseudoko ´dy .......... * jako pr ˇı ´klad uvedu Yourdonovu ”strukturovanou anglic ˇtinu”, resp. ”strukturovanou angloc ˇes ˇtinu” * za ´kladnı ´ mys ˇlenka - omezeny ´ slovnı ´k be ˇz ˇne ´ho jazyka, pr ˇida ´me strukturu programovacı ´ho jazyka * slovnı ´k se skla ´da ´ z: - pr ˇı ´kazu ˚ - rozhodovacı ´ch konstrukcı ´ - opakovacı ´ch konstrukcı ´ * pr ˇı ´kazy: - vy ´raz, napr ˇ. X = Y*Z - sloveso, pojmy definovane ´ v datove ´m slovnı ´ku . pro jakoukoli specifikaci by me ˇlo postac ˇovat 40-50 sloves, napr ˇ. READ, WRITE, CREATE, APPEND, FIND, ... resp. c ˇeske ´ nac ˇti, vypis ˇ, vytvor ˇ, pr ˇidej atd. - vnor ˇenı ´ konstrukcı ´ nejc ˇaste ˇji vyja ´dr ˇeno odsazenı ´m, ne ˇkdy se mu ˚z ˇeme setkat take ´ s c ˇı ´slova ´nı ´m 1.1.1, 1.1.1.1... * rozhodovacı ´ konstrukce: IF podmı ´nka IF podmı ´nka DO CASE akce akce1 CASE podmı ´nka1 ENDIF ELSE akce1 akce2 ... ENDIF CASE podmı ´nka_n akce_n OTHERWISE akce ENDCASE
zswi/p8dfd.d
zswi/p8dfd.d
3. ledna 2005
* cykly: DO WHILE podmı ´nka akce ENDDO
REPEAT akce UNTIL podmı ´nka
Pr ˇı ´klad: ´c PROCES 1.2.3: U ˇtova ´nı ´ objedna ´vek. DO WHILE jsou objedna ´vky ke zpracova ´nı ´ READ objedna ´vka celkova ´-c ˇa ´stka = 0 DO WHILE jsou poloz ˇky v objedna ´vce celkova ´-c ˇa ´stka = celkova ´-c ˇa ´stka + cena-poloz ˇky ENDDO WRITE (do procesu 1.1.5) ID-za ´kaznı ´ka + celkova ´-c ˇa ´stka ENDDO
* definice procesu by neme ˇla pr ˇesa ´hnout jednu stra ´nku A4 (cca 70 r ˇa ´dek) - pokud se nevejde, me ˇla by se pouz ˇı ´t jina ´ formulace, resp. jednodus ˇs ˇı ´ algoritmus - pokud to nejde, moz ˇna ´ z ˇe proces nenı ´ elementa ´rnı ´
Nassi-Shneidermanovy diagramy ............................. * ne ˇkdy se pouz ˇı ´vajı ´ mı ´sto pseudoko ´du; uva ´dı ´m pro zajı ´mavost
statement 1 statement 2 sequence WHILE c statement 1 statement 2 ... while-do
T
condition
F
statement 1 statement 2 if-then-else statement 1 statement 2 ... UNTIL c repeat-until
CASE c case case case statement 1 statement 2 statement 3 FOR ... statement 1 statement 2 ... for-do
* pr ˇı ´klad Nassi-Shneidermanova diagramu procesu:
1.2.3 Customer Orders Items New Customer?
TRUE
FALSE
Create Account Query Customer For each Item in ORDER Item in Stock? TRUE
Ship Item
FALSE
Order Item
* po vysve ˇtlenı ´ jsou pro za ´kaznı ´ky c ˇasto srozumitelne ˇjs ˇı ´ nez ˇ pseudoko ´d (podle publikovany ´ch vy ´zkumu ˚ pro 75-80% lidı ´) * vyz ˇaduje nemale ´ mnoz ˇstvı ´ grafiky - vyplatı ´ se pouze, pokud ma ´me SW podporu pro jejich vytva ´r ˇenı ´ * neme ˇli bychom pr ˇekroc ˇit 3 ´ urovne ˇ vnor ˇenı ´, jinak je vhodna ´ spı ´s ˇe rozhodovacı ´ tabulka Vstupnı ´ a vy ´stupnı ´ podmı ´nky ........................... * v ne ˇktery ´ch pr ˇı ´padech se uda ´va ´ pouze vstupnı ´ a k nı ´ odpovı ´dajı ´cı ´ vy ´stupnı ´
87
Za´klady softwarove´ho inzˇeny´rstvı´
88
zswi/p8dfd.d
podmı ´nka: ´c PROCES 1.2.3: U ˇtova ´nı ´ objedna ´vek. Vstupnı ´ podmı ´nka: na vstupu (z procesu 1.1.4) se objevı ´ objedna ´vka Vy ´stupnı ´ podmı ´nka: na vy ´stup (do procesu 1.1.5) je zasla ´no ID-za ´kaznı ´ka + celkova ´-c ˇ´ astka Vstupnı ´ podmı ´nka: na vstupu (z procesu 1.1.4) je objedna ´vka, za ´kaznı ´k nenı ´ v databa ´zi Vy ´stupnı ´ podmı ´nka: je vygenerova ´na chybova ´ zpra ´va * be ˇh procesu je spous ˇte ˇn urc ˇeny ´m vstupem Rozhodovacı ´ tabulky a stromy ............................ * pouz ˇı ´vajı ´ se, pokud by byl pseudoko ´d vyjadr ˇujı ´cı ´ podmı ´nku sloz ˇity ´ * nejprve najdeme vs ˇechny relevantnı ´ vstupy, uc ˇı ´me poc ˇet moz ˇny ´ch kombinacı ´ * vytvor ˇı ´me tabulku - sloupce = pravidla: poc ˇet pravidel je da ´n poc ˇtem kombinacı ´ vstupu ˚ - r ˇa ´dky tabulky: nejprve vs ˇechny vstupy, pak vs ˇechny vy ´stupy
veˇk > 18 pohlavı´ = Zˇ hmotnost > 40 kg poda´vat le´k 1 poda´vat le´k 2
1 A A A A
2 N A A A
3 A N A
4 N N A
5 A A N
A
A
A
6 N A N A
7 A N N A A
8 N N N A
* hornı ´ polovina tabulky definuje podmı ´nky * ve spodnı ´ polovine ˇ je pro kaz ˇdy ´ sloupec (= podmı ´nku) uveden vy ´stup * pokud uz ˇivatel, se ktery ´m musı ´me konzultovat, odmı ´tne tabulku jako nesrozumitelnou, mu ˚z ˇeme pouz ˇı ´t rozhodovacı ´ strom:
věk > 18 pohlaví = Ž hmotnost > 40 kg pohlaví = M pohlaví = Ž hmotnost <= 40 kg pohlaví = M
věk <= 18 věk > 18
Lék1 Lék2 A A A
věk <= 18 věk > 18
A A
věk <= 18
A
věk > 18 věk <= 18
A
A
A
* vy ´hoda obou zpu ˚sobu ˚: - specifikacı ´ nenı ´ urc ˇen zpu ˚sob implementace - s uz ˇivatelem mu ˚z ˇeme probrat jedno pravidlo po druhe ´m - a hlavne ˇ ma ´me jasnou odpove ˇd’ pro vs ˇechny kombinace podmı ´nek Strukturovana ´ analy ´za --------------------V pr ˇedcha ´zejı ´cı ´m textu jsme popsali na ´stroje potr ˇebne ´ pro strukturovanou analy ´zu, ale zatı ´m jsme neuvedli, jak tyto na ´stroje pouz ˇı ´t. V dals ˇı ´m textu si proto uvedeme za ´klady dvou nejzna ´me ˇjs ˇı ´ch metodik, a to klasicke ´ DeMarcovy metodologie a Yourdonovy ”modernı ´ strukturovane ´ analy ´zy”. * vstupem strukturovane ´ analy ´zy (DeMarco) jsou uz ˇivatelske ´ poz ˇadavky,
zswi/p8dfd.d
-
3. ledna 2005 vy ´stupem je tzv. strukturovana ´ syste ´m je specifikova ´n pomocı ´ pr ˇı ´padne ´ jednodus ˇs ˇı ´ procesy v elementa ´rnı ´ procesy zapsa ´ny v v datove ´m slovnı ´ku popis dat
specifikace DFD, uvedeny podstatne ´ procesy, pame ˇti a ´ udaje DFD niz ˇˇ sı ´ ´ urovne ˇ pseudoko ´du, rozhodovacı ´ tabulkou nebo stromem
Ota ´zka: co ma ´ analytik vyrobit - model pu ˚ vodnı ´ho syste ´mu nebo nove ´ho? * pr ˇedpokla ´dejme: - existujı ´cı ´ syste ´m s ne zcela zr ˇetelnou strukturou plnı ´ urc ˇite ´ funkce - syste ´m z ne ˇjake ´ho du ˚vodu nahrazujeme novy ´m syste ´mem - jak najı ´t specifikaci nove ´ho syste ´mu? * klasicka ´ strukturovana ´ analy ´za pomocı ´ vytvor ˇenı ´ 4 modelu ˚ syste ´mu: 1. fyzicky ´ model sta ´vajı ´cı ´ho syste ´mu (jaky ´ syste ´m pouz ˇı ´va ´ za ´kaznı ´k?) - analytik zmapuje sta ´vajı ´cı ´ syste ´m, jeho fc ˇnı ´ strukturu a data - mu ˚z ˇe obsahovat zpracova ´vanı ´ a pr ˇesun fyzicky ´ch formula ´r ˇ˚ u apod. 2. logicky ´ model sta ´vajı ´cı ´ho syste ´mu (jaka ´ je jeho logicka ´ struktura?) - z fyzicke ´ho modelu vytvor ˇı ´me logicky ´ (cca 75% redukce) - zrus ˇı ´me vs ˇechny implementac ˇnı ´ detaily, co by syste ´m de ˇlal kdybychom me ˇli idea ´lnı ´ technologii (nekonec ˇne ´ pame ˇti, nekonec ˇnou rychlost atd.) - zı ´ska ´me logicke ´ procesy a podstatu transformace dat 3. logicky ´ model nove ´ho syste ´mu (co je tr ˇeba zme ˇnit?) - ve ˇts ˇina syste ´mu pravde ˇpodobne ˇ zu ˚stane stejna ´ + poz ˇadavky na nove ´ fce - po konzultaci s uz ˇivatelem promı ´tnuty zme ˇny do logicke ´ho modelu 4. fyzicky ´ model nove ´ho syste ´mu (jak to nejle ´pe implementovat?) - na ´vrh implementace. Proble ´my pr ˇi striktnı ´m dodrz ˇova ´nı ´ modelu: * pr ˇi vytva ´r ˇenı ´ fyzicke ´ho modelu vı ´ uz ˇivatel o syste ´mu vı ´c nez ˇ analytik; u uz ˇivatele tı ´m c ˇasto vznikne dojem, z ˇe analytik problematice nerozumı ´ a z ˇe se jı ´ teprve za jeho penı ´ze uc ˇı ´ * uz ˇivatel odmı ´ta ´ spolupra ´ci na vy ´voji nove ´ho logicke ´ho modelu; ma ´ pocit, z ˇe pokud analytik neumı ´ vytvor ˇit bez pomoci za ´kaznı ´ka fyzicky ´ model sta ´vajı ´cı ´ho syste ´mu, pak nemu ˚z ˇe ume ˇt ani dobr ˇe navrhnout novy ´ syste ´m * analytickou pra ´ci ne ˇkter ˇı ´ uz ˇivatele ´ povaz ˇujı ´ za oddech vy ´voja ´r ˇ˚ u pr ˇed ”skutec ˇnou pracı ´” (ko ´dova ´nı ´m), tvorba 4 modelu ˚ tuto dobu prodluz ˇuje, coz ˇ sniz ˇuje ochotu spolupracovat s analytikem (tj. 4 modely je proste ˇ moc) * zmı ´ne ˇne ´ proble ´my r ˇes ˇı ´ ”modernı ´ strukturovana ´ analy ´za” (Yourdon 1989)
Vyvaz ˇova ´nı ´ modelu ˚ ----------------Strukturovana ´ analy ´za: * model kontextu syste ´mu * diagramy datovy ´ch toku ˚ (DFD) * datovy ´ slovnı ´k * ERA diagramy * specifikace c ˇinnosti procesu ˚ - pseudoko ´dy - Nassi-Shneidermanovy diagramy - rozhodovacı ´ tabulky a stromy * kaz ˇdy ´ model se zaby ´va ´ ne ˇjaky ´m aspektem modelovane ´ho syste ´mu - DFD, specifikace procesu ˚ - funkce syste ´mu - datovy ´ slovnı ´k, ERA diagramy - data syste ´mu * ve velky ´ch syste ´mech by bylo snadne ´ vytvor ˇit ne ˇkolik nekonzistentnı ´ch pohledu ˚ na syste ´m - napr ˇ. v datove ´m slovnı ´ku mohou zu ˚stat poloz ˇky vznikle ´ v poc ˇa ´tec ˇnı ´ fa ´zi analy ´zy syste ´mu, ktere ´ se v DFD uz ˇ nevyskytujı ´ * proto je po dokonc ˇenı ´ modelu ˚ tr ˇeba prove ´st tzv. vyvaz ˇova ´nı ´ modelu ˚ * vyvaz ˇova ´nı ´ DFD a datove ´ho slovnı ´ku = zajistı ´me na ´sledujı ´cı ´: - kaz ˇdy ´ datovy ´ tok a kaz ˇda ´ pame ˇt’ musı ´ by ´t definova ´na v datove ´m slovnı ´ku - kaz ˇda ´ datova ´ poloz ˇka v datove ´m slovnı ´ku se musı ´ vyskytovat v DFD - mechanicka ´ pra ´ce => je vhodne ´ mı ´t podporu CASE na ´stroje * vyvaz ˇova ´nı ´ DFD a specifikace procesu ˚
89
90
Za´klady softwarove´ho inzˇeny´rstvı´ - kaz ˇda ´ bublina v DFD musı ´ by ´t sdruz ˇena bud’ s DFD niz ˇs ˇı ´ ´ urovne ˇ, nebo se specifikacı ´ procesu - kaz ˇda ´ specifikace procesu musı ´ mı ´t bublinu v DFD nejniz ˇs ˇı ´ ´ urovne ˇ - vstupy a vy ´stupy si musejı ´ vza ´jemne ˇ odpovı ´dat * vyvaz ˇova ´nı ´ specifikace procesu ˚ a datove ´ho slovnı ´ku - vs ˇechna data pouz ˇita ´ ve specifikaci procesu musejı ´ by ´t definova ´na bud’ loka ´lne ˇ, nebo v datove ´m slovnı ´ku - kaz ˇda ´ poloz ˇka v datove ´m slovnı ´ku musı ´ by ´t odkazova ´na ze specifikace procesu nebo z jine ´ poloz ˇky datove ´ho slovnı ´ku * vyvaz ˇova ´nı ´ ERA diagramu oproti DFD a specifikaci procesu - kaz ˇda ´ pame ˇt’ v DFD musı ´ odpovı ´dat entite ˇ, relaci nebo entite ˇ+relaci v ERA diagramu - poloz ˇky v datove ´m slovnı ´ku popisujı ´ jak toky v DFD tak entity v ERA modelu - procesy musejı ´ by ´t schopny: . vytva ´r ˇet a rus ˇit instance vs ˇech entit a relacı ´ v ERA diagramu . nastavovat hodnotu a pouz ˇı ´vat hodnotu instance.
❉
zswi/p9sad.d
zswi/p9sad.d
3. ledna 2005
91
KIV/ZSWI 2004/2005 Pr ˇedna ´s ˇka 9 Modernı ´ strukturovana ´ analy ´za ============================= * Yourdon 1989 * mı ´sto c ˇtyr ˇ modelu ˚ syste ´mu se zame ˇr ˇuje pr ˇı ´mo na nalezenı ´ esencia ´lnı ´ho modelu syste ´mu, tj. logicke ´ho modelu nove ´ho syste ´mu * v modernı ´ strukturovane ´ analy ´ze se postupuje v te ˇchto krocı ´ch: - vytvor ˇı ´me model prostr ˇedı ´ (definuje hranici mezi syste ´mem a zbytkem sve ˇta) . nejprve definujeme ´ uc ˇel syste ´mu (neme ˇl by by ´t dels ˇı ´ nez ˇ odstavec) . vytvor ˇı ´me model kontextu syste ´mu . vytvor ˇı ´me poc ˇa ´tec ˇnı ´ datovy ´ slovnı ´k definujı ´cı ´ data putujı ´cı ´ mezi syste ´mem a termina ´tory - vytvor ˇı ´me seznam uda ´lostı ´ - na za ´klade ˇ uda ´lostı ´ vytvor ˇı ´me pr ˇedbe ˇz ˇny ´ model chova ´nı ´ syste ´mu - model chova ´nı ´ syste ´mu pr ˇestrukturujeme do konec ˇne ´ho modelu chova ´nı ´ (= esencia ´lnı ´ model syste ´mu) - vytvor ˇı ´me uz ˇivatelsky ´ implementac ˇnı ´ model (dopln ˇuje esencia ´lnı ´ model o informace nutne ´ pro implementaci modelu) - konec analy ´zy, na ´sleduje na ´vrh architektury, podrobny ´ na ´vrh a ko ´dova ´nı ´
Vytvor ˇenı ´ seznamu uda ´lostı ´ .......................... * uda ´losti se klasifikujı ´ na: - uda ´lost datove ´ho toku (F) - uda ´lost ktera ´ se projevı ´ pr ˇı ´chodem dat; napr ˇ. uda ´lost ”pr ˇis ˇla objedna ´vka” - c ˇasova ´ uda ´lost (T) - napr ˇ. zpracova ´nı ´ transakcı ´ mezi bankovnı ´mi ´ uc ˇty nastane ve 3:00 - r ˇı ´dı ´cı ´ uda ´lost (C) - asynchronnı ´ uda ´lost napr ˇ. v RT syste ´mech * identifikace uda ´lostı ´: procha ´zı ´me kaz ˇdy ´ termina ´tor, pta ´me se jake ´ akce mu ˚z ˇe prova ´de ˇt nad syste ´mem (obvykle probı ´ra ´me spolec ˇne ˇ s uz ˇivateli, kter ˇı ´ hrajı ´ role termina ´toru ˚ - analogicky jako pr ˇi identifikaci pr ˇı ´padu ˚ pouz ˇitı ´ v OO analy ´ze) orders, cancelled orders EVENT LIST: 1. something happened (F) 2. ....
orders
CUSTOMERS invoice, shipping list
MANAGEMENT
Book Shop
books, invoices credit
PUBLISHERS ACCOUNTING
invoice sales reports
- me ´ne ˇ c ˇasta ´ alternativa: vycha ´zı ´me z ERA diagramu a hleda ´me uda ´losti ktere ´ zpu ˚ sobujı ´ vznik a za ´nik instancı ´ entit a relacı ´ * pro kaz ˇde ´ho kandida ´ta na uda ´lost se pta ´me, zda je skutec ˇne ˇ uda ´lostı ´, tj. zda v jejı ´m du ˚sledku syste ´m vyprodukuje vy ´stup nebo zme ˇnı ´ svu ˚j stav * pro kandida ´ta na uda ´lost se pta ´me, zda se vs ˇechny instance uda ´losti ty ´kajı ´ stejny ´ch dat (pokud ne, budou to nejspı ´s ˇ dve ˇ ru ˚ zne ´ uda ´losti; cı ´lem je rozlis ˇit mezi ru ˚zny ´mi uda ´lostmi, ktere ´ se na ´hodou de ˇjı ´ spolec ˇne ˇ nebo vypadajı ´ podobne ˇ) * pak se pro kaz ˇdou uda ´lost pta ´me ”musı ´ syste ´m ne ˇjak reagovat, pokud se uda ´lost neuda ´ podle oc ˇeka ´va ´nı ´?” (tj. modelujeme odpove ˇdi na chyby/poruchy termina ´toru ˚; napr ˇ. zboz ˇı ´ nepr ˇijde v oc ˇeka ´vane ´ dobe ˇ, co musı ´ syste ´m ude ˇlat?) Vytvor ˇenı ´ pr ˇedbe ˇz ˇne ´ho modelu chova ´nı ´ ....................................
* v klasicke ´ strukturovane ´ analy ´ze se vyuz ˇı ´va ´ postup shora dolu ˚, pak ale c ˇasto nasta ´va ´ tzv. proble ´m ”paraly ´zy analy ´zy”: pr ˇi definici velke ´ho syste ´mu
Za´klady softwarove´ho inzˇeny´rstvı´
92
zswi/p9sad.d
postra ´da ´me vodı ´tko, jak vytvor ˇit z kontextove ´ho diagramu DFD ´ urovne ˇ 1 * proto se v modernı ´ strukturovane ´ analy ´ze vyuz ˇı ´va ´ identifikace odpove ˇdı ´ na uda ´losti * postup pro vytva ´r ˇenı ´ pr ˇedbe ˇz ˇne ´ho modelu chova ´nı ´: - pro kaz ˇdou uda ´lost ze seznamu nakreslı ´me bublinu, oc ˇı ´slujeme jı ´ podle c ˇı ´sla uda ´losti - bublinu pojmenujeme podle odpove ˇdi, ktera ´ by me ˇla by ´t sdruz ˇena s uda ´lostı ´ (napr ˇ. odpove ˇd’ na ”za ´kaznı ´k zaplatil fakturu” je ”vloz ˇ platbu mezi pr ˇı ´jmy”) - pokud je na uda ´lost vı ´ce odpove ˇdı ´, pr ˇida ´me pro dals ˇı ´ neza ´vislou odpove ˇd’ dals ˇı ´ bublinu (neza ´visle ´ odpove ˇdi = mezi bublinami nenı ´ komunikace) - k bubline ˇ nakreslı ´me vstupy, vy ´stupy a potr ˇebne ´ pame ˇti - identicke ´ bubliny sdruz ˇı ´me do jedne ´ (identicke ´ bubliny majı ´ stejny ´ vstup, vy ´stup a proces; napr ˇ. ru ˚zne ´ typy objedna ´vek mohou mı ´t stejnou odpove ˇd’) - vy ´sledny ´ DFD zkontrolujeme oproti kontextove ´mu diagramu a seznamu uda ´lostı ´ * vy ´sledny ´ model by me ˇl - popisovat pouze logicke ´ procesy a podstatu transformace dat - zcela vynechat implementaci (nerozlis ˇuje ani, zda fci prova ´dı ´ c ˇlove ˇk nebo existujı ´cı ´ poc ˇı ´tac ˇovy ´ syste ´m) - proto vynecha ´me napr ˇ.: . procesy, jejichz ˇ ´ uc ˇelem je pr ˇenos dat z jedne ´ c ˇa ´sti syste ´mu do jine ´ . procesy pro verifikaci dat vznikly ´ch uvnitr ˇ syste ´mu . procesy pro fyzicky ´ vstup a fyzicky ´ vy ´stup (”vytiskni fakturu”) - je tr ˇeba rozlis ˇovat mezi zdrojem informace (”obchodnı ´ za ´stupce”) a mechanismem pro vstup/vy ´stup (”syste ´m pro zada ´va ´nı ´ objedna ´vek”); mechanismy vynecha ´me Dokonc ˇenı ´ modelu chova ´nı ´ ........................ * pr ˇedbe ˇz ˇny ´ DFD chova ´nı ´ syste ´mu bude zbytec ˇne ˇ komplikovany ´, zjednodus ˇı ´me ho * dokonc ˇı ´me specifikaci procesu ˚ * dokonc ˇı ´me datovy ´ slovnı ´k * zjednodus ˇenı ´ DFD chova ´nı ´ syste ´mu strukturova ´nı ´m - agregace = spr ˇı ´zne ˇne ´ procesy sdruz ˇı ´me do agrega ´tu ˚ (= seskupenı ´), ktere ´ budou tvor ˇit bubliny v DFD vys ˇs ˇı ´ ´ urovne ˇ - kaz ˇdy ´ agrega ´t by se me ˇl ty ´kat ´ uzce pr ˇ´ ıbuzny ´ch odpove ˇdı ´ na uda ´losti, tj. ve ˇts ˇinou procesu ˚ zpracova ´vajı ´cı ´ch pr ˇı ´buzna ´ data - sdruz ˇovat bychom me ˇli skupiny po cca 7+-2 procesech+pame ˇtech - pr ˇi tom ma ´me pr ˇı ´lez ˇitost ”schovat” pame ˇti, ktere ´ jine ´ procesy nepotr ˇebujı ´
* ne ˇkdy procesy naopak nejsou primitivnı ´ a vyz ˇadujı ´ dals ˇı ´ rozde ˇlenı ´ - napr ˇ. v na ´sledujı ´cı ´m pr ˇı ´kladu: bublinu jsme nedoka ´zali dobr ˇe pojmenovat, proto jı ´ rozde ˇlı ´me na primitivnı ´ procesy
x y
process x
y
process y
z
process z
p ?
z
x q r
X’
P’
Y’
Q’ combine
Z’
produce p
p
produce q
q
produce r
r
R’
zswi/p9sad.d
3. ledna 2005
* po dokonc ˇenı ´ modelu chova ´nı ´ syste ´mu vytvor ˇı ´me specifikaci procesu ˚ * dokonc ˇı ´me datovy ´ slovnı ´k, ERA model * vy ´s ˇe uvedene ´ informace tvor ˇı ´ tzv. esencia ´lnı ´ model syste ´mu
Vytvor ˇenı ´ uz ˇivatelske ´ho implementac ˇnı ´ho modelu .............................................. Uz ˇivatelsky ´ implementac ˇnı ´ model pokry ´va ´: * alokaci esencia ´lnı ´ho modelu na lidi a stroje (ktere ´ bubliny a pame ˇti budou realizova ´ny manua ´lne ˇ) - to musı ´ rozhodnout uz ˇivatel * rozhranı ´ aplikace s uz ˇivatelem (volba vstupnı ´ch a vy ´stupnı ´ch zar ˇı ´zenı ´, forma ´ty obrazovek, forma ´ty vy ´stupu ˚) * omezenı ´, napr ˇ. objemy dat, c ˇasy odpove ˇdı ´ na ru ˚zne ´ uda ´losti atd., tj. mimofunkc ˇnı ´ poz ˇadavky na aplikaci * vytvor ˇenı ´ uz ˇivatelske ´ho implementac ˇnı ´ho modelu je oficia ´lne ˇ poslednı ´m krokem modernı ´ strukturovane ´ analy ´zy poz ˇadavku ˚. - na ´sleduje na ´vrh architektury, podrobny ´ na ´vrh, implementace, testova ´nı ´ Pozna ´mka: Pr ˇi analy ´ze nemusejı ´ by ´t pouz ˇity vs ˇechny na ´stroje (modely) - pouz ˇı ´vajı ´ se vz ˇdy pouze ty na ´stroje, ktere ´ majı ´ v dane ´m kontextu smysl. Napr ˇı ´klad pokud jsou datove ´ struktury jednoduche ´, nemusı ´me vytva ´r ˇet ERA diagramy. [] Krome ˇ klasicke ´ (DeMarcovy) metodologie a (Yourdonovy) modernı ´ strukturovane ´ analy ´zy se v praxi pouz ˇı ´vajı ´ dals ˇı ´ metodiky pro strukturovanou analy ´zu, napr ˇ. ˇesku je z nich asi nejpouz SADT, SREM/RDD, SA/SD. V C ˇı ´vane ˇjs ˇı ´ SSADM (Structured Systems Analysis and Design Method); ma ´ v podstate ˇ podobny ´ za ´be ˇr a na ´stroje jako DeMarcova a Yourdonova strukturovana ´ analy ´za (vy ´stupy - DFD, model entit, ...), ale je to standard - velmi podrobne ˇ definovane ´ kroky vc ˇetne ˇ vy ´stupu ˚ a pr ˇedepsany ´ch kontrol pr ˇed pr ˇechodem k dals ˇı ´mu kroku. Pouz ˇitı ´ metodiky SSADM je v ne ˇktery ´ch zemı ´ch podmı ´nkou pro zı ´ska ´nı ´ sta ´tnı ´ch zaka ´zek. Na ´vrh architektury ================== * architektura softwaru je popis podsyste ´mu ˚ (komponent) a vztahu ˚ mezi nimi - jednotlive ´ aspekty architektury se obvykle nazy ´vajı ´ ”pohledy” (viewpoints) - napr ˇ. fyzicky ´ pohled (umı ´ste ˇnı ´ komponent), procesnı ´ pohled (ty ´ka ´ se paralelismu), struktura ´lnı ´ pohled (jak vy ´voja ´r ˇi rozde ˇlı ´ syste ´m do implementac ˇnı ´ch c ˇa ´stı ´) apod. * pr ˇi klasicke ´m postupu vycha ´zejı ´cı ´m ze strukturovane ´ analy ´zy na ´s bude zajı ´mat zejme ´na fyzicky ´ a struktura ´lnı ´ pohled - nejprve rozhodneme, ktere ´ c ˇa ´sti esencia ´lnı ´ho modelu budou alokova ´ny na ktere ´ poc ˇı ´tac ˇe (napr ˇ. cely ´ syste ´m bude implementova ´n na jednom poc ˇı ´tac ˇi) - pak pr ˇir ˇadı ´me ”procesy” a ”pame ˇti” alokovane ´ na stejny ´ poc ˇı ´tac ˇ jednotlivy ´m procesu ˚m Podrobny ´ postup na ´vrhu architektury byl jiz ˇ popsa ´n v 6. pr ˇedna ´s ˇce - pro strukturovane ´ metody vy ´voje je postup v za ´sade ˇ stejny ´, a proto ho zde nebudu opakovat. V mnoha pr ˇı ´padech je vhodne ´ vycha ´zet z tzv. architektonicky ´ch stylu ˚ (makro-architektonicky ´ch vzoru ˚), ktere ´ pr ˇedstavujı ´ typicke ´ r ˇes ˇenı ´ architektury pro dany ´ typ aplikace. Pr ˇı ´klady architektonicky ´ch stylu ˚ uvedu pozde ˇji. Strukturovany ´ na ´vrh syste ´mu =========================== * ne ˇkdy se take ´ nazy ´va ´ funkc ˇne ˇ orientovany ´ na ´vrh (function-oriented design) * pr ˇedcha ´zela mu strukturovana ´ analy ´za a na ´vrh architektury - produktem analy ´zy jsou:
93
Za´klady softwarove´ho inzˇeny´rstvı´
94
zswi/p9sad.d
. model kontextu syste ´mu resp. DFD ´ urovne ˇ 0 . mnoz ˇina diagramu ˚ datovy ´ch toku ˚ (DFD) . specifikace c ˇinnosti elementa ´rnı ´ch procesu ˚ (pseudoko ´dy, Nassi-Shneidermanovy diagramy, rozhodovacı ´ tabulky a stromy) . datovy ´ slovnı ´k . ERA diagramy - produktem na ´vrhu architektury je rozhodnutı ´, ktere ´ c ˇa ´sti esencia ´lnı ´ho modelu budou pr ˇir ˇazeny jednotlivy ´m podsyste ´mu ˚m, pr ˇı ´padne ˇ na ktere ´ poc ˇı ´tac ˇe nebo procesory budou alokova ´ny (napr ˇ. cely ´ syste ´m bude implementova ´n na jednom poc ˇı ´tac ˇi) * podrobny ´ - v ra ´mci bublina - napr ˇ. z
na ´vrh aplikace probı ´ha ´ v na ´sledujı ´cı ´ch krocı ´ch: podsyste ´mu ˚ transformace DFD na hierarchii podprogramu ˚ (kaz ˇda ´ se stane podprogramem) DFD y
A
x
z
B
p
C
q
D
E
r
vzniknou podprogramy s na ´sledujı ´cı ´ hierarchiı ´:
C z
p
B
D
y
q
A
E
x
r
get x
put r
Transformace DFD na hierarchii podprogramu ˚ .......................................... V obecne ´m pr ˇı ´pade ˇ nenı ´ pr ˇevod DFD tak pr ˇı ´moc ˇary ´ jako v pr ˇedchozı ´m pr ˇı ´kladu, proto se pouz ˇı ´va ´ na ´sledujı ´cı ´ postup: * vycha ´zı ´me z DFD nejniz ˇs ˇı ´ ´ urovne ˇ (bubliny = elementa ´rnı ´ procesy); pro kaz ˇdy ´ DFD provedeme: - identifikujeme centra ´lnı ´ transformaci = c ˇa ´st DFD popisujı ´cı ´ za ´kladnı ´ fce syste ´mu, neza ´visla ´ na implementaci vstupu ˚ a vy ´stupu ˚ - dva zpu ˚soby hleda ´nı ´ centra ´lnı ´ transformace: . bud’ pr ˇedpokla ´da ´me ”idea ´lnı ´ sve ˇt”, kde vstupy nikdy neobsahujı ´ chyby, vy ´stupy nemusı ´ by ´t forma ´tova ´ny apod.; odseka ´va ´me vs ˇechny nepotr ˇebne ´ vstupnı ´ a vy ´stupnı ´ proudy, co na ´m zu ˚ stane je centra ´lnı ´ transformace . nebo najdeme ”str ˇed” DFD odhadem (to je hors ˇı ´ varianta, ale nic jine ´ho na ´m nezby ´va ´, pokud nedoka ´z ˇeme centra ´lnı ´ transformaci identifikovat jinak) - kolem centra ´lnı ´ transformace nakreslı ´me obla ´c ˇek
α
A
β
B
γ ε
φ
F
δ
C
D
ζ
centrální transformace
η E
ι
G
κ
* vytvor ˇı ´me hierarchii procesu ˚ - hierarchie procesu ˚ bude vyjadr ˇovat vztah nadr ˇı ´zenosti a podr ˇı ´zenosti - nejprve musı ´me najı ´t kandida ´ta na s ˇe ´fa . pokud je dobry ´ kandida ´t (v centra ´lnı ´ transformaci), zvedneme ho a necha ´me ostatnı ´ bubliny viset dolu ˚, viz obra ´zek (a) . pokud je potencia ´lnı ´ch kandida ´tu ˚ vı ´ce, vyzkous ˇı ´me, ktery ´ na ´m poskytne nejleps ˇı ´ na ´vrh
zswi/p9sad.d
3. ledna 2005 γ D
η
E
α
β
B φ
G
φ
šéf
ε
A
ι
F
A
α
ζ
ε
B
β
δ
C
γ
95
F
γε
ι
ι G
centrální trans− formace
κ
b) vytvoření nového šéfa
κ
a) vyzvednutí šéfa
. pokud nenı ´ dobry ´ kandida ´t, vytvor ˇı ´me nove ´ho s ˇ´ efa, centra ´lnı ´ transformaci nahradı ´me s ˇe ´fem a pu ˚vodnı ´ transformaci pod s ˇe ´fa zave ˇsı ´me (jako jednu bublinu, vstupy a vy ´stupy budou proudit pr ˇes s ˇe ´fa; viz obra ´zek (b)) * transformace DFD na hierarchii bloku ˚ (kaz ˇda ´ bublina se stane blokem) - ”s ˇe ´f” se stane r ˇı ´dı ´cı ´m blokem, ostatnı ´ budou jeho podr ˇı ´zenı ´ - vytvor ˇı ´me poc ˇa ´tec ˇnı ´ strukturogram
γ
BOSS
ε B
δ
ζ
F
η
φ
β A
α
READ
φ
D
E
ι
READ
α
G
κ WRITE
κ
- ˇ sipky ukazujı ´ sme ˇr vola ´nı ´, pr ˇidali jsme bloky pro vstup a vy ´stup - jme ´na bloku ˚ by me ˇla odpovı ´dat jejich rolı ´m v hierarchii, tj. nemusejı ´ odpovı ´dat na ´zvu ˚m bublin - jme ´no by me ˇlo sumarizovat i c ˇinnost podr ˇı ´zeny ´ch bloku ˚ . pr ˇı ´klad na ´zvu ˚ bloku ˚ - postupne ˇ: ”zı ´skej poloz ˇku” (blok pro c ˇtenı ´ dat), ”zı ´skej transakci” (pomocı ´ niz ˇs ˇı ´ho bloku vytvor ˇı ´ transakci), ”zı ´skej platnou transakci” (ove ˇr ˇı ´ platnost transakce) - strukturovany ´ design se zna ´zorn ˇuje pomocı ´ tzv. strukturogramu ˚ (structure charts) . strukturogramy ukazujı ´ rozde ˇlenı ´ syste ´mu do hierarchie bloku ˚ a jejich vza ´jemnou komunikaci . blok pr ˇedstavuje proceduru nebo fci programovacı ´ho jazyka; blok se zna ´zorn ˇuje jako obde ´lnı ´k obsahujı ´cı ´ na ´zev bloku . knihovnı ´ procedury a fce (pr ˇeddefinovane ´ bloky) se zna ´zorn ˇujı ´ pomocı ´ zdvojenı ´ svisly ´ch c ˇar obde ´lnı ´ka . vola ´nı ´ podprogramu je zna ´zorne ˇno obyc ˇejnou s ˇipkou (od volajı ´cı ´ho k volane ´mu) . pr ˇeda ´va ´nı ´ zpracova ´vany ´ch dat je zna ´zorne ˇno s ˇipkou s pra ´zdny ´m krouz ˇkem (s ˇipka sme ˇr ˇuje od odesilatele k pr ˇı ´jemci dat) . pr ˇeda ´va ´nı ´ pr ˇı ´znaku ˚ je zna ´zorne ˇno s ˇipkou s plny ´m krouz ˇkem
NAJDI JMÉNO ZÁKAZNÍKA blok
PŘIDEJ ZÁZNAM DO DATABÁZE
volání data příznak
knihovní (předdefinovaný) blok
Pozna ´mka pro zajı ´mavost (blok vs. modul ve strukturovane ´m designu) V pu ˚vodnı ´ literatur ˇe o strukturovane ´m na ´vrhu se o blocı ´ch hovor ˇı ´ jako o ”modulech”. Termı ´n ”modul” ma ´ ale dnes uz ˇ jiny ´ vy ´znam nez ˇ v roce 1980, proto
Za´klady softwarove´ho inzˇeny´rstvı´
96
ho v souvislosti se strukturogramy rade ˇji nebudeme pouz ˇı ´vat. [] * ´ uprava strukturogramu - pr ˇida ´me c ˇtecı ´ a za ´pisove ´ bloky, bloky pro c ˇtenı ´ z databa ´ze apod. - centra ´lnı ´ transformaci mu ˚z ˇeme rozde ˇlit podle DFD - pr ˇida ´me bloky pro obsluhu chyb - pokud jsou potr ˇebne ´, pr ˇida ´me bloky pro inicializaci a ukonc ˇenı ´ programu - pokud je nespra ´vny ´ vy ´be ˇr s ˇe ´fa, zme ˇnı ´me ho (nespra ´vny ´ vy ´be ˇr s ˇe ´fa se obvykle projevı ´ tak, z ˇe pravy ´ s ˇe ´f signalizuje sve ´mu nadr ˇı ´zene ´mu, co ma ´ de ˇlat) * ove ˇˇ renı ´ funkc ˇnosti na ´vrhu - implementuje strukturogram poz ˇadavky vyja ´dr ˇene ´ v DFD? - pokud si ne ˇjaky ´ blok potr ˇebuje vyz ˇa ´dat data, mu ˚z ˇe to ude ˇlat? - pokud ne, mu ˚z ˇeme zme ˇnit hierarchii vola ´nı ´ * pokud jsme vy ´s ˇe uvedene ´ kroky provedli pro jednotlive ´ DFD, ma ´me k dispozici mnoz ˇinu neza ´visly ´ch strukturogramu ˚ - vytvor ˇı ´me nads ˇe ´fa, ktery ´ bude volat jednotlive ´ s ˇe ´fy - optima ´lnı ´ je, pokud nads ˇe ´f obsahuje konstrukci case, ktera ´ vyvola ´ ne ˇktere ´ho podr ˇı ´zene ´ho (napr ˇ. vy ´be ˇrem poloz ˇky v menu); v takove ´m pr ˇı ´pade ˇ bychom museli uz ˇ DFD rozde ˇlit podle typu ˚ transakcı ´ * tı ´m konc ˇı ´ fa ´ze strukturovane ´ho na ´vrhu - hlavnı ´m ´ uc ˇelem strukturovane ´ho na ´vrhu je rozde ˇlenı ´ syste ´mu do bloku ˚ - vy ´stupem je jeden nebo vı ´ce strukturogramu ˚, z bloku ˚ vzniknou podprogramy - strukturovany ´ na ´vrh ner ˇes ˇı ´ sdruz ˇenı ´ podprogramu ˚ do modulu ˚ (to probereme da ´le) nebo na ´vrh vnitr ˇku podprogramu ˚ (zde mu ˚z ˇeme vycha ´zet z pseudoko ´du, viz pr ˇedna ´s ˇka o ko ´dova ´nı ´)
Charakteristiky kvalitnı ´ch podprogramu ˚ -------------------------------------Dve ˇ za ´kladnı ´ charakteristiky dobre ´ho na ´vrhu podprogramu ˚ je silna ´ soudrz ˇnost a slaba ´ prova ´zanost. Soudrz ˇnost .......... * soudrz ˇnost (cohesion) = jak blı ´zky ´ vztah k sobe ˇ majı ´ operace uvnitr ˇ podprogramu * existuje ne ˇkolik ´ urovnı ´ soudrz ˇnost: funkc ˇnı ´, sekvenc ˇnı ´, komunikac ˇnı ´ atd. * funkc ˇnı ´ soudrz ˇnost - podprogram vykona ´va ´ pra ´ve ˇ jednu funkci - napr ˇ. fce sin() bude mı ´t funkc ˇnı ´ soudrz ˇnost, protoz ˇe vykona ´va ´ jedinou fci - fce sin_and_tan() by neme ˇla funkc ˇnı ´ soudrz ˇnost, protoz ˇe by prova ´de ˇla dve ˇ fce - podprogramy by me ˇly by ´t silne ˇ soudrz ˇne ´, tj. de ˇlat pokud moz ˇno jen jednu ve ˇc - du ˚ sledkem silne ´ soudrz ˇnosti je vys ˇs ˇı ´ spolehlivost (to je proka ´za ´no studiemi) Z vy ´s ˇe r ˇec ˇene ´ho vyply ´va ´, z ˇe funkce by neme ˇly by ´t vı ´ceu ´c ˇelove ´ (klasicky ´ s ˇpatny ´ pr ˇı ´klad: fce realloc(ptr, size) jazyka C zve ˇts ˇuje alokovany ´ ´ usek pame ˇti, zmens ˇuje ho, uvoln ˇuje (pokud size=0), alokuje novy ´ ´ usek pame ˇti (ptr=NULL), atd.). Proto je to take ´ nejhu ˚r ˇe srozumitelna ´ fce standardnı ´ knihovny jazyka C. * sekvenc ˇnı ´ soudrz ˇnost - slabs ˇı ´ typ soudrz ˇnosti nez ˇ je funkc ˇnı ´ soudrz ˇnost - podprogram sesta ´va ´ z kroku ˚, ktere ´ se musejı ´ prove ´st v urc ˇite ´m por ˇadı ´ - kroky postupne ˇ zpracova ´vajı ´ sdı ´lena ´ data, ale netvor ˇı ´ ucelenou fci - napr ˇı ´klad program bude prova ´de ˇt 10 kroku ˚, pokud je prvnı ´ch 5 v jedne ´ fci a druhy ´ch 5 ve druhe ´, je to sekvenc ˇnı ´ soudrz ˇnost - funkc ˇnı ´ soudrz ˇnost je leps ˇı ´ => fce sdruz ˇı ´me do jedne ´, operace bude ucelena ´ * komunikac ˇnı ´ soudrz ˇnost - jes ˇte ˇ slabs ˇı ´ typ - operace prova ´de ˇjı ´ zpracova ´nı ´ stejny ´ch dat, ale jinak spolu nemajı ´ nic spolec ˇne ´ho; napr ˇ. zme ˇna dvou nesouvisejı ´cı ´ch prvku ˚ datove ´ struktury - z prakticky ´ch du ˚vodu ˚ jes ˇte ˇ akceptovatelne ´ Pozna ´mka (analogie soudrz ˇnost podprogramu ˚ pro tr ˇı ´dy: soudrz ˇnost tr ˇı ´dy)
zswi/p9sad.d
zswi/p9sad.d
3. ledna 2005
Jedna z charakteristik dobr ˇe navrz ˇeny ´ch tr ˇı ´d je soudrz ˇnost tr ˇı ´dy; je to analogie soudrz ˇnosti podprogramu ˚, avs ˇak o jednu ´ uroven ˇ zapouzdr ˇenı ´ vy ´s ˇe. Ukazuje vza ´jemny ´ vztah sady atributu ˚ a operacı ´ tvor ˇı ´cı ´ch rozhranı ´ tr ˇı ´dy. Podrobne ˇji viz (Page-Jones 2001), kap. 9.3. [] Prova ´zanost ........... * stupen ˇ prova ´zanosti (degree of coupling) = jak blı ´zky ´ vztah majı ´ dva podprogramy - napr ˇ. fce sin(x) ma ´ slabou prova ´zanost s ostatnı ´mi podprogramy, protoz ˇe jedine ´, co potr ˇebuje zna ´t, je jednoduchy ´ vstupnı ´ parametr x - pone ˇkud silne ˇjs ˇı ´ typ prova ´zanosti nasta ´va ´, pokud si podprogramy pr ˇeda ´vajı ´ datove ´ struktury - jes ˇte ˇ silne ˇjs ˇı ´ prova ´zanost nasta ´va ´, pokud procedury pouz ˇı ´vajı ´ globa ´lnı ´ data atd. V praxi obvykle nenı ´ du ˚lez ˇite ´ urc ˇovat pr ˇesnou ´ uroven ˇ soudrz ˇnosti a prova ´zanosti, ale je tr ˇeba se snaz ˇit o silnou soudrz ˇnost a slabou prova ´zanost.
Vytva ´r ˇenı ´ modulu ˚ ---------------* pro ´ uc ˇely dals ˇı ´ho vy ´kladu zadefinujeme na ´sledujı ´cı ´ termı ´ny: - podprogram = procedura nebo funkce - modul = mnoz ˇina dat a podprogramu ˚, napr ˇı ´klad ”unit” v ne ˇktery ´ch verzı ´ch Pascalu, zdrojovy ´ soubor v C apod. . by ´va ´ obvykle definova ´n jako nejmens ˇı ´ jednotka zdrojove ´ho textu programu, kterou mu ˚z ˇeme samostatne ˇ pr ˇeloz ˇit Vyleps ˇenı ´ modularity podsyste ´mu ............................... Pote ´, co byla vytvor ˇena struktura podsyste ´mu, mu ˚z ˇeme jı ´ da ´le vyleps ˇit pomocı ´ na ´sledujı ´cı ´ch pravidel: * projdeme jednotlive ´ podprogramy, zmens ˇujeme prova ´zanost a zvys ˇujeme soudrz ˇnost - pokud je ve dvou podprogramech stejna ´ c ˇinnost, mu ˚z ˇe by ´t vyjmuta do samostatne ´ho podprogramu - pokud jsou dva podprogramy vysoce prova ´za ´ny, mu ˚z ˇe by ´t vhodne ´ je spojit (zjednodus ˇı ´ se jejich rozhranı ´) * omezenı ´ pu ˚sobnosti procedury: procedura by me ˇla mı ´t vliv pouze na podr ˇı ´zene ´ procedury - podr ˇı ´zeny ´ch procedur nema ´ by ´t velke ´ mnoz ˇstvı ´ (”low fan-out”) * s rostoucı ´ hloubkou strukturogramu se snaz ˇte o to, aby procedura byla vola ´na vys ˇs ˇı ´m poc ˇtem nadr ˇı ´zeny ´ch procedur (”high fan-in”) - strukturogram by me ˇl mı ´t tvar ova ´lu, na spodnı ´ ´ urovni by me ˇly by ´t vs ˇeobecne ˇ uz ˇitec ˇne ´ procedury, ktere ´ bude volat vı ´ce nadr ˇı ´zeny ´ch * rozhranı ´ kaz ˇde ´ho podprogramu se snaz ˇı ´me co nejvı ´ce zjednodus ˇit
Na ´vrh modulu ˚ ............ * perfektnı ´ modularita jednotlivy ´ch podprogramu ˚ = komunikace pouze pomocı ´ jednoduche ´ho rozhranı ´ - skupina podprogramu ˚ mu ˚z ˇe sdı ´let spolec ˇna ´ data, podprogramy pak nejsou perfektne ˇ modula ´rnı ´ - pokud spolec ˇna ´ data skryjeme uvnitr ˇ modulu (budou pr ˇı ´stupna ´ pouze podprogramu ˚m uvnitr ˇ modulu) a zbytek programu mu ˚z ˇe s modulem komunikovat pouze pomocı ´ jeho oficia ´lnı ´ho rozhranı ´, bude skupina podprogramu ˚ perfektne ˇ
97
Za´klady softwarove´ho inzˇeny´rstvı´
98
modula ´rnı ´, i kdyz ˇ jednotlive ´ podprogramy perfektne ˇ modula ´rnı ´ nejsou * moduly procedura ´lnı ´ch programovacı ´ch jazyku ˚ jsou vlastne ˇ ”poor folks’ objects” - sdruz ˇujı ´ data a operace nad daty, pr ˇı ´padne ˇ jinou navza ´jem souvisejı ´cı ´ mnoz ˇinu sluz ˇeb - moduly podporujı ´ OO koncepty abstrakce a zapouzdr ˇenı ´, nepodporujı ´ de ˇdic ˇnost - dobry ´ modula ´rnı ´ na ´vrh podstatne ˇ usnadn ˇuje ´ udrz ˇbu (lokalizace zme ˇn) * moduly je vhodne ´ vytvor ˇit pro vs ˇechny sluz ˇby, jejichz ˇ implementace se mu ˚z ˇe zme ˇnit, nebo pro souc ˇa ´sti, ktere ´ lze vyuz ˇı ´t v jiny ´ch projektech - uz ˇivatelske ´ rozhranı ´: bude se pravde ˇpodobne ˇ vyvı ´jet, zbytek syste ´mu by jı ´m neme ˇl by ´t ovlivne ˇn - HW nebo syste ´move ´ za ´vislosti: pro snadne ˇjs ˇı ´ pr ˇenos syste ´mu do jine ´ho prostr ˇedı ´ (napr ˇı ´klad operac ˇnı ´ syste ´my: moduly pro jednotlive ´ HW architektury, ovladac ˇe apod.; nebo Netscape - moduly pro pra ´ci se sı ´tı ´ ve Windows a v UNIXu) - vstupy/vy ´stupy: snadne ˇjs ˇı ´ zme ˇna forma ´tu souboru ˚, vy ´stupnı ´ch tiskovy ´ch sestav apod. - spra ´va dat - moduly pro kaz ˇdy ´ typ dat; k datu ˚m pr ˇistupujeme pouze pomocı ´ podprogramu ˚, coz ˇ usnadn ˇuje zme ˇnu reprezentace apod. Napr ˇ. modul implementujı ´cı ´ za ´sobnı ´k by me ˇl procedury rozhranı ´ init_stack(), push() a pop() - moduly pro navza ´jem pr ˇı ´buzne ´ operace, napr ˇ. manipulace s r ˇete ˇzci, statisticke ´ fce, graficke ´ podprogramy apod. Napr ˇ. modul obsahujı ´cı ´ trigonometricke ´ fce sin(), cos(), tan() atd. Vyva ´r ˇenı ´ modulu ˚ v na ´vaznosti na strukturovany ´ design .................................................... * pokud navazujeme na strukturovany ´ design, ma ´me k dispozici strukturogram - sdruz ˇı ´me souvisejı ´cı ´ bloky nı ´zke ´ ´ urovne ˇ (bloky nı ´zke ´ ´ urovne ˇ budou nejc ˇaste ˇji vstupy, vy ´stupy, pr ˇı ´stup k databa ´zi, pomocne ´ podprogramy, uz ˇivatelske ´ rozhranı ´) - zbytek strukturogramu rozde ˇlı ´me na c ˇa ´sti, ktere ´ jsou silne ˇ kohezivnı ´ a k ostatnı ´m c ˇa ´stem se va ´z ˇı ´ volne ˇ (snaz ˇı ´me se o minima ´lnı ´ rozhranı ´ mezi c ˇa ´stmi) - bloky v kaz ˇde ´ c ˇa ´sti budou tvor ˇit jeden nebo vı ´ce modulu ˚ Modul 1
l2
du
Mo
Mo ln
du
i
i
i
Vstupní modul
u
u
Pomocné podpr.
o
o
o
Výstupní modul
Podle Page-Jonese (1980) se ukazuje jako nejleps ˇı ´ na ´sledujı ´cı ´ pr ˇir ˇazenı ´ modulu ˚ ty ´mu ˚m programa ´toru ˚: * na ´vrha ´r ˇi syste ´mu ko ´dujı ´ moduly vys ˇs ˇı ´ ´ urovne ˇ * jednotlive ´ typy modulu ˚ niz ˇs ˇı ´ ´ urovne ˇ pr ˇir ˇadı ´me ty ´mu ˚m, ktere ´ s danou oblastı ´ majı ´ zkus ˇenosti (databa ´ze, uz ˇivatelske ´ rozhranı ´ apod.) - ty ´my mohou obsahovat i me ´ne ˇ zkus ˇene ´ programa ´tory, na ´vrha ´r ˇi syste ´mu na ne ˇ dohlı ´z ˇejı ´ Pozna ´mka (klasicka ´ chyba pr ˇi na ´vrhu modulu ˚) Mezi klasicke ´ chyby patr ˇı ´ na ´vrh modulu ˚ tak, aby odpovı ´dal poc ˇtu dostupny ´ch programa ´toru ˚. Spra ´vny ´ na ´vrh zapouzdr ˇuje podprogramy do modulu ˚ podle vy ´s ˇe uvedeny ´ch krite ´riı ´ (jako je zapouzdr ˇenı ´ pr ˇı ´buzny ´ch operacı ´ atd.) a na poc ˇtu programa ´toru ˚ by neme ˇl pr ˇı ´mo za ´viset. []
❉
zswi/pAcode.d
zswi/pAcode.d
3. ledna 2005
KIV/ZSWI 2004/2005 Pr ˇedna ´s ˇka 10 Na ´vrh uz ˇivatelske ´ho rozhranı ´ ============================ * ve ˇts ˇinu aplikacı ´ mu ˚z ˇeme rozde ˇlit do dvou c ˇa ´stı ´ - aplikac ˇnı ´ logika a uz ˇivatelske ´ rozhranı ´ (user interface, da ´le jen UI) * stars ˇı ´ aplikace textove ´ rozhranı ´, v souc ˇasny ´ch syste ´mech graficke ´ uz ˇivatelske ´ rozhranı ´ (GUI), protoz ˇe dovoluje podstatne ˇ vı ´ce moz ˇnostı ´ Doporuc ˇenı ´ pro na ´vrh UI ....................... Mandel (1997) popisuje ve sv knize o na ´vrhu uz ˇivatelsky ´ch rozhranı ´ tr ˇi c ˇasto citovana ´ ”zlata ´ pravidla”: * syste ´m by me ˇl reagovat na potr ˇeby uz ˇivatele, tj. uz ˇivatel by ho me ˇl r ˇı ´dit (nikoli naopak) * rozhranı ´ by me ˇlo by ´t konzistentnı ´ = vs ˇechny jeho c ˇa ´sti by se me ˇly chovat podobne ˇ * dobr ˇe navrz ˇene ´ UI by neme ˇlo mı ´t poz ˇadavky na pame ˇt’ uz ˇivatele Tato pravidla mu ˚z ˇeme trochu rozepsat: * syste ´m by me ˇl reagovat na potr ˇeby uz ˇivatele, tj. uz ˇivatel by ho me ˇl r ˇı ´dit - uz ˇivatel by neme ˇl by ´t nucen pouz ˇı ´vat ne ˇjake ´ rozhranı ´ jen proto, z ˇe se snadno implementuje; uz ˇivatel by neme ˇl by ´t nucen vykona ´vat nechte ˇne ´ akce . napr ˇ. pokud spustı ´m fci spell check textove ´ho procesoru a uvidı ´m mı ´sto, ktere ´ bych chte ˇl opravit, aplikace by me ˇ neme ˇla nutit zu ˚stat v rez ˇimu spell check - za ´kladnı ´ terminologie rozhranı ´ by me ˇla vycha ´zet z aplikac ˇnı ´ dome ´ny (uz ˇivatel se pohybuje ve virtua ´lnı ´m sve ˇte ˇ aplikace, napr ˇ. interaguje s objekty, ktere ´ se objevujı ´ na obrazovce) . napr ˇ. v syste ´mu pro r ˇı ´zenı ´ letove ´ho provozu bude opera ´tora informovat o letadlech, letovy ´ch koridorech, radiomaja ´cı ´ch apod.; implementace (pr ˇı ´stup k databa ´zi, komunikace atd.) by me ˇla by ´t pr ˇed uz ˇivatelem skryta - pokud uz ˇivatel ude ˇla ´ chybu, ma ´ mı ´t moz ˇnost operaci pr ˇedc ˇasne ˇ ukonc ˇit (cancel) nebo se vra ´tit do stavu pr ˇed vykona ´nı ´m chybne ´ akce (undo) . mechanismus ”cancel” - uz ˇivatele ´ budou nevyhnutelne ˇ pr ˇi pouz ˇı ´va ´nı ´ syste ´mu chybovat, UI ma ´ obsahovat moz ˇnost zrus ˇenı ´ c ˇa ´sti nebo cele ´ transakce (napr ˇ. zada ´va ´nı ´ pacienta) - UI by me ˇlo poskytnout pr ˇime ˇr ˇene ´ moz ˇnosti pro ru ˚zne ´ typy uz ˇivatelu ˚; zkus ˇenı ´ uz ˇivatele ´ budou chtı ´t napr ˇ. kla ´vesove ´ zkratky pro zrychlenı ´ pr ˇı ´stupu k moz ˇnostem syste ´mu, na druhou stranu zac ˇa ´tec ˇnı ´ci potr ˇebujı ´ vedenı ´ a na ´pove ˇdu ve stylu kuchar ˇky . napr ˇ. ne ˇktere ´ volne ˇ s ˇı ´r ˇene ´ programy dovolujı ´ nakonfigurovat, zda je uz ˇivatel zac ˇa ´tec ˇnı ´k, str ˇedne ˇ pokroc ˇily ´ c ˇi pokroc ˇily ´, a podle toho uz ˇivatele v ru ˚zne ´ mı ´r ˇe ”obte ˇz ˇujı ´” na ´pove ˇdou * UI by me ˇlo by ´t konzistentnı ´, tj. vs ˇechny pr ˇı ´kazy a menu by me ˇly pouz ˇı ´vat stejny ´ forma ´t - konzistence redukuje c ˇas uc ˇenı ´, protoz ˇe znalost zı ´skanou v jedne ´ c ˇa ´sti syste ´mu lze pouz ˇı ´t i v jine ´ c ˇa ´sti syste ´mu - UI by me ˇlo by ´t zaloz ˇeno na srozumitelne ´ metafor ˇe (analogii) z rea ´lne ´ho sve ˇta * s konzistencı ´ souvisı ´ princip nejmens ˇı ´ho pr ˇekvapenı ´ - podobne ´ akce vykonana ´ ru ˚ zny ´ch kontextech by me ˇly mı ´t podobne ´ du ˚sledky; pokud se syste ´m zachova ´ neoc ˇeka ´vany ´m zpu ˚sobem, budou uz ˇivatele ´ nemile pr ˇekvapeni - napr ˇ. pokud pr ˇi kreslenı ´ jednoho objektu znamena ´ stisk prave ´ho tlac ˇı ´tka mys ˇi zrus ˇenı ´ objektu a pr ˇi kreslenı ´ jine ´ho pr ˇipojenı ´ dals ˇı ´ c ˇa ´ry, nenı ´ UI aplikace konzistentnı ´ a mu ˚z ˇe dojı ´t k nemile ´mu pr ˇekvapenı ´ uz ˇivatele - UI by me ˇlo by ´t konzistentnı ´ i mezi podsyste ´my, napr ˇ. kla ´vesa Backspace by me ˇla vz ˇdy de ˇlat to same ´ (napr ˇ. zrus ˇit znak vlevo od kurzoru) * dobr ˇe navrz ˇene ´ UI by neme ˇlo mı ´t poz ˇadavky na pame ˇt’ uz ˇivatele - UI by me ˇlo omezovat potr ˇebu uz ˇivatele pamatovat si pr ˇedchozı ´ akce a jejich vy ´sledky (me ˇlo by uz ˇivateli napoma ´hat zjistit c ˇi pr ˇipomenout apod.) - UI by me ˇlo obsahovat na ´pove ˇdu, pr ˇi chybe ˇ by me ˇla by ´t poskytnuta smysluplna ´
99
Za´klady softwarove´ho inzˇeny´rstvı´
100
zswi/pAcode.d
zpe ˇtna ´ vazba v terminologii uz ˇivatele - chybove ´ zpra ´vy by me ˇly sde ˇlit typ chyby a kde se chyba uda ´la (ozna ´menı ´ ´ VSTUPNI ´ U ´DAJ” na ”CHYBNY ´m nic ner ˇekne) - chybove ´ zpra ´vy by me ˇly by ´t konstruktivnı ´ a kdekoli je to moz ˇne ´, tam by me ˇly napove ˇde ˇt, jak mu ˚z ˇe by ´t chyba opravena (leva ´ zpra ´va je negativnı ´, obvin ˇuje uz ˇivatele z toho z ˇe ude ˇlal chybu, nepouz ˇı ´va ´ jazyk uz ˇivatele (patient id); prava ´ je pozitivnı ´, r ˇı ´ka ´ z ˇe proble ´m je v syste ´mu a poskytuje na ´vod, jak chybu napravit)
Error #33 Invalid patient id entered OK
Cancel
Patient W. Gates is not registered Click on Patients for a list of registered patients Click on Retry to re−input a patient name Click on Help for more information Patients
Retry
Cancel
Help
Webove ´ aplikace by navı ´c me ˇly uz ˇivateli poskytovat odpove ˇdi na tr ˇi hlavnı ´ ota ´zky (Dix 1999): * kde jsem? - tj. jakou aplikaci pra ´ve ˇ pouz ˇı ´va ´m, na jake ´m mı ´ste ˇ jsem v hierarchii stra ´nek * co mohu de ˇlat? - tj. jake ´ funkce jsou nynı ´ dostupne ´ * kde jsem byl a kam jdu? - srozumitelna ´ navigace
Dals ˇı ´ pozna ´mky: * barva by neme ˇla by ´t prima ´rnı ´m nositelem vy ´znamu, protoz ˇe cca 10% populace je v ru ˚ zne ´ mı ´r ˇe barvoslepy ´ch * zvukovy ´m efektu ˚m se pokud moz ˇno vyhy ´ba ´me * du ˚lez ˇite ´ je uvaz ˇovat poz ˇadavky na c ˇas odpove ˇdi (de ´lku i variabilitu); pokud je c ˇas dels ˇı ´ nez ˇ cca 2s, je du ˚ lez ˇite ´, aby uz ˇivatel vide ˇl, z ˇe se ne ˇco de ˇje (napr ˇ. zobrazenı ´m ”teplome ˇru”) * je tr ˇeba poc ˇı ´tat s tı ´m, z ˇe uz ˇivatele ´ prakticky nikdy nec ˇtou manua ´l; ovla ´da ´nı ´ musı ´ by ´t intuitivnı ´, na ´pove ˇda snadno dostupna ´
Pozna ´mka pro zajı ´mavost (doporuc ˇenı ´ pro konkre ´tnı ´ GUI) Pro konkre ´tnı ´ GUI obvykle existujı ´ doporuc ˇenı ´ vy ´robce (style guide) pro na ´vrh aplikace s vyuz ˇitı ´m poskytovany ´ch prvku ˚ GUI. Doporuc ˇenı ´ bude obsahovat napr ˇı ´klad pravidlo, z ˇe defaultnı ´ hodnota ve formula ´r ˇi ma ´ by ´t nejpravde ˇpodobne ˇjs ˇı ´ volba, pr ˇı ´padne ˇ nejme ´ne ˇ nebezpec ˇna ´ volba; pokud je defaultnı ´ hodnota odvozena z jiny ´ch hodnot zadany ´ch uz ˇivatelem, pak ty hodnoty, ze ktery ´ch odvozujeme dals ˇı ´, majı ´ by ´t blı ´zko zac ˇa ´tku formula ´r ˇe atd. Jako pr ˇı ´klad uvedu ”Java Look and Feel Design Guideline”, kterou najdete na adrese http://java.sun.com/products/jlf/ed2/book/index.html . []
Na ´vrh UI ........ * mu ˚z ˇeme vycha ´zet ze sce ´na ´r ˇe, ktery ´ se va ´z ˇe k pr ˇı ´padu pouz ˇitı ´ * procha ´zı ´me sce ´na ´r ˇ, identifikujeme hranic ˇnı ´ objekty (podstatna ´ jme ´na) a akce (slovesa), ty ´kajı ´cı ´ se komunikace uz ˇivatele se syste ´mem - pta ´me se: jake ´ informace bude uz ˇivatel potr ˇebovat zada ´vat, me ˇnit, prohlı ´z ˇet? - napr ˇ. uz ˇivatel zada ´ {jme ´no} a {heslo} * vy ´hodne ´ je zac ˇı ´t na papı ´r ˇe - c ˇisty ´ papı ´r je pracovnı ´ plocha (c ˇasem se mu ˚z ˇe sta ´t oknem aplikace, dialogovy ´m oknem apod.) - pro kaz ˇdou pracovnı ´ plochu si poznamena ´me ”materia ´l” (data) a ”na ´stroje” (aktivnı ´ prvky pracujı ´cı ´ s materia ´lem) - pracovnı ´ plochu pojmenujeme
zswi/pAcode.d
3. ledna 2005
101
* vytvor ˇı ´me diagram procha ´zenı ´ pracovnı ´mi plochami (navigation map) popisuje, jak budou uz ˇivatele ´ moci pr ˇejı ´t z jedne ´ pracovnı ´ plochy do jine ´ - pro zna ´zorne ˇnı ´ mu ˚z ˇeme pouz ˇı ´vat na ´sledujı ´cı ´ notaci (Constantine 1998):
jakýkoli kontext pro interakci "Akce"
obrazovka nebo displej okno
změna kontextu spuštěná "Akcí" změna kontextu, návrat zpět se předpokládá
dialog nebo zpráva změna kontextu v kterémkoli směru
panel apod. ve složeném dialogu
- napr ˇı ´klad c ˇa ´stec ˇny ´ diagram programu pro spra ´vu syste ´mu by mohl vypadat na ´sledovne ˇ:
Úvodní obrazovka
Nastavení klávesnice Správa periferií
Nastavení myši Nastavení tiskárny
Správa uživatelů
Přidej uživatele
identifikace uživatele
Zruš uživatele
oprávnění uživatele
Změň nastavení uživatele
počáteční nastavení
Pozna ´mka: pokud byste chte ˇli ke stejne ´mu ´ uc ˇelu pouz ˇı ´t UML, mu ˚z ˇete pouz ˇı ´t napr ˇ. stavovy ´ diagram - uda ´losti popı ´s ˇeme kla ´vesou, pr ˇı ´kazem z menu atd. * abstraktnı ´ prototyp pr ˇevedeme na vzhled obrazovek - typicky se zac ˇı ´na ´ tı ´m, z ˇe kaz ˇdou abstraktnı ´ komponentu implementujeme jako jeden standardnı ´ prvek GUI (widget) - pak se snaz ˇı ´me zjednodus ˇit zpu ˚sob pra ´ce nebo us ˇetr ˇit mı ´sto na obrazovce * pro na ´vrh UI be ˇz ˇny ´ch syste ´mu ˚ mu ˚z ˇeme pouz ˇı ´t diagramy rozvrz ˇenı ´ oken (window layout diagram, viz take ´ [Page-Jones: Za ´klady OO na ´vrhu v UML. Grada 2001], str. 168) - zobrazuje pr ˇibliz ˇne ˇ na ´vrh okna, neobsahuje vs ˇechny kosmeticke ´ dopln ˇky - mu ˚z ˇeme zac ˇı ´t hruby ´m na ´vrhem prototypu pomocı ´ papı ´rove ´ho modelu UI, nakreslenı ´m obra ´zku na poc ˇı ´tac ˇi, pr ˇı ´padne ˇ v na ´stroji pro vytva ´r ˇenı ´ oken - informace ve formula ´r ˇı ´ch by me ˇla by ´t poz ˇadova ´na v logicke ´ posloupnosti (napr ˇ. oslovenı ´, jme ´no, pr ˇı ´jmenı ´; nikoli jme ´no, oslovenı ´, pr ˇı ´jmenı ´)
Soubor
Edit
Zobrazení
Nastavení
?
Vkládání údajů o pacientovi Titul: Jméno: Příjmení: Pohlaví: Ž
M
Telefonní číslo domů: OK
Zrušit
- pr ˇi na ´vrhu vzhledu je nejvy ´hodne ˇjs ˇı ´ evoluc ˇnı ´ vy ´voj (exploratory development), kde uz ˇivatel na ´vrh vyhodnocuje nebo spoluvytva ´r ˇı ´
Za´klady softwarove´ho inzˇeny´rstvı´
102
Vyhodnocenı ´ UI .............. * UI je obtı ´z ˇne ´ vyhodnotit bez otestova ´nı ´ na skutec ˇny ´ch uz ˇivatelı ´ch - dotaznı ´ky - co si uz ˇivatele ´ o rozhranı ´ myslı ´ - pozorova ´nı ´ uz ˇivatelu ˚ pr ˇi pra ´ci, pr ˇi pokusu vyr ˇes ˇit ´ ulohu ”myslı ´ nahlas” - snı ´ma ´nı ´ typicke ´ho vyuz ˇitı ´ syste ´mu videokamerou - vloz ˇenı ´ ko ´du, ktery ´ sbı ´ra ´ informace o nejpouz ˇı ´vane ˇjs ˇı ´ch vlastnostech a nejc ˇaste ˇjs ˇı ´ch chyba ´ch * z ˇa ´dny ´ ze zpu ˚sobu ˚ nedetekuje vs ˇechny proble ´my UI * dotaznı ´ky, ota ´zky mohou by ´t (1) jednoduche ´ odpove ˇdi typu ano/ne, (2) c ˇı ´selne ´ odpove ˇdi, (3) subjektivnı ´ ozna ´mkova ´nı ´, (4) subjektivnı ´ procentua ´lnı ´ odpove ˇd’; napr ˇ. 1. Jsou ikony srozumitelne ´? Pokud ne, ktere ´ ikony jsou nejasne ´? 2. Jak obtı ´z ˇne ´ bylo nauc ˇit se za ´kladnı ´ pra ´ci se syste ´mem? Ohodnot’te obtı ´z ˇnost na stupnici 1 az ˇ 5 (kde 5 je nejvys ˇs ˇı ´ obtı ´z ˇnost). 3. Kolik % fcı ´ syste ´mu jste pouz ˇila? (Vs ˇechny = 100%, z ˇa ´dne ´ = 0%) 4. Jak srozumitelne ´ jsou chybove ´ zpra ´vy? ... * pozorova ´nı ´ a nahra ´va ´nı ´, ktere ´ vlastnosti pouz ˇı ´vajı ´, jake ´ chyby de ˇlajı ´; analy ´za nahrane ´ relace dovoluje pozorovat, napr ˇ. zda UI nevyz ˇaduje pr ˇı ´lis ˇ mnoho pohybu ˚ rukou (proble ´m ne ˇktery ´ch GUI je nutnost opakovane ˇ pr ˇesouvat ruce mezi mys ˇı ´ a kla ´vesnicı ´ - optima ´lnı ´ je, pokud lze aplikaci ovla ´dat pouze pomocı ´ kla ´vesnice) * sbe ˇr statistik - zjis ˇte ˇnı ´ nejc ˇaste ˇjs ˇı ´ch operacı ´ => UI mu ˚z ˇe by ´t upraveno tak, aby tyto operace bylo moz ˇne ´ zvolit nejrychleji Architektonicke ´ styly ===================== * architektonicky ´ styl (angl. architectural style, macro-architectural pattern) je znovupouz ˇitelna ´ abstrakce syste ´mu - v praxi se vyskytuje opakovane ˇ v ru ˚zny ´ch aplikacı ´ch - mu ˚ˇ zeme z ne ˇj vycha ´zet pr ˇi tvorbe ˇ vlastnı ´ch aplikacı ´ * vlastnosti jednotlivy ´ch stylu ˚ jsou zna ´me ´ z jiz ˇ existujı ´cı ´ch aplikacı ´ dane ´ho stylu (s ˇka ´lovatelnost, vy ´konnost, bezpec ˇnost apod.) - styl slouz ˇı ´ jako komunikac ˇnı ´ na ´stroj a za ´klad pro managerske ´ rozhodova ´nı ´ (napr ˇ. pro rozde ˇlenı ´ do ty ´mu ˚, organizaci dokumentace projektu apod.) - styl je popsa ´n: . mnoz ˇinou podsyste ´mu ˚ a jejich typu ˚ (napr ˇ. datove ´ ´ uloz ˇis ˇte ˇ, proces, UI) . topologicky ´m uspor ˇa ´da ´nı ´m podsyste ´mu ˚ . mnoz ˇinou se ´manticky ´ch omezenı ´ (napr ˇ. datove ´ ´ uloz ˇis ˇte ˇ nesmı ´ me ˇnit uloz ˇene ´ hodnoty) . mnoz ˇinou interakc ˇnı ´ch mechanismu ˚ (vola ´nı ´ podprogramu, uda ´lost, roura) V dals ˇı ´m textu si uka ´z ˇeme nejdu ˚lez ˇite ˇjs ˇı ´ architektonicke ´ styly. Obecne ´ struktury ---------------Vrstvene ´ syste ´my ................ * syste ´m strukturujeme do podsyste ´mu ˚, ktere ´ tvor ˇı ´ vrstvy, vrstva pouz ˇı ´va ´ pouze sluz ˇby niz ˇs ˇı ´ch vrstev - pouz ˇı ´vajı ´ se, pokud fc ˇnost mu ˚z ˇe by ´t rozde ˇlena na c ˇa ´st specifickou pro aplikaci a generickou c ˇa ´st pouz ˇitelnou pro mnoho aplikacı ´ - dals ˇı ´ du ˚vody: . pokud c ˇa ´sti syste ´mu majı ´ by ´t nahraditelne ´ . pokud je du ˚lez ˇita ´ pr ˇenositelnost do ru ˚zny ´ch OS nebo HW . pokud mu ˚z ˇete vyuz ˇı ´t jiz ˇ existujı ´cı ´ vrstvu (OS, komunikaci po sı ´ti...) - pouz ˇı ´va ´ se v mnoha SW produktech, napr ˇı ´klad ne ˇktere ´ operac ˇnı ´ syste ´my
zswi/pAcode.d
zswi/pAcode.d
3. ledna 2005 vrstva 3 vrstva 2 vrstva 1 HW
Styl dataflow ............. * pouz ˇı ´va ´ se, pokud se mu ˚z ˇeme na syste ´m dı ´vat jako na posloupnost transformacı ´ zpracova ´vajı ´cı ´ch vstup a produkujı ´cı ´ch vy ´stup * vy ´hodou integrovatelnost - relativne ˇ jednoduche ´ rozhranı ´ mezi komponentami * dva hlavnı ´ podstyly - ”roury a filtry” a ”da ´vkove ˇ sekvenc ˇnı ´” architektura * roury a filtry (pipe-and-filter architecture) - podsyste ´my nazy ´va ´me filtry, jsou propojene ´ rourami, ktere ´ pr ˇena ´s ˇejı ´ data - kaz ˇdy ´ filtr pracuje neza ´visle, pouze oc ˇeka ´va ´ data v urc ˇite ´m forma ´tu a produkuje vy ´stup v urc ˇene ´m forma ´tu
filter
filter
filter
filter
filter
filter
filter
pipes
filter
* da ´vkove ˇ sekvenc ˇnı ´ - pokud vy ´s ˇe uvedena ´ architektura degeneruje do jedne ´ linea ´rnı ´ posloupnosti transformacı ´ - vstupem da ´vka dat, aplikuje na nı ´ posloupnost sekvenc ˇnı ´ch komponent (filtru ˚)
filter
filter
filter
filter
- pr ˇı ´kladem mohou by ´t pr ˇekladac ˇe programovacı ´ch jazyku ˚, napr ˇ. pr ˇekladac ˇ jazyka C: zdrojovy ´ text nejprve zpracuje preprocesor, pote ´ se provede lexika ´lnı ´ a syntakticka ´ analy ´za, optimalizace, nakonec generova ´nı ´ ko ´du
Pasivnı ´ datove ´ ´ uloz ˇis ˇte ˇ: styl reposita ´r ˇ (repository) .................................................... * centrem architektury je datove ´ ´ uloz ˇis ˇte ˇ (databa ´ze nebo soubor) * ostatnı ´ podsyste ´my (klienti) k ´ uloz ˇis ˇti pr ˇistupujı ´ a c ˇtou, pr ˇida ´vajı ´, rus ˇı ´ nebo modifikujı ´ data
client client
client data repository
client
client
client client client
* tento styl se pouz ˇı ´va ´, pokud je poz ˇadova ´no uchova ´nı ´, vy ´be ˇr a spra ´va velke ´ho mnoz ˇstvı ´ dat a pokud jsou data vhodne ˇ strukturovana ´ * hlavnı ´ cı ´le: - integrovatelnost, klientske ´ podsyste ´my pracujı ´ neza ´visle - s ˇka ´lovatelnost (scalability) = moz ˇnost snadno pr ˇida ´vat nove ´ klienty a data
103
Za´klady softwarove´ho inzˇeny´rstvı´
104
Aktivnı ´ datove ´ ´ uloz ˇis ˇte ˇ: styl tabule (blackboard) ................................................. * mnoz ˇina agentu ˚ spolupracuje pomocı ´ datove ´ho ´ uloz ˇis ˇte ˇ - ´ uloz ˇis ˇte ˇ je aktivnı ´, posı ´la ´ ozna ´menı ´ agentu ˚m o zme ˇne ˇ dat, ktera ´ je zajı ´majı ´ - agent vyhodnotı ´ obsah ´ uloz ˇis ˇte ˇ, pr ˇı ´padne ˇ vloz ˇı ´ vy ´sledek nebo c ˇa ´stec ˇne ´ ˇes r ˇenı ´ - obra ´zek zna ´zorn ˇuje pr ˇı ´klad uspor ˇa ´da ´nı ´; agenti jsou aktivova ´ni r ˇı ´dı ´cı ´m objektem/modulem, vyuz ˇı ´vajı ´ rozhranı ´ tabule pro pr ˇı ´stup k datu ˚m
Control activates
Blackboard Update - solutions - controlData Inspect operates_on
Agent
- napr ˇı ´klad syste ´my pro ume ˇlou inteligenci, rozpozna ´va ´nı ´ r ˇec ˇi apod. - tj. syste ´my, kde nezna ´me vhodne ´ uzavr ˇene ´ (algoritmicke ´) r ˇes ˇenı ´ proble ´mu, ale umı ´me r ˇes ˇit pomocı ´ agentu ˚ (napr ˇ. znalostnı ´ch agentu ˚), kter ˇı ´ k r ˇes ˇenı ´ pr ˇispı ´vajı ´
Distribuovane ´ syste ´my --------------------Pokud syste ´m mu ˚z ˇeme strukturovat jako mnoz ˇinu volne ˇ va ´zany ´ch podsyste ´mu ˚, podsyste ´my mohou be ˇz ˇet na neza ´visly ´ch strojı ´ch propojeny ´ch sı ´tı ´. Peer-to-peer ............ * komponenty spolu mohou nava ´zat komunikaci - vyme ˇn ˇujı ´ si informace podle potr ˇeby
komponenta
komponenta
komponenta
komponenta
komponenta
Architektura klient/server .......................... * pokud ´ uloha mu ˚z ˇe by ´t rozde ˇlena na tvu ˚ rce poz ˇadavku ˚ (klient) a jejich vykonavatele (server) * v syste ´mu je alespon ˇ jeden klient a alespon ˇ jeden server * nejc ˇaste ˇjs ˇı ´ podstyly stylu klient-server: - tr ˇı ´vrstva ´ architektura (3-tier architecture) - tlusty ´ klient (fat client) * tr ˇı ´vrstva ´ architektura (3-tier architecture) - funkc ˇnost se rozde ˇluje do 3 c ˇa ´stı ´: . klienti - obsahujı ´ prezentac ˇnı ´ sluz ˇby, obvykle jeden klient slouz ˇı ´ jednomu uz ˇivateli . datove ´ sluz ˇby - obvykle jsou implementova ´ny pomocı ´ databa ´zove ´ho serveru . aplikac ˇnı ´ logika - informace vytva ´r ˇı ´ a modifikuje pomocı ´ datovy ´ch sluz ˇeb, poskytuje informace klientu ˚m
zswi/pAcode.d
zswi/pAcode.d
3. ledna 2005
presentation
application logic
client application
business application
105 data services relational database
sdws zmc ehftqdr ax ktjh wkwd
- v souc ˇasne ´ dobe ˇ nejoblı ´bene ˇjs ˇı ´, ”SW pru ˚ mysl se neodvratne ˇ r ˇı ´tı ´ tı ´mto sme ˇrem” (citace z jedne ´ pr ˇedna ´s ˇky) - c ˇasta ´ varianta: tenky ´ klient - klientem je napr ˇ. WWW prohlı ´z ˇec ˇ * tlusty ´ klient (fat client) - klient obsahuje prezentaci i aplikac ˇnı ´ logiku, vyuz ˇı ´va ´ data z databa ´ze
client = application logic + GUI
data services (relational database)
sngkd mzjqdrkhk ktjh cwk wdhe wkwd
- oproti tr ˇı ´vrstve ´ architektur ˇe relativne ˇ snadny ´ na ´vrh, ale obtı ´z ˇna ´ ´ udrz ˇba
Broker ...... * cı ´lem je, aby distribuovanost byla transparentnı ´ = objekt mu ˚z ˇe volat metodu jine ´ho objektu, aniz ˇ by ve ˇde ˇl, z ˇe objekt nenı ´ loka ´lnı ´
client proxy
broker
remote object
* proxy vola ´ brokera, ktery ´ zjistı ´, kde se nacha ´zı ´ vzda ´leny ´ objekt * pr ˇı ´klad: CORBA (Common Object Request Broker Architecture) - je to architektura+infrastruktura pro spolupra ´ci aplikacı ´ prostr ˇednictvı ´m sı ´tı ´
Interaktivnı ´ syste ´my -------------------Architektura Model-View-Controller (MVC) ........................................ * architektura doporuc ˇovana ´ a s ˇiroce pouz ˇı ´vana ´ pro klasicke ´ i webove ´ interaktivnı ´ aplikace
View
vytvoř, aktualizuj
informuj o změně
Model
Controller změň
* odde ˇluje funkc ˇnı ´ vrstvu aplikace (”Model”) od dvou aspektu ˚ uz ˇivatelske ´ho rozhranı ´ (nazy ´vany ´ch ”View” a ”Controller”) - Model = objekty, ktere ´ budeme v aplikaci prohlı ´z ˇet a me ˇnit (napr ˇ. obchodnı ´ data) - View (na ´hled) = zobrazenı ´ modelu; pr ˇi zme ˇne ˇ obsahu modelu je vyvola ´na take ´ zme ˇna zobrazenı ´ - Controller = obsluhuje interakci uz ˇivatele s modelem . na za ´klade ˇ zme ˇn modelu a vstupu ˚ uz ˇivatele (stisku kla ´ves, vy ´be ˇru z menu)
Za´klady softwarove´ho inzˇeny´rstvı´
106
zswi/pAcode.d
vybı ´ra ´ View, ktery ´ se ma ´ zobrazit . typicky jeden Controller pro mnoz ˇinu pr ˇı ´buzny ´ch fcı ´ * architektura MVC byla jiz ˇ popsa ´na (viz str. 79 pr ˇedna ´s ˇek)
Ostatnı ´ styly ------------Virtua ´lnı ´ stroj ............... * pokud je vy ´poc ˇet bud’ velmi abstraktnı ´, nebo se pr ˇedpokla ´da ´ jeho be ˇh na ru ˚ zny ´ch typech stroju ˚ * pr ˇı ´klady: - interprety, napr ˇ. JVM - syste ´my zaloz ˇene ´ na pravidlech, napr ˇ. expertnı ´ syste ´my - procesory pr ˇı ´kazovy ´ch jazyku ˚, napr ˇ. /bin/sh
method area Java program .class files
class loader
Java API .class files
bytecodes bytecode interpreter
instruction/data interpreter data
updates data
host system
Co se vy ´be ˇru architektonicke ´ho stylu aplikace ty ´c ˇe, nejpr ˇı ´jemne ˇjs ˇı ´ by bylo mı ´t katalog stylu ˚ (podobne ˇ jako existujı ´ katalogy pro na ´vrhove ´ vzory), kde by bylo uvedeno ”pokud je proble ´m podobny ´ X, pouz ˇijte styl Y”. Na rozdı ´l od na ´vrhovy ´ch vzoru ˚ zatı ´m vy ´voj tak daleko nenı ´...
Pozna ´mka (na ´vrh syste ´mu shora dolu ˚) Alternativa metodic ˇte ˇjs ˇı ´ch pr ˇı ´stupu ˚ (napr ˇ. strukturovany ´ch nebo objektove ˇ orientovany ´ch metod) je neforma ´lnı ´ na ´vrh syste ´mu shora dolu ˚, kde vycha ´zı ´me z architektonicke ´ho na ´vrhu: * architektonicky ´ na ´vrh - identifikujeme a zdokumentujeme podsyste ´my a jejich vztahy * abstraktnı ´ specifikace podsyste ´mu ˚ - pro kaz ˇdy ´ podsyste ´m vytvor ˇı ´me abstraktnı ´ specifikaci podsyste ´mu a jeho omezenı ´ * na ´vrh rozhranı ´ podsyste ´mu ˚ - pro kaz ˇdy ´ podsyste ´m navrhneme a dokumentujeme rozhranı ´ (specifikace rozhranı ´ musı ´ by ´t jednoznac ˇna ´, aby bylo moz ˇne ´ podsyste ´m pouz ˇı ´vat bez znalosti jeho vnitr ˇnı ´ho fungova ´nı ´) * na ´vrh komponent - sluz ˇby alokujeme komponenta ´m, navrhneme rozhranı ´ komponent * podrobne ˇ navrhneme a specifikujeme datove ´ struktury * podrobne ˇ navrhneme a specifikujeme algoritmy * po na ´vrhu na ´sleduje ko ´dova ´nı ´ [] Implementace a ko ´dova ´nı ´ ======================= * vstupem implementace je na ´vrh (design) SW syste ´mu - na ´vrh mu ˚ˇ ze by ´t na ru ˚zne ´ ´ urovni podrobnosti - obvykle popis modulu ˚/tr ˇı ´d a jejich vztahu ˚ - v ne ˇktery ´ch pr ˇı ´padech mu ˚z ˇe by ´t kostra programu automaticky vygenerova ´na CASE na ´strojem * aktivity a postupy ve fa ´zi implementace:
zswi/pAcode.d
3. ledna 2005
- na ´vrh podprogramu ˚, algoritmu ˚, datovy ´ch struktur - psanı ´ a dokumentace ko ´du, strukturovane ´ programova ´nı ´ - testova ´nı ´ a lade ˇnı ´ modulu ˚, optimalizace Implementace ”zdola nahoru” --------------------------Na ´vrh syste ´mu te ´me ˇr ˇ vz ˇdy probı ´ha ´ shora dolu ˚, protoz ˇe se snaz ˇı ´me velky ´ proble ´m (vytva ´r ˇeny ´ SW syste ´m) rozde ˇlit do tak maly ´ch c ˇa ´stı ´, abychom je doka ´zali postupne ˇ vyr ˇes ˇit (tj. nakonec naprogramovat). Tento pr ˇı ´stup se c ˇasto nazy ´va ´ ”rozde ˇl a panuj”. Implementaci je naproti tomu ve ˇts ˇinou vhodne ´ realizovat zdola nahoru: * zac ˇı ´na ´me s podprogramy nejniz ˇs ˇı ´ ´ urovne ˇ, ktere ´ ihned testujeme - pro testova ´nı ´ podprogramu mu ˚z ˇeme vytvor ˇit jednoduchy ´ hlavnı ´ program, ktery ´ bude pouze volat testovany ´ podprogram s pr ˇı ´slus ˇny ´mi parametry * jakmile je podprogram funkc ˇnı ´, je tr ˇeba ho zdokumentovat - v komenta ´r ˇi k podprogramu uvedeme co podprogram de ˇla ´, vy ´znam vstupnı ´ch a vy ´stupnı ´ch argumentu ˚ a pr ˇı ´padne ´ na ´vratove ´ hodnoty * po vytvor ˇenı ´ vs ˇech potr ˇebny ´ch podprogramu ˚ niz ˇs ˇı ´ ´ urovne ˇ mu ˚z ˇeme napsat podprogram vys ˇs ˇı ´ ´ urovne ˇ a otestovat ho atd. * nakonec napı ´s ˇeme hlavnı ´ program Vytva ´ˇ renı ´m syste ´mu zdola nahoru postupne ˇ zve ˇts ˇujeme vyjadr ˇovacı ´ sı ´lu jazyka, ktery ´ pro psanı ´ syste ´mu pouz ˇı ´va ´me. Ve chvı ´li, kdy na ´m zac ˇnou velke ´ c ˇa ´sti syste ´mu pracovat, stane se to pro na ´s take ´ motivacı ´ k dals ˇı ´mu programa ´torske ´mu ´ usilı ´. Pozna ´mka (dals ˇı ´ vyleps ˇenı ´) Vy ´sledkem pr ˇedcha ´zejı ´cı ´ho kroku je te ´me ˇˇ r funkc ˇnı ´ SW, ktery ´ je ve ˇts ˇinou moz ˇne ´ jes ˇte ˇ podstatne ˇ vyleps ˇit: * pro kaz ˇdy ´ podprogram je vhodne ´ se podı ´vat, jaky ´m zpu ˚sobem je vola ´n; c ˇasto je vy ´hodne ´ podprogram rozs ˇı ´r ˇit o c ˇinnost, ktera ´ se prova ´dı ´ vz ˇdy pr ˇed a po vola ´nı ´ pr ˇı ´slus ˇne ´ho podprogramu * volajı ´-li se dva nebo vı ´ce podprogramu ˚ vz ˇdy ve stejne ´m por ˇadı ´, je vhodne ´ tyto podprogramy sdruz ˇit vytvor ˇenı ´m dals ˇı ´ho podprogramu * vykona ´va ´-li podprogram ne ˇkolik typu ˚ c ˇinnostı ´, mu ˚z ˇe by ´t vhodne ´ ho rozde ˇlit na podprogramy pro jednotlive ´ c ˇinnosti. [] Vytva ´ˇ renı ´ podprogramu ˚ z pseudoko ´du ---------------------------------* vlastnı ´ ko ´dova ´nı ´ je vysoce individua ´lnı ´ za ´lez ˇitost, obvykle neby ´va ´ podr ˇı ´zeno ne ˇjake ´mu SW procesu * jako pr ˇı ´klad metodiky pro ko ´dova ´nı ´ jednotlivy ´ch podprogramu ˚ uvedu vytva ´r ˇenı ´ podprogramu ˚ z pseudoko ´du (PDL-to-code process, McConnell 1993) - vstupem je podrobny ´ na ´vrh v pseudoko ´du - ten pr ˇevezmeme nebo vytvor ˇı ´me - na za ´klade ˇ pseudoko ´du vytva ´r ˇı ´me ko ´d, z pseudoko ´du se stanou komenta ´r ˇe Vytva ´r ˇenı ´ pseudoko ´du .................... * pseudoko ´d mu ˚z ˇeme zı ´skat napr ˇ. jako vy ´stup strukturovane ´ analy ´zy, napr ˇı ´klad: PROCES 3.2.1: ”Vydej stvrzenku” vytiskni hlavic ˇku stvrzenky celkova ´-hotovost = 0 DO WHILE v tabulce ”penı ´ze” jsou nezpracovane ´ za ´znamy do ”platba” nac ˇti za ´znam z tabulky ”penı ´ze” vytiskni obsah za ´znamu ”platba” k celkove ´ hotovosti ”celkova ´-hotovost” pr ˇic ˇti c ˇa ´stku z ”platba” vytiskni ”celkova ´-hotovost”
107
Za´klady softwarove´ho inzˇeny´rstvı´
108
* pokud nema ´me pseudoko ´d, musı ´me ho navrhnout - postupujeme od obecne ´ho ke konkre ´tnı ´mu - napı ´s ˇeme komenta ´r ˇ popisujı ´cı ´ ´ uc ˇel podprogramu . ove ˇr ˇı ´me, zda je c ˇinnost podprogramu dobr ˇe definova ´na, zda zapada ´ do architektury a zda alespon ˇ nepr ˇı ´mo odpovı ´da ´ poz ˇadavku ˚m . definujeme ´ uc ˇel podprogramu - musı ´ by ´t definova ´n tak podrobne ˇ, aby podprogram bylo moz ˇne ´ implementovat . popı ´s ˇeme vstupy a vy ´stupy (vc ˇetne ˇ globa ´lnı ´ch prome ˇnny ´ch, ktere ´ vytva ´r ˇeny ´ podprogram ovlivnı ´), zpu ˚sob obsluhy chyb - pokud je manipulace s daty podstatnou souc ˇa ´stı ´ c ˇinnosti, navrhneme hlavnı ´ datove ´ struktury - podprogram pojmenujeme - vytvor ˇı ´me vysokou ´rovn ˇovy ´ pseudoko ´d podprogramu . pseudoko ´d nebude pouz ˇı ´vat prvky cı ´love ´ho jazyka, bude popisovat za ´me ˇr - vytvor ˇeny ´ pseudoko ´d zkontrolujeme . kontrola a oprava pseudoko ´du je podstatne ˇ snazs ˇı ´ nez ˇ kontrola a oprava vy ´sledne ´ho programu! * je to ope ˇt iterativnı ´ proces, chyby je tr ˇeba opravovat ihned, jak je naleznete Transformace do ko ´du .................... * pseudoko ´d transformujeme do ko ´du takto: - pseudoko ´d postupne ˇ zjemn ˇujeme az ˇ na ´ uroven ˇ, kdy je snadne ´ doplnit skutec ˇny ´ ko ´d - pseudoko ´d zme ˇnı ´me v komenta ´r ˇe - napı ´s ˇeme deklaraci podprogramu - pod kaz ˇdy ´ komenta ´r ˇ doplnı ´me ko ´d - ko ´d zkontrolujeme, doplnı ´me zby ´vajı ´cı ´ c ˇa ´sti (chybe ˇjı ´cı ´ deklarace prome ˇnny ´ch, os ˇetr ˇenı ´ chyb apod.) * po ”ruc ˇnı ´” kontrole ko ´du podprogram syntakticky zkontrolujeme pr ˇekladem - pr ˇi pr ˇekladu povolı ´me vs ˇechna varova ´nı ´ pr ˇekladac ˇe, pr ˇı ´padna ´ varova ´nı ´ vyr ˇes ˇı ´me
Strukturovane ´ programova ´nı ´ -------------------------* strukturovane ´ programova ´nı ´ = pouz ˇı ´va ´nı ´ r ˇı ´dı ´cı ´ch konstrukcı ´ tak, aby kaz ˇdy ´ blok ko ´du me ˇl pouze jeden vstupnı ´ a jeden vy ´stupnı ´ bod - jednoduche ´, hierarchicke ´ struktury pro r ˇı ´zenı ´ be ˇhu - za ´kladnı ´ r ˇı ´dı ´cı ´ konstrukce: sekvence, ve ˇtvenı ´, iterace * za ´kladnı ´ mys ˇlenka v Dijkstrove ˇ c ˇla ´nku ”Go To Statement Considered Harmful” (1968, viz http://www.acm.org/classics/oct95/ ) - nestrukturovane ´ jazyky typu FORTRAN a BASIC pouz ˇı ´valy r ˇı ´zenı ´ pomocı ´ pr ˇı ´kazu GOTO (pr ˇı ´kaz GOTO spustı ´ prova ´de ˇnı ´ instrukcı ´ od udane ´ho na ´ve ˇs ˇtı ´) - pr ˇı ´klad v jazyce BASIC: 10 20 30 40 50 60 70
A=10 B=5 IF A
- proble ´m: lze vytva ´r ˇet libovolne ˇ komplikovane ´ konstrukce => ze za ´pisu programu s GOTO nenı ´ snadno viditelne ´ dynamicke ´ chova ´nı ´ programu (be ˇh procesu) - r ˇes ˇenı ´: strukturovane ´ programova ´nı ´, pr ˇı ´klad v jazyce Python: a = 10 b = 5
zswi/pAcode.d
zswi/pBcode.d
3. ledna 2005
109
if a < b: print ”A je mens ˇı ´ nez ˇ B\n” else: print ”A je ve ˇts ˇ´ ı nez ˇ B\n” - strukturovane ´ programova ´nı ´ zleps ˇı ´ produktivitu oproti nestrukturovane ´mu az ˇ o 600%, c ˇitelnost ko ´du zleps ˇı ´ o cca 30% - strukturovane ´ programova ´nı ´ podporujı ´ vs ˇechny souc ˇasne ´ procedura ´lnı ´ programovacı ´ jazyky (obsahujı ´ strukturovane ´ r ˇı ´dı ´cı ´ konstrukce typu ”if-then-else”, ”while”, ”repeat-until”, ”for”) * ˇ res ˇenı ´ vy ´jimec ˇny ´ch situacı ´ pouze strukturovany ´mi konstrukcemi mu ˚z ˇe by ´t zbytec ˇne ˇ komplikovane ´ - proto ma ´ ve ˇts ˇina jazyku ˚ vı ´ce zpu ˚sobu ˚ jak opustit r ˇı ´dı ´cı ´ konstrukci (napr ˇ. pr ˇı ´kazy ”continue”, ”break”, ”return”, pr ˇı ´padne ˇ ”goto”) - pouz ˇı ´vat obezr ˇetne ˇ pro r ˇes ˇenı ´ situacı ´, jako je pr ˇedc ˇasne ´ opus ˇte ˇnı ´ vnor ˇeny ´ch cyklu ˚ pr ˇi chybe ˇ Modernı ´ jazyky vycha ´zejı ´ z mys ˇlenek strukturovane ´ho programova ´nı ´, ale posouvajı ´ je da ´le (objekty/tr ˇı ´dy, vy ´jimky, ...).
❉
Za´klady softwarove´ho inzˇeny´rstvı´
110
zswi/pBcode.d
KIV/ZSWI 2004/2005 Pr ˇedna ´s ˇka 11 Prototypova ´nı ´ ============= * na prvnı ´ pr ˇedna ´s ˇce jsem zmin ˇoval dva druhy prototypu ˚: - prototypy, ze ktery ´ch vyvineme konec ˇny ´ syste ´m . vyvineme relativne ˇ jednoduchy ´ syste ´m, implementujı ´cı ´ nejdu ˚lez ˇite ˇjs ˇı ´ poz ˇadavky za ´kaznı ´ka . podle dals ˇı ´ch poz ˇadavku ˚ pr ˇizpu ˚sobujeme . me ˇly by by ´t vyvı ´jeny se stejnou kvalitou jako ostatnı ´ SW - throw-away prototypy - ´ uc ˇelem je zı ´ska ´nı ´ nebo ove ˇr ˇenı ´ poz ˇadavku ˚ apod. . majı ´ kra ´tkou dobu z ˇivota, je tr ˇeba je rychle vytvor ˇit, snadno zme ˇnit V dals ˇı ´m textu se budu zaby ´vat pouze throw-away prototypy, tj. verzemi SW syste ´mu, ktere ´ majı ´ slouz ˇit pro zjis ˇte ˇnı ´ dals ˇı ´ch informacı ´ o syste ´mu nejc ˇaste ˇji v souvislosti se sbe ˇrem poz ˇadavku ˚ nebo v souvislosti s hleda ´nı ´m odpove ˇdı ´ na technicke ´ ota ´zky (vy ´konnost apod.). Tvorba prototypu ˚ by tedy v ra ´mci pr ˇedna ´s ˇek logicky patr ˇila ke sbe ˇru poz ˇadavku ˚, ale z prakticky ´ch du ˚vodu ˚ ji uva ´dı ´m zde. * experimenty ove ˇr ˇily intuitivne ˇ zr ˇejmy ´ pr ˇedpoklad, z ˇe prototypy sniz ˇujı ´ mnoz ˇstvı ´ proble ´mu ˚ se specifikacı ´ poz ˇadavku ˚ (Boehm at al. 1984) * prototypy se vytva ´r ˇejı ´ v na ´sledujı ´cı ´ch krocı ´ch: - definice ´ uc ˇelu prototypu - napr ˇı ´klad prototyp uz ˇivatelske ´ho rozhranı ´, prototyp demonstrujı ´cı ´ uz ˇitec ˇnost syste ´mu za ´kaznı ´kovi apod. - urc ˇenı ´ funkc ˇnosti prototypu - co bude a co nebude prototyp obsahovat . pr ˇi tvorbe ˇ throw-away prototypu obvykle rezignujeme na mimofunkc ˇnı ´ poz ˇadavky, jako je c ˇas odpove ˇdi, pame ˇt’ova ´ na ´roc ˇnost, spolehlivost (omezena ´ kontrola chyb) - vytvor ˇenı ´ prototypu . throw-away prototypy nemusejı ´ by ´t nutne ˇ spustitelne ´; uz ˇitec ˇne ´ (a levne ´) jsou i papı ´rove ´ modely uz ˇivatelske ´ho rozhranı ´ apod. - vyhodnocenı ´ prototypu - nejdu ˚lez ˇite ˇjs ˇ´ ı fa ´ze, zde zı ´ska ´va ´me dı ´ky prototypu potr ˇebne ´ informace . pro otestova ´nı ´ UI je tr ˇeba zvolit typicke ´ho uz ˇivatele syste ´mu Rychle ´ prototypova ´nı ´ -------------------* pro rychle ´ prototypova ´nı ´ (rapid prototyping) se pouz ˇı ´vajı ´ zejme ´na: - dynamicke ´ vysokou ´rovn ˇove ´ programovacı ´ jazyky - databa ´zove ´ jazyky - komponentove ˇ orientovane ´ programova ´nı ´
Vysokou ´rovn ˇove ´ programovacı ´ jazyky ..................................
univerzální programovací jazyky imperativní nízkoúrovňové
deklarativní
vysokoúrovňové
assembler
funkcionální
logické
LISP, Scheme, ML, Haskell Prolog, Mercury...
procedurální
objektově orientované Smalltalk−80, C++, Ada 95, Python, Java, C# ...
nestrukturované
strukturované
BASIC, FORTRAN
Algol, Ada, C, Pascal ...
Programovacı ´ jazyky mu ˚z ˇeme v za ´sade ˇ rozde ˇlit do na ´sledujı ´cı ´ch kategoriı ´: * imperativnı ´ - posloupnost pr ˇı ´kazu ˚ me ˇnı ´ stav programu, jsou odvozeny od von Neumannova modelu poc ˇı ´tac ˇe * funkciona ´lnı ´ - vy ´poc ˇet je zapsa ´n pomocı ´ fcı ´, ktere ´ vracejı ´ hodnotu
zswi/pBcode.d
3. ledna 2005
* logicke ´ - programy jsou vyja ´dr ˇeny pomocı ´ fakt a jejich vztahu ˚ * klasicke ´ procedura ´lnı ´ jazyky jako Pascal, C/C++, Ada, Java atd. - vytva ´r ˇenı ´ spolehlivy ´ch a rychly ´ch programu ˚ - deklarace datovy ´ch typu ˚ => specializace fcı ´, neumoz ˇn ˇuje ”na ´hodnou spolupra ´ci”, nutı ´ programa ´tora prova ´de ˇt explicitnı ´ volby brzy ve vy ´vojove ´m procesu * pro prototypova ´nı ´ se pouz ˇı ´vajı ´ pr ˇedevs ˇı ´m dynamicke ´ vysokou ´rovn ˇove ´ jazyky - obsahujı ´ silne ´ mechanismy pro manipulaci dat, spra ´va pame ˇti v rez ˇii jazyka (tj. programa ´tor nemusı ´ r ˇes ˇit proble ´my pr ˇi alokaci a dealokaci pame ˇti, na rozdı ´l napr ˇ. od C kde programa ´tor musı ´ pame ˇt’ alokovat/uvoln ˇovat explicitne ˇ pomocı ´ malloc() a free()) - dynamicke ´ typova ´nı ´ (typy argumentu ˚ nebo prome ˇnny ´ch se nedeklarujı ´) - pr ˇedpoklad ”je leps ˇı ´ mı ´t 100 fcı ´ pracujı ´cı ´ch nad jednou datovou strukturou nez ˇ mı ´t 10 fcı ´ pracujı ´cı ´ch nad 10 datovy ´mi strukturami” - pr ˇı ´klady jazyku ˚: awk, Javascript, Lisp/Scheme, Haslell, Perl, Prolog, Python, Ruby, Smalltalk, Tcl, Visual Basic... * pr ˇı ´klad c ˇ. 1: Python - objektove ˇ orientovany ´ interpretovany ´ jazyk, moz ˇnost procedura ´lnı ´ho programova ´nı ´ - elegantnı ´ a snadno nauc ˇitelna ´ syntaxe, sdruz ˇova ´nı ´ pr ˇı ´kazu ˚ pomocı ´ odsazova ´nı ´ def spocti(a, b): if a b: return a else: return b - vestave ˇne ´ vysokou ´rovn ˇove ´ typy: seznam, slovnı ´k - knihovny s mnoha tr ˇı ´dami usnadn ˇujı ´cı ´mi programova ´nı ´ (napr ˇ. regula ´rnı ´ vy ´razy, komunikace po internetu, XML, GUI...) - Jython = v Jave ˇ implementovany ´ Python, dovoluje vola ´nı ´ Pythonovske ´ho ko ´du z Javy a naopak (v Jave ˇ implementovana ´ c ˇa ´st ko ´du mu ˚z ˇe volat prototyp vytvor ˇeny ´ v Pythonu) - nevy ´hody pro rea ´lne ´ aplikace: slaba ´ spra ´va pame ˇti, pomaly ´ (cca 3x pomalejs ˇı ´ nez ˇ Java) * pr ˇı ´klad c ˇ. 2: Haskell98 - modernı ´ funkciona ´lnı ´ jazyk, tj. vy ´poc ˇet je prova ´de ˇn vyhodnocova ´nı ´m funkcı ´ - funkce jsou obvykle definova ´ny mnoz ˇinou rovnic - leva ´ strana vy ´razu obsahuje vzory, ktere ´ se porovna ´vajı ´ se skutec ˇny ´mi argumenty - jako pr ˇı ´klad - implementace algoritmu quicksort: qsort [] = [] qsort (x:xs) = qsort less ++ [x] ++ qsort more where less = filter (<x) xs more = filter (>=x) xs * dals ˇı ´ jazyky pro ne ˇktere ´ typy prototypu ˚: - Tcl - c ˇasto prototypova ´nı ´ graficky ´ch aplikacı ´ (Tk toolkit, ktery ´ je dnes ale dostupny ´ i z jazyku ˚ Python, GUILE atd.) . Tcl se ve ˇts ˇinou pouz ˇı ´va ´ jako rozs ˇir ˇovacı ´ jazyk pro aplikace v C nebo C++ . nevy ´hoda: nema ´ dobr ˇe navrz ˇene ´ datove ´ struktury (do verze 8.0 pouze r ˇete ˇzce) - awk a Perl - orientova ´ny pr ˇedevs ˇı ´m na zpracova ´nı ´ textovy ´ch souboru ˚ (vestave ˇne ´ regula ´rnı ´ vy ´razy apod.) . nevy ´hoda: Perl ma ´ problematickou syntaxi - Lisp (Common Lisp, Scheme) - funkciona ´lnı ´ jazyk . hlavnı ´ datovou strukturou je seznam . minima ´lnı ´ syntaxe . c ˇasto se pouz ˇı ´va ´ jako rozs ˇir ˇovacı ´ jazyk aplikacı ´ (AutoLisp pro AutoCAD, GUILE pro volne ˇ s ˇı ´r ˇene ´ programy, elisp pro Emacs) - Prolog - logicke ´ programova ´nı ´, ne ˇkdy simulace databa ´zı ´ * ne ˇkdy se ru ˚zne ´ c ˇa ´sti prototypu vytva ´r ˇejı ´ v ru ˚zny ´ch jazycı ´ch (pro danou c ˇa ´st se volı ´ nejvhodne ˇjs ˇı ´ jazyk)
111
Za´klady softwarove´ho inzˇeny´rstvı´
112
Databa ´zove ´ programova ´nı ´ ....................... * mezi aplikacemi zpracova ´vajı ´cı ´mi data je velka ´ podobnost - pro vstup a vy ´stup obvykle mnoz ˇina formula ´r ˇ˚ u nebo tabulek, zadana ´ data uloz ˇena do databa ´ze - vy ´be ˇr dat z databa ´ze, vytvor ˇenı ´ vy ´stupnı ´ch sestav * proto vznikly specializovane ´ jazyky pro manipulaci s databa ´zı ´, s nimi souvisejı ´cı ´ na ´stroje pro definici UI * pro na ´stroje + prostr ˇedı ´ se pouz ˇı ´va ´ pojem ”jazyky c ˇtvrte ´ generace” (fourth-generation languages, 4GLs) * v 4GL prostr ˇedı ´ typicky: - databa ´zovy ´ dotazovacı ´ jazyk, dnes obvykle SQL . dotazy obvykle vygenerova ´ny automaticky z formula ´r ˇ˚ u vyplne ˇny ´ch uz ˇivatelem - genera ´tor UI . interaktivnı ´ definice formula ´r ˇ˚ u pro vstup nebo zobrazova ´nı ´ dat, jejich propojenı ´, definice dovoleny ´ch rozsahu ˚ vstupnı ´ch hodnot . ve ˇts ˇina dnes ˇnı ´ch 4GL podporuje WWW formula ´r ˇe - genera ´tor vy ´stupnı ´ch sestav . pro definici a vytva ´r ˇenı ´ (tiskovy ´ch) vy ´stupu ˚ z informace obsaz ˇene ´ v databa ´zi * nevy ´hoda: 4GL nejsou zatı ´m nijak standardizovane ´
Komponentove ˇ orientovane ´ prototypova ´nı ´ ...................................... * komponentove ˇ orientovane ´ prototypova ´nı ´ ma ´ obdobne ´ vy ´hody a nevy ´hody jako komponentove ˇ orientovane ´ programova ´nı ´: - nemusı ´me-li ne ˇktere ´ c ˇa ´sti prototypu navrhnout a implementovat, snı ´z ˇı ´me tı ´m c ˇas vy ´voje - na druhou stranu je c ˇasto nutne ´ pr ˇizpu ˚ sobit specifikaci tomu, jake ´ komponenty ma ´me k dispozici * extre ´mnı ´m pr ˇı ´padem je vyuz ˇitı ´ cely ´ch aplikacı ´ jako komponent - prototyp mu ˚z ˇe by ´t realizova ´n napr ˇ. jako objekt sloz ˇene ´ho dokumentu (text, c ˇa ´st tabulky, zvukove ´ soubory), ktere ´ jsou udrz ˇova ´ny ru ˚zny ´mi aplikacemi (editor, spreadsheet, program pro pr ˇehra ´va ´nı ´ zvukovy ´ch souboru ˚) - nejpouz ˇı ´vane ˇjs ˇı ´ mechanismus Microsoft OLE (Object Linking and Embedding) - vy ´hoda: prototyp je vytvor ˇen rychle - nevy ´hoda: pokud uz ˇivatele ´ nemajı ´ zkus ˇenosti s pouz ˇity ´mi aplikacemi, mu ˚z ˇe pro ne ˇ by ´t matoucı ´ funkc ˇnost, ktera ´ pro prototyp nenı ´ zapotr ˇebı ´ * prostr ˇedı ´ pro vytva ´r ˇenı ´ prototypu ˚ obecne ˇ obsahuje: - komponenty - ra ´mec pro sestavova ´nı ´ komponent - poskytuje mechanismus r ˇı ´zenı ´ + mechanismus pro komunikaci . jeden pr ˇı ´klad je prostr ˇedı ´ tzv. skriptovacı ´ch jazyku ˚ (scripting languages), mezi ktere ´ patr ˇı ´ jazyky pr ˇı ´kazovy ´ch interpretu ˚, Python, Tcl apod. . dals ˇı ´m pr ˇı ´kladem jsou obecne ´ ra ´mce pro integraci komponent (CORBA, DCOM, JavaBeans)
Volba programa ´torsky ´ch konvencı ´ =============================== Implementaci by me ˇly pr ˇedcha ´zet minima ´lne ˇ na ´sledujı ´cı ´ kroky: 1. 2. 3. 4. 5.
pochopenı ´ r ˇes ˇene ´ho proble ´mu na ´vrh architektury syste ´mu vy ´be ˇr vhodne ´ho programovacı ´ho jazyka vy ´be ˇr programa ´torske ´ho prostr ˇedı ´, ktere ´ poskytuje vhodne ´ na ´stroje volba programa ´torsky ´ch konvencı ´ (pokud se nejedna ´ o jednora ´zovy ´ program)
Body (1) a (2) uz ˇ byly popsa ´ny v pr ˇedchozı ´ch pr ˇedna ´s ˇka ´ch. Vy ´be ˇr programovacı ´ho jazyka a prostr ˇedı ´ byl zmı ´ne ˇn v souvislosti s prototypova ´nı ´m.
zswi/pBcode.d
zswi/pBcode.d
3. ledna 2005
Proto se budeme jes ˇte ˇ zaby ´vat bodem (5). Motivace -------Jedno ze za ´kladnı ´ch pravidel znı ´: Zdrojovy ´ text programu musı ´ by ´t srozumitelny ´ pro lidi (ostatnı ´ c ˇleny ty ´mu). Jak poznamena ´va ´ Fowler ve sve ´ knı ´z ˇce ”Refactoring”: Any fool can write code that a computer can understand. Good programmers write code that humans can understand. * srozumitelnost du ˚lez ˇita ´ zejme ´na pro ´ udrz ˇbu - co kdyz ˇ je v programu nalezena chyba a pu ˚vodnı ´ programa ´tor nenı ´ k dispozici? * pokud programa ´tor nerozumı ´ cizı ´mu programu, mu ˚z ˇe pro ne ˇj by ´t jednodus ˇs ˇı ´ nesrozumitelny ´ ko ´d napsat znovu nez ˇ ho pr ˇevzı ´t => sniz ˇuje produktivitu Pozna ´mka (ko ´d pis ˇte pro ”pru ˚me ˇrne ´ho programa ´tora”) Pr ˇi c ˇtenı ´ vas ˇeho ko ´du by se me ˇl programa ´tor cı ´tit jako pr ˇi c ˇtenı ´ nejnudne ˇjs ˇı ´ho roma ´nu na sve ˇte ˇ. Funkce kaz ˇde ´ho r ˇa ´dku by me ˇla by ´t zr ˇejma ´. Pokud ko ´d bude ne ˇjak zacha ´zet s prome ˇnnou, me ˇl by si c ˇtena ´r ˇ r ˇı ´ci: ”Mne ˇ bylo pr ˇedem jasne ´, z ˇe ude ˇla ´s ˇ pr ˇesne ˇ tohle!” [] * proble ´m - pokud c ˇtete ko ´d vytvor ˇeny ´ jiny ´mi programa ´tory, je c ˇasto obtı ´z ˇne ˇ srozumitelny ´ kvu ˚li jejich programa ´torske ´mu stylu (forma ´tova ´nı ´ atd.) - programa ´torsky ´ styl (coding style) = soubor pravidel pro psanı ´ zdrojovy ´ch textu ˚, ty ´ka ´ se forma ´tova ´nı ´, tvorby na ´zvu ˚, komenta ´r ˇ˚ u, pr ˇedepsane ´ho chova ´nı ´ SW v urc ˇity ´ch situacı ´ch (napr ˇ. pr ˇi chybe ˇ) atd. - c ˇtenı ´ ko ´du vytvor ˇene ´ho ve stylu, na ktery ´ nejste zvyklı ´, trva ´ vz ˇdy de ´le, nez ˇ pokud styl zna ´te - nespra ´vny ´ c ˇi nekonzistentnı ´ styl => chybna ´ interpretace - proto je styl ko ´du, ktery ´ budou c ˇı ´st dals ˇı ´ lide ´, podstatny ´ => ty ´m nebo ty ´my by se me ˇly shodnout na souboru pravidel pro psanı ´ zdrojovy ´ch textu ˚ sdı ´lene ´m cely ´m projektem . nedokonaly ´ syste ´m je leps ˇı ´ nez ˇ z ˇa ´dny ´ . vza ´jemna ´ srozumitelnost pr ˇedne ˇjs ˇı ´ nez ˇ preference jednoho autora . na druhou stranu existujı ´ studie porovna ´vajı ´cı ´ c ˇitelnost ne ˇktery ´ch stylu ˚ - pozitivnı ´ du ˚sledek jednotne ´ho stylu: ko ´d bude pro vs ˇechny zu ´c ˇastne ˇne ´ c ˇitelne ˇjs ˇı ´ * programa ´torsky ´ styl se ty ´ka ´ pr ˇedevs ˇı ´m - odsazova ´nı ´ bloku ˚ - zalamova ´nı ´ r ˇa ´dku ˚, mezer a za ´vorek - jmenny ´ch konvencı ´ - komenta ´r ˇ˚ u Pozna ´mka (standardnı ´ konvence pro jazyk Java) Pokud je to moz ˇne ´, me ˇl by by ´t jednotny ´ styl ty ´mu zaloz ˇeny ´ na standardnı ´ch konvencı ´ch dane ´ho programovacı ´ho jazyka. Napr ˇ. pro jazyk Java jsou standardnı ´ konvence autoru ˚ jazyka zver ˇejne ˇne ´ na http://java.sun.com/docs/codeconv/ Konvence pro jazyk Java oproti na ´mi uva ´de ˇny ´m oblastem navı ´c pokry ´vajı ´ pojmenova ´nı ´ souboru ˚ a jejich organizaci. []
Odsazova ´nı ´ bloku ˚ ................ * spra ´vne ´ odsazenı ´ musı ´ ukazovat logiku programu - cı ´l: samodokumentujı ´cı ´ ko ´d - du ˚sledky nespra ´vne ´ho c ˇi nekonzistentnı ´ho odsazenı ´: chybna ´ interpretace,
113
Za´klady softwarove´ho inzˇeny´rstvı´
114
obtı ´z ˇne ˇ udrz ˇovatelny ´ ko ´d; napr ˇı ´klad na ´sledujı ´cı ´ ko ´d bude jinak interpretovat c ˇlove ˇk a jinak poc ˇı ´tac ˇ: for (int i = 1; i <= 10; i++) leftboot = left[i]; left[i] = right[i]; right[i] = leftboot; * doporuc ˇuje se psa ´t pouze jeden pr ˇı ´kaz na r ˇa ´dku * odsazova ´nı ´ bloku ˚ tak, aby bylo vide ˇt, ktere ´ pr ˇı ´kazy jsou v bloku - c ˇiste ´ odsazova ´nı ´: lze v Ade ˇ, protoz ˇe kaz ˇda ´ r ˇı ´dı ´cı ´ struktura ma ´ svu ˚j ukonc ˇovac ˇ: zac ˇa ´tek_bloku pr ˇı ´kaz1 pr ˇı ´kaz2 konec_bloku
while Color = Red loop pr ˇı ´kaz1; pr ˇı ´kaz2; end loop;
- simulovane ´ c ˇiste ´ odsazova ´nı ´: jako kdyby ”begin” a ”end” byly souc ˇa ´stı ´ ˇı r ´dı ´cı ´ struktury . styl ”Kernighan & Ritchie” v C . de facto standard v C, C++ a Jave ˇ, v Pascalu se pr ˇı ´lis ˇ nepouz ˇı ´va ´ xxxxxx begin pr ˇı ´kaz1 pr ˇı ´kaz2 end
while (c) { pr ˇı ´kaz1; pr ˇı ´kaz2; }
- begin-end hranice: za hranici bloku povaz ˇujeme ”begin” a ”end” . podle toho zda ”begin” a ”end” povaz ˇujeme za souc ˇa ´st bloku 3 varianty . varianta 1 se pouz ˇı ´va ´ v C i Pascalu, varianta 2 v C (styl GNU), varianta 3 v Pascalu 1. 2. 3. xxxxxx while (!done) while (!done) while not done begin { { begin pr ˇı ´kaz1 pr ˇı ´kaz1; pr ˇı ´kaz1; pr ˇı ´kaz1; pr ˇı ´kaz2 pr ˇı ´kaz2; pr ˇı ´kaz2; pr ˇı ´kaz1; end } } end * forma ´tova ´nı ´ jednopr ˇı ´kazovy ´ch bloku ˚ - me ˇlo by by ´t konzistentnı ´ s forma ´tova ´nı ´m dels ˇı ´ch bloku ˚ - v za ´sade ˇ na ´sledujı ´cı ´ moz ˇnosti, kaz ˇda ´ ma ´ sve ´ vy ´hody i nevy ´hody: 1. if (expr) cmd;
2. if (expr) { cmd; }
3. 4. if (expr) if (expr) cmd; { cmd; } - ve skupinovy ´ch projektech se doporuc ˇuje styl 2, protoz ˇe konzistentnı ´ s odsazova ´nı ´m podle K&R, a pokud budete pr ˇida ´vat pr ˇı ´kazy za if, nemu ˚z ˇete zapomenout pr ˇidat ”{” a ”}” * ne ˇkdy ma ´te potr ˇebu pouz ˇı ´t ”specia ´lnı ´” forma ´tova ´nı ´; te ´me ˇr ˇ vz ˇdy je to pr ˇı ´znak ˇpatne s ˇ navrz ˇene ´ metody/podprogramu nebo rozhranı ´ * napr ˇı ´klad rozhranı ´ pro jazyk C++ pro pra ´ci s Okny: HRESULT hr = Ne ˇjake ´Jme ´noFunkce( 0, // 0, // THIS|THAT|ANOTHER, // BSTR(0), // &something); //
Rezervova ´no, parametr musı ´ by ´t 0 Nede ˇlej ne ˇco divne ´ho Nastav ne ˇjake ´ specia ´lnı ´ pr ˇı ´znaky Rezervova ´no, musı ´ vypadat takhle Objekt, ktery ´ ma ´ by ´t vyplne ˇn hodnotou
- proble ´mem vy ´s ˇe uvedene ´ho rozhranı ´ je pr ˇı ´lis ˇ mnoho parametru ˚ Pozna ´mka pro zajı ´mavost (automaticke ´ forma ´tova ´nı ´) * ne ˇktere ´ ty ´my nechajı ´ programa ´tory pouz ˇı ´vat styl odsazova ´nı ´, jaky ´ kdo chce, a pouz ˇijı ´ napr ˇ. ”indent -kr -i8 -l80” pr ˇed pr ˇida ´nı ´m ko ´du do reposita ´r ˇe
zswi/pBcode.d
zswi/pBcode.d
3. ledna 2005
projektu * automaticke ´ forma ´tova ´nı ´ ale obc ˇas vede k me ´ne ˇ pr ˇehledne ´mu ko ´du, nez ˇ je ko ´d forma ´tovany ´ ruc ˇne ˇ * program indent(1) v Linuxu - forma ´tuje zdrojove ´ texty jazyka C - mezery, odsazenı ´, umı ´ste ˇnı ´ programovy ´ch za ´vorek, komenta ´r ˇe - pr ˇeddefinovane ´ styly: . Kernighan & Ritchie (-kr) . Berkeley (-orig) . GNU (-gnu) - nejdu ˚lez ˇite ˇjs ˇı ´ parametry: -iN ... odsazenı ´ pr ˇı ´kazu ˚ v bloku o N mezer -lN ... de ´lka r ˇa ´dku bude N znaku ˚ -br ... sloz ˇene ´ za ´vorky budou na stejne ´ r ˇa ´dce jako ”if”, ”while” atd. -bli0 -bliN ... sloz ˇene ´ za ´vorky na dals ˇı ´ r ˇa ´dce odsazene ´ o N znaku ˚ -diN ... odsazenı ´ jmen prome ˇnny ´ch od typu v deklaracı ´ch na sloupec N * obdobne ´ programy existujı ´ i pro jine ´ jazyky, napr ˇ. astyle pro C, C++ a Javu, Jalopy pro jazyk Java []
Zalamova ´nı ´ a vkla ´da ´nı ´ pra ´zdny ´ch r ˇa ´dku ˚ ..................................... * ˇ ra ´dek by neme ˇl by ´t dels ˇı ´ nez ˇ je obvykla ´ s ˇı ´r ˇka obrazovky (napr ˇ. 80 znaku ˚ pro znakovy ´ termina ´l) * dlouhe ´ r ˇa ´dky je nutne ´ zalomit na logicke ´m mı ´ste ˇ - souvisejı ´cı ´ ve ˇci ponechat na stejne ´m r ˇa ´dku - na pokrac ˇovacı ´m r ˇa ´dku odsazenı ´ podle ´ urovne ˇ ”vnor ˇenı ´” zalamovane ´ho mı ´sta fd = open(name, O_WRONLY|O_CREAT|O_TRUNC|O_APPEND, S_IRUSR|S_IWUSR|S_IRGRP|S_IROTH); - ne ˇktere ´ konvence doporuc ˇujı ´ zalamovat pr ˇed opera ´torem (napr ˇ. konvence pro jazyk Java, GNU konvence), jine ´ za nı ´m (napr ˇ. Delphi; je tr ˇeba se r ˇı ´dit vybranou konvencı ´) if (queue == NULL && foo_this_is_long && bar > win (x, y, z) && remaining_condition) ... if (queue == NULL && foo_this_is_long && bar > win (x, y, z) && remaining_condition) ... * pra ´zdny ´m r ˇa ´dkem je vhodne ´ od sebe odde ˇlit logicke ´ celky: - jednotlive ´ sekce v programu, podprogramu, tr ˇı ´de ˇ nebo metode ˇ (napr ˇ. loka ´lnı ´ prome ˇnne ´ od prvnı ´ho pr ˇı ´kazu apod.) - skupinu souvisejı ´cı ´ch pr ˇı ´kazu ˚ - jednotlive ´ podprogramy nebo metody - komenta ´r ˇe Pozna ´mka (k de ´lce podprogramu ˚) Jiz ˇ dlouha ´ le ´ta se traduje, z ˇe podprogramy by neme ˇly pr ˇesahovat cca jednu az ˇ dve ˇ obrazovky (cca 50 r ˇa ´dku ˚). Studie vs ˇak proka ´zaly, z ˇe do cca 200 r ˇa ´dek ko ´du samotna ´ de ´lka podprogramu neovlivn ˇuje negativne ˇ chybovost ani srozumitelnost. Podprogram by tedy me ˇl by ´t dlouhy ´ pr ˇesne ˇ tak, jak je zapotr ˇebı ´. []
Pouz ˇı ´va ´nı ´ mezer a za ´vorek ......................... * K&R doporuc ˇujı ´ kolem opera ´toru ˚ obvykle zapsat mezeru, napr ˇ.
115
Za´klady softwarove´ho inzˇeny´rstvı´
116
zswi/pBcode.d
x = x * (y + 1); * uvnitr ˇ vy ´razu ˚ se doporuc ˇuje vkla ´dat za ´vorky a mezery pro leps ˇı ´ srozumitelnost - tedy nikoli: x = a + b % c * d / e; ale napr ˇ.: x = a + (((b % c) * d) / e); nikoli: z = x / 2 + 3 * y; ale napr ˇ.: z = x/2 + 3*y; * za c ˇa ´rkou a str ˇednı ´kem ma ´ na ´sledovat mezera, napr ˇ. foobar (x, y, z);
// nikoli: foobar (x,y,z);
Jmenne ´ konvence ............... * dobre ´ na ´zvy jsou nejdu ˚lez ˇite ˇjs ˇı ´ sloz ˇkou programa ´torske ´ho stylu - pr ˇ´ ıklad chybne ´ho pojmenova ´nı ´: x = x - fee(x1, x) + tt; // co to asi mu ˚z ˇe znamenat? - pr ˇ´ ıklad leps ˇı ´ho pojmenova ´nı ´: kredit = kredit - poplatek(zakaznik, kredit) + urok; * na ´zvy majı ´ doda ´vat ko ´du vy ´znam - z c ˇı ´m ve ˇts ˇı ´ c ˇa ´sti programu je na ´zev viditelny ´, tı ´m pec ˇlive ˇji ho musı ´me zvolit - prome ˇnnou, metodu, tr ˇı ´du atd. bychom me ˇli oznac ˇit srozumitelny ´m na ´zvem, ktery ´ popisuje vy ´znam entity, kterou reprezentuje - napr ˇı ´klad pocetSedadel, pocet_mist_k_stani, jmenoOlympijskehoTymu apod. . vy ´s ˇe uvedene ´ na ´zvy jsou samy o sobe ˇ srozumitelne ´ . ne ˇktera ´ jme ´na jsou ale pr ˇı ´lis ˇ dlouha ´ na to, aby byla prakticka ´ (z vy ´s ˇe uvedeny ´ch poslednı ´ dve ˇ) . vy ´zkum uka ´zal, z ˇe psychologicke ´ optimum je cca 8-20 znaku ˚ - na ´zvy dels ˇı ´ nez ˇ 20 znaku ˚ je vhodne ´ konzistentne ˇ zkra ´tit, napr ˇ. pouz ˇı ´t srozumitelne ´ prefixy/postfixy (jako jsou anglicke ´ Sum, Max, Min, Ptr) * existujı ´ dals ˇı ´ konvence pro pojmenova ´nı ´ r ˇı ´dı ´cı ´ch prome ˇnny ´ch cyklu ˚, logicky ´ch prome ˇnny ´ch, konstant, tr ˇı ´d a metod apod. - r ˇı ´dı ´cı ´ prome ˇnne ´ cyklu ˚ - pokud jsou cykly kra ´tke ´, pouz ˇı ´vajı ´ se c ˇasto jednoznakove ´ na ´zvy jako i, j, k; napr ˇ. v jazyce C: for (i = 0; i < BUFFER_SIZE; i++) ... - pokud je smyc ˇka dels ˇı ´ nez ˇ ne ˇkolik r ˇa ´dek, ma ´ i zde smysl pouz ˇı ´t popisne ´ jme ´no, napr ˇ. v Pascalu: for TeamIndex := 1 to TeamCount do begin for EventIndex := 1 to EventCount [ TeamIndex ] do ... * logicke ´ prome ˇnne ´ - me ˇly by mı ´t pozitivnı ´ jme ´no podmı ´nky - napr ˇ. c ˇesky chyba, konec, nalezeno atd. - nebo anglicky done, error, found, success (pr ˇı ´padne ˇ isDone, isError, isFound, isSuccess) * vy ´c ˇty a pojmenovane ´ konstanty - c ˇasto velky ´mi pı ´smeny, napr ˇ. VELIKOST_BUFFERU nebo BUFFER_SIZE (v C, Jave ˇ), pr ˇı ´padne ˇ ˇEDIT nebo BorderLayout.CENTER (v Jave Okraj.VYSTR ˇ) * doc ˇasne ´ prome ˇnne ´ (temporary variables, c ˇasto na ´zvy ”tmp”, ”tem”) - doc ˇasna ´ prome ˇnna ´ = loka ´lnı ´ prome ˇnna ´, ktera ´ se uvnitr ˇ jednoho podprogramu pouz ˇı ´va ´ postupne ˇ pro ne ˇkolik ru ˚zny ´ch ´ uc ˇelu ˚ - jejich vy ´skyt je c ˇasto varujı ´cı ´ pr ˇı ´znak toho, z ˇe programa ´tor proble ´mu jes ˇte ˇ zcela nerozumı ´ - doc ˇasny ´m prome ˇnny ´m bychom se me ˇli spı ´ˇ se vyhy ´bat, pro kaz ˇdy ´ ´ uc ˇel bychom me ˇli vytvor ˇit samostatnou loka ´lnı ´ prome ˇnnou se smysluplny ´m na ´zvem - krome ˇ zvy ´s ˇenı ´ c ˇitelnosti to usnadnı ´ optimalizaci dobry ´m pr ˇekladac ˇ˚ um * v objektove ˇ orientovany ´ch jazycı ´ch, ktere ´ rozlis ˇujı ´ mala ´ a velka ´ pı ´smena, se c ˇasto pouz ˇı ´va ´ konvence pocha ´zejı ´cı ´ z jazyka Smalltalk: - jme ´no tr ˇı ´dy a jme ´no konstruktoru zac ˇı ´na ´ velky ´m pı ´smenem, napr ˇ. Point, Rectangle, Image, ImagePanel apod.
zswi/pBcode.d
3. ledna 2005
- jme ´no metody, prome ˇnne ´ atd. maly ´m pı ´smenem, napr ˇ. metody addMouseListener(), paintComponent(), prome ˇnne ´ point, rectWidth, imageHeight apod. Pozna ´mka (neforma ´lnı ´ jazykove ˇ za ´visle ´ konvence - C) Pro konkre ´tnı ´ programovacı ´ jazyky vznikly dals ˇı ´ konvence. Pokud budete programovat v jazyce C, brzy zjistı ´te, ˇ ze (az ˇ na vy ´jimky) jsou na ´zvy prome ˇnny ´ch a funkcı ´ tvor ˇeny maly ´mi pı ´smeny a podtrz ˇı ´tkem (”pocet_sedadel”, ”pocet_mist_k_stani” apod.), pro loka ´lnı ´ prome ˇnne ´ se pouz ˇı ´vajı ´ kra ´tke ´ na ´zvy (”c” a ”ch” pro znaky, ”p” pro ukazatel, ”s” pro r ˇete ˇzec) apod. []
Pozna ´mka pro zajı ´mavost (Mad’arska ´ notace pro pojmenova ´nı ´ identifika ´toru ˚) * mad’arska ´ notace - vznik ve firme ˇ Microsoft (Simonyi asi 1984), dnes ˇnı ´ rozs ˇı ´r ˇenı ´ zejme ´na dı ´ky rozhranı ´ MS Windows * viz za ´ve ˇr pozna ´mky (mı ´nusu ˚ je vı ´ce nez ˇ plusu ˚, tj. mad’arskou notaci ˇUJI pouz NEDOPORUC ˇı ´vat, pokud nemusı ´te) * k identifika ´toru pr ˇida ´va ´ prefix popisujı ´cı ´ funkc ˇnı ´ typ identifika ´toru * na ´zev ”mad’arska ´ notace” jednak protoz ˇe identifika ´tor vypada ´ na prvnı ´ pohled nesrozumitelne ˇ a take ´ protoz ˇe Simonyi pocha ´zı ´ z Mad’arska * za ´kladnı ´ mys ˇlenka pojmenovat hodnoty jejich funkc ˇnı ´m typem, aby programa ´tor nemusel na ´zev prome ˇnne ´ a fce dlouho vymy ´s ˇlet - ”funkc ˇnı ´ typ” dvou prome ˇnny ´ch je stejny ´, pokud je nad obe ˇma moz ˇne ´ prove ´st stejne ´ operace (tj. nebere se v ´ uvahu pouze reprezentace, ale take ´ vy ´znam) - napr ˇı ´klad pokud je operace setPosition(x, y) v por ˇa ´dku, zatı ´mco setPosition(y, x) je nesmysl, nemajı ´ ”cela ´ c ˇı ´sla” x a y stejny ´ funkc ˇnı ´ typ - funkc ˇnı ´ typy jsou pojmenova ´ny kra ´tky ´mi indika ´tory, ktere ´ si volı ´ programa ´tor; neme ˇly by to by ´t obecne ´ na ´zvy, protoz ˇe s nimi jsou potı ´z ˇe (napr ˇ. ”color” je obecny ´ na ´zev, ale v aplikaci mu ˚z ˇeme mı ´t vı ´c funkc ˇnı ´ch typu ˚ pro uchova ´va ´nı ´ barev; proto rade ˇji na ´zvy jako ”co”, ”cl”, ”kl” apod.) - napr ˇı ´klad funkc ˇnı ´ typy pro textovy ´ procesor by mohly by ´t: ”wn” (okno), ”row” (r ˇa ´dek textu), ”fon” (font), ”f” (boolovska ´ hodnota flag), ”ch” (znak - character) apod. * ze za ´kladnı ´ch funkc ˇnı ´ch typu ˚ mu ˚z ˇeme konstruovat dals ˇı ´ typy pomocı ´ prefixu ˚ - standardnı ´ prefixy:
prefix a c d e g h i m p
anglicky array count difference element of an array global variable handle index module-level pointer
vy´znam pole pocˇet, naprˇ. pocˇet znaku˚, za´znamu˚ apod. rozdı´l mezi dveˇma promeˇnny´mi stejne´ho typu prvek pole globa´lnı´ promeˇnna´ popisovacˇ, naprˇ. popisovacˇ souboru apod. index do pole promeˇnna´ modulu ukazatel
- napr ˇ. ”arow” = pole prvku ˚ typu ”row” - datove ´ struktury majı ´ vlastnı ´ typy (na ´zev typu by neme ˇl by ´t odvozen z prvku ˚ datove ´ struktury, protoz ˇe reprezentace typu se mu ˚z ˇe snadno zme ˇnit, aniz ˇ by se zme ˇnil jeho vy ´znam) - datove ´ typy jsou pojmenova ´ny stejny ´mi zkratkami jako funkc ˇnı ´ typy, tj. v programu bychom nas ˇli deklarace jako: WN wnMain; ROW rowFirst; * pravidla pro pojmenova ´nı ´ hodnot (prome ˇnny ´ch): funkc ˇnı ´ typ volitelne ˇ na ´sledovany ´ kvalifika ´torem - napr ˇ. v na ´zvu ”rowFirst” je ”row” typ a ”First” je kvalifika ´tor; typ by me ˇl by ´t od kvalifika ´toru vhodny ´m zpu ˚ sobem odde ˇlen, napr ˇ. v C velke ´ pı ´smeno
117
Za´klady softwarove´ho inzˇeny´rstvı´
118
zswi/pBcode.d
- pr ˇı ´klady identifika ´toru ˚ v mad’arske ´ notaci: ch cch ach achInsert echInsert hwn
datova ´ struktura pro znak poc ˇet znaku ˚ pole znaku ˚ pole znaku ˚ pro vloz ˇenı ´ prvek pole znaku ˚ pro vloz ˇenı ´ popisovac ˇ okna (typ ”okno” jsme si pojmenovali ”wn”, viz vy ´s ˇe)
* vy ´hody - standardnı ´ konvence (to je uz ˇitec ˇne ´ samo o sobe ˇ) - snadna ´ tvorba na ´zvu ˚ * nevy ´hody: - hlavnı ´ nevy ´hoda - vytvor ˇena ´ jme ´na nejsou vz ˇdy informativnı ´ (napr ˇ. ”hwn” ner ˇı ´ka ´, o jaky ´ typ okna se jedna ´ - nevı ´m, zda je to hlavnı ´ okno, help, menu apod.) - spojuje vy ´znam dat s jejich reprezentacı ´ - mnoho uz ˇivatelu ˚ mad’arske ´ notace pouz ˇ´ ıva ´ mı ´sto funkc ˇnı ´ch typu ˚ za ´kladnı ´ typy programovacı ´ch jazyku ˚ (int, long apod.) - coz ˇ je zbytec ˇne ´ (pr ˇekladac ˇ za ´kladnı ´ typ dat zna ´) []
Komenta ´r ˇe ......... * dopln ˇujı ´, co v ko ´du nenı ´ vide ˇt (se ´mantika, odkazy, zdroje informacı ´, za ´me ˇr/u ´c ˇel, nestandardnı ´ operace) - komentova ´nı ´ modulu ˚, prome ˇnny ´ch, podprogramu ˚, bloku ˚, r ˇa ´dek ko ´du * komentova ´nı ´ modulu ˚ - kaz ˇdy ´ modul by me ˇl zac ˇı ´nat komenta ´r ˇem, ktery ´ struc ˇne ˇ popı ´s ˇe ´ uc ˇel modulu (pr ˇı ´padne ˇ jine ´ho zdrojove ´ho souboru aplikace) - dals ˇı ´ c ˇa ´st komenta ´r ˇe obvykle popisuje copyright apod. - napr ˇ.: /* farm.c -- obsahuje funkce pro zakla ´da ´nı ´ a rus ˇenı ´ farem. * * Copyright 2003 Luka ´s ˇ Petrlı ´k */ * komentova ´nı ´ deklaracı ´ prome ˇnny ´ch, zejme ´na globa ´lnı ´ch; napr ˇ. wrkstate *worker; farminfo *farm; int nfarms;
/* Seznam obsahujı ´cı ´ stav vs ˇech pracovnı ´ku ˚. */ /* Seznam obsahujı ´cı ´ popis vs ˇech farem. */ /* Celkovy ´ poc ˇet farem spravovany ´ch aplikacı ´. */
* komentova ´nı ´ podprogramu ˚ - c ˇinnost podprogramu - argumenty, vy ´znam hodnot, ktere ´ mohou naby ´vat, ´ uc ˇel argumentu ˚ - vy ´znam pr ˇı ´padne ´ na ´vratove ´ hodnoty * komentova ´nı ´ bloku ˚ ko ´du apod. - komenta ´r ˇ by me ˇl by ´t odsazen stejne ˇ jako komentovany ´ ko ´d - pr ˇed nebo za komenta ´ˇ rem je vhodne ´ vynechat pra ´zdny ´ r ˇa ´dek, abychom komenta ´r ˇ snadno nas ˇli foobar(buff); /* * POSIX.1 specifies that if the O_APPEND flag is set, no intervening * file modification operation is allowed (see POSIX.1:1996, section * 6.4.2.2, lines 226-228). */ write(fd, buff, strlen(buff)); * komenta ´r ˇe nepr ˇeha ´ne ˇt, vysve ˇtlit pr ˇedevs ˇı ´m co a proc ˇ program de ˇla ´
zswi/pBcode.d
3. ledna 2005
Pozna ´mka (na ´stroje pro kontrolu programa ´torsky ´ch konvencı ´) Pro kontrolu programa ´torsky ´ch konvencı ´ existujı ´ na ´stroje. Napr ˇı ´klad pro programy v Jave ˇ existuje na ´stroj Checkstyle, ktery ´ umı ´ kontrolovat vs ˇechny zde uvedene ´ konvence, vc ˇetne ˇ jmenny ´ch konvencı ´. [] Na ´stroje pro dokumentaci: javadoc --------------------------------* javadoc je na ´stroj pro jazyk Java - generuje HTML dokumentaci vc ˇetne ˇ kr ˇı ´z ˇovy ´ch referencı ´ na za ´klade ˇ specia ´lne ˇ forma ´tovany ´ch komenta ´r ˇ˚ u (”doc comments”) - komenta ´r ˇ zac ˇı ´na ´ /** a konc ˇı ´ */ (pokud vı ´ce r ˇa ´dku ˚, mohou zac ˇı ´nat hve ˇzdic ˇkou) - komenta ´r ˇe musı ´ by ´t umı ´ste ˇny pr ˇed dokumentovanou tr ˇı ´dou, metodou apod. - v komenta ´r ˇı ´ch moz ˇno pouz ˇı ´t HTML (krome ˇ H1-H3) - klı ´c ˇova ´ slova pro odkazy apod. na ´ urovni modulu a tr ˇı ´dy * na ´ urovni modulu a tr ˇı ´dy: @author jme ´no @version verze @see Jme ´noTr ˇı ´dy
// bere se v ´ uvahu pouze pokud zada ´n parametr -author // bere se v ´ uvahu pouze pr ˇi zadane ´m parametru -version // generuje ”See Also: Jme ´noTr ˇı ´dy”
* na ´ urovni atributu ˚ a metod @param na ´zev popis @return popis_hodnoty @exception modul.Jme ´noTr ˇı ´dy popis @deprecated na ´hradnı ´_r ˇes ˇenı ´
// // // //
popis parametru popis na ´vratove ´ hodnoty tote ´z ˇ co @throws - generuje ”Throws” lze take ´ na ´ urovni tr ˇı ´dy nebo rozhranı ´
* pr ˇı ´klad: /** * Toto je komenta ´r ˇ pro tr ˇı ´du Hello. * * @author Luka ´s ˇ Petrlı ´k * @version 1.0 (25.4.2003) * @see java.lang.Object */ public class Hello { /** Pr ˇı ´klad komenta ´r ˇe atributu. */ int x = 0; /** Popis metody main. */ public static void main(String[] args) { System.out.println(”Hello World!”); } } * popis javadoc naleznete na http://java.sun.com/products/jdk/javadoc/ * podobne ´ na ´stroje jsou dostupne ´ i pro dals ˇı ´ jazyky nebo jsou jazykove ˇ neza ´visle ´, napr ˇ. na ´stroje Doc++, RoboDoc, atd. - pr ˇehled najdete na http://www.codeassets.com/doc_tools.htm Pozna ´mka (na ´stroj Checkstyle) Vy ´s ˇe zmı ´ne ˇny ´ na ´stroj Checkstyle umı ´ kontrolovat i Javadoc komenta ´r ˇe. [] Optimalizace programu --------------------* program by me ˇl by ´t tak efektivnı ´, jak je od ne ˇj poz ˇadova ´no, nikoli tak, jak je to technicky moz ˇne ´ - pr ˇ´ ılis ˇne ´ zame ˇr ˇenı ´ na vy ´konnost zhors ˇuje c ˇitelnost a udrz ˇovatelnost ko ´du
119
Za´klady softwarove´ho inzˇeny´rstvı´
120
- optimalizace je draha ´ c ˇinnost, tj. je tr ˇeba du ˚kladne ˇ zva ´z ˇit, zda je nutna ´ - pr ˇi optimalizaci je riziko zanesenı ´ chyb do funkc ˇnı ´ho ko ´du * na vy ´konnost se mu ˚z ˇeme zame ˇr ˇit na dvou ´ urovnı ´ch: strategicke ´ a takticke ´ - strategie: . nejde zme ˇnit/vyladit design? . mu ˚z ˇeme pouz ˇı ´t jiny ´ algoritmus, zme ˇnit datove ´ struktury? - taktika - optimalizace ko ´du: . cca 20% programu konzumuje 80% c ˇasu (Boehm 1987, podobne ˇ Bentley 1988) . nutne ´ optimalizovat pouze kriticka ´ mı ´sta programu . kriticka ´ mı ´sta dnes nenı ´ moz ˇne ´ urc ˇit bez me ˇr ˇenı ´, protoz ˇe modernı ´ pr ˇekladac ˇe prova ´de ˇjı ´ pome ˇrne ˇ agresivnı ´ optimalizaci * na ´stroje - profilery - zjis ˇte ˇnı ´ c ˇasu stra ´vene ´ho v jednotlivy ´ch c ˇa ´stech - napr ˇ. volne ˇ s ˇı ´r ˇene ´ na ´stroje gcc a gprof: $ gcc -pg program.c $ ./a.out $ gprof a.out gmon.out
# pr ˇeloz ˇı ´ program.c a vloz ˇı ´ ko ´d pro profilova ´nı ´ # pr ˇeloz ˇeny ´ program spustı ´me, vytva ´r ˇı ´ gmon.out # gprof vypı ´s ˇe statistiky (doby stra ´vene ´ ve fcı ´ch apod.)
* nejc ˇaste ˇjs ˇı ´ zdroje neefektivity: - pr ˇı ´stup k souboru ˚m - podprogramy pro forma ´tovany ´ tisk - operace v pohyblive ´ r ˇa ´dove ´ c ˇa ´rce - stra ´nkova ´nı ´ (bude popsa ´no v pr ˇedme ˇtu KIV/ZOS) - vola ´nı ´ sluz ˇeb operac ˇnı ´ho syste ´mu (takte ´z ˇ viz KIV/ZOS).
❉
zswi/pCtest.d
zswi/pCtest.d
3. ledna 2005
KIV/ZSWI 2004/2005 Pr ˇedna ´s ˇka 12 Verifikace a validace ===================== * verifikace = ove ˇr ˇenı ´, zda produkt dane ´ fa ´ze vy ´voje SW odpovı ´da ´ konceptua ´lnı ´mu modelu (napr ˇ. zda ko ´d odpovı ´da ´ na ´vrhu apod.) - tj. odpove ˇd’ na ota ´zku: vytva ´r ˇı ´m produkt spra ´vne ˇ? * validace = vyhodnocenı ´ SW na konci procesu vy ´voje SW, abychom zajistili splne ˇnı ´ poz ˇadavku ˚ na SW - tj. odpove ˇd’ na ota ´zku: vytva ´r ˇı ´m spra ´vny ´ produkt? Verifikace a validace je s ˇiroke ´ te ´ma, my se budeme zaby ´vat pouze na ´sledujı ´cı ´mi tr ˇemi oblastmi: * automaticka ´ staticka ´ analy ´za - pouz ˇı ´va ´ se nejc ˇaste ˇji pro kontrolu zdrojovy ´ch textu ˚ SW syste ´mu, pr ˇı ´padne ˇ kontrola modelu ˚ apod. * inspekce - ruc ˇnı ´ kontrola artefaktu ˚ SW procesu, typicky prova ´de ˇna ´ skupinou 3 az ˇ 5 lidı ´ * testova ´nı ´ - spous ˇte ˇnı ´ programu s takovy ´mi daty, abychom v programu odhalili defekty Za ´kladnı ´ termı ´ny, ktere ´ budu da ´le pouz ˇı ´vat: * omyl (error) - chybna ´ ´ uvaha nebo pr ˇeklep vy ´voja ´r ˇe, vede k jednomu nebo vı ´ce defektu ˚m * defekt (fault, bug, defect) - rozdı ´l mezi chybny ´m programem a jeho spra ´vnou verzı ´ * symptom (symptom, failure, run-time fault) - pozorovatelne ´ chybne ´ chova ´nı ´ programu; defekt se pr ˇi konkre ´tnı ´m be ˇhu mu ˚z ˇe projevit z ˇa ´dny ´m, jednı ´m nebo vı ´ce symptomy
Automaticka ´ staticka ´ analy ´za ---------------------------* pouz ˇı ´vajı ´ se programy pro automatickou kontrolu modelu ˚ nebo zdrojovy ´ch textu ˚ - napr ˇı ´klad pr ˇekladac ˇ jazyka Java obsahuje silnou typovou kontrolu - pro slabe ˇ typovane ´ jazyky (napr ˇ. C) se pouz ˇı ´vajı ´ staticke ´ analyza ´tory (code checkers) . nejstars ˇı ´ ze zna ´my ´ch staticky ´ch analyza ´toru ˚ je program lint(1), ktery ´ byl souc ˇa ´stı ´ historicky ´ch syste ´mu ˚ UNIX . v souc ˇasnosti se c ˇasto pouz ˇı ´va ´ volne ˇ s ˇı ´r ˇeny ´ lclint(1) . detekuje neinicializovane ´ prome ˇnne ´, odchylky od standardu ˚ apod. . me ˇl by se pouz ˇı ´t vz ˇdy pr ˇed inspekcemi * dals ˇı ´ kontroly - mnoho programu ˚ pouz ˇı ´va ´ pro detekci podezr ˇely ´ch mı ´st heuristiky - nevy ´hoda: pokud zdrojovy ´ text neodpovı ´da ´ heuristika ´m zabudovany ´m v programu, mohou tyto programy produkovat fales ˇna ´ chybova ´ hla ´s ˇenı ´ - pr ˇı ´klad program: Jlint pro jazyk Java Inspekce a procha ´zenı ´ programu ˚ -----------------------------* pouz ˇı ´vajı ´ se pr ˇi pr ˇezkouma ´va ´nı ´ (review) DSP, detailnı ´ho na ´vrhu, ko ´du (inspekce ko ´du se prova ´de ˇjı ´ pr ˇed testova ´nı ´m programu, inspekcı ´m by me ˇla pr ˇedcha ´zet staticka ´ analy ´za) * zahrnujı ´ c ˇtenı ´ dokumentu nebo programu ty ´mem napr ˇ. 3 nebo 4 lidı ´ (jeden z nich autor) s cı ´lem nale ´zt defekty (nikoli jejich r ˇes ˇenı ´) * budu popisovat pro testova ´nı ´ ko ´du, testova ´nı ´ ostatnı ´ch artefaktu ˚ SW procesu je analogicke ´ * vy ´hody: - by ´vajı ´ pome ˇrne ˇ efektivnı ´ (typicky najdou 30% az ˇ 70% defektu ˚ detailnı ´ho na ´vrhu a ko ´dova ´nı ´) - ´ usilı ´ by ´va ´ pr ˇibliz ˇne ˇ polovic ˇnı ´ oproti ekvivalentnı ´mu otestova ´nı ´ na
121
Za´klady softwarove´ho inzˇeny´rstvı´
122
poc ˇı ´tac ˇi (na druhou stranu - pokud ma ´me testy jiz ˇ pr ˇipravene ´, mohou be ˇz ˇet automaticky) - cena opravy defektu by ´va ´ niz ˇs ˇı ´ nez ˇ pr ˇi testova ´nı ´ na poc ˇı ´tac ˇi (protoz ˇe je zna ´ma ´ pr ˇesna ´ pr ˇı ´c ˇina defektu, zatı ´mco testova ´nı ´ na poc ˇı ´tac ˇi najde pouze symptomy) - nale ´za ´ jine ´ typy defektu ˚ nez ˇ klasicke ´ testova ´nı ´, tj. je s nı ´m komplementa ´rnı ´ (je vhodne ´ prova ´de ˇt obojı ´) * nevy ´hody: - pro maxima ´lnı ´ efektivitu je tr ˇeba, aby s nimi ty ´m zı ´skal zkus ˇenost Faganovske ´ inspekce ko ´du ........................ * zahrnujı ´ procedury a techniky pro skupinove ´ c ˇtenı ´ ko ´du (Fagan 1976) * poprve ´ vyuz ˇity ve firme ˇ IBM * ty ´m prova ´de ˇjı ´cı ´ inspekci se obvykle skla ´da ´ ze 4 osob - modera ´tor - jeho ´ ukolem je rozdistribuovat materia ´ly pro schu ˚zku, napla ´novat schu ˚zku, ve ´st jı ´, zaznamena ´vat defekty, zajistit aby byly opraveny . modera ´tor by me ˇl by ´t schopny ´ programa ´tor, ale ne autor programu; nemusı ´ mı ´t detailnı ´ znalosti programu, jehoz ˇ inspekce se prova ´dı ´ - programa ´tor - autor programu - dals ˇı ´mi c ˇleny obvykle na ´vrha ´r ˇ (pokud je odlis ˇny ´ od programa ´tora) a specialista na testova ´nı ´ * pr ˇed schu ˚zkou modera ´tor (napr ˇ. ne ˇkolik dnı ´ pr ˇedem) rozdistribuuje program a specifikaci na ´vrhu programu, ´ uc ˇastnı ´ci se majı ´ s materia ´lem sezna ´mit * inspekce probı ´hajı ´ podle na ´sledujı ´cı ´ho sce ´na ´r ˇe: - optima ´lnı ´ doba inspekce je asi 90 az ˇ 120 min, me ˇla by probı ´hat bez pr ˇerus ˇenı ´ 1. na schu ˚zce je programa ´tor poz ˇa ´da ´n o vysve ˇtlenı ´ logiky programu pr ˇı ´kaz po pr ˇı ´kazu - modera ´tor je zodpove ˇdny ´ za to, z ˇe se ´ uc ˇastnı ´ci zame ˇr ˇı ´ na vyhleda ´va ´nı ´ defektu ˚, nikoli na jejich r ˇes ˇenı ´ - be ˇhem proslovu vznikajı ´ ota ´zky, usilujı ´cı ´ o urc ˇenı ´, zda se v ko ´du nacha ´zejı ´ defekty - zkus ˇenost ukazuje, z ˇe velkou c ˇa ´st defektu ˚ najde programa ´tor be ˇhem vy ´kladu (jiny ´mi slovy: samotne ´ c ˇtenı ´ ko ´du pr ˇed posluchac ˇi je efektivnı ´ technika pro hleda ´nı ´ defektu ˚) 2. program je analyzova ´n vzhledem k seznamu obvykly ´ch programa ´torsky ´ch chyb (seznam se vytva ´r ˇı ´ v pru ˚be ˇhu pr ˇedchozı ´ch inspekcı ´) 3. po skonc ˇenı ´ schu ˚zky dostane programa ´tor seznam defektu ˚ - pokud je nalezeno vı ´ce defektu ˚ nebo pokud ne ˇktery ´ defekt vyz ˇaduje podstatny ´ za ´sah do programu, mu ˚z ˇe se domluvit nova ´ inspekce po oprave ˇ programu - defekty jsou analyzova ´ny a kategorizova ´ny, pouz ˇijeme je pro zpr ˇesne ˇnı ´ seznamu obvykly ´ch programa ´torsky ´ch chyb pouz ˇity ´ch v bode ˇ (2) * pr ˇi ve ˇts ˇine ˇ inspekcı ´ se projde cca 150 pr ˇı ´kazu ˚ za hodinu * krome ˇ nalezenı ´ defektu ˚ je vedlejs ˇı ´m efektem zpe ˇtna ´ vazba ty ´kajı ´cı ´ se programa ´torske ´ho stylu, vy ´be ˇru algoritmu ˚ a programovacı ´ch technik * identifikace c ˇa ´stı ´, ktere ´ obsahujı ´ vı ´ce defektu ˚ - defekty se vyskytujı ´ ve shlucı ´ch, pravde ˇpodobnost existence dals ˇı ´ch defektu ˚ v dane ´ sekci programu (napr ˇ. podprogramu) je pr ˇı ´mo ´ ume ˇrna ´ poc ˇtu defektu ˚ v pr ˇı ´slus ˇne ´ sekci jiz ˇ nalezeny ´ch - pokud jsou v ne ˇktere ´ sekci nalezeny defekty, me ˇli bychom se na nı ´ vı ´ce zame ˇr ˇit, napr ˇ. pr ˇi testova ´nı ´ na poc ˇı ´tac ˇi Pozna ´mka pro zajı ´mavost (Internet Explorer) V souvislosti v vy ´s ˇe uvedeny ´m je zajı ´mave ´ si pr ˇec ˇı ´st na ´sledujı ´cı ´ (cit. z http://www.zive.cz, c ˇla ´nek z 11.2.2004): Podle britske ´ho s ˇe ´fa bezpec ˇnosti spolec ˇnosti Microsoft je Internet Explorer nejbezpec ˇne ˇjs ˇı ´ dostupny ´ internetovy ´ prohlı ´z ˇec ˇ. Toto tvrzenı ´ je zaloz ˇeno na poc ˇtu chyb, ktere ´ jiz ˇ byly odstrane ˇny. K prohla ´s ˇenı ´ dos ˇlo po vyda ´nı ´ bezpec ˇnostnı ´ za ´platy z minule ´ho ponde ˇlı ´, ktera ´ vs ˇak pr ˇinesla proble ´my. ...
zswi/pCtest.d
zswi/pCtest.d
3. ledna 2005
[] * aby inspekce fungovaly, musı ´ k nim mı ´t vs ˇichni ´ uc ˇastnı ´ci spra ´vny ´ pr ˇı ´stup - pokud programa ´tor cha ´pe inspekci jako ´ utok na svou osobu a bra ´nı ´ se, bude inspekce nutne ˇ neefektivnı ´ - naopak funguje, pokud bude cha ´pat jako pomoc ke zleps ˇenı ´ kvality sve ´ho ko ´du Pr ˇı ´klad obvykly ´ch programa ´torsky ´ch chyb (pro jazyk C): * data - je prome ˇnna ´ inicializova ´na? - jsou odkazy do pole v ra ´mci definovany ´ch mezı ´ pole? - nenasta ´va ´ pr ˇi indexova ´nı ´ pole chyba off-by-one? - ukazuje ukazatel na alokovanou pame ˇt’? - pokud c ˇteme za ´znam ze souboru, ma ´ prome ˇnna ´ spra ´vny ´ typ? * chyby vy ´poc ˇtu - jsou v ko ´du vy ´poc ˇty se smı ´s ˇeny ´mi typy (napr ˇ. sc ˇı ´ta ´nı ´ float a int)? . c ˇasto zdrojem chyb - je do krats ˇı ´ hodnoty (napr ˇ. int) pr ˇir ˇazova ´na hodnota s dels ˇı ´ reprezentacı ´? - je moz ˇne ´ pr ˇetec ˇenı ´ nebo podtec ˇenı ´ be ˇhem vy ´poc ˇtu? - mu ˚z ˇe nastat pr ˇı ´pad, z ˇe de ˇlitel je 0? - jake ´ jsou du ˚sledky nepr ˇesnostı ´ rea ´lne ´ aritmetiky? - atd. * * * *
rı ˇ ´zenı ´ toku rozhranı ´ vstup a vy ´stup ostatnı ´
Procha ´zenı ´ ko ´du (walkthroughs) .............................. * podobne ˇ jako inspekce je technika detekce defektu ˚ pomocı ´ skupinove ´ho c ˇtenı ´, v podrobnostech se lis ˇı ´ * schu ˚ zka 3 az ˇ 5 lidı ´, trva ´ 1 az ˇ 2 hodiny, take ´ nema ´ by ´t pr ˇerus ˇena - role modera ´tora - podobna ´ jako v pr ˇı ´pade ˇ inspekcı ´ - sekreta ´r ˇ - zaznamena ´va ´ vs ˇechny nalezene ´ defekty - tester - programa ´tor - autor ko ´du - role ostatnı ´ch c ˇlenu ˚ ty ´mu nenı ´ usta ´lena ´, doporuc ˇuje se napr ˇ. zkus ˇeny ´ programa ´tor, zac ˇı ´najı ´cı ´ programa ´tor (ma ´ zatı ´m nezkaleny ´ pohled), osoba, ktera ´ bude prova ´de ˇt ´ udrz ˇbu apod. * stejne ˇ jako v pr ˇı ´pade ˇ inspekcı ´ by me ˇli dostat materia ´l ne ˇkolik dnı ´ pr ˇedem - c ˇlenove ´ ty ´mu si hrajı ´ na poc ˇı ´tac ˇ: tester pr ˇijde na schu ˚zku s maly ´m poc ˇtem papı ´rovy ´ch testovacı ´ch pr ˇı ´padu ˚ - vstupy a oc ˇeka ´vane ´ vy ´stupy programu nebo podprogramu - ty ´m prova ´dı ´ testovacı ´ pr ˇı ´pad, stav programu (hodnota prome ˇnny ´ch) zaznamena ´va ´ na tabuli nebo na papı ´r - v pr ˇı ´pade ˇ nejasnostı ´ se pta ´ programa ´tora na logiku programu a na pr ˇedpoklady . ve ˇts ˇina defektu ˚ je nalezena ota ´zkami, nikoli testovacı ´mi pr ˇı ´pady - na ´sleduje obdoba bodu 3. z popisu inspekcı ´ - tj. programa ´tor dostane seznam defektu ˚, opravı ´... * podobne ˇ jako v pr ˇı ´pade ˇ inspekcı ´ je podstatny ´ pr ˇı ´stup - ty ´m by me ˇl hodnotit program, nikoli toho, kdo program napsal - na defekty nehlede ˇt jako na neschopnost programa ´tora, ale cha ´pat je jako nutny ´ du ˚sledek doposud nedokonaly ´ch metod programova ´nı ´ Testova ´nı ´ ========= * testova ´nı ´ = spous ˇte ˇnı ´ programu se za ´me ˇrem najı ´t v ne ˇm defekty (tj. snaz ˇı ´me se, aby se projevily symptomy pr ˇı ´padny ´ch defektu ˚)
123
Za´klady softwarove´ho inzˇeny´rstvı´
124
Black box a white box testova ´nı ´ ------------------------------* existujı ´ dva za ´kladnı ´ zpu ˚soby testova ´nı ´ - ”black box” a ”white box” testova ´nı ´ * black box testova ´nı ´ (pouz ˇı ´vajı ´ se take ´ na ´zvy: functional, data-driven, input/output driven testing) - tester na program pohlı ´z ˇı ´ jako na c ˇernou skr ˇı ´n ˇku s danou specifikacı ´, vnitr ˇnı ´ struktura a vnitr ˇnı ´ funkce programu ho nezajı ´majı ´ - hleda ´ pr ˇı ´pady, ve ktery ´ch se program nechova ´ podle specifikace - pro nalezenı ´ vs ˇech defektu ˚ by bylo nutne ´ otestovat program se vs ˇemi moz ˇny ´mi vstupy (platny ´mi i neplatny ´mi), coz ˇ je prakticky nemoz ˇne ´ . napr ˇ. pr ˇekladac ˇ jazyka C bychom museli otestovat se vs ˇemi platny ´mi i neplatny ´mi programy - vı ´me, z ˇe ´ uplne ´ otestova ´nı ´ programu je nemoz ˇne ´ - jak ale maximalizovat poc ˇet defektu ˚ nalezeny ´ konec ˇny ´m poc ˇtem testovacı ´ch pr ˇı ´padu ˚? . k programu uz ˇ nemu ˚z ˇeme pr ˇistupovat c ˇiste ˇ jako k c ˇerne ´ skr ˇı ´n ˇce, ale musı ´me uc ˇinit ne ˇjake ´ rozumne ´ pr ˇedpoklady o jeho vnitr ˇnı ´m chova ´nı ´ * white box testova ´nı ´ (take ´: glass-box, clear-box, logic-driven testing) - testovacı ´ data se odvozujı ´ z programove ´ logiky - pro ´ uplne ´ otestova ´nı ´ programu bychom potr ˇebovali pomocı ´ testovacı ´ch pr ˇı ´padu ˚ otestovat vs ˇechny moz ˇne ´ logicke ´ cesty v programu (analogie otestova ´nı ´ programu se vs ˇemi moz ˇny ´mi vstupy, viz vy ´s ˇe) - ma ´ dva za ´sadnı ´ proble ´my: . poc ˇet logicky ´ch cest je i v maly ´ch programech pr ˇı ´lis ˇ velky ´ - napr ˇı ´klad fragment programu for (i=0; i<100; i++) { if (podmı ´nka) pr ˇı ´kaz1; else pr ˇı ´kaz2; } ma ´ za pr ˇedpokladu neza ´vislosti podmı ´nek 2ˆ100 logicky ´ch cest, ktery ´mi mu ˚z ˇe by ´t vykona ´n (ve skutec ˇnosti podmı ´nky nebudou neza ´visle ´, takz ˇe cest bude me ´ne ˇ) . i po otestova ´nı ´ vs ˇech logicky ´ch cest mohou v programu zu ˚stat nenalezene ´ defekty, protoz ˇe ne ˇktere ´ logicke ´ cesty mohou chybe ˇt a protoz ˇe nemusejı ´ by ´t nalezeny defekty citlive ´ na data, napr ˇ. if ((a - b) < epsilon) ...
// mı ´sto: if (abs(a - b) < epsilon) ...
* pr ˇi black-box i white-box testova ´nı ´ se budou testovacı ´ pr ˇı ´pady skla ´dat z popisu vstupnı ´ch dat a z popisu spra ´vne ´ho vy ´stupu pro dana ´ vstupnı ´ data - program nebo jeho c ˇa ´st spustı ´me se vstupnı ´mi daty, porovna ´me pr ˇedpoklad se skutec ˇny ´m vy ´stupem (nejle ´pe automaticky) - testovacı ´ pr ˇı ´pady majı ´ obsahovat platne ´ i neplatne ´ vstupy - testovacı ´ pr ˇı ´pady je tr ˇeba uchova ´vat, protoz ˇe je mu ˚z ˇete znovu potr ˇebovat (napr ˇ. pro otestova ´nı ´ programu po zme ˇne ˇ) - je nutne ´ take ´ zkontrolovat, zda program neprova ´dı ´ nechte ˇne ´ vedlejs ˇı ´ efekty (za ´pisy do databa ´ze apod.)
Na ´vrh testovacı ´ch pr ˇı ´padu ˚ ------------------------* uz ˇ jsme vide ˇli, z ˇe ´ uplne ´ otestova ´nı ´ programu nenı ´ moz ˇne ´ - proto je pro testova ´nı ´ velmi podstatny ´ na ´vrh efektivnı ´ch testovacı ´ch pr ˇı ´padu ˚ - tj. klademe si ota ´zku - jaka ´ podmnoz ˇina vs ˇech testovacı ´ch pr ˇı ´padu ˚ ma ´ nejve ˇts ˇı ´ pravde ˇpodobnost nale ´zt ve ˇts ˇinu defektu ˚? * prvnı ´ na ´pad - na ´hodne ˇ vybrana ´ podmnoz ˇina vs ˇech moz ˇny ´ch vstupu ˚ - pravde ˇpodobne ˇ jedna z nejhors ˇı ´ch moz ˇnostı ´, protoz ˇe ma ´ malou pravde ˇpodobnost by ´t optima ´lnı ´ podmnoz ˇinou nebo by ´t alespon ˇ blı ´zka ´ optima ´lnı ´ podmnoz ˇine ˇ
zswi/pCtest.d
zswi/pCtest.d
3. ledna 2005
* pouz ˇitelne ´ metody budou kombinacı ´ mys ˇlenek black box a white box testova ´nı ´ - existuje ne ˇkolik metodik, kaz ˇda ´ ma ´ sve ´ silne ´ a slabe ´ stra ´nky - tj. kaz ˇda ´ detekuje/pr ˇehle ´dne jine ´ typy defektu ˚ - proto je dobre ´ pr ˇipravovat testovacı ´ pr ˇı ´pady pomocı ´ vı ´ce metod Rozde ˇlenı ´ vstupu ˚ do ekvivalentnı ´ch tr ˇı ´d ....................................... * dobry ´ testovacı ´ pr ˇı ´pad bude mı ´t dve ˇ vlastnosti: - bude vyvola ´vat co nejvı ´c vstupnı ´ch podmı ´nek, a tı ´m omezı ´ celkovy ´ poc ˇet potr ˇebny ´ch testovacı ´ch pr ˇı ´padu ˚ - testovacı ´ pr ˇı ´pad by me ˇl pokry ´vat urc ˇitou mnoz ˇinu vstupnı ´ch hodnot . mnoz ˇinu vstupu ˚ bychom me ˇli rozde ˇlit do tr ˇı ´d ekvivalence tak, abychom mohli rozumne ˇ pr ˇedpokla ´dat, z ˇe test ne ˇjake ´ reprezentativnı ´ hodnoty v dane ´ tr ˇı ´de ˇ je ekvivalentnı ´ testu ktere ´koli dals ˇı ´ hodnoty
vstupní hodnoty
systém
výstupní hodnoty
třídy ekvivalence
* z te ˇchto ´ uvah je odvozena metodologie pro black-box testova ´nı ´ zna ´ma ´ jako equivalence partitioning = rozde ˇlenı ´ do tr ˇı ´d ekvivalence - nejprve identifikujeme tr ˇı ´dy ekvivalence - pak definujeme testovacı ´ pr ˇı ´pady * identifikace tr ˇı ´d ekvivalence - vezmeme kaz ˇdou vstupnı ´ podmı ´nku (c ˇasto ve ˇtu nebo fra ´zi z DSP) a podle nı ´ rozde ˇlı ´me mnoz ˇinu vs ˇech vstupnı ´ch hodnot do dvou nebo vı ´ce podmnoz ˇin . existujı ´ dva typy tr ˇı ´d ekvivalence - platne ´ (reprezentujı ´cı ´ platne ´ vstupy) a neplatne ´ (reprezentujı ´cı ´ chybne ´ vstupnı ´ hodnoty) - rozde ˇlenı ´ do tr ˇı ´d ekvivalence je heuristicky ´ proces, mu ˚z ˇeme vyuz ˇı ´t na ´sledujı ´cı ´ch doporuc ˇenı ´: . pokud vstupnı ´ podmı ´nka specifikuje interval hodnot (napr ˇ. rok mu ˚z ˇe by ´t mezi 2000 a 2100), pak ma ´me jednu platnou tr ˇı ´du ekvivalence (hodnoty 2000 az ˇ 2100) a dve ˇ neplatne ´ tr ˇı ´dy ekvivalence (hodnoty < 2000, hodnoty > 2100) . pokud vstupnı ´ podmı ´nka specifikuje mnoz ˇinu vstupnı ´ch hodnot a pokud lze pr ˇedpokla ´dat, z ˇe kaz ˇda ´ z nich bude obsluhova ´na jinak (napr ˇ. ”vlak”, ”autobus”), bude jedna platna ´ tr ˇı ´da ekvivalence pro kaz ˇdy ´ prvek mnoz ˇiny; pr ˇida ´me jednu neplatnou tr ˇı ´du ekvivalence pro dals ˇı ´ prvek mnoz ˇiny (napr ˇ. ”letadlo”) . pokud vstupnı ´ podmı ´nka specifikuje situaci, ktera ´ ”musı ´ nastat”, napr ˇ. prvnı ´ znak identifika ´toru musı ´ by ´t pı ´smeno, bude jedna platna ´ tr ˇı ´da ekvivalence (je pı ´smeno) a jedna neplatna ´ tr ˇı ´da ekvivalence (nenı ´ pı ´smeno) . pokud je du ˚vod pr ˇedpokla ´dat, z ˇe prvky ne ˇjake ´ tr ˇı ´dy nejsou obsluhova ´ny stejne ˇ, rozde ˇlte tr ˇı ´du do mens ˇı ´ch tr ˇı ´d ekvivalence * definice testovacı ´ch pr ˇı ´padu ˚ - pro kaz ˇdou neplatnou tr ˇı ´du ekvivalence vytvor ˇı ´me samostatny ´ testovacı ´ pr ˇı ´pad (to je nutne ´, abychom otestovali kaz ˇdou podmı ´nku kontrolujı ´cı ´ neplatny ´ vstup); testovacı ´ pr ˇı ´pady budou typicky obsahovat: . pr ˇı ´lis ˇ ma ´lo dat nebo ˇ za ´dna ´ data . pr ˇı ´lis ˇ mnoho dat . neplatna ´ data (napr ˇ. negativnı ´ poc ˇet zame ˇstnancu ˚) - dokud jsou platne ´ tr ˇı ´dy ekvivalence nepokryte ´ testovacı ´mi pr ˇı ´pady, vytvor ˇı ´me testovacı ´ pr ˇı ´pad pokry ´vajı ´cı ´ co nejvı ´ce platny ´ch tr ˇı ´d ekvivalence; testovacı ´ pr ˇı ´pady budou typicky obsahovat: . nomina ´lnı ´ pr ˇı ´pady = be ˇz ˇne ´ nebo oc ˇeka ´vane ´ hodnoty . minima ´lnı ´ norma ´lnı ´ konfiguraci (napr ˇ. jediny ´ zame ˇstnanec) . maxima ´lnı ´ norma ´lnı ´ konfiguraci (pokud ji umı ´me urc ˇit) * je vy ´hodne ´ testovat hranic ˇnı ´ hodnoty tr ˇı ´d ekvivalence vstupnı ´ch hodnot, - napr ˇı ´klad pokud je platny ´ vstup -1.0 az ˇ +1.0, pak vytvor ˇı ´me testovacı ´ pr ˇı ´pady pro vstupy -1.0, +1.0, -1.0001, +1.0001 - stejne ˇ otestovat hranice vy ´stupnı ´ch hodnot
125
Za´klady softwarove´ho inzˇeny´rstvı´
126
Pr ˇı ´klad (bankomat) Napr ˇı ´klad SW bankomatu bychom mohli otestovat pomocı ´ na ´sledujı ´cı ´ch testovacı ´ch pr ˇı ´padu ˚: 1. 2. 3. 4. 5. 6.
Vadna ´ karta, konec. Platna ´ karta, chybne ´ PIN, konec. Platna ´ karta, platne ´ PIN, konec. Vy ´be ˇr platne ´ c ˇa ´stky, dotaz na zu ˚statek. Vy ´be ˇr neplatne ´ c ˇa ´stky. Neplatny ´ dotaz na zu ˚ statek.
[] White-box testova ´nı ´ ------------------* white-box testova ´nı ´ = vyuz ˇı ´va ´me znalost implementace - obvykle se pouz ˇı ´va ´ pro testova ´nı ´ relativne ˇ maly ´ch c ˇa ´stı ´ programu, jako jsou podprogramy v modulu, metody tr ˇı ´dy - tj. testova ´nı ´ jednotek - pokud jsou moduly integrova ´ny do syste ´mu, sloz ˇitost naru ˚sta ´ tak, z ˇe jsou struktura ´lnı ´ techniky prakticky neproveditelne ´; ne ˇktere ´ proveditelne ´ techniky uvedeme da ´le - se zvys ˇova ´nı ´m rozsahu projektu testy jednotek zabı ´rajı ´ mens ˇı ´ podı ´l na celkove ´m c ˇasu vy ´voje (podle literatury od 35% pro male ´ syste ´my az ˇ po cca 8% pro velke ´ syste ´my) * pokud zna ´me strukturu implementace, mu ˚ˇ zeme pro testova ´nı ´ pouz ˇı ´t ope ˇt tr ˇı ´dy ekvivalence a testovat be ˇz ˇne ´ a hranic ˇnı ´ podmı ´nky se znalostı ´ ko ´du * ilustrovat budu na za ´klade ˇ bina ´rnı ´ho vyhleda ´va ´nı ´ v jazyce Java: class BinSearch { // bina ´rnı ´ vyhleda ´va ´nı ´ // key - klı ´c ˇ // elemArray - ser ˇazene ´ pole prvku ˚, ve ktere ´m se vyhleda ´va ´ // r - vy ´sledek, obsahuje r.index a boolovskou hodnotu // r.found, ktera ´ je true pokud byl klı ´c ˇ v poli public static void search(int key, int elemArray[], Result r) { int bottom = 0; int top = elemArray.length - 1; int mid; r.found = false; r.index = -1; while (bottom <= top) { mid = (top + bottom) / 2; if (elemArray[mid] == key) { r.index = mid; r.found = true; return; } else { if (elemArray[mid] < key) bottom = mid + 1; else top = mid - 1; } // konec ”if” } // konec ”while” } // konec ”search()”
// // // // // // // // // // // // // // //
n1 n2 n3 n4 n5 n6 n7 n8 n9 n10 n11 n12 n13 n14 n15
} // konec ”BinSearch” - z ko ´du mu ˚z ˇeme zjistit, z ˇe bina ´rnı ´ vyhleda ´va ´nı ´ rozde ˇluje vyhleda ´vacı ´ prostor do tr ˇech c ˇa ´stı ´ (prostr ˇednı ´ prvek pole elemArray[mid], zac ˇa ´tek pole, konec pole), kaz ˇda ´ c ˇa ´st tvor ˇı ´ tr ˇı ´du ekvivalence
zswi/pCtest.d
zswi/pCtest.d
3. ledna 2005
hranice jednotlivých tříd ekvivalence elements < mid
elements > mid
střed - pro testova ´nı ´ bychom mohli pouz ˇı ´t napr ˇı ´klad na ´sledujı ´cı ´ testovacı ´ pr ˇı ´pady: vstupnı ´ pole (elemArray) klı ´c ˇ vy ´stup tr ˇı ´da ekvivalence (elemArray) (key) (found, index) (pole, prvek) -------------------------------------------------------------------------17 17 true, 0 jedna hodnota, vy ´skyt v poli 17 0 false, -1 jedna hodnota, nenı ´ v poli 17, 21, 23, 29 17 true, 0 vı ´ce hodnot, prvnı ´ prvek 9, 16, 18, 30, 31, 41, 45 45 true, 6 vı ´ce hodnot, poslednı ´ prvek 17, 18, 21, 23, 29, 38, 41 23 true, 3 vı ´ce hodnot, prostr ˇednı ´ prvek 17, 18, 21, 23, 29, 33, 38 21 true, 2 vı ´ce hodnot, soused prostr ˇednı ´ho 12, 18, 21, 23, 32 23 true, 3 vı ´ce hodnot, soused prostr ˇednı ´ho 21, 23, 29, 33, 38 25 false, -1 vı ´ce hodnot, nenı ´ v poli - testova ´nı ´ bychom provedli vytvor ˇenı ´m ovladac ˇe (napr ˇ. metody s na ´zvem ”test”, pr ˇı ´padne ˇ ”main”), ktery ´ bude volat testovany ´ podprogram nebo metodu - zadane ´ vstupy (pr ˇı ´padne ˇ i vy ´stupy) mohou by ´t zako ´dova ´ny v ovladac ˇi, pr ˇevzaty z pr ˇı ´kazove ´ho r ˇa ´dku, zada ´ny uz ˇivatelem, pr ˇec ˇteny ze souboru apod. - napr ˇı ´klad: public static void main(String[] args) { int[] values = { 21, 23, 29, 33, 38 }; // inicializace Result r = new Result(); search(25, values, r); // vlastnı ´ test if (r.index != -1 || r.found != false) // odpovı ´da ´ pr ˇedpokladu? System.out.println(”Test 8 FAILED”); } * vytva ´r ˇenı ´ testu ˚ si vynucuje dobry ´ na ´vrh - ma ´-li by ´t ko ´d testovatelny ´, je tr ˇeba, aby moduly/tr ˇı ´dy byly volne ˇ va ´zane ´, nevyz ˇadovaly sloz ˇitou inicializaci apod. Pozna ´mka (na ´stroje JUnit a JUnitDoclet) Jako pomu ˚ cka pro testova ´nı ´ se v jazyce Java c ˇasto pouz ˇı ´va ´ knihovna JUnit, ktera ´ poskytuje na ´stroje pro spous ˇte ˇnı ´ testovacı ´ch pr ˇı ´padu ˚ a umı ´ graficky i textove ˇ zobrazit vy ´sledky testu ˚. Dals ˇı ´ pomocny ´ na ´stroj JUnitDoclet (je implementova ´n jako plug-in do na ´stroje JavaDoc) umı ´ vygenerovat kostru testovacı ´ch pr ˇı ´padu ˚ pro JUnit. [] * z ko ´du mu ˚z ˇeme urc ˇit take ´ dals ˇı ´ typ hranic ˇnı ´ podmı ´nky, ktery ´ nasta ´va ´, pokud docha ´zı ´ ke kombinaci vstupnı ´ch hodnot - napr ˇı ´klad pokud podprogram hodnoty na ´sobı ´, testovacı ´ pr ˇı ´pady mohou zahrnovat dve ˇ velka ´ kladna ´ c ˇı ´sla, dve ˇ velka ´ za ´porna ´ c ˇı ´sla apod. Pokrytı ´ ko ´du testovacı ´mi pr ˇı ´pady ................................ * pr ˇi white-box testova ´nı ´ na ´s zajı ´ma ´, do jake ´ mı ´ry testovacı ´ pr ˇı ´pady pokry ´vajı ´ zdrojovy ´ text programu - jak uz ˇ jsme si uvedli, otestovat vs ˇechny cesty v programu je obvykle neproveditelne ´, proto se o to nebudeme pokous ˇet - prakticke ´ metody by me ˇly testovat pouze rozumnou podmnoz ˇinu cest v programu * je dobry ´m krite ´riem alespon ˇ jedno vykona ´nı ´ kaz ˇde ´ho pr ˇı ´kazu? (statement coverage, pokrytı ´ vs ˇech pr ˇı ´kazu ˚)
127
Za´klady softwarove´ho inzˇeny´rstvı´
128
- napr ˇı ´klad me ˇjme pr ˇı ´kaz: if (a>1) and (b=0) then x = x/a; - oba pr ˇı ´kazy (if a pr ˇir ˇazovacı ´ pr ˇı ´kaz) by bylo moz ˇne ´ pokry ´t jediny ´m testovacı ´m pr ˇı ´padem (a=2, b=0) - pr ˇ´ ıklady defektu ˚, ktere ´ by testem zu ˚ staly neodhaleny: mı ´sto ”and” ma ´ by ´t ”or”, mı ´sto ”a>1” ma ´ by ´t ”a>=1” nebo ”a>0” apod. - podmı ´nka pokrytı ´ vs ˇech pr ˇı ´kazu ˚ je nutna ´, ale nikoli postac ˇujı ´cı ´ * krite ´rium pokrytı ´ zesı ´lı ´me - je dobry ´m krite ´riem pokrytı ´ vs ˇech rozhodovacı ´ch pr ˇı ´kazu ˚ tak, aby byly vykona ´ny vs ˇechny jejich ve ˇtve? (branch coverage) - musı ´me vytvor ˇit tolik testovacı ´ch pr ˇı ´padu ˚, aby se v kaz ˇde ´m pr ˇı ´kazu ”if” vykonala alespon ˇ jednou ve ˇtev pr ˇi podmı ´nce ”false” a alespon ˇ jednou ve ˇtev pr ˇi podmı ´nce ”true” atd. . pro sloz ˇite ˇjs ˇı ´ podprogramy se vyplatı ´ modelovat cestu podprogramem pomocı ´ orientovane ´ho grafu, popisujı ´cı ´ho moz ˇny ´ tok r ˇı ´zenı ´ v podprogramu
posloupnost
if
while
do−while
switch
. uzly reprezentujı ´ pr ˇı ´kaz nebo c ˇa ´st pr ˇı ´kazu (pr ˇir ˇazovacı ´ pr ˇı ´kazy, vola ´nı ´ podprogramu ˚, pr ˇı ´padne ˇ podmı ´nky rozhodovacı ´ch pr ˇı ´kazu ˚) . kaz ˇdy ´ pa ´r uzlu ˚, pro ktery ´ je moz ˇny ´ pr ˇenos r ˇı ´zenı ´, je spojen hranou . pr ˇı ´klad - graf toku r ˇı ´zenı ´ pro dr ˇı ´ve uvedeny ´ pr ˇı ´klad na bina ´rnı ´ vyhleda ´va ´nı ´ v Jave ˇ:
n1 n2
bottom > top
n3
while bottom <=top
n4 n5 n6 n7 n8
if (elemArray [mid] == key) if (elemArray [mid] < key)
n10 n11
n13 n15
nf
. neza ´visla ´ cesta = musı ´ procha ´zet alespon ˇ jednu novou hranu v grafu, tj. prove ´st jednu nebo vı ´ce novy ´ch podmı ´nek - kvu ˚li ”patologicky ´m pr ˇı ´padu ˚m” (podprogram neobsahuje rozhodova ´nı ´, ma ´ vı ´ce vstupnı ´ch bodu ˚ apod.) pr ˇipojujeme jes ˇte ˇ podmı ´nku pokrytı ´ vs ˇech pr ˇı ´kazu ˚ - jako krite ´rium by postac ˇovalo, pokud bychom me ˇli vz ˇdy jedinou podmı ´nku v rozhodovacı ´m pr ˇı ´kazu - pro ko ´d ”if (a>1) and (b=0) then x = x/a” je sta ´le jes ˇte ˇ slabe ´ krite ´rium: pokud otestujeme pomocı ´ (a=2, b=0) a (a=2, b=1), neodhaleny by zu ˚staly defekty jako mı ´sto ”a>1” ma ´ by ´t ”a>=1” * rozumny ´m krite ´riem je pokrytı ´ vs ˇech kombinacı ´ podmı ´nek v rozhodovacı ´m pr ˇı ´kazu (multiple condition coverage) - oproti branch coverage navı ´c vyz ˇaduje, aby byly otestova ´ny vs ˇechny kombinace hodnot logicky ´ch operandu ˚ v podmı ´nce - ko ´d ”if (a>1) and (b=0) then x = x/a” mu ˚z ˇeme otestovat c ˇtyr ˇmi testovacı ´mi pr ˇı ´pady: . (a=2, b=0) => obe ˇ podmı ´nky jsou true, ve ˇtev ”then” se provede . (a=2, b=1) => true, false, ve ˇtev ”then” se neprovede . (a=1, b=0) => false, true, ve ˇtev ”then” se neprovede . (a=1, b=1) => false, false, ve ˇtev ”then” se neprovede - testovacı ´ pr ˇı ´pady nenı ´ vhodne ´ generovat strojove ˇ z ko ´du, ale mu ˚z ˇeme si
zswi/pCtest.d
zswi/pCtest.d
3. ledna 2005 pomoci na ´strojem generujı ´cı ´m ”na ´pady na testovacı ´ pr ˇı ´pady” z vy ´razu ˚ (napr ˇ. pro Javu na ´stroj ”multi”)
* dals ˇı ´ obvykle ´ krite ´rium je pokrytı ´ smyc ˇek - vyz ˇaduje 3 testovacı ´ pr ˇı ´pady: - te ˇlo smyc ˇky se nevykona ´, tj. pr ˇi prvnı ´m vyhodnocenı ´ bude test ”false” - te ˇlo smyc ˇky se vykona ´ pra ´ve ˇ jednou, tj. pr ˇi prvnı ´m vyhodnocenı ´ bude test ”true”, pote ´ ”false” - te ˇlo smyc ˇky se vykona ´ vı ´ce nez ˇ jednou, tj. test bude ”true” nejme ´ne ˇ dvakra ´t * dals ˇı ´ moz ˇne ´ krite ´rium - all-du-path - jedna cesta pro kaz ˇdou definici-pouz ˇitı ´: . pokud je prome ˇnna ´ definova ´na v jednom pr ˇı ´kazu a pouz ˇita v jine ´m, cesta by me ˇla procha ´zet obe ˇma pr ˇı ´kazy * pro urc ˇenı ´ pokrytı ´ velky ´ch sad testu ˚ spous ˇte ˇny ´ch na cele ´ syste ´my jsou uz ˇitec ˇne ´ tyto podmı ´nky: - pokrytı ´ podprogramu ˚ - zda byl podprogram vyvola ´n alespon ˇ jednou - pokrytı ´ vola ´nı ´ - zda kaz ˇdy ´ podprogram volal vs ˇechny podprogramy, ktere ´ mu ˚ˇ ze volat * testy prova ´de ˇne ´ bez me ˇr ˇene ´ pokrytı ´ ko ´du typicky pokry ´vajı ´ pouze 55% ko ´du (Grady 1993) - pro zjis ˇte ˇnı ´, ktere ´ cesty byly vykona ´ny, se pouz ˇı ´vajı ´ dynamicke ´ analyza ´tory programu . pr ˇi pr ˇekladu je ke kaz ˇde ´mu pr ˇı ´kazu pr ˇipojen ko ´d, ktery ´ poc ˇı ´ta ´, kolikra ´t byl dany ´ pr ˇı ´kaz vykona ´n (tzv. instrumentace) . po be ˇhu mu ˚z ˇeme zjistit, ktere ´ c ˇa ´sti programu nebyly pokryty pr ˇı ´slus ˇny ´m testovacı ´m pr ˇı ´padem . pr ˇı ´klad na ´stroje: GCT (Generic Coverage Tool) volne ˇ s ˇı ´r ˇeny ´ na ´stroj pro jazyk C, viz ftp://ftp.cs.uiuc.edu/pub/testing/gct.files; pr ˇı ´klad c ˇ´ asti vy ´stupu: ”program.c”, line 9: loop one time: 10, many times: 2.
Strategie testova ´nı ´ ------------------* testova ´nı ´ by me ˇlo by ´t pr ˇedem napla ´nova ´no spolu s cely ´m SW procesem - pro zvy ´s ˇenı ´ efektivity testova ´nı ´ je vhodne ´ prova ´de ˇt take ´ inspekce ko ´du - testova ´nı ´ by me ˇlo zac ˇı ´nat na ´ urovni jednotek (procedur, tr ˇı ´d - funkce kaz ˇde ´ jednotky se ove ˇr ˇı ´ samostatne ˇ) a postupovat sme ˇrem k ve ˇts ˇı ´m celku ˚m (podsyste ´mu ˚m, cele ´mu syste ´mu) - testova ´nı ´ jednotek prova ´dı ´ obvykle ten, kdo danou c ˇa ´st napsal; testova ´nı ´ ve ˇts ˇı ´ch celku ˚ prova ´dı ´ nebo alespon ˇ r ˇı ´dı ´ specialista - tester (rozsa ´hlejs ˇı ´ software testuje neza ´visla ´ testovacı ´ skupina) Pozna ´mka (psychologicky ´ proble ´m testova ´nı ´) Pro ve ˇts ˇinu programa ´toru ˚ je obtı ´z ˇne ´ testovat vlastnı ´ programy, protoz ˇe jejich za ´jem je spı ´s ˇe uka ´zat, z ˇe jejich program neobsahuje defekty a pracuje podle poz ˇadavku ˚ za ´kaznı ´ka. Jiny ´mi slovy, protoz ˇe testova ´nı ´ je destruktivnı ´ proces, pro programa ´tora mu ˚z ˇe by ´t velmi obtı ´z ˇne ´ pr ˇepnout se z ko ´dova ´nı ´ programu (proces konstrukce) na testova ´nı ´ (destrukci). Program take ´ mu ˚z ˇe obsahovat chyby zpu ˚sobene ´ nepochopenı ´m specifikace, ktere ´ programa ´tor nemu ˚z ˇe sa ´m odhalit. Proto je vhodne ´ pr ˇenechat testova ´nı ´ sestavene ´ho programu ne ˇkomu jine ´mu, napr ˇ. neza ´visle ´mu testovacı ´mu ty ´mu. Programa ´tor je vs ˇak vz ˇdycky zodpove ˇdny ´ za otestova ´nı ´ jednotek, ktere ´ vytvor ˇil (procedur, funkcı ´, tr ˇı ´d). [] Testova ´nı ´ me ˇlo probı ´hat postupne ˇ souc ˇasne ˇ s implementacı ´ syste ´mu v na ´sledujı ´cı ´ch krocı ´ch: * testova ´nı ´ jednotek (unit testing) - testujeme nejmens ˇı ´ jednotky na ´vrhu, napr ˇ. procedury nebo funkce; pro testova ´nı ´ mu ˚z ˇeme pouz ˇı ´vat white-box techniky * integrac ˇnı ´ testova ´nı ´ (integration testing) - sestavujeme software, spolu s
129
Za´klady softwarove´ho inzˇeny´rstvı´
130
tı ´m testujeme defekty ty ´kajı ´cı ´ se rozhranı ´ mezi jednotlivy ´mi c ˇa ´stmi * validac ˇnı ´ testova ´nı ´ (validation testing) - po integraci se zame ˇr ˇujeme na funkce viditelne ´ uz ˇivatelem * testova ´nı ´ syste ´mu (system testing) - pokud SW je pouze jednou souc ˇa ´stı ´ ve ˇts ˇı ´ho celku, ´ uc ˇelem je otestovat celek; napr ˇ. za ´te ˇz ˇove ´ testova ´nı ´, zotavenı ´ po za ´vade ˇ apod. Testova ´nı ´ by me ˇlo by ´t pla ´nova ´no v souvislosti s aktivitami konstrukce SW:
požadavky na software předběžný návrh
podrobný návrh
plánování validačních testů plánování integračních testů plánování testů jednotek
validační testování integrační testování
testování jednotek
kódování
Pozna ´mka pro zajı ´mavost (na ´zev ”testova ´nı ´ jednotek”) Na ´zev ”testova ´nı ´ jednotek” (unit testing) pocha ´zı ´ z vy ´roby hardwaru, kde znamena ´ testova ´nı ´ (me ˇr ˇenı ´) jednotlivy ´ch souc ˇa ´stek (jednotek) pr ˇed jejich sestavenı ´m do komponent, ktere ´ se otestujı ´ a sestavı ´ se z nich cely ´ pr ˇı ´stroj, ktery ´ se ope ˇt otestuje. [] Testova ´nı ´ jednotek ------------------
* pojmem ”jednotka” se v pr ˇı ´pade ˇ konvenc ˇne ˇ napsane ´ho SW obvykle myslı ´ procedura, funkce, nebo nejmens ˇı ´ samostatne ˇ pr ˇeloz ˇitelna ´ jednotka zdrojove ´ho textu (c ˇili neexistuje vs ˇeobecne ˇ pr ˇijı ´mana ´ definice) - jednotka se testuje samostatne ˇ, okolnı ´ jednotky jsou nahrazeny ovladac ˇi testu ˚ (r ˇı ´dı ´ testovanou jednotku) nebo testovacı ´mi maketami (nahrazujı ´ jednotky volane ´ z testovane ´ jednotky) - pouz ˇı ´vajı ´ se jiz ˇ probrane ´ white-box techniky * pro objektove ˇ-orientovany ´ software se za jednotku povaz ˇuje tr ˇı ´da - tr ˇı ´dy jako samostatne ´ komponenty jsou obvykle rozsa ´hlejs ˇı ´ nez ˇ samostatne ´ podprogramy * pr ˇi testova ´nı ´ tr ˇı ´dy bychom me ˇli prove ´st: - samostatne ´ otestova ´nı ´ kaz ˇde ´ metody . ne ˇktere ´ metody lze testovat az ˇ po pr ˇedchozı ´m vyvola ´nı ´ jiny ´ch metod, napr ˇ. po inicializaci objektu . pokud pouz ˇı ´va ´me de ˇdic ˇnost, musı ´me testovat i vs ˇechny zde ˇde ˇne ´ operace (mohou obsahovat pr ˇedpoklady o dals ˇı ´ch operacı ´ch a atributech, ktere ´ ale mohly by ´t potomkem zme ˇne ˇny; obdobne ˇ musı ´me znovu otestovat potomky pr ˇi zme ˇne ˇ rodic ˇe) - testovat nastavenı ´ vs ˇech atributu ˚ objektu, dotaz na vs ˇechny atributy - testovat pru ˚chod vs ˇemi stavy objektu, pr ˇı ´padne ˇ simulace vs ˇech uda ´lostı ´, ktere ´ zpu ˚sobujı ´ zme ˇnu stavu objektu . pokud jsme vytvor ˇili stavovy ´ diagram objektu, mu ˚z ˇeme z ne ˇj urc ˇit posloupnost pr ˇechodu ˚ , ktere ´ chceme testovat, a najı ´t posloupnost uda ´lostı ´, ktere ´ ji zpu ˚ sobı ´ Integrac ˇnı ´ testova ´nı ´ -------------------* po otestova ´nı ´ individua ´lnı ´ch komponent musı ´me komponenty integrovat = sestavit do c ˇa ´stec ˇne ´ho nebo ´ uplne ´ho syste ´mu * vy ´sledek musı ´me otestovat na proble ´my, ktere ´ vznikajı ´ interakcı ´ komponent
zswi/pCtest.d
zswi/pDscm.d
3. ledna 2005
131
* ”big bang” (velky ´ tr ˇesk) - po otestova ´nı ´ jednotlivy ´ch modulu ˚ je z nich v jedine ´m kroku sestavena aplikace - pouz ˇitelne ´ pouze pro male ´ programy - pro ve ˇts ˇı ´ syste ´my nejme ´ne ˇ efektivnı ´ zpu ˚sob integrace = vysoka ´ pravde ˇpodobnost neu ´spe ˇchu * hlavnı ´m proble ´mem je lokalizace defektu ˚ , protoz ˇe vztahy mezi komponentami mohou by ´t znac ˇne ˇ sloz ˇite ´ - proto se c ˇasto pro integraci a testova ´nı ´ pouz ˇı ´va ´ inkrementa ´lnı ´ pr ˇı ´stup - nejprve integrujeme minima ´lnı ´ konfiguraci syste ´mu, otestujeme - k syste ´mu pr ˇida ´va ´me inkrementy, po kaz ˇde ´m pr ˇida ´nı ´ syste ´m otestujeme - pokud nastaly proble ´my, budou pravde ˇpodobne ˇ (ale ne nutne ˇ) zpu ˚sobeny pr ˇida ´nı ´m poslednı ´ho inkrementu * ve skutec ˇnosti nebude tak jednoduche ´, protoz ˇe ne ˇktere ´ vlastnosti budou rozpty ´leny do ne ˇkolika komponent, vlastnost mu ˚z ˇeme otestovat az ˇ po integraci te ˇchto komponent => pr ˇi pla ´nova ´nı ´ testu ˚ je tr ˇeba poc ˇı ´tat s c ˇasovy ´m pla ´nem na dokonc ˇenı ´ modulu ˚ * pokud ma ´ du ˚lez ˇity ´ modul neoc ˇeka ´vane ´ proble ´my, mu ˚z ˇe se tı ´m zdrz ˇet cela ´ integrace (programa ´tor r ˇes ˇı ´ proble ´m, zatı ´mco vs ˇichni ostatnı ´ na ne ˇj c ˇekajı ´) Testova ´nı ´ rozhranı ´ .................. * cı ´lem testova ´nı ´ rozhranı ´ je detekovat defekty, ktere ´ mohou vzniknout chybnou interakcı ´ mezi moduly nebo podsyste ´mu nebo chybny ´m pr ˇedpokladem o rozhranı ´ * testova ´nı ´ rozhranı ´ je obtı ´z ˇne ´, protoz ˇe ne ˇktere ´ typy defektu ˚ se projevı ´ pouze za neobvykly ´ch podmı ´nek * uvedu pouze obecna ´ pravidla (volne ˇ podle Sommerville 2001): - v testovane ´m ko ´du najde ˇte vs ˇechna vola ´nı ´ externı ´ch komponent - navrhne ˇte mnoz ˇinu testu ˚ tak, aby externı ´ komponenty byly vola ´ny s parametry, ktere ´ jsou extre ´my jejich rozsahu (napr ˇ. pra ´zdny ´ r ˇete ˇzec, dlouhy ´ r ˇete ˇzec, ktery ´ by mohl zpu ˚sobit pr ˇetec ˇenı ´ apod.) - navrhne ˇte testy, ktere ´ by me ˇly zpu ˚sobit neu ´spe ˇch externı ´ komponenty (zde jsou c ˇasto chybne ´ pr ˇedpoklady) - v syste ´mech s pr ˇeda ´va ´nı ´m zpra ´v pouz ˇijte za ´te ˇz ˇove ´ testova ´nı ´ (viz da ´le) - pokud spolu komponenty komunikujı ´ prostr ˇednictvı ´m databa ´ze, sdı ´lene ´ pame ˇti apod., navrhne ˇte testy, ve ktery ´ch se bude lis ˇit por ˇadı ´ aktivace komponent; testy mohou odhalit implicitnı ´ pr ˇedpoklady programa ´tora o por ˇadı ´, v jake ´m por ˇadı ´ budou sdı ´lena ´ data produkova ´na a konzumova ´na * mnoho defektu ˚ rozhranı ´ odhalı ´ staticke ´ testy - napr ˇ. silna ´ typova ´ kontrola v pr ˇekladac ˇı ´ch jazyka Java - pro slabe ˇ typovane ´ jazyky (napr ˇ. C) by se pr ˇed integrac ˇnı ´m testova ´nı ´m me ˇly pouz ˇı ´t staticke ´ analyza ´tory (code checkers) * ne ˇktere ´ inspekce se mohou zame ˇr ˇit take ´ na rozhranı ´ komponent a jejich pr ˇedpokla ´dane ´ chova ´nı ´ Validac ˇnı ´ testova ´nı ´ ------------------* zac ˇı ´na ´ tam, kde konc ˇı ´ integrac ˇnı ´ testova ´nı ´ * testujeme, zda SW spln ˇuje poz ˇadavky uz ˇivatele * akceptac ˇnı ´ testova ´nı ´ = zadavatel urc ˇı ´, zda produkt spln ˇuje zada ´nı ´ - testuje se na rea ´lny ´ch datech * pro genericke ´ produkty nenı ´ ve ˇts ˇinou moz ˇne ´ vykonat akceptac ˇnı ´ testova ´nı ´ u kaz ˇde ´ho za ´kaznı ´ka, proto alfa a beta testova ´nı ´ - alfa testy: na pracovis ˇti, kde se SW vyvı ´jı ´ (zna ´me ´ prostr ˇedı ´) . testuje uz ˇivatel, vy ´vojovı ´ pracovnı ´ci ho sledujı ´ a zaznamena ´vajı ´ proble ´my - beta testy: testujı ´ vybranı ´ uz ˇivatele ´ ve sve ´m prostr ˇedı ´ (vy ´voja ´r ˇ˚ um nezna ´me ´m) . defekty ohla ´s ˇene ´ uz ˇivateli jsou opraveny => fina ´lnı ´ produkt
❉
Za´klady softwarove´ho inzˇeny´rstvı´
132
zswi/pDscm.d
KIV/ZSWI 2004/2005 Pr ˇedna ´s ˇka 13 Testova ´nı ´ syste ´mu ----------------* ´ uc ˇelem otestovat cely ´ syste ´m, jehoz ˇ je SW souc ˇa ´stı ´ * mı ´vajı ´ ru ˚zny ´ ´ uc ˇel, napr ˇ. otestovat vlastnosti jako je vy ´konnost, kompatibilita, bezpec ˇnost, instalovatelnost, spolehlivost apod. Testova ´nı ´ vy ´konnosti .................... * v mnoha typech syste ´mu ˚ je nepr ˇı ´pustne ´, aby SW nespln ˇoval poz ˇadavky na vy ´konnost (zejme ´na v r ˇı ´dı ´cı ´ch syste ´mech) * v takove ´m pr ˇı ´pade ˇ by se vy ´konnost me ˇla testovat ve vs ˇech krocı ´ch vc ˇetne ˇ jednotkovy ´ch testu ˚ * pomocne ´ procedury monitorujı ´ dobu vykona ´nı ´ apod. Za ´te ˇz ˇove ´ testova ´nı ´ .................. * obvykle se pouz ˇı ´vajı ´ testy, kde se za ´te ˇz ˇ postupne ˇ zvys ˇuje, dokud nenı ´ vy ´konnost syste ´mu neakceptovatelna ´ nebo dokud syste ´m nehavaruje - za ´te ˇz ˇ = mnoz ˇstvı ´ dat, frekvence poz ˇadavku ˚, data, ktera ´ jsou extre ´mne ˇ na ´roc ˇna ´ na zpracova ´nı ´ - je vhodne ´ urc ˇit c ˇa ´sti ko ´du, ktere ´ mohou by ´t problematicke ´ pr ˇi velke ´ za ´te ˇz ˇi, za ´te ˇz ˇove ´ testy navrhnout tak, aby pokry ´valy pr ˇedevs ˇı ´m tyto c ˇa ´sti ko ´du - ove ˇr ˇenı ´, zda hava ´rie syste ´mu nepos ˇkodı ´ data apod. - mu ˚ˇ ze odhalit ne ˇktere ´ defekty, ktere ´ se norma ´lne ˇ neprojevı ´ - du ˚ lez ˇite ´ zejme ´na u internetovy ´ch aplikacı ´, v distribuovany ´ch syste ´mech apod., kde se vysoce zatı ´z ˇene ´ syste ´my mohou zahltit, protoz ˇe si vyme ˇn ˇujı ´ c ˇı ´m da ´l vı ´ce koordinac ˇnı ´ch dat, c ˇı ´mz ˇ se ope ˇt zvys ˇuje za ´te ˇz ˇ syste ´mu atd. Testova ´nı ´ zotavenı ´ syste ´mu po hava ´rii ..................................... * mnoho syste ´mu ˚ se musı ´ by ´t schopno zotavit po hava ´rii v pr ˇedepsane ´m c ˇase, jinak hrozı ´ znac ˇne ´ financ ˇnı ´ ztra ´ty - pr ˇi testova ´nı ´ zotavenı ´ syste ´mu zpu ˚sobujeme ru ˚zne ´ hava ´rie syste ´mu a ove ˇr ˇujeme, zda se syste ´m zotavil spra ´vne ˇ a v c ˇasove ´m limitu Na ´stroje pro testova ´nı ´ SW ------------------------* v rozsa ´hly ´ch syste ´mech mu ˚z ˇe cena testova ´nı ´ dosa ´hnout 50% ceny vy ´voje, mohou existovat stovky az ˇ tisı ´ce testovacı ´ch pr ˇı ´padu ˚ - proto potr ˇeba automatizace testu ˚ - automatizace testu ˚ take ´ sniz ˇuje cenu zme ˇn - programa ´tor ˇi se nemusejı ´ tolik oba ´vat, z ˇe zme ˇnou zanesou do ko ´du defekt, protoz ˇe testy by defekt (s urc ˇitou pravde ˇpodobnostı ´) odhalily - obvykle ´ je na ´sledujı ´cı ´ uspor ˇa ´da ´nı ´:
generátor testovacích dat správce testů testovaný program
specifikace
testovací data
orákulum
skutečné výsledky
predikce výsledků porovnání souborů
generátor sestav
zpráva o výsledcích testů
zswi/pDscm.d
3. ledna 2005
* jednotlive ´ programy majı ´ na ´sledujı ´cı ´ fce: - spra ´vce testu ˚ (test manager) - r ˇı ´dı ´ be ˇh testu ˚ - genera ´tor testovacı ´ch dat (test data generator) - generuje testovacı ´ vstupnı ´ data pro testovany ´ SW - ora ´kulum (oracle) - generuje pr ˇedpokla ´dane ´ vy ´stupnı ´ hodnoty . ora ´kulum lze vyvinout jako novy ´ program (obsahujı ´cı ´ podmnoz ˇinu funkc ˇnosti, co nejme ´ne ˇ pracna ´ implementace) . c ˇasto lze vyuz ˇı ´t prototyp SW, pr ˇedchozı ´ verze SW, SW vytvor ˇeny ´ konkurencı ´ apod. . pokud se jako ora ´kulum pouz ˇı ´va ´ pr ˇedchozı ´ verze SW, pouz ˇı ´va ´ se na ´zev regresivnı ´ testova ´nı ´ (regression tests = porovna ´va ´me vy ´sledky stare ´ a nove ´ verze, rozdı ´ly znamenajı ´ potencia ´lnı ´ proble ´m v nove ´ verzi) - program pro porovna ´nı ´ souboru ˚ (file comparator) - porovna ´ vy ´sledky skutec ˇne ´ho be ˇhu s pr ˇedpokla ´dany ´mi hodnotami vygenerovany ´mi ora ´kulem; c ˇasto lze pouz ˇı ´t univerza ´lnı ´ programy jako cmp(1) a diff(1) v UNIXu apod. - genera ´tor zpra ´v (report generator) - umoz ˇn ˇuje definovat a generovat zpra ´vy o vy ´sledcı ´ch testu ˚ Pozna ´mka (regresivnı ´ vs. progresivnı ´ testova ´nı ´) Proces testova ´nı ´ ma ´ testova ´nı ´ pr ˇida ´va ´ a a jejich rozhranı ´ s du ˚sledky zme ˇn v jiz ˇ
svou progresivnı ´ i regresivnı ´ fa ´zi. Progresivnı ´ fa ´ze testuje nove ´ fce (nove ˇ pr ˇidane ´ nebo modifikovane ´ moduly jiz ˇ integrovany ´mi moduly). Regresivnı ´ fa ´ze testuje integrovany ´ch c ˇa ´stech.
[] * jako jednoduchou uka ´zku uvedu c ˇa ´st pr ˇı ´kazove ´ho souboru pro pr ˇı ´kazovy ´ interpret (shell) v UNIXu, ktery ´ prova ´dı ´ testova ´nı ´ aplikace: test-mkdata > data.test test-oracle < data.test > result1.test aplikace < data.test > result2.test if cmp result1.test result2.test; then echo Test 1: PASSED else echo Test 1: FAILED fi
# # # # #
Vytvor ˇı ´ testovacı ´ data ”data.test”. Ora ´kulum pr ˇedpovı ´ vy ´sledky ”result1.test”. Testujeme aplikaci. Porovna ´me skutec ˇne ´ a pr ˇedpove ˇzene ´ vy ´sledky. Soubory stejne ´ -> test pros ˇel.
# Soubory rozdı ´lne ´ -> test nepros ˇel.
* na ´stroje pro zachycenı ´ a pozde ˇjs ˇı ´ pr ˇehra ´nı ´ testu ˚ (capture-replay tool) - informace prote ´kajı ´ SW syste ´mem - na vhodne ´ mı ´sto toku dat aplikacı ´ vloz ˇı ´me na ´stroj, ktery ´ tekoucı ´ data zaznamena ´ - tester spustı ´/vykona ´ a zaznamena ´ testovacı ´ pr ˇı ´pady - pozde ˇji mu ˚z ˇe zaznamenane ´ testovacı ´ pr ˇı ´pady spustit znovu (regresivnı ´ testova ´nı ´) - existujı ´ komerc ˇnı ´ capture-replay na ´stroje pro zachycenı ´/pr ˇehra ´nı ´ stisku ˚ kla ´ves a pohybu ˚ mys ˇi, obsahujı ´cı ´ i na ´stroje pro zachycenı ´ a porovna ´nı ´ vy ´stupu ˚ na obrazovku - pouz ˇı ´vane ´ pro GUI aplikace . pro ve ˇts ˇinu ostatnı ´ch ´ uc ˇelu ˚ (testova ´nı ´ zapouzdr ˇeny ´ch syste ´mu ˚ apod.) je ve ˇts ˇinou nutne ´ vytvor ˇit si vlastnı ´ SW pro podporu testova ´nı ´ * kolik defektu ˚ lze oc ˇeka ´vat a kolik z nich lze najı ´t testova ´nı ´m? - podle kvality vy ´voje lze oc ˇeka ´vat asi 10 az ˇ 50 defektu ˚ na 1000 r ˇa ´dek ko ´du pr ˇed testova ´nı ´m . napr ˇ. Microsoft Application Division 10-20 defektu ˚/1000 r ˇa ´dek ko ´du (Moore 1992) - testy najdou obvykle me ´ne ˇ nez ˇ 60% defektu ˚, proto je vhodne ´ je kombinovat s inspekcemi - ne ˇkter ˇı ´ autor ˇi uva ´de ˇjı ´, z ˇe defekty jsou c ˇaste ˇji v testovacı ´ch pr ˇı ´padech nez ˇ v testovane ´m ko ´du (McConnell 1993) - pro kriticke ´ syste ´my je vhodne ´ pouz ˇı ´vat kombinaci forma ´lnı ´ch metod vy ´voje, inspekcı ´ a testova ´nı ´ (napr ˇ. pro Cleanroom metodiku v pru ˚me ˇru 2.3 defektu ˚/1000 r ˇa ´dek ko ´du, pro ne ˇktere ´ syste ´my az ˇ 0 defektu ˚)
Pozna ´mka (kvalita SW a rychlost vy ´voje) Ve ˇts ˇina manageru ˚ se snaz ˇı ´ zkra ´tit dobu vy ´voje omezenı ´m c ˇasu ve ˇnovane ´mu inspekcı ´m na ´vrhu a ko ´du, testova ´nı ´ apod. Zejme ´na testova ´nı ´ by ´va ´ c ˇasto
133
Za´klady softwarove´ho inzˇeny´rstvı´
134
zswi/pDscm.d
obe ˇtova ´no, protoz ˇe je na konci vy ´vojove ´ho cyklu (tj. blı ´zko deadline). Podle dostupny ´ch studiı ´ (shrnuty ´ch napr ˇ. v DeMarco a Lister 1987, McConnell 1996 aj.) tento chybny ´ pr ˇı ´stup celkovou dobu vy ´voje naopak prodluz ˇuje. Jiny ´mi slovy, kvalitne ˇjs ˇı ´ produkt bude dr ˇı ´ve dokonc ˇen. Pokud obe ˇtujeme kvalitu, vy ´voj se tı ´m prodlouz ˇı ´ a prodraz ˇı ´. Ve skutec ˇnosti vypada ´ vztah mezi dobou vy ´voje a poc ˇtem defektu ˚ pr ˇibliz ˇne ˇ na ´sledovne ˇ: většina projektů se pohybuje zde nejrychlejší projekty
životně kritické systémy
doba vývoje cca 95%
100%
% defektů odstraněných před uvolněním produktu
[]
Lade ˇnı ´ ====== * testova ´nı ´m nalezneme defekty, na ´sleduje proces lade ˇnı ´ (angl. debugging) * lade ˇnı ´ = identifikace pr ˇı ´c ˇiny defektu (90% c ˇasu) a jejı ´ oprava (10% c ˇasu) * me ˇlo by probı ´hat v 5 krocı ´ch - (1) stabilizace symptomu, (2) nalezenı ´ pr ˇı ´c ˇiny, (3) oprava, (4) otestova ´nı ´ opravy defektu, (5) vyhleda ´nı ´ obdobny ´ch defektu ˚ * stabilizace symptomu - potr ˇebujeme, aby se defekt projevoval spolehlive ˇ - proto nejprve hleda ´me testovacı ´ pr ˇı ´pad, ktery ´ symptom reprodukuje - testovacı ´ pr ˇı ´pad co nejvı ´ce zjednodus ˇı ´me, aby se defekt jes ˇte ˇ projevoval - pr ˇi zjednodus ˇova ´nı ´ testovacı ´ho pr ˇı ´padu c ˇasto jiz ˇ mu ˚z ˇeme vytva ´r ˇet hypote ´zu, proc ˇ defekt nasta ´va ´ - existujı ´ defekty, ktere ´ se neprojevujı ´ spolehlive ˇ, napr ˇı ´klad neinicializovane ´ prome ˇnne ´, neplatny ´ ukazatel, chyby c ˇasove ´ho soube ˇhu . ne ˇktere ´ z te ˇchto defektu ˚ mu ˚z ˇeme zviditelnit; napr ˇı ´klad neinicializovane ´ prome ˇnne ´ - pr ˇed spus ˇte ˇnı ´m programu pame ˇt’ zaplnit na ´hodny ´mi hodnotami apod. . chyby c ˇasove ´ho soube ˇhu lze zviditelnit pomocı ´ vloz ˇenı ´ yield(), pr ˇı ´padne ˇ na ´hodne ´ho prokla ´da ´nı ´ (o chyba ´ch c ˇasove ´ho soube ˇhu - viz pr ˇedme ˇt ZOS) * nalezenı ´ pr ˇı ´c ˇiny symptomu - napr ˇ. hleda ´nı ´ zu ´z ˇenı ´m podezr ˇele ´ c ˇa ´sti ko ´du: systematicky vynecha ´va ´me ko ´d (i na ´ ukor funkc ˇnosti), testujeme zda se symptom jes ˇte ˇ vyskytuje . adaptace metody bina ´rnı ´ho vyhleda ´va ´nı ´ - vynecha ´ se pr ˇibliz ˇne ˇ polovina ko ´du, pokud se symptom projevuje ope ˇt rozde ˇlı ´me na poloviny atd. . vynecha ´va ´nı ´ vola ´nı ´ podprogramu - pouz ˇitı ´ ladı ´cı ´ho programu nebo ladı ´cı ´ch vy ´pisu ˚ - sledujeme, kde nastane symptom . pr ˇeskakujeme ty c ˇa ´sti programu, ktere ´ nejsou relevantnı ´, mu ˚z ˇeme pouz ˇı ´t obdobne ´ metody jako vy ´s ˇe (aniz ˇ bychom vynecha ´vali ko ´d) - ne ˇkdy pomu ˚z ˇe se vyspat (podve ˇdomı ´ pracuje za na ´s) * oprava defektu - pokud jsme defekt nalezli, by ´va ´ jeho oprava pome ˇrne ˇ jednoducha ´, ale je vysoke ´ nebezpec ˇı ´ zanesenı ´ dals ˇı ´ho defektu (podle ne ˇktery ´ch studiı ´ vı ´ce nez ˇ 50%) - podle studie z 1986 majı ´ ve ˇts ˇı ´ s ˇanci prove ´st opravu spra ´vne ˇ programa ´tor ˇi s celkovou znalostı ´ programu (oproti programa ´toru ˚m, kter ˇı ´ se sezna ´mı ´ pouze s opravovanou c ˇa ´stı ´ programu) - proto je pr ˇed opravou tr ˇeba rozume ˇt jak proble ´mu, tak opravovane ´mu programu * opravu je tr ˇeba otestovat - defekty je nutne ´ opravovat po jednom, opravy po jedne ´ otestovat - pote ´ program otestovat jako celek, nejle ´pe regresivnı ´mi testy, aby se uka ´zaly pr ˇı ´padne ´ vedlejs ˇı ´ efekty opravy
zswi/pDscm.d
3. ledna 2005
135
- pro pr ˇı ´pad defektu v oprave ˇ je vhodne ´ mı ´t uchova ´nu pr ˇedchozı ´ verzi (ruc ˇne ˇ, SCM), porovnat obe ˇ verze (napr ˇ. v UNIXu programem diff(1)), z toho je c ˇasto moz ˇne ´ zjistit proble ´m. * hleda ´me obdobne ´ defekty Defenzivnı ´ programova ´nı ´ ----------------------* defenzivnı ´ programova ´nı ´ = zabezpec ˇenı ´ definovane ´ho chova ´nı ´ pr ˇi chybny ´ch vstupech, zamezenı ´ propagace chyb z podprogramu ven * na ´stroje: - kontroly vstupnı ´ch parametru ˚ - makro assert() v C, aserce v Jave ˇ), preconditions/postconditions v Eiffelu (programming by contract) . pokud nejsou, snadno si naprogramujeme jejich ekvivalent, napr ˇ. v Pascalu: procedure Assert(Condition: boolean; Message: string); begin if (not Condition) then begin writeln(’Assertion ’, Message, ’ failed. Aborting the program’); halt; end end; . pouz ˇitı ´ napr ˇ.: Assert(delitel <> 0, ’delitel <> 0’);
(* de ˇlitel nesmı ´ by ´t roven 0 *)
- vy ´jimky v Jave ˇ, C++, Delphi, Pythonu apod. - konstrukce typu try-catch a try-catch-finally: try { foo(); } catch (SomethingWentWrongException e) { System.out.println(”some error”); } finally { dispose(); }
// zde mu ˚z ˇe nastat vy ´jimka // pokud nastane vy ´jimka, // provede se toto // nakonec se vz ˇdy provede // toto
- program mu ˚z ˇe pr ˇi spus ˇte ˇnı ´ ove ˇr ˇovat sve ´ datove ´ struktury, vola ´nı ´ fcı ´ apod. * reakce na chybu - fce vra ´tı ´ specia ´lnı ´ na ´vratovy ´ ko ´d - programova ´ vy ´jimka, zpu ˚sob propagace - podle stanoveny ´ch konvencı ´ - nastavenı ´ defaultnı ´ hodnoty vstupu nebo defaultnı ´ho stavu * o zpu ˚sobu reakce na chybu se by me ˇlo rozhodnout na ´ urovni architektury, aplikace by se me ˇla ve vs ˇech svy ´ch c ˇa ´stech chovat konzistentne ˇ Pozna ´mka (rozdı ´l mezi vy ´vojovou verzı ´ produktu a dodanou verzı ´) Zatı ´mco be ˇhem vy ´voje potr ˇebujeme, aby defekty byly co nejle ´pe viditelne ´, ve vy ´sledne ´m produktu se naopak snaz ˇı ´me, aby defekty co nejme ´ne ˇ rus ˇily. Ve vy ´sledne ´m produktu proto: * ponecha ´va ´me ko ´d, ktery ´ kontroluje vy ´znamne ´ defekty; pokud aplikace hla ´sı ´ internı ´ chybu, me ˇla by take ´ ozna ´mit, jaky ´m zpu ˚sobem jı ´ uz ˇivatel mu ˚z ˇe ohla ´sit * zrus ˇı ´me ko ´d testujı ´cı ´ nepodstatne ´ defekty, * zrus ˇı ´me ko ´d, ktery ´ zpu ˚sobuje hava ´rie * ponecha ´me ko ´d, ktery ´ umoz ˇnı ´ pr ˇijatelne ´ ukonc ˇenı ´ aplikace pr ˇi chybe ˇ (napr ˇ. s uloz ˇenı ´m dat) Rus ˇenı ´ ko ´du neprova ´dı ´me fyzicky (pr ˇi lade ˇnı ´ ho budeme ope ˇt potr ˇebovat), ale napr ˇ. pomocı ´ preprocesoru vynecha ´me te ˇlo procedury Assert, vyuz ˇijeme verzova ´nı ´ apod.
Za´klady softwarove´ho inzˇeny´rstvı´
136
Napr ˇ. v jazyce C definicı ´ makra NDEBUG zme ˇnı ´me vs ˇechny vy ´skyty assert() na pra ´zdny ´ pr ˇı ´kaz. []
´drz U ˇba SW syste ´mu ˚ ================= * ´ udrz ˇba SW = aktivity, ktere ´ jsou prova ´de ˇny po uvolne ˇnı ´ programu, resp. po jeho doda ´nı ´ za ´kaznı ´kovi * ´ udrz ˇba zahrnuje pr ˇedevs ˇı ´m tyto tr ˇi typy aktivit: - oprava chyb SW (corrective maintenance) - pr ˇizpu ˚sobenı ´ SW zme ˇna ´m prostr ˇedı ´, ve ktere ´m be ˇz ˇı ´ - OS, periferie apod. (adaptive maintenance) - pr ˇida ´va ´nı ´ nove ´ funkc ˇnosti nebo zme ˇna funkc ˇnosti na za ´klade ˇ poz ˇadavku ˚ uz ˇivatele (perfective maintenance) * v pru ˚me ˇru cca 17% ´ udrz ˇby se ty ´ka ´ opravy chyb, 18% pr ˇizpu ˚sobenı ´ SW zme ˇna ´m prostr ˇedı ´ a 65% pr ˇida ´va ´nı ´ nebo zme ˇny funkc ˇnosti * ´ udrz ˇba tvor ˇı ´ cca 50% az ˇ 75% vy ´voje, pro obtı ´z ˇne ˇ zme ˇnitelne ´ syste ´my (jako jsou zapouzdr ˇene ´ syste ´my rea ´lne ´ho c ˇasu) az ˇ 80% - studie ukazujı ´, z ˇe cena ´ udrz ˇby syste ´mu postupne ˇ stoupa ´ - proto je efektivnı ´ syste ´m navrhnout a implementovat tak, aby se cena ´ udrz ˇby snı ´z ˇila * proces ´ udrz ˇby je spus ˇte ˇn mnoz ˇinou poz ˇadavku ˚ na zme ˇny od uz ˇivatelu ˚ syste ´mu, managementu nebo od za ´kaznı ´ka - provedeme vyhodnocenı ´ ceny a dopadu zme ˇn - navrz ˇene ´ zme ˇny jsou schva ´leny nebo neschva ´leny; ne ˇktere ´ jsou odloz ˇeny . rozhodnutı ´ o schva ´lenı ´/neschva ´lenı ´ zme ˇn je do urc ˇite ´ mı ´ry ovlivne ˇno udrz ˇovatelnostı ´ komponenty, ve ktere ´ zme ˇnu prova ´dı ´me - zme ˇny jsou implementova ´ny a ove ˇr ˇeny . v idea ´lnı ´m pr ˇı ´pade ˇ: zme ˇna specifikace syste ´mu, na ´vrhu, implementace, otestova ´nı ´ syste ´mu - je doda ´na nova ´ verze * uz ˇ bylo probı ´ra ´no, viz ”Spra ´va poz ˇadavku ˚” na tr ˇetı ´ pr ˇedna ´s ˇce Nestrukturovana ´ ´ udrz ˇba ...................... * vy ´s ˇe uvedene ´ by ovs ˇem platilo v idea ´lnı ´m pr ˇı ´pade ˇ * pracnost a cenu ´ udrz ˇby ve skutec ˇnosti zvys ˇujı ´ tyto faktory: - po doda ´nı ´ produktu je ty ´m obvykle rozpus ˇte ˇn, lide ´ jsou pr ˇir ˇazeni jiny ´m projektu ˚m; ´ udrz ˇba je pr ˇenecha ´na jine ´mu ty ´mu nebo jednotlivcu ˚m, kter ˇı ´ syste ´m neznajı ´ => ve ˇts ˇina jejich ´ usilı ´ musı ´ by ´t ve ˇnova ´na pochopenı ´ existujı ´cı ´ho syste ´mu - smlouva by ´va ´ obvykle pouze na doda ´nı ´ syste ´mu, o ´ udrz ˇbe ˇ se nemluvı ´ => ty ´m nema ´ motivaci vytva ´r ˇet udrz ˇovatelny ´ SW (zvla ´s ˇte ˇ pokud se pr ˇedpokla ´da ´, z ˇe ´ udrz ˇbu bude prova ´de ˇt ne ˇkdo jiny ´) - ´ udrz ˇba je obvykle pr ˇenecha ´na nejme ´ne ˇ zkus ˇeny ´m programa ´toru ˚m, navı ´c syste ´my mohou by ´t vytvor ˇeny v zastaraly ´ch programovacı ´ch jazycı ´ch (Cobol), ktere ´ se ty ´m prova ´de ˇjı ´cı ´ ´ udrz ˇbu musı ´ teprve nauc ˇit - zme ˇnami se sniz ˇuje strukturovanost ko ´du - tı ´m roste ”entropie” SW, dokumentace stary ´ch syste ´mu ˚ mu ˚z ˇe by ´t ztracena nebo mu ˚z ˇe by ´t nekonzistentnı ´ atd. * v mnoha pr ˇı ´padech je jediny ´m dostupny ´m prvkem SW konfigurace zdrojovy ´ text - proto proces ´ udrz ˇby zac ˇı ´na ´ (obtı ´z ˇny ´m) procesem vyhodnocenı ´ ko ´du . ko ´d obsahuje pouze implementaci, nikoli za ´me ˇr => obtı ´z ˇna ´ interpretace . pokud neexistujı ´ testy, nenı ´ moz ˇne ´ regresivnı ´ testova ´nı ´ - takove ´mu pr ˇı ´padu r ˇı ´ka ´me nestrukturovana ´ ´ udrz ˇba (unstructured maintenance), produktivita klesa ´ na 40:1 oproti vy ´voji (podle Boehma) - tomuto stavu se snaz ˇı ´me pr ˇedejı ´t, pokud je to moz ˇne ´ * v za ´sade ˇ dve ˇ moz ˇnosti, jak se k proble ´mu postavit: - pr ˇedpokla ´dat vodopa ´dovy ´ model - syste ´m vyvinout, udrz ˇovat dokud se ´ udrz ˇba stane ekonomicky neu ´nosna ´, pak nahradit novy ´m syste ´mem
zswi/pDscm.d
zswi/pDscm.d
3. ledna 2005
137
- evoluce syste ´mu - pr ˇedpokla ´dat napr ˇ. spira ´lovy ´ model . syste ´m by me ˇl by ´t navrz ˇen tak, aby ho bylo moz ˇne ´ pr ˇizpu ˚sobovat novy ´m poz ˇadavku ˚m . pokud syste ´m nevyhovuje (= nı ´zka ´ udrz ˇovatelnost), musı ´me syste ´m pr ˇepracovat (pr ˇestrukturovat apod.) * udrz ˇovatelnost syste ´mu lze me ˇr ˇit na ´sledujı ´cı ´mi - poc ˇet poz ˇadavku ˚ na opravy chyb . pokud poc ˇet poz ˇadavku ˚ na opravy stoupa ´, mu ˚z ˇe je procesem ´ udrz ˇby vna ´s ˇeno vı ´ce chyb, nez ˇ je tj. indikuje snı ´z ˇenı ´ udrz ˇovatelnosti - pru ˚ me ˇrna ´ doba potr ˇebna ´ pro vyhodnocenı ´ dopadu . odra ´z ˇı ´ rozsah (napr ˇ. poc ˇet komponent), ktere ´ zme ˇnu . pokud naroste, udrz ˇovatelnost se sniz ˇuje - pru ˚ me ˇrna ´ doba implementace poz ˇadavku na zme ˇnu - poc ˇet nevyr ˇı ´zeny ´ch poz ˇadavku ˚ na zme ˇnu
metrikami: to znamenat, z ˇe do programu jich odstran ˇova ´no ´ udrz ˇbou, zme ˇny jsou ovlivne ˇny poz ˇadavkem na
* pokud je program s ˇpatne ˇ udrz ˇovatelny ´, jsou moz ˇne ´ na ´sledujı ´cı ´ kroky pro zleps ˇenı ´: - konverze SW do modernı ´ho programovacı ´ho jazyka (nebo do moderne ˇjs ˇı ´ varianty pouz ˇite ´ho programovacı ´ho jazyka); napr ˇı ´klad z Fortranu do jazyka Java nebo C# - zpe ˇtne ´ inz ˇeny ´rstvı ´ = analy ´za programu s cı ´lem najı ´t specifikaci a na ´vrh SW . obvykle na za ´klade ˇ zdrojovy ´ch textu ˚, v ne ˇktery ´ch pr ˇı ´padech jsou ztraceny a je nutne ´ vycha ´zet ze spustitelne ´ho ko ´du - vyleps ˇenı ´ struktury programu s cı ´lem zleps ˇit jeho srozumitelnost . pro automatickou transformaci nestrukturovane ´ho ko ´du na strukturovany ´ existujı ´ na ´stroje (pr ˇi transformaci ale ztratı ´me pu ˚vodnı ´ komenta ´r ˇe) - modularizace programu = sdruz ˇenı ´ souvisejı ´cı ´ch c ˇa ´stı ´ programu, v ne ˇktery ´ch pr ˇ´ ıpadech vc ˇetne ˇ transformace architektury SW . stejna ´ motivace jako pr ˇi vytva ´r ˇenı ´ modulu ˚ pr ˇi vy ´voji, tj. abstrakce dat, abstrakce r ˇı ´zenı ´ HW, sdruz ˇenı ´ pr ˇı ´buzny ´ch fcı ´ - pr ˇizpu ˚sobenı ´ zpracova ´vany ´ch dat zme ˇne ˇne ´mu programu O postupech pr ˇi pr ˇepracova ´va ´nı ´ existujı ´cı ´ch syste ´mu ˚ hovor ˇı ´ kniha Martina Fowlera ”Refactoring: Zleps ˇenı ´ existujı ´cı ´ho ko ´du. Grada, Praha 2003.” Metriky ======= * metrika (metrics) = jake ´koli me ˇr ˇenı ´ atributu ˚ SW produktu nebo SW procesu - napr ˇ. poc ˇet r ˇa ´dku ˚ ko ´du, poc ˇet defektu ˚ , defekty na 1000 r ˇa ´dek ko ´du apod. - jsou potr ˇebne ´, abyste ve ˇde ˇli, co se s projektem opravdu de ˇje, pro zleps ˇova ´nı ´ SW nebo SW procesu, pro odhady o budoucı ´ch projektech, pro informaci, kam zame ˇr ˇit testova ´nı ´ atd. - napr ˇ. pr ˇed zavedenı ´m testovacı ´ho na ´stroje mu ˚z ˇeme zme ˇr ˇit poc ˇet defektu ˚ nalezeny ´ch za c ˇasovou jednotku, tote ´z ˇ po zavedenı ´ na ´stroje - jiny ´ pr ˇı ´klad - nejvı ´ce defektu ˚ by ´va ´ v procedura ´ch/metoda ´ch s vysokou cyklomatickou sloz ˇitostı ´ - tam bychom me ˇli zame ˇr ˇit sve ´ ´ usilı ´ pr ˇi testova ´nı ´ * nejdu ˚lez ˇite ˇjs ˇı ´ metriky se ty ´kajı ´ na ´sledujı ´cı ´ch oblastı ´: - metriky analyticke ´ho modelu (napr ˇ. kvalita specifikace) - metriky na ´vrhu (napr ˇ. sloz ˇitost komponent) - metriky zdrojovy ´ch textu ˚ (napr ˇ. nı ´z ˇe uvedene ´ LOC a cyklomaticka ´ sloz ˇitost) - metriky pro testova ´nı ´ (napr ˇ. pokrytı ´ logiky programu, efektivita testova ´nı ´) * nejjednodus ˇs ˇı ´ a nejc ˇaste ˇjs ˇı ´ metrika zdrojovy ´ch textu ˚ - poc ˇet r ˇa ´dek ko ´du (Lines of Code, LOC) - ota ´zka - co ma ´me poc ˇı ´tat jako r ˇa ´dek ko ´du? - pokud se snaz ˇı ´me me ˇr ˇit mnoz ˇstvı ´ pra ´ce do programu vloz ˇene ´, nebudeme zapoc ˇı ´ta ´vat komenta ´r ˇe, pra ´zdne ´ r ˇa ´dky a automaticky generovany ´ ko ´d - ne ˇkdy se nazy ´va ´ NCLOC (Non-comment LOC) nebo ELOC (Effective LOC) - je za ´klad metodiky COCOMO pro odhad ceny SW * McCabeho metrika ”cyklomaticka ´ sloz ˇitost” poc ˇı ´ta ´ rozhodovacı ´ body v podprogramu - vysoka ´ cyklomaticka ´ sloz ˇitost ma ´ korelaci s chybovostı ´, s obtı ´z ˇnostı ´ c ˇı ´st a testovat podprogram (jak uz ˇ bylo ˇ rec ˇeno, prosta ´ de ´lka podprogramu
Za´klady softwarove´ho inzˇeny´rstvı´
138
nema ´ korelaci s chybovostı ´) - cyklomatickou sloz ˇitost spoc ˇteme na ´sledovne ˇ: 1. Pro pr ˇı ´mou cestu podprogramem zapoc ˇteme 1. 2. Pro kaz ˇde ´ z na ´sledujı ´cı ´ch klı ´c ˇovy ´ch slov nebo jejich ekvivalentu ˚ pr ˇic ˇteme jednic ˇku: if, while, do-while, for, a pro ”and a ”or” ve sloz ˇeny ´ch podmı ´nka ´ch. 3. Pro kaz ˇdy ´ pr ˇı ´pad v switch/case pr ˇic ˇteme 1. - pokud je >10, je pr ˇı ´znak, z ˇe je vhodne ´ podprogram zjednodus ˇit (napr ˇ. c ˇa ´st podprogramu vloz ˇit do dals ˇı ´ho podprogramu volane ´ho z pu ˚vodnı ´ho) Pozna ´mka pro zajı ´mavost (cyklomaticka ´ sloz ˇitost a graf toku r ˇı ´zenı ´) Pokud v rozhodovacı ´ch pr ˇı ´kazech nejsou sloz ˇene ´ podmı ´nky, odpovı ´da ´ cyklomaticka ´ sloz ˇitost poc ˇtu regionu ˚ v grafu toku r ˇı ´zenı ´ podprogramu. Pojmem region se myslı ´ oblast ohranic ˇena ´ hranami a uzly grafu; oblast mimo graf se poc ˇı ´ta ´ jako samostatny ´ region. Jako pr ˇı ´klad uva ´dı ´m graf toku r ˇı ´zenı ´ pro pr ˇı ´klad bina ´rnı ´ho vyhleda ´va ´nı ´, uvedeny ´ na minule ´ pr ˇedna ´s ˇce:
R1 while
n3
R2
R3 if n5 if n10
R4
Pro kontrolu si mu ˚z ˇeme spoc ˇı ´st cyklomatickou sloz ˇitost pomocı ´ vy ´s ˇe uvedene ´ metody: zapoc ˇteme pr ˇı ´mou cestu, while, if a if, tj. vy ´sledek je ope ˇt 4. [] Ne ˇktere ´ uz ˇitec ˇne ´ metriky ........................ * velikost zdrojovy ´ch textu ˚ - celkovy ´ poc ˇet r ˇa ´dek (LOC) - celkovy ´ poc ˇet komenta ´r ˇovy ´ch r ˇa ´dek (CLOC) - poc ˇet deklaracı ´ dat - poc ˇet pra ´zdny ´ch r ˇa ´dek * produktivita - E-faktor (environmental factor) = poc ˇet nepr ˇerus ˇeny ´ch hodin / celkova ´ pracovnı ´ doba; optima ´lnı ´ je cca 0.4 - pracovnı ´ doba stra ´vena ´ na projektu - pracovnı ´ doba stra ´vena ´ na kaz ˇde ´m podprogramu - poc ˇet zme ˇn v podprogramu - na ´klady projektu - na ´klady projektu na r ˇa ´dek ko ´du - na ´klady na opravu defektu * sledova ´nı ´ defektu ˚ - va ´z ˇnost defektu - mı ´sto defektu - zpu ˚sob opravy defektu - osoba zodpove ˇdna ´ za defekt - poc ˇet r ˇa ´dek zme ˇne ˇny ´ch pr ˇi oprave ˇ defektu - pracovnı ´ doba stra ´vena ´ opravou defektu - pru ˚me ˇrna ´ doba potr ˇebna ´ na nalezenı ´ defektu - pru ˚me ˇrna ´ doba potr ˇebna ´ na opravu defektu - poc ˇet pokusu ˚ opravit defekt - poc ˇet novy ´ch chyb zaneseny ´ch opravou defektu * celkova ´ kvalita
zswi/pDscm.d
zswi/pDscm.d -
3. ledna 2005 celkovy ´ poc ˇet defektu ˚ poc ˇet defektu ˚ v podprogramu pru ˚me ˇrny ´ poc ˇet defektu ˚ na 1000 r ˇa ´dek ko ´du str ˇednı ´ doba mezi hava ´riemi chyby detekovane ´ pr ˇekladac ˇem
* udrz ˇovatelnost - poc ˇet parametru ˚ pr ˇeda ´vany ´ch kaz ˇde ´mu podprogramu - poc ˇet loka ´lnı ´ch prome ˇnny ´ch pouz ˇity ´ch kaz ˇdy ´m podprogramem - poc ˇet podprogramu ˚ volany ´ch kaz ˇdy ´m podprogramem - poc ˇet rozhodovacı ´ch bodu ˚ v kaz ˇde ´m podprogramu - sloz ˇitost r ˇı ´dı ´cı ´ch konstrukcı ´ v kaz ˇde ´m podprogramu - poc ˇet r ˇa ´dek ko ´du v kaz ˇde ´m podprogramu - poc ˇet komenta ´r ˇ˚ u v kaz ˇde ´m podprogramu - poc ˇet deklaracı ´ dat v kaz ˇde ´m podprogramu - poc ˇet pra ´zdny ´ch r ˇa ´dek v kaz ˇde ´m podprogramu - poc ˇet pr ˇı ´kazu ˚ goto v kaz ˇde ´m podprogramu - poc ˇet vstupne ˇ/vy ´stupnı ´ch pr ˇı ´kazu ˚ v kaz ˇde ´m podprogramu * objektove ˇ orientovane ´ metriky - va ´z ˇena ´ sloz ˇitost tr ˇı ´dy - hloubka stromu de ˇdic ˇnosti - poc ˇet pr ˇı ´my ´ch potomku ˚ tr ˇı ´dy - poc ˇet operacı ´ pr ˇedefinovany ´ch v kaz ˇde ´ podtr ˇı ´de ˇ - stupen ˇ prova ´zanosti mezi tr ˇı ´dami
Pra ´ce v ty ´mech ============== * ve ˇts ˇina profesiona ´lnı ´ch programa ´toru ˚ pracuje v ty ´mech, ty ´my od 2 do ne ˇkolika set lidı ´ - pokud je ty ´m velky ´, je zr ˇejma ´ potr ˇeba, aby byl ne ˇjak strukturova ´n . rozde ˇlenı ´ do skupin, kaz ˇda ´ skupina je zodpove ˇdna ´ za podprojekt . skupiny by neme ˇly mı ´t vı ´ce nez ˇ 8 c ˇlenu ˚ . maly ´ poc ˇet = zmens ˇenı ´ komunikac ˇnı ´ch proble ´mu ˚ Constantine (1993) popisuje c ˇtyr ˇi paradigmata pro organizaci ty ´mu ˚: * uzavr ˇene ´ paradigma - ty ´m ma ´ pevne ˇ stanovenou hierarchii - pr ˇı ´kladem je na prvnı ´ pr ˇedna ´s ˇce zmı ´ne ˇny ´ ”chirurgicky ´ ty ´m” - tyto ty ´my pracujı ´ dobr ˇe, pokud je SW podobny ´ pr ˇedchozı ´m projektu ˚m, obvykle by ´vajı ´ me ´ne ˇ inovativnı ´ * na ´hodne ´ paradigma - ty ´m ma ´ volnou strukturu, role za ´visejı ´ na iniciative ˇ jednotlivy ´ch c ˇlenu ˚ ty ´mu (”tvor ˇiva ´ neza ´vislost”) - mu ˚ˇ ze mı ´t vysokou vy ´konnost, pokud si c ˇlenove ´ mohou vza ´jemne ˇ du ˚ve ˇr ˇovat, jednotlivı ´ c ˇlenove ´ majı ´ pr ˇime ˇr ˇene ´ dovednosti a pokud neobsahuje rebely - vhodne ´ pro inovativnı ´ projekty, c ˇasto proble ´my pokud je vyz ˇadova ´na ”be ˇz ˇna ´ pra ´ce” * otevr ˇene ´ paradigma - ty ´m zaloz ˇeny ´ na spolupra ´ci, typicky znac ˇna ´ komunikace a rozhodova ´nı ´ zaloz ˇene ´ na konsensu - vhodne ´ pro r ˇes ˇenı ´ obtı ´z ˇny ´ch proble ´mu ˚, obvykle neby ´va ´ tak efektivnı ´ jako jine ´ typy ty ´mu ˚ * synchronnı ´ paradigma - za ´visı ´ na moz ˇnosti rozde ˇlit proble ´m na neza ´visle ´ c ˇa ´sti - c ˇlenove ´ ty ´mu pracujı ´ na jednotlivy ´ch podproble ´mech, c ˇlenove ´ mezi sebou nemusejı ´ pr ˇı ´lis ˇ komunikovat Neza ´visle na typu organizace ty ´mu ovlivn ˇujı ´ pra ´ci v ty ´mu pr ˇedevs ˇı ´m 4 faktory: * sloz ˇenı ´ ty ´mu: ma ´ ty ´m vyva ´z ˇene ´ technicke ´ schopnosti, zkus ˇenosti, osobnostnı ´ charakteristiky? * koheze ty ´mu: je ty ´m mnoz ˇinou jednotlivcu ˚ nebo ma ´ ”skupinove ´ho ducha” (skupina o sobe ˇ uvaz ˇuje jako o ty ´mu) * skupinova ´ komunikace: doka ´z ˇı ´ spolu c ˇlenove ´ efektivne ˇ komunikovat? * organizace ty ´mu: ma ´ kaz ˇdy ´ pr ˇime ˇr ˇenou roli v ty ´mu?
139
Za´klady softwarove´ho inzˇeny´rstvı´
140 Sloz ˇenı ´ ty ´mu ............
* v psychologicke ´ studii motivace (Bass & Dunteman) se uka ´zalo, z ˇe profesiona ´ly lze v za ´sade ˇ rozde ˇlit podle jejich motivace do tr ˇı ´ kategoriı ´: - ´ ukolove ˇ orientovanı ´ - motivacı ´ je jim pra ´ce, kterou vykona ´vajı ´ . pr ˇi vytva ´r ˇenı ´ SW je motivacı ´ intelektua ´lnı ´ vy ´zva vytvor ˇit SW . platı ´ pro velkou c ˇa ´st vy ´voja ´r ˇ˚ u - orientovanı ´ na sebe - v za ´sade ˇ motivova ´ni osobnı ´m ´ uspe ˇchem a uzna ´nı ´m . vy ´voj SW je jim prostr ˇedkem k dosaz ˇenı ´ vlastnı ´ch cı ´lu ˚ - orientovanı ´ na interakci - jsou motivovanı ´ pr ˇı ´tomnostı ´ a c ˇinnostı ´ spolupracovnı ´ku ˚ * lide ´ orientovanı ´ na interakci pracujı ´ rade ˇji ve skupina ´ch, zatı ´mco ´ ukolove ˇ orientovanı ´ a na sebe orientovanı ´ obvykle rade ˇji pracujı ´ sami * u z ˇen je pravde ˇpodobne ˇjs ˇı ´ orientace na interakci nez ˇ u muz ˇ˚ u, c ˇasto jsou efektivne ˇjs ˇı ´ komunika ´tor ˇi * motivace jednotlivce se skla ´da ´ ze vs ˇech tr ˇı ´ kategoriı ´, jedna z nich ale ve ˇts ˇinou pr ˇevaz ˇuje * osobnosti nejsou staticke ´, motivace se mu ˚z ˇe me ˇnit . napr ˇı ´klad pokud ma ´ ´ ukolove ˇ orientovany ´ c ˇlen ty ´mu pocit, z ˇe nenı ´ pr ˇime ˇr ˇene ˇ odme ˇn ˇova ´n, mu ˚z ˇe se jeho motivace zme ˇnit na ”orientovany ´ na sebe” * pro skupinu je dobre ´, pokud obsahuje dopln ˇujı ´cı ´ se typy osobnostı ´: - ´ ukolove ˇ orientovanı ´ by ´vajı ´ obvykle nejsilne ˇjs ˇı ´ technicky - na sebe orientovanı ´ obvykle tlac ˇı ´ ty ´m na dokonc ˇenı ´ pra ´ce (vy ´sledky) - orientovanı ´ na interakci napoma ´hajı ´ komunikaci uvnitr ˇ skupiny * Proc ˇ optimalizovat sloz ˇenı ´ ty ´mu [pr ˇevzato od P. Brady] Dobr ˇe vyva ´z ˇeny ´ ty ´m je velmi silna ´ zbran ˇ s enormnı ´ kapacitou k tvor ˇive ´ pra ´ci - a proto je take ´ drahy ´ a musı ´ by ´t zate ˇˇ zova ´n odpovı ´dajı ´cı ´mi ´ ukoly. Optimalizovat sloz ˇenı ´ je tedy vhodne ´ pr ˇi vytva ´r ˇenı ´ novy ´ch skupin za ´ uc ˇelem ambicio ´znı ´ch a na ´roc ˇny ´ch ´ ukolu ˚, a take ´ pro ty ´my, ktere ´ musı ´ obsta ´t v prostr ˇedı ´ velky ´ch zme ˇn, silne ´ konkurence, potr ˇeby rychle ´ inovace a akc ˇnosti. * Kdy sloz ˇenı ´ ty ´mu nenı ´ kriticke ´ [pr ˇevzato od P. Brady] Nenı ´ vz ˇdy nutne ´ snaz ˇit se optimalizovat sloz ˇenı ´ ty ´mu. Optimalizace nenı ´ na mı ´ste ˇ v pr ˇı ´padech rutinnı ´ch operacı ´ a ´ uloh pod intelektua ´lnı ´ ´ urovnı ´ idea ´lnı ´ho ty ´mu - takovy ´ ty ´m by pro dany ´ ´ uc ˇel byl velmi drahy ´ nehlede ˇ na to, ˇe by pra z ´ce neposkytovala jeho c ˇlenu ˚ m motivaci a uspokojenı ´. Ne ˇkdy ji nelze aplikovat z prakticky ´ch c ˇi logisticky ´ch du ˚vodu ˚ - ne vz ˇdy je moz ˇnost vybrat lidi s poz ˇadovany ´mi vlastnostmi, aniz ˇ by bylo potr ˇeba nabı ´rat nove ´ zame ˇstnance; je take ´ moz ˇne ´, z ˇe jsou k dispozici lide ´ s potencia ´lem, ale bez technicky ´ch znalostı ´. Je vz ˇdy leps ˇı ´ se o vyva ´z ˇenı ´ sloz ˇenı ´ ty ´mu pokusit c ˇa ´stec ˇne ˇ nez ˇ vu ˚bec. Pokud pr ˇesto nenı ´ vyhovujı ´cı ´, mohou se c ˇlenove ´ jeho nedostatky snaz ˇit nahradit bde ˇnı ´m nad slaby ´mi aspekty s pouz ˇitı ´m ”nejleps ˇı ´ch ze vs ˇech s ˇpatny ´ch” lidı ´ a postupnou zme ˇnou. * du ˚lez ˇita ´ role je vedoucı ´ skupiny - obvykle technicke ´ sme ˇr ˇova ´nı ´ a administrace projektu - sledujı ´ pra ´ci ty ´mu, efektivitu * vedoucı ´ obvykle urc ˇeni managementem - proble ´m - urc ˇenı ´ vedoucı ´ nemusejı ´ by ´t vu ˚dci skupiny po technicke ´ stra ´nce - ve skutec ˇnosti si skupina mu ˚z ˇe najı ´t ve sve ´m str ˇedu napr ˇ. technicky nejschopne ˇjs ˇı ´ho, nejleps ˇı ´ho motiva ´tora - ne ˇkdy je proto vy ´hodne ´ odde ˇlit technicke ´ vedenı ´ od administrace projektu Koheze skupiny .............. * kohezivnı ´ skupina = pro c ˇleny jsou jejich individua ´lnı ´ za ´jmy me ´ne ˇ du ˚lez ˇite ´ nez ˇ za ´jmy skupiny
zswi/pDscm.d
zswi/pDscm.d
3. ledna 2005
- tj. c ˇlenove ´ se cı ´tı ´ by ´t c ˇleny skupiny, snaz ˇı ´ se skupinu chra ´nit, poma ´hat si navza ´jem apod. - lze podpor ˇit poskytova ´nı ´m informacı ´ a du ˚ve ˇry skupine ˇ * vy ´hody kohezivnı ´ skupiny: - konsensem mohou vzniknout standardy kvality - c ˇlenove ´ skupiny te ˇsne ˇ spolupracujı ´ - mohou se od sebe navza ´jem uc ˇit apod. - c ˇlenove ´ znajı ´ navza ´jem svojı ´ pra ´ci (vy ´hoda pokud napr ˇ. c ˇlen skupiny onemocnı ´) - programy mohou by ´t cha ´pa ´ny jako skupinove ´ vlastnictvı ´ (egoless programming) - usnadn ˇuje prova ´de ˇnı ´ inspekcı ´, pr ˇijı ´ma ´nı ´ kritiky a vyleps ˇova ´nı ´ programu skupinou * kohezivnı ´ skupiny majı ´ na ´chylnost ke dve ˇma proble ´mu ˚m: - iraciona ´lnı ´ rezistence ke zme ˇne ˇ vedoucı ´ho - pokud je vedoucı ´ nahrazen ne ˇky ´m mimo skupinu, skupina se mu ˚z ˇe sjednotit proti nove ´mu vedoucı ´mu => snı ´z ˇenı ´ produktivity . pokud je to moz ˇne ´, me ˇl by by ´t vedoucı ´ zvolen z c ˇlenu ˚ skupiny - tzv. skupinove ´ mys ˇlenı ´ - kriticke ´ mys ˇlenı ´ je potlac ˇeno ve prospe ˇch loajality vu ˚c ˇi skupine ˇ (resp. skupinovy ´m norma ´m, skupinovy ´m rozhodnutı ´m)
Komunikace uvnitr ˇ skupiny ......................... * dobra ´ komunikace mezi c ˇleny skupiny je podstatna ´ * podstatne ´ faktory: - velikost skupiny - struktura skupiny - sloz ˇenı ´ - fyzicke ´ pracovnı ´ prostr ˇedı ´ * klı ´c ˇovy ´m faktorem je velikost skupiny - poc ˇet moz ˇny ´ch komunikac ˇnı ´ch cest je n * (n-1) - tj. pro sedmic ˇlennou skupinu (42 cest) je pravde ˇpodobne ´, z ˇe ne ˇkter ˇı ´ c ˇlenove ´ spolu budou komunikovat velmi zr ˇı ´dka * dals ˇı ´m faktorem struktura skupiny - v neforma ´lne ˇ strukturovany ´ch skupina ´ch efektivne ˇjs ˇı ´ komunikace nez ˇ ve forma ´lne ˇ (hierarchicky) strukturovany ´ch skupina ´ch - v hierarchicky strukturovany ´ch skupina ´ch majı ´ informace tendenci putovat nahoru a dolu ˚ v hierarchii, ale lide ´ na ne ˇktere ´ ´ urovni spolu nekomunikujı ´ - proble ´m velky ´ch skupin * sloz ˇenı ´ skupiny - pokud se skupina skla ´da ´ z pr ˇı ´lis ˇ mnoha lidı ´ stejne ´ho osobnostnı ´ho typu, nasta ´vajı ´ konflikty a komunikace uva ´zne - komunikace je obvykle leps ˇı ´ ve skupina ´ch, kde jsou muz ˇi i z ˇeny, nez ˇ ve skupina ´ch sloz ˇeny ´ch pouze z muz ˇ˚ u nebo pouze z z ˇen - z ˇeny jsou c ˇaste ˇji interakc ˇne ˇ orientovane ´ => mohou by ´t prostr ˇednı ´ci * fyzicke ´ pracovnı ´ prostr ˇedı ´ - velmi podstatne ´ pro chova ´nı ´ a vy ´konnost skupiny - podle (DeMarco & Lister 1985) rozdı ´ly ve vy ´konnosti ty ´mu ˚ az ˇ 1:11 - pro vy ´konnost nejdu ˚lez ˇite ˇjs ˇı ´ vlastnosti: . soukromı ´ - potr ˇeba prostoru, kde se mohou soustr ˇedit na pra ´ci bez vyrus ˇova ´nı ´ . pr ˇirozene ´ sve ˇtlo, viditelnost vne ˇjs ˇı ´ho prostr ˇedı ´ (= okna) . moz ˇnost individua ´lnı ´ch ´ uprav prostr ˇedı ´ podle zpu ˚sobu pra ´ce * pro komunikaci je podstatne ´, aby skupina mohla diskutovat projekt forma ´lne ˇ i neforma ´lne ˇ - (Weinberg 1971) cituje pr ˇı ´pad, kdy organizace chte ˇla zabra ´nit programa ´toru ˚m ”ztra ´cet c ˇas” povı ´da ´nı ´m u automatu na kafe; po odstrane ˇnı ´ automatu se okamz ˇite ˇ dramaticky zvy ´s ˇil poc ˇet forma ´lnı ´ch poz ˇadavku ˚ na vy ´pomoc - vyplatı ´ se mı ´t neforma ´lnı ´ mı ´sto pro setka ´va ´nı ´, stejne ˇ jako konferenc ˇnı ´ mı ´stnost pro forma ´lnı ´ sezenı ´
141
Za´klady softwarove´ho inzˇeny´rstvı´
142 zasedací místnost
kancelář
kancelář kancelář
sdílená dokum.
sdílená shared dokum. doc
kancelář
kancelář
kancelář
kancelář
kancelář
Softwarove ´ profese .................. V ra ´mci ty ´mu ˚ vykona ´vajı ´ ru ˚znı ´ c ˇlenove ´ ru ˚ znou pra ´ci; vs ˇichni jsou stejne ˇ potr ˇebnı ´, ne ˇkter ˇı ´ ale nesou ve ˇts ˇı ´ zodpove ˇdnost. Jako pr ˇı ´klad uvedu rozde ˇlenı ´ na profese podle (Paleta 2003): * zadavatel nebo manager produktu - forma ´lne ˇ nenı ´ souc ˇa ´stı ´ ty ´mu - sestavuje poz ˇadavky na vytva ´r ˇenou aplikaci, zodpovı ´da ´ ota ´zky ty ´mu, pr ˇebı ´ra ´ aplikaci - u syste ´mu ˚ vytva ´r ˇeny ´ch na zaka ´zku je za ´stupcem zadavatele * vedoucı ´ projektu - r ˇı ´dı ´ vlastnı ´ vy ´voj, je zodpove ˇdny ´ za splne ˇnı ´ poz ˇadavku ˚, termı ´nu a rozpoc ˇtu - komunikuje se zadavatelem nebo managerem produktu * technicky ´ leader nebo architekt - ostatnı ´ se na ne ˇj obracejı ´, pokud majı ´ technicky ´ dotaz - navrhuje celkovou strukturu aplikace, vybı ´ra ´ technologie a vy ´vojove ´ prostr ˇedky * databa ´zovy ´ specialista - na ´vrh databa ´ze - pr ˇı ´prava vy ´konnostnı ´ch testu ˚ a na za ´klade ˇ jejich vy ´sledku ˚ optimalizace databa ´ze * analytik - rozpracova ´va ´ specifikaci, vytva ´r ˇı ´ konceptua ´lnı ´ model aplikace - navrhuje posloupnost obrazovek apod. - role mu ˚z ˇe by ´t kombinova ´na s pozicı ´ programa ´tora nebo tvu ˚rce dokumentace * na ´vrha ´r ˇ uz ˇivatelske ´ho rozhranı ´ - navrhuje obrazovky aplikace tak, aby byly pr ˇehledne ´ a snadno pouz ˇitelne ´ * programa ´tor - vytva ´r ˇı ´ ko ´d na za ´klade ˇ specifikace a konceptua ´lnı ´ho modelu * tester - r ˇı ´dı ´ nebo prova ´dı ´ testova ´nı ´ * tvu ˚rce dokumentace - zpracova ´va ´ technickou dokumentaci vytva ´r ˇenou ostatnı ´mi c ˇleny ty ´mu, vytva ´r ˇı ´ uz ˇivatelskou dokumentaci (manua ´ly, na ´pove ˇda) Konfigurac ˇnı ´ management ======================= * v SW projektech se me ˇnı ´ poz ˇadavky na syste ´m, design syste ´mu, ko ´d, dokumentace syste ´mu atd. - v pru ˚be ˇhu c ˇasu ve ˇdı ´ vs ˇichni zu ´c ˇastne ˇnı ´ vı ´ce (o tom co potr ˇebujı ´, jak by se to nejle ´pe ude ˇlalo, atd.) - poz ˇadavky na zme ˇny budou pr ˇicha ´zet ve vs ˇech fa ´zı ´ch tvorby SW - pro r ˇı ´zenı ´ zme ˇn v projektech byly vyvinuty procesy, nazy ´vane ´ souhrnne ˇ konfigurac ˇnı ´ management (angl. software configuration management, SCM) - ´ ukolem SCM definovat procedury pro prova ´de ˇnı ´ zme ˇn, eliminuje ne ˇktere ´ proble ´my vznikajı ´cı ´ zejme ´na pokud je mnoho vy ´voja ´r ˇ˚ u a mnoho verzı ´ SW * pr ˇedstavte si ty ´m vyvı ´jejı ´cı ´ SW - ´ uspe ˇs ˇny ´ SW => tisı ´ce poz ˇadavku ˚ na opravy a vyleps ˇenı ´ - ko ´d ve sdı ´lene ´m adresa ´r ˇi - co kdyz ˇ dva programa ´tor ˇi prova ´de ˇjı ´ zme ˇnu ve
zswi/pDscm.d
zswi/pDscm.d
3. ledna 2005
stejne ´m modulu? - oprava chyby v produkc ˇnı ´ verzi, me ˇla by se promı ´tnout za ´roven ˇ ve vy ´vojove ´ verzi, do ktere ´ jsou ale mezitı ´m pr ˇida ´va ´ny dals ˇı ´ vlastnosti - vyleps ˇenı ´ zavleklo chyby - jak se vra ´tit ke stare ´ verzi? - jak zjistit, z c ˇeho se ktera ´ verze skla ´da ´? - obvykle kombinace te ˇchto + dals ˇı ´ch proble ´mu ˚ * pro ´ uspe ˇch projektu podstatna ´ schopnost r ˇı ´dit zme ˇny tak, aby si syste ´m mohl zachovat integritu v c ˇase Tradic ˇnı ´ SCM proces ------------------* v tradic ˇnı ´m procesu vy ´voje SW zaloz ˇene ´m na vodopa ´dove ´m modelu je SW pr ˇeda ´n SCM ty ´mu po dokonc ˇenı ´ vy ´voje a po otestova ´nı ´ jednotlivy ´ch komponent - SCM ty ´m pr ˇebı ´ra ´ odpove ˇdnost za sestavenı ´ ´ uplne ´ho syste ´mu a za vedenı ´ testu ˚ - chyby objevene ´ pr ˇi testu syste ´mu jsou pr ˇeda ´ny zpe ˇt k oprave ˇ vy ´vojove ´mu ty ´mu - tento pr ˇı ´stup ovlivnil tvorbu standardu ˚; napr ˇ. IEEE Std. 828 nevyslovene ˇ pr ˇedpokla ´da ´ vodopa ´dovy ´ model, tj. obtı ´z ˇne ˇ se pr ˇizpu ˚sobujı ´ napr ˇ. inkrementa ´lnı ´mu vy ´voji - proto take ´ SCM patr ˇı ´ k nejhu ˚r ˇe zpracovany ´m te ´matu ˚m v literatur ˇe o SW inz ˇeny ´rstvı ´ - napr ˇed popı ´s ˇu tradic ˇnı ´ SCM proces (tak jak ho popisujı ´ standardy), pak zmı ´nı ´m pr ˇizpu ˚sobenı ´ SCM pro inkrementa ´lnı ´ model SW procesu * tradic ˇnı ´ SCM definuje 4 procedury, ktere ´ musejı ´ by ´t pro SW projekt definova ´ny, pokud ma ´ by ´t definova ´n dobry ´ SCM proces - identifikace konfigurace - r ˇı ´zenı ´ konfigurace - vytva ´r ˇenı ´ za ´znamu ˚ o stavu konfigurace - autentizace konfigurace Identifikace konfigurace ........................ * informace, ktere ´ jsou vy ´stupem jednotlivy ´ch fa ´zı ´ SW procesu, mu ˚z ˇeme rozde ˇlit do tr ˇı ´ velky ´ch kategoriı ´: (1) programy (jak zdrojove ´ texty tak spustitelne ´), (2) dokumentace programu ˚ , (3) data - na poc ˇa ´tku ma ´me specifikaci syste ´mu, z nı ´ vznikne DSP, pozde ˇji design atd. - informace vytvor ˇena ´ v du ˚sledku SW procesu a reprezentujı ´cı ´ urc ˇitou podobu dane ´ho SW syste ´mu se nazy ´va ´ konfigurace SW * konfigurace sesta ´va ´ z tzv. ”konfigurovatelny ´ch poloz ˇek” (configurable item, CI), ktere ´ jsou atomicke ´ z hlediska zme ˇn a oznac ˇova ´nı ´ verzı ´ - CI bude napr ˇ. DSP, ERA model, jeden .java soubor, jedna .dll knihovna, mnoz ˇina testovacı ´ch pr ˇı ´padu ˚ apod. - mezi CI existujı ´ za ´vislosti (kompozice, generova ´nı ´, master-dependent, ...) - kaz ˇda ´ CI je jednoznac ˇne ˇ identifikovatelna ´ (typ CI, identifika ´tor projektu, identifika ´tor zme ˇny nebo verze) * konzistentnı ´ konfigurace = SW konfigurace, jejı ´z ˇ prvky jsou navza ´jem bezrozporne ´ - obsahuje napr ˇ. zdrojove ´ texty, makefiles, konfigurac ˇnı ´ soubory, dokumentace, testu ˚ atd. v pr ˇı ´slus ˇny ´ch verzı ´ch - bezrozporna ´ = napr ˇ. zdrojove ´ soubory lze pr ˇeloz ˇit, knihovny pr ˇilinkovat * baseline = konzistentnı ´ konfigurace tvor ˇı ´cı ´ stabilnı ´ za ´klad pro produkc ˇnı ´ verzi nebo dals ˇı ´ vy ´voj (startovacı ´ bod pro r ˇı ´zenou evoluci) - pr ˇ´ ıklad: milnı ´k beta verze aplikace stabilnı ´: vytvor ˇena ´, otestovana ´ a schva ´lena ´ managementem - pro baseline pr ˇedpokla ´da ´me na ´sledujı ´cı ´ vlastnosti: . dokumentovana ´ funkc ˇnost, tj. vlastnosti SW pro kaz ˇdou baseline jsou dobr ˇe zna ´me ´ . zna ´ma ´ kvalita: napr ˇ. zna ´me ´ chyby budou dokumentova ´ny, SW pros ˇel testova ´nı ´m pr ˇed tı ´m, nez ˇ je definova ´n jako baseline . baseline je nezme ˇnitelna ´ a znovu vytvor ˇitelna ´: po definici nemu ˚z ˇe by ´t baseline zme ˇne ˇna, vs ˇechny CI tvor ˇı ´cı ´ baseline mu ˚z ˇeme kdykoli znovu vytvor ˇit - zme ˇny prvku ˚ baseline jen podle schva ´lene ´ho postupu - pr ˇi proble ´mech na ´vrat k baseline
143
Za´klady softwarove´ho inzˇeny´rstvı´
144
- kaz ˇda ´ nova ´ baseline je pr ˇedchozı ´ baseline + souhrn schva ´leny ´ch zme ˇn CI * proces identifikace konfigurace definuje baseline, z jaky ´ch CI se skla ´da ´ * dals ˇı ´ uz ˇitec ˇne ´ pojmy: - delta = mnoz ˇina zme ˇn CI mezi dve ˇma po sobe ˇ na ´sledujı ´cı ´mi verzemi . v ne ˇktery ´ch syste ´mech jednoznac ˇne ˇ identifikovatelna ´ - repository (u ´loz ˇis ˇte ˇ, databa ´ze projektu) = centra ´lnı ´ mı ´sto, kde jsou uloz ˇeny vs ˇechny CI projektu . r ˇ´ ızeny ´ pr ˇı ´stup (udrz ˇenı ´ konzistence) - workspace (pracovnı ´ prostor) = soukromy ´ datovy ´ prostor, v ne ˇmz ˇ je moz ˇno prova ´de ˇt zme ˇny prvku ˚ konfigurace, aniz ˇ by byla ovlivne ˇna jejich podoba v repository . akce ”zkopı ´rova ´nı ´ CI z repository” a ”uloz ˇenı ´ CI do repository” ˇı R ´zenı ´ konfigurace .................. * proble ´m ve vs ˇech fa ´zı ´ch z ˇivotnı ´ho cyklu: - jak zvla ´dat mnoz ˇstvı ´ poz ˇadavku ˚ na ´ upravy produktu (opravy, vyleps ˇenı ´)? - jak poznat, kdy uz ˇ jsou vyr ˇes ˇeny? * nutny ´ striktnı ´ postup akcı ´: klasifikace a vyhodnocenı ´ navrhovany ´ch zme ˇn, jejich schva ´lenı ´ nebo neschva ´lenı ´, koordinace schva ´leny ´ch zme ˇn, implementace zme ˇn na pr ˇı ´slus ˇnou baseline, dokumentace a ove ˇr ˇenı ´ * poz ˇadavek obsahuje: na ´zev a verzi produktu / subsyste ´mu, ktere ´ho se ty ´ka ´; popis chyby c ˇi poz ˇadovane ´ zme ˇny (co nejpr ˇesne ˇjs ˇı ´) + indikaci priority; pro chybu: jak vznikla, jak je moz ˇne ´ ji znovu reprodukovat; informace o pouz ˇite ´m software (konfigurace, OS, knihovny) - poz ˇadavek procha ´zı ´ stavy: novy ´ -> pr ˇevzaty ´ -> pr ˇir ˇazeny ´ -> vyr ˇes ˇeny ´/zrus ˇeny ´/duplicitnı ´ -> uzavr ˇeny ´ * postup zpracova ´nı ´ poz ˇadavku - pr ˇijetı ´ poz ˇadavku . pr ˇide ˇlenı ´ ID . nastavenı ´ za ´vaz ˇnosti, priority (kriticka ´ chyba - proble ´m - vada na kra ´se - vyleps ˇenı ´) - v tradic ˇnı ´m procesu schva ´lenı ´, neschva ´lenı ´, odloz ˇenı ´ zme ˇny r ˇı ´dı ´ ”komise pro r ˇı ´zenı ´ konfigurace” (angl. configuration control board, CCB) . chyba -> nutno ove ˇr ˇit, z ˇe chyba je rea ´lna ´ - zpracova ´nı ´ poz ˇadavku . pove ˇr ˇeny ´ c ˇlove ˇk (dle zodpove ˇdnosti za c ˇa ´sti syste ´mu) . lokalizace zme ˇn v produktech procesu . oprava v loka ´lnı ´m workspace, testova ´nı ´ a validace . schva ´lenı ´, nova ´ baseline * SW podpora - syste ´my pro spra ´vu zme ˇn (bug tracking systems) - evidence a archivace poz ˇadavku ˚, sledova ´nı ´ stavu poz ˇadavku, pr ˇı ´padne ˇ statistiky - c ˇasto emailove ´, webove ´ - napr ˇ. Gnats + Gnatsweb, Bugzilla, JitterBug apod. Vytva ´r ˇenı ´ za ´znamu ˚ o stavu konfigurace ..................................... * zajis ˇte ˇnı ´ sledovatelnosti zme ˇn SW * zaznamena ´va ´nı ´ informacı ´ o kaz ˇde ´ verzi SW a o zme ˇna ´ch oproti pr ˇedchozı ´ baseline, ktere ´ k te ´to verzi vedly * za ´znam pomu ˚z ˇe zodpove ˇde ˇt ota ´zky jako - ”Byla chyba XYZ opravena?” - ”Kdo je zodpove ˇdny ´ za tuto modifikaci?” ˇı - ”C ´m pr ˇesne ˇ se tato verze lis ˇı ´ od baseline?” * konkre ´tnı ´ na ´stroje uvedeme pozde ˇji Autentizace konfigurace ....................... * proces, ktery ´ zajis ˇt’uje
zswi/pDscm.d
zswi/pDscm.d
3. ledna 2005
145
- aby v nove ´ baseline byly zahrnuty vs ˇechny pla ´novane ´ a schva ´lene ´ zme ˇny - aby souc ˇa ´stı ´ dodane ´ho syste ´mu byly vs ˇechny poz ˇadovane ´ programy, dokumentace a data
SCM pro inkrementa ´lnı ´ vy ´voj --------------------------* pr ˇı ´klad procesu: - cely ´ syste ´m se sestavuje c ˇasto (napr ˇ. denne ˇ) - organizace urc ˇı ´ c ˇas, do kdy musı ´ vy ´voja ´r ˇi doruc ˇit sve ´ komponenty (napr ˇ. 14h) - komponenty mohou by ´t neu ´plne ´, ale musejı ´ poskytovat za ´kladnı ´ funkc ˇnost, ktera ´ mu ˚z ˇe by ´t otestova ´na * z komponent se sestavı ´ nova ´ verze syste ´mu - syste ´m je pr ˇeda ´n testovacı ´mu ty ´mu, ktery ´ provede pr ˇeddefinovane ´ testy syste ´mu - vy ´voja ´r ˇi zatı ´m da ´le pracujı ´ na svy ´ch komponenta ´ch, pr ˇida ´vajı ´ funkc ˇnost a opravujı ´ chyby objevene ´ v pr ˇedchozı ´ch testech - testovacı ´ ty ´m zdokumentuje objevene ´ chyby, pr ˇeda ´ je vy ´voja ´r ˇ˚ um - vy ´voja ´r ˇi chybu opravı ´ v dals ˇı ´ verzi komponenty * hlavnı ´ vy ´hodou dennı ´ho sestavova ´nı ´ je brzke ´ nalezenı ´ proble ´mu ˚ vznikly ´ch interakcı ´ komponent * vy ´voja ´r ˇi pocit’ujı ´ tlak, aby jejich komponenty nezpu ˚sobily hava ´rii syste ´mu du ˚ sledkem je leps ˇı ´ testova ´nı ´ jednotek * SCM proces musı ´ ne ˇkdo r ˇı ´dit, musı ´ ustanovit podrobne ´ procedury, musı ´ zajistit, aby vs ˇechny zme ˇny probe ˇhly spra ´vne ˇ * pr ˇı ´klad velke ´ho projektu - ja ´dro OS Linux: - ve ˇts ˇinu skutec ˇne ´ho vy ´voje jinı ´ vy ´voja ´r ˇi, ale jake ´ vlastnosti bude obsahovat ja ´dro urc ˇuje jeden c ˇlove ˇk - Linus Torvalds - vs ˇichni vy ´voja ´r ˇi mu posı ´lajı ´ zme ˇny, ktere ´ majı ´ by ´t zac ˇlene ˇny do ja ´dra - hraje roli SCM procesu: . r ˇ´ ızenı ´ konfigurace (zac ˇlen ˇova ´nı ´/nezac ˇlen ˇova ´nı ´ zme ˇn ostatnı ´ch vy ´voja ´r ˇ˚ u) . vytva ´r ˇenı ´ za ´znamu ˚ o stavu konfigurace (ChangeLog) . autentizace konfigurace (zaruc ˇuje, z ˇe ja ´dro ma ´ vs ˇechny c ˇa ´sti)
Verzova ´nı ´ --------* ´ uc ˇel: udrz ˇenı ´ pr ˇehledu o podoba ´ch CI - verze popisuje stav CI, nebo postup jeho zme ˇn - extenziona ´lnı ´ verzova ´nı ´: kaz ˇda ´ verze ma ´ jednoznac ˇne ´ ID napr ˇ. 1.5.1 = za ´kladnı ´ verze pro DOS, 1.5.2 pro UNIX, 1.6.1 oprava pro DOS, 2.1.1 = novy ´ release pro DOS . pr ˇı ´stup v c ˇasto pouz ˇı ´vany ´ch na ´strojı ´ch (rcs/cvs, SourceSafe) . jednoducha ´ implementace . nepouz ˇitelne ´ pr ˇi ve ˇts ˇı ´m poc ˇtu verzı ´ - intenziona ´lnı ´ verzova ´nı ´: verze je popsa ´na souborem atributu ˚ . napr ˇ. OS=DOS and UmiPostscript=YES . nutne ´ pro ve ˇts ˇı ´ prostory verzı ´ . potr ˇeba vhodny ´ch na ´stroju ˚ (Adele, c ˇa ´stec ˇne ˇ cpp) * prostor verzı ´ je c ˇasto reprezentova ´n grafem - uzly = verze, hrany = vazby mezi verzemi, nejc ˇaste ˇji relace na ´slednictvı ´ - ve ˇtvenı ´ (branch) - c ˇasto nahrazuje varianty (rcs/cvs) - operace vytvor ˇenı ´ ve ˇtve (branch-off, split) a spojenı ´ (merge)
v1 sequence
v1 v2
tree v4 v2
v2 v3
v3
acyclic graph
v1
v5
v3 v4
* na ´stroje pro verzova ´nı ´ - ruc ˇnı ´ verzova ´nı ´ = dohody a konvence o znac ˇenı ´ verzı ´ v na ´zvech (dokument,
Za´klady softwarove´ho inzˇeny´rstvı´
146
soubor, adresa ´r ˇ), baseline pomocı ´ za ´lohy vs ˇech souboru ˚ v dane ´m c ˇase - za ´kladnı ´ - spra ´va verzı ´ souboru ˚ . obvykle extenziona ´lnı ´ verzova ´nı ´ modulu ˚ . ukla ´da ´nı ´ vs ˇech verzı ´ v zapouzdr ˇene ´ ´ usporne ´ forme ˇ . pr ˇı ´klady na ´stroju ˚: rcs, cvs - pokroc ˇile ´ - integrovane ´ do CASE . obvykle kombinace extenziona ´lnı ´ho a intenziona ´lnı ´ho verzova ´nı ´ . automaticka ´ podpora pro ci/co prvku ˚ z repository do na ´stroju ˚ . pr ˇı ´klad na ´stroje: ClearCase, Adele rcs: Revision Control System ............................ * spra ´va verzı ´ pro textove ´ soubory; UNIX, Windows, DOS - extenziona ´lnı ´ stavove ´ verzova ´nı ´ komponent - c ˇa ´sti syste ´mu - utility spous ˇte ˇne ´ z pr ˇı ´kazove ´ho r ˇa ´dku: . ci, co, rcs, rlog, rcsdiff, rcsmerge - ukla ´da ´ (do foo.c,v souboru) . historii vs ˇech zme ˇn v textu souboru . informace o autorovi a c ˇasu zme ˇn . textovy ´ popis zme ˇny zadany ´ uz ˇivatelem . dals ˇı ´ informace (stav prvku, symbolicka ´ jme ´na) - pouz ˇı ´va ´ diff(1) pro ´ usporu mı ´sta . poslednı ´ revize uloz ˇena cela ´ . pr ˇedchozı ´ pomocı ´ delta vygenerovane ´ programem diff(1) - funkce . zamyka ´nı ´ souboru ˚, poskytova ´nı ´ R/O kopiı ´ . symbolicka ´ jme ´na revizı ´, na ´vrat k pr ˇedchozı ´m verzı ´m . moz ˇnost ve ˇtvenı ´ . informace o souboru a verzi lze vc ˇlenit do textu pomocı ´ klı ´c ˇovy ´ch slov $Author$, $Date$, $Revision$, $State$, $Log$ (popis poslednı ´ zme ˇny zadany ´ uz ˇivatelem), $Id$ (kombinace filename revision datum author state) . typicke ´ pouz ˇitı ´ v C: static char rcsid[] = ”$Id$” pr ˇi ”co” expanduje na ”$Id: soubor.c,v 1.1 2003/05/16 03:17:16 luki Exp $” CVS (Concurrent Versioning System) .................................. * nadstavba nad rcs => umı ´ vs ˇe, co umı ´ rcs (zejm. klı ´c ˇova ´ slova) * optimisticky ´ pr ˇı ´stup ke kontrole paralelnı ´ho pr ˇı ´stupu - mı ´sto zamkni-modifikuj-odemkni (RCS) pracuje syste ´mem zkopı ´ruj-modifikuj-sluc ˇ * pra ´ce s cely ´mi konfiguracemi (projekty) najednou * sdı ´lene ´ repository + soukrome ´ pracovnı ´ prostory * repository loka ´lnı ´ nebo vzda ´lena ´ (rsh, p-server) * moz ˇnost definovat obsah a strukturu konfigurace * zjis ˇt’ova ´nı ´ stavu prvku ˚, rozdı ´lu ˚ oproti repository * pr ˇı ´kazova ´ r ˇa ´dka, graficke ´ nadstavby (UNIX, Windows, web) * rcs i cvs jsou volne ˇ s ˇı ´r ˇene ´ * mnoz ˇstvı ´ informacı ´ on-line, viz napr ˇ. http://www.loria.fr/˜molli/cvs-index.html * existujı ´ dals ˇı ´ podobne ´ na ´stroje, napr ˇ. PRCS, Subversion apod. cpp: Realizace variant ...................... * cpp = C preprocessor, umoz ˇn ˇuje intenziona ´lnı ´ stavove ´ verzova ´nı ´ - napr ˇ. chceme variantu foo.c pro pr ˇı ´pad OS=DOS and UmiPostscript=YES - definice atributu ˚ pro popis variant - hlavic ˇkovy ´ soubor (centra ´lnı ´ mı ´sto def. varianty cele ´ho syste ´mu) parametry pr ˇı ´kazove ´ r ˇa ´dky gcc -DOS_DOS (napr ˇ. v Makefile)
Automatizace pr ˇekladu a sestavenı ´ projektu: make -----------------------------------------------* program ”make” pocha ´zı ´ ze syste ´mu ˚ UNIX, pu ˚vodne ˇ souvislost s jazykem C * ´ uc ˇelem automatizace pr ˇekladu a sestavenı ´ projektu, minimalizace c ˇasu spotr ˇebovane ´ho vytva ´r ˇenı ´m aktua ´lnı ´ch verzı ´ objektovy ´ch a dals ˇı ´ch ”strojove ˇ vytva ´r ˇeny ´ch” souboru ˚
zswi/pDscm.d
zswi/pDscm.d
3. ledna 2005
147
* spustitelny ´ program a objektove ´ soubory se typicky vytva ´r ˇejı ´ ze zdrojovy ´ch textu ˚ * popis pravidel pr ˇekladu umı ´stı ´me do souboru ”Makefile” (pr ˇı ´padne ˇ ”makefile”) * pr ˇeklad spustı ´me pr ˇı ´kazem ”make” Pr ˇı ´klad (projekt v jazyce C v syste ´mu UNIX) * program p bude sestaven ze dvou objektovy ´ch souboru ˚ a.o a b.o * ty se vytva ´r ˇejı ´ pr ˇekladem z odpovı ´dajı ´cı ´ch zdrojovy ´ch textu ˚ a.c a b.c, oba pouz ˇı ´vajı ´ spolec ˇny ´ hlavic ˇkovy ´ soubor inc.h: * pro pr ˇeklad projektu vytvor ˇı ´me soubor Makefile, obsahujı ´cı ´ tr ˇi pravidla: p: a.o b.o cc -o p a.o b.o a.o: a.c inc.h cc -c a.c b.o: b.c inc.h cc -c b.c * poslednı ´ pravidlo znamena ´: - soubor ”b.o” za ´visı ´ na souborech ”b.c” a ”inc.h” . pokud bude soubor ”b.c” nebo soubor ”inc.h” mlads ˇı ´ nez ˇ ”b.o”, je tr ˇeba ”b.o” znovu vytvor ˇit pomocı ´ pr ˇı ´kazu ”cc -c b.c” . b.c bude mlads ˇı ´, napr ˇ. pokud v ne ˇm provedu zme ˇnu textovy ´m editorem - ostatnı ´ pravidla obdobna ´, tj. pokud dojde ke zme ˇne ˇ, provede se minima ´lnı ´ poc ˇet pr ˇı ´kazu ˚, ktera ´ zajistı ´, aby vy ´sledek byl aktua ´lnı ´
p
p cc -o p a.o b.o
a.o
b.o
a.o
b.o cc -c b.c
a.c
inc.h
b.c
a.c
inc.h
b.c
[] * pravidla majı ´ tvar cı ´l: prerekvizity pr ˇı ´kaz1 pr ˇı ´kaz2 - cı ´l (cı ´lovy ´ soubor, co se ma ´ vytvor ˇit) - volitelne ˇ prerekvizity (soubory, ze ktery ´ch se cı ´l vytva ´r ˇı ´) - volitelne ˇ pr ˇı ´kazy, ktere ´ se spustı ´, pokud je ne ˇktera ´ z prerekvizit mlads ˇı ´ nez ˇ cı ´l (cı ´l je ”zastaraly ´”, me ˇl by se vytvor ˇit z prerekvizit; pro zjis ˇte ˇnı ´ sta ´r ˇı ´ se pouz ˇı ´va ´ c ˇas modifikace souboru) . pozor, v UNIXove ´m ”make” musı ´ by ´t pr ˇı ´kazy uvozeny tabula ´torem * provedenı ´ souboru Makefile - spustı ´me pr ˇı ´kaz ”make” - make najde prvnı ´ pravidlo v souboru Makefile - pr ˇed provedenı ´m pravidla rekurzivne ˇ zajistı ´, aby jeho prerekvizity nebyly zastarale ´ . kaz ˇdou prerekvizitu bude povaz ˇovat za cı ´l, najde pr ˇı ´slus ˇne ´ pravidlo . pokud je cı ´l zastaraly ´, vytvor ˇı ´ ho znovu pomocı ´ pr ˇı ´kazu ˚ pravidla - chyba (nenulova ´ na ´vratova ´ hodnota pr ˇı ´kazu) zpu ˚sobı ´ ukonc ˇenı ´ programu make (lze potlac ˇit uvedenı ´m ”-”, tj. ignoruje pr ˇı ´padnou chybu) * fales ˇne ´ (phony) cı ´le - cı ´l je ve skutec ˇnosti ”na ´ve ˇs ˇtı ´ podprogramu”, nikoli vytva ´r ˇeny ´ soubor - pravidlo nema ´ prerekvizity - pouz ˇı ´va ´ se napr ˇ. pro automatizaci ´ uklidovy ´ch akcı ´, instalaci, provedenı ´ testu ˚, vytva ´r ˇenı ´ distribuc ˇnı ´ch archivu ˚ apod. (phony cı ´le clean, install, test apod.)
Za´klady softwarove´ho inzˇeny´rstvı´
148 clean: -rm *.o core
* prome ˇnne ´ (v terminologii programu make nazy ´vane ´ makra) - definice: jme ´no=r ˇete ˇzec - pouz ˇitı ´: $(jme ´no) - pr ˇı ´klad: CC=gcc
# ktery ´m pr ˇekladac ˇem jazyka C budeme pr ˇekla ´dat
p: a.c $(CC) -o p a.c * dals ˇı ´ vlastnosti: vestave ˇna ´ pravidla, inferenc ˇnı ´ pravidla * soubory Makefile najdete ve ve ˇts ˇine ˇ volne ˇ s ˇı ´r ˇeny ´ch programu ˚ (ja ´dro OS Linux apod.) * protoz ˇe ”make” je velmi pouz ˇı ´va ´no, mnoho firem apod. ma ´ vlastnı ´ rozs ˇı ´r ˇenı ´ (podpora paralelnı ´ho be ˇhu, ”include” a ”ifdef” podobne ˇ jako v C, apod.) * gcc -M umı ´ vytvor ˇit za ´vislosti pro objektove ´ soubory, jikes pro .class * existujı ´ dals ˇı ´ na ´stroje se obdobny ´m ´ uc ˇelem, napr ˇ. Ant pro automatizaci pr ˇekladu projektu ˚ v jazyce Java
Eticke ´ a pra ´vnı ´ aspekty tvorby SW ================================= * stejne ˇ jako v jiny ´ch oborech i v SW inz ˇeny ´rstvı ´ existujı ´ urc ˇita ´ eticka ´ pravidla, jejichz ˇ nedodrz ˇova ´nı ´ je povaz ˇova ´no za neslus ˇne ´ a neprofesiona ´lnı ´ * profesiona ´lnı ´ organizace jako ACM a IEEE definovaly ”eticke ´ za ´sady SW inz ˇeny ´ra” (CS Code of Ethics), viz http://www.acm.org/serving/se/code.htm * ne ˇktere ´ za ´kladnı ´ za ´sady: - pr ˇi vytva ´r ˇenı ´ SW ma ´te moz ˇnost by ´t ne ˇkomu prospe ˇs ˇnı ´ nebo mu zpu ˚sobit s ˇkodu (nebo da ´t moz ˇnost jiny ´m, aby byli prospe ˇs ˇnı ´ nebo ublı ´z ˇili) . napr ˇı ´klad pokud jste zodpove ˇdnı ´ za vy ´voj syste ´mu kriticke ´ho pro bezpec ˇnost lidı ´ a c ˇas va ´s tlac ˇı ´ - bylo by neeticke ´ prohla ´sit syste ´m za otestovany ´, pokud nenı ´ . pokud je pravde ˇpodobna ´ ´ uc ˇast na vojensky ´ch, nuklea ´rnı ´ch nebo jiny ´ch projektech, na ktere ´ existujı ´ ru ˚zne ´ pohledy z eticke ´ho hlediska, je tr ˇeba to pr ˇedem mezi zame ˇstnavatelem a zame ˇstnancem vyjasnit - du ˚ve ˇrnost - me ˇli byste respektovat du ˚ve ˇrnost informacı ´ o klientech nebo zame ˇstnavateli - zpu ˚ sobilost - me ˇli byste si by ´t ve ˇdomi sve ´ ´ urovne ˇ a nepr ˇijı ´mat ve ˇdome ˇ pra ´ci, ktera ´ je nad vas ˇe schopnosti - dodrz ˇovat autorska ´ pra ´va, patenty apod. - porus ˇova ´nı ´m mu ˚z ˇete uve ´st do potı ´z ˇı ´ nejen sebe - nezneuz ˇı ´vat cizı ´ poc ˇı ´tac ˇe napr ˇ. pro provozova ´nı ´ programu ˚, se ktery ´mi by vlastnı ´k nesouhlasil Autorsky ´ za ´kon .............. * pokud se z ˇivı ´te SW, je z ˇivotne ˇ nutne ´ zna ´t autorsky ´ za ´kon (121/2000 Sb. ”Za ´kon o pra ´vu autorske ´m, o pra ´vech souvisejı ´cı ´ch s pra ´vem autorsky ´m a o zme ˇne ˇ ne ˇktery ´ch za ´konu ˚”) viz http://www.nkp.cz/o_knihovnach/00-121.htm - z § 2 vyply ´va ´, z ˇe poc ˇı ´tac ˇovy ´ program (”je-li pu ˚vodnı ´ v tom smyslu, z ˇe je autorovy ´m vlastnı ´m dus ˇevnı ´m vy ´tvorem”) i jeho jednotlive ´ vy ´vojove ´ fa ´ze a c ˇa ´sti jsou pr ˇedme ˇtem ochrany podle AZ; podle § 65 je chra ´ne ˇn jako dı ´lo litera ´rnı ´ - § 5, § 11 a § 26: autorem je fyzicka ´ osoba, ktera ´ dı ´lo vytvor ˇila, autorstvı ´ nelze pr ˇeve ´st nebo se ho vzda ´t * s AZ souvisı ´ § 152 trestnı ´ho za ´kona: ”Kdo neopra ´vne ˇne ˇ zasa ´hne do za ´konem chra ´ne ˇny ´ch pra ´v k autorske ´mu dı ´lu ... bude potresta ´n odne ˇtı ´m svobody az ˇ na dve ˇ le ´ta nebo pene ˇz ˇity ´m trestem nebo propadnutı ´m ve ˇci.” * licence - § 12 a § 46: autor ma ´ pra ´vo sve ´ dı ´lo uz ˇı ´t a ude ˇlit jine ´ osobe ˇ smlouvou
zswi/pDscm.d
zswi/pDscm.d
3. ledna 2005
149
licenci k jednotlivy ´m zpu ˚sobu ˚m nebo ke vs ˇem zpu ˚sobu ˚m uz ˇitı ´ (uz ˇitı ´ podle AZ = rozmnoz ˇova ´nı ´, rozs ˇir ˇova ´nı ´ atd.; rozmnoz ˇova ´nı ´ je podle § 66 i ”vytvor ˇenı ´ rozmnoz ˇeniny (nezbytne ´) k zavedenı ´ ... programu do pame ˇti poc ˇı ´tac ˇe”) . § 49: licence mu ˚z ˇe by ´t vy ´hradnı ´ nebo nevy ´hradnı ´ (vy ´hradnı ´ = autor nesmı ´ poskytnout licenci tr ˇetı ´ osobe ˇ) . § 49: povinnou na ´lez ˇitostı ´ licence je vy ´s ˇe odme ˇny nebo zpu ˚sob jejı ´ho urc ˇenı ´ ˇeske . § 50: nenı ´-li v licenci r ˇec ˇeno jinak, platı ´ pouze na ´ uzemı ´ C ´ republiky . § 50: nenı ´-li urc ˇeno jinak, platı ´ max. jeden rok (!!!) - § 58: zame ˇstnavatel vykona ´va ´ svy ´m jme ´nem a na svu ˚j ´ uc ˇet autorova majetkova ´ pra ´va k dı ´lu, ktere ´ autor vytvor ˇil ke splne ˇnı ´ svy ´ch povinnostı ´ k zame ˇstnavateli (nenı ´-li sjedna ´no jinak) . nenı ´-li sjedna ´no jinak, zame ˇstnavatel mu ˚z ˇe dı ´lo zver ˇejnit pod svy ´m jme ´nem, upravovat atd. . poc ˇı ´tac ˇove ´ programy se povaz ˇujı ´ za zame ˇstnanecka ´ dı ´la i tehdy, byla-li vytvor ˇena na objedna ´vku * licence platna ´ v pra ´vnı ´m r ˇa ´du jine ´ zeme ˇ nemusı ´ by ´t platnou licencı ´ podle c ˇeske ´ho AZ a naopak (zejme ´na pokud v licenci chybı ´ ne ˇktere ´ ze za ´kona povinne ´ ustanovenı ´) * podle c ˇeske ´ho AZ vznika ´ pra ´vo autorske ´ k dı ´lu v okamz ˇiku, ”kdy je dı ´lo vyja ´dr ˇeno v jake ´koli objektivne ˇ vnı ´matelne ´ podobe ˇ” - naproti tomu v jiny ´ch jurisdikcı ´ch je poz ˇadova ´no uve ´st informaci o copyrightu ve tvaru: Copyright ˇR: * pr ˇı ´klad licence platne ´ v C Copyright 2004 Za ´padoc ˇeska ´ univerzita v Plzni Za ´padoc ˇeska ´ univerzita v Plzni tı ´mto poskytuje nabyvateli rozmnoz ˇeniny tohoto poc ˇı ´tac ˇove ´ho programu a jeho dokumentace (da ´le jen ”Software”) bezu ´platne ˇ celosve ˇtovou a c ˇasove ˇ neomezenou nevy ´hradnı ´ licenci ke vs ˇem zpu ˚ sobu ˚m uz ˇitı ´ Software vc ˇetne ˇ zejme ´na pra ´va Software rozmnoz ˇovat a rozs ˇir ˇovat, s pra ´vem upravovat Software a me ˇnit jeho na ´zev, spojovat Software s jiny ´mi dı ´ly a zar ˇazovat Software do de ˇl souborny ´ch.
❉
Za´klady softwarove´ho inzˇeny´rstvı´
150
zswi/pDscm.d
Pouzˇita´ literatura: 1. Scott W. Ambler, Larry L. Constantine: The Unified Process Elaboration Phase. CMP Books, 2000. 2. Kent Beck: Extreme Programming Explained. Addison-Wesley, 2000. 3. Barry W. Boehm: A Spiral Model of Software Development and Enhancement. In IEEE Computer 21(1988), pp. 61–72. 4. Barry Boehm, Prasanta Bose: A Collaborative Spiral Process Model Based on Theory W. In Proceedings, 3rd International Conference on the Software Process, Applying the Software Process, IEEE 1994. 5. Barry W. Boehm, Tony Ross: Theory-W Software Project Management: Principles and Examples. In: IEEE Transactions on Software Engineering, vol. 15 no. 7, July 1989. 6. Grady Booch, James Rumbaugh, Ivar Jacobson: The Unified Modeling Language User Guide. Addison-Wesley, 1999. 7. Frederick P. Brooks, jr.: The Mythical Man-Month. Essays on Software Engineering, Anniversary Edition. AddisonWesley, 1995. 8. Brad J. Cox: Object Oriented Programming. An Evolutionary Approach. Addison-Wesley, 1987. 9. Tom DeMarco, Timothy Lister: Peopleware. Productive Projects and Teams, 2nd ed. Dorset House Publishing, 1999. 10. Norman E. Fenton: Software Metrics. Chapman & Hall, 1991. 11. Gail Freeman-Bell, James Balkwill: Management in Engineering. Prentice Hall, 1996 12. Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides: Design Patterns. Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995. 13. James Gosling, Henry McGilton: The Java Language Environment. A White Paper. Sun Microsystems, 1996 14. Ralph E. Johnson: Frameworks = Components + Patterns. CACM October 1997, Vol. 40, No. 10., pp. 39-42. 15. Steve McConnell: Code Complete. A Practical Handbook of Software Construction. Microsoft Press, 1993. 16. OMG Unified Modeling Language Specification, Version 1.5. OMG, 2003. 17. Meilir Page-Jones: Za´klady objektoveˇ orientovane´ho na´vrhu v UML. Grada 2001. 18. Petr Paleta: Co programa´tory ve sˇkole neucˇ´ı. Computer Press, Brno 2003. 19. Roger S. Pressman: Software Engineering: A Practitioner’s Approach, 6th edition. McGraw-Hill, 2005. 20. Karel Richta, Jirˇ´ı Sochor: Softwarove´ inzˇeny´rstvı´ I. Vydavatelstvı´ CˇVUT, Praha 1996 (dotisk 1998). 21. James Rumbaugh, Nichael Blaha, William Premerlani, Frederick Eddy, William Lorensen: Object-Oriented Modeling and Design. Prentice-Hall, 1991. ˇ epa: Programova´nı´ ve velke´m. Softwarove´ noviny 5/2003, str. 18-27. 22. Va´clav R 23. Joseph Schmuller: Myslı´me v jazyku UML. Grada, Praha 2001. 24. Stefan Sigfried: Understanding Object-Oriented Software Engineering. IEEE Press, 1996. 25. Ian Sommerville: Software Engineering, 6th ed. Addison-Wesley, 2001 26. SWEBOOK: Guide to the Software Engineering Body of Knowledge, Trial Version. IEEE 2004.
