1. Strukturna sistemska analiza in načrtovanje
(SSADM - Structured Systems Analysis and Design Method)

2. SSADM – cilji in koncepti
strukturiran razvoj programske opreme
metodologija
notacija (pravila zapisovanja)
integracija analize in načrtovanja
cilj: nadzor kakovosti
zasnova (izhodišče): tok informacij (podatkov)
v 80-ih in 90-ih letih pogosto uporabljana metodologija, danes jo postopoma nadomešča poenotena metolodologija (unified process - UML)
veliko inačic

3. Glavni koraki Data Flow Diagram - DFD
pripravi in analiziraj Diagram Toka Podatkov
Data Flow Diagram - DFD
iz diagrama toka podatkov izpelji Strukturni graf
Structure Chart - SC

4. Izhod (output) faze analize
Diagram Toka Podatkov (Data Flow Diagram)
Podatkovni Slovar (Data Dictionary)
Mini Specifikacije (Process Specifications)

5. Diagram toka podatkov Celotni IS je sestavljen iz:
procesov,
poslovne logike in
podatkovnega modela.
Pri DFD se osredotočimo na:
procese in
tok podatkov med njimi (kako podatki pridejo v sistem, kam gredo, kje se obdelujejo, kdo sprejema odločitve...)

6. Logični / fizični nivo modela
Logični nivo
- opisuje procese, ne da bi pri tem povedal kako so realizirani - izpeljani.
Fizični nivo
- vključuje informacije o tem, kako so procesi implementirani

7. Notacijski elementi DFD
De Marco, Yourdon Gane, Sarson
proces
zbirka podatkov
izvor / ponor (terminator)
tok podatkov

8. Procesi label label proces = aktivnost
predstavlja transformacijo podatkov
na vhodu sprejme podatkovni tok
na izhodu proizvaja podatkovni tok
lahko ga naprej razgradimo (razčlenimo/ izvedemo dekompozicijo)
labela: glagol
povezan je s specifikacijo procesa
P_Number
label
P_Number
label

9. Tok podatkov label predstavlja prehod informacij povezovalni element
prenos podatkov
ne predstavlja nadzor pretoka
je usmerjen
lahko se deli ali združi
labela: samostalnik
opisan je v podatkovnem slovarju
label
label
label
label
label
label

10. Zbirka podatkov label label trajna shramba za podatke
predstavlja bazo podatkov ali datoteke
pasivnost – v bazi se ne izvajajo aktivnosti
obdelana s strani procesov
labela: samostalnik
opisana je v podatkovnem slovarju in/ali z ER diagramom
label
label D#

11. Terminator label izvor / ponor za zunanje tokove podatkov
zagotavlja povezavo z vsebino sistema
pasivnost: razen sprejemanja / pošiljanja podatkov ne izvaja nobene druge aktivnosti
labela: samostalnik
opisana je v podatkovnem slovarju
label

12. Postopek izdelave DFD izdelava kontekstnega diagrama
izdelava diagrama na ‘prvem’ nivoju
funkcionalna dekompozicija posameznih procesov do elementarnih procesov
validacija diagrama z uporabnikom

13. Značilnosti kontekstnega diagrama
Ima le en proces  cel poslovni sistem se nahaja znotraj edinega procesa z oznako 0
ni zbirk podatkov  vse so skrite znotraj edinega procesa
izvori / ponori so (določajo) meje sistema (zato se imenujejo tudi terminatorji)

14. Primer: Kontekstni diagram knjigarne

15. Diagram na ‘prvem’ nivoju
Diagram prikazuje podprocese (funkcije) osnovnega procesa.
Primer: iz opisa so razvidne tri funkcije (procesi):
prodaja,
nabava in
vzdrževanje.

16. Primer: DFD diagram na 1. nivoju za knjigarno

17. Funkcionalna dekompozicija
Posamezne procese proučimo in napravimo diagrame toka podatkov na nižjih nivojih.
podprocese označimo s številkami – denimo:
pomeni tretji nivo – to je tretja podfunkcija prve podfunkcije prve funkcije
na nižjih nivojih novih izvorov / ponorov ni!
pri dekompoziciji pazi na število povezav:
proces, definiran na višjem nivoju mora imeti enako število vhodov in izhodov kot je vsota vhodov in izhodov vseh njegovih podprocesov

18. Primer: dekompozicija procesa 1. na podprocese

19. Kdaj je dekompozicija končana?
ko pridemo do elementarnih procesov -
Elementarni procesi predstavljajo en izračun, eno odločitev, eno operacijo nad bazo...
ko je vsak tok ena transakcija, on-line dialog, poročilo, dokument...
ko zbirka predstavlja entiteto
ko je uporabnik zadovoljen ali pa ko vidimo, da lahko izvajamo naslednje faze izgradnje

20. Konceptualni standardi podatkovnih tokov
podatkovni tokovi ponazarjajo potek informacije od enega objekta k drugemu objektu
podatkovni tokovi ne morejo spreminjati podatkov
podatki ne morejo biti ustvarjeni ali uničeni znotraj podatkovnega toka
podatkovni tok je lahko v določenih pogojih prazen
podatkovni tokovi ne morejo neposredno prehajati od terminatorja (vir/ponor) k datoteki
podatkovni tokovi ne morejo neposredno prehajati od terminatorja do terminatorja

21. Notacijski standardi podatkovnih tokov in zbirk podatkov
podatkovni tok je predstavljen z usmerjeno črto, opremljeno z labelo
vsak podatkovni tok mora biti označen z labelo.
Izjema: podatkovni tok, usmerjen proč od zbirke ali v zbirko, ni treba poimenovati, če predstavlja zbirko v celoti.
labela je samostalnik, izogibamo se generičnim računalniškim imenom (DATA, INPUT, ...)
vsi podatkovni tokovi morajo nastopati v podatkovnem slovarju
zbirka mora imeti vsaj en vhodni in vsaj en izhodni tok
zbirka se lahko pojavi na katerikoli plasti (nivoju) DFD

22. Nekaj splošnih navodil za DFD
dekompozicija = razčlenitev procesa na elementarne sestavine
vmesniki med procesi morajo tudi na nižjih nivojih ostati konsistentni (skladni)
pri procesih na nižjih nivojih lahko dodamo nove tokove podatkov in nove zbirke podatkov
nivo 0 uporabljamo kot ‘abstraktni’ nivo
terminatorji niso procesi (niso aktivni)
DFD nima časovne komponente

23. Poiščimo napake:
All processes must have at least one data flow in and one data flow out.
All processes should modify the incoming data, producing new forms of outgoing data.
Each data store must be involved with at least one data flow.
Each external entity must be involved with at least one data flow.
A data flow must be attached to at least one process.

24. DFD 0: Registration System (Context Level)
printer
Registration System
(A Toy Example)
user P2
Prepare
invoice P4
Print
invoice
invoice
invoice_prt
registration
reg+
reg-profile P1
Read
& check
reg.
prices
registration db
conf_msg
reg_info
reg+ P5
Write
conf. P3
Accept
reg.
conf.
user

25. DFD L1: Registration System
printer
user P2
Prepare
invoice P4
Print
invoice
invoice
invoice_prt
registration
reg+
reg-profile P1
Read
& check
reg.
prices
registration db
conf_msg
reg_info
reg+ P5
Write
conf. P3
Accept
reg.
error_msg (reg-)
conf.
user

26. DFD L2: P1- Read and Check Registration
error_reason
P1.3
Error-handler
registration
error_msg (reg-)

27. Podatkovni slovar specificira (opredeli) podatkovne elemente DFD:
tokove podatkov
enostavne zbirke podatkov
skladnost z DFD
specifikacije morajo biti skladne z diagramom
popolnost
glede na zahteve DFD mora biti popoln
sestavljajo ga specifikacije podatkovnih elementov
vsi podatkovni tokovi in zbirke podatkov iz DFD so razčlenjeni do podatkovnih elementov oz. prvinskih podatkov (DE - "data element")

28. Formalna notacija za podatkovni slovar
pravila - opredeljujejo opis, strukturo ali zamenjavo
= izenačitev - kompozicija
podatkovni element = podatkovna struktura
oseba = ime_osebe + naslov
ime_osebe = priimek + osebno_ime
meta-simboli - opisujejo strukturo:
+ logični in (zaporedje)
[...|...|...] logični ekskluzivni ali
m{ ... }n iteracija (>= ena ponovitev)
( ... ) opcija
 komentar

29. 1. primer podatkovnega slovarja
naročeno_blago=šifra_blaga + naročena_količina + prevoz + (opombe)
prevoz = [ letalo | ladja | vozilo]
letalo = prevoznik + številka_leta + destinacija + datum + (spremljevalec)

30. 2. primer podatkovnega slovarja
* registracija osebe za tečaj-e
registracija = oseba + podjetje + (1{tečaj}4) + datum + (opomba)
oseba = ime + priimek + (naziv)
podjetje = ime_podjetja + ime_oddelka + naslov
naslov = ulica + hišna_št + poštna_št + kraj + (država)
tečaj = [ “word” | ”excel” | ”powerpoint” | ”internet”]
==> alternativna obravnava tečajev?

31. - alternativa:
registracija = oseba + podjetje + tečaji + datum + (opomba)
oseba = ime + priimek + (naziv)
podjetje = ime_podjetja + ime_oddelka + naslov
naslov = ulica + hišna_št + poštna_št + kraj + (država)
tečaji = (“word”) + (”excel”) + (”powerpoint”) + (”internet”)

32. Data Dictionary - naloge
Napišite podatkovni slovar za vozniško dovoljenje
Napišite podatkovni slovar za teden v šolskem dnevniku dela

33. Mini Specifikacije
izdelamo za tiste procese iz DTP, ki niso razgrajeni, torej so atomarni (prvinski) procesi, imenovani tudi funkcionalne primitive
opišemo transformacijo vhodnih podatkov v izhodne
vsak elementarni proces ima svojo MS
za MS lahko uporabimo:
strukturirano besedilo
odločitvene tabele
odločitvena drevesa

34. MS - Strukturirano besedilo
za formaliziranje zapisa so uporabljeni osnovni proceduralni konstrukti:
zaporedje / sekvenca (blok)
odločitev / vejitev (if – then – else)
ponavljanje / zanka (while, repeat)
kot operandi nastopajo tisti podatkovni tokovi, ki prihajajo v ali izstopajo iz trenutno aktualnega procesa

35. Primer strukturiranega besedila
proces Izdaja_čekov
številka procesa: X.X
begin       
if stanje pozitivno then          
izdaj 20 čekov
  else (stanje je negativno)      
if dovoljena prekoračitev then  
izdaj 10 čekov
    opozorilo o negativnem stanju
else (prekoračitev ni dovoljena) 
opozorilo o negativnem stanju
end

36. Odločitvena tabela - shema
(ukrep-akcija)
popis pogojev | vrednosti pogojev | |
popis ukrepov | ukrepi pri pogojih
odločitvene tabele lahko kombiniramo s strukturnim besedilom

37. Odločitvena tabela - shema
pogoj1
vr11
vr12
vr13 …
pogoj2
vr21
vr22
vr23 ..
ukrep1
u1kp1
u1kp2
u1kp3
ukrep2
u2kp1
u2kp2
u2kp3 ….
pogojev
Popis
ukrepov
Popis
- u1kp1 pomeni ukrep 1 pri kombinaciji pogojev 1 (prvi stolpec)

38. Odločitvena tabela – primer izdaja čekov
pozitivno stanje D N
prekoračitev dovoljena
število izdanih čekov 20 10
obvestilo o ned. stanju
pogojev
Popis
ukrepov
Popis