Kurs: Softverski dizajn Materijali vezani uz ovu lekciju: - Test dijagram toka podataka (data flow diagram) - Dijagram toka podataka (Data Flow Diagram) (PDF dokument) U ovoj lekciji obrađivaćemo:
Pitanje izbora selekcijePostoji više različitih formi za opisivanje osobina softvera. Grubo ih možemo podeliti u dve grupe:
Postoji više različitih reprezentativnih formi, kao i varijacija nekih od najviše korišćenih formi. U tabeli 1 i tabeli 2 dat je pregled pogleda na model dizajna koji svaka od formi pruža i lista karakteristika dizajna koji se može predstaviti njenim korišćenjem.
Notacije crne kutije (Black Box)Notacije crne kutije se bavi sa spoljašnjim osobinama elemenata modela dizajna. Koristi se da opiše šta će pojedini elemenat raditi, pre nego kako će nešto uraditi. Izbor forme nije jedinstven i može mu se pristupiti sagledavajući i tehnološki i istorijski aspekt. Za početak razmotrićemo dijagram toka podataka (eng. Data Flow Diagram - DFD), oblik koji je bio primenjivan za sistemsko modelovanje pre pojave računara i koji je povezan sa arhitektonskim stilom. Dijagram entitet-veza (eng. Entity-Relationship Diagram - ERD) je takođe povezan za arhitektonski stil, mada na jedan drugačiji način (forma bazirana na transakciji). Razmotrićemo i dve forme ponašanja, State Transition Diagram (STD) i Statechart, svaku sa svojim prednostima i ograničenjima. Jacksonov strukturni dijagram (eng. Jackson Structure Diagram) nudi sasvim drugačiji primer ovakvih notacija i više se bavi strukturom i stoga manje eksplicitno vezan sa bilo kojim drugim pogledom. Na kraju, postoji i Unified Modeling Language (UML), danas jedan od najzastupljenijih načina predstave[2]. Dijagram toka podataka (Data-Flow Diagram)Data-Flow Diagram (u daljem tekstu - DFD) se uglavnom koristi za opis problemski orijentisanog pogleda na rad sistema. On omogućava opis zasnovan na modelovanju toka informacija oko mreže operativnih elementata, gde svaki element koristi ili menja informaciju koja ide ka tom elementu. Korišćenje pojedinih DFD oblika za opis rada složenih sistema je gotovo sigurno postojalo i pre doba primene računara, a Page-Jones[3] je sugerisao da su ti oblici verovatno nastali na mnogim mestima i u različita vremena, ali potpuno nezavisno. Najranija referenca koja je raspoloživa datira iz 1920. godine. Generalni pristup DFD koncepta efikasno je prikazan kroz primer koji je koristio Tom De Marco[5]. U uvodu svoje knjige "Strukturna Analiza i Specifikacija Sistema", on daje primer neformalnog dijagrama toka koji se koristi kako bi razjasnio uputstvo za sklopanje kajaka. Očigledno je da u ovom slučaju tok podataka predstavlja fizički oblik (sastoji se od podsklopova). Princip je isti kao i za softver, tako da ovaj primer pruža odličnu demonstraciju efikasnosti takvog oblika kada se koristi za opisivanje procesa. U tom smislu, jednostavan dijagram toka (slika 1.) pokazuje kako je ovaj obrazac može koristiti za opis konstrukcionog sklopa baštenske kuće. ![]()
Čak je i ovaj jednostavan primer dovoljan da prikaže neke od prednosti DFD-a kada se koristi za opisivanje niza operacija. Drugim rečima, pokazuje da se odmah mogu videti preduslovi za bilo koju operaciju, tj. na prvi pogled. Na primer, ako uzmemo operaciju 5: "Fit doors to walls - postavka vrata", možemo videti da ista zavisi od završetka operacija 3 i 4, a može se videti i zašto. Sekvencijalna lista akcija može dostaviti iste podatke, ali aspekt zavisnosti, koji se vidi kroz korišćenje DFD-a, uopšteno je manje jasan u takvoj formi. Koristi ovakve vizualizacije postaju još važnije za operacije koje uključuju puno veću kompleksnost od predhodno navedenog primera. DFD se u širokoj meri koristi za softverski dizajn tokom više godina, tako da se u literaturi može pronaći veći broj varijacija sa tačnim oblicima simbola koji se koriste za crtanje DFD-a. Kroz ovu lekciju razmatreće se obrazac koji opisuje De Marco[5]. Postoji i drugi primeri formi, koji koriste više formalne notacije, obavljaju pomalo drugačiju ulogu u procesu dizajna, a koristi se u "Strukturnoj sistemskoj analizi i metodama dizajna" (eng. Structured Systems Analysis and Design Method[6]). Forma DFD-aDFD je grafička predstava, koja koristi samo četiri osnovna simbola. Zbog svoje vrlo apstraktne prirode, pod uslovima obezbeđenog nivoa opisa, uglavnom se koristi u vreme ranog stadijuma dizajna koji se često naziva "Analiza", u trenutku kada dizajnerski tim verovatno donosi neke od većih odluka arhitekturalnog dizajna. Na slici 2 je prikazan primer korišćenja jednog DFD-a za opis rada sistema bankomata. ![]()
Četiri osnovna elementa koji se koristi u dijagramu su:
Pogledajmo primer prikazan na slici 2. Operacija validacije zahteva ulaz iz kartice kupca ili od samog kupca u obliku ličnog identifikacionog broja ili PIN-a ili iz internog fajla. Prva dva od pomenutih ulaza se koriste za proveru autentičnosti i identiteta kupca, dok treći osigurava da je kartica, koja može biti izdana od strane različitih finansijskih institucija, prihvatljiva za uređaj. Izlazi iz tog procesa se potom posmatraju sa aspekta prihvatanja (sledi izbor tražene transakcije od strane kupca) ili odbijanja (koji može uključivati povratak ili zadržavanje kartice). Čak i ako postoji dozvola da se nastavi dalje sa transakcijom, biće još validacionih procesa kako bi se osiguralo da je odabrana mogućnost dozvoljena za datog klijenta. U suštini, DFD pruža "top-level" model kako dizajner namerava da radi bankomat. Akcenat je stavljen na opis delova domena (kupca, PIN, transakcije), pre nego na rešenje i kao takav identifikuje glavne arhitekturalne zadatke za bankomatski sistem. Hijerarhijsko proširenje DFD-aVažna karakteristika DFD-a je da može biti proširen u hijerarhijskom smislu, gde se operacije (krug na slici) mogu opisuju narednim DFD modelom. Kao primer, na slici 3. je pokazana ekspanzija kruga 1 sa slike 2, korišćenjem istih simbola. Takođe ističe se važnost brojčanih oznaka koje se koristi za identifikovanje krugova, budući da identitifikacioni broj pokazuje nivo kruga i njegov položaj u proširenom opisu sistema. U našem primeru korišćene su oznake 1.1, 1.2 i 1.3. Dakle, u ovom primeru, dizajner je prema sopstvenim idejama proširio operaciju "Validate customer access". Treba primetiti da za operaciju u krugu 1.3, gde nema namere da se pokaže struktura kontrole toka koja je vezana sa mogućim iteracijama zahtevanim radi dozvole kupcu tri pokušaja za unos PIN koda. DFD se ne odnosi na kontrolnu logiku koja je su uključena u obavljanje ove operacije, a njene detalje će biti potrebno obraditi kasnije, koristeći druge forme za opis. Dok je značaj ekspanzije u omogućavanju postupnog usavršavanje dizajna, sa druge strane to može dovesti do problema nedoslednosti. Promene mogu biti izvedene na nižem nivou (eng. lower-level) dijagrama koji menja broj i/ili formu informacije o protoku (krive linije) prethodnog (starijeg) dijagrama. Proveru konzistentnosti takvih promena (kao i automatsko numerisanje krugova), generalno se vrši putem specijalizovanog alata koji pomaže pri izradi DFD-a. ![]() DFD gledišteDijagram toka podataka se prvenstveno bavi opisom arhitekture nekog sistema u smislu njegove funkcije, u kojoj se identifikuju operacije koje sistem treba da izvrši, koristeći apstraktni nivo opisa. Elementi dijagrama toka se koriste za identifikuju informacije koje je potrebna za izvođenje odgovarajuće operacije, kao i onih koje su generisane na osnovu njih. Pitanje apstrakcije postaje važno kada se radi o izboru konvencija koje bi trebalo koristiti pri crtanju dijagrama. Slika 3 upravo pokazuje to pitanje: krug 1.3 opisuje broj dozvoljenih pokušaja u kojima korisnik unosi PIN, ali dijagram ne pokazuje iteraciju na direktan način. U istom trenutku, a kada se radi o sekvenci informacija, oblik i dijagram ne daje nikakve informacije o tome da li se operacija izvodi sekvencijalno ili paralelno. Konvencija obično podrazumeva sekvencijalan niz operacija, ali DFD se može podjednako koristiti za opisivanje paralelnih operacija. Neke dizajnerske metode upravo koriste ove prednosti DFD-a. Korišćenje DFD-aZbog svoje apstraktne prirode i sposobnosti da opiše funkciju, DFD se široko koristi za inicijalno modelovanje sistema (često nazivano i analizom). To je glavna komponenta široko korišćenog SSA/SD (Structured Systems Analysis/Structured Design) pristupa, a takođe se koristi i u raznim izvodima ovog metoda. U takvoj ulozi, jedna od prednosti korišćenja DFD-a je da se može relativno lako shvatiti od strane korisnika, budući da se koristi za modelovanje problema, pre nego na računarski-orijentisano rešenje. De Marco[5] utvrđuje razliku između "logičnog" i "fizičkog" DFD-a, što je korisno uzeti u obzir. Fizički oblik DFD-a se koristi za modelovanje sistema u smislu njegovih fizičkih entiteta, pre nego njihovih funkcija. Na primer, slika 4. pokazuje fizički DFD koji se koristi za modelovanje rada rezervacija u nekoj turističkoj agenciji. Oznake na krugovima u ovom dijagramu opisuju ko izvršava posao, pre nego što opisuju posao u njegovim detaljima (Na primer, Roger radi na poslovima koji se tiču železničkog prevoza). ![]()
Slika 5. prikazuje ekvivalentan logički DFD, u kojoj su sada krugovi označeni da pokažu šta se dešava sa podacima, pre nego ko izvršava taj posao. Ovo je više apstraktni i više struktuiran pogled u odnosu na dijagram sa slike 4, ali jasno se vidi da proizilazi iz pomenutog dijagrama. Oba od tih oblika su važni: fizičkog DFD pomaže kod inicijalnog modelovanja i zadataka komunikacije sa naručiocima, dok je logički DFD potreban kada dizajner počinje da gradi arhitekturalni model u cilju izgradnje celokupnog sistema (U ovom slučaju, sistem će verovatno biti neka vrsta automatizovanog sistema rezervacija). ![]()
Kao što je pomenuto ranije, drugi oblici DFD-a se koriste za pomoć pri detaljnijem modelovanju dizajna, u tački koja ističe opštu korisnost ovog alata. Ovo zauzvrat odražava činjenicu da je često relativno lako definisati akciju (kao što je naglasak starijih programskih jezika na obezbeđivanju formi koji opisuju akciju, umesto na strukture podataka). Iz svega toga proističe da se DFD može relativno lako razumeti, i često se može mnogo lakše razviti u poređenju sa drugim formama opisa. Reference:1. David Budgen, Software design, Addison Wesley, 2003
|