Projektovanje informacionih

sistema
RAZVOJ INFORMACIONIH
SISTEMA

Sloenost razvoja IS i modeli

ivotnog ciklusa IS
Sloenost razvoja IS savladava se:
Razbijanjem celokupnog razvoja na faze
nain razbijanja na faze se naziva
Model ivotnog ciklusa IS
Dekompozicijom samog sistema,
odnosno definisanjem arhitekture
sistema
Funkcionalna (strukturna) ili objektana
dekompozicija
Dvoslojna, troslojna ili vieslojna arhitektura

Modeli ivotnog ciklusa

IS
Tri osnovne grupe (principa):
Konvencionalni razvoj: striktno praenje svih
pravila inenjerskog pristupa razvoju IS.
Brzi razvoj: to pre doi do kakvog takvog
reenja, pa ga onda usavravati
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
P L A N IR A N J E
R AZVO J A
A N A L IZ A I
S P E C IF IK A C IJ A
ZAHTEVA
PRO JEKTO VANJE
IM P L E M E N T A C I J A ( k o d ir a n je
i te s tir a n je )
O D R AVAN J E

KONVENCIONALNI IVOTNI CIKLUS

STRUKURNI PRISTUP
1. PLANIRANJE BSP METODA
2. ANALIZA I SPECIFIKACIJA

ZAHTEVA
STRUKTURNA SISTEMSKA ANALIZA
NALAENJE 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

KONVENCIONALNI IVOTNI CIKLUS

STRUKURNI PRISTUP
2. PROJEKTOVANJE
Logiko projektovanje
Izgradnja odgovarajueg modela
podataka (model objekti-veze)
Transformacija modela objekti veze u
normalizovan relacioni model.
Projektovanje strukturnih programa

Fiziko projektovanje

Fiziko projektovanje baza podataka

Projektovanje korisnikog interfejsa
Dodavanje fiikih elemenata
strukturnim programima.

KONVENCIONALNI IVOTNI CIKLUS

STRUKURNI 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
PODATAKA
(Struktura baze i
dinami~ka pravila
integr)

KONVENCIONALNI IVOTNI CIKLUS

OBJEKTNI PRISTUP
1. PLANIRANJE Nita specifino
2. ANALIZA I SPECIFIKACIJA

ZAHTEVA

Izrada Sluajeva korienja:

Dijagram sluajeva korienja i
verbalni opis svakog SK
Izrada sistemskih dijsgrama
sekvenci

Opis SK:
P rod aja
< < in c lu d e > >

R eg istr o v a n j e
a r tik a la

< < e x te n d > >

1.
2.
3.
4.
5.

U p r a v lj a n j e
z a lih a m a

< < in c lu d e >

>

P la c a n j e

6.
P la c a n j e u
g o to v o m

P la c a n j e
k a tic o m

Uesnici
Namena
Kratak opis
Pre i Post uslovi
Opis osnovnog toka
dogaaja
Opis alternativnog
toka dogaaja

KASIR
:System
unesi stavku (prkod, kol)

SISTEMSKI DIJAGRAM
SEKVENCI ZA SLUAJ

kraj prodaje ( )

KORIENJA PRODAJA
placanje (iznos)

KONVENCIONALNI IVOTNI CIKLUS

OBJEKTNI PRISTUP
3. PROJEKTOVANJE
Logiko projektovanje
Izrada konceptualnog modela
(dijagrama klasa bez operacija)
Izgradnja dijagrama sekvenci,
dijagrama kolaboracije ili dijagrama
aktivnosti za opis dinamike sistema
(logike aplikacije)
Izgradnja kompletnog logikog modela
sistema (dijagram klasa sa operacijama
definisanim preko dijagrama sekvenci
kolaboracije ili aktivnosti)

KONVENCIONALNI IVOTNI CIKLUS

OBJEKTNI PRISTUP
4. PROJEKTOVANJE
Fiziko projektovanje (zavisno od
konkretnog okruenja)
Projektovanje baze podataka
Projektovanje korisnikog interfejsa
Dodavanje novih klasa na osnovu
odgovarajuih uzora (pattern-a): MVC
patern, Perzistentni brokeri i mnogi drugi
Izgradnja kompletnog fizikog modela
sistema

KONVENCIONALNI IVOTNI CIKLUS

OBJEKTNI PRISTUP
5. IMLEMENTACIJA
Rasporeivanje delova modela na
pojedine elemente vieslojne
arhitekture,
Transformacija fizikog modela u
konkretno implenemtaciono okruenje
Dodatno kodiranje
Testiranje

KONVENCIONALNI IVOTNI CIKLUS

NEDOSTACI
P L A N IR A N J E
R A ZVO J A

A N A L IZ A I
S P E C IF IK A C IJ A
ZAH TE V A

PR O JEKTO VANJE

Problemi razvoja:

IM P L E M E N T A C I J A ( k o d ir a n je
i te s tir a n je )

Teko je, gotovo nemogue utvrditi sve

zahteve na poetku projekta i potpuno tano;
Projekti su obino dugotrajni t teko je
skrupulozno sprovesti metodologiju do kraja
Do prve verzije sistema (koja bi trebalo da
bude konana) dolazi se veoma sporo.
Zaksneo povratni uticaj korisnika
Veoma obimna dokumentacija za velike
projekte.

O D R AVAN JE

KONVENCIONALNI IVOTNI CIKLUS

NEDOSTACI
P L A N IR A N J E
R A ZVO J A

A N A L IZ A I
S P E C IF IK A C IJ A
ZAH TE V A
PR O JEKTO VANJE
IM P L E M E N T A C I J A ( k o d ir a n je
i te s tir a n je )

Problemi odravanja:
Veoma skupo odravanje
Dvostruko odravanje, odravanje koda i
odravanje projektne dokumentacije
U sluaju izmene zahteva treba proi ponovo
kroz sve faze projektaovanja i izvriti izmene. To
se obino ne radi, pa na kraju, i pored
ogromnog truda imamo nesaglasnost koda i
projektne dokumentacije.
SVI OVI NEDOSTACI I ZNATNO MANJOJ
MERI DOLAZE DO IZRAAJA U OBJEKTNIM
PRISTUPIMA!

O D R AVAN JE

Modifikacije konvencionalnog ivotnog

ciklusa: Spiralni model
Analiza i
specifikacija zahteva

Evaluacija i
Planiranje sledeeg
ciklusa

Analiza izvodljivosti

Izrada prototipa

Prototipovi slie za:

Validaciju kor. Zahteva
Experimenat sa implementacionim
okruenjem

Modifikacije konvencionalnog ivotnog

ciklusa: Inkrementalni model

Prethodi podela na podsisteme,

odnosno definisanje polazne
arhitekture sistema

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 a tio n (s )

ite r.
#1

ite r.
#2

ite r.
#k

ite r.
#k +1

ite r.
# k+2

ite r.
# n-1

ite r.
#n

Brzi (rapid, agile) razvoj

U ovom pristupu, umesto da se trudimo
da detaljnom analizom pokuamo da
utvrdimo potpune zahteve korisnika,
pokuavamo da razvijemo sistem sa
nekompletno definisanim zahtevima.
Prototipski
Agile

razvoj- rapid prototyping

Software Development

Iz m e n a s p e c if ik a c ije

Prototipski razvoj
S p e c if ik a c ija
a r h ite k tu r e s is te m a
(b a z e p o d a ta k a i
s k u p a a p lik a c ija )

S p e c if ik a c ija
a p lik a c ije

Iz r a d a p r o to tip a

E v a lu a c ija
p r o to tip a

P r o je k to v a n je i
iz g r a d n ja k o n a n e
a p lik a c ije

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
uraen (Jezici etvrte generacije)
Loa dokumentacija, teko odravanje ovako izgraenog sistema

Agile Software Development

Cilj je kod koji radi, a ne perfektna
dokumentacija. Vie se vodi rauna 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 okruenju sa
stalno promenljivim zahtevima. U takvom
okruenju konvencionalni ivotni ciklus bi
bio neupotrebljiv.

XP (Extreme
Programming)
XP se zasniva na sledeim principima:
1.

2.

3.
4.

Planiranje. Korisnik daje procenu dobiti za

realizaciju pojedinih zahteva, a programeri
odgovarajuu procenu trokova i na osnovu
toga se odreuju zahtevi koji e biti realizovani
odmah i zatevi koji e biti odloeni.
Jednostavna realizacija. XP tim proizvodi
jednostavne sisteme i a zatim ih uestalo
menja i poboljava
Metafora. XP timovi koriste zajedniki sistem
imena i zajedniuki opis sistema.
Jednostavno projektovanje. XP
podrazumeva da se svaki program pravi na
najednostavniji nain koji zadovoljava zahteve.

XP (Extreme
Programming)
5.

6.

7.

8.

Testiranje. Stalno se vri validacija sistema. Prvo

se definie test, a onda se razvija softver koji
treba da ga zadovolji. Korisnik definie test za
prihvatanje sistema.
Refactoring. Softver se stalno poboljava, s tim
da se ouva njegova jednostavnost. Ne prave se
duplikati.
Programiranje u parovima. Dva programera
razvijaju jedan kod kontroliui jedan drugog.
Rade na istoj maini. Pokazuje se da ovakav
razvoja daje znatno bolje rezultate od
individualnog razvoja.
Kolektivno vlasnitvo. Ceo kod pripada svim
programerima. Kad god je potrebna neka izmena
bilo ko moe da je izvri.

XP (Extreme
Programming)
9. Stalna integracija. Integracija razvijenih

delova radi se vie puta dnevno. To zahteva

uee 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. Znaajno se
poboljava komunikacija, smanjuje potreba
za prepiskom i dokumentacijom.
12. Standardno kodiranje. Svi programeri
treba da piu kod na isti, standardni, nain
da bi se principi XP-a mogli da sprovedu.

Formalni (transformacioni)
razoj
E v a l u a c i ja i
in v e r z n a
t r a n s f o r m a c i ja

A n a liz a
z a h te v a

F o rm a ln a
s p e c i f i k a c i ja

T r a n s f o r m a c i ja
s p e c i f i k a c i je u
i m p l e m e n t a c i ju

R a d n i s is te m

Izvrni kod se dobija iskljuivo transformacijom formalne

specifikacije u implementaciju
Ovakav pristup omoguuje jednostavnu promenu
implementacionog okruenja (platforme) - jednostavno
adaptivno odravanje
Perfektivno odravanje sistema se znaajno pojednostavljuje
nema dvostrukog odravanja (dokumentacije i koda)

Formalni (transformacioni)
razoj
E v a l u a c i ja i
in v e r z n a
t r a n s f o r m a c i ja

A n a liz a
z a h te v a

F o rm a ln a
s p e c i f i k a c i ja

T r a n s f o r m a c i ja
s p e c i f i k a c i je u
i m p l e m e n t a c i ju

R a d n i s is te m

Koji se jezici (modeli) koriste za formalnu

specifikaciju?
Kako se vri transformacija formalne
specifikacije u radni sistem (kod)?
Kako se vri formalna inverzna transformacija?

Formalni (transformacioni)
razoj
U vreme kada je definisan transformacioni
pristup je bio mogu samo za veoma
specifine i jednostavne sisteme za koje ke
bilo mogue definisti formalni specifikacioni
jezik i odgovarajuu transformaciju
CASE alati delimino podravaju ovakav
pristup (Model objekti-veze kao jezik za
specifikaciju i SQL ko radni sistem, na primer)
Osnovna ideja, znaajne prednosti ovoga
pristupa, sve bolji jezici (modeli) za
specifikaciju i CASE alati stalno unapreuju
transformacioni pristup razvoju IS.

Transformacioni razvoj:Cleanroom
engineering
Cleanroom engineering koji je predloio IBM
(druga polovina 80-tih) je rigorozni metod razvoja
u kome greke nisu dozvoljene (za razliku od
drugih pristupa koji se zasnivaju na trial-anderror pristupima).
Cleanroom engineering polazi od injenice da
su programi nain realizacije matematikih
funkcija. Za specifikaciju programa neophodno
je definisati funkciju koja u potpunosti opisuje
ponaanje koje se od programa zahteva.
Nalaenje procedure koja realizuje tu funkciju je
osnova razvoja softvera.

Transformacioni razvoj:Cleanroom
engineering
U

S
U

S
u11

U x X --> Y
Iz la z n a
t r a s f o r m a c i ja

U x X --> X
P r e l a z n a f u n k c i ja
s t a n ja

C rn a
k u tija

u12

K u tija
s ta n ja

y12

y11
u13

y13

P ro z ra n a
k u tija

Transformacioni razvoj:Sistemskoteorijski ivotni ciklus FON kraj

prolog veka
1. Identifikacija sistema: nalaenje

funkcionalnog modela sistema, na osnovu

nekog posmatranja (analize):
S:Fa : T x U ---> Y, a A}
2. Realizacija sistema: nalaenje 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:Sistemskoteorijski ivotni ciklus FON kraj

prolog veka
Identifikacija sistema skup funkcija
(bilo koji alat za funkcionalnu specifikaciju
sistema, Dijagrami tokova podataka,
najbolje, a mogu i Sluajevi korienja)

Realizacija sistema:
Izbor najpovoljnijeg modela za realizaciju
funkcija
Nalaenje minimalne realizacije u okviru
izabranog modela.

ID E N T IF IK A C IJA
U L A Z

IZ L A Z

R E A L IZ A C IJA
<<ObjectType>>
CINI_VRSTA

U L A Z
<<ObjectType>>
VRSTA_CINPOS
SIFRA_VR_CINPOS : VARCHAR
NAZIV_VR_CINPOS : VARCHAR
NACIN_REAL : NUMBER

IZ L A Z

<<ObjectType>>
KLASA

IM P L E M E N T A C IJA
U L A Z

se r v e r :S a m o p o s.

<<baza >>
:P r o d a ja

:u p iti

IZ L A Z

:tr a n s a k c .

K lij en t: P O S te r m in a l

:P O S - G U I

SISTEMSKO-TEORIJSKI IVOTNI CIKLUS

Ponekad se u Sistemsko-teorijski ivotni

ciklus daodaje i etvrta faza:
4. Sinteza upravljanja
ime se realizuje upravljaka funkcija IS,
odnosno MIS (Management Information
System)

UPRAVLJAKI INFORMACIONI SISTEMI

Samosinhronzovani skup

K o r isn ik
( A k te r)
F 1

Aplikacija
Sinhronizacija preko
podataka u bazi

F 2

O B JE K T N I M O D E L
SK U P M E \ U SO B N O P O V E Z A N IH
O B JE K A T A

F 3
K o r isn ik
( A k te r)

F 4

F 5
K o r isn ik
( A k te r)

Omogueno upravljanje
pojedinanim funkcijama
Savremeni menadment je
orjentisan prema upravljanju
procesima koji predstavljaju
orkestraciju funkcija u cilju
obavljanja nekog zadatka.

Upravljanje procesima- Modeli procesa

Danas postoji gotovo opta saglasnost da je

upravljanje meusobno povezanim i meusobno
zavisnim poslovnim procesima ("process centered
management approach") osnova uspenog
funkcionisanja bilo koje organizacije
Reinenjering
poslovnih
procesa

Upravljanje
kvalitetom

Modeli (poslovnih)
procesa

Standardi i
modeliranje

.....

Razvoj
informacionih
sistema

UPRAVLJAKI INFORMACIONI SISTEMI

P R O C E SO R 1

F 2

F 1

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 P O D A T A K A
O B JE K T N I M O D E L

F 3

P R O C E SO R 2

F 4

F 5

Praenje realizacije
nekog ugovora,
Praenje realizacije
narudbenice kupca,
Sprovoenje nekog
upravnog postupka i
slino.

P R O C E SO R 3

Odnos poslovnih procesa i poslovnih funkcija

Upravljaki mehanizam sadri:
Model poslovnih procesa
Model organizaciono-tehnolokog okruenja
Operativni plan obavljanja poslovnih procesa
Operacije za upravljanje: lansiranje u suspedndovanje posla,
preraspodela izvrioca i slino

Transformacioni
razvoj:Modelom voeni razvoj
Model Driven Architecture (MDA) koju je
2001 predloila Object Management Group
je an approach to using models in
software development. Zato je bolje
koristiti prevod Modelom voeni razvoj
mego Modelom voene arhitekture.
Pojam arhitektura se vezuje za injenicu
da se preko asptraktnih modela (PIM)
moe da ostvari inteoperabilnost
heterogenih sistema.

Modelom voeni razvoj

R a u n a rs k i
n e z a v is a n m o d e l
C IM

Computation Independent Model CIM model

odgovarajueg domena, zajedniki renik za korisnika i
projektanta

P la tfo r m s k i
n e z a v is a n m o d e l
P IM

M o d e l z a o p is
P la tfo r m e
PD M

T r a n s f o r m a c i ja

P la tfo r m s k i z a v is a n
m odel
PSM

Platform Independent Model PIM.

Model IS nezavisan od
implementacione platforme.
Specifikacija sistema
Platform Description Model PDM
Model implementacione platforme

Platform Specific Model- PSM

Model IS implementiran u datom
okruenju.

Modelom voeni razvoj

Modelom voeni razvoj omoguava:
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

2.

3.

4.

5.
6.

Modeling Language User Guide,Addison

Weseley,1999,
J.Rambaugh, I Jacobson, G.Booch, The Unified
Modeling Language Reference
Manual,Addison Weseley,1999,
I Jacobson, G.Booch, J.Rambaugh, The Unified
Software Development Process, Addison
Weseley,1999,
Larman, G., Applying UML and Patterns,
Prentice Hall, 1998.
Gamma, E., Helm, R., Johnson, R., Vlissider, J.,
Design Patterns, Addison-Weseley, 1995.
Fowler, M., Analysis Patterns, Addison Weseley,
1997.

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.Fernndez, 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