PIS01 - IstorijaRazvojaMetoda&Alata (12 Files Merged) PDF

Projektovanje informacionih sistema
ISTORIJA RAZVOJA METODA I ALATA ZA

PROJEKTOVANJE INFORMACIONIH SISTEMA
ISTORIJA SOFTVERSKOG INŽENJERSTVA

Softversko inženjerstvo i softverska
kriza
Termin “Softversko inženjerstvo” se prvi put pojavio na jednoj NATO konferenciji
još 1968. godine. Pod njim se podrazumevao skup metoda, tehnika i alata za
projektovanje softvera, po principima projektovanja proizvoda, ure|aja i objekata u
drugim inženjerskim disciplinama. Softversko inženjerstvo se javilo kao odgovor na
“softversku krizu”
Pod “softverskom krizom” se podrazumevaju svi, ne mali, problemi u razvoju

softvera, prvenstveno niska produktivnost i visoki trpškovi razvoja. Sofverska kriza
se obično ilustruje sledećim Boehm-ovim dijagramom:
100%
HARDVER
80
RAZVOJ
SOFTVERA
od1985. razvijaju se različite formalne metode, alati i
60 metodologije kako bi se poboljšalo upravljanje kvalitetom
softvera.
40
ODR@AVANJE
SOFTVERA
20
1955 1970 1985 Godine

Tipovi održavanja softvera prema ISO/IEF 14674 standardu
Adaptivno održavanje - modifikacija sofverskog proizvoda da bi se sačuvala upotrebna verdnost u promenljivoj sredini
Perfektivno održavanje - modifikacija softverskog proizvoda radi unapredjenja performansi ili održivosti
Korektivno održavanje – modifikacija sofverskog proizvoda radi popravke otkrivenih grešaka
Pod terminom “kriza” podrazumeva se nešto prolazno.

Da li softverska kriza još uvek traje?
Računarske
discipline
CE - Computer Engineering
CS - Computer Science
IS - Information Systems *
IT - Information Technology
SE - Software Engineering
quantitative
approaches
Fokus informacionih sistema je na

integracija informacionih tehnologija i
poslovanja da bi efikasno ostvarili
ciljevi preduzeća
Istorijat Softverskog inženjerstva će se diskutovati sa tri me|usobno čvrsto povezana
aspekta:
1. PROGRAMSKI JEZICI I PROGRAMIRANJE
2. MODELI I METODE RAZVOJA SOFVERA
3. CASE ALATI ZA RAZVOJ SOFTVERA
Istorijat, odnosno “revolucionarne promene” se dešavaju uvek ma isti način: Prvo u

programskim jezicima, zatim u metodologiji razvoja softvera i na kraju u CASE
alatima.
REVOLUCIONARNE PROMENE - FAZE
RAZVOJA:
“HEROJSKO DOBA - REŠAVANJE PROBLEME ISKLJUČIVO
PROGRAMIRANJEM
STRUKTURNE METODE
MODELI PODATAKA, BAZE PODATAKA I JEZICI IV GENERACIJE
“DOBA ZRELOSTI” - OBJEKTNE METODE

1. PROGRAMSKI JEZICI I PROGRAMIRANJE
ARHITEKTURA PROGRAMSKIH JEZIKA:
1) TIPOVI
PODATAKA (PROGRAMSKO-JEZIČKI, VIRTUELNI TIPOVI). POD TIPOM
PODATKA SE PODRAZUMEVA SKUP VREDNOST I SKUP OPERACIJA NAD NJIMA:
ATOMSKI TIPOVI
AGREGIRANI TIPOVI - STRUKTURE PODATAKA
2) KONTROLNE STRUKTURE - DEFINISANJE REDOSLEDA OBAVLJANJA OPERACIJA NA

TIPOVIMA:
SEKVENCIJA
SELEKCIJA
ITERACIJA
JEZICI SU SE RAZLIKOVALI PO TOME KOJE TIPOVE PODATAKA PODRŽAVAJU I NA KOJI NAČIN
OSTVARUJU KONTROLNE STRUKTURE (KOLIKO SE “STRUKTUIRANI”)
STRUKTURNA FAZA
1965 - 1980
NAJVEĆA (GOTOVO JEDINA) PAŽNJA U POČETNOM PERIODU RAZVOJA
SOFTVERSKOG INŽENJERSTVA POSVEĆIVALA SE KONTROLNIM STRUKTURAMA
(ALGORITAMSKE APSTRAKCIJE):
1) STRUKTUIRNO PROGRAMIRANJE:
REŠAVANJE SINDROMA “ŠPAGETI KODA”
DOBRO DEFINISANE STRUKRURE PROGRAMA
PROGRAMIRANJE BEZ ILI SA KONTROLISANOM PRIMENOM “GO TO” NAREDNE. “Go to
considers harmful”
2) STRUKTURNA ANALIZA I PROJEKTOVANJE

Structured System Analysis. Structured Design - Yourdon i Constantine
SADT (Structured Analysis and Design Technique) - D.T.Ross, Sof. Tech. Inc., Današnji IDEF0 standard dela
američke administracije (vojske i drugih)
ISAC (Information System Work and Analysis of Changes), Langefors, Švedska
NIVO I
SPO LJNI_ TO KP_1 PRO C_A TO KP_4 TO KP_6 SPO LJNI_

PRO C_D
O BJEKAT _1 1. 4. O BJEKAT _3
SKLADP_1 SKLADP_2
TO KP_3
TO KP_2 TO KP_5
SPO LJNI_ PRO C_B PRO C_C
O BJEKAT _2 2. 3.
TO KP_3 NIVO II
PRO C_BA
2.1
TO KP_2a
SPO LJNI_ SKLADP_3 TO KP_5

O BJEKAT _2
TO KP_2b
PRO C_BC
TO KP_7 2.3
PRO C_BB
2.2
X
Ukupna suma
plata Ukupna suma
A plata
B
Inicijalizacija
Y
svega
Ukupna suma
plata
Izra~unati i
{tampati
prose~nu platu
Prose~na
plata
Plata
[tampati
îtati platu prose~nu
platu
PRAVILA STRUKTURNOG PROJEKTOVANJA
NALAŽENJE “CENTRALNE TRANSFORMACIJE” ILI “ANALIZIATORA TRANSAKCIJA”

KAO ČVORA STABLA
DEFINISANJE HIJERARHIJSKE STRUKTURE MODULA
ANALIZA POVEZANOSTI (copling-a) I KOHEZIJE MODULA

(Ova pravila su i danas aktuelna za definisanje “odgovornosti objekata” za pojedine operacije u
objektnom projektovanju)
UOČAVANJE POTREBE DA SE JASNO ODVOJE SPECIFIKACIJA,
PROJEKTOVANJE I IMPLEMENTACIJA SOFTVERA. DEFINISANJE
KONVENCIONALNOG (“VODOPAD”) “ŽIVOTNOG CIKLUSA IS”
1. ANALIZA ZAHTEVA I SPECIFIKACIJA IS.

Specifikacija treba da jasno, neprotivrečno i formalno
odgovori na pitanje “šta” softver treba da radi;
2. PROJEKATOVANJE. Daje odgovor na pitanje “kako”
3. IMPLEMENTACIJA. Kodiranje i testiranje
4. UVOĐENJE
5. ODRŽAVANJE
CASE ALATI
PSL/PSA (Problem Statement Language - Problem Statement Language) ISDOS projekat University of
Michigan, Prof D. Teichroew, učestvovao i FON. Verovatno prvi CASE alat.
Enterprise Architect
Visual Paradigm
Rational Rose
Mnogi drugi
Pretežno “lower cases” - prve faze razvoja, analiza i specifikacija sistema.

Mnogi su još “živi”, jer se stalno proširuju i nadgra|uju.
MODELI PODATAKA, BAZE PODATAKA I
JEZICI IV GENERACIJE
1980 -1995
BAZE PODATAKA, APSTRAKCIJE
PODATAKA, MODELI PODATAKA I
NEPROCEDURALNI JEZICI
Iskjučivo algoritamske transakcije nisu rešile mnoge probleme:
REDUNDASA PODATAKA U MASOVNOJ OBRADI PODATAKA
NEZAVISNOST PROGRAMA OD LOGIČKE I FIZIČKE STRUKTURE PODATAKA
UKLJUČIVANJE KORISNIKA U RAZVOJ SOFTVERA - POKUŠAJ DA KORISNIK SAMSTALNO

ZADOVOLJAVA SVOJE NEPOSREDNE ZAHTEVE - RAZVOJ NEPROCEDURALNIH JEZIKA
PRENOŠENJE VEĆEG DELA SEMANTIKE PROBLEMA NA PODATKE - RAZVOJA MODELA

PODATAKA
MODELI PODATAKA
IZLAZNA IZLAZI
ULAZ STANJE
TRANSFORM.
REAL NI SIST EM
PODACI O ULAZU
PROGRAMI BAZA PROGRAMI IZLAZI

ZA ODR@. PODATAKA ZA IZVE[
INF O R MAC IO NI S IST E M
GENERACIJE MODELA PODATAKA

I GENERACIJA: Jezici treće generacije sa relativno jednostavnim tipovima podataka.
II GENERACIJA: Modeli konvencionalnih Sistema za upravljanje bazom podataka - hijerarhijski mrežni i relacioni.
III GENERACIJA: Semantički bogati modeli Model objekti veze, SDM i drugi.
RELACIONI MODEL
Definicija preko tipova podataka:

Skup vrednosti: SKUP RELACIJA (TABELA)
Operacije: RELACIONA ALGEBRA
Znatno moćniji tipovi podataka nego u drugim konvencionalnim sistemima
Mogućnost definisanja neproceduralnog jezika
SQL
RELACIONI MODEL <-----> KOMERCIJALNI RELACIONI SUBP
E.F. Codd: “The Relational model for Database management”, Version 2, Addisov -Weseley, 1990.
IPAK NEDOVOLJNO SEMANTIČKI BOGATI:
NE POSTOJE MEHANIZMI ZA IMPLEMENTACIJU APSTRAKCIJA AGREGACIJE I GENERALIZACIJE
NE POSTOJI MOGUĆNOST DEFINISANJA APSTRAKTNOG TIPA KAO DOMENA
MODEL OBJEKTI - VEZE
REGBR
[N
KOLA MARKA NASTAVNIK
IMEN
BOJA
(1,1) (0,1)
BI
PARKIRA [P PREDAJE
IME
NAZP
DATUM OCENA
(0,1) SEM B^ (0,M)
(0,M) (0,M)
STUDENT POLO@IO PREDMET
(1,M)
(0,M)
(0,M) (1,1)
Vrste (0,1)
IMA SLU[A
S PRIPADA
(1,M) ZANIMANJE (1,M)
RODITELJ KATEDRA
VANREDAN
MLB IMER [K NAZIVK

(1,M) (0,M)
RADI UÊSTVUJE
(0,M) (0,M)
[PROJ
POSAO PROJEKAT
NAZPROJ
(1,M)
[POS NAZPOS
[ZAD
ZADATAK OPISZAD
NAZZAD
PROMENE U ŽIVOTNOM CIKLUSU
UVOĐENJE TRANSFORMACIONIH PRINCIPA: Formalna specifikacija i

automatska transformacija specifikacije u implemnetaciju
PROTOTIPSKI RAZVOJ: Odbacivi i nadgradivi prototipovi.

CASE ALATI
Uglavnom isti kao i ranije, samo prošireni sa
modelma podataka
Visual Paradigm
Rational Rose
Mnogi drugi
Ne samo “lower cases” - već delimični i

“uper cases”, generisanje baza podataka.
OBJEKTNE METODE
1980 -
APSTRAKTNI TIPOVI PODATAKA - PRETEČA
OBJEKTNI JEZICI
IZOLOVANE OBJEKTNE METODE
STANDARDI - UML - ZRELOST - 1998

APSTRAKTNI TIPOVI PODATAKA
REALNI SISTEM SOFTVERSKI SISTEM
Skup objekata, njihovih veza, njihovih Skup vrednosti (prostih istruktura) i

atributa i operacija nad njima operacija nad njima
“ SEMANTIČKA PRAZNINA”
APSTRAKTNI TIPOVI SU KORISNIČKI DEFINISANI TIPOVI, POGODNI ZA

OPIS REALNIH SISTEMA, KOJI TREBA DA SMANJE OVU “SEMANTIČKU
PRAZNINU”.
i
s
I nivo m APSTRAKTNI
p
p
e
ru~no prevo|enje l
c
(programiranje) e
i
m
f
e
II nivo i VIRTUELNI
n
k
t
automat. prevo|enje a
a
(kompilacija) c
c
i
i
III nivo j FIZI^KI
j
a
a
OSNOVE OBJEK TNOG PRI STUPA: SI STEM JE SK UP
POVEZANI H OBJEK ATA
Pod objektom se podrazumeva entitet koji je sposoban da ~uva svoja stanja i koji
stavlja na raspolaganje okolini skup operacija preko kojih se ta stanja prikazuju ili
menjaju.
Bitna karakteristika objekata u OO pristupima je u~aurenje (encapsulation),

sakrivanje informacijha (information hiding). U strogo objektnim pristupima jednini
vidljivi deo objekta su operacje i to ne na~in na koji su implementirane, ve} samo
njihovi efekti (specifikacija).
Aca
Oper acij e
Zapamti
starost
Prika` i starost
Kora~aj
I graj
Ska~i
U složenom sistemu postojaće mnoštvo objekata, pa bi i njihov direktan opis bio
veoma složen. Zbog toga je neophodno uvesti apstrakcije klasifikacije i generalizacije.
U apstrakciji klasifikacije definišu se pojam tipa, odnosno klase objekata.

U najnovijim pristupima se insistira na razlici koncepata tipa i klase objekata:
Pod tipom se podrazumeva kategorija objekata koji imaju isti skup stanja. Neki
konkretan objekat se tretira kao pojavljivanje tipa. Tip objekta se definiše sa dva
aspekta:
(1) kao jedan interfejs preko koga se definišu spoljne karakteristike objeketa toga
tipa i
(2) kao jedna ili više klasa koje pretstavljaju različite implementacije datog tipa.
STANDARDNI OPIS KLASA U UML-U
Ime-klase
vidljivost naziv-atributa-1: tip-podatka-1 = početna vrednost-1 šiskaz osobinać

vidljivost naziv-atributa-2: tip-podatka-1 = početna vrednost-1 šiskaz osobinać
.....................
vidljivost naziv-operacije-1 (lista-argumenata-1): tip-resultata-1 šiskaz osobinać

vidljivost naziv-operacije-2 (lista-argumenata-1): tip-resultata-2 šiskaz osobinać
....................
Svaka operacija ima “pozvani” objekat kao implicitni argument. Ponašanje operacije zavisi od
klase kojoj “pozavni” objekat pripada. Objekat “zna” svoju klasu, pa samim tim i način
implementacije posmatrane operacije. Osobina da objekat poziva neku operaciju drugog objekta
ne znajući kojoj klasi ovaj objekat pripada naziva se polimorfizam.
U OBJEKTNIM PRISTUPIMA JASNO SE RAZDVAJAJU MODELI I METODOLOGIJA
ZA MODELE SE DEFINIŠU STANDARDI: NAJPOZNATIJI STANDARD JE:
UML
Unified Modeling Language
Rational Software Corporation
1. G. Booch, J. Rumbaugh, I. Jackobson: "Unified Modeling Language User Guide, Addison Weseley", 1998
2. J. Rumbaugh, G. Booch, I. Jackobson: "Unified Modeling Language Reference Manual", Addison Weseley,
1998
3. I. Jackobson, G. Booch, J. Rumbaugh: "The Ojectory Software Development Process", Addison Weseley,
1998
MODELI
MODELI ZA OPIS FUNKCIJA SISTEMA:

Dijagrami slučajeva korišćenja: "Use Case Diagrams"
(Strukturna sistemska analiza)
MODELI ZA OPIS STRIKTURE SISTEMA:
Dijagrami klasa
(Model objekti veze)
MODELI ZA OPIS DINAMIKE:
Dijagrami sekvenci ( Sequence Diagrams)
Dijagrami kolaboracije (Collaboration Diagrams)
Dijagrami promene stanja (State Transition Diagrams)
Dijagrami aktivnosti (Activity Diagrams)
DIJAGRAMI ZA OPIS IMPLEMENTACIJE
Deployment Diagrams
PRIMER DIJAGRAMA SLUČAJEVA KORIŠĆENJA
BANKOVNI AUTOMAT
Podizanje novca
Komitent
Ulaganje
Ra~unar
banke
Prenos
Operater
Administracija
PRIMER DIJAGRAMA KLASA
Osoba Preduze}e
ime
naziv
adresa 1+ adresap
telefon
mtbr najva`niji proizvod
obra~unaj_vreme zaposli
zaradi_platu otpusti
poloàj nazivo
vrsta_posla
Rukovodi
Radnik Menadèr Odelenje
Projekat Proizvod
naziv_proj naziv
budèt cena
prioritet teìna
{najva`nijii_proizvod=Proizvod.naziv
za max (proizvod.cena) }
PRIMER DIJAGRAMA SEKVENCI Objekti
Trans
OPIS [ef obrade Radnik êk Izve{taj
plata
[ef startuje tran. i

po~ni
ubacuje datum za
svakog radnika
sra~unava se plata i ubaci
prikazuje {efu datum
sra~unaj platu
plata
{ef ubacuje obustavu ubaci

obustavu
{tampa se ~ek {tampaj
{tampa se izve{taj {tampaj

izve{taj
Granica Aktivacija
sistema Korisni~ki interfejs Doga|aj
PRIMER DIJAGRAMA KOLABORACIJE
formiraj ( )
Narud`benica
1. Dodaj ima
za
StavkaNar Artikal
1.1 proveri(StavkaNar)
1.2 izuzmi (StavkaNar.kol)
(a) Dijagram kolaboracije
Narud`benica
Narbr
...
Formiraj ( )
ima
StavkaNar Artikal
za
RbrSt ArtId
Kol KolSklad
Dodaj ( ) Proveri(StavkaNar)
Izuzmi(StavkaNar.kol)
(b) Dijagram klasa

PRIMER DIJAGRAMA PROMENE STANJA
DOGADJAJ 1 (argument)
STANJE 1 [uslov 1 ] / akcija 1 STANJE 2
do: AKTIVNOST 1 do: AKTIVNOST 2
[uslov 2 ] / akcija 2
STANJE 3
do: AKTIVNOST 3
PRIMER IMPLEMENTACIONOG DIJAGRAMA
Monty Server : Ra~unarServer
"baza_podataka"
sastanciDB
Rasporedjivanje rezervacija
Branov Ra~unar : PC
Planer
METODOLOGIJA
Pod metodologijom se podrazumeva definisani proces razvoja softvera, gde se u

različitim fazama primenjuju različiti standardni modeli
Podrazumeva se "sloboda" u definisanju metodologija, odnosno mogućnost

definisanja sopstvene metodologije
SISTEMSKO-TEORIJSKA OO METODOLOGIJA
LABORATORIJA ZA IS FON-a
MODEL "ŽIVOTNOG CIKLUSA"
IDENTIFIKACIJA SISTEMA
Definisanje funkcionalnog modela preko SSA
Definisanje Slučajeva korišćenja iz primitivnih funkcija SSA
REALIZACIJA SISTEMA
Definisanje strukture objektnog modela (ili Modela objekti veze)
Opis dinamike svakog Slučaja korišćenja
Definisanje potpunog dijagrama fundamentalnih klasa
PROJEKTOVANJE
Definisanje klasa baze podataka
Definisanje interfejs klasa
IMPLEMENTACIJA
PRIMER DEFINISANJA OPERACIJA ZA
DIJAGRAM KLASA
Narud`benica Stavka Artikal
Formiraj
Dodaj Proveri
Izuzmi
Narud`benica
Formiraj ( )
Stavka
Artikal
Dodaj ( )
Proveri ( )
Izuzmi ( )
POTPUNO ODVAJANJE SPECIFIKACIJE I
IMPLEMENTACIJE - TROSLOJNA
ARHITEKTURA SOFTERA
I NTERFEJS K ONTROL NE K L A SE BA Z E
K L A SE (POSL OV NE PODA TA K A
K L A SE)
K L I JENT A PL I K A CI ONI SERV ER BA Z E

SERV ER PODA TA K A
CASE ALATI
U znatno većoj meri su transformacioni
Visual Paradigm
Rational Rose
RAZVOJ INFORMACIONIH SISTEMA

Složenost razvoja IS i modeli “Životnog
ciklusa IS”
Složenost razvoja IS savladava se:

Razbijanjem celokupnog razvoja na faze –
način razbijanja na faze se naziva Model
životnog ciklusa IS
Dekompozicijom samog sistema, odnosno
definisanjem arhitekture sistema
Funkcionalna (strukturna) ili objektana
dekompozicija
Dvoslojna, troslojna ili višeslojna arhitektura
Modeli “životnog ciklusa IS”
Tri osnovne grupe (principa):
 Konvencionalni razvoj: striktno praćenje svih
pravila inženjerskog pristupa razvoju IS.
 Brzi razvoj: što pre doći do kakvog takvog
rešenja, pa ga onda usavršavati
 Formalni (transformacioni) razoj definisanje
formalnih modela i postupaka razvoja – formalna
transformacija formalne specifikacije IS u
implementaciju.
KONKRETNE MOTODE I PRISTUPI NE SPADAJU

STRIKTNO NI U JEDNU GRUPU – KOMBINUJU
DVA ILI SVA TRI PRINCIPA.
Konvencionalni razvoj
Konvencionalni “vodopad životni
ciklus” i sve njegove modifikacije:
“Fontana” model
Spralni model
(Iterativno) Inkrementalni pristup
KONVENCIONALNI "VODOPAD" ŽIVOTNI CIKLUS
PLANIRANJE
RAZVOJA
ANALIZA I
SPECIFIKACIJA
ZAHTEVA
PROJEKTO-
VANJE
IMPLEMENTA-
CIJA (kodiranje
i testiranje)
ODRŽAVANJE
KONVENCIONALNI ŽIVOTNI CIKLUS – STRUKURNI
PRISTUP
1. PLANIRANJE – BSP METODA
2. ANALIZA I SPECIFIKACIJA ZAHTEVA
STRUKTURNA SISTEMSKA ANALIZA NALAŽENJE SKUPA
“ATOMSKIH” FUNDAMENTALNIH FUNKCIJA SISTEMA,
NJIHOVIH ULAZA I IZLAZA
OPIS ULAZA, IZLAZA I SKLADI[TA PREKO RE^NIKA SSA.
OPIS POJEDINA^NIH ATOMSKIH FUNKCIJA PREKO
PSEUDOKODA
PRISTUP
2. PROJEKTOVANJE
Logičko projektovanje
Izgradnja odgovarajućeg modela podataka (model objekti-veze)
Transformacija modela objekti veze u normalizovan relacioni model.
Projektovanje strukturnih programa
Fizičko projektovanje
Fizičko projektovanje baza podataka
Projektovanje korisničkog interfejsa
Dodavanje “fižičkih elemenata” strukturnim programima.
PRISTUP
4. Implementacija
Kodiranje u nekom strukturnom jeziku i testiranje ili
Primena generatora aplikacija (jezika četvrte generacije)
Relacione baze podataka i dvoslojna klijent-server arhitektura.
KLIJENT
(Forme, kod
aplik.)
SERVER BAZE
P ODAT AKA
(Struktura baze i
dinami~ka pravila
integr) .
KONVENCIONALNI ŽIVOTNI CIKLUS – OBJEKTNI
PRISTUP
1. PLANIRANJE – Ništa specifično
2. ANALIZA I SPECIFIKACIJA ZAHTEVA
• Izrada Slučajeva korišćenja: Dijagram slučajeva korišćenja i
verbalni opis svakog SK
• Izrada sistemskih dijsgrama sekvenci
Opis SK:
<<extend>> Upravljanje 1. Učesnici
Prodaja
zalihama
2. Namena
<<include>>
<<include>
>
3. Kratak opis
4. Pre i Post uslovi
Registrovanje 5. Opis osnovnog toka
artikala Placanje
događaja
6. Opis alternativnog
toka događaja
Placanje u Placanje
gotovom katicom
KASIR
:System
unesi stavku (prkod, kol)

SISTEMSKI DIJAGRAM
SEKVENCI ZA SLUČAJ kraj prodaje ( )
KORIŠĆENJA “PRODAJA”
placanje (iznos)
PRISTUP
3. PROJEKTOVANJE
Logičko projektovanje
Izrada konceptualnog modela (dijagrama klasa bez operacija)
Izgradnja dijagrama sekvenci, dijagrama kolaboracije ili dijagrama
aktivnosti za opis dinamike sistema (logike aplikacije)
Izgradnja kompletnog logičkog modela sistema (dijagram klasa sa
operacijama definisanim preko dijagrama sekvenci kolaboracije ili
aktivnosti)
PRISTUP
4. PROJEKTOVANJE
Fizičko projektovanje (zavisno od konkretnog okruženja)
Projektovanje baze podataka
Projektovanje korisničkog interfejsa
Dodavanje novih klasa na osnovu odgovarajućih uzora (pattern-a): MVC
patern, Perzistentni brokeri i mnogi drugi
Izgradnja kompletnog fizičkog modela sistema
PRISTUP
5. IMLEMENTACIJA
Raspoređivanje delova modela na pojedine elemente višeslojne arhitekture,
Transformacija fizičkog modela u konkretno implenemtaciono okruženje
Dodatno kodiranje
Testiranje
KONVENCIONALNI ŽIVOTNI CIKLUS – NEDOSTACI
PLANIRANJE
RAZVOJA
ANALIZA I
SPECIFIKACIJA
ZAHTEVA
PROJEKTO-
VANJE
IMPLEMENTA-
CIJA (kodiranje
i testiranje)
Problemi razvoja: ODRŽAVANJE
Teško je, gotovo nemoguće utvrditi sve zahteve

na početku projekta i potpuno tačno;
Projekti su obično dugotrajni t teško je
skrupulozno sprovesti metodologiju do kraja
Do prve verzije sistema (koja bi trebalo da bude
konačna) dolazi se veoma sporo. Zaksneo
povratni uticaj korisnika
Veoma obimna dokumentacija za velike projekte.
KONVENCIONALNI ŽIVOTNI CIKLUS – NEDOSTACI
PLANIRANJE
RAZVOJA
ANALIZA I
SPECIFIKACIJA
ZAHTEVA
PROJEKTO-
VANJE
IMPLEMENTA-
CIJA (kodiranje
i testiranje)
Problemi održavanja:
ODRŽAVANJE
Veoma skupo održavanje

Dvostruko održavanje, održavanje koda i
održavanje projektne dokumentacije
U slučaju izmene zahteva treba proći ponovo kroz
sve faze projektaovanja i izvršiti izmene. To se
obično ne radi, pa na kraju, i pored ogromnog
truda imamo nesaglasnost koda i projektne
dokumentacije.
SVI OVI NEDOSTACI I ZNATNO MANJOJ

MERI DOLAZE DO IZRAŽAJA U OBJEKTNIM
PRISTUPIMA!
Modifikacije konvencionalnog životnog
ciklusa: Spiralni model
Analiza i Analiza izvodljivosti

specifikacija zahteva
Evaluacija i Izrada prototipa

Planiranje sledećeg
ciklusa
Prototipovi sliže za:
–Validaciju kor. Zahteva
–Experimenat sa implementacionim
okruženjem
Modifikacije konvencionalnog životnog ciklusa:
Inkrementalni model
Prethodi podela na podsisteme,

odnosno definisanje polazne
arhitekture sistema
Modifikacije konvencionalnog životnog ciklusa:
Iterativno-inkrementalni razvoj
(Unified Software Development process
Inception Elaboration Construction Transition
Requirements
An iteration in the
elaboration phase
Analysis
Design
Implementation
Test
P r e lim in a r y ite r. ite r. ite r. ite r. ite r. ite r. ite r.

Ite r a tio n (s ) #1 #2 #k #k +1 # k+2 # n-1 #n
Brzi (rapid, agile) razvoj
U ovom pristupu, umesto da se trudimo da
detaljnom analizom pokušamo da utvrdimo
potpune zahteve korisnika, pokušavamo da
razvijemo sistem sa nekompletno definisanim
zahtevima.
Prototipski razvoj- rapid prototyping
Agile Software Development

Izmena specifikacije
Prototipski razvoj
Specifikacija
arhitekture sistema Specifikacija Evaluacija
Izrada prototipa
(baze podataka i aplikacije prototipa
skupa aplikacija)
Projektovanje i
izgradnja konačne
aplikacije
–Prototipovi aplikacija a ne celog sistema

–Prethodno definisanje arhitekture sistema: skupa aplikacija i modela (baze)
podataka
–Postojanje alata za izradu prototipova, prototip mora brzo i jeftino da bude
urađen (Jezici četvrte generacije)
–Loša dokumentacija, teško održavanje ovako izgrađenog sistema
Agile Software Development
Cilj je kod koji radi, a ne perfektna
dokumentacija. Više se vodi računa o
organizaciji ljudi koji rade na projektu, a manje
o metodologijama i alatima za razvoj.
Najpopularniji Agile Development pristup je
XP (Extreme Programming). XP je
projektovan za male timove koji treba da brzo
razviju neki softver u okruženju sa stalno
promenljivim zahtevima. U takvom okruženju
konvencionalni životni ciklus bi bio
neupotrebljiv.
XP (Extreme Programming)
XP se zasniva na sledećim principima:
1. Planiranje. Korisnik daje procenu dobiti za
realizaciju pojedinih zahteva, a programeri
odgovarajuću procenu troškova i na osnovu toga se
određuju zahtevi koji će biti realizovani odmah i
zatevi koji će biti odloženi.
2. Jednostavna realizacija. XP tim proizvodi
jednostavne sisteme i a zatim ih učestalo menja i
poboljšava
3. Metafora. XP timovi koriste zajednički “sistem
imena” i zajedniučki opis sistema.
4. Jednostavno projektovanje. XP podrazumeva da
se svaki program pravi na najednostavniji način koji
zadovoljava zahteve.
5. Testiranje. Stalno se vrši validacija sistema. Prvo se
definiše test, a onda se razvija softver koji treba da
ga zadovolji. Korisnik definiše test za prihvatanje
sistema.
6. Refactoring. Softver se stalno poboljšava, s tim da
se očuva njegova jednostavnost. Ne prave se
duplikati.
7. Programiranje u parovima. Dva programera
razvijaju jedan kod kontrolišući jedan drugog. Rade
na istoj mašini. Pokazuje se da ovakav razvoja daje
znatno bolje rezultate od individualnog razvoja.
8. Kolektivno vlasništvo. Ceo kod pripada svim
programerima. Kad god je potrebna neka izmena
bilo ko može da je izvrši.
9. Stalna integracija. Integracija razvijenih delova
radi se više puta dnevno. To zahteva učešće
svih programera i ubrzava proces razvoja.
10. 40-časovna radna nedelja. Prekovremeni rad
je izuzetak. Programeri treba da budu odmorni,
zdravi i produktivni.
11. Stalno prisustvo korisnika. Značajno se
poboljšava komunikacija, smanjuje potreba za
prepiskom i dokumentacijom.
12. Standardno kodiranje. Svi programeri treba
da pišu kod na isti, standardni, način da bi se
principi XP-a mogli da sprovedu.
Formalni (transformacioni)
razoj
Evaluacija i
inverzna
transformacija
Transformacija
Analiza Formalna
specifikacije u Radni sistem
zahteva specifikacija
implementaciju
• Izvršni kod se dobija isključivo transformacijom formalne

specifikacije u implementaciju
• Ovakav pristup omogućuje jednostavnu promenu
implementacionog okruženja (platforme) - jednostavno
“adaptivno održavanje”
• Perfektivno održavanje sistema se značajno pojednostavljuje –
nema “dvostrukog održavanja” (dokumentacije i koda)
razoj
Evaluacija i
inverzna
transformacija
Transformacija
Analiza Formalna
specifikacije u Radni sistem
zahteva specifikacija
implementaciju
Koji se jezici (modeli) koriste za formalnu

specifikaciju?
Kako se vrši transformacija formalne specifikacije u
radni sistem (kod)?
Kako se vrši formalna inverzna transformacija?
razoj
U vreme kada je definisan transformacioni pristup
je bio moguć samo za veoma specifične i
jednostavne sisteme za koje ke bilo moguće
definisti formalni specifikacioni jezik i
odgovarajuću transformaciju
CASE alati delimično podržavaju ovakav pristup
(Model objekti-veze kao jezik za specifikaciju i
SQL ko radni sistem, na primer)
Osnovna ideja, značajne prednosti ovoga
pristupa, sve bolji jezici (modeli) za specifikaciju i
CASE alati stalno unapređuju transformacioni
pristup razvoju IS.
Transformacioni razvoj:Cleanroom engineering
Cleanroom engineering koji je predložio IBM (druga

polovina 80-tih) je rigorozni metod razvoja u kome
“greške nisu dozvoljene” (za razliku od drugih pristupa
koji se zasnivaju na “trial-and-error” pristupima).
Cleanroom engineering polazi od činjenice da su

programi način realizacije matematičkih funkcija.
Za specifikaciju programa neophodno je definisati
funkciju koja u potpunosti opisuje ponašanje koje se od
programa zahteva. Nalaženje procedure koja realizuje tu
funkciju je osnova razvoja softvera.
Transformacioni razvoj:Cleanroom
engineering
U Y Crna
S
kutija
S
X
U U x X --> X U x X --> Y Y
Prelazna funkcija Izlazna
stanja trasformacija Kutija
stanja
S u12 y12
U Y
u11 y11
u13 y13
Prozračna
kutija
Transformacioni razvoj:”Sistemsko-
teorijski životni ciklus” – FON kraj prošlog
veka
1. Identifikacija sistema: nalaženje funkcionalnog modela sistema, na osnovu
nekog posmatranja (analize):
S:šFa : T x U ---> Y, a e A}
2. Realizacija sistema: nalaženje modela sistema u izabranom prostoru stanja.
: U x X  X (Funkcija prelaza stanja)
 = U x X  Y (Izlazna transformacija)
3. Implementacija: kodiranje i testiranje
Transformacioni razvoj:”Sistemsko-
teorijski životni ciklus” – FON kraj prošlog
veka
Identifikacija sistema – skup funkcija (bilo koji alat za funkcionalnu
specifikaciju sistema, Dijagrami tokova podataka, najbolje, a mogu i
Slučajevi korišćenja)
Realizacija sistema:
Izbor najpovoljnijeg modela za realizaciju
funkcija
Nalaženje minimalne realizacije u okviru
izabranog modela.
SISTEMSKO-TEORIJSKI “ŽIVOTNI CIKLUS”
Ponekad se u “Sistemsko-teorijski životni

ciklus” daodaje i četvrta faza:
4. Sinteza upravljanja
čime se realizuje upravljačka funkcija IS,

odnosno MIS (Management Information System)
UPRAVLJAČKI INFORMACIONI SISTEMI
• Samosinhronzovani skup
K o r i sn i k
( A k ter )
Aplikacija
• Sinhronizacija preko podataka

F1 F2 u bazi
O B JE K T N I M O D E L • Omogućeno upravljanje
SK U P M E \ U SO B N O P O V E Z A N I H pojedinačnim funkcijama
O B JE K A T A
• Savremeni menadžment je
orjentisan prema upravljanju
procesima koji predstavljaju
F3 F4 F5
orkestraciju funkcija u cilju
obavljanja nekog zadatka.
K o r i sn i k K o r i sn i k
( A k ter ) ( A k ter )
Upravljanje procesima- Modeli procesa
Danas postoji gotovo opšta saglasnost da je upravljanje međusobno
povezanim i međusobno zavisnim poslovnim procesima ("process
centered management approach") osnova uspešnog funkcionisanja
bilo koje organizacije
Reinženjering Razvoj
Upravljanje
poslovnih ..... informacionih
kvalitetom
procesa sistema
Modeli (poslovnih)
procesa
Standardi i
modeliranje
UPRAVLJAČKI INFORMACIONI SISTEMI
P R O C E SO R 1
 Praćenje realizacije
F1 F2
nekog ugovora,
 Praćenje realizacije
U P R A V L JA ^ K I
M E H A N IZ A M
"W F E N G IN E "
M O D E L PO D A T A K A
O B JE K T N I M O D E L
narudžbenice kupca,
 Sprovođenje nekog
F3 F4 F5 upravnog postupka i
slično.
P R O C E SO R 2 P R O C E SO R 3
Odnos poslovnih procesa i poslovnih funkcija
Upravljački mehanizam sadrži:

• Model poslovnih procesa
• Model organizaciono-tehnološkog okruženja
• Operativni plan obavljanja poslovnih procesa
• Operacije za upravljanje: lansiranje u suspedndovanje posla,
preraspodela izvršioca i slično
Transformacioni razvoj:Modelom
vođeni razvoj
Model Driven Architecture (MDA) koju je 2001
predložila Object Management Group je “an
approach to using models in software
development”. Zato je bolje koristiti prevod
Modelom vođeni razvoj mego Modelom
vođene arhitekture.
Pojam arhitektura se vezuje za činjenicu da
se preko asptraktnih modela (PIM) može da
ostvari inteoperabilnost heterogenih sistema.
Modelom vođeni razvoj
Računarski Computation Independent Model –CIM – model
odgovarajućeg domena, zajednički rečnik za korisnika i
nezavisan model
CIM
projektanta
Platform Independent Model – PIM.

Platformski Model za opis Model IS nezavisan od
nezavisan model Platforme
PIM PDM implementacione platforme.
Specifikacija sistema
Transformacija Platform Description Model –PDM

Model implementacione platforme
Platformski zavisan
model Platform Specific Model- PSM
PSM
Model IS implementiran u datom
okruženju.
Modelom vođeni razvoj
Modelom vođeni razvoj omogućava:
Specifikaciju sistema nezavisnu od bilo
kakve implementacije;
Specifikaciju platforme;
Izbor platforme za implementaciju
specifikaovanog sistema;
Transformaciju specifikacije sistema u
izabranu platformu.
Reference: Osnovne
1. G.Booch, J.Rambaugh, I Jacobson, The Unified
Modeling Language – User Guide,Addison
Weseley,1999,
2. J.Rambaugh, I Jacobson, G.Booch, The Unified
Modeling Language – Reference Manual,Addison
Weseley,1999,
3. I Jacobson, G.Booch, J.Rambaugh, The Unified
Software Development Process, Addison
Weseley,1999,
4. Larman, G., Applying UML and Patterns, Prentice
Hall, 1998.
5. Gamma, E., Helm, R., Johnson, R., Vlissider, J.,
Design Patterns, Addison-Weseley, 1995.
6. Fowler, M., Analysis Patterns, Addison –Weseley,
Reference: Dati materijali
4. OMG, UML 2.0 Infrastructure Specification
5. OMG, UML 2.0 Superstructur Specification
6. OMG, MDA Guide Version 1.0.1
7. OMG, Meta Object Facility (MOF) 2.0 Core
Proposal
8. OMG, MetaObjectFacility(MOF)Specification
9. Rational Software Corporation, UML Profile For
EJB
10. J.Bezevin, Model Engineering for Software
Modernization
Reference: Dati materijali
11. L.Fernández, and A.Moreno, An Introduction to UML
Profles
12. Jean Bezivin, Applying MDA Approach to B2B
Applications: A Road Map
13. John D. Poole, Model-Driven Architecture: Vision,
Standards and Emerging Technologies
ANALIZA ZAHTEVA I
SPECIFIKACIJA IS
MODELI I MODELOVANJE
• Model je "subjektivni odraz objektivne stvarnosti". Zbog

toga može da postoji više različitih modela istog sistema, sa
istog ili različitih aspekata.
• Model je neka simplifikacija realnosti
• Modeli se izgrađuju da bi se bolje razumeo realni sistem
• Modelovanje je način da se savlada složenost nekog
sistema
• Modelovanje je opšti pristup u svim inženjerskim
disciplinama
• U svakoj oblasti postoji, obično više, intelektualnih alata
(jezika) za modelovanje sistema - UML za oblast
razvoja softvera
CILJEVI UML-a
OPŠTI VIZUELNI JEZIK ZA MODELOVANJE
SOFTVERSKIH SISTEMA I RAZMENU DOBIJENIH
MODELA
MOGUĆNOST PROŠIRENJA I SPECIJALIZACIJE

OSNOVNIH KONCEPATA U SKLADU SA POTREBAMA
VRSTE SISTEMA KOJA SE MODELIRA
PODRŠKA SPECIFIKACIJI NEZAVISNOJ OD RAZVOJNE

METODOLOGIJE I IMPLEMENTACIONOG OKRUŽENJA
UVOĐENJE FORMALIZMA KOJI ĆE OMOGUĆITI

RAZUMEVANJE JEZIKA
PODRŠKA KONCEPTIMA VIŠIH NIVO APSTRAKCIJE:

KOMPONENTA, KOLABORACIJA, APLIKACIONI KOSTUR
ASPEKTI MODELA U UML-U
Za svaki aspekt daje se statički i dinamički
opis sistema
Modeli i dijagrami
Model je potpun opis sistema
sa neke tačke gledišta
State
State
Diagrams
Dijagrami
Diagrams
Use Case klasa
Use Case
Dijagrami
Diagrams State
Use Case Diagrams State
Diagrams
Use Case slučajeva Dijagrami
Diagrams
Dijagrami Diagrams
Diagrams korišćenja objekata
sekvenci
Scenario State
Scenario
Diagrams State
Diagrams
Dijagrami
Diagrams Dijagrami
Diagrams
kolaboracije Modeli komponenti
Scenario Component
Scenario Component
Diagrams
Diagrams
Dijagrami Dijagrami
Diagrams
Diagrams Rasporeda
prelaza stanja Dijagrami
aktivnosti
ASPEKT SLUČAJEVA KORIŠĆENJA
Opisuje se ponašanje sistema sa tačke gledišta

korisnika prvenstveno, a koristi se u analizi i
testiranju takođe. Predstavljaju funkcionalnu
specifikaciju sistema.
Statički opis ovoga aspekta daje se preko

Dijagrama slučajeva korišćenja, a
dinamički, prvenstveno tekstualno, a zatim i
preko dijagrama interakcija, dijagrama
promene stanja ili dijagrama aktivnosti.
ASPEKT PROJEKTOVANJA
Aspekt projektovanja predstavlja realizaciju

sistema u "objektnom prostoru stanja".

Dijagram klasa i Dijagrama objekata.
Dinamički opis se daje preko dijagrama

interakcija, dijagrama promene stanja i
dijagrama aktivnosti.
ASPEKT IMPLEMENTACIJE
Aspekt implementacije predstavlja komponente i

fajlove preko kojih se sistem fizički ostvaruje.

Dijagrama komponenti.

ASPEKT PROCESA
Aspekt procesa opisuje način odvijanja procesa u

sistemu, "niti" procesa, konkurentnost i
sinhronizaciju.
Koriste se isti dijagrami kao i u aspektu

projektovanja i za statički i za dinamički opis, a
najviše dijagrami aktivnosti.
ASPEKT RAZMEŠTANJA
Aspekt razmeštanja predstavlja topologiju sistema,

računarsko-komunikacionu mrežu. Pokazuje se kako
su u ovoj mreži razmeštene komponente koje
predstavljaju fizičku realizaciju sistema.
Dijagrami razmeštaja se koriste za statički opis.

FUNKCIONALNI MODEL SISTEMA
STRUKTURNA SISTEMSKA ANALIZA
SLUČAJEVI KORIŠĆENJA
Informacioni sistemi mogu biti veoma složeni. OO model

složenog IS može sadržati i nekoliko hiljada različitih
objekata sa mnoštvom njihovih atributa i veza. Zbog toga
prvi modeli u razvoju nekog sistema ne mogu da budu
objektni, moraju biti funkcionalni.
KAO ALATI ZA MODELOVANJE FUNKCIJA SISTEMA

(TRANSFORMACIJE ULAZA U IZLAZ) KORISTIĆE SE:
• STRUKTURNA SISTEMSKA ANALIZA (KONVENCIONALNI MODEL) I
• MODEL SLUČAJEVA KORIŠĆENJA (UML)
FUNKCIONALNI MODEL SISTEMA
PREDSTAVLJA SISTEM KAO "CRNU KUTIJU"
PREDSTAVLJA SE FUNKCIONALNOST SISTEMA NA

NAČIN KAKO JE VIDE SPOLJNI OBJEKTI
PREDSTAVLJAJU SE ULAZI I IZLAZI IZ SISTEMA I

FUNKCIJE KOJE TRANSFORMIŠU ULAZE (POBUDU,
STIMULACIJU) U IZLAZE
PREDSTAVLJA MODEL ZAHTEVA JER TREBA DA

POKAŽE POTPUNO, PRECIZNO I NEDVOSMISLENO
KAKO ĆE OBJEKTI VAN SISTEMA (KORISNICI,
AKTERI) KORISTITI POSMATRANI SISTEM)
Zadatak funkcionalnog
modelovanja je: R1 R2
Y 1 U 1
U 2 Y 2 U 3 Y 3
• dekomponovanje složenog SISTEM U m

Rn
S
sistema na skup podsistema Y m
(“logičkih jedinica posla”, (a) Sistem kao celina
“atomskih transakcija”,
“slučajeva korišćenja”) - SSA
R1 R2
Y 3
• opis pojedinačnih podmodela

U 1 Y 1
U 2
Y 2
U 3
tako da, s jedne strane budu S1 S2 S3
razumljivi korisniku, a sa druge

da posluže da se iz njih na
STANJE SISTEMA
(KOMUNIKACIJA)
organizovan način mogu da

Sm
formiraju ostali (objektni) U m
modeli, odnosno nastavi i Rn Y m
kontroliše dalji proces razvoja (b) Dekomponovani sistem sa podsistemima koji
softverskog sistema - SK
komuniciraju samo preko stanja sistema
MODEL SLUČAJEVA KORIŠĆENJA
Pod terminom “slučaj korišćenja” podrazumeva se
jedan specifičan način korišćenja IS, jedna “atomska”
funkcija IS. Preko “slučaja korišćenja” opisuje se interakcija
nekog objekta van sistema sa samim IS. Skup “slučajeva
korišćenja” predstavlja sve pretpostavljene načine korišćenja
sistema.
Model slučajeva korišćenja je graf sa dve vrste

čvorova: čvorovima koje predstavljaju aktere i
čvorovima koji predstavljaju slučajeve korišćenja.
Akter je objekat van sistema koji predstavlja tip (vrstu)
korisnika. Akter je bilo šta što stupa u interakciju sa IS, ništa
drugo van posmatranog IS nema nikakav uticaj na sistem.
Akter može biti korisnik (čovek) ili neki drugi sistem. Treba
praviti razliku između korisnika i aktera. Korisnik je čovek
koji koristi sistem, dok je akter specifična uloga koju
korisnik ima u komunikaciji sa sistemom.
OPŠTI MODEL SLUČAJEVA KORIŠĆENJA
Direktna komunikacija između dva aktera i dva konkretna

(oni sa kojima komuniciraju akteri) slučaja korišćenja se ne
može predstaviti na modelu (grafu). Međutim, kako će
kasnije biti prikazano, moguće je definisati asocijaciju
između klasa slučajeva korišćenja i klasa aktera (apstraktni
akteri i apstraktni slučajevi korišćenja), da bi se jednostavnije
prikazao neki složeni model.
PRIMER SLUČAJA KORIŠĆENJA
OPIS SLUČAJA KORIŠĆENJA - SCENARIO
Svaki slučaj korišćenja treba da bude detaljno opisan.
Mada je moguće davati i formalan opis slučaja korišćenja
(dijagrami interakcije, dijagram promene stanja)
preporučuje se da se u prvoj fazi koristi struktuirani
verbalni opis, jer je on neophodan čak i ako se da neki
formalni opis.
Uobičajeno je, takođe, da se posebno daje opis normalnog

toka događaja u slučaja korišćenja, a posebno mogući
izuzeci.
Jedan slučaj korišćenja predstavlja skup sekvenci

događaja. Jedna sekvenca događaja se naziva scenario.
Postoji osnovni scenario i skup mogućih izuzetaka i
alternativnih funkcionisanja.
PODIZANJE NOVCA: osnovni scenario
Provera kartice: Komitent ubacuje karticu u automat.

Automat čita karticu i proverava da li je prihvatljiva. Ako je
prihvatljiva, zahteva se od komitenta da unese “tajnu šifru”.
Proveravanje šifre: Komitent unosi tajnu šifru. Ako je šifra
korektna zahteva se da korisnik izabere transakciju.
Unos tipa transakcije: Komitent bira “podizanje novca” i
automat šalje računaru banke tajnu šifru da bi se dobili brojevi
komitentovih računa. Dobijaju se komitentovi brojevi računa i
prikazuju na ekranu automata.
Podizanja novca: Komitent bira račun i unosi iznos koji
podiže.Automat šalje računaru banke zahtev za podizanje datog
iznosa sa datog računa. Priprema se štampanje izveštaja za
komitenta.
Kraj: Automat vraća karticu komitentu. Izdaje se izveštaj
komitentu
PODIZANJE NOVCA:- alternativna scenaria
Kartica nije prihvatljiva: Kartica se vraća korisniku

sa zvučnim signalom.
Nekorektna tajna šifra: Odgovarajuća poruka se

prikazuje na ekranu i daje se šansa korisniku da je
ponovo unese. Dozvoljava se tri pokušaja, a zatim se
vraća kartica korisniku.
Prekid: Korisnik može u svakom trenutku da prekine

transakciju. Poništiće se svi dotadašnji efekti i vratiti
kartica korisniku.
Mada SK treba, prvenstveno, da bude logički opis korišćenja
sistema, treba imati u vidu i buduću arhitekturu sistema, a
ponekad se opis daje preciznije ako je prethodno definisan
korisnički interfejs. To ne sme da implicira zavisnost buduće
aplikacije od interfejsa.
POD 7 8 9
ULAG 4 5 6
PRENOS 1 2 3
PREKID 0
SPREMAN PONOVI POMO]
PRINTER IZDAVANJE NOVCA
ÎTA^ KARTICE ULAGANJE NOVCA

VEZE U DIJAGRAMIMA SLUČAJEVA
KORIŠĆENJA
ASOCIJACIJA - prikazana veza između aktera i
slučaja korišćenja
GENERALIZACIJA - veza opštijeg i specifičnijeg

slučaja korišćenja koji nasleđuje opis opštijeg
<<extend>> - stereotip veze zavisnosti koja

referencira (ubacuje) moguće dodatno"ponašanje"
opisano u posebnom apstraktnom SK, u osnovni SK
<<include>> - stereotip veze zavisnosti koja

eksplicitno ubacuje dodatno "ponašanje" opisano u
posebnom apstraktnom SK, u osnovni SK
ILUSTRACIJA VEZE
<<include>>
Osnovni SK eksplicitno
uključuje ponašanje
opisano sa apstraktnim
SK. Služi da se izbegne
višestruko opisivanje istog
ponašanja.
PRIMER VEZE
<<extend>>
Osnovni SK implicitno
proširuje ponašanje opisano
u apstraktnom SK.
Proširenje se vrši u tzv
"tačkama proširenja“
("uključi statistiku", za dati
primer)
PRIMER GENERALIZACIJE SK
Gde god se koristi

SK nadtip, može se
koristiti i SK podtip
APSTRAKTNI AKTER
Kada dva aktera imaju slične uloge u odnosu na sistem oni mogu
naslediti zajedničkog apstraktnog aktera. Ako se isti slučaj
korišćenja može povezati sa različitim akterima, pogodno je
definisati apstraktnog aktera i opisati samo jedan slučaj
korišćenja. Koncept apstraktnog aktera je takođe koristan za
opisivanje privilegija u korišćenju nekog sistema.
Primalac izveštaja
o ukupnom
prometu
Komitent Administrator
KOLABORACIJA I SLUČAJ KORIŠĆENJA
Kolaboracija "Sistem za automatske
transakcije sa novcem" implementira
(realizuje) SK "Podizanje".
Kolaboracija je asocijacija elemenata
koji u međusobnoj saradnji realizuju
neki zahtev. (Navedene klase
"učesnici")
"Use Case Driven

Development Process"
OPIS SCENARIJA PREKO
SISTEMSKOG DIJAGRAMA SEKVENCI
PROBLEMI
U nekom složenom sistemu broj slučajeva korišćenja

može da bude veoma veliki. Kako definisati taj skup
slučajeva korišćenja?
Kako pokupiti "znanje" o strukturama podataka u

postojećem sistemu, korisno da se izgradi
konceptualni model sistema (dijagram klasa)?
Metoda SSA, kao metoda funkcionalne

dekompozicije, može da bude odgovor, na ovo
a i na neka druga pitanja modelovanja
(modelovanje poslovnih procesa)
Strukturna sistemska analiza (SSA) je jedna potpuna

konvencionalna metoda za specifikaciju
informacionog sistema, odnosno softvera. Ona se na
različite načine može povezati sa drugim metodama i
modelima za projektovanje softvera, pa i sa
objektnim metodama.
SSA posmatra informacioni sistem kao funkciju

(proces obrade) koja, na bazi ulaznih, generiše izlazne
podatke. Ulazni podaci se dovode u proces obrade, a
izlazni iz njega odvode preko tokova podataka.
Imajući u vidu zahtev da specifikacija treba da se
oslobodi svih implementacionih detalja od interesa su
samo sadržaj i struktura ulaznog toka, a ne i medijum
nosilac toka.
Osnovni koncepti za specifikaciju IS u SSA su:
funkcije, odnosno procesi obrade podataka,
interfejsi, objekti van sistema sa kojima sistem
komunicira preko tokova podataka,
tokovi podataka, preko kojih se podaci prenose između
interfejsa, funkcije i skladišta,
skladišta podataka, u kojima se permanentno čuvaju
stanja sistema
Njihov međusobni odnos se prikazuje preko dijagrama

toka podataka koji prikazuje vezu interfejsa, odnosno
skladišta kao izvora odnosno ponora podataka, sa
odgovarajućim procesima, kao i međusobnu vezu
procesa.
OSNOVNI KONCEPTI SSA
SPOLJNI_ TOK_PODATAKA_1
OBJEKAT_1
TOK_PODATAKA_6
SPOLJNI_
PROCES_A
OBJEKAT_2
1.
TOK_PODATAKA_2
TOK_PODATAKA_3
TOK_PODATAKA_5
TOK_PODATAKA_4
PROCES_B
2.
SKLADI[TE_PODATAKA
HIJERARHISKA DEKOMPOZICIJA PROCESA
NIVO I
SPOLJNI_ TOKP_1 PROC_A TOKP_4 TOKP_6 SPOLJNI_

PROC_D
OBJEKAT_1 1. 4. OBJEKAT_3
SKLADP_1 SKLADP_2
TOKP_3
TOKP_2 TOKP_5
SPOLJNI_ PROC_B PROC_C
OBJEKAT_2 2. 3.
TOKP_3 NIVO II
PROC_BA
2.1
TOKP_2a
SPOLJNI_ SKLADP_3 TOKP_5

OBJEKAT_2
TOKP_2b
PROC_BC
TOKP_7 2.3
PROC_BB
2.2
Imajući u vidu sve rečeno, jednu potpunu specifikaciju IS
čine:
1. Hijerarhijski organizovan skup dijagrama toka
podataka;
2. Rečnik podataka koji opisuje sadržaj i strukturu svih
tokova skladišta podataka;
3. Specifikacija logike primitivnih procesa;
Pored dijagrama tokova podataka uobičajeno je za jedan

sistem da se prikaže i Dijagram dekompozicije koji
prikazuje celokupnu dekompoziciju sistema, od Dijagrama
konteksta do primitivnih funkcija. Ovde se predlaže da se
za izradu Dijagrama dekompozicije koriste Jackson-ovi
dijagrami, jer se sa njima može opisati i logika primitivnuh
procesa i time izvršiti bolja priprema za konstukciju
Dijagram slučajeva korišćenja
SSA- SINTAKSNA I METODOLOŠKA PRAVILA
• Za formiranje DTP - ova postoji čitav skup formalnih (sintaksnih)

pravila. Najznačajnije je pravilo koje se mora poštovati pri
dekompoziciji procesa, pravilo balansa tokova: Ulazni i izlazni
tokovi na celokupnom DTP-u koji je dobijen dekompozicijom nekog
procesa P moraju biti ekvivalentni sa ulaznim i izlaznim tokovima
toga procesa P na dijagramu višeg nivoa. Pri tome se uzima u obzir
dekompozicija tokova predstavljena u rečniku podataka.
• Kao najvažnije metodološko pravilo koristi se pravilo da funkcije na

DTP-u između sebe treba da komuniciraju isključivo preko
skladišta. Korišćenje ovoga pravila vodi uvek ka identifikaciji nekih
fundamentalnih funkcija u sistemu, fundamentalnih sa sledeće dve
tačke gledišta:
(I) funkcije su autonomne, jedna od druge zavise isključivo
preko skladišta;
(II) bilo koja složenija funkcija dobija odgovarajućim
kombinovanje fundamentalnih
JACKSON-ovi DIJAGRAMI ZA OPIS
STRUKTURE PODATAKA I PROGRAMA
Potiču iz Jackson-ove metode razvoja programa koja
polazi od stava da se struktura programa može
dedukovati iz strukture podataka na njegovom ulazu i
izlazu.
Koriste se sledeće oznake:
Agregacija podataka Selekcija podataka Skup

Sekvenca Selekcija Iteracija
PRIMER SSA- BANKOVNI AUTOMAT
KOMITENT
Podaci za Podaci za Podaci za

Račun
ulaganje podizanje prenos
BANKOVNI
Dijagram AUTOMAT
konteksta
BAZA PODATAKA
RAČUNARA BANKE
KOMITENT
Račun
Podaci za
ulaganje Račun Podaci za
Račun Podaci za
podizanje prenos
ULAGANJE PODIZANJE PRENOS
BAZA PODATAKA RAČUNARA

BANKE
Dijagram prvog nivoa

Jackson-ov dijagram dekompozicije

[]
BANKOVNI AUTOMAT
<> <> <>

PROVERA PROVERA PROVERA

KARTICE KARTICE KARTICE

TAJNE [IFRE TAJNE [IFRE TAJNE [IFRE

NOVCA NOVCA NOVCA
ZAVR[ETAK ZAVR[ETAK ZAVR[ETAK

RADA RADA RADA
(Označeni su zajednički delovi u različitim primitivnim procesima

– kandidati za apstraktne slučajeve korišćenja)
PRIMER SLUČAJA KORIŠĆENJA
PRIMER VEZE
<<extend>>
Osnovni SK implicitno
proširuje ponašanje opisano
u apstraktnom SK.
Proširenje se vrši u tzv
"tačkama proširenja“
("uključi statistiku", za dati
primer)
PRIMER GENERALIZACIJE SK
Gde god se koristi

SK nadtip, može se
koristiti i SK podtip
[]
BANKOVNI AUTOMAT
<> <> <>


KARTICE KARTICE KARTICE

TAJNE [IFRE TAJNE [IFRE TAJNE [IFRE

NOVCA NOVCA NOVCA
ZAVR[ETAK ZAVR[ETAK ZAVR[ETAK

RADA RADA RADA
KONCEPTUALNO
MODELOVANJE
Konceputulani model
Konceptualni model predstavlja
suštinske karakteristike sistema za koji
se projektuje baza podataka.
Opisuje se na visokom nivou apstrakcije,
preko modela podataka.
Predstavlja celokupan mogući
informacioni sadržaj baze podataka,
nezavisno od toga koji je deo tog sadržaja
i kako implementiran.
Konstruisanje konceptulanog
modela
Koriste se intelektualni alati kao što su model
podataka ‘ PMOV, )DEF1X, Dijagram klasa,
Postupak modelovanja je uvek veština , zavisi od
sposobnosti, znanja i iskustva analitičara.
Ne mogu se dati neka stroga pravila modelovanja
koja bi, bez obzira na to ko modelovanje vrši, vodila
do jedinstvenog modela složenog realnog sistema.
Mogu se dati samo opšte metodološke preporuke,
opšti metodološki pristupi, kao pomoć u ovom
složenom poslu..
Pristupi konceptualnom
modelovanju
Postoji više metodoloških pristupa
konceptualnommodelovanju, a u razvoju modela nekog
konkretnog sistema oni se gotovo uvek kombinuju.
Integracija podmodela;
Direktno modelovanje na bazi verbalnog opisa sistema;
Konkretizacija opštih generičkih modela, odnosno
korišćenje uzora paterna ;
Normalizacija relacija; - (specifican za relacioni model)
Transformacija jednog modela u drugi direktno i
inverzno inženjerstvo .
PROJEKTOVANJE RELACIONIH BAZA
PODATAKA
1. PRIMENA NORMALNIH FORMI NA

ANALIZU RELACIJA
2. PRIMENA NORMALNIH FORMI NA
SINTEZU RELACIJA
3. TRANSFORMACIJA DRUGIH MODELA U
RELACIONI
NORMALNE FORME - PROJEKTOVANJE
RELACIJA NORMALIZACIJOM
Normalizacija je postupak projektovanja logičke

strukture baze podataka. Uobičajeno je da se
koristi za projektovanje logičke strukture
relacionog modela. Međutim, postupak
normalizacije ima opštiji značaj i treba ga
primenjivati i na druge modele baze podataka
(mrežni i hijerarhijski, relaciono-objektni), a i za
projektovanje strukture zapisa u obradi podataka
zasnovanoj na kolekciji izolovanih datoteka.
NENORMALIZOVANA RELACIJA
STUDENT
BI IME SEM [ SMER IMERUK [ PRED NAZPRED OCENA
21 GORAN 5 01 BATA 121 MATEMAT 7
323 BAZEPOD 8
056 MARKSIZ 8
77 ANA 7 01 BATA 056 MARKSIZ 10
121 MATEMAT 5
36 PERA 4 02 MIKA 323 BAZEPOD 8
456 ELEKTRON 9
442 FIZIKA 6
056 MARKSIZ 8
ANOMALIJE U AŽURIRANJU (DODAVANJU ZAPISA,

IZBACIVANJU ZAPISA, IZMENI VREDNOSTI ATRIBUTA)
ANOMALIJE (NESIMETRIČNOST) U IZVEŠTAVANJU

PRIMENA NORMALNIH FORMI NA
PROJEKTOVANJE BAZE PODATAKA ANALIZOM
RELACIJA
DAT JE SKUP NENORMALIZOVANIH RELACIJA. (NA PRIMER,

SVAKA “STAVKA” REČNIKA PODATAKA STRUKTURNE SISTEMSKE
ANALIZE MOŽE SE TRETIRATI KAO NENORMALIZOVANA
RELACIJA)
PRIMENOM DEFINICIJA NORMALNIH FORMI, RELACIJE SE
NORMALIZUJU. PRI TOME SE MOŽE ODMAH PRIMENITI DK/NF,
ALI JE MNOGO PRAKTIČNIJE POSTEPENO PRIMENJIVATI
DEFINICIJE 2NF, 3NF, BCNF 4NF, 5NF.
DOBIJENE RELACIJE SA ISTIM KLJUČEM MOGU DA SE
KONSOLIDUJU (SPOJE) AKO SE TIME NE NARUŠAVA SEMANTIKA
SISTEMA.
TRANSFORMACIJA MODELA OBJEKTI-VEZE U
RELACIONI MODEL
P1. Pravilo za objekte (nastavak)

Ključ relacije je:
 identifikator objekta, za objekte "jezgra" (objekte
koji nisu ni agregacije, ni slabi, ni podtipovi),
 za slab objekat, identifikator nadređenog objekta,
proširen sa jednim ili više atributa slabog, koji
jedinstveno identifikuju slabi objekat u okviru
nadredjenog,
 za agregaciju, složeni kljuc koga čine identifikatori
objekata koji čine agregaciju,
 za podtip, identifikator nadtipa.
TRANSFORMACIJA MODELA OBJEKTI-VEZE U
RELACIONI MODEL
P2. Dodatno pravilo za veze. Preko pravila (P1) u
relacioni model su prevedeni svi objekti i sve veze koje imaju
barem jedno preslikavanje s kardinalnošću (1,1) iz MOV.
Sve ostale veze postaju posebne relacije. Ime relacije je ime veze.
Atributi ovih relacija su identifikatori objekata koji čine vezu.
Ključ ovako dobijene relacije je:
 složeni ključ koga čine oba identifikatora, ako je gornja
granica kardinalnosti oba preslikavanja M,
 identifikator objekta sa gornjom granicom kardinalnosti
preslikavanja 1, ako jedno preslikavanje ima gornju granicu 1,
a drugo M
• identifikator bilo kog objekta, ako oba preslikavanja imaju gornju granicu
kardinalnosti preslikavanja jednaku 1.
PRIMER
UGRKOL
MLB*
NAD POD
STRUK
IMER R,C R,C
ZANIMANJE
SASTAV PRIMENA
[IFOD NAZOD (0,M) (0,M)
STAROST
C,C C,C
R,C R,C
ZAPO[LJAVA (1,M) R,C C,C
RADI (1,1) (1,M) (0,M)
RADNIK ZAPOS ODELENJE PROIZVODI PROIZVOD
C,C RUKOVODI RUKOVO\ENO

(1,M) VRSTA (1,1)
(0,1) (1,1) [PRO C,C
R,C VRSTA
R,C R,C NAZPRO
RUKOV S
ISPLATE
C,C C,C POREKLO

AMORT
DATUM IZNOS
MA[INA MATERIJAL
PRIMER
Na osnovu pravila P1 dobija se:
RADNIK(MLB, IMER, ZANIMANJE, STAROST, ŠIFOD)

PLATE(MLB,DATUM,IZNOS)
ODELENJE(ŠIFOD, NAZOD, MLB)
PROIZVOD(ŠPRO,NAZPRO,VRSTA)
MAŠINA(ŠPRO,AMORT)
MATERIJAL (ŠPRO, POREKLO)
Na osnovu pravila P2 dobija se za preostale veze
PROIZVODI(ŠIFOD,ŠIFPRO)
STRUKT(ŠIFPRONAD, ŠIFPROPOD, UGRKOL)
A B C
A B C
SINTEZA RELACIJA NA OSNOVU TEORIJE
FUNKCIONALNIH ZAVISNOSTI
[DOB,
[DOB 0 0 [KUP
[KUP
ELIMINISANJE
NEPOTPUNE
A B C FUNKCIONAL.
ZAVISNOSTI NA ZKUP
ELIMINISANJE TRANZITIVNE
ZAVISNOSTI
[DOB,
[DOB 0 0 [KUP
[KUP
A B C
NA ZKUP
Prethodni grafovi ukazuju na mogućnost definisanja postupka za
sintezu relacija na osnovu zadatog skupa atributa i njihovih
međusobnih funkcionalnih zavisnosti Da bi se ovaj problem formalno
definisao uvedimo i sledeće definicije:
Zatvaranje skupa funkcionalnih zavisnosti F je skup F+svih
funkcionalnih zavisnosti koje se mogu dedukovati iz F, preko negog
skupa pravila zaključivanja.
Posmatrajmo dva skupa funkcionalnih zavisnosti F i G. Kaže se da je
skup G prekrivanje skupa F ako je G+ = F+, tj ako su im zatvaranja
ista. U tom slučaju se, kaže da su skupovi G i F ekvivalentni.
Formalno se problem projektovanja baze podataka može definisati na
sledeći način:
Za skup funkcionalnih zavisnosti definisan modelom
sistema naći minimalno prekrivanje i implementirati
ga preko odgovarajućeg skupa relacija
•PRAVILA ZAKLJUČIVANJA ZA IZVOĐENJE
ZATVARANJA FUNKCIONALNIH ZAVISNOSTI?
•ALGORITMI ZA NALAŽENJE ZATVARANJA?
•ALGORITMI ZA NALAŽENJE MINIMALNOG

PREKRIVANJA?
PRAVILA ZAKLJUČIVANJA ZA IZVOĐENJE
ZATVARANJA
Pravila zaključivanja su osobine funkcionalnih zavisnosti na osnovu
kojih, iz jedne ili više funkcionalnih zavisnosti nekog skupa, možemo
logički dedukovati neke druge.
Armstrong-ove aksiome predstavljaju, jedan neprotivrečan i potpun

skup pravila zaključivanja. Neprotivrečan, u smislu da se iz njega
mogu dedukovati samo važeće funkcionalne zavisnosti, a potpun, u
smislu da se na osnovu njega mogu dedukovati sve funkcionalne
zavisnosti.
ARMSTRONG-ove AKSIOME
Oznaka U se nadalje koristi kao oznaka za skup atributa neke relacije.

A1. REFLEKSIVNOST. Ako je Y  X  U, tada važi X -> Y. Ovo pravilo
generiše trivijalne funkcionalne zavisnosti. Trivijalne funkcionalne zavisnosti
definisane su skupom atributa U neke relacije, a ne samim funkcionalnim
zavisnostima koje u relaciji važe.
A2. PROŠIRENJE. Ako važi X -> Y i ako je Z  U, tada važi i XZ -> YZ.
(Oznaka XZ je skraćena oznaka za X U Z).
A3. TRANZITIVNOST. Ako postoje funkcionalne zavisnosti X -> Y i Y -> Z,
tada postoji i X -> Z.
ARMSTRONG-ove AKSIOME
Iz Armstrongovih aksioma mogu se izvesti i sledeća korisna dodatna pravila

zaključivanja:
D1.ADITIVNOST (pravilo unije). Ako postoje funkcionalne zavisnosti X -> Y i
X -> Z, tada postoji i Y -> YZ
D2. PSEUDOTRANZITIVNOST. Ako postoje funkcionalne
zavisnosti X -> Y i YW -> Z, tada postoji i funkcionalna zavisnost
XW -> Z.
D3.DISTRIBUTIVNOST(pravilo dekompozicije). Ako postoji
funkcionalna zavisnost X -> YZ, tada važi i X -> Y i X -> Z.
USLOVI DA JE H MINIMALNI PREKRIVAČ F
1.Desne strane funkcionalnih zavisnosti u H su pojedinačni atributi.

2. Za svaku funkciju f: X ---> A iz F, ako je ispunjeno
F - X ---> A+ = F+, tada f  H. (Eliminiše redundantne funkcionalne
zavisnosti.)
3. Ni za jedno X ---> A iz H, za bilo koji pravi podskup Z od X (Z 
X), H - X ---> A U Z ---> A nije ekvivalentno sa H. (Ne postoji
nepotreban atribut na levoj strani)
4. F+ = H+, odnosno zatvarači skupa funkcionalnih zavisnosti i njegovog
minimalnog prekrivača su jednaki. (Garantuje da su sve fukcionalne
zavisnosti sačuvane u minimalnom prekrivaču.)
BERNSTEIN-ov ALGORITAM ZA NALAŽENJE
MINIMALNOG PREKRIVANJA
0. Na osnovu pravila dekompozicije, svesti skup funkcionalnih zavisnosti F na
skup funkcionalnih zavisnosti F1 čije su desne strane pojedinačni atributi.
1. Eliminisanje nepotrebnih atributa. Eliminiši nepotrebne atribute iz F1 i
formiraj skup funkcionalnih zavisnosti G koji je ekvivalentan sa F1 (G +=
F1+ ).
2. Nalaženje neredundantnog prekrivača. Nađi neredundantni prekrivač H
skupa funkcionalnih zavisnosti G.
3. Podela i grupisanje. Podeli skup funkcionalnih zavisnosti u H u grupe Hk
tako da u svakoj grupi leve strane budu identične.
4. Spajanje ekvivalentnih ključeva. Za svaki par grupa Hi i Hj , sa levim
stranama X i Y spoji Hi i Hj zajedno ako postoji bijekcija X <-----> Y
u H. Za svako A  Y izbaci X ---> A iz H. Za svako B  X izbaci
Y ----> B iz H. Formiraj skup J u koji se stavljaju zavisnosti X ---> Y
i Y -- -> X za svaku bijekciju grupa.
5. Eliminisanje novodobijenih tranzitivnih zavisnosti posle koraka 4.
Nađi prekrivač H'  H tako da je (H', J)+ = (H , J)+ i da nijedan
pravi podskup od H' nema tu osobinu.
6. Konstruisanje relacija. Za svaku grupu Hk konstruiši jednu relaciju sa
svim atributima koji se pojavljuju u grupi. Leva strana funkcionalnih
Nalaženje minimalnog prekrivača nije jednoznačan zadatak, odnosno da
jedan skup funkcionalnih zavisnosti ima više minimalnih prekrivača.
Osnovni problem u gornjem algoritmu je nalaženje minimalnog prekrivača

i njegovog zatvarača H+. Algoritam nalaženja minimalnog prekrivača
skupa funkcionalnih zavisnosti F može se realizovati tako što će se,
postepeno, eliminisati iz skupa F one funkcionalne zavisnosti fi za koje
važi (F - fi)+ = F+. To znači da se algoritam nalaženja minimalnog
prekrivača svodi na algoritam nalaženja zatvarača.
ALGORITAM ZA NALAŽENJE ZATVARAČA
Nalaženje zatvarača F+ skupa funkcionalnih zavisnosti F direktnom primenom

Armstrongovih aksioma je eksponencijalne složenosti. Zbog toga se primenjuje
postupak nalaženja tzv. “Zatvarača skupa atributa”: Neka je F skup
funkcionalnih zavisnosti nad skupom atributa U i neka je X  U. Tada je X+,
zatvarač podskupa X u odnosu na F, skup atributa A takav da se X ---> A može
dedukovati iz F pomoću Armstrongovih aksioma.
Može se dokazati sledeća lema: Neka funkcionalna zavisnost X ---> Y može se
dedukovati iz F pomoću Armstrongovih aksioma, ako i samo ako je Y  X+, a
X+ je zatvarač skupa X a odnosu na F.
ALGORITAM ZA NALAŽENJE ZATVARAČA
SKUPA ATRIBUTA
Ulaz: Skup atributa U, skup funkcionalnih zavisnosti F nad U i podskup X
 U.
Izlaz: X+, zatvarač X u odnosu na F.
Postupak: Sračunava se niz skupova atributa X(0) , X(1) , ..., preko pravila:
1. X(0) = X
2. X(i,1) = X(i) U V, gde je V takav skup atributa A da postoji neka funkcija Y --
-> Z, gde je A  Z, a Y  X(i). Kako se X(j,1) sračunava samo na osnovu
X(j) i kako je skup U konačan, postupak se završava kada postane X(i,1) =
X(i).
PRIMER BERNSTEIN-ovog ALGORITMA
Dat je skup atributa U = A, B, C, D, X1, X2

Dat je skup funkcionalnih zavisnosti:
G = X1X2 -> AD, CD -> X1X2, AX1 -> B, BX2-> C, C -> A
Korak 0:
f1: X1X2 ---> A f5: AX1 ---> B
f2: X1X2 ---> D f6: BX2 ---> C
f3: CD ---> X1 f7: C ---> A
f4: CD ---> X2
Korak 1: Nema nepotrebnih atributa.

Korak 2: Proverava se redom da li se svaka fi može dedukovati iz tranzitivnog
zatvarača preostalih, odnosno da li je
fi  F - fi+ .
Za funkciju f1, na primer, to je ekvivalentno proveri da li je A  X1X2 u
odnosu na F - f1:
X(0) = X1X2 X(1) = X1X2 (zbog f2)
Prema tome X1X2 ---> A ne može se dedukovati iz (F - f1)+ pa zbog toga
pripada neredundantnom prekrivaču. Isto se može zaključiti i za preostale
fi iz F.
Korak 3: Podela i grupisanje. Vrši se grupisanje funkcionalnih zavisnosti u

sledeće grupe:
H1=f1, f2, H2=f3, f4, H3=f5, H4=f6, H5=f7
Korak 4:Spajanje ekvivalentnih ključeva. Proverava se da li između levih strana
funkcionalnih zavisnosti nekih grupa postoji bijekcija. Bijekcija postoji ako je N 
M+, a M  N+.
Sračunajmo X1X2, u odnosu na skup H koji je u ovom slučaju jednak skupu
F:
X(0) = X1X2 X(1) = X1X2AD (zbog f1 i f2)
X(2) = X1X2ADB (zbog f5)
X(3) = X1X2ADBC (zbog f3, f4, f5, f6)
X1X2, = X1X2ADBC
Sračunajmo CD, u odnosu na skup H:

X(0) = CD
X(1) = CDX1X2A (zbog f3, f4 i f7)
X(2) = CDX1X2AB (zbog f5)
X(3) = CDX1X2AB (zbog f6)
CD, = X1X2ADBC
Prema tome postoji bijekcija X1X2 <---> CD. Zbog toga se
zavisnosti X1X2---> A, X1X2 ---> B, CD ---> X1, CD --->X2
spajaju u grupu (X1, X2, C, D, A). U skup J treba dodati gornju
bijekciju, odnosno četiri zavisnosti: X1X2 ---> C, X1X2 ---> D,
CD ---> X1 i CD ---> X2. Kako zadnje tri već postoje u F,
dodaje se samo f8: X1X2 ---> C.
Korak 5. Eliminisanje novodobijenih tranzitivnih

zavisnosti. Novi skup funkcionalnih zavisnosti H , J obuhvata
zavisnosti f1 do f8. Eliminisanje tranzitivnih zavisnosti se
radi ponovo preko Koraka 2, uključujući i f8. Prvo se ispituje
da li je sada f1 redundantna. Sračunava se X1X2, u odnosu na
H , J - f1.
X(0) = X1X2
X(1) = X1X2DC (na osnovu f2 i f8)
X(2) = X1X2DCA (na osnovu f7)
X1X2, = X1X2DCA
Kako je A  X1X2, funkcionalna zavisnost f1 je
redundantna. Ostale funkcionalne zavisnosti (koje bi
proveravali na isti način) nisu.
Korak 6. Konstruišu se sledeće relacije:
R1(X1, X2, C, D)
R2(A, X1, B)
R3(B, X2, C)
R4(C, A)
FIZIČKO PROJEKTOVANJE RELACIONIH BAZA
PODATAKA
F)Z)ČKO PROJEKTOVANJE BAZA PODATAKA SE
VRŠ) NAKON POTPUNOG LOG)ČKOG
PROJEKTOVANJA, NA OSNOVU JASNE LOG)ČKE
STRUKTURE BAZE PODATAKA.
F)Z)ČKO PROJEKTOVANJE BAZA PODATAKA
VEOMA JE ZAVISNO OD KONKRETNOG SUBP.
N)JE UOB)ČAJENO DA SE VRŠE NEK) DETALJN)
F)Z)ČK) PRORAČUN) , RAD)JE SE PR)MENJUJU
EKSPERTSKA ZNANJA ) KASN)JE PODEŠAVANJE
F)Z)ČKE STRUKTURE.
FIZIČKO PROJEKTOVANJE RELACIONIH BAZA
PODATAKA - KORACI:
1. PR)LAGOĐAVANJE LOG)ČKE STRUKTURE

KONKRETNOM SKUPU APLIKACIJA -
DENORMALIZACIJA
2. DISTRIBUCIJA BAZE PODATAKA - RAZL)Č)TE
KL)JENT- SERVER AR()TEKTURE
. KLASTEROVANJE - PODACI KOJI SE ZAJEDNO
KOR)STE TREBA DA BUDU F)Z)ČK) BL)SK)
. ODREĐ)VANJE METODA PR)STUPA
)NDEKS)RANJE ) EVENTUALNO (EŠ)NG
KONCEPTUALNO
MODELOVANJE 2
METODOLOGIJA MODELOVANJA
1. INTEGRISANJE PODMODELA
2. DIREKTNO MODELIRANJE
3. KOMBINOVANI METOD
INTEGRACIJA PODMODELA
Postupak integracija podmodela podrazumeva:
1. Izgradnja poslovnog modela sistema i specifikacija identifikovanih aplikacija

 korišćenjem Strukturne sistemske analize
 Ili opisa slučajeva korišćenja preko Sistemskog dijagrama sekvenci sa, na primer XML opisom
argumenata poruka
 ili Dijagramom aktivnosti sa strukturom objektnih tokova opisanih preko nekog modela
podataka.
2. Izgradnja podmodela podataka za svaku specifikovanu aplikaciju, odnosno
primitivni poslovni proces (funkciju).
3. Integracija podmodela u jedinstveni model celog sistema.
DTP PRVOG NIVO ZA JEDAN
JEDNOSTAVNI PRIMER
NARDOB
KUPCI
VIRMAN
KATALOG
OTPREMDOB NABAVKA
DOBAVLJA^ NARKUP
FAKTURA
1.
PRODAJA
PLA]ANJA
2.
PROIZVODI
RAÛN
OTPREMKUP KUPAC
OTPREMNICE I
PRIJEMNICE
NARUD@BKUP
DATDOB
OTPREMNICE
SKLADI[TENJENE
3.
DTP ZA FUNKCIJU “NABAVKA”
OTPRDOB
DATDOB
NARUÎVANJE
PRIHVATANJE
NARDOB
1.2
KATALOG 1.3
DOBAVLJA^
OBRADA
OSNOV.
PODATAKA
1.1
DATOB DATPRO
OTPREMNICE I
PRIJEMNICE
PLA]ANJE
1.4
DTP ZA FUNKCIJU “PRODAJA”
PLA]ANJA
NARKUP
RAÛN
KUPAC
OTPREMKUP
OBRADA
PORUD@BINA
2.1
KUPCI
PROIZVODI
PROIZVODI OTPREMA
2.2
NARUD@BKUP
OTPREMNICE
UPLATE
KUPCI
NAPLATA
2.3
STRUKTURA TOKOVA I SKLADIŠTA
IZGLED TOKA OTPRENICA DOBALJAČA( OTPRDOB)
[ if_dob ..... Naziv_dob ....... A dresa_dob ....

Br_otpr ..... D atum_otpr.......
Red_br [ if_proizv Naziv_proizv Otpr_kol V rednost

... .... ..... ..... .....
.... ..... ...... .,..... .....
DEFINICIJA U REČNIKU SSA
OTPDOB: < Sif_dob, Naziv_dob, Adresa_dob, Br_otpr,

Datum_otpr,{<Red_br , Sif_proizv, Naziv_proizv,
Otpr_kol, Vrednost>}>
PODMODEL ZA OTPREMNICU DOBAVLJAČA
Sif_dob N aziv _d o b A d r e sa _ d o b
D o b av lja~
1,M
B r o j_o tp r D atu m _o tp r
O t p r e m n i ca D o b a v
1,M
Sif_p r o izv N aziv _p r o izv
O tp r _k o l V r e d n o st
1,1 0,M
R ed _b r St a v k a O t p r e m n i ce Za P r o i zv o d
STRUKTURA TOKOVA I SKLADIŠTA
NARDOB: < [if_dob, Naziv_dob, Adresa_dob, Br_nar,

Datum_nar,{<Red_br , [if_proizv, Naziv_proizv,
Nar_kol, Opis>}>
Sif_dob N aziv _d o b A d r e sa _ d o b
D o b av lja~ PODMODEL ZA
0,M
NARUD@BENICU
B r o j_n ar U p u } en a D atu m _n ar
DOBAVLJAÂ
1,1
N a r u d ` b e n i ca D o b
1,M Sif_p r o izv N aziv _p r o izv

N ar _k o l O p is
1,1 0,M
INTEGRACIJA PRETHODNA DVA PODMODELA
Sif_dob N aziv _d o b A d r e sa _ d o b B r o j_o tp r D atu m _o tp r
0,M
D o b av lja~ O t p r e m n i ca D o b a v
0,M 1,M
D atu m _n ar O tp r _k o l
B r o j_n ar U p u } en a V r e d n o st
R ed _b r
1,1
St a v k a O t p r e m n i ce
N a r u d ` b e n i ca D o b
1,1
O p is 1,M Za
N ar _k o l
0,M
1,1 0,M
Sif_p r o izv
N aziv _p r o izv
(1,1) VIRMAN
UPLA]EN
(0,M) (1,M)
(0,M) (0,M) (1,M)

DOBAVLJA^ UZ
POFAK
(0,M) (0,M)
(0,M)
(0,M) (1,M) (0,M) (1,M)

OTPRDOB PRIJEM PRIJEMNICA PO FAKTURA
KATLOG
(1,M)
(1,M)
(1,M)
STAVKA_KAT
STAVKA_PRIJ
KONA^NI
STAVKA_OTPRDOB
(0,M)
(1,1) MODEL
(1,1)
POSLATA
SADR@I
OPISUJE
(0,M)
(1,1) (0,M)
(0,M) (1,1)
PROIZVOD POPRIJ
NARDOB
(0,M) (1,1)
OTPRPRO SATVKA_OTPRK
(0,M)
NARPRO
(1,M) (0,M)
(1,1) RAÛN
PORA^ OTPRKUP
STAVKA_NARD (0,M)
STAVKA_NK (0,M)
(1,M)
(1,M)
(1,M) NO
(1,M)
ZAOTPR
(0,M)
UPLATAK
NARKUP
OTPROOB
(0,M)
(0,M)
(0,M)
SADR@I
KUPAC
Međusobno nekonzistentni podmodeli
A D
VrstaA (1,1) 1,M

S
F
VrstaF (0,1)
S
B C
Podmodel (a)
A H
Podmodel (b)
Uzor za konstruisanje model
podataka u poslovnim sistemima
Strukture tokova i skladišta podataka su osnova za nalaženja modela.
Delovi navedenog primera mogu se uopštiti, odnosno poslužiti kao
uzor:
Neki tok ili skladište podataka se sastoji od jednog ili više poslovnih dokumenata.
Jedan poslovni dokument prikazuje neki skup povezanih objekata. Neophodno je
identifikovati te objekte, utvrditi koja polja dokumenta predstavljaju njihove
atribute i razlučiti veze objekata koje su na njemu prikazane.
Može se konstatovati da, najčešće, poslovni dokumenti imaju jednu od sledeća
dva tipa struktura: (1) “ravni dokumenat” u kome se sva polja pojavljuju samo
jednom (Faktura, UplataDob) i (2) “dokumenat sa stavkom” u kome postoje
stavke (tabele), odnosno skup polja koje se višestruko ponavljaju
(NarudžbenicaDob, Otremnica, Katalog). Pogodno je stavke tretirati kao posebne
“slabe” objekte u modelu. Isto tako je pogodno pretpostaviti da stavke imaju
redne brojeve.
Dokumenta koja se primaju iz “okoline” treba tretirati kao “slabe objekte”, sa
njihovim pošiljaocima kao nadređenim objektom (Otpremnica, Faktura, Katalog).
Očigledno je da BrojDokumenta ne može biti njihov jedinstveni identifikator, već
se identifikacija mora proširiti i sa identifikatorom pošiljaoca.
DIREKTNO MODELOVANJE
POD DIREKTNIM MODELOVANJEM PODRAZUMEVA SE RAZVOJ

MODELA PODATAKA NA OSNOVU:
POZNAVANJA REALNOG SISTEMA,

ISKUSTVA,
TEKSTUALNOG OPISA,
POZNAVANJA GENERIČKIH MODELA PODATAKA (PATERNA)
Dijagram slučajeva korišćenja za
“Video klub”
Registrovanje Registrovanje
novih novih
video traka ~lanova
Vra} anje Iznajmljivanje

traka Radnik traka
Struktuirani tekstualni opis slučajeva korišćenja
za “Video klub”
Registrovanje novih video traka
1. Za svaku novu traku formiraju se odgovarajući podaci (vrsta trake, naziv,
broj kopija, datum nabavke, naziv dobavljača, adresa dobavljača, dnevna
renta).
2. Pri ubacivanju podataka o traci u bazu, proverava se, preko imena i vrste,
da li takav zapis već postoji. Ako postoji, povećava se u postojećem
zapisu broj kopija. Ako ne postoji automatski se dodeljuje šifra trake datoj
traci i registruje odgovarajući zapis.
Registrovanje članova
1. Formiraju se podaci o članu (broj lične karte, ime, prezime, adresa,
telefon).
2. Podaci o članu se unose u bazu.
Iznajmljivanje traka
1. Član bira jednu ili više traka koje želi da iznajmi.
2. Formira se dokumenat Izdatnica u koga se unose podaci o članu, a kao
posebne stavke izdatnice unose se podaci o iznajmljenim trakama. Unosi
se i datum izdavanja i predviđen datum vraćanja traka.
3. Na osnovu podataka o dnevnoj renti traka, sračunava se i ukupan iznos
koji član treba da plati, ako trake vrati na vreme.
4. Član potpisuje izdatnicu, dobija njenu kopiju i odnosi trake.
Vraćanje traka
1. Član vraća trake.
2. U izdatnicu se unosi datum kada su trake vraćene i ukupna cena
iznajmljivanja.
3. Član plaća iznajmljivanje.
Konceptualni model “Video kluba”
Izdatnica
^ lan
Broj
BrLK Datum
Ime 0..* Izdata 1..1 PredvDatumVra}
Prezime Zadu` enje
Adresa DatumVra} anja
Telefon Obra~unIznajm
Uplata
1..*
Ima
1..1
Traka
Dobavlja~
Stavka izdatnice
Dobavio IdTrake Za
IdDobavlj
NazivTrake IznosPoTraci
NazivDobavlj 1..* 1..1 0..* 1..1
VrstaTrake
AdresaDobavlj
BrojKopija
DnevnaRenta
VERZIJE MOV-a: IDEF1x standard
Veze po PMOV sintaksi
Veze po IDEF1x i IE standardu
a) jedan:vise identifikujuca veza
b) jedan:vise neidentifikujuca veza
c) nespecificirana veza
Objekti po PMOV sintaksi
Objekti po IDEF1x standardu
Atributi i domeni
Viseznacni atributi
Viseznacni atributi
Viseznacni atributi
Viseznacni atributi
Primer 1: Avionska karta za jednu standardnu avio-liniju može biti sastavljena od više
kupona. Jedna linija može da uključi više letova na relaciji izmedju mesta polaska i mesta
krajnjeg odredišta. Svaki avion obično ima nekoliko letova u toku dana (let je
identifikovan preko datuma i vremena poletanja aviona). Karta sadrži podatke o avionskoj
liniji, prezimenu i imenu putnika, mestu polazišta, mestu krajnjeg odredišta, datumu
izdavanja, roku važenja i ceni. Kuponi karte sadrže identične podatke i podatke o
pojedinačnim letovima izmedu polazišta i krajnjeg odredišta: mesto poletanja, mesto
sletanja, osnovni podaci o avionu. broj leta, klasa sedišta, datum i vreme poletanja.
Generalizacija i specijalizacija
Agregacija
UML Modeli
- Aspekt projektovanja -
(statički opis strukture sistema)
ASPEKTI MODELA U UML-U
Za svaki aspekt daje se statički i dinamički opis sistema
ASPEKT ASPEKT
PROJEKTOVANJA IMPLEMENTACIJE
ASPEKT SLUÂJEVA KORI[]ENJA
ASPEKT ASPEKT
PROCESA RAZME[TANJA
Modeli i dijagrami
Model je potpun opis sistema
sa neke tačke gledišta
State
State
Diagrams
Dijagrami
Diagrams
Use Case kalsa
Use Case
Dijagrami
Diagrams State
Use Case Diagrams State
Diagrams
Use Case slučajeva Dijagrami
Diagrams
Diagrams
Dijagrami korišćenja objekata
Diagrams
sekvenci
Scenario State
Scenario
Diagrams State
Diagrams
Dijagrami
Diagrams Dijagrami
Diagrams
kolaboracije Modeli komponenti
Scenario Component
Scenario Component
Diagrams
Diagrams
Dijagrami Dijagrami
Diagrams
Diagrams Rasporeda
prelaza stanja Dijagrami
aktivnosti
Aspekt projektovanja pretstavlja realizaciju sistema u "objektnom
prostoru stanja".
Statički opis ovoga aspekta daje se preko Dijagram klasa i Dijagrama

objekata.
Dinamički opis se daje preko dijagrama interakcija, dijagrama

promene stanja i dijagrama aktivnosti.
DIJAGRAMI KLASA
Dijagram klasa najčešće korišćeni dijagam u OO pristupima
razvoju softvera
On pretstavlja skupove klasa, interfejsa, kolaboracija i njihove

međusobne veze
Koristi se da pretstavi:
1. Osnovni "rečnik sistema" – definiše pojmove koji se u tom

sistemu koriste,
2. Opiše strukturu neke kolaboracije,
3. Pretstavi logičku šemu baze podataka
Preduze}e
PRIMER
Odelenje Kancelarija
DIJAGRAMA
naziv:Imena
* Lokacija adresa: String
KLASA
0..1 telefon:Broj
*
* *
{podskup}
~lan 1..* 1 menager
Lice Centrala
ime:Imena
radnikId:Integer
zavanje:String
dajFoto(p:Foto) Podaci_o_Ug
dajGlas() adresa:String
dajUgovor()
dajDosije()
Li~ni dosije
pla}enPorez
radnaIstorija
plata
ITajniPodaci
kolaboracija
Razmena poruka
izme|u ~vorova
TransportniAgent
po{iljalac
primalac
IDistribucija
po{aljiPoruku()
* DIJAGRAM KLASA
KAO STATIČKI OPIS
KOLABORACIJE
*
sandu~e
Red Poruka
ID
dodajPoruku() zaglavlje
izbaciPoruku telo
ra~un()
UlazniRed IzlazniRed
PRIMER DIJAGRAMA KLASA KAO
LOGIČKE ŠEME BAZE PODATAKA
Student
{persistent} Radnik
{persistent}
0 .. * broj_ind mtbr
Slu{aju ime ime
registrovanje_za_kurs zaposli_se
ispi{i_se otpusti_se
0 .. * Upisan
Sekcija
Predmet Asistent Nastavnik
Sadrì {persistent}
{persistent} 0 .. * {persistent} {persistent}
idesek
ime je_sek Rang
opis
idpr
Zahtevan
drì_se 0 .. * 0 .. * 0 .. * 0 .. *
0 .. * Ve`be drì_ve`be
izostavljen
0 .. * predaje drì_predavanje
Zahtevase_prethodno
Definisanje Klase
Klasa je okvir (template) tj.specifikacija
za kolekciju objekata koji deli isti skup atributa i operacija.
Nastavnik
Klasa atributi
operacije
Objekti
• Veze - Relationships
Veza je ono sto klasa ili neki objekat zna o
durgoj klasi ili objektu.
 [Klase] Generalizacija (Generalization)

Nasladjivanje
• Primer: Osoba - Nastavnik, Student, Sluybenik...
• Primer: TransportnoSredstvo - Avion, Voz, Auto, Brod...
 [Objekat] Asocijacija (Associations)
• Nastavnik – Predmet
• Student - Predmet
 [Objekat] Aggregations & Composition (Whole-Part)
• Assembly – Parts, Group – Members, Container - Conte
UML Class Diagram Notation 1 of 2
Klasa
CLAN
mlb
{
prezime
ime
atributi telefon
adresa
grad
itd...
proveriIzdatCD
operacije
{ proveriVraceneCD
kupiCD
itd...
UML Class Diagram Notation 2 of 2
Class
Generalization
Relationship
Object Object
Aggregation Composition
Object Association Association Association
n n 1..* 1
0..* 0..*
Will always be “1”

Primer Generalizacije
<<abstract>>
ULOGA
atributi
operacije
Nastavnik Student Referent Posetilac

atributi atributi atributi atributi
operacije operacije operacije operacije
Note: <<abstract>> = no objects

Primer loše generalizacije
(narušava “is a” ili “is a kind of”)
Osoba
atributi
operacije
Arm Noga Glava

atributi atributi atributi
operacije operacije operacije

Generalizacija
- Višestruka klasifikacija
Discriminator
Doktor
Žensko
uloga
<<abstract>> Medicinska
Osoba Sestra
Pol
Muško {complete} pacijent
Fizio-
#1 terapeut
Pacijent
#3
#2
Kardinalnosti
1
Klasa tačno jedan
0..* više
Klasa (nula ili više)
0..1 opciono
Klasa
(nula ili jedan)
m..n tačno definisan
Klasa brojni opseg
Primer:
0..*
Preduzeće Radnik
1
Aggregation Composition
Nastavnik Porudžbenica
1..* 1
0..* 1..*
Predmet StavkaPorudžbenice
(drugi primer: ruka --> prst)

DEFINISANJE SEMANTIKE UML-a PREKO
DIJAGRAMA KLASA
METAMODEL ZA MEHANIZME PROŠIRENJA
*
Elemenat modela 0..1 * VrednostEtikete
etiketa:Naziv
1..* vrednost:String
*
Ograni~enje
*
*
or
Generalizuju}i
elemenat
Stereotip
* 1
icona:Geometrija
osnovnaKlasa:Naziv 0..1
*
Dijagram klasa (Stereotipi)
Važni stereotipi:
<<interface>> specificira kolekciju operacija za specifikaciju
servisa
<<type>> specificira strukturu i ponašanje (ne implementaciju)
<<enumeration>> specificira predefinisane vrednosti
<<implementationClass>> pomoćna klasa kreirani u detaljnom diza
<<interface>> <<type>> <<enumeration>>

ImageReader Complex Status
Fundamental Idle
Attributes Working
readImage Fundamental Error
writeImage behavior
Asocijacija kao klasa
Student Predmet
Položio
Datum
Ocena
Association
Class
DIJAGRAM OBJEKATA
(POJAVLJIVANJA)
Dijagram objekata pokazuje skup objekata i njihovih veza u jednom trenutku
vremena.
Dijagrami objekata modeliraju stanje sistema u jednom trenutku vremena,
odnosno daju zamrznutu sliku sistema u jednom trenutku vremena.
Dijagrami objekata daju statičku strukturu za opis dinamičkog ponašanja sistema
preko dijagrama interakcije. Oni su pojavljivanje odgovarajućeg dijagrama klasa i
statički deo dijagrama interakcije
Pretstavljaju skup objekata i pojavljivanja veza, mogu da sadrè i komentare i
ograničenja, da budu podeljeni u pakete i podsisteme.
NAČIN OZNAČAVANJA OBJEKATA (POJAVLJIVANJA)
Ana : Lice Naziv objekta i naziv odgovarajuće

Klase
: Lice "Anonimni" objekat date klase
Objekat čija se klasa podrazumeva

Aca (očigledna je)
"Siroče", pojavljivanje nedefinisane

agent: klase
Anonimno pojavljivanje sa definisanom

"putanjom" za naziv klase
:Odeljenje::OrgStruktura
"Multiobjekat", pretstavlja kolekciju

anonimnih objekata.
:Odelenja
Aca Prikazivanje vrednosti atributa

objekta
id = a234/27
starost = 36
Radnik:Ana
Eksplicitno prikazivanje
[na godi{njem odmoru ] stanja objekta
teku}aTr:Transakcija Primer jednostavnog Dijagrama

objekata sa stereotipnom vezom
koja pokazuje pripadnost klasi
primarniAgent <<pojavljivanje>>
Agent
[radi ]
:Transakcija
PRIMER DIJAGRAMA OBJEKATA
r:Robot
[uPokretu ]
<<globalni>>
o:Okolina <<nedodeljen>> :Elemenat
a1:Povr{ina a2:Povr{ina
z1:Zid z2:Zid v1:Vrata

{irina = 20 {irina = 90 {irina = 36
KLASE, ASOCIJACIJE
POJAVLJIVANJA, VEZE I PORUKE
Lice
1..* poslodavac
Preduze}e
+sra~Platu(d:Danrada)
+rasporedi(o:Odel) radnik *
Klase, asocijacija, uloge, kardinalnosti
rasporedi(erc)
l:Lice :Preduze}e
pojavljivanja , linkovi i poruke

UML Modeli
- Aspekt projektovanja -
(dinamički opis sistema)
Aspekt projektovanja predstavlja realizaciju
sistema u "objektnom prostoru stanja".

Dijagram klasa i Dijagrama objekata.

DIJAGRAMI SEKVENCI I
DIJAGRAMI KOLABORACIJE
Interakcije se mogu modelovati na dva načina:
 Prikazujući vremenski redosled poruka:

DIJAGRAMI SEKVENCI
 Prikazujući interakciju u kontekstu neke organizacije

(strukture) objekata:
DIJAGRAMI KOMUNIKACIJE
Moguće je automatski prevesti jedan oblik u drugi.

PRIMER DIJAGRAMA SEKVENCI
:interfejs :prodaja :stavka :artikal
novaOtp(br,kup)
novaStavka(prkod,kol)
provera(prkod,kol)
potvrda(kol)
:stavkaNar
novaStavkaNar(prkod,kol)
krajOtpr(br,kup)
Dijagram sekvenci (Sequence diagram)
Actor
Object
:Watch :LCDDisplay :Time

:WatchUser
pressButton1() blinkHours()
pressButton1() blinkMinutes()
Message pressButton2() incrementMinutes()

refresh()
pressButtons1And2()
commitNewTime()
stopBlinking()
Activation Lifeline
Ponašanje se predstavlja kao interakciju između objekata

Nested messages
ZoneButton TarifSchedule Display
Passenger
selectZone()
lookupPrice(selection)
price
displayPrice(price)
Dataflow
…to be continued...
The source of an arrow indicates the activation which sent

the message
An activation is as long as all nested activations
Horizontal dashed arrows indicate data flow
Vertical dashed lines indicate lifelines
Iteration & condition
…continued from previous slide...
ChangeProcessor CoinIdentifier Display CoinDrop

Passenger
*insertChange(coin) lookupCoin(coin)
price
Iteration displayPrice(owedAmount)
[owedAmount<0] returnChange(-owedAmount)
Condition
…to be continued...
Iteration is denoted by a * preceding the message name

Condition is denoted by boolean expression in [ ] before the message
name
Creation and destruction
…continued from previous slide...
ChangeProcessor
Passenger
Creation
createTicket(selection)
Ticket
print()
free()
Destruction
Creation is denoted by a message arrow pointing to the object.

Destruction is denoted by an X mark at the end of the destruction
activation.
In garbage collection environments, destruction can be used to denote
the end of the useful life of an object.
Sequence Diagram Summary
UML sequence diagram represent behavior
in terms of interactions.
Useful to find missing objects.
Time consuming to build but worth the
investment.
Complement the class diagrams (which
represent structure).
Communication diagram for: “Make a Purchase”
aGUI
1: prepare ( )
2: process order ( )
:Order
1.1: prepare ( )
1.1.1: get availability( )

:LineItem aProduct
1.1.2: get price ( )
Dijagram sekvenci za: “Izrada Narudzbenice”
Interfejs :Nardz :StavkaNar Proizvod

init( )
init ( )
loop [for each line item]
dajStanje ( )
(stanje)
dajCenu ( )
(cena)
(ukcena)
zapamti( )
(narudz br)
SISTEMSKI DIJAGRAM SEKVENCI
UnosUDelovodnik(Godina, Vrsta)
NoviPredmet(Klasifikacija, OrgJed, Naziv, VrstaAkta,

Podnosilac)
s : System
Pisar
SISTEMSKI DIJAGRAM SEKVENCI
PostojeciPredmet(RedniBroj)
ZavediAkt(VrstaAkta, Podnosilac,
Predmet)
Pisar s : System
Delovodnik
Vrsta
Godina
*
0..1 * * Pripada
Klasifikacija Predmet Organizaciona
Jedinica
Sifra RedniBroj
Naziv NazivPredmeta Sifra
Naziv
1..*
Akt
Podbroj
Predmet
DatumPrijema
VrstaAkta
Podnosilac
d=DajDelovodnik(Godina, Vrsta)
create()
TekuciDelovodnik(d)
NoviPredmet(Klasif, OrgJed, Naziv,VrstaAkta, Podnosilac,)
TekPred=NoviPredmet(Klasif, OrgJed, Naziv)

create()
NoviAkt(VrstaAkta, Podnosilac, Naziv)
Pisar p : Pisarnica
u : Unos tekPred :
d : Delovodnik Predmet
NaUnos
:IzborDelovodnika
1: UnosUDelovodnik(Godina, Vrsta)
1.2: create
1.1: d= DajDelovodnik(Vrsta, Godina) :Pisarnica u:Unos
1.3: TekuciDelovodnik(d)
1.4: create 1.5: Prikazi(u)
:FormaUnos
unesiStavku(prkod,kol)
1:[ nova prodaja ]kreiraj()
3:napraviStavkuPr(spec,kol)
:Kasa :Prodaja
2: spec : = specifik(prkod)
1.1:napravi() 3:napravi(spec,kol)
:Katalog
artikala sl: Stavka
prodaje
2.1: spec : = nadji(prkod)
3.2: dodaj(sl)
:Specifik. :Stavka
arikala prodaje
DIJAGRAMI PROMENE(PRELAZA)
STANJA
Pri opisivanju dinamike sistema preko dijagrama prelaza stanja
koriste se sledeći pojmovi:
(1) Sistem (objekat) je skup objekata, njihovih atributa i

njihovih veza. Struktura sistema - odnos njegovih objekata,
veza i atributa opisuje se preko modela opisanih u
prethodnom delu.
(2) Stanje sistema (objekta) u jednom trenutku vremena

predstavlja skup vrednosti atributa svih objekata i
“vrednosti” svih veza u tom trenutku. Termin
“vrednost veze” opisuje par (za binarne veze ili n-torku
uopšte) identifikatora pojavljivanja objekata koji su u vezi.
DIJAGRAMI PROMENE STANJA
(3) Događaji iniciraju promene stanja sistema. Odziv sistema
na neki događaj zavisi od stanja u kome se on nalazi.
Događaj moè da prouzrokuje promenu stanja sistema i/ili
da indukuje novi događaj. Događaj se zbiva u jednom
trenutku vremena, događaj nema trajanje (u vremenskoj
skali u kojoj se posmatra dati sistem). Ponekad se događaj
i poruka tretiraju kao sisnonimi. Međutim, precizno,
poruka je pojavljivanje događaja, što će kasnije biti
pokazano.
(4) Dijagram prelaza (promene) stanja je apstrakcija koja

pokazuje stanja, događaje i prelaze (tranzicije) iz
stanja u stanje kao mogući odziv na događaje.
(5) Dijagram promene stanja povezuje stanja (konkretna,
imenovana) sa događajima u sistemu. Promena stanja
izazvana događajem naziva se tranzicija (prelaz).
Dijagram promene stanja je usmereni graf u kome su
čvorovi stanja, a grane tranzicije, sa usmerenjem od
polaznog do prouzrokovanog stanja. Granama grafa daju
se nazivi događaja koji prouzrokuju tranziciju. (Jedan
događaj moè da prouzrokuje više tranzicija, pa više grana
moè da ima isto ime !!!).
(6) Početna i krajnja stanja. Moè se uvesti i koncept
početnog i krajnjeg stanja, za objekte (sisteme) koji imaju
“ograničen ìvot”. U tom slučaju, početno stanje je rezultat
kreiranja odgovarajućeg objekta, a krajnje podrazumeva
njegovo “uništenje” (nestanak). Početna i krajna stanja na
grafu imaju specijalne oznake, a mogu imati i imena.
START MAT CRNI

BELI NA POTEZU POBEDJUJE
SAGLASNOST
POTEZ POTEZ
REMI
CRNOG BELOG
SAGLASNOST
BELI
CRNI NA POTEZU POBEDJUJE
MAT
(7) Uslovi. Uslov je Bulova funkcija nad

vrednostima atributa i veza. Stanja sistema se
mogu opisati preko uslova. Iskaz da je objekat u
nekom stanju je uslov. Pored toga, uslovi se mogu
koristiti da ograniče tranzicije prouzrokovane
događajima. Ponekad, za prelaz sistema iz jednog
stanja u drugo potrebno je, pored događaja, da
bude ispunjen i neki uslov. Na dijagramu prelaza
stanja uslov se iskazuje uz naziv događaja, unutar
uglaste zagrade.
(8) Akcija pretstavlja jedno "atomsko sračunavanje"koje prouzrokuje promenu
stanja sistema ili vraća neku vrednost. Neka akcija okida događaj koji će sistem
prevesti iz jednog u drugo stanje.Akcija moè da pozove operaciju nekog
objekta, da kreira ili uništi neki objekat ili da pošalje signal nekom objektu.
Akcije se mogu pridružiti stanjima i tranzicijama. Ako se akcije pridružuju
stanjima one mogu biti:
"entry" – akcija koja se obavlja uvek pri ulazu u stanje, bez obzira koja je
tranzicija to prouzrokovala;
"exit" - akcija koja se obavlja uvek pri napuštanju stanja, bez obzira koja je
tranzicija to prouzrokovala;
"inerna tranzicija" – akcija koja ne menja stanje sistema.
Akcija se moè obaviti i pri prelazu iz jednog u drugo stanje Na tranziciji akcije se
iskazuju uz naziv događaja, iza uslova i oznake "/".
(9) Aktivnosti. Kada je objekat (ili deo sistema) u
nekom stanju, on je bilo neaktivan ili obavlja neku
aktivnost dok ga događaj ne prevede u neko
drugo stanje.Drugim rečima, dok obavlja
određenu aktivnost, sistem je u datom stanju. Na
dijagramu prelaza stanja aktivnosti se definišu
nazivom iza ključne reči DO, u okviru stanja
(čvora).
STANJE 1 DOGADJAJ 1 (argument)

do: AKTIV NOST 1 [uslov 1= "True" ] / akcija 1 STANJE 2
entr y/A kcija1 do: AKTIV NOST 2
exit/Akcija 2
doga|aj5/Akcija5
[uslov 2 = "Fals e" ] / akcija 2
STANJE 3
do: AKTIV NOST 3
(9) Sinhronizacija konkurentnih aktivnosti. U jednom

stanju se može obavljati više konkurentnih aktivnosti.. Ove
aktivnosti ne moraju biti sinhronizovane, mogu se obavljati
bilo kojim redom, ali sve one moraju biti obavljene pre nego
što se izvrši tranzicija u drugo stanje. Konkurentne aktivnosti
u jednom stanju se prikazuju podelom stanja (čvora) na
delove razmaknute isprekidanom linijom.
EMITOVANJE
UZET KE[
DO: DAJ KE[
SPREMAN SPREMAN ZA
POSTAVLJANJE RESET
DO: DAJ KARTICU UZETA
KARTICA
(10) Neoznačena ili automatska tranzicija. Koristi se da

bi se prikazala automatska tranzicija iz jednog stanja u
drugo koja se obavlja čim se aktivnost u nekom stanju
obavi. Kraj aktivnosti u nekom stanju moè se tretirati kao
neimenovani događaj. Taj neimenovani događaj "okida"
neimenovanu tranziciju u drugo stanje.
(11) Dekompozicija dijagrama prelaza stanja

Dijagrami prelaza stanja se mogu dekomponovati na
sledeće načine:
(i) Kompozitno stanje, odnosno sekvencijalna
podstanja.
(ii) Generalizacija stanja.
(iii) Agregacija stanja - agregaciona konkurentnost.
Kompozitno stanje. Svaka aktivnost u okviru stanja se

može predstaviti posebnim Dijagramom dekompozicije.
Dobijeni dijagram ima ulaz i izlaz, odnosno početno i
završno stanje. Ova stanja i odgovarajući događaji su
nevidljivi sa dijagrama višeg nivoa i predstavljaju samo
detaljan opis aktivnosti. Ugnježdeni dijagram stanja
“zamenjuje” jedno stanje na dijagramu višeg nivoa. Sve
ulazne tranzicije sa dijagrama višeg nivoa prenose se na
početno stanje, a sve izlazne transakcije na završno.
Izlazno stanje može da generiše poruku - događaj svome
nadređenom stanju.
UBACIVANJE (koli~ina/postavi saldo)
PRIMA NOVAC
SLOBODNA
UBACIVANJE (koli~)/dodaj na saldo
poni{ti/vrati lovu
[nema proizvoda ] select(proizv) [provra < 0]
do: TESTIRAJ SELEKCIJU I

PRORAÛNAJ PROVERU
[provra = 0] [provra > 0]
do: izdaj proizv do: izdaj kusur
(a)
ru~ica spremna
do: POMERI RUÎCU do: POMERI RUÎCU
NA VRSTU NA KOLONU
ru~ica spremna
do: PREUZMI
PROIZVOD SA POLICE
(b) Dekompozicija stanja "izdaj proizvod" kao ugnje`dena stanja

Generalizacija stanja. Pod generalizacijom stanja će se ovde

podrazumevati odnos između stanja i podstanja u kome
podstanje nasleđuje osobine stanja, promenljive stanja i
tranzicije stanja (precizno, izlazne tranzicije). Ako je neki
događaj primljen kada je objekat u datom podstanju, sve
tranzicije nadstanja su potencijalno primenljive, ako nisu
“prekrivene” istoimenom tranzicijom na podstanju. Nadstanje
se predstavlja kao kontura koja zaokružuje podstanja. Moguće
su tranzicije od nadstanja u podstanje i obrnuto, kao i tranzicije
iz podstanja u neko drugo stanje van konture.
MENJAČ
(automatski)
PRITISNI LER
LER PRITISNI RIKVERC RIKVERC
PRITISNI PRITISNI
NAPRED LER
NAPRED
STOP GORE GORE
PRVA DRUGA TREĆA

DOLE DOLE
Agregacija stanja - agregaciona konkurentnost.

Konkuretna stanja su posledica postojanja složenih objekata
koji su agregacija svojih komponenti ili postojanja višestrukih
paralelnih aktivnosti.
U slučaju složenih objekata, svaka komponenta može da ima

svoja stanja i svoj dijagram prelaza stanja. Stanje agregiranog
objekta je Dekartov proizvod stanja njegovih komponenti.
Slučaju višestrukih paralelnih aktivnosti je prikazan ranije

PALJENJE
PRENOS
(MENJAČ)
KOLA
KOČNICA
UBRZANJE
(GAS)
a) Agregacioni objekat kola

PALJENJE
OKRENI KLJUČ NAPRED
[PRENOS U LERU] OSLOBODI KLJUČ
ISKLJUČEN VERGLANJE UPALJEN
OKRENI KLJUČ NAZAD
PRENOS
MENJAČ
PRITISNI LER
LER PRITISNI RIKVERC RIKVERC
PRITISNI PRITISNI
NAPRED LER
NAPRED
STOP GORE GORE
PRVA DRUGA TREĆA

DOLE DOLE
UBRZANJE
GAS
PRITISNI
ISKLJUČEN OTPUSTI
UKLJUČEN
KOČNICA
PRITISNI
ISKLJUČEN OTPUSTI
UKLJUČEN
Početak
Kreiraj stak
DIJAGRAM PROMENE
STANJA ZA STAK Prazan
pop
Greška 1
push pop [prazan] do: prikaži
grešku 1
pop
[NOT prazan] U punjenju
pop
push [NOT pun]
push [pun]
Pun
push
Greška 2
do:prikaži grešku
2
DIJAGRAMI PROMENE STANJA OBRADU PREDMETA
H
Otvaranje
NoviPredmet(...) predmeta
Iniciran unos
DO: NoviPredmet(...)
KrajUnosa PostojeciPredmet(RedniBroj)
NoviPredmet(...)
PostojeciPredmet(RedniBroj)
Nalazenje predmeta Zavodjenje akta

Postoji tekuci
predmet
DO: DajPredmet DO: NoviAkt(...)
ZavediAkt(...)
KrajUnosa
H
odgovor mreže
Prekid
čekanje na
do: poruka o
odgovor mreže
poništenju
poništi
unešena tajna šifra
ubačena kartica
Glavni ekran [čitljiva] do:provera
do:zahtev za
do:prikaz
tajnom šiform autorizacije
glavnog ekrana
loša tajna šifra

ubačena kartica
[nečitljiva]
OK
Nečitljiva poništi NOT_OK
preuzeta do:poruka o
kartica nečitljivoj kartici
do:zahtev za
tipom trans
poništi
Izbačena kartica Poništenje
do:izbaci karticu; do:poruka o
poništi
zahtev za uzimanje poništenju
kartice
unešen
tip
Kraj do:zahtev za
do:poruka o
do:štampaj unosom sume
lošem računu
račun
kraj unešena
nastavi suma
uspešna
Preuzet novac transakcija do:obrad
do:zahtev za do:isplati sumu novca;
novčane
nastavkom zahtev zapreuzimanje
transakcije
neuspešna
transakcija
do:poruka o
greški
poništi
State Chart Diagrams
Event Initial state State
[button2Pressed]
Transition
[button1&2Pressed]
BlinkHours IncrementHrs
[button1Pressed]
[button1&2Pressed] [button2Pressed]
BlinkMinutes IncrementMin.
[button1Pressed]
[button1&2Pressed] [button2Pressed]
BlinkSeconds IncrementSec.
StopBlinking Final state
Represent behavior as states and transitions

AGILNE METODE ZA RAZVOJ

SOFTVERA
Sadržaj
Tradicionalni pristupi
Agilne metode - osnovni pojmovi
Agile Manifesto, definicija i principi
Karakteristike agilnog razvoja
Poređenje sa drugim pristupima
Aktuelne agilne metode

Tradicionalne metodologije
“Vodopad”
Izrada prototipa
Iterativno-inkrementalni
Spiralni
Objektno- orijentisani
Design-driven development
Domain-driven development
Test-driven development
Pojam agilnih metoda
Grupa metodologija koje se zasnivaju
na iterativnom i inkrementalnom
razvoju
Zahtevi i rešenja se razvijaju kroz
saradnju između timova
Adaptivno planiranje
Brz odgovor na promene
Agile Manifesto
Osnovna definicija agilnog razvoja
Nastao je 2001. godine kao odgovor na
potrebu za kreiranjem razvojnih metoda
koje je lako savladati
Lista principa koji se moraju zadovoljiti
da bi neka metoda bila agilna
Maksime agilnog razvoja
“Iako cenimo značaj činilaca
Veću vrednost ima: predstavljenih na desnoj strani,
stavke prikazane na levoj
Pojedinac i interakcija strani vrednujemo više.”
od procesa i alata
Primenljiv softver od detaljne
dokumentacije
Saradnja sa klijentima od ugovornih
aranžmana
Reakcija na promenu od pridržavanja
plana
Agile Manifesto principi
1. Zadovoljstvo korisnika brzom isporukom
korisnog softvera
2. Mogućnost promene zahteva, čak i u
poodmakloj fazi razvoja
3. Česta isporuka softvera, u razmaku od par
nedelja
4. Ispravan softver je osnovna mera napretka
5. Razvoj koji je u stanju da održi konstantan
tempo
6. Bliska kooperacija između projektanata i
poslovnih saradnika
7. Najbolji tip komunikacije je komunikacija
“licem-u-lice”
8. Projekti se izvode u okruženju u kojem su
motivisani pojedinci, u koje se može imati
poverenja
9.Kontinualno usmeravanje pažnje ka
tehničkoj veštini i dobrom dizajnu
10. Jednostavnost
11. Samoorganizovani timovi
12. Povećanje performansi tima na
osnovu prethodnog iskustva
Pojam iteracije
Jedan kratak period vremena, koji

obično traje između jedne i četiri
nedelje
Svaka iteracija uključuje tim kroz
celokupan ciklus razvoja softvera
Brzina agilnog razvoja
Osnovni pojmovi:
Jedinica posla - jedinica koju je tim
izabrao kao meru brzine izvođenja projekta
Interval - trajanje svake iteracije u
procesu razvoja softvera
Brzina - određuje se na osnovu prethodna
dva parametra
Brzina agilnog razvoja
Merenje tempa kojim tim radi kako bi se
procenilo vreme potrebno za dodavanje
nove funkcionalnosti
Merenje brzine kako bi se obezbedile
dodatne informacije o ostvarenom
učinku tima tokom vremena
Karakteristike
Akcenat je na funkcionalnom softveru, a
ne na dokumentaciji
Evolutivni razvoj i isporuka
Iterativni pristup
Brz i fleksibilan odgovor na promene
Timski rad i kolaboracija
Razbijanje zadatka na sitne korake
Nema dugoročnog planiranja
Karakteristike
Minimalan broj funkcionalnosti po
iteraciji
Tim nema ni jedan od postojećih oblika
hijerarhije
Tim sam bira način realizacije zadataka
u svakoj iteraciji
Zastupnik klijenta proverava
usklađenost projekta sa zahtevima
Poređenje sa iterativno-
inkrementalnim modelom
Agilne metode karakteriše:
Kraće iteracije
Iteracija se tretira isključivo kao definisano
vreme, a ne kao cilj koji treba ostvariti
Poređenje sa “vodopad”
modelom
Agilne metode karakteriše:
Dodavanje malog skupa funkcionalnosti na

kraju svake iteracije
Mogućnost promene zahteva u bilo kojoj
fazi projekta
Poređenje sa „kaubojskim
kodiranjem”
„Kaubojsko kodiranje“ nije agilno

„Kaubojsko kodiranje“ karakteriše
odsudstvo definisane metode
Agilni timovi slede definisani proces,
projekat mora biti usklađen sa
definisanim planom
Šta ih čini jedinstvenim?
Primenom agilnih metoda razvoj
softvera postaje:
Inkrementalan
Kooperativan
Direktan
Adaptivan
Proces uvođenja
Pre primene agilnih metoda odgovoriti
na sledeća pitanja:
� kako se odabrana metoda uklapa u
okruženje
� da li postoje timovi koji žele da probaju da
rade na agilan način
� da li postoje zainteresovani korisnici
Istorijat
Nastanak ranih agilnih metoda vezuje
se za period pre 2000. godine:
1986. – SCRUM u oblasti opšteg
menadžmenta
1995. – Adaptive software development,
Feature driven development i Dynamic
systems software development method
1996. – Crystal clear i ekstremno
programiranje
Agilne metode danas
Extreme programming (XP)
Scrum
Kanban
Adaptive software development (ASD)
Crystal clear i ostale crystal metode
Agilne metode danas
Dynamic systems development method
(DSDM)
Feature driven development (FDD)
Agile Unified Process (AUP)
Agile modeling
Scrum
Iterativni, inkrementalni razvojni okvir
Upravljanje projektima, pre svega za
razvoj softvera
Termin dolazi iz ragbija
Strategija „vraćanje lopte nazad u igru
uz pomoć timskog rada”
Scrum - karakteristike
Sprint - osnovna jedinica u procesu
razvoja
Sprint traje između jedne nedelje i
mesec dana i teži da ima konstantnu
dužinu
Definisanje skupa praksi i uloga
Scrum uloge
1. “Scrum Master” održava procese,
najčešće umesto projektnog menadžera
2. “Product Owner” predstavlja
zainetesovane strane ili poslovanje
3. “Team” grupa čije su funkcije
isprepletane, a zadatak je analiza,
dizajn, implementacija, testiranje itd.
Scrum proces
Faze procesa
1. Faza pre igre:
Planiranje - definisanje sistema koji će se
razvijati – tzv. Product Backlog
Dizajn/arhitektura – projektovanje sistema
na osnovu podataka iz prethodne faze
2. Faza razvoja (faza igre) - agilni deo
Scrum pristupa, neprekidna kontrola svih
bitnih parametara; “crna kutija” u kojoj se
može očekivati nepredviđeno ponašanje
Faze procesa
3. Faza posle igre – do ove faze se
dolazi kada se utvrdi da su svi zahtevi
ispunjeni; nema novih zahteva
Priprema uključuje testiranje,
integraciju i dokumentaciju
Scrum proces - faze
Kanban
Sekcije na Kanban tabli:
Backlog
Spremni taskovi
Kodiranje – taskovi na kojima se trenutno radi
Testiranje – taskovi koji se trenutno testiraju
Odobravanje – taskovi koji čekaju odobrenje
za puštanje u produkciju
Završeni taskovi – taskovi koji su pušteni u
rad
Kanban - Jira
Kanban - karakteristike
Ograničen broj taskova u svakoj od
sekcija (Work In Progress - WIP)
Što manje opterećenje tima
Kontinuiran rad kroz projekat
Nema jasno definisanih uloga ni rokova
Baždarenje – povećavanje ili
smanjivanje WIP parametra za svaku
sekciju
Kanban - primena
Manji projekti
Manji timovi – broj članova manji od 4
Nije moguće planirati iteraciju unapred
Timovi se bave rešavanjem bagova,
održavanjem sistema
Novi zadaci svakog dana
Ekstremno programiranje - XP
Definisanje tačaka kada je moguće
dodati nove zahteve
Programiranje u parovima
Ekspert – ekspert
Ekspert – početnik
Početnik - početnik
XP karakteristike
Funkcionalnosti se programiraju tek kada
se pojavi potreba
Ravna menadžment struktura
Jednostavnost i jasnoća koda
Česta komunikacija sa kupcem i među
samim programerima
Potencijalne mane
Nestabilni zahtevi korisnika

Nedostatak specifikacije i dokumenata
Kompromisi usled konflikta sa
korisnikom nisu dokumentovani
Životni ciklus
Istraživanje
Planiranje
Iteracije do nove distribucije
Proizvodnja
Održavanje i umiranje
Feature-driven development
Iterativni, inkrementalni proces za
razvoj softvera
Spaja najbolje prakse
Blagovremena isporuka
FDD proces se sastoji od 5 aktivnosti:
1. Razvoj modela
2. Kreiranje liste funkcionalnosti
3. Planiranje na osnovu funkcionalnosti
4. Projektovanje prema funkcionalnosti
5. Razvoj funkcionalnosti
Dynamic systems
development method
Bazira na metodi brzog razvoja
aplikacija
Definiše troškove, željeni kvalitet i
vreme
Koristi MoSCoW metodu za prioritete
MoSCoW metoda
Ova metoda definiše sledeće kategorije:
M – MUST – zahtevi koji moraju biti
zadovoljeni
S – SHOULD – stavke koje bi trebalo
uključiti u rešenje, ako je to moguće
C – COULD - poželjni zahtevi, ali ne i
neophodni i biće uključeni ukoliko to vreme
i resursi dozvole
W - WON'T – zahtevi o kojima se može
razmišljati u budućnosti
Adaptive Software Development
Posledica brzog razvoja aplikacija
Princip kontinualne adaptacije procesa
Repetitivne serije ciklusa špekulacije,
kolaboracije i učenja
Paradoks planiranja - sve
zainteresovane strane greše po pitanju
nekih aspekata, dok pokušavaju da
definišu misiju projekta
ASD životni ciklus
Osnovne karakteristike ASD životnog
ciklusa su:
Fokusira se na misiju
Zasniva se na karakteristikama
Iterativan
Vođen je rizikom
Tolerantan na promene
Crystal Clear
Član Crystal porodice metodologija
Namenjen timovima koji se sastoje od 6
ili 8 projektanata
Primena na sisteme koji nisu krucijalni
Akcenat na efikasnosti i bezbednosti
komponenti projekta
Fokusira se na ljude, a ne na procese
Agile Unified Process
Pojednostavljena verzija RUP-a
AUP ima sedam disciplina:
1. Model
2. Implementacija
3. Test
4. Razvoj
5. Konfiguracioni menadžment
6. Projektni menadžment
7. Okruženje
Agile Modeling
Dodatak ostalim agilnim metodama kao
što su XP, AUP, Scrum
Ne isključuje korišćenje standardnih
alata za modelovanje
Okvir za korišćenje različitih alata u
zavisnosti od preferencija članova tima
MODELOM VOĐEN) RAZVOJ

(ARHITEKTURA)
MODEL DRIVEN ARCHITECTURE

Modelo vođe i razvoj
Računarski Computation Independent Model –CIM – model
nezavisan model odgovarajućeg domena, zajednički rečnik za
CIM
korisnika i projektanta
Platform Independent Model – PIM.

Model IS nezavisan od
Platformski Model za opis
nezavisan model Platforme implementacione platforme.
PIM PDM
Specifikacija sistema
Platform Description Model –PDM

Model implementacione platforme
Transformacija
Platform Specific Model- PSM

Platformski zavisan Model IS implementiran u datom
model
PSM okruženju.
• Modelom vođeni razvoj omogućava:
– Specifikaciju sistema nezavisnu od bilo
kakve implementacije;
– Specifikaciju platforme;
– Izbor platforme za implementaciju
specifikaovanog sistema;
– Transformaciju specifikacije sistema u
izabranu platformu.
Modelom vođeni razvoj, kao i svi drugi
pristupi u transformacionom ražvoju
softvera, nije ništa revolucionarno novo.
To je samo jedan viši nivo kompilacije
jednog u drugi jezik.
FOTRAN
FORTRAN Compiler
Izvršni kod
Program
MDA
Transformacija EJB
UML MODEL KLASA
Java kod
MDA i interoperabilnost
Sa tačke gledišta korisnika heterogeni
distribuirani računarski sistem treba da se
posmatra kao jedinstveni svet , bez ikakvih
platformski specifičnih barijera .
Broj različitih platformi stalno raste i ne može se
očekivati standardizacija ptpuna unificiranost
na tom nivou.
Preostaje da se standardizacija ostvari na nivo
specifikacije, odnosno modela i da se preko tih
opštih modela ostvari interoperabilnost delova
sistema realizovanih na različitim platformama.
MDA- osnovni pojmovi
Model driven zato što se u svim fazama razvoja
(spefifikacija,projrktovanje, implementacija,
održavanje koriste modeli.
Arhitektura . Arhitektura nekog sistema,
uopšte, je specifikacija njegovih delova i pravila
koja definišu način komunikacije između delova.
U MDA pristupu definišu se modeli koji se koriste
u razvoju softvera i pravila njihovog povezivanja.
Platforma je sistem sa definisanim skupom
funkcija (bez detaljne specifikacije njihove
implementacije preko koji je moguće
implementirati neki softver.
MDA- osnovni pojmovi
Vrste platformi:
Generičke:Objektna, Batch, Tok podataka
Specifične tehnologije: CORBA, J2EE
Tehnologije pojedinih proizvođača: CORBA:
Borland VisiBroker;J2EEs: IBM WebSphere,
Oracle;Microsoft .NET.
Simbol za platformu
MODELI- četvoro ovoska
hijerarhija meta-modela
u skladu sa
Meta-meta model je model meta-
M3 meta-metamodela. On definiše pravila za
model izgradnju pravila za formiranje
konstrukcija u nekom modelu (MOF).
u skladu sa
Meta-model je model modela.
On definiše pravila
M2
meta-mode za formiranje konstrukcija u modelu
(Pravila za formiranje nekog UML
modela - UML meta-model)
u skladu sa
M1 Model IS
model sistema (UML model)
opisuje
sistem Informacioni
M0
sistem koji se
(IS) modeluje
MODELI- četvoro ovoska
hijerarhija meta-modela
u skladu sa u skladu sa
meta-meta-
EBNF
model
gramatica
meta-mode
Pascala
Analogija
model sistema Pascal program
opisuje opisuje
sistem jedno izvršenje
Jean Bézivin
(IS) Pascal programa
MODELI I METAMODELI
MOF
meta
izvor
meta
Klasa ponor Asocijacija
UML meta-model
meta
meta
1 *
Klasa Atribut
UML model
meta meta
Student
Ime:String
MODELI-
četvoronovoska
hijerarhija
meta-modela
Kada se kaže da je meta-model “pojavljivanje” meta-meta

modela podrazumeva se da je svaki koncepta meta-
modela jedno pojavljivanje met-meta modela.
MDA OMG standardi
Osnovni MDA
OMG astandardi
su:
• UML
• MOF
• CWM
• XMI
MDA OMG standardi
UML – OMG standardni jezik za modelovanje
diskretnih sistema:
UML 2.0 standard dat je u dva osnovna dokumenta: (1)
UML 2.0: Infrastructure - osnovni koncept jezika i (2)
UML 2.0: Superstructure- nadgradnja sa konstrukcijama
korisničkog nivoa.
MOF (Meta object facility) – standardni jezik za
specifikaciju meta modela. Mof sdarži dva osnovna
dela:
Abstrakni model generičkih objekata i njihovoh
asocijacija vrlo sličan sa UML jezgom
Skip pravila za preslikavanje MOF modela u jezički
nezavisne interfejse. Implementacija ovih interfejsa
omogućava pristup i ažuriranje bilo kog modela
zasnovanog na MOF-u.
MDA OMG standardi
XM) XML Metadata )nterchange . Definiše XML
tagove preko kojih se može opisati serijalizovan
model baziran na MOF-u. Služi prvenstveno za
razmenu modela. Transformacija iz jednog u drugi
često se vrši i na sledeći način:
Model1  XMI1 XSLT XMI2  Model2
CWM The Common Warehouse Metamodel definiše
metamodele koji predstavljaju stovarišta podataka
data warehousing i odgovarajuće OLAP analize.
JMI (Java Metadata Interface) – omogućava
preslikavanje MOF modela u Javu da bi se aostavrila
mogućnost održavavanja MOF metabaza iz Jave.
MDA hijerarhija modela
MOF
M3
EJB
M2 UML XMI CWM SSA
Metamod
.....
UML model UML model UML model SSA model

M1 Kadrovi Finansije Proizvodnja Nabavka
.......
M0 a:Radnik 01:ORGJED .......

UML Infrastructure specifikacija
• UML specifikacija se daje preko UML metamodela.

• Jedan od osnovnih principa UML-a je proširljivost. Zbog toga
UML 2.0 Infrastructure librarary sadrži dva osnovna dela:
 Jezgro (Core)
 Profiles - proširenja. Profil – mehanizam prilagođavanja
modela konkretnim platformama (J2EE/EJB, .NET/COM+ i
drugim)
UML- Od os Jezgra i ostalih odela
Jezgro se koristi za
definisanje
drugih metamodela i
kreiranje drugih jezika
preko koncepta profila.
Jezgro je praktično
zajednički deo za sve
ove modele.
Paketi u UML
jezgru
PrimitiveTypes sadrže nekoliko predefinisanih tipova potrebnih za

metamodelovanje, posebno za UML i MOF.
Abstractions sadrži nekoliko abstraktnih metaklasa koje se višestruko
koriste(specijalizuju) i različitim metamodelima.
Basic sadrži podskup koncepata iz paketa Constructs koji se
prvenstveno koriste za objektne jezike i XMI.
Constracts sadrži metaklase koje su konkretneklase okrenute prema
konceptima objektno-orjentisanog modelovanja (koriste se za UML i MOF i
njihovo usaglašavanje)
Abstractions
UML specifikacija
Svaki koncept iz odgovarajućeg paketa se
opisuje sa:
Dijagramom klasa
Opštim opisom
Opisom svih atributa
Opisom svih asocijacija
Specifikacijom semantike
Generalization je podtip
DirectRelationship To znači da nasleđuje
sve
odgovarajuće osobine
pa
i asocijacije.
Preslikavanje
generalization je
podskup preslikavanja
target, a specific
podskup
preslikavanja source
To znači da ako se za
neko pojavljivanje
klase
generalization
zatheva
target dobiće se
instanca asocijacije
general.
Primeri koncepata UML met-modela
mer generalizacione hijerarhije
ojmova u UML meta-modelu
Core::Basics::P
Core::Constructs::StructuralFeature
Core::Constructs::Property
Basic – specifikacija klase
Constructions – specifikacija
Dijagrama klasa
Višestruke asocijacije
Binarna i ternarna asocijacija

Essential MOF (EMOF)
Koristi osnovne elemente iz paketa Basic i Abstractions iz UML2
ne dodaje svoje sopstvene klase. Na primer sam pojam klase se
specifikuje na isti način. EMOF može da posluži za specifikaciju
metamodela objektnih jezika i XMI
The Complete MOF (CMOF) se koristi specifikaciju drugih modela

na primer UML-a
The Complete MOF (CMOF)
Specifikacija Dijagrama klasa
MOF
Za konstrukciju meta-modela koristi se
MOF
Pošto je meta-model model modela, na
njega se može primeniti isti jezik koji se
koristi za izgradnju modela nekih sistema,
pod uslovom da je takav jezik reflesivan što
praktično znači dovoljno opšt
UML dijagram klasa ima tu osobinu i zato je
on osnova MOF-a.
Preslikavanje PIM PSM
Računarski
Osnovni pojmovi
nezavisan model
CIM
• MDA preslikavanje definiše
transformacije iz PIM u
specifičan PSM u skladu sa
odgovarajućim modelom
Platformski Model za opis
nezavisan model
PIM
Platforme
PDM
platforme.
• Preslikavanje tipova -
definišu se pravila preskivanja
Transformacija u koja mogu da budu uključene
i vrednosti iz pojavljivanja.
Preslikavanje na nivou
Platformski zavisan
model metamodela je preskikavanje
PSM
tipova.
• Preslikavanje pojavljivanja
modela. Uvođenje oznaka
Preslikavanje PIM PSM
(Osnovni pojmovi)
Oznake (Marks) mogu da budu:
Tipovi modela (klase, asocijacije, uloge u
asocijacijama ili drugi tipovi)
Stereotipovi iz UML profila
Elementi metamodela (MOF-a, na primer)
Neki nefunkcionalni zahtevi (specifikacija
kvaliteta ili zahtevanih performamsi).
Primer: Entity oznaka se može primeniti na klasu ili
objekat u PIM-u čime se naznačava da će se na te
klase ili objekte primenti temlejt sa nazivom Entity.
Preslikavanje PIM PSM (Osnovni
pojmovi)
Tempejt je model koji definiše transformaciju neka
vrsta design pattern .
Primer: CORBA Entity template specifikuje da se objekta
iz PIM-a označen sa Entity preslikava u CORBA PSM
model u objekat tipa HomeInterface i objekat tipa
EntityComponent i njihovu međusobnu vezu.
Jezik za preslikavanje: prirodni jezik, neki
algoritamski jezik ili jezik za preslikavanje modela
(XSLT za XMI1XMI2). The current. MOF
Query/View/Transformation RFP (Request for
Proposal) zahteva da se u okviru MOF-a definiše
standardni jezik za preslikavanje modela.
PIM PSM preslikavanje tipova
Preslikavanje PIM PSM preko meta-
modela
Preslikavanje PIM PSM preko
oznaka
Preslikavanje PIM PSM preko tipova i
pefinisanih paterna meta-modela
Preslikavanje PIM PSM preko
UML profila
)zgrađuje se profil
PLatforma platforme u koji se PIM
preslikava – koncepti UML
PIM meta-modela ili MOF-a se
proširuju da bi se
Pofil obuhvatile specifičnosti
Platforme
(Oznake)
platforme
Koncepti PIM modela
označavaju se sa
Označeni PIM oznakama koje odgovaraju
konceptima profila
platforme
Vrši se preslikavanje
preko pravila koja se
PSM
definišu na ovako
označenim P)M-u
Izgradnja PIM-a
PIM se izgradjuje nekim postupkom
specifikacije IS.
Specifikacija )S preko Sitemsko-teorijskog
životnog ciklusa:
Identifikacija – nalaženje funkcionalnog modela
Definisanje slučajeva korišćenja
Definisanje sistemskih dijagrama sekvenci
Realizacija
Specifikacija strukturnog (konceptualnog) modela
Specifikacija dinamike sistema (Dijagmi sekvenci,
kolaboracije, aktivnosti)
Specifikacija konačnog objedinjenog strukturnog i
dinamičkog modela
“lučajevi korišće ja - Dijagram
SAMOPOSLUGA Kupac
Kasir
Pro daja
Lo go vanje
Menager
V ra}anje artikala
Po kretanje kasa
“lučajevi korišće ja - Dijagram
Kasir
<<extend>> Upravljanje
Prodaja
zalihama
<<include>
<<include>> >
Registrovanje
artikala Placanje
Placanje u Placanje
gotovom katicom
Sistemski dijagram sekvenci
: Kasa
: Kasir UnnesiStavku(Integer, Double)
KrajProdaje( )
Placanje(Double)
Konceptualni model
Dinamika sistema – Dijagram sekvenci
: Kasa : : TransProdaje
KatalogArtikala
: Kasir UnnesiStavku(Integer, Double)
DajArtikal(Integer)
NapraviStavku(SpecifikacijaArtikala, Integer)
KrajProdaje( )
Ukupno( )
Placanje(Double)
NapraviPlacanje( )
Ko ač i PIM
EJB PSM
Deo generisanog koda
Java Code Generation Process --
// Import Statements
import java.rmi.RemoteException;
import javax.ejb.*;
public class KasaEJB implements javax.ejb.SessionBean {

public Prodavnica theProdavnica;
public TransProdajeEJB theTransProdajeEJB;
/*
Method: Default Constructor
*/
public KasaEJB() {}
/*
Method: UnnesiStavku
*/
public Double UnnesiStavku(Integer PrKod, Double Kol) {}
/*
Method: KrajProdaje
*/
public Prodaja KrajProdaje() {}
/*
Method: Placanje
*/
public Double Placanje(Double Iznos) {}
UML Profili
UML profil
Profil je mehanizam prilagođavanja metamodela

konkretnim platformama (J2EE/EJB, .NET/COM+, i
drugim)
Nikakva postojeće ograničenja u UML meta-modelu se ne
ukidaju, profilom se samo dodaju nova.
UML profil
Razlozi za definisanje profila su:
Uvođenje terminologije specifične za neku platformu
Uvođenje specifičnih oznaka
Proširenje semantike nekog koncepta meta-modela
Ograničavanje upotrebe koncepata metamodela
Dodavanje informacija za transformisanje PIMPSM
Na pitanje kada koristiti profil, a kada formirati novi

Metamodel (jezik), nema unapred definisanog
odgovora.
UML profil
Mehnaizmi za proširenje uML metamodela su
tagged values ograničenja i stereotipovi.
Osnovni mehanizam je stereotip. Stereotip
definiše kako se proširuje neka metaklasa ili
prethodno definisani stereotip . Ne može da se
koristi sam nego zajedno sa metaklasom koju
proširuje. Jedna metaklasa može da ima više
različituh stereotipova. Streotip se označavi bilo
sa
<< naziv stereotipa>> ili
Novim grafičkim simbolom
Extension specijalna vrsta
asocijacije koja definiše proširenje
UML profil
) sam UML sadrži neke predefinisane profile.
Time su uvedeni novi koncepti koji proširuju
semantiku nekih osnovnih UML koncepata sa ili
bez uvođenja novih oznaka.
<<include>> i <<extend>> u Dijagramima slučajeva
korišćenja kao proširenje veže zavisnosti.
<<interface>> stereotip klase
<<executable>> stereotip komponente
<<framework>> stereotip paketa
<<profile>> stereotip paketa
....
Primer definisanja profila
Profil TežinaBoja
I za klasu i za asocijaciju u UML-u se može definisati boja,

a za asocijaciju samo “težina”
Profil TežinaBoja
Za uvedene koncepte u profilu se mogu
definisati ograničenja OCL ili prirodni
jezik)
Sa obojenom asocijacijom se mogu povezati
klase koje imeju tu istu boju.
context UML::InfrastructureLibrary::Core::Constructs::Association
inv: self.isStereotyped(“Obojena”) implies
self.connection -> forAll (isStereotyped(“Obojena”)
implies boja=self.boja)
Profil TežinaBoja
Tagged value su meta-atributi prudruženi metaklasi (boja, težina).
U modelu se predstavljaju kao atributi klasa preko para
(naziv taga, vrednost)
Slozeni primer definisanja profila
Enterprise Java-Beans (EJB)
tehnologija
EJB su komponente J2EE komponente koje se izvršavaju u okviru

EJB kontejnera koji obezbeđuje upravljanje transakcijam i sigurnost.
Enterprise beans su komponente u kojima je učaurena poslovna
Logika sistema (aplikacije).
Enterprise Java-Beans (EJB) tehnologija
Session bean Jedan Session bean predstavlja jednog klijenta

na serveru. Da bi pristupio aplikaciji na serveru
kljijent koristi Seesion Bean. On sakriva
kompleksnost aplikacije od kljijenta. Nije
perzistentan (Statless, Stateful)
Entity bean Predstavlja poslovni entitet koji postoji u bazi.
Povezan je sa jednom tabelom ili pogledom u
relacionoj bazi. Jedno njegovo pojavljivanje
odgovara redu u tabeli. Jedan entity bean može
da koristi više klijenata. Svaki entity bean ima
jedinstveni identifikator (primary key)
Message-driven Predstavlja “listener for the Java Message
been Service API”, za procesiranje asinhronih poruka.
Klijent može da ptristupi
Session ili Entity beans
samo preko predefinisanih
interfejsa
• Remote interface definiše za dati bean specifične poslovne

metode.
• Home interface definiše “životni ciklus” i metode za nalaženje
bean-a.
EJB profil
<<Stereotype>>
Home
<<Stereotype>>
Komponenta
Bean
<<metaclass>>
Interface
<<Stereotype>>
Remote
<<Streotype>> <<Streotype>>
EntityBean SesionBean
Stanje:VrstaStanja
<<Enumeration>>
VrstaStanja
Stateless
Stateful
EJB PSM
Deo generisanog koda
Java Code Generation Process --
// Import Statements
import java.rmi.RemoteException;
import javax.ejb.*;
public class KasaEJB implements javax.ejb.SessionBean {

public Prodavnica theProdavnica;
public TransProdajeEJB theTransProdajeEJB;
/*
Method: Default Constructor
*/
public KasaEJB() {}
/*
Method: UnnesiStavku
*/
public Double UnnesiStavku(Integer PrKod, Double Kol) {}
/*
Method: KrajProdaje
*/
public Prodaja KrajProdaje() {}
/*
Method: Placanje
*/
public Double Placanje(Double Iznos) {}
OCL (Object constraint language)

Sadržaj
Uvod
Osnove OCL – a
OCL navigacija
OCL tipovi podataka i operacije nad njima
OCL alati
Uvod
 Object Constraint Language (OCL) je formalni
jezik za definisanje izraza u UML modelima.
 Izrazinajčešće predstavljaju ograničenja koja moraju biti
zadovoljena u okviru sistema koji se modeluje ili upite nad
objektima u modelu.
 Deklarativan jezik
 Specificira se ono što mora biti zadovoljeno, ne ono što
treba da se uradi
 Nema spoljašnjih efekata (side - effect)
 Evaluacija OCL izraza nikada ne dovodi do promene stanja
sistema
 Nije programski jezik
 Nije moguće definisati programsku logiku niti kontrolu toka
upotrebom OCL - a
Uvod
Prva verzija razvijena 1995. godine, od
strane IBM – a
Trenutna verzija je OCL 2.3.1. (Januar 2012)
OCL je deo UML standarda
Može se koristiti za definisanje
ograničenja ili upita nad svim vrstama
UML dijagrama
najčešće je to UML Class diagram
Osnove OCL – a: Primer
Osnove OCL – a: Context
Kontekst (Context) definiše kontekst
upotrebe OCL izraza u okviru UML modela.
npr. za UML Class Diagram, kontekst OCL izraza
se koristi za identifikovanje elementa (klasa,
interfejs...) na koji se odnosi OCL izraz
Sintaksa:
context <classifier>
Primer: OCL izraz se odnosi na klasu
Komitent
context Komitent
Osnove OCL – a: Invariant
Konstanta (Invariant) koristi se za
definisanje OCL ograničenja koje treba da
bude zadovoljeno tokom celokupnog
životnog ciklusa objekta.
Drugačije rečeno, Invariant ograničenje
uvek mora biti zadovoljeno.
Označava se klauzulom inv.
Sintaksa:
context <classifier>
inv[<naziv ograničenja>]: <Boolean OCL izraz>
Osnove OCL – a: Invariant
 Primer: datum isteka važenja kartice mora
uslediti nakon datuma početka važenja
kartice (atributi DatumOd i DatumDo klase
PlatnaKartica)
context PlatnaKartica
inv : DatumDo > DatumOd
inv : self.DatumDo > self.DatumOd
inv datumOgraničenje: self.DatumDo > self.DatumOd
Osnove OCL – a: Precondition
Ograničenje koje se odnosi na operaciju
klase u UML class diagramu.
Ograničenje koje mora biti zadovoljeno u
trenutku izvršavanja operacije.
Označava se klauzulom pre.
Sintaksa:
context <classifier> :: <operacija>(<parametri>)
pre[<naziv ograničenja>]: <Boolean OCL izraz>
Osnove OCL – a: Precondition
Primer: može se proveriti raspoloživost
sredstava za uneti iznos, ako je prethodno
uneti PIN odgovarajući
context Transakcija :: proveraSume(i : Double)
pre : self.uspesnoLogovanje=true
Primer: uneti iznos mora biti veći od 0

context Transakcija :: proveraSume(i : Double)
pre : i>0
Osnove OCL – a: Postcondition
Ograničenje koje se odnosi na operaciju
klase u UML class diagramu.
Ograničenje koje mora biti zadovoljeno po
završetku izvršavanja operacije.
Označava se klauzulom post.
Sintaksa:
context <classifier> :: <operacija>(<parametri>)
post[<naziv ograničenja>]: <Boolean OCL izraz>
Primer: trajanje transakcije mora biti
jednako razlici početka i kraja transakcije
context
Transakcija::trajanjeTransakcije():Timestamp
post: result = self.krajTransakcije –
self.pocetakTransakcije
result klauzula
odnosi se na rezultat (povratnu vrednost)
operacije nad kojom je definisano Postcondition
ograničenje.
Primer: stanje na računu posle podizanja
novca biće jednako početnom stanju
umanjenom za podignutu sumu
context Racun:: umanjiZaSumu(s:Integer):void
post: stanje = stanjet@pre - s
@pre klauzula
odnosi se na vrednost atributa pre izvršenja operacije
(npr. stanje@pre).
npr. stanje se odnosi na vrednost posle izvršenja
operacije
@pre klauzula može se koristi isključivo u postcondition
ograničenjima.
OCL navigacija
Nazivi uloga (preslikavanja) koriste se za
pristup odgovarajućim objektima preko
međusobne veze.
ukoliko naziv uloge nije definisan, koristi se naziv klase
sa malim početnim slovom.
U kontekstu instance x klase C1:
C2 C3
r2 1 r3 0..1
x.r2 je tipa C2
x.r3 je tipa C3 C1
x.r4 je tipa Set(C4) r4

{ordered}
* r5 *
x.r5 je tipa OrderedSet(C5) C4 C5
OCL navigacija
Primer: Vlasnik računa mora imati više od

17 godina
context Racun
inv : self.vlasnik.godineStarosti > 17
OCL tipovi podataka
Predefinisani tipovi podataka
Primitivni tipovi: String, Integer, Real, Boolean
Tipovi kolekcije: Collection, Set, OrderedSet,
Bag, Sequence
Tip n-torka: Tuple
Specijalni tipovi: OclAny, OclType...
Korisnički definisani tipovi podataka

Korisničke klase, npr. Komitent, Racun,
Transakcija...
Operacije i operatoti nad
primitivnim tipovima
Tip Vrednost Operatori i operacije
Boolean true, false =, <>, and, or, xor, not, implies,
if-then-else-endif
Integer -1, 0, 1, … =, <>, >, <, >=, <=, *, +, - ,/ , abs(), max(b), min(b),
mod(b), div(b)
Real 1.5, … =, <>, >, <, >=, <=, *, +, - , /, abs(), max(b), min(b),
round(), floor()
String 'a', 'John' =, <>, size(), concat(s2),
substring(lower, upper) (1<=lower<=upper<=size),
toReal(), toInteger()
Tipovi kolekcije i tip n-torka
Sintaksa Opis Primeri

Kolekcija elemenata tipa
Collection(T)
T
Neuređena kolekcija,
Set(T) Set{1 , 2}
nisu dozvoljeni duplikati
Uređena kolekcija,
OrderedSet(T) OrderedSet {2, 1}
nisu dozvoljeni duplikati
Neuređena kolekcija,
Bag(T) Bag {1, 1, 2}
dozvoljeni duplikati
Uređena kolekcija, Sequence {1, 2, 1}
Sequence(T)
dozvoljeni duplikati Sequence {1..4} ( = {1,2,3,4})
Tuple {age: Integer = 5,
Tuple(field1: T1, … , N-torka( sa imenovanim
name: String = 'Joe‘ }
fieldn : Tn) delovima)
Tuple {name = 'Joe', age = 5}
Collection(T) operacije i iteratori
Operacija Opis
size(): Integer Vraća broj elemenata u kolekciji.
isEmpty(): Boolean Vraća true ukoliko je size = 0.
notEmpty(): Boolean Vraća true ukoliko je size > 0.
count(object: T): Integer Vraća broj pojavljivanja elemenata tipa T u
kolekciji.
sum(): T Vraća sumu svih elemenata u kolekciji (T mora
podržavati “+”)
Iterator Opis
exists(iterators | body) : Boolean Vraća true ukoliko je body uslov zadovoljen za
BAR JEDAN element u kolekciji.
forAll(iterators | body): Boolean Vraća true ukoliko je body uslov zadovoljen za
SVE elemente u kolekciji.
one(iterator| body): Boolean Vraća true ukoliko je body uslov zadovoljen za
TA NO jedan element u kolekciji.
Set(T) operacije
Operacija Opis
union(s: Set(T)): Set(T) Unija seta nad kojim se poziva operacija i
seta s.
intersection(b: Bag(T)): Set(T) Presek seta nad kojim se poziva operacija i
bag – a b.
including(object: T): Set(T) Vraća originalni set uklju ujući element
object.
excluding(object: T): Set(T) Vraća originalni set isklju ujući element
object.
asOrderedSet(): OrderedSet(T) Vraća originalni set kao OrderedSet.
asSequence(): Sequence(T) Vraća originalni set kao Sequence.
asBag(): Bag(T) Vraća originalni set kao Bag.
Bag(T) operacije
Operacija Opis
union(b: Bag(T)): Bag(T) Unija bag-a nad kojim se poziva operacija i
bag-a b.
intersection(s: Set(T)): Set(T) Presek bag-a nad kojim se poziva operacija i
set-a s.
including(object: T): Bag(T) Vraća originalni bag uklju ujući element
object.
excluding(object: T): Bag(T) Vraća originalni bag isklju ujući element
object.
asSequence(): Sequence(T) Vraća originalni bag kao Sequence.
asSet(): Set(T) Vraća originalni bag kao Set.
asOrderedSet(): OrderedSet(T) Vraća originalni bag kao OrderedSet.
Sequence(T) operacije
Operacija Opis
at(i : Integer) : T Vraća i-ti element sekvence (1<=i<=size).
indexOf(object : T) : Integer Vraća indeks elementa object u sekvenci.
first() : T Vraća prvi element sekvence.
last() : T Vraća poslednji element sekvence.
asBag(): Bag(T) Vraća originalnu sekvencu kao Bag.
asSet(): Set(T) Vraća originalnu sekvencu kao Set.
asOrderedSet(): OrderedSet(T) Vraća originalnu sekvencu kao OrderedSet.
append(object: T): “Lepi” element object na kraj originalne
Sequence(T) sekvence.
prepend(obj: T): Sequence(T) “Lepi” element object na po etak originalne
sekvence.
insertAt(i : Integer, object : T) Dodaje element object na i-to mesto u
: Sequence(T) skevenci(1<=index<=size+1).
OrderedSet(T) operacije
Operacija Opis
at(i : Integer) : T Vraća i-ti element uređenog seta(1<=i<=size).
indexOf(object : T) : Integer Vraća indeks elementa object u uređenom setu.
first() : T Vraća prvi element uređenog seta.
last() : T Vraća poslednji element uređenog seta.
append(object: T): “Lepi” element object na kraj originalnog
OrderedSet(T) uređenog seta.
prepend(obj: T): OrderedSet (T) “Lepi” element object na po etak originalnog
uređenog seta.
insertAt(i : Integer, object : T) : Dodaje element object na i-to mesto u
OrderedSet (T) uređenom setu(1<=index<=size+1).
Pozivanje OCL operacija
Za pozivanje operacija koristi se “ ->”, ne “.”

Primer: u svakom trenutku, komitent mora
posedovati barem jednu platnu karticu
context Komitent
inv : self.poseduje -> size() >= 1
OCL alati
Dresden OCL Toolkit
Eclipse MDT/OCL
Incremental OCL
Kent OCL Library
OCLE
OSLO – Open Source Library for OCL
................
QVT (Query/View/transformation)
“adržaj
Uvod
Relations jezik
Operational Mapping jezik
Kritike QVT – a
QVT alati i implementacije
Uvod
QVT predstavlja standard za transformacije
modela definisan od strane OMG – a
(Object Management Group).
Trenutna verzija standarda je QVT 1.1. (2011)
QVT specifikacija je hibridne
deklarativno/imperativne prirode.
Deklarativni deo je podeljen na dva nivoa.
Uvod – QVT arhitektura
Uvod – Relations jezik
Deklarati a spe ifika ija eza iz eđu MOF
modela.
Podrža a
Kompleksne paterne mapiranja objekata.
Implicitno kreiranje trace klasa i njihovih
i sta i, radi praće ja iz rše ja tra sfor a ije.
Poseduje i grafičku si taksu.
Uvod – Core jezik
Deklarativan jezik.
Mali odel/jezik koji podrža a apira ja
eđu pro e lji i kroz e alua iju uslo a
definisanih nad ovim promenljivim u odnosu
na skup modela.
Jednake ekspresivnosti kao i Relations jezik, sa
jednostavnijom semantikom.
Trace modeli se moraju definisati eksplicitno,
isu iz ede i iz sa e tra sfor a ije, kao što je
slučaj sa Relatio s jeziko .
Uvod – Operational Mappings jezik
Operational Mappings jezik je imperativan
jezik koji proširuje Relatio s i Core jezike.
Oslanja se na OCL.
“i taksa Operatio al Mappi gs jezika sadrži
standardne imperativne konstrukcije (npr.
različite rste petlji .
Operational mapiranje podrazumeva
mapiranje u potpunosti definisano
upotrebom Operational Mappings – a.
Uvod – Black Box implementacija
Doz olja a i ple e ta iju slože ih

algoritama u bilo kom programskom jeziku.
Dozvoljava upotrebu domain – specific

i lioteka za izraču ja a je red osti
propertija modela.
Relations jezik – transformacija
Transformacija modela predstavlja skup
relacija koje moraju biti zadovoljene kako bi
tra sfor a ija ila uspeš a.
Tra sfor a ija se ože koristiti za:
Proveru konzistentnosti modela
Iz e u jed og odela kako i se održala ko ziste t ost
Modeli koji se tra sfor išu oraju iti
imenovani.
Modeli koji se tra sfor išu su određe og tipa
modela.
Relations jezik – transformacija
Primer: defi isa je tra sfor a ije iz eđu
UML i relacionog modela
transformation umlRdbms (uml : SimpleUML,

rdbms : SimpleRDBMS) { ... }
• umlRdbms – naziv transformacije

uml i rdbms – odeli koji se tra sfor išu
SimpleUML i SimpleRDBMS – tipovi modela koji
se tra sfor išu
Relations jezik – relacija i domen
Relacije u tra sfor a iji defi išu ogra iče ja
koja moraju biti zadovoljena od strane
ele e ata odela uključe ih u
transformaciju.
Domen je tipizira a pro e lji a koja se ože
upariti sa ele e to odela određe og
tipa modela.
Do e ože i ati defi isa i pater koji
predsta lja skup pro e lji ih i ogra iče ja
koja elementi modela, vezani za te
promenjlive, moraju zadovoljiti kako bi ispunili
patern.
Relations jezik – relacija i domen
Primer: apirati s aki UML paket u še u
aze podataka. Nazi i paketa i še e
moraju biti isti.
relation PackageToSchema{
domain uml p:Package {name=pn}
domain rdbms s:Schema {name=pn}
}
Relations jezik – Checkonly i Enforce
domeni
Kada se rela ija iz rša a u s eru checkonly
do e a, rši se pro era da li u to do e u
postoji element koji zadovoljava relaciju.
Kada se rela ija iz rša a u s eru enforce

do e a, rši se pro era da li u to do e u
postoji element koji zadovoljava relaciju.
Ukoliko ne postoji takav element, model se
menja kako bi zadovoljio relaciju.
Relations jezik – Checkonly i Enforce
domeni
Primer:
relation PackageToSchema{
checkonly domain uml p:Package {name=pn}
enforce domain rdbms s:Schema {name=pn}
}
Relations jezik - Patern
Vezuje se za domen.
Template izraz koji se koristi da bi povezao
ele e te odela uključe e u tra sfor a iju
sa promenljivama definisanim u okviru
domena.
Primer:
domain uml c:Class {
namespace = p:Package {},
kind='Persistent',
name=cn
}
Relations jezik – When i Where
klauzule
When klauzula defi iše uslo e pod koji a
relacija mora da bude zadovoljena.
Where klauzula defi iše uslo koji ora iti

zadovoljen od strane svih elemenata
odela koji učest uju u rela iji.
Whe i here klauzule ogu sadržati i OCL

izraze.
Relations jezik – When i Where
klauzule
Primer: rela ija ClassToTa le ora ažiti ukoliko aži
rela ija Pa kageTo“ he a. Ukoliko aži rela ija
ClassToTa le, oraju ažiti i s e odgo arajuće rela ije
AttributeToColumn.
relation ClassToTable{
domain uml c:Class {...}
domain rdbms t:Table {...}
when {
PackageToSchema(p, s);
}
where{
AttributeToColumn(c, t);
}
Relations jezik – graficka notacija
Relations jezik – Top-level
relacije
U iz rša a ju tra sfor a ije, s e top-level
relacije moraju biti zadovoljene.
Ostale relacije moraju biti zadovoljene samo
ako su pozvane iz where klauzule neke druge
relacije.
Primer:
transformation umlRdbms (uml : SimpleUML, rdbms :
SimpleRDBMS) {
top relation PackageToSchema {…}
top relation ClassToTable {…}
relation AttributeToColumn {…}
}
Operational Mapping jezik
Operational Mapping jezik omoguća a:
Definisanje transformacija upotrebom potpuno
imperativnog pristupa (operational
transformacije)
Dopunu relacionih transformacija
imperativnim operacijama koje implementiraju
relacije (hibridni pristup)
Operational Mapping jezik –
Operational transformacije
Operational transformacija predstavlja
definiciju jednosmerne transformacije koja
je izraže a a i perati a ači .
U svom potpisu definiše odele uključe e
u tra sfor a iju i ulaz u tačku
transformacije (main).
Kao i klasa, operational transformacija
ože se i sta irati zajed o sa s oji
propertijima i operacijama.
Operational transformacije
transformation Uml2Rdbms(in uml:UML,out rdbms:RDBMS) { iše

Potpis: defi
main() {....} naziv transformacije,
.... počet e i ilj e
metamodele.
.....................................................
.... helperi...
.... operacije mapiranja... Ulazna tačka:
} Elementi Počet a tačka
transformacije: transformacije koja
Helperi i operacije poči je iz rše je
apira ja defi išu operacije u okviru
logiku main()
transformacije.
Operacije mapiranja
Opera ija apira ja apira jeda ili iše
ele e ata počet ih odela u jeda ili iše
elemenata ciljnih modela.
Uvek jednosmerna.
Iz rša a opera ije kako i kreirala ele e te
ciljnih modela.
Može pozi ati druge opera ije apira ja.
“a drugi opera ija a apira ja ože
usposta ljati od ose asleđi a ja.
Operacije mapiranja
Primer:
mapping Package::packageToSchema() : Schema

when { self.name.startingWith() <> "_"}
{
name := self.name;
table := self.ownedElement->map class2table();
}
Pozivanje operacija mapiranja
mapping Class::class2table() : Table when
{self.isPersistent()}
{
name := 't_' + self.name;
column := self.attribute->map attr2Column());
key := self.map class2key(result.column);
}
mapping Attribute::attr2Column() : Column {
name:=self.name; type:=getSqlType(self.type);
}
Helperi
Helper je operacija vezana za tip podatka koja
raća određe u red ost.
Može se ezi ati i za pri iti e tipo e i za
tipove modela.
Mogu se koristiti za navigaciju kroz izvorne
modele.
Dve vrste helpera:
Query (bez spoljnih efekata)
Helper sa spolj i efekti a, rši se iz e a
ulaznih paametara)
Helperi
Primeri:
query Association::isPersistent() : Boolean =
(self.source.kind='persistent' and
self.destination.kind='persistent');
..........
helper Package::computeCandidates(inout list:List) : List

{
if (self.nothingToAdd()) return list;
list.append(self.retrieveCandidates());
return list;
}
Kontrola toka
Compute
compute (v:T := initexp) { … self.getSomething() …};
While
self.myprop := while(v:T = initexp; v<>null) { …
self.getSomething() …}
forEach
self.ownedElement->forEach(i|i.isKindOf(Actor)) { …
}
Break
Continue
If-then-else
Kritike QVT - a
Ne postoji potpuna implementacija
standarda
Samo Relations i Operational Mappings jezici
Ogra iče a upotre a
Vezan za XMI format
Obimna specifikacija
Prerana standardizacija
QVT alati i implementacije
QVT Operational Mappings
Borland Together
SmartQVT
Eclipse M2M Operational QVT
QVT Core
OptimalJ (prekinut dalji razvoj)
QVT Relations
MediniQVT
ModelMorf
Eclipse M2M Declarative QVT
Literatura
http://www.omg.org/spec/QVT/
http://www.omg.org/spec/QVT/20091201/QV
TBase.xml
TCore.xml
TOperational.xml
TRelation.xml

PIS01 - IstorijaRazvojaMetoda&Alata (12 Files Merged) PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

PIS01 - IstorijaRazvojaMetoda&Alata (12 Files Merged) PDF

Uploaded by

Copyright:

Available Formats

Projektovanje informacionih sistema

ISTORIJA RAZVOJA METODA I ALATA ZA

ISTORIJA SOFTVERSKOG INŽENJERSTVA

Pod “softverskom krizom” se podrazumevaju svi, ne mali, problemi u razvoju

1955 1970 1985 Godine

Pod terminom “kriza” podrazumeva se nešto prolazno.

Fokus informacionih sistema je na

2. MODELI I METODE RAZVOJA SOFVERA

3. CASE ALATI ZA RAZVOJ SOFTVERA

Istorijat, odnosno “revolucionarne promene” se dešavaju uvek ma isti način: Prvo u

MODELI PODATAKA, BAZE PODATAKA I JEZICI IV GENERACIJE

“DOBA ZRELOSTI” - OBJEKTNE METODE

2) KONTROLNE STRUKTURE - DEFINISANJE REDOSLEDA OBAVLJANJA OPERACIJA NA

2) STRUKTURNA ANALIZA I PROJEKTOVANJE

SPO LJNI_ TO KP_1 PRO C_A TO KP_4 TO KP_6 SPO LJNI_

SPO LJNI_ SKLADP_3 TO KP_5

NALAŽENJE “CENTRALNE TRANSFORMACIJE” ILI “ANALIZIATORA TRANSAKCIJA”

DEFINISANJE HIJERARHIJSKE STRUKTURE MODULA

ANALIZA POVEZANOSTI (copling-a) I KOHEZIJE MODULA

1. ANALIZA ZAHTEVA I SPECIFIKACIJA IS.

Pretežno “lower cases” - prve faze razvoja, analiza i specifikacija sistema.

REDUNDASA PODATAKA U MASOVNOJ OBRADI PODATAKA

NEZAVISNOST PROGRAMA OD LOGIČKE I FIZIČKE STRUKTURE PODATAKA

UKLJUČIVANJE KORISNIKA U RAZVOJ SOFTVERA - POKUŠAJ DA KORISNIK SAMSTALNO

PRENOŠENJE VEĆEG DELA SEMANTIKE PROBLEMA NA PODATKE - RAZVOJA MODELA

PROGRAMI BAZA PROGRAMI IZLAZI

INF O R MAC IO NI S IST E M

GENERACIJE MODELA PODATAKA

Definicija preko tipova podataka:

(1,M) ZANIMANJE (1,M)

MLB IMER [K NAZIVK

UVOĐENJE TRANSFORMACIONIH PRINCIPA: Formalna specifikacija i

PROTOTIPSKI RAZVOJ: Odbacivi i nadgradivi prototipovi.

Ne samo “lower cases” - već delimični i

APSTRAKTNI TIPOVI PODATAKA - PRETEČA

IZOLOVANE OBJEKTNE METODE

STANDARDI - UML - ZRELOST - 1998

Skup objekata, njihovih veza, njihovih Skup vrednosti (prostih istruktura) i

APSTRAKTNI TIPOVI SU KORISNIČKI DEFINISANI TIPOVI, POGODNI ZA

Bitna karakteristika objekata u OO pristupima je u~aurenje (encapsulation),

U apstrakciji klasifikacije definišu se pojam tipa, odnosno klase objekata.

vidljivost naziv-atributa-1: tip-podatka-1 = početna vrednost-1 šiskaz osobinać

vidljivost naziv-operacije-1 (lista-argumenata-1): tip-resultata-1 šiskaz osobinać

ZA MODELE SE DEFINIŠU STANDARDI: NAJPOZNATIJI STANDARD JE:

MODELI ZA OPIS FUNKCIJA SISTEMA:

[ef startuje tran. i

{ef ubacuje obustavu ubaci

{tampa se ~ek {tampaj

{tampa se izve{taj {tampaj

(a) Dijagram kolaboracije

(b) Dijagram klasa

Pod metodologijom se podrazumeva definisani proces razvoja softvera, gde se u

Podrazumeva se "sloboda" u definisanju metodologija, odnosno mogućnost

K L I JENT A PL I K A CI ONI SERV ER BA Z E

U znatno većoj meri su transformacioni

RAZVOJ INFORMACIONIH SISTEMA

Složenost razvoja IS savladava se:

KONKRETNE MOTODE I PRISTUPI NE SPADAJU

unesi stavku (prkod, kol)

Problemi razvoja: ODRŽAVANJE

Teško je, gotovo nemoguće utvrditi sve zahteve

Veoma skupo održavanje

SVI OVI NEDOSTACI I ZNATNO MANJOJ