3. Zkladn techniky analzy a nvrhu softvrovch systmov ----------------------------------------------------------- ivotn cyklus programu predstavuje hrub ncrt aktivt pri vvoji softvrovch systmov. V kontexte ivotnho cyklu programu predstavuje metodolgia sbor pravidiel a presn popis postupu pri vvoji softvrovho systmu, ie spresnenie jednotlivch etp ivotnho cyklu do konkrtnych krokov a loh. V sasnosti sa v praxi pouva viacero metodolgi, napr. SSADM a MERISE ako najviac roziren tandardy, spolu s mnostvom metodolgi vyvinutch na zklade pecifickch poiadaviek konkrtneho producenta softvru. Metodolgia pouivan v uritej softvrovej firme mus by pre potreby tejto firmy podrobne popsan a zdokumentovan. Pouivan metodolgia mze by bu prevzat, "domca", alebo zskan prostrednctvom poradenskej firmy. Pod prevzatou metodolgiou sa rozumie aplikcia normy tandardnej metodolgie pre potreby konkrtnej softvrovej firmy. V tomto prpade prevedie firma podrobn analzu dostupnch materilov a metodolgiu zavedie do praxe firmy. Tento prstup je vhodn pre firmy, ktor maj sksenosti s vvojom vcsich systmov a chc da vlastnmu procesu vvoja metodologick zklad. Domca metodolgia je metodolgia vypracovan v rmci firmy, ktor ju nsledne aj pouiva. Tento prstup vyaduje mnostvo vedomost a najm mnostvo praktickch sksenost s rozsiahlymi softvrovmi projektami. Preto k vypracovaniu vlastnch metodolgi pristupuj iba vek a renomovan softvrov firmy. Zainajcim softvrovm firmm sa doporuuje aplikova zskan metodolgiu od pecializovanej konzultanej firmy. Takto konzultan firmy maj dostatok sksenost s vvojom a prispsobenm existujcich metodolgi specifickm poiadavkm konkrtnej softvrovej firmy. Konzultan firmy maj zrove sksenosti so zavdzanm tchto metodolgi do praxe zkaznckych firiem. Metodolgia vo vcsine prpadov pozostva z nasledovnch komponentov: - techniky definujce ako realizova jednotliv cinnosti - truktrny model pecifikujci kedy vykonva jednotliv kroky v metodolgii a ich nvznos (tzv. metdy) - zoznam tandardnch dokumentov definujcich o je potrebn vykona Aplikcia presne definovanej metodolgie prinsa niekoko vznamnch vhod: - zmenuje sa riziko plytvania prostriedkov (materilnych, finannch i intelektulnych) na vvoj softvrovho systmu. Aplikcia vysksanej metodolgie znamen, e najefektvneji spsob realizcie pouivateskch poiadaviek na vytvran systm je presne definovan ete pred zaiatkom vlastnho vvoja systmu a predstavuje tandard, na zklade ktorho realizan tm postupuje. - zvsenie produktivity realizanho tmu. Toto zvsenie produktivity je mon vidie v nasledovnch dsledoch pouitia metodolgie: - aplikcia zauivanej metodolgiu pre kad projekt. Nie je potrebn metodolgiu "objavova" pre kad projekt zvlst. - metodolgia obsahuje nstroje umonujce kontrolova progres prc a zabezpeujcich spen ukonenie kadej fze projektu - metodolgia navdza ku kontrole, ktor odhal chyby a nekonzistencie u v rannch fzach projektu - vyadovanm vytvrania priebenej dokumentcie redukuje mnostvo asu potrebn k vytvoreniu dokumentcie - zvsenie kvality vyvjanho softvrovho systmu. Metodolgia vyaduje precznu pecifikciu poiadaviek pouivatea a umonuje pouivateovi pecifikovan poiadavky sptne overi. Dobr metodolgia navye nti tvorcu vytvra flexibiln systm, ktorch dokumentcia je vytvran sbene s ich vvojom. - meratenos vlastnost procesu vvoja produktu. Tm, e sa pouiva tandardizova metodolgia, stva sa proces meraten a porovnvaten. Je mon vyhodnocova a porovnva rzne projekty a na zklade takto zskanch informci v budcnosti tento proces zefektvova. - koordincia prc. Metodolgia pre kad etapu predpisuje zoznam loh, ktor je potrebn v danej etape vykona a ktor s potrebn pre prechod k nasledujcej etape. Manager projektu mze bezprostredne sledova, kde postup prc zaostva a identifikova prciny a mon dsledky zaostvania. - zjednoduenie plnovania. Bez plnovania nie je mon ni realizova. Dobr metodolgia umonuje plnova, sledova postup, iniciova opravn a korekn akcie a spresova plnovanie tak, ako postupuje projekt. - poskytuje komunikan prostriedky pre castnkov projektu. V kadej etape je na vvoji systmu zainteresovanch viacero profesi odbornkov. Metodolgia pre kad etapu predpisuje komunikane prostriedky tak, aby boli zrozumiten pre vetkch, ktor s na danej etape zainteresovan. Jedn sa najm o komunikciu: - pouivate - analytik - analytik - programtor - analytici - vedenie projektu Komunikcia je vylepen zavedenm grafickch formalizmov a pouivanm truktrovanho textu namiesto rozsiahleho slovnho popisu. Kad metodolgia obsahuje shrn technk, ktor sa pouivaj pre vytvranie a opis produktov (vstupnch dokumentov) rznych etp. Tieto techniky bvaj rznorod tak, aby zachytili rzne aspekty opisu vytvranho systmu. Vo vebecnosti je potrebn zachyti nasledovn aspekty: - funknos systmu a jeho funkn dekompozciu - dajov struktru a vzahy medzi dajovmi truktrami - asov zvislosti (najm casov nslednos) Pre opis tchto aspektov sa v praxi vyuiva cel skla existujcich technk. Pouivan techniky je mon rozdeli do troch vekch skupn: - techniky pre systmov analzu. Pouivaj sa pri analze pouivateskch poiadaviek a architektonickom nvrhu systmu. Do tejto skupiny partia nasledovn techniky: - spolon nvrh (Joint Application Design) - diagramy toku dt (Data Flow Diagram) - dajov slovnky (Data Dictionary) - entitno-funkn matice - modely ivotnho cyklu entt (Entity Life Histories) - rozhodovacie tabuky (Decision Table) - analza zaaenia (Workload Analysis Chart) - stavov diagramy (State Transition Graphs) - techniky pre modelovanie dajov. Tieto techniky slzia na pecifikciu truktry dajov a ich vzjomnch zvislost. K tejto skupine technk patria: - modelovanie dajov (Data Model Diagram) - entito-relan diagramy (Entity-Relationship Diagram) - normalizcia - techniky pre systmov nvrh. Tieto techniky slzia k opisu nvrhu systmu na rznych rovniach. Patria sem: - truktrne diagramy (Structure Chart) - akn diagramy (Action Diagram) - vvojov diagramy (Flow Chart) - prototypovanie pouivateskch rozhran (Illustrative Output) - techniky pre implementciu. Implementan techniky slzia pre zabezpeenie kvality vytvranho kdu realizujceho systmov nvrh. Patr sem najm: - truktrovan programovanie Z uvedenho prehadu vidno, e spektrum pouivanch technk je irok. Vo zvyku tejto kapitoly sa budeme venova opisu jednotlivch technk. 3.1. Spolon nvrh ------------------- Spolon nvrh (Joint Application Design) predstavuje techniku pouivan pri identifikcii a analze pouivateskch poiadaviek. Jej vyuitie je rovnako v etape architektonickho nvrhu systmu. Pvodne bola tto technika vyvinut firmou IBM na zaiatku 80-tych rokov a scasnosti sa tto technika rozirila vaka monosti ustanovenia konsenzu u v prvch etapch ivotnho cyklu vyvjanho systmu. Podstatou techniky spolonho nvrhu je intenzvne 2 a 4 dov stretnutie reprezentatvnych pouivateov so systmovmi analytikmi, na ktorom sa analyzuj dodan poiadavky, odstrauj sa rozpory a nekonzistencie v nich a vyber sa z monch alternatv. Pre tvorbu pecifikcie a kostry architektonickho nvrhu systmu bva potrebnch viacero JAD stretnut. Vsledkom tchto stretnut je jednak ucelen specifikcia systmu, ako aj kostra architektonickho nvrhu systmu reprezentujca vybran alternatvu pre realizciu systmu, ktor sa stvaj zvznmi pre obe zainteresovan strany. Na JAD stretnut s za zadvateov projektu prtomn vybran skupiny pouivateov, zodpovedn za jednotliv funkn moduly projektovanho systmu, tzn reprezentujci jednotliv organizan subjekty pouivateskej organizcie. lohou tejto skupiny je presn specifikovanie poiadaviek, identifikcia prpadnch konfliktov a ich rieenie. Rovnako je ich lohou vber z alternatv dosahovania poadovanch vlastnost predkladanch analytikmi a stanovenie priort jednotlivch poiadaviek. Tvorcovia systmu mzu by taktie ucastnkmi stretnutia, avak iba v lohe pozorovateov. Do diskusi by nemali zasahova. Tvorcov systmu v tomto ohade zastupuje vedci projektu, ktor sa na stretnut mus zcastni.. Stretnutie je moderovan modertorom, pecilne pre tento cel vybranm. Jeho hlavnou lohou je riadenie diskusie a jej zameranie na problm "ak informcie je potrebn spracovva" a neskznu k rieeniu problmu "ako realizova spracovanie informci". Na stretnut mus by prtomn taktie zapisovate, ktor zaznamenva prijat rozhodnutia. Vstupom zo spolonho stretnutia by mali by nasledovn dokumenty: - podrobn specifikcia pouivateskch poiadaviek - modely procesov (napr. diagramy toku dt) - dtov modely, resp. defincie dajov - spracovatesk poiadavky - nvrhy vstupnch zostv a vstupnch vstupnch obrazoviek - operan tok - oakvan prnosy pre pouivatea - pecifikcia kritickch atribtov spen zavsenie JAD stretnutia vyaduje dlhodobejiu prpravu. Vchodiskom s podklady pre stretnutie pripraven skupinou analytikou, ktor s doruen kadmu castnkovi stretnutia. Tieto podklady mzu obsahova jednak vsledky predchdzajcich analz k overeniu, zoznam otzok, ktor je potrebn na nasledujcom strenut vyrieit" ako aj zoznam alternatv rieenia vybranch problmov. Pre vlastn stretnutie je dleit nleit prprava pln nasadenie kadho z castnkov. Z tohoto dvodu je vhodn stretnutie organizova mimo zadvateskej organizcie, aby nikto nebol rozptyovan kadodennmi problmami svojho pracoviska. Pri vlastnom stretnut je vhodn vyuiva audiovizulne prostriedky a hlavne prostriedky umonujce modelova, resp. prototypova aspekty pecifikcie (napr. pouivatesk rozhrania). Pre spech stretnutia je potrebn venova pozornos najm nasledovnm aspektom: - presvedi najvysi management o vhodnosti tejto metdy zska jeho podporu - starostliv vber castnkov stretnutia - sksen modertor stretnutia - prprava a plnovanie stretnutia, defincia oakvanch vsledkov stretnutia Technika spolonho nvrhu prinsa pri jej sprvnej aplikcii niekoko nespornch vhod. Uvedieme aspo niekoko z nich: - skrten cas pri tvorbe pecifikcie a architektonickho nvrhu - pritireiv poiadavky sa identifikuj pomerne skoro a na spolonom stretnut, ako analzou dielich poiadaviek od rznych skupn pouivateov - zvsenie kvality nvrhu, pretoe poiadavky s jasnejie a reprezentuj vsledok konsenzu - pouivatelia s zainteresovan na vvoji systmu, preto nadobdaj pocit spolupatrinosti k systmu (jeho vlastnctva) 3.2. Diagramy toku dt ---------------------- Diagram toku dajov predstavuje grafick reprezentciu toku a spracovania dajov v analyzovanom, resp. navrhovanom systme. Reprezentuje vsledky truktrovanej analzy scasnho systmu spracovania informci, alebo poiadavky spracovania v navrhovanom systme. V diagramoch toku dt (alej budeme pouiva skrten oznaenie DFD) sa vyskytuj nasledovn typy entt: - procesy - toky dajov (data-flow) - extern entity - dajov archvy (data-store) Pre oznaenie tchto entt sa v praxi pouivaj dve sady symbolov: DeMarco-Yourdon a Gane-Sarson, ktor s ilustrovan na OBR.3.1. Obe sady symbolov s z hadiska pouitia ekvivalentn. Pri pouivan sa doporuuje nemiea symboly z oboch mnoin, pretoe to mze vies k nedorozumeniam. OBR.3.1. Zkladn entity DFD (DeMarco-Yourdon, Gane-Sarson) Kad z uvedench entt v DFD je mon identifikova menom. Tto identifikcia by mala by opisn, tzn. mala by vyjadrova funkciu, resp. postavenie danej entity v procese spracovania informci v analyzovanom, resp. vytvranom systme. Napriek nzvu, podstatou DFD je opis procesov v systme a toku dajov medzi jednotlivmi procesmi. Pre lepie pochopenie podrobnejie opseme jednotliv entity DFD. EXTERN ENTITY -------------- Prvm nvrhovm rozhodnutm pri budovan softvrovch systmov je definovanie rozhrania systmu na okolit prostredie, resp. jeho kontextu v okolitom prostred spracovania informci. Toto rozhranie (kontext) rozdeuje vetky entity na intern (tzn. obsiahnut v systme) a extern, ktor sa bud nachdza mimo systmu. Extern entity z hadiska systmu predstavuj informan vstupy a vstupy a v skutonosti mzu reprezentova pouivateov, organizcie a in systmy spracovania informci, s ktormi vyvjan alebo analyzovan systm komunikuje. Extern entity sa nachdzaj iba v kontextovom DFD, ktor je niekedy nazvan aj DFD 0-tej rovne. Kontextov DFD mze by vo veobecnosti vemi zloit. Aby sa zabrnilo kriovaniu dajovch tokov (a tm znzeniu prehadnosti DFD) je povolen pouiva viacero externch entt reprezentujcich jeden extern objekt. Tieto extern entity je potrebn oznai ako duplikty tak, ako je to ilustrovan na OBR.3.2. Tento obrzok zrove ilustruje, e i alie entity *konkrtne data-store) je mon reprezentova duplicitne. OBR.3.2. Duplikty entt v DFD Ako prklad pouitia externch entt v kontextovom DFD je mon uvies kontextov DFD pre systm spracovania reklamci v uritom abstraktnom podniku. Predpokladajme, e tento podnik potrebuje zavies automatizovan systm pre evidenciu a spracovanie reklamci. Vstupy do systmu (tzn. prijat reklamcie) zadva reklaman oddelenie (z hadiska systmu extern entita). Toto oddelenie m zrove ma k dispozcii prehad nespracovanch reklamci, z ktorch vyberie jednu a spracuje ju. Tm sa vybran reklamcia stane spracovanou. Systm by mal zrove poskytova managementu (alia extern entita) zkladn informcie pre podporu rozhodovania, napr. zoznam najviac reklamovanch vrobkov. Ilustrcia kontextovho DFD pre takto vemi jednoducho pecifikovan systm je na OBR.3.3. OBR.3.3. kontextov diagram pre prklad spracovania reklamci TOKY DAJOV ----------- Toky dajov (data-flow) reprezentuje informan prepojenie medzi ostatnmi typmi entt v DFD. Tok dajov je reprezentovan sipkou, ktor zrove uruje smer toku dajov. Pri vytvran tokov dajov v DFD diagrame si treba uvedomi, e tok dajov mus reprezentova udaje, resp. presvan informcie. Tto zsada je pri tvorbe DFD najviac poruovan najm zainajcimi analytikmi. astokrt sa tok dajov pouiva na vyjadrenie nslednosti krokov v spracovan udajov, o je prstup prevzat z vvojovch diagramov (o rozdieloch DFD a vvojovch diagramov budeme hovori neskr). Pre vyvarovanie sa chb tohoto druhu je vhodn dodriava nasledovn pravidl: - toky dajov je vhodn nazva podstatnmi menami. Pokia tok dajov takto nie je mon nazva, tak tok dajov asi neexistuje. V prklade na OBR.3.3. by chybe tohoto druhu zodpovedal nzov "Zskaj nespracovan reklamciu". V danom prpade by tok dajov reprezentoval akciu alebo tok riadenia medzi procesmi a nie skuton tok dajov. - pokste sa popsa struktru dajov v toku dajov. Ak toto nie je mon, tak potom tok dajov v skutonosti neexistuje. V prklade napr. tok dajov "Najviac reklamovan vrobky" pozostva z prvkou s nasledovnou truktrou: - identifikcia vrobku - celkov reklamovan mnostvo vrobku - kad tok dajov mus zaina alebo koni v procese, pretoe daje z danho toku s bu vsledkom spracovania istho procesu, alebo s vstupom pre spracovanie v istom procese. PROCESY ------- Procesy reprezentuj spracovanie alebo akcie vykonvan lumi, strojmi alebo poitami nad vstupujcimi dajmi (cez data-flow) a produkujce vstupn udaje (do data-flow). Men procesov zvisia na rovni abstrakcie, ktor dan DFD vyjadruje. Proces mze reprezentova cel systm, subsystm, alebo konkrtnu funkciu. Meno procesu by malo identifikova cinnos, ktor sa v danom procese prevdza. Proces m vstupn a vstupn toky dajov. Kad proces by mal ma aspo jeden vstupn a aspo jeden vstupn tok dajov. Na tomto mieste je potrebn si uvedomi, e toky dajov vstupujce do procesu nijako neidentifikuj v akej kombincii musia by udaje k dispozcii pre spracovanie, tzn. asovanie procesu. Tieto detaily s obsiahnut k popise procesu, nie v popise tokov dajov v DFD. Na OBR.3.3. je kontextov diagram systmu obsahujci jedin proces. Tento proces reprezentuje spracovanie informci v celom navrhovanom systme. Vznamnou vlastnosou DFD je monos opisu analyzovanho alebo vytvranho systmu na viacerch rovniach abstrakcie. Tto vlastnos v praxi znamen, e poda potreby je mon kad proces v DFD dekomponova na ali DFD popisujci dan proces na nisej rovni abstrakcie. Procesy, ktor sa alej nedekomponuj sa nazvaj primitvne procesy. Dekompozcia procesu je ilustrovan na OBR.3.4. Dan DFD reprezentuje DFD 1. rovne, ktorej rove abstrakcie je nisia ako rove abstrakcie kontextovho DFD. V tomto prpade dan DFD obsahuje 4 procesy, reprezentujce jednotliv cinnosti systmu vykonvan pri spracovan reklamci. OBR.3.4. DFD dekompozcie kontextovho DFD DATA-STORE ---------- Entita typu data-store slzi na reprezentciu archivcie dajov v systme. Mono ju prirovna k internej pamti, ktor vak mze uchovva prvky rznej truktry (napr. spracovan aj nespracovan reklamcie, ako vyplva z OBR.3.4.). Kad miesto v systme, ktor akumuluje daje bude reprezentovan entitou typu data-store, napr. poitaov sbor, archv alebo ann. Nzov entity data-store m zodpoveda udajom, ktor s uchovvan. Pre zabrnenie kriovania tokov dajov je v DFD mon pre reprezentciu jednej entity typu data-store poui grafickch symbolov. V tomto prpade duplicita mus by oznaen poda konvencie na OBR.3.2. Pre sprvne vytvranie DFD je okrem u uvedench pravidiel vhodn pozna ete nasledujce: - iba procesy mzu by pripojen k entitm typu data-store, tzn. iba procesy mzu ita a modifikova udaje uchovvan v systme. - nie je vhodn pouiva reprezentciu tokov dajov pomocou obojsmernch ipiek, pretoe smer toku dajov je dleit. Smer toku dajov je mon interpretova nasledovne: - tok dajov z data-store do procesu znamen, e proces pouiva daje (pouiva, nie ita). V prpade e po pouit sa daj v data-store zrui, je potrebn poui specilnu nzvov konvenciu pre tok dajov. - tok dajov z procesu do data-store, e proces modifikuje obsah data-store. Modifikcia mze znamena: - pridanie alebo uchovanie novho zznamu - zruenie existujceho zznamu - modifikciu obsahu existujceho zznamu - pre programtorov je jasn ze napr. pre modifikciu obsahu zznamu je potrebn tento zznam najskr sprstupni. Takto rove detailu nie je potrebn zahrnt do DFD nakreslenm spojenia procesu a data-store v oboch smeroch. Dleit je iba vsledok, tzn. modifikcia obsahu data-store. V tomto prpade bude smer toku dajov veden z procesu do data-store. - mnoh procesy pouivaj a aj modifikuj udaje z data-store. V tomto prpade je potrebn nakresli udajov toky spjajce obojsmerne proces a data-store. Najm pre analytikov-zaiatonkov, ktor maj predchdzajce sksenosti s vvojovmi diagramami, mze by pouitie DFD spoiatku obtiane. Uveme preto explicitne rozdiely medzi vvojovmi digramami a DFD diagramami: - procesy v DFD mzu by vykonvan paralelne. Vvojov diagramy reprezentuj sekvenciu procesov a riadenie nad aktivitou. DFD nepopisuje riadenie, tzn. as a spsob aktivcie jednotlivch procesov. - DFD zachytva tok dajov cez vytvran systm. Vvojov diagram zachytva sekvenciu jednotlivch krokov algoritmu realizujceho spracovanie. DFD neumonuj (a ani sa o to nesnaia) zachyti cykly a vetvenia (if-then-else) pri opise spracovania - DFD popisuj procesy, ktor mzu ma v zsade odlin casovanie (napr. vber a vkladanie na bankov konto), priom toto asovanie priamo nedefinuj Pouitie DFD je v procese analzy systmu vznamn. Dleitou vlastnosou DFD je, e umonuj modelova systm na rznej rovni abstrakcie. Nisia rove abstrakcie sa zska dekompozciu procesu z vysej rovne abstrakcie do samostatnho DFD (ako je to zrejm na OBR.3.3. a OBR.3.4.). Tto dekompozcia koni po dosiahnut elementrnych (primitvnych) procesov. Elementrnym procesom sa vo veobecnosti nazva tak proces, ktorho opis sa zmest na jednu stranu dokumentu formtu A4. DFD sa v mnohch metodolgich rozdeuj na fyzick a logick. Fyzick DFD opisuj akm spsobom systm dosahuje analyzovan alebo poadovan sprvanie. S v nich zachyten fyzick zvislosti v analyzovanom systme, napr. asov zvislosti (aktivcia procesu napr. raz za de, aktivcia procesu po dosiahnut isteho stavu at.) a fyzick podstata informci (napr. "modr dodvkov list"). Logick DFD opisuj co systm rob, priom sa abstrahuje od toho, ako systm realizuje poadovan funkcie. Na tejto rovni sa neuvauj casov zvislosti, ako aj materilna podstata informci. 3.3. dajov slovnky --------------------- dajov slovnky predstavuj prostriedok na uchovvanie rznorodch informci o analyzovanom alebo navrhovanom systme. Medzi hlavn uchovvan informcie partia informcie o entitch (produktoch a komponentoch produktov jednotlivch technk), ktor sa pri analze alebo nvrhu systmu pouili, ako aj informcie o pouivateskch a nvrhovch ohranieniach, pseudokd opisujci proces, nvrhy pouivateskch rozhran at. Vytvranie dajovch slovnkov je nevyhnutn pri vcsich softvrovch projektoch. Dleit pri vytvran slovnkov je, e treba dodriava nvrhov disciplnu a kad nov entitu automaticky vloi do slovnka a popsa. dajov slovnky s podstatnou scasou dokumentcie vytvranho systmu. Pre kad entitu s v slovnku uchovvan specifick informcie o nej. Jedn sa najm o popis danej entity, jej vlastnosti, miesto jej vskytu, jej kauzlne vzby k alim entitm, ale najm vzby k pouivateskm a nvrhovm poiadavkm. Tieto kauzlne vzby pomhaj identifikova tie asti systmu, ktor je potrebn prepracova pri modifikcii niektorej z tchto poiadaviek vyplvajcich z potrieb drby systmu. dajov slovnky mzu by udriavan v rznej forme. Jedn sa najm o ich udriavanie vo forme rozsiahlej dokumentcie "na papieri", ako aj vo forme poitaovch sborov v CASE systmoch. Obe tieto formy uchovvania dtovch slovnkov s ekvivalentn. 3.4. Entitno-funkn matice --------------------------- Technika entitno-funknch matc tvor rozhranie medzi funknou a dtovou analzou. Jej cieom je identifikcia vzahov medzi funkciami (procesmi) a dtovmi entitami uchovvanmi v entitch typu data-store. Pri vytvran entitno-funknej matice sa mnohokrt vychdza z dajovho slovnka. Vytvor sa tabuka, ktorej riadky predstavuj udajov struktry a stpce predstavuj jednotliv procesy. Jednotliv prvky tabuky mzu by vyplnen jednm z nasledovnch psmen, ak dan proces uritm spsobom ovplyvuje dan dtov entitu: I - dajov struktra je vkladan (vytvran) danm procesom R - dajov struktra je sprstupovan (itan) danm procesom M - dajov struktra je modifikovan danm procesom D - dajov struktra je danm procesom zruen A - dajov struktra je archivovan danm procesom Entitno funkn matica slzi na analzu doposia vytvorenej pecifikcie systmu a pouiva sa na jej validciu. Pre kad udajov struktru (entitu) je potrebn identifikova cel jej ivotn cyklus, tzn. procesy ovplyvujce vytvorenie, modifikciu, pouivanie a zruenie danej entity. Ak u nejakej entity tento cel zivotn cyklus nie je mon identifikova, pravdepodobne je v pecifikcii systmu chyba. Prklad entitno-funknej matice pre problm spracovania reklamci je na OBR.3.5. OBR.3.5. - entitno-funkn matica Z entitno-funknej matice na OBR.3.5. je vidno, e pre entitu "spracovan reklamcie" nie je definovan opercia zruenia. Znamen to, e uveden analza problmu mze by nepln, pretoe uveden entita v systme iba vznik a mze spsobi problm so zaplnenm dostupnho pamtovho priestoru. 3.5. Graf ivotnho cyklu entt ------------------------------- Technika ivotnho cyklu entity zko nadvzuje na entitno-relan matice. Riadok v tejto matici definuje akm spsobom je dan entita ovplyvnen jednotlivmi procesmi (funkciami). Popisuje sekvenciu, v ktorej s funkcie na dan entitu aplikovan, alebo stavy, v ktorch je mon dan funkciu aplikova. Tieto informcie umonuje reprezentova technika grafu ivotnho cyklu entity, ktor sa vytvra pre kad entitu z entitno-relanej matice. Prvkami grafu ivotnho cyklu entity s procesy, ktor transformuj stavy spracovania danej entity, ako aj vlastn stavy spracovania danej entity. Tieto stavy mzu by nazvan menom, alebo jednoducho oislovan. Stavy v grafe uruj podmienky aplikovatenosti jednotlivch funkci. Technika ivotnho cyklu entity je pouivan k validcii pecifikcie. Vytvranie grafov umonuje identifikova chbajce informcie o asovan a zvislostiach jednotlivch procesov, ktor s nevyhnutn k sprvnej analze vytvranho systmu. Grafy ivotnho cyklu entt s ilustrovan na OBR.3.6. a OBR.3.7. OBR.3.6. - graf ivotnho cyklu pre nespracovan reklmacie OBR.3.7. - graf ivotnho cyklu pre spracovan reklamcie Grafy ivotnho cyklu programu umonuje analytikovi zamera sa na konkrtnu entitu a analyzova vetky funkcie a ich asovanie, ktor tto entitu ovplyvuj. 3.6. Rozhodovacie tabuky ------------------------- Rozhodovacie tabuky predstavuj techniku umonujcu zoskupova akcie, ktor maj by systmom vykonvan, spolu s podmienkami, za ktorch je mon tieto akcie vykona. Rozhodovacia tabuka pozostva zo tyroch ast: - horn lav cas pozostva z podmienok. Tieto podmienky s vyjadren ako tvrdenia, ktorm je mon priradi hodnotu. Hodnota mze by bu logick (no/nie), alebo numerick (poet det), alebo in. - horn prav cas pozostva z kombinci hodnt pre jednotliv podmienky. - doln lav cas pozostva z akci, ktor s systmom vykonvan - doln prav cas pre kad akciu obsahuje X pre kad stpec, vyjadrujci podmienky, za ktorch je dan akcia aplikovaten. Prnos pouitia rozhodovacch tabuliek spoiva v dvoch aspektoch. Tm prvm je monos analzy plnosti, konzistentnosti a jednoznanosti informci obsiahnutch v pecifikcii z hadiska spojenia akci a podmienok ich aplikovatenosti. Druhm prnosom je, e v rozhodovacej tabuke sa mzu vyskytova iba tyri typy chb: neplnos, protireivos, redundancia a viacznanos, im sa zjednoduuje analza rozhodovacch tabuliek. - neplnos znamen, e urit pravidl chbaj, tzn. logika vyhodnotenia je nepln. Neplnos je mon identifikova njdenm takej kombincie hodnt podmienok, ktor nie je pokryt ziadnou z akci. Znamen to, e v uritej kombincii podmienok by pre systm nebola definovan ziadna akcia, ktor m vykona. - protireivos mono rozdeli na prorireivos v akcich a protireivos v podmienkach. Protireivos v akcich znamen, e pri rovnakej podmienke je mon aplikova viacero akci. Znamen to, e v danom stave je mon aplikova viacero akci, ie zavdza sa nedeterminizmus. Tieto pravidl je potrebn opravi. Protireivos v podmienkach znamen, e pravidl sa lsia iba v jednej podmienke, priom akcia je rovnak. Pre tieto pravidl je mon vykona kompresiu. - redundancia znamen, e viacer pravidl maj aktivuj rovnak akcie za rovnakch podmienok. V praxi to znamen, e uveden pravidl s ekvivalentn, tzn. pouivatesk informcie s redundantn. - viacznanos znamen, e skompresovan tabuka obsahuje skryt protireenia a redundancie. Prklad plnej rozhodovacej tabuky je na OBR.3.8. OBR.3.9. ilustruje rovnak rozhodovaciu tabuku po kompresii. OBR.3.8. - pln rozhodovacia tabuka OBR.3.9. - rozhodovacia tabuka po kompresii Vznamnou vlastnosou rozhodovacch tabuliek je monos ich hierarchickho spjania, ktor umonuje zachyti i komplexn systmy. Toto spojenie je mon vloenm akcie "Prejdi na tabuku... " medzi akcie v nadradenej tabuke. Rozhodovacia tabuka sa pri analze systmu pouiva pomerne asto. Jej vhodou je presn formt pre vyjadrenie vzahov medzi akciami a podmienkami. Pouitie rozhodovacej tabuky nti analytika vytvra specifikciu, ktor je logicky pln a preto je mon nekonzistencie identifikova pomerne skoro. Rozhodovaciu tabuku je mon poui rovnako na verifikciu poidaviek na procesy, ako aj ako technick specifikciu pre programtorov. Rozhodovacie tabuky vyzeraj pomerne jednoducho. Vytvranie zloitejej tabuky je vak asovo nron a vyaduje viacero cyklov spresovania. Pri prci s pouivatemi pouitie rozhodovacch tabuliek mze prinies problmy. Pouivatelia mzu by struktrou tabuky veden k prepecifikovaniu poiadaviek uvdzanm kombinci podmienok, ktor s sce logicky mon, ale z hadiska analyzovanho systmu nerelevantn. 3.7. Analza zaaenia ---------------------- Analza zaaenia (Workload Analysis Chart) umonuje identifikciu a popis najdleitejich transakci, ktor vykonva analyzovan alebo navrhovan systm. Cieom tejto techniky je zoskupenie vetkch transakci a nslednho odvodenia odhadu vpotovho zaaenia a odozvy systmu na jednotliv transakcie. Analza zaaenia umonuje odhad zachovania kritickch atribtov ete pred vlastnou implementciou jednotlivch transakci, pre ktor s tieto kritick atribty definovan. Poadovan udaje o transakcich sa usporadvaj do tabuliek, v ktorch kad riadok zodpoved konkrtnej transakcii. Pre kad transakciu je mon definova jej nasledovn charakteristiky, reprezentovan stpcami tabuky: - meno transakcie - typ transakcie (on-line, batch) - zloitos (jednoduch, strednej zloitosti, zloit) - zdroj aktivcie - rozsah transakcie a v rmci neho: - rozsah naitavanch dajov - rozsah zapisovanch dajov - rozsah uchovvanch dajov - frekvencia aktivcie priemern, ako aj pikov - poadovan doba odozvy (okamit, alebo poas nonho spracovania) - prp. podmienka, kedy mono transakciu aktivova Technika analzy zaaenia umonuje u v poiatkoch analzy systmu identifikova rozsah spracovvanch informci a tm definova vkonov poiadavky na vpotov systm. Slzi taktie na upresnenie poiadaviek na jednotliv transakcie, ktor doposia nemuseli by analyzovan tak podrobne. Tto techniku mono z tohoto dvodu vyui pre kompletizciu poiadaviek v pecifikcii. Ilustrcia vsledku analzy pre transakciu spracovania reklamcie je uveden na OBR.3.10. OBR.3.10. analza zaaenia - pre operciu spracovania reklamcie 3.8. Stavov diagramy --------------------- Stavov diagramy s prostriedkom pre vyjadrenie kauzlnych a asovch svislost (nslednosti) akci a stavov v systme. Stavov diagram bva reprezentovan orientovanm grafom, kde vrcholy reprezentuj jednotliv stavy systmu alebo stavy vybranho podsystmu. Mon prechody medzi stavmi s reprezentovan orientovanmi hranami vychdzajcimi z uritho stavu a koniace v nasledujcom stave. Prechodov hrany s oznaen nasledovnmi dajmi: - podmienka, na ktor je viazan prechod medzi danmi stavmi. Touto podmienkou zvcsa bva identifikcia istej udalosti, ktor v danom stave iniciuje prechod do danho stavu. - akcia, ktor sa m aktivova pro prechode medzi dvoma stavmi. Tto akcia v konenom dsledku spsob transformciu stavu systmu do stavu reprezentovanho cieovm vrholom danej hrany. Vcsinou touto akciou bva jedna z transakci. Stavov diagramy je mon vo veobecnosti rozdeli na deterministick a nedeterministick. U deterministickch stavovch diagramov existuje v kadom stave pri zadanej podmienke iba jeden prechod k nasledujcemu stavu. U nedeterministickch stavovch diagramov existuje v danom stave za danej podmienky viacero prechodov k rznym nasledujcim stavom. Znamen to, e pre dan stav a dan podmienku nie je mon jednoznane uri nasledovn stav. Nedeterminizmu sa pri opise softvrovch systmov stavovmi diagramami snaime vyhnt. Stavov diagramy s vemi obubenou a pouivanou technikou najm pri analze vzjomnch svislost jednotlivch innost systmu. Pri tvorbe stavovho diagramu sa astokrt zist neplnos specifikcie systmu. Niektor modifikcie stavovch diagramov pouivaj aj hierarchick prstup k tvorbe stavovch diagramov. V takomto stavovom diagrame reprezentuje dan stav ali stavov diagram, ktor m definovan poiaton stav (ktor je pri prechode do danho stavu na vysej hiararchickej rovni) a koncov stav (je mon prechod ddo alieho stavu na vysej hierarchickej rovni). Stavov diagramy sa okrem analzy pouivaj i pri nvrhu. Typickm, prkladom je nvrh pouivateskch rozhran. Prklad nvrhu jednoduchho pouivateskho rozhrania je ilustrovan na OBR.3.11., hoci na tomto obrzku s definovan iba podmienky prechodu medzi stavmi, nie akcie vykonvan pri tomto prechode. OBR.3.11. 3.10. Entitno-relan diagramy ------------------------------ Modelovanie dajov predstavuje mnoinu technk poskytujcich grafick prostriedky pre opis truktry a vzjomnch vzahov medzi dajmi v systme. Modelovanie dajov sa niekedy uprednostuje pred modelovanm systmu (DFD), pretoe truktra spracovvanch dajov bva v ase pomerne mlo modifikovan, zatia co funkn charakteristika systmu sa mze podstatnm spsobom meni. daje v systme s obrazom informci vznikajcich a spracovvanch v organizcii, pre ktor sa dan softvrov produkt vyvja. Tieto informcie maj svoje pecifick charakteristiky a vzjomn svislosti. Cieom dtovej analzy a vytvorenia dtovho modelu je zabezpeenie transformcie vetkch potrebnch informci do dajovch truktr a nvrh o najvhodnejieho spsobu uchovvania tchto informci z hadiska ich nslednho spracovania. Dtov modelovanie zko svis s nslednm nvrhom schmy databzy. Dtov modelovanie vyaduje identifikciu zkladnch dtovch entt reprezentujcich spracovvan informcie a ich vzjomnch vzahov. S dtovm modelovanm svis normalizcia dajovch truktr zameran k elimincii redundancie, zabezpeenia dajovej nezvislosti a jednoznanho prstupu k dajom. Pouivanmi technikami s entitno-relan diagramy, dtov modely a normalizcia. Vhodne navrhnut dtov model mze podstatne uahi nsledn realizciu systmu. Vlastnosti "dobrho" dtovho modelu je mon zhrnt nasledovne: - dobr dtov model m by jednoduch (dtov elementy obsiahnut v uritej entite sa maj vzahova iba k danej entite). - dobr dtov model mus by neredundantn (dtov element m popisova iba jednu entitu) - dobr dtov model mus by flexibiln a adaptabiln. Entitno-relan diagramy (alej aj ERD) s prvou z pouivanch technk pre modelovanie dajov. ERD s grafickm prostriedkom pre vyjadrenie dajovch entt a vzahov medzi nimi. Cieom pouitia ERD je definovanie dajovch entt v analyzovanom, resp. navrhovanom systme a identifikcia vzjomnch vzahov medzi tmito entitami na kvalitatvnej rovni. Na rozdiel od DFD, ERD nezachycuj tok spracovania dajov. Nemono ich preto "ita" ako DFD, alebo vvojov diagramy. Hoci ERD svisia s modelovanm dajov, nezachycuj proces vzniku, modifikcie a zniku dajovch entt. ERD obsahuj dva typy objektov: dajov entity a vzahy medzi dajovmi entitami. dajov entita mze reprezentova akkovek uchovvan informciu. Entita vcsinou reprezentuje viacero vskytov objektu danho typu v relnom prostred. Ako prklad je mon uvies entitu reprezentujcu informcie o pracovnkoch firmy. Tieto informcie mzu by vo vytvranom systme reprezentovan pomocou zznamov, priom pre kadho pracovnka existuje samostatn zznam. V dtovom modele bude tto mnoinu dajov reprezentova jedin dtov entita, reprezentujca mnoinu zznamov tohoto typu. dajov entity s v ERD reprezentovan ako uzly v grafe. dajov entity s pomenovan podstatnmi menami popisujccimi objekt reprezentovan danou entitou (napr. nespracovan reklamcia, spracovan reklamcia) dajov entity reprezentuj struktrovan informciu. Pre zpis tejto truktry je mon pre kad entitu definova dajov elementy. Vo vcsine prpadov aspo jeden dajov element (alebo aj kombincia viacerch dajovch elementov) m jedinen hodnotu charakterizujcu dan udajov entitu. Takto element, resp. kombincia elementov sa nazva kuc. truktra dajovej entity pre informciu o "tovare na sklade" je ilustrovan na OBR.3.12. OBR.3.12. truktra dajovej entity Vzahy medzi entitami reprezentuj prirodzen vzahy medzi informciami reprezetovanmi danmi entitami. Vzahy medzi entitami s v ERD reprezentovan samostatnm vrcholom grafu, ktor je vloen medzi uzly grafu reprezentujce entity tohoto vzahu. Vrcholy reprezentujce vzahy medzi entitami bvaj pomenovan, priom na pomenovanie sa vcsinou pouivaj sloves. Kad takto vzah mze obsahova podrobneji popis, reprezentujci podstatu danho vzahu z hadiska pouivateskho pohadu na vzah medzi danmi entitami. Dleitou charakteristikou kadho vzahu je poiadavka kvantifikcie, tzn. stanovenia potu vskytov uritej dtovej entity pre jedin exemplr druhej dtovej entity vo vzahu. Tieto vzahy s typu: - 1 ku 1 pre jeden vskyt prvej entity vo vzahu mze existova iba jeden vskyt druhej entity, a naopak - 1 ku M pre jeden vskyt prvej entity vo vzahu mze exitova vea vskytov druhej entty - M ku N pre jeden vskyt prvej entity vo vzahu mze exitova vea vskytov druhej entty a pre jeden vskyt druhejej entity vo vzahu mze exitova vea vskytov prvej entity Kvantifikcia vzahov v ERD je vyjadren priradenm oznaenia (1 alebo M) hranm spjajcim vrchol reprezentujci dan vzah s uzlami reprezentujcimi jednotliv entity. Prklady entitno-relanch diagramov s ilustrovan na OBR.3.13. OBR.3.13. prklady entitno-relanch diagramov Kad vzah v ERD je mon interpretova obojsmerne. Informcie z entitno-relanch diagramov ilustrovanch na OBR.3.13. je preto mon cita nasledovne: 1. Ku kadej dodvke mze existova najviac jedna (tzn. 0 alebo 1) reklamcia Ku kadej reklamcii existuje prve jedna dodvka. 2. Kad faktra mze obsahova viacero fakturci dodvok. Kad fakturcia dodvky mze by obsiahnut prve v jednej faktre. 3. tudent navtevuje viacero kurzov. Kurz je navtevovan viacermi tudentami. 4. Modul obsahuje viacer moduly. Modul je obsiahnut vo viacerch moduloch. 3.10. Dtov modely ------------------- Dtov modely vyjadruj kvantitatvnu strnku modelu dajov. Na rozdiel od ERD sa v dtovch modeloch (pouiva sa aj oznaenie DMD) neprirauj vzahom pecilne uzly, ale vzahy medzi entitami identifikovanmi v ERD sa reprezentuj hranami. Z pohadu optimalizcie dtovho modelu s postaujce iba kvantitatvne aspekty modelu dajov a vynechanie uzlov reprezentujcich vzahy medzi entitami vedie k sprehadneniu tohoto modelu. ERD reprezentuje pouivatesk pohad na truktru spracovvanch informci, obsahujci aj smantiku vzahov v tomto modele. Dtov model vyjadruje analytick a nvrhrsky pohad na tto truktru dajov, v ktorom smantika vzahov medzi entitami nie je potrebn. Na reprezentciu vzahov medzi dtovmi entitami sa vyuiva viacero notci. Najpouivanejie notcie s ilustrovan na OBR.3.14. OBR.3.14. notcie pre dtov modely Ilustrcia dtovho modelu pre problm jednoduchho skladovho hospodrstva a zsielkovej sluby v Bachmanovej notcii je na OBR.3.15. OBR.3.15. dtov model Dtov model ilustrovan na OBR.3.15. je mon "ita" nasledovne: 1. Pre jednu entitu typu zkaznk mze existova viacero entt typu objednvka. Pre jednu entitu objednvka existuje prve jedna entita typu zkaznk 2. Pre jednu entitu typu zkaznk mze existova viacero entt typu reklamcia. Pre jednu entitu reklamcia existuje prve jedna entita typu zkaznk 3. Pre jednu entitu typu objednvka existuje prve jedna entita typy reklamcia. Pre jednu entitu typu reklamcia existuje prve jedna entita typy objednvka. 4. Pre jednu entitu typu objednvka mze existova viacero entt typu tovar. Pre jednu entitu tovar mze existova viacero entt typu objednvka. 5. Pre jednu entitu typu reklamcia mze existova viacero entt typu tovar. Pre jednu entitu tovar mze existova viacero entt typu reklamcia. 3.11. Normalizcia ------------------ truktra dajov a dtov model navrhnut pouivateom nie vdy zodpoved poiadavkm na efektvne uchovvanie a spracovvanie informci. Z tohoto dvodu sa prevdza transformcia tohoto modelu do modelu, ktor tieto poiadavky spna. Tto transformcia sa nazva normalizciou dtovho modelu. Normalizcia predstavuje postupn procedru transformcie dtovho modelu do jednotlivch normlnych foriem. V praxi sa pouivaj nasledovn druhy normlnych foriem: - 1. normlna forma - 2. normlna forma - 3. normlna forma Teoreticky bola odvoden ete aj 4. a 5. normlna forma, ktor sa vak v praxi nepouivaj. Cieom normalizcie je postupn transformcia dajov do 3. normlnej formy, ktor sa z hadiska efektvnosti uchovvania a spracovvania informci povauje sa dostaton. TRANSFORMCIA DO 1. NORMLNEJ FORMY ----------------------------------- Transformciu dajovho modelu do 1. normlnej formy budeme ilustrova na prklade. Majme daje o objednvkach knh organizovan tak, ako ilustruje OBR.3.16. OBR.3.16. netruktrovan udaje pred transformciou do 1. NF Pre popis transformcie dajovho modelu do normlnych foriem pre jednoduchos zavedieme nasledovn terminolgiu: tabuka bude reprezentova typ dtovej entity riadok tabuky bude reprezentova intanciu dtovej entity stpec tabuky bude reprezentova dtov element v entite Transformcia dajov do prvej normlnej formy svis s odstrnenm opakujcich sa stpcov v tabukch. Opakova sa mze bu jednotliv stpec, alebo skupiny stpcov. V prklade na OBR.3.16. sa jedn o opakovanie stpcov s nzvami "Meno", "ISBN", "Nzov", "Autor", "Cena", "Mnostvo" a "Suma". Transformcia do prvej normlnej formy sa d opsa nasledovnm algoritmom: Opakujca skupina stpcov sa vyjme z tabuky a vytvor sa nov tabuka. Kucom novej tabuky bude kuc zloen kuc pozostvajci z kuca pvodnej tabuky roziren o jednu, resp. i viacero opakujcich sa stpcov. V konkrtnom prpade je mon z pvodnej tabuky vytvori dve tabuky, jednu reprezentujcu zkaznkov a druh objednan knihy. Kucom pre tabuku zkaznkov (zvyok pvodnej tabuky) je islo zkaznka. Klcom pre tabuku objednvok (novo vytvoren tabuka) bude zloen kuc pozostvajci zo stpcov "islo zkaznka" a "ISBN". Ilustrcia vsledku transformcie je na OBR.3.17. OBR.3.17. - tabuky po transformcii do 1. NF Tabuky v 1.NF neobsahuj opakujce sa mnoiny stpcov. Kad riadok tabuky (reprezentujci intanciu uritho typu) m rovnak poet stpcov a kad stpec reprezentuje hodnoty rovnakho typu. Problmom s dajmi v 1.NF je funkn zvislos jednotlivch dtovch elementov (stpcov). Tento pojem znamen, e element A sa mus meni scasne s elementom B, inak by bola poruen dtov integrita. Tento problm riei 2.NF. TRANSFORMCIA DO 2. NORMLNEJ FORMY ----------------------------------- Entity dajovho modelu v 2.NF sa vyznauj vlastnosou, e kad element (stpec tebuky) je zvisl na celom kuci. Normalizcia do 2.NF sa prevdza iba pre tabuky so zloenmi kucmi. Pre tabuky s jednoduchmi kucmi znamen normalizcia do 2.NF mon roztepenie tabuky. Transformciu dajovch truktr z 1.NF do 2.NF je mon popsa nasledovne: Ak v uritej tabuke zistme, e niektor stpec je zvisl iba na asti kuca tabuky, tento stpec vyjmeme do samostatnej tabuky. Kucom tejto tabuky sa stane t cas kuca pvodnej tabuky, na ktorej je dan stpec zvisl. V naom prklade sa jedn o tabuku objednvok. Jej kucom je zloen kuc pozostvajci zo stpcov "islo zkaznka" a "ISBN". Analyzujme postupne zvislos jednotlivch stpcov na komponentoch kuca: "Titul" - zvis iba na stpci "ISBN" "Autor" - zvis iba na stpci "ISBN" "Cena" - zvis iba na stpci "ISBN" "Mnostvo" - zvis na stpcoch "islo zkaznka" aj "ISBN" "Suma" - zvis na stpcoch "islo zkaznka" aj "ISBN" Vsledkom normalizcie bude teda roztiepenie tabuky s objednvkami na dve tabuky: tabuku objednvok, v ktorej z pvodnej tabuky ostan stpce ,Cislo zkaznka", "ISBN", "Mnostvo" a "Suma" a nov tabuku knh, do ktorej sa presun stpce "ISBN", "Titul", "Autor" a "Cena". Vsledok je ilustrovan na OBR.3.18. OBR.3.18. tabuky po transformcii do 2.NF TRANSFORMCIA DO 3. NORMLNEJ FORMY ----------------------------------- Transformcia dajovho modelu do 3.NF znamen odstrnenie funknch vzieb medzi stpcami, ktor nie s scasou kuca. Tabuka v 3.NF m t vlastnos, e vetky stpce s zvisl iba od kuca a nie s zvisl od iadneho inho stpca. Transformciu tabuky do 3.NF je mon popsa nasledovne: Postupne sa analyzuj vetky nekucov stpce tabuky. Pre vetky stpce sa testuje ich zvislos na inch nekucovch stpcoch. Tto zvislos je mon testova poloenm nasledovnch otzok: 1. Je obsah stpca X zvisl od obsahu stpca Y, alebo naopak ? 2. Ak je znma hodnota stpca X, existuje iba jedna mon hodnota stpca Y ? Ak je odpove aspo na jednu z tchto otzok kladn, zvisl poloka sa z tabuky vyjme a vytvor sa pre u nov tabuka s kucom, na ktorej obsahu je vybrat poloka zvisl. Tto poloka (tvoriaca kuc novej tabuky) scasne ostva v pvodnej tabuke. Testovanie transformovania tabuliek do 3.NF je mon na zklade nasledovnch otzok: 1. Plat, e pre jednu hodnotu kuca tabuky v 3.NF existuje iba jedna mon hodnota dajov v danom stpci? 2. S jednotliv dtov poloky priamo zvisl na hodnote kuca? Tabuky ilustrovan na OBR.3.18. s u priamo v 3.NF. Pre transformciu do 3.NF preto uvedieme in prklad. Predpokladajme, e objednvka m struktru ilustrovan na OBR.3.19. Je zrejm, e poloky (stpce) "Meno odberatea", "Adresa odberatea" a "Telefn odberatea" nie s zvisl na kuci tvorenm polokou "islo objednvky". Vsledkom normalizcie je rozdelenie tabuky na dve tabuky (OBR.3.19), ktor spnaj podmienky 3.NF. OBR.3.19. transformcia do 3.NF KONSOLIDCIA ------------ Konsolidcia dtovho modelu je vynten mechanickm charakterom procesu normalizcie. Normalizcia zohaduje iba syntax jednotlivch entt a ich elementov, nie ich vznam. V dtovom modele mzu existova synonym, tzn. dtov elementy rovnakho informanho obsahu, ale s rznym menom. Prvm krokom konsolidcie je preto identifikcia synonm a ich nazvanie rovnakm menom. Normalizciou a identifikciou synonm mohlo vzniknt viacero tabuliek s identickmi kucmi. lohou konsolidcie je spoji tieto tabuky do jednej tabuky s vylcenm redundantnch (tzn. viacnsobnch) dtovch elementov. Pretoe spjanm sa do vytvranch tabuliek mohli dosta i zvisl elementy, je potrebn uplatni na takto vytvran tabuky test na prslunos k 3.NF a na zklade tohoto testu vykona dodaton normalizciu do 3.NF. 3.12. truktrne diagramy ------------------------- truktrne diagramy je mon zaradi k technikm vytvrania nvrhu systmovej architektry. Cieom truktrnych diagramov je zachytenie organizcie systmu alebo programu, ktor bva odvdzan zo pecifikcie vo forme DFD. Zkladnou jednotkou truktrneho diagramu je modul. Modul truktrneho diagramu je chpan ako "ierna krabika" obsahujca logiku transformcie vstupnch dajov na vstupn. Kad modul je oznaen menom charakterizujcim jeho funkciu, priom k modulu mze by pripojen podrobneji opis jeho funkcie. Komunikcia medzi modulmi reprezentuje vmenu informci, resp. tok riadenia medzi jednotlivmi komponentami analyzovanho alebo vytvranho systmu. Tieto informcie mzu ma udajov, alebo riadiaci charakter. Pri kontrukcii truktrnych diagramov sa doporuuje dodriava nasledovn zsady: - nvrh reprezentovan struktrnym diagramom by mal by vyvzen, aby mal zmeny v poiadavkch ovplyvnili iba obmedzen mnostvo modulov - je vhodn identifikova moduly, ktor s v systme asto pouivane (tzv. common modules) - moduly by mali ma mal poet vzieb na okolie a vysok stupe kohzie (vntornch zvislost) - komunikcia je mon iba medzi nadradenmi a podradenmi modulmi, nie medzi modulmi na rovnakej hierarchickej rovni - men modulov by mali vyjadrova funkciu modulu a odrza ich lohu v hierarchii modulov - iadny modul by nemal ma viac ako 7 nasledovnkov (podriadench modulov) - hierarchie truktrneho diagramu nebva vo vcsine prpadov hlbia ako 4 rovne Ilustrcia jednoduchho truktrneho diagramu pre spracovanie bankovch ctov je na OBR.3.20. OBR.3.20. truktrny diagram Transformcia vsledkov analzy do truktrneho diagramu je pomerne zloit proces. Pre vykonanie tejto transformcie sa pouivaj metdy transformanej a transaknej analzy. Pouitie tchto metd popseme v samostatnch astiach. TRANSFORMAN ANALZA --------------------- Metda transformanej analzy je uren k transformcii vsledkov analzy systmu pecifikovanej pomocou DFD do truktrneho diagramu systmu. Metdu je mon popsa ako sekvenciu nasledovnch krokov: 1. vytvorenie DFD diaramov. Pre kad DFD je potrebn skontrolova jasn nazvanie procesov a dtovch tokov. 2. identifikcia aferentnch a eferentnch ast. Aferentn vetvy zahruj vetky procesy a dajov toky, ktor slzia pre prpravu dajov a neprevdzaj vlastn spracovanie dajov charakterizujce podstatu systmu, resp. subsystmu popsanho pomocou danho DFD (napr. sprstupovanie a zskavanie dajov a ich validcia). Eferentn vetvy DFD zahruj vetky procesy a dajov toky, v ktorch daje po plnom spracovan s pripraven na vstup (napr. formtovanie, vstup z modulu). 3. identifikcia centrlnej transakcie. Oznaia sa najvntornejie dajov toky v aferentnej aj eferentnej vetve. Vytvorenia sa prepojenia medzi dajovmi tokmi v aferentnej a eferentnej vetve a toto prepojenie identifikuje centrlnu transformciu. Centrlna transformcia zahna vetky procesy definujce zkladn funkciu systmu. 4. produkcia prvotnho truktrneho diagramu. truktrny diagram reprezentuje organizciu modulov systmu do vertiklnej hierarchie. Na najvysej hierarchickej rovni truktrneho diagramu je mon vidie korepondenciu medzi modulmi a procesmi DFD. Procesy zahrnut v centrlnej transformcii s preto vhodnmi kandidtmi pre vrchol truktrneho diagramu. Vhodnho kandidta je potrebn "vytiahnu" na vrchol hierarchie a ostatn procesy umiestni na nisie hierarchick urovne. Ak sa nepodar njs vhodnho kandidta, je mon aplikova stratgiu "bring the boss from the outside", tzn. vloenie modulu vybratho mimo dan DFD, ktor bude riadi prcu ostatnch modulov. V tomto bode sa identifikuj aj moduly, ktorch pouitie je irie (common moduly), tzn. mzu by aktivovan z viacerch modulov). 5. prepracovanie truktrneho diagramu. Prvotn struktrny diagram mze poruova viacero zsad pre ich kontrukciu. Jednm z problmov v truktrnom diagrame mze by, e urit modul je nadraden vcsiemu potu alich modulov. V tomto prpade je potrebn vytvori dali riadiaci modul (podriaden pvodnmu), ktor bude nadraden casti tchto modulov. V tejto asti sa prevdza kontrola taktie kohzie a viazanosti modulov. Moduly, ktor maj siln vzjomn vzby je mon spoji do jednho modulu. Naopak, modul, ktor realizuje viacero nezvislch funkci, je mon rozdeli naviacero nezvislch modulov. Do truktrneho diagramu sa na zver dopln tok riadenia. 6. kontrola nvrhu truktrneho diagramu. Pod kontrolou nvrhu truktrneho diagramu sa rozumie kontrola vybalancovania nvrhu. V prpade, e mal zmena poiadaviek spsob zsadn zmeny v truktrnom diagrame, je mon vybra in proces ako vrchol truktrneho diagramu. Proces transformanej analzy je ilustrovan na OBR.3.21.a. a OBR.3.21.c. Na OBR.3.21.c. je truktrny diagram konkretizovan zavedenm operci vstupu a vstupu dajov, ktor tvoria listy trukrneho diagramu. OBR.3.21. TRANSAKN ANALZA ------------------ Transakn analza predstavuje prostriedok pre odvodenie truktrneho diagramu pre systm spracovvajci transakcie. Na rozdiel od transformanej analzy, ktorej vchodiskou s DFD analyzovanho systmu, transakn analza vychdza z vykonvanch transakci (napr. z vsledkov analzy zaaenia). Charakteristikou vcsiny transaknch systmov je skutonos, e transakcie vcsinou zdieaj mnoho spolonho kdu. Tradin nvrh takchto systmov bva organizovan okolo modulov spolonho kdu a pouiva prepnae pre nasmerovanie dajov na kd pecifick pre dan transakciu. Na rozdiel od tohoto prstupu sa transakn analza snai vytvori samostatn modul (alebo mnoinu modulov) pre kad transakciu. Vytvorenie truktrneho diagramu je mon aplikciou nasledovnch krokov: 1. Pre kad systmov transakciu sa vytvor samostatn modul. Ak vrchol truktrneho diagramu sa vytvor tzn. transakn centrum, ktor bva v diagrame znzorovan kosotvorcom. Transakn centrum slzi ako riadiaci modul pre aktivciu zodpovedajceho modulu pre poadovan transakciu. 2. Pre kad transakn modul sa vykon jeho dekompozcia na podraden moduly. Hbka dekompozcie nie je uren, zvis od zloitosti konkrtnej transakcie. 3. Identifikuj sa spolon moduly pre realizciu identickch aktivt v rznych transakcich. Tieto moduly sa oznaia ako common a ponech sa iba jeden ich vskyt v truktrnom diagrame. Prstupom transaknej analzy je teda predpoklad o rozdielnosti vetkch modulov a pokia sa preukze ich zhoda.4. truktrny diagram sa prekontroluje, i zodpoved zsadm nvrhu truktrnych diagramov. V praxi bva transaknm centrom aktivovanch vea transaknch modulov. V tomto prpade sa medzi transakn centrum a dan moduly vloia fiktvne moduly, ktor realizuj postupn odovzdvanie riadenia jednotlivm transaknm modulom. 3.13. Vvojov diagramy ----------------------- Vek skupinu technk tvoria techniky reprezentujce zpis kostier procesov (process outlines). Tieto techniky zachytvaj spsob dosahovania poadovanej funknosti procesov definovanm vzahu riadenia a spracovania. Tieto techniky zachytvaj algoritmus spracovania, ktor je nezvisl od implementcie v konkrtnom programovacom jazyku. K skupine technk pre zpis procesov patria prostriedky umonujce reprezentciu algoritmu spracovania rozmanitmi spsobmi, od grafickej a po truktrovan jazyk. Vvojov diagramy patria ku grafickm prostriedkom reprezentcie riadenia procesu spracovania informci. Predstavuj jeden z prvch prostriedkov, s ktormi programtori prdu do styku. asto sa vvojov diagramy povauj za analytick nstroj, ale ich miesto je v nvrhovej asti ivotnho cyklu softvrovho systmu. Vvojov diagramy predstavuj orientovan grafy. Uzly reprezentuj rzne druhy spracovania: - blok zaiatku. Na tomto mieste zaina spracovanie popisovan vvojovm diagramom. Vo vvojovom diagrame mze by iba jeden zaiaton blok. - blok konca. Reprezentuje bod, v ktorom spracovanie opisovan danm vvojovm diagramom koni. Jeden vvojov diagram mze ma aj viacero koncovch bodov, ktor s ovem ekvivalentn. Viacero koncovch bodov sa zavdza z dvodu zamedzenia zbytonho kriovania hrn v grafe a tm zvseniu prehadnosti grafu. - jednoduch blok spracovania. Aktivitu reprezentovan tmto modulom je mon popsa jednoduchm prkazom, resp. skupinou prkazov. Typickm prkazom bva priradenie. - vstupno-vstupn blok. Reprezentuje naitanie vstupov, resp. vstup informci zo systmu - rozhodovac blok. Reprezentuje vetvenie alej innosti v zvislosti na vyhodnoten uritej podmienky. - blok modulu spracovania. Reprezentuje aktivciu zloitejej aktivity, ktor bva popsan samostatnm vvojovm diagramom. Tomuto modulu zodpoved aktivcia podprogramu. - spojovac bod. Mnohokrt bva vvojov diagram natoko zloit, e ho nie je mon umiestni na jeden dokument. V tomto prpade sa umiestni na viacero dokumentov a prepojenie riadenia sa vykon pomocou spojovacch bodov. Grafick reprezentcia uvedench modulov je ilustrovan na OBR.3.22. Uveden moduly zodpovedaj minimlnej potrebnej mnoine pre opis spracovania. astokrt bva tto mnoina rozirovan o alie moduly, napr. modul viac-cestnho vetvenia. OBR.3.22. - grafick reprezentcia blokov vo vvojovom diagrame Hrany v orientovanom grafe reprezentuj tok riadenia. V tomto spoiva zsadn rozdiel medzi vvojovmi diagramami a DFD, kde hrany reprezentuj tok dajov. Riadenie pri spracovan reprezentovanom vvojovm diagramom prechdza blokmi reprezentujcimi spracovanie v smere ipok. V prpade vetvenia sa vyhodnot podmienka a riadenie pokrauje vetvou zodpovedajcou logickej hodnote vyhodnotenej podmienky. Vvojov diagramy vemi asto predstvuj vsledok nvrhovej etapy. Z vvojovch diagramov je priamo mon prejs k implementcii, priom jeden vvojov diagram mze priamo reprezentova procedru v cieovom programovacom jazyku. Vznamnou charakteristikou vvojovch diagramov je monos ich hierarchickho zoskupovania. 3.14. Jacksonove diagramy ------------------------- Jacksonove diagramy s prostriedok pre grafick znzornenie procesu spracovania informci. Navrhnut boli pecilne pre spracovanie dajov, k omu s prispsoben i zkladn kontrukcie. Jacksonove diagramy podporuj struktrovanmu prstupu k tvorbe programov zachovvajc pravidlo jedinho vstupu a vstupu pre kad modul. Poskytuj nasledovn zkladn riadiace kontrukcie: - vkonn blok - sekvencia - vetvenie - itercia Uveden kontrukcie s postaujce pre vyjadrenie akhokovek spracovania nad dajmi. Ich grafick vyjadrenie je ilustrovan na OBR.3.23. OBR.3.23. 3.15. Akn diagramy -------------------- Akn diagram predstavuje prostriedok pre grafick reprezentciu hiararchickej truktry programu, tzn. spja spolu svisiace asti programu do hierarchicky truktrovanch logickch celkov. Akn diagramy je mon pouiva pri trukturalizcii popisu postupu spracovania v prirodzenom jazyku s pouitm zkladnch riadiacich kontrukci. Na najvysej rovni abstrakcie mze akn diagram predstavova ekvivalent truktrneho diagramu. Akn diagram organizuje akcie do spolu svisiacich celkov. Zkladnm symbolom aknho diagramu je vertiklne ohranienie uzatvrajce logicky svisiace asti procesu spracovania do spolonho celku. Notcia pre vytvranie aknch diagramov je ilustrovan na OBR.3.24. OBR.3.24. notcia pre akn diagramy Akn diagramy sa pouivaj podobne ako vvojov diagramy ako dokument pre pecifikciu nvrhu postupu spracovania pre jednotliv moduly vytvranho systmu. 3.16. Prototypovanie pouivateskch rozhran --------------------------------------------- Nvrh pouivateskch rozhran predstvuje dleit scas nvrhu systmu. Tento nvrh pozostva z dvoch ast: nvrhu obrazoviek a nvrhu spsobu komunikcie. Prototypovanie pouivateskch rozhran predstavuje jeden z prstupov k nvrhu obrazoviek pouivateskho rozhrania. Zachytva zobrazenie dajov na jednotlivch obrazovkch, ako aj spsob zadvania potrebnch dajov pouivateom. Dokumenty nvrhu obsahuj popis kadej obrazovky. Spsob komunikcie je dleitou scasou nvrhu rozhrania. Obsahuje reakciu na vstupy od pouivatea a innosti, ktor je potrebn aktivova. Pre opis spsobu komunikcie na najastejie pouivaj stavov diagramy. Pre vytvranie pouivateskch rozhran existuje viacero nvodov. Vcsina z nich vychdza z praktickch sksenost podloench vsledkami psyholgie. Opisom zsad nvrhu pouivateskch rozhran sa budeme zaobera v samostatnej asti.