Specifikacija i Modelovanje Softvera

Software Systems Modeling

Poglavlje 02. Specifikacija dizajna
softverskih sistema

Prof.dr Branko Perišić

perisic@uns.ac.rs
 Specifikacija dizajna - 1
PREDSTAVLJA KORAK U KOME SE
ANALIZA ZAHTEVA
PREVODI U ARHITEKTURU SISTEMA
KOJI JE PREDMET PROJEKTOVANJA

IDENTIFIKACIJA SPECIFIKACIJA
OSNOVNIH FORMATA
MODULA

DEFINISANJE DEFINICIJA
KOMUNIKACIONIH STRUKTURE
PUTEVA ZA PRENOS PODATAKA
PODATAKA IZMEĐU
MODULA

DEFINISANJE
UNUTRAŠNJE
STRUKTURE
POJEDINAČNIH
MODULA
 Specifikacija dizajna - 2
SPECIFIKACIJA
ZAHTEVA
(SPECIFIKACIONI
DOKUMENT)

SPECIFIKACIJA
DIZAJNA
DEKOMPOZICIJA (DESIGN SPECIFICATION)
ILI
KOMPOZICIJA MODELING-IN_THE_LARGE

IMPLEMENTACIJA
(MODELING-IN-THE-
SMALL)
 Specifikacija dizajna - 3

Elementi specifikacije dizajna:

• Segregacija – razlaganje funkcionalne specifikacije na

MODULE
• Hijerarhijsko organizovanje modula
• Definisanje tokova podataka između modula
• Definisanje strukture spoljašnjih skladišta podataka
• Definisanje pristupnih puteva spoljašnjim skladištima
podataka
• Definisanje struktura podataka koje se razmenjuju
među modulima posredstvom definisanih tokova (puteva)
• Izrada ključnih algoritama
• Definisanje unutrađnje strukture svakog modula
 UML Specifikacija dizajna – (1)

Slučajevi korišćenja ne definišu način na koji će

sistem biti izgrađen, već samo način na koji
učesnici mogu koristiti funkcije projektovanog
sistema.

• STATIČKA STRUKTURA SISTEMA –

definiše način implementacije slučajeva korišćenja.

• KLASE
• OBJEKTI
• VEZE
 UML Specifikacija dizajna – (2)

• DINAMIČKO PONAŠANJE SISTEMA –

definiše način komunikacije između objekata i efekte te
komunikacije,
komunikacije odnosno načine na koji OBJEKTI sarađuju i
kako se unutar sistema menjaju u toku vlastitog životnog
ciklusa.

• DIJAGRAMI STANJA
• DIJAGRAMI SEKVENCE
• DIJAGRAMI SARADNJE
• DIJAGRAMI AKTIVNOSTI
 UML Specifikacija dizajna – (3)

•UML Specifikacija dizajna definiše način

realizacije (implementacije) slučajeva
korišćenja!
<<realizuje>>
Saradnja klasa
Use Case
<<implementira>>
<<implementira>>
<<implementira>>

Opis slučaja koriščenja

Klasa A Klasa |B Klasa C
Atributi Atributi Atributi
Operacije Operacije Operacije
Osnovni koncepti objektne paradigme

• Objekat
• Klasa
• Atribut
• Operacija
• Interfejs (Polimorfizam)
• Relacije
 Šta je Objekat?
• Neformalno, objekat
pretstavlja neki entitet
bilo fizički,Formalna definicija objekta
konceptualni ili
Objekat pretstavlja koncept, apstrakciju ili
 logički(software)
stvar sa jasnim granicama i značenjem sa
Kamion
– Fizički entitet
aspekta neke primene.
 Objekat je nešto što poseduje:
– Konceptualni entitet
– Stanje Hemijski proces

– Ponašanje
– Identitet
– Softverski entitet Jednostruko spregnuta lista
Osnovni koncepti objektne paradigme

• Objekat
• Klasa
• Atribut
• Operacija
• Interfejs (Polimorfizam)
• Relacije
 Šta je klasa?
• Klasa je opis grupe objekata koji poseduju skup
zajedničkih: svojstava (atributa), ponašanja
(operacije/metode), veza i značenja.
– Objekat je INSTANCA neke klase

• Klasa pretstavlja APSTRAKCIJU jer:

– Naglašava relevantne karakteristike
– Potiskuje sve ostale karakteristike
 Dobro strukturirana klasa!
• Dobro strukturirana klasa ima sledeće osobine:
– Predstavlja JASNU APSTRAKCIJU nečega što je sastavni
deo problema (sistema)
sistema ili realizacije (implementacije)
(rešenja).
rešenja
– Sadrži mali broj dobro definisanih odgovornosti i ispravno ih
realizuje.
– Omogućava jasno razdvajanje SPECIFIKACIJE i
IMPLEMENTACIJE apstrakcije koju predstavlja.
– Razumljiva je i jednostavna, ali otvorena (dozvoljava
modifikacije, proilagođavanja...)
 UML - Odeljci klase
• Klasa se sastoji od četiri sekcije Ime pripada domenu
problema.
problema Treba da
– Prva sekcija sadrži naziv klase bude IMENICA bez
prefiksa
– Druga sekcija sadrži svojstva (attribute)
Imenovane ili sufiksa.
osobine
Uobičajeno
klase kojeje da je
opisuju
– Treća sekcija sadrži ponašanje (operations)
prvo
opseg slovo svake
vrednosti koje
reči koja čini složeno
Operacija
konkretni primercije
– Četvrta opis odnosa atributa i operacija.
ime VELIKO.
VELIKOmoguonoga
apstrakcija
osobine da
što se može izvršiti
sadrže.
Naziv klase Profesor nad objektom i što je
Ime
Atributi Identifi kator zajedničko za sve
Tekst
objekte.u slobodnoj
Metode create( ) formi koji pobliže
save( )
delete( ) opisuje vezu između
change( ) atributa i operacija.
Odgovornosti
 Primer klase
Klasa Programer
Svojstva
firstName
lastName
address

Ponašanje
writeCode
getProject
deliverProject
Osnovni koncepti objektne paradigme

• Objekat
• Klasa
• Atribut
• Operacija
• Interfejs (Polimorfizam)
• Relacije
 Šta je Atribut?
Klasa Objekat
 Atribut je imenovano svojstvo klase koje
Atribut opisuje skup
Vrednost vrednosti koje instance
atributa
posmatrane klase :PonudaKurseva
mogu poprimiti.
(Booch,1999) number = 101
startTime = 900
 Atribut poseduje tip
PonudaKurseva koji =definiše
endTime 1100 tip
number njegovih instanci.
startTime
endTime Jedino objekat može promeniti vrednosti
:PonudaKurseva
svojih atributa. number = 104
startTime = 1300
 Vrednosti atributa endTime
definišu stanje objekta.
= 1500
 Atributi (nastavak.)
• Različiti objekti iste klase
 UML predstava atributa
• Odeljak atributa (Attribute Compartment)
[vidljivost] ime [višestrukost] [:tip] [= početna vrednost]
[{lista vrednosti}]
[{promenljivost}]
changable – default
Kardinalitet 1. primitivni frozen – konstatna
(Boolean, String, Integer)
2. složeni addOnly – samo pri dodavanju

1. public (+) Svaki spoljnji klasifikator može koristiti tu karkteristiku

2. protected (#) Svaki naslednik može koristiti karakteristiku
3. private (-) Samo klasifikator može koristiti karakteristiku
default – public ili undefined
 UML predstava atributa-(2)
• Primeri:
Primeri
+pozicijacentra: Point = (0,0)
-naziv: String = ‘’Nepoznat’’
-status [1..4]: Char =‘0’{‘0’,’1’.’2’,’3’}
-identifikacija:LongInteger
zajednicki za sve objekte

-semafor:Colour=‘crven’{‘žut’,’crven’,’zelen’}
Osnovni koncepti objektne paradigme

• Objekat
• Klasa
• Atribut
• Operacija
• Interfejs (Polimorfizam)
• Relacije
 Šta je operacija (Metoda)?
• Operacija je IMPLEMENTACIJA SERVISA koji
se može zahtevati od strane bilo koje instance a
koji utiče na ponašanje objekta. (Booch, 1999)
• Operacija može biti:
– Upit (ne menja stanje objekta)
– Komanda (može da promeni stanje objekta)
 Šta je Operacija?

PonudaKursa
Klasa
addStudent
deleteStudent
getStartTime
Operacija getEndTime
 UML pretstava operacija
• Odeljak operacija (Operation Compartment)
[vidljivost] ime ([lista parametara]) [:tip rezultata] [{osobina}]
isQuiery Čista funkcija bez sporednih efekata.
parametar [,lista parametara]
sequential U datom objektu u jednom trenutku
postoji samo jedan upravljački tok.
parametar = [smer] ime: tip [=podrazumevana vrednost]
Oni koji pozivaju metodu moreju se
eksterno sinhronizovati.
{in, out, inout}
guarded Jedna operacija u jednom trenutku na
1. public (+) Svaki spoljnji klasifikator svakoj
može instanci
koristiti(objektu).
operaciju.
Sekvencijalnost je zagarantovana
2. protected (#) Svaki naslednik može koristiti
unutaroperaciju.
objekta!

3. private concurent
(-) Samo klasifikator Operacije
može koristiti su atomičke prirode.
operaciju.
Dozvoljeni su konkurentni pozivi iz
default = public paralelnih upravljačkih tokova ka
jednoj instanci klase.
 UML predstava operacija-(2)
Toolbar
#currentSelection: Tool
#toolCount: Integer
+pozicija: Possition=“Up”
Primer
+draw(p:Possition)
specifikacije +pickItem(i:Integer)
operacija
+addTool(t: Tool)
+removeTool(t: Tool)
+getTool(): Tool
#chackOrphans)=:Boolean
-compact()
+restart() {guarded}
Osnovni koncepti objektne paradigme

• Objekat
• Klasa
• Atribut
• Operacija
• Interfejs (Polimorfizam)
• Relacije
 Šta je Polimorfizam?
• Mogućnost skrivanja više različitih
implementacija iza jedinstvenog interfejsa.
interfejsa

Proizvođač B
Proizvođač A Proizvođač C

OO Princip:
Encapsulacija
 Šta je interfejs?
• Interfejs pretstavlja skup metoda koje se
koriste za specificiranje servisa klase ili
komponente. (Booch, 1999)

• Interfejs je “ugovor”
ugovor između povezanih
servisa i skupa uslova koji moraju biti
zadovoljeni u cilju pružanja servisa.

• Interfejsi formalizuju polimorfizam,

polimorfizam
dozvoljavaju deklarativno specificiranje
polimorfizma nezavisno od implementacije.
implementacije
 Šta je interfejs-(2)?
• Interfejs podržava “plug-and-play”
plug-and-play
architekture
Kupa
<<interface>>
Telo
Piramida
Draw
Move
Scale
Rotate Kocka

Veza realizacije
 Predstavljanje interfejsa
Kupa

Piramida
Ikonički

Telo Kocka

Kupa
<<interface>>
Telo
Kanonski Piramida
(Klasa/Stereotip) Draw
Move
Scale
Rotate Kocka
Osnovni koncepti objektne paradigme

• Objekat
• Klasa
• Atribut
• Operacija
• Interfejs (Polimorfizam)
• Relacije
 Veze između Klasa i Objekata
• Asocijacija
– Agregacija
– Kompozicija
• Zavisnost
• Generalizacija
• Realizacija
 Veze između Klasa i Objekata –(2)
• Koliko pojava date klase
Asocijacija opisuje grupu veza sa zajedničkom strukturom i
može biti vezano za jednu
semantikom (Osoba radi za Preduzeće) kod koje su svi učesnici
pojavu druge.
“SVESNI POSTOJANJA ONIH DRUGIH” DRUGIH tj. međusobno se
referenciraju. Asocijacija je obično dvosmerna
Imenovanje veza između klasa
asocijacije
1, 0..1, * , 1..*, n..m,k,r
koja opisuje skup mogućih veza na isti način nailikoji
(glagol klasa opisuje
imenica)
skup potencijalnih instanci (objekata).
Uloga klase u
UML simbolika: asocijaciji (opciono)
<<naziv asocijacije K1-K2>>

Klasa K1 Klasa K2
<<Uloga K1>> <<UlogaPredstavlja
K2>> jedan atribut ili
skup atributa referencirane
<<kvalifikator>> klase pomoću kojih se iz
<<kardinalitet K1>> skupa
<<kardinalitet K2>> instanci klase izdvaja
podskup koji ima vrednost
<<naziv asocijacije K2-K1>> kvalifikatora!
 Primer 1.
• Modeluje semantičku vezu između klasa.
Naziv asocijacije

Profesor Radi za Univerzitet

Asocijacija

Klasa
Naziv uloge

Professor Univerzitet
Zaposleni Poslodavac
Primer 2: Kvalifikovana asocijacija

Kvalifikator /Ključ
 Asocijacije –(1)
• Obične (normalne)
• Rekurzivne - (povezuju različite instance iste klase)
• Refleksivne – (povezuju iste instance)
• Kvalifikovane – (ako je definisan kvalifikator)
• Uređene – (ako postoji eksplicitno uređenje - sortiranje)
• Agregacija modeluje vezu čije je značenje “deo-celina”
celina ili
“deo-od”
od preko koje su objekti koji predstavljaju delove
celine povezane sa objektom koji predstavlja celinu. Delovi
ne dele sudbinu celine!
• Kompozicija modeluje vezu čije je značenje “deo-celina”
celina
ili “deo-od”
od preko koje su objekti koji predstavljaju delove
celine povezane sa objektom koji predstavlja celinu. Delovi
moraju da dele sudbinu celine!
 Agregacija i Kompozicija
Agregacija:
Klasa K1 Klasa K2

Kompozicija:
Klasa K1 Klasa K2
 Primer:

Kardinalitet

Student 1 0..* Raspored

Navigacija
Kompozicija
Agregacija
Asocijativna klasa
 Veze između Klasa i Objekata-(3)

• Zavisnost je slabija verzija veze koja odražava

odnos klijenta (potrošača)
potrošača i servera
(proizvođača).
proizvođača Podrazumeva vezu koja
opisuje međuzavisnost elemenata modela kod
koje promena u sklopu jednog (nezavisnog)
nezavisnog
elementa uzrokuje promenu u sklopu drugog
(zavisnog)
zavisnog elementa.
• Može se uspostaviti između različitim
elemenata modela (klase, komponente, paketi)
ali jedino na istom nivou apstrakcije!
apstrakcije
 Veze između Klasa i Objekata-(3)
• Primeri zavisnosti:
1. Jedna klasa preuzima objekat druge klase kao
parametar!
parametar
2. Jedna klasa pristupa globalnom objektu druge klase!
3. Jedna klasa poziva operaciju definisanu u drugoj klasi!

UML simbolika:(zavisnost)
Klasa K1 Klasa K2
labela <<stereotip>>
 Primeri veza zavisnosti

Klijent Server
Komponenta
Klasa

Klijent
Paket Server
Veza
zavisnosti
Veza
zavisnosti
KlijentPaket ServerPakete
Primer veza zavisnosti –(2)
 Veze između Klasa i Objekata-(4)

• Rafinacija (refinments) predstavlja vezu

između JEDNE TE ISTE STVARI na
različitim nivoima APSTRAKCIJE!
APSTRAKCIJE

UML simbolika:(rafinacija)

Klasa K1 Klasa K2
(specifikacija zahteva) labela <<stereotip>> (specifikacija dizajna)
 Relacije: Realizacija
• Jedan klasifikator služi kao “ugovor”
ugovor koji drugi
klasifikator prihvata da poštuje.
poštuje
• Postoji između:
– Interfejsa i klasifikatora koji ih realizuju
– Slučajeva korišćenja i saradnje klasa koja ih realizuje.

Klasa Komponenta
Podsistem
Interfejs Interfejs
Interfejs

Vodeća forma
Kanonski oblik

Use Case Use-Case Realization

 Realizacija - implementira

Interfejs pretstavlja skup operacija koje služe za

specificiranje servisa klase ili komponente
(Booch, 1999).
Interfejsi formalizuju polimorfizam, dopuštaju
definisanje polimorfizma na deklarativni način
nezavisno od implementacije.
 Veze između Klasa i Objekata-(5)

• Generalizacija predstavlja vezu između

klasa u kojoj jedna od njih ima opšta svojstva
dok je druga njena specijalizacija.
specijalizacija Podređeni
element je u potpunoj saglasnosti sa
nadređenim i poseduje sve osobine nad-
klase (roditeljska klasa – predak),
predak ali može
posedovati i dodatne osobine koje definiše
pod-klasa (potomak).
potomak Veza generalizacije je
jedino moguća između KLASA!
KLASA
 Generalizacija
• Veza između klasa kod koje jedna klasa deli strukturu
i/ili ponašanje jedne ili više klasa.
• Definiše hijerarhiju apstrakcija kod koje PODKLASE
nasleđuju svojstva ili ponašanje od jedne ili više
SUPERKLASA.
– Jednostruko nasleđivanje (Single inheritance)
– Višestruko nasleđivanje (Multiple inheritance)
• Generalizacija je veza tipa “je-pripadnik-vrste”
vrste (is-a-
kind-of).
Generalizacija - primer
 Primer: Jednostruko nasleđivanje
• Jedna klasa nasleđuje od druge
Predak

Account
balance
name
Superklasa number
(roditelj) Withdraw()
CreateStatement()
Veza
generelizacije

Checking Savings

Podklase Withdraw() GetInterest()

Withdraw()

Potomci
 Primer: Višestruko nasleđivanje
• Klasa može da nasleđuje više drugih

Letelica Životinja

višestruko nasle ivanje

Avion Helikopter Ptica Vuk Konj

Koristite višestruko nasleđivanje jedino kada je stvarno

potrebno a i tada pažljivo!
pažljivo
 Šta se nasleđuje?

• Klasa potomak nasleđuje atribute klase pretka,

metode i veze sa drugim klasama.
klasama
• Klasa potomak može:
– Dodati nove atribute, metode i veze
– Redefinisati nasleđene metode.
• Zajednički atributi, metode i/ili veze se prikazuju
na što je moguće višem nivou hijerarhije.

Nasle ivanje “niveliše”

niveliše sli nosti me u klasama!
 Primer: Šta se nasleđuje

ZemaljskoVozilo
vlasnik Osoba
Suoperklasa weight
(Roditelj) licenseNumber 0..* 1

register( )
generalizacija

Auto Kamion Prikolica

Podklase
size tonnage
(Potomci)
getTax( )
 Primer-1: Dijagram klasa
Figure
{abstract}
Canvas
sadrži * pozicija: Pos

sadrži *
draw(): {abstract}

Linija
{abstract}

Grupa Element sadrži *

draw(): {abstract}
draw(): draw():

Luk Duz

draw(): draw():
 Primer-1: JAVA implementacija-(2)

abstract public class Figure

{
abstract public void draw();
protected Pos position;
};
public class Element extends Figure
{
public void draw();
{
/* Kod draw metode Elementa */
}
};
 Primer-2: Dijagram klasa
Invertor IKolo

+Iscrtavanje() : void +Iscrtavanje() : void IliKolo

+Pomeranje() : void +Pomeranje() : void
+Selektovanje() : void Logičko kolo +Selektovanje() : void +Iscrtavanje() : void
+Pomeranje() : void

1 +Selektovanje() : void
Grafički objekat Poseduje ulaze/izlaze 1..*
#Tačka1 :TPoint
Linijski objekat Ulaz/izlaz
#Tačka2 :TPoint
#Selektovan? : bool
+Iscrtavanje() : void +Iscrtavanje() : void
#Pomera se? : bool
+Pomeranje() : void +Pomeranje() : void
+Iscrtavanje() : void
+Selektovanje() : void +Selektovanje() : void
+Pomeranje() : void 1
+Selektovanje() : void Veza
Početni objekat
1 0..*
Krajnji objekat
+Iscrtavanje() : void
0..1
+Pomeranje() : void
+Selektovanje() : void
 Vežbanja

• Definišite pojmove objekat,

objekat klasa i tip!
tip
• Koje vrste veza mogu biti definisane između
klasa?
klasa
• Izradite dijagram klasa koji opisuje statičku
strukturu Generičkog Grafičkog Editora.
Specifikacija i Modelovanje Softvera
Software Systems Modeling
Poglavlje 02. UML Specifikacija dizajna
softverskih sistema
Specifikacija i Modelovanje Softvera
Software Systems Modeling
Poglavlje 02.01 Dizajn softverskih sistema

Prof.dr Branko Perišić

perisic@uns.ac.rs
 Aspekti dizajna softverskih sistema - 1

•Linija razdvajanja ANALIZE i DIZAJNA softverskih

sistema, u opštem slučaju, nije jasno definisana.

•Termin dizajn ponekad na prvi pogled ima dvosmisleno

značenje. Ako ga posmatramo kao glagol (dizajnirati)
tada ga tumačimo kao kreativni proces transformacije
problema u rešenje. Ako ga posmatramo kao imenicu
(dizajn) tada ga tumačimo kao formalni opis rešenja.

•Kada je softver u pitanju dizajn se iskazuje

formalizmima implementacione hardversko/softverske
platforme.
 Aspekti dizajna softverskih sistema - 2
•Konceptualni (sistemski) dizajn– precizna
specifikacija iz koje korisnik nedvosmisleno i
jednoznačno dobija informaciju o tome šta će da radi
softver.
softver

•Tehnički dizajn – omogućava projektantima i

programerima razumevanje stvarno potrebnog hardvera i
softvera za rešavanje problema.
•Arhitektonski dizajn – bavi se izborom strategije
rešavanja i modularizacijom sistema.
•Detaljni dizajn – bavi se formulacijom detaljnih
algoritama i strukture podataka neophodne za
implementaciju modula .
 Arhitektonski dizajn - 1

Strategija – Distribuirana/Centralizovana arhitektura

1. Klijent/Serve arhitektura – omogućava
modeliranje svojstava proizvoljne distribuirane
arhitekture. (klient,server)
2. Troslojna arhitektura – (klient, aplikacioni sloj,
server) (BCE-Boundary-Control-Entity)
3. Agentska arhitektura – mobilni agenti
(JBeans)
 Arhitektonski dizajn - 2

Dekompozicija i modularnost
Karakteristika složenih sistema je postojanje
unutrašnje strukture do koje se dolazi
dekompozicijom.
• Karakteristika rešenja je postojanje jasno definisanih
celina (modula) koji kooperiraju u cilju implementacije
funkcija sistema.
 Arhitektonski dizajn - 3
1. Dekompozicija bazirana na modulima:
•U sklopu ovog pristupa konstrukcija se bazira na
alokaciju funkcija komponentama počevši od
najvišeg nivoa apstrakcije pa do elemantarne
(atomičke) funkcionalnosti.

2. Dekompozicija bazirana na podacima:

•U sklopu ovog pristupa dizajn se rukovodi
spoljašnjom strukturom podataka. Najviši nivo
apstrakcije obuhvata generalnu strukturu
podataka dok najniži nivoi opisuju elemente
podataka.
 Arhitektonski dizajn - 4
3.   Dekompozicija bazirana na događajima
U sklopu ovog pristupa akcenat se stavlja na događaje i
rukovanje događajima odnosno način na koji
događaju menjaju stanje sistema.
4. Dekompozicija bazirana na odnosu ULAZ/IZLAZ:
U sklopu ovog pristupa akcenat se stavlja na ulaze i
izlaze sistema (sistem se posmatra kao crna kutija).
5. Dekompozicija bazirana na objektima
U sklopu ovog pristupa akcenat se stavlja na objekte
sa kojima sistem radi, njihove apstrakcije (klase) i
veze među njima.
 Arhitektonski dizajn - 5
• Bez obzira na pristup bilo koja vrsta
dekompozicije razdvaja dizajn na delove koji se
obično nazivaju moduli ili komponente.
komponente
• Za sistem kažemo da je modularan ako se
svaka aktivnost u sistemu odvija uz podršku
samo jedne komponente sa jasno definisanim
ulazima i izlazima.
izlazima
• Za komponentu kažemo da je dobro definisana
ako i samo ako su svi njeni ulazi esencijalni sa
aspekta funkcionalnosti koju podržava a svi
njeni izlazi posledica neke od njenih (privatnih)
akcija.
 Karakteristike kvalitetnog dizajna

1. NEZAVISNOST KOMPONENTI (Component

Independency)
2. IDENTIFIKACIJA I RUKOVANJE
IZUZECIMA (exception identification and
handling)
3. OTPORNOST NA GREŠKE I RUKOVANJE
GREŠKAMA (Error handling)
4. SMANJENJE SLOŽENOSTI (Reduction of
complexity)
 Nezavisnost komponenti - 1
1. Snaga veza među modulima (COUPLING)

1.1. Nepovezani (uncoupled). – nizak nivo zavisnosti

1.2. Veza preko podataka (data coupling) – parametri.
Karakteristika odjektnog dizajna
1.3. Veza preko strukture podataka (stamp coupling).
NIZAK
1.4. VezaSTEPEN
preko kontrolaZAVISNOSTI
(control coupling) –MODULA.
parametri
(low coupling)
obezbeđuju prenos kontrole.
1.5. Veza preko zajedničkih elemenata (common coupling) –
globalne reference i/ili globalne vrednosti.
1.6. Veza preko sadržaja (content coupling) – jedna
komponenta modifikuje drugu. – visok nivo zavisnosti
 Nezavisnost komponenti - 2
2. Unutrašnja funkcionalna snaga modula (COHESION)
1.1. Funkcionalna (functional) – jedan modul jedna funkcija
1.2. Sekvencijalna kohezija (sequential) – jedan modul sadrži više
funkcija koje se sekvencijalno koriste tako što se izlaz iz jedne
prosleđuje na ulaz druge.
1.3. Komunikaciona (communication) – modul sadrži više
funkcija koje su povezane preko zajedničkog repozitorijuma
eksternog za modul.
1.4. Procedurna (procedural) – modul sadrži više funkcija koje se
moraju izvršiti u utvrđenom redosledu.
1.5. Temporalna (temporal) – modul sadrži više funkcija čije je
izvršenje vremenski povezano (t, t+dt,.....)
1.6. Logička (logical) – ima smisla da budu zajedno!
1.7. Koincidentna (coincidental) – slučajno su zajedno!
 Rukovanje izuzecima – exceptions 1
•Predstavlja jedan od ključnih elemenata kvalitetnog
dizajna jer stvara osnov za preventivno i korektivno
delovanje u slučaju pojave ‘’iznenadnih događaja’’.
•Formiranje potpunog skupa izuzetaka predstavlja
osnov za kvalitetno testiranje softverskog sistema.
Jedan od načina da se to postigne je IDENTIFIKACIJA
POZNATIH IZUZETAKA – situacija koje su u suprotnosti sa
onim što softver treba da radi i obogaćivanje dizajna
postupcima (metodama) za rukovanje izuzecima.
•Tipični primeri izuzetaka ove vrste su: oštećenje podataka
(corrupted data), nemogućnost pružanja servisa, pružanje
pogrešnog servisa, isporuka pogrešnih pojava strukture
podataka i sl.
 Rukovanje izuzecima - exceptions 2

Svaki od identifikovanih izuzetaka može da se opsluži

na jedan od tri načina:

•Ponovni pokušaj (Retrying) – prvobitno stanje se restaurira i

ponovi servis uz korišćenje druge strategije.
strategije
•Korekcija (Correction) - prvobitno stanje se restaurira, izvrši
se korekcija nekog od elemenata servisa i ponovi servis uz
korišćenje iste strategije.
•Izveštavanje o neuspehu (Reporting failure) - prvobitno
stanje se restaurira, izvesti se komponenta za rukovanje
greškama i servis se blokira.
blokira
Osnovni problem: IDENTIFIKACIJA/ ’’ HVATANJE ’’ IZUZETAKA
 Rukovanje greškama – errors - 1

•U fazi dizajna neophodno je anticipirati greške i rukovati

njima u cilju minimizacije vremena u kome softverski sistem
nije funkcionalan odnosna maksimiziranja sigurnosti. Greška
(fault) je uzrok – otkaz (failure) je obično njena posledica.
•Važno je shvatiti da svaka greška ne mora nužno biti
vezana za otkaz budući da se deo koda koji sadrži
grešku možda neće nekada izvršiti.
•Sa druge strane je moguće zamisliti situaciju u kojoj dolazi
do otkaza nakon koga je nemoguće ponoviti okolnosti u
kojima se on desio.
 Rukovanje greškama – errors - 2
• Prevencija grešaka (fault prevention) – dizajn uparen sa
testiranjem i verifikacijom
•Izbegavanje otkaza (failure avoidance) – nadzor i
sprečavanje pojave otkaza
•Detekcija grešaka (fault detection) – otkrivanje greške na
osnovu manifestacije otkaza
•Ispravka grešaka (fault correction) – uklanjanje grešaka,
oporavak od posledica otkaza, testiranje, verifikacija i
ponovno aktiviranje.
• Otpornost na greške (fault tolerance) – uklanjanje grešaka
je nekada skupo i rizično. Otpornost na greške
podrazumeva dizajniranje softvera tako da izoluje štetu
uzrokovanu otkazom, dinamički reorganizuje servise,
obezbedi oporavak ili redundantni servis i nastavi podršku
korisnicima.
 Smanjenje složenosti

SMANJENJE SLOŽENOSTI –
pojednostavljivanje strukture softverskog
sistema i strukture podataka do nivoa
potpune funkcionalnosti uz minimalnu
složenost.
Predstavlja izuzetan izazov za fazu
konstrukcije softvera u kojoj često dolazi do
‘’infiltriranja’’
infiltriranja i kumuliranja
neracionalnosti i neefikasnosti kao posljedica
ad-hok intervencija.
intervencija
 Objektni model softverskog sistema
LokalizacijaProizvoda PersonalizacijaProizvoda

- GetLocalParam () : int - GetProfile () : int

SoftverskiProizvod
{abstract}

+ Oznaka softverskog proizvoda : int

KonfiguracijaProizvoda
*
{abstract}
*
<<call>>
- GetConfig () : int
* ElementSoftverskogProizvoda
{abstract}

* RukovalacIzuzetcima
{abstract}
KompozicijaEementa <<call>>

RukovalacGreskama
<<call>> {abstract}
GUIelement
{abstract}
RepozitorijumElement

Polje Repozitorijum
{abstract}
PrimarniProzor <<Implementira>> + GetResultSet () : void
{abstract} + SaveResultSet () : void
Forma
{abstract}

Meni Tabela
{abstract} {abstract}

KomandnoDugme
{abstract}
Toolbar
{abstract}
PodlogaZaCrtanje
{abstract}
 Opšti ciljevi dizajna softverskih sistema - 1

1. Svaki dizajner želi kreirati interaktivni sistem

visokog kvaliteta kome se ‘’dive’’ njegove
kolege, koga korisnici ‘’glorifikuju’’, koji se
nezadrživo širi i biva često imitiran od strane
drugih dizajnera.

2. Zahvalnost korisnika nije posledica velikih

obećanja ili dobre reklame već isključivo nastaje
kao produkt iskustva u radu sa implementiranim
rešenjem.
 Opšti ciljevi dizajna softverskih sistema - 2

3. Kada je interaktivni sistem kvalitetno dizajniran

korisnički interfejs, kao posrednik između čoveka
i programa, nestaje omogućavajući korisniku da
se skoncentriše na posao koji radi.
 Esencijalni zahtevi prema softverskom sistemu

1. ISPRAVNO FUNKCIONISANJE Ako sistem ne

funkcioniše ispravno ostali elementi nisu bitni!

2. POUZDANOST, RASPOLOŽIVOST, BEZBEDNOST i

INTEGRITET
Ako sistem ne poseduje gornje osobine ostali elementi
nisu bitni!

3. STANDARDIZACIJA, INTEGRACIJA,
KONZISTENTNOST i PRENOSIVOST
Ako sistem ne poseduje gornje osobine ostali
elementi nisu bitni!

4. VREME ISPORUKE i TROŠKOVI

Ako sistem nije isporučen na vreme i u skladu sa
procenjenim troškovima ostali elementi nisu bitni!
 Principi izrade GUI aplikacija- 1

Izrada GUI aplikacija predstavlja

multidisciplinarnu aktivnost i podrazumeva
timski rad. Dobar GUI dizajn zahteva kombinaciju
veština koje posedije: umetnik-grafički dizajner,
sistem analitičar (analiza zahteva), sistem
dizajner (dizajn proizvoda kao celine), programer,
ekspert iz domena informacionih tehnologija
(uređaji i sredstva), sociolog, psiholog i ekspert
za domen primene (tehnolog procesa rada).
 Osnovni postulati kvalitetnog GUI-dizajna - 1

KORISNIČKA ORIJENTISANOST (user is in

1. control). Bitno je napomenuti da koncept
korisničke orijentisanosti ne podrazumeva da
aplikacija u celosti radi posao za korisnika
(''mama će sve da uradi samo ti sedi...''), već da
''podržava'' korisnika u obavljanju njegovog posla
kroz interaktivni mehanizam:
korisnička akcija (izbor stavke menia, klik miša,
pomeranje kursora i sl.)-
preuzimanje kontrole od strane aplikacije
(otvaranje GUI prozora ili dijaloga, poziv servisnog
programa(storred-procedure,4GL skript i sl.))-
povratna informacija (set podataka, poruka, slika,
animacija i sl.).
 Osnovni postulati kvalitetnog GUI-dizajna - 2

1.KONZISTENTNOST(consistency). Pod
2. konzistentnošću u ovom slučaju podrazumevamo
poštovanje standarda i uobičajenog načina na koji
korisnik obavlja ''posao''. Važno je da GUI dizajner nije
previše inventivan kada je korisnički interfejs u pitanju i
da striktno poštuje dva osnovna aspekta konzistentnosti
GUI aplikacija:
usklađenost sa GUI standardima isporučioca
(npr. Microsoft Windows 'look-and-feel' , Apple Macintosh
menu-standard i sl.)
• usklađenost sa konvencijama imenovanja,
označavanja i drugim GUI-elementima i standardima
interno razvijenim u sklopu organizacionog sistema
korisnika.
 Osnovni postulati kvalitetnog GUI-dizajna - 3

3. PERSONALIZACIJA i PODEŠAVANJE
(personalization and customization). Pod
personalizacijom se podrazumeva podešavanje
(customization) u skladu sa ličnim afinitetima
korisnika, dok se pod podešavanjem u opštem
smislu podrazumeva administrativna procedura ua
prilagođavanje softvera različitim grupama korisnika.
Personalizacija – reorganizacija kolona u sklopu
browser-a i sačuvavanje podešavanja u
personalnom profilu. Podešavanje – ''lagani (light)''
režim rada za početnike i ''full (potpuni)'' režim rada
za iskusne korisnike.
 Osnovni postulati kvalitetnog GUI-dizajna - 4

4. PODRŠKA EKSPERIMENTISANJU i OPORAVKU

(forgivenes principle). Kvalitetna GUI aplikacija treba
da omogući korisniku eksperimentisanje,
eksperimentisanje pravljenje
grešaka i oporavak od grešaka restauriranjem
''početne pozicije'‘ (roll-back and recovery). Ova
osobina podrazumeva implementaciju višenivovske
undo-funkcije (multilevel undo) kao standardnog
svojstva elementa softverskog sistema. Zavisno od
generičke oblasti primene ova osobina nekada nije
poželjna (npr. undo akcije uzimanja novca iz
bankomata nakon što je novac već preuzet ali bez
vraćanja novca u automat!).
 Osnovni postulati kvalitetnog GUI-dizajna - 5

5. POVRATNA INDIKACIJA (feedback). Da bi moga

ostati u upravljačkoj ulozi neophodno je da korisnik
tačno zna šta se dešava od trenutka kada se
kontrola privremeno prenese na pozvani servis
(program). Projektant mora u sastav aplikacije
ugraditi vizualne i/ili auditivne efekte koji
jednoznačno ilustruju aktivnost pozvanog servisa
(pešćani sat, indikator progresa i sl.). Nije
preporučljivo pretpostaviti da je vreme odgovora
pozvanog servisa toliko kratko da je povratna
indikacija nepotrebna.
 Osnovni postulati kvalitetnog GUI-dizajna - 6

6. ESTETSKI ASPEKTI i MOGUĆNOST KORIŠĆENJA

(aesthetics and usability).
Pod estetskim aspektom softverskog sistema
podrazumeva se vizualna pojava GUI aplikacije koja
podleže skupu ocenskih kriterijuma.
Pod mogućnošću korišćenja (usability) podrazumeva
se: lakoća, jednostavnost, efikasnost, pouzdanost i
produktivnost pri korišćenju softverskog sistema.
sistema
(Lepota je u jednostavnosti!)
(Lepota je u oku onoga koji posmatra!).
Specifikacija i Modelovanje Softvera
Software Systems Modeling
Poglavlje 02. 01. Dizajn softverskih sistema