Transcript METODE SISTEMSKE ANALIZE

Objektno-orijentisana
analiza i modelovanje
 Objektno-orijentisana analiza
 Objektno-orijentisano modelovanje
 Osnovni koncepti
 UML
 UML relacije
 Proces objektnog modelovanja
Beograd, 2004/2005.
Objektno-orijentisana analiza
• Objektno-orijentisana analiza - OOA (Object-Oriented
Analysis):
– eliminiše veštački razdvojene podatake od procesa,
– podaci i procesi su integrisani u objekte,
– podaci objekta (properties) se kreiraju, čitaju, ažuriraju, brišu
putem ugrađenih procesa ili metoda (methods).
• Programski jezici kao što su C++, Visual Basic, C#, Java i dr.
se baziraju na OOA
• OOA koristi se u mnogim profesijama i znači da se na problem
gleda preko objekata koji su uključeni u taj problem.
Primer: Kada projektuje kancelarije arhitekta razmišlja o radnim
prostorima, temeljima, konstrukciji i vodovodu. To su objekti iz
stvarnog sveta. Arhitekta ne razmišlja o procesu nalivanja
temelja betonom, zakucavanju eksera ili spajanju vodovodnih
cevi. To su procesi nižih nivoa koji imaju svoju važnost, ali se
ne uzimaju u obzir kod projektovanja poslovne zgrade.
17.7.2015
Poslovni informacioni sistemi
2
Proces OOA (UML)
• OOA zahteva da se identifikuju:
– objekti,
– atributi objekata,
– ponašanja objekata (metodi) i
– relacije objekata koji podržavaju poslovne zahteve sistema.
• Faze procesa OOA su sledeće:
– modelovanje funkcija poslovnog sistema
– modelovanje aktivnosti slučajeva korišćenja upotrebom
dijagrama aktivnosti
– pronalaženje i identifikovanje poslovnih objekata
– organizovanje objekata i identifikovanje njihovih relacija
17.7.2015
Poslovni informacioni sistemi
3
Objektno orijentisano modelovanje
• Proveren metod smanjivanja kompleksnosti PIS
• Primenjuje princip dekompozicije strukture PIS
• Kompleksni sistem se dekomponuje u manji broj relativno
nezavisnih objekata sa minimalnim brojem međusobnih veza u
sukcesivnim fazama dekompozicije
• Svi objekti su istovremeno aktivni i po potrebi izazivaju načine
(metode) ponašanja jedan drugoga
• Ponašanje sistema opisuje se terminima interakcija objekata
• Detalji tih ponašanja su skriveni (enkapsulirani)
• Povezivanje objekata dostupno je samo interfejsu
17.7.2015
Poslovni informacioni sistemi
4
OOM -Koncept klasifikacije objekata
– Međusobnu isključivost – sprečava preklapanja,
– Potpunost – unija svih kategorija obuhvata sve
moguće klasifikacije
– Nedvosmislenost – svaka klasifikacija mora biti
jasna i precizna
– Ponovljivost – svaki proces klasifikacije mora biti
ponovljiv i davati isti rezultat
– Prihvatljivost – svaka klasifikacija mora biti logična
i intuitivna
– Primenljivost – klasifikacija mora biti primenljiva u
različitim sferama istraživanja
17.7.2015
Poslovni informacioni sistemi
5
Objektno-orijentisana analiza i modelovanje
- Koncept klase • Klasa:
– apstrakcija skupa stvarnih karakteristika realnog
objekta, objedinjenih jednakom opštom
strukturom i ponašanjem.
– skup objekata koji dele zajedničke atribute i
ponašanja.
• Ljudi rado klasifikuju stvari, da bi našli sličnosti među
njima i prema tome ih grupisali.
• Stvari sa sličnim svojstvima i ponašanjima grupišu se
zajedno prema pravilima (kriterijumima) klasifikacije.
Primer:
Klasa „Student“ označava opšti pojam studenata
sa jednakim opštim podacima i metodama ponašanja
17.7.2015
Poslovni informacioni sistemi
6
Objektno-orijentisana analiza i modelovanje
-Koncept objekta• Objekat:
– elemenat klase, tj. apstrakcija određene stvarnosti;
– aktivni elementi sa unutrašnjom strukturom i načinom ponašanja
(metodom)
– objekat koji pripada klasi naziva se primerak ili instanca (instance)
klase
– svaki objekat koji je instanca klase ima atribute i ponašanja definisana
u klasi
Primer: Objekat „Student Petar Petrović“ sa odgovarajućim
konkretnim podacima i moguće posebnim načinom ponašanja je
instanca klase Student.
• Objekti mogu biti:
– stvari, ljudi, događaji, sistemi, strukture ili uređaji.
• Efektivan metod za identifikovanje objekata:
– proučiti scenariji upotrebe i identifikovati imenice i pridružene
glagole koji će se prevesti u objekte i pridružena ponašanja.
Primer: Zaposleni kreira ugovor sa klijentom. Mogu se identifikovati
sledeći poslovni objekti: zaposleni, ugovor i klijent.
17.7.2015
Poslovni informacioni sistemi
7
Objektno-orijentisana analiza i modelovanje
-Koncept atributa objekta• Atributi:
– su svojstva jednog objekta definisana
vrednostima koje objekat poseduje.
– da bi se identifikovali atributi objekta, treba
razmotriti prideve ili imenice (koje nisu postali
objekti) unutar scenarija upotrebe.
– svaka instanca objekta sadrži sopstveni set
vrednosti.
Primer:
Objekat Klijent sadrži atribute broj računa, naziv i
adresu sa konkretnim vrednostima npr.
1007, ComTrade, Savski nasip 7.
17.7.2015
Poslovni informacioni sistemi
8
Objektno-orijentisana analiza i modelovanje
-Koncept ponašanja objekta• Ponašanja (behaviors):
–
–
–
–
aktivnosti koje objekat izvršava,
implementiraju poslovna pravila,
obrađuju podatke i pristupaju informacijama,
odnose se na operacije, funkcije ili transformacije koje izvršava
objekat,
– dodeljuju se odgovarajućim objektima,
• Servisi (methods):
– servisi su specifična ponašanja koje poslovni objekat mora da izv
Primer: Vrata se mogu otvarati, zatvarati, zaključavati ili otključavati.
Porudžbina se može modifikovati, obrisati, dodati itd.
• Da bi se uočile neopohodne funkcionalnosti ponašanja treba:
– identifikovati akcije koje objekat mora da izvršava u scenarijima
upotrebe.
– analizira ti šta objekat mora da radi i koje podatke mora da održava.
Primeri akcija: izračunavanje ukupnih iznosa, određivanje troškova
transporta. Poslovni informacioni sistemi
17.7.2015
9
Objektno-orijentisana analiza i modelovanje
-Koncept enkapsulacije • Enkapsulacija (encapsulation):
– osnovni instrument smanjenja kompleksnosti sistema,
– podrazumeva skraćivanje unutrašnje strukture objekta, detalja
realizacije i načina ponašanja (metoda),
– objekat ne mora da otkriva sve svoje atribute i ponašanja,
– smanjuje složenost realizacije, održavajući vidljivim samo značajne
interfejse na datom nivou apstrakcije.
• Primer: objekat kalkulator koji izračunava kvadrat nekog broja
ima interfejs za rezultat, ali ne pokazuje algoritm proračuna
• Svaki atribut ili metod unutar neke klase može biti:
– Javni (public) - označava da su atribut ili metod vidljivi za sve klase u
programu (označava se sa „+“);
– Privatni (private) – atribut ili metod su vidljivi samo unutar svoje klase
(označava se sa „-“);
– Zaštićeni (protected) – atribut ili metod su vidljivi samo za klase
naslednice (oznaka “#”);
17.7.2015
Poslovni informacioni sistemi
10
Objektno-orijentisana analiza i modelovanje
-Koncept nasleđivanja • Nasleđivanje (inheritance) - klasifikacija odozgo nadole:
– jedan objekat nasleđuje svojstva drugog objekta,
– omogućava formiranje nove klase O na bazi postojeće,
– ne narušava integritet složenog objekta,
– smanjuje multiplikativne elemenate realnog sistema,
– opšta informacija se ne duplira,
– samo ukazuje na postojeće promene,
– klasa-potomak postaje koren nove klase-naslednika,
– za objekat - naslednika treba definisati samo karakteristike
koje ga čine jedinstvenim u klasi (opšta svojstva nasleđuje od
roditelja)
– omogućuje da jedan objekat bude poseban slučaj nekog
opštijeg objekta.
17.7.2015
Poslovni informacioni sistemi
11
Objektno-orijentisana analiza i modelovanje
-Koncept polimorfizam • Polimorfizam (polymorphism):
– svojstvo objekta da se svrsta u više od jedne
klase,
– često seobjašnjava frazom "jedan način pristupa,
više metoda“,
– omogućava grupisanje objekata sa sličnim
karakteristikama,
– podrazumeva opšti načina pristupa za rad sa
grupom srodnih aktivnosti.
– omogućava da opšta klasa definiše metode
zajedničke za sve izvedene klase,
• Nasleđivanje i polimorfizam omogućavaju
modularnost i skalabilnost objekata.
17.7.2015
Poslovni informacioni sistemi
12
Objektno-orijentisana analiza i modelovanje
-Koncept grane objekta• Relativno nezavisne karakteristike realnih objekata
• U OOM objekta takve se karakteristike nazivaju grane objekta.
• Omogućavaju raznolikost aspekata posmatranja i apstrakcije
objekata bolje od polimorfizma.
Primer:
– grane objekata zaštite IS: raspoloživost, integritet i
poverljivost informacija.
– grane objekata sistema zaštite: upravljačke, organizacione
i tehničke kontrole zaštite
– obe grane objekata razmatraju se sa različitim nivoima
detalja.
17.7.2015
Poslovni informacioni sistemi
13
UML - prikupljanje i
analiziranje informacija





17.7.2015
Upotreba notacija modeliranja
UML modelovanje
Kreiranje slučajeva korišćenja (use cases) i
scenarija korišćenja (usage scenarios)
Prikupljanje informacija
Analiziranje informacija
Poslovni informacioni sistemi
14
Koristi od modeliranja
• Modeliranje može pojasniti prezentaciju složenih
problema.
• Modeliranje trenutnog stanja identifikuje:
– zahteve
– probleme i rizike
– izgubljene informacije
• Dve najčešće korišćene notacije su:
– Unified Modeling Language (UML) i
– Object Role Modeling (ORM).
17.7.2015
Poslovni informacioni sistemi
15
Objedinjeni jezik modelovanja - UML
• OOA i modelovanje naročito su postali popularni
pojavom UML (Unified Modeling Language) jezika
• UML obezbeđuje i grafičku sintaksu za objektne
modele i ima razvijen CASE alat Rationale Rose.
• UML definiše više različitih tipova dijagrama koji
zajedno modeluju jedan IS, ili aplikaciju.
• UML dijagrami se koriste za sveobuhvatno
prikazivanje funkcionalnosti organizacije u celini.
• Koriste se za modelovanje poslovnih procesa.
• Svaki dijagram ima svoju svrhu i ciljnu grupu.
• NEDOSTATAK.
– nedostaje SA u prvom koraku
17.7.2015
Poslovni informacioni sistemi
16
Šta je UML?
• UML je jezik za vizuelizaciju i
modeliranje softverskih sistema.
• UML se može koristiti za:
– kreiranje specifikacija
– izgradnju modela
– dokumentovanje modela
17.7.2015
Poslovni informacioni sistemi
17
UML dijagrami
• Svaki tip dijagrama pokazuje različite poglede:
– dijagram klasa (Class) – opisuje različite klase i njihova
spajanja (associations).
– objektni dijagram (Object) – opisuje raziličite objekte u
sistemu i njihove međusobne veze.
– dijagram slučajeva korišćenja (Use case) – prikazuje
željenu funkcionalnost sistema.
– dijagram komponenti (Component) – prikazuje
implementacioni pogled na sistem odnosno prikazuje
različite komponente sistema i njihove veze (npr. source
code, object code i execution code).
– dijagram implementacije (Deployment) – predstavlja
spajanje softverskih komponenti sa čvorovima fizičke
implementacije sistema.
17.7.2015
Poslovni informacioni sistemi
18
UML dijagrami
– dijagram saradnje (Collaboration) – predstavlja skup klasa i
njihovih poslatih i prijemnih poruka.
– dijagram sekvenci (Sequence) – opisuje interakciju između
klasa koja predstavlja redosled poruka koje se razmenjuju
između klasa.
– dijagram stanja (State) – je algoritam različitih stanja jednog
objekta koji se događaju pri uticaju različitih spoljnih događaja.
– dijagram aktivnosti (Activity) – predstavlja drugi način
pogleda na stanje i uključuje i sekvence aktivnosti; pogodan
kod modeliranja konkurentnih procesa, da se vidi
neophodna sinhronizacija između klasa i zadataka.
17.7.2015
Poslovni informacioni sistemi
19
ORM (Object Role Modeling)
• ORM koristi prirodan jezik i intuitivne dijagrame.
• ORM je metodologija za modeliranje podataka koji
se odnose na poslovne zahteve.
• ORM se koristi za dokumentovanje poslovnih
pravila i projektovanje baza podataka, a finalni
rezultat je model baze podataka.
• Informacije se predstavljaju kao elementarne činjenice
koje pokazuju da objekti imaju neka svojstva ili da su
jedan ili više objekata u vezi.
17.7.2015
Poslovni informacioni sistemi
20
Kako identifikovati zahteve?
• Kreirati listu zahteva tokom procesa prikupljanja informacija i
identifikovati izvor odakle je zahtev došao.
• Zahtevi moraju da budu kratke (ostvarljive) rečenice.
• Proširiti listu zahteva
– preispitati sve prikupljene informacije
– pronaći zahteve
• Zahteve odvojiti od želja
• Prepoznati ograničenja i pretpostavke
– Ograničenje je fiksni limit, kao npr. budžet
– Razjasniti pretpostavke da bi izbegli nesporazume
• Identifikovati skrivene zahteve
– npr., zakonske regulative koje se menjaju
17.7.2015
Poslovni informacioni sistemi
21
Primer: Uplata telefonskog računa
• Preduslovi
– ako nema struje transakcija neće moći da se izvrši
• Posledice izvršenja scenarija upotrebe
– evidencija plaćenog računa
• Razbijanje na pojedinačne poslove
– službenik vrši naplatu telefonskog računa
• Izuzetak – skretanje na drugi scenario upotrebe ili
obaranje transakcije
– ukoliko nema dovoljno novca za plaćanje, onda
prelazimo na drugi scenariio upotrebe .
17.7.2015
Poslovni informacioni sistemi
22
Prikupljanje informacija
• Kategorije informacija:
– Poslovne – opisuje kako se radi posao, funkcije i unakrsne
funkcije koje posao obavlja, primarne ciljeve, proizvode i
usluge, finansije, organizacionu strukturu.
– Aplikacije – automatizovane i neautomatizovane usluge
koje podržavaju poslovne procese - gotove aplikacije,
komponente, dostupne izvorne kodove
– Operacije – informacije koje su neophodne da bi se
pokrenuo poslovni proces.
– Tehnologije – tehničke usluge neophodne za izvršenje i
podršku poslovne misije -topologije, razvojna okruženja,
bezbednost, usluge mreže, DBMS, tehničke
specifikacije, operativne sisteme, hardvere i dr.
17.7.2015
Poslovni informacioni sistemi
23
Tehnike za prikupljanje informacija
Tehnike
Opis
Praćenje
(shadowing)
Direktno posmatranje kako pojedinac obavlja svoj posao kako bi se
uvidela praksa i problemi.
Intervjui
Prikupljanje određenih informacija od pojedinaca. Nedostatak je što oni
daju svoje viđenje posla i problema i ukoliko nije ekspert u domenu koji
proučavamo.
Fokus grupe
Sa većom grupom se radi intervju kako bi se dobila prečišćena
informacija, otkrila ponašanja i deljena mišljenja.
Istraživanja
Prikupljanje detaljnih i statističkih podataka.
Instrukcije korisnika Radi se njegov posao. Krajnji korisnik vas podučava kako oni rade sa
sistemom.
Pravljenje prototipa
Simulirati sistem koji nije moguće testirati direktno. Pravi se prototip koji
se usavršava.
Instrumentalizovane
verzije
Koriste se metode praćenja da bi se snimilo kako korisnik izvršava
zadatke.
17.7.2015
Poslovni informacioni sistemi
24
Analiziranje informacija
• Prikupiti dovoljno informacija,
• Filtrirati informacije relevantne za poslovanje,
• Verifikovati da li postoji dovoljno informacija koje
govore o poslovnim zahtevima i zahtevima za
rešenjem:
– Potrebe zaštite informacija
– Podrška za rešenja i njihove karakteristike
– Planirane promene u poslovanju koje mogu da
utiču na projektovano rešenje
– Performanse koje korisnici očekuju ili koje su
neophodne da bi se održala konkurentnost
– Integracija postojećih aplikacija sa novim
rešenjem
17.7.2015
Poslovni informacioni sistemi
25
Početak dokumentovanja zahteva
• Već tokom intervjua napisati listu potencijalnih zahteva
– Odvojiti zahteve od želja i napraviti
– Grubi dokument (draft) o zahtevima izvučenim iz intervjua i
use case dijagrama
Orig
ID
Opis zahteva
1
Can synchronize with our online applications
to record all the information collected
throughout the day
Territory sales
manager
2
Retrieve the customer data and allow us to
view the data in various ways
Territory sales
manager
3
Prioriteti?
Find out who my best customers are
Y
Izvor
Pitanja
Territory sales
manager
Na sledećim slajdovima se prikazuje:
•inicijalni use case dijagram koji predstavlja početno stanje i analizu
tekućeg stanja sistema i
•revidirani use case dijagram procesa u sistemu posle reinženjeringa
17.7.2015
Poslovni informacioni sistemi
26
17.7.2015
Poslovni informacioni sistemi
27
17.7.2015
Poslovni informacioni sistemi
28
Interna dokumentacija projektnog tima
Dokumentacija
Identifikuje
Upotreba
Katalog učesnika
(actors catalog)
Svakog učesnika po imenu
Lista odgovornosti za svakog učesnika i
ukazivanje na daljne informacije
Katalog poslovnih
pravila
(business rules
catalog)
Svako poslovno pravilo po
ID broju, nazivu, opisu i
autoritetu
Opisuje trenutne funkcionalnosti
Rečnik
(glossary)
Terminologija i definicije
koje koriste različiti
stakeholders-i, poslovni
procesi i projektni termini
Osigurava se konzistencija iste
terminologije radi jasnijeg
sporazumevanja
17.7.2015
Poslovni informacioni sistemi
29
Objedinjeni jezik modelovanja - UML
• Dijagram slučajeva upotrebe (use case)
poslovnog procesa:
– Koriste se za modelovanje poslovnog
procesa.
– Prikazuju opštu funkcionalnost sistema.
– Ukazuje na poslove koje organizacija obavlja.
– Reprezentuju procese u toku posla
– Akteri posla predstavljaju uloge u interakciji.
– Ne vode računa o automatskim procesima.
17.7.2015
Poslovni informacioni sistemi
30
Objedinjeni jezik modelovanja - UML
• Dijagrami slučajeva upotrebe:
– Opisuju učesnike (actor), objekte (objects) i akcije (actions)
koji dostižu ciljeve u sistemu
– Prikazuju interakciju slučajeva upotrebe i aktera.
– Strelica od slučaja upotrebe prema akteru ukazuje da
akter funkcionalno zavisi od slučaja upotrebe (dobija neku
informaciju).
– Predstavljaju funkcionalnosti poslovnih
procesa/sistema sa perspektive korisnika.
– Obezbeđuju specifikaciju zahteva.
– Identifikuju:
• granice sistema
• sekvencu zadataka i hijerarhije
17.7.2015
Poslovni informacioni sistemi
31
Kako izvući use case-ove
• Pronaći zadatak analizirajući izvore informacija
Izvod iz intervjua: “Da bi identifikovali naše
najbolje kupce i razloge zbog čega su oni najbolji,
prodajno osoblje treba da pronađe način da
pristupi i analizira naše podatke o prodaji”
• Da se napravi use case dijagram, treba identifikovati sledeće:
– sistem
– učesnike – entitet koji je u interakciji sa sistemom - korisnici
sistema ili neki drugi sistem ili BP koja je smeštena van
sistema.
– veze između učesnika i sistema – samo bitne za
poslovanje
– granice sistema
17.7.2015
Poslovni informacioni sistemi
32
Kako izvući use case-ove
• Za svaki zadatak
odrediti:
– Actor - Ko
izvršava akciju
– Akciju
– Objekat akcije
Primer:
• Prodavac pravi
porudžbinu
• Menadžer
prodaje
odobrava veći
popust
17.7.2015
Actor
Action
Object
Prodajno osoblje
pristupa
podacima o prodaji
prodajno osoblje
analizira
podatke o prodaji
prodajno osoblje
identifikuje
najbolje klijente
Poslovni informacioni sistemi
33
Use case iskazi u spreadsheet-
17.7.2015
Poslovni informacioni sistemi
34
Primer: UML use-case dijagram
• UML
dijagram
koji
predstavlja
prethodne
use case
iskaze
17.7.2015
Poslovni informacioni sistemi
35
Šta su scenarija upotrebe (Usage Scenarios)?
• Usage scenarios opisuje šta use case radi:
– use case:
• opisuju visok nivo interakcije između jednog učesnika
i sistema,
• jedan use case obično zahteva nekoliko scenarija kako
bi se detaljno opisao
– scenarija upotrebe:
• obezbeđuju dodatne informacije o sekvencama
aktivnosti od kojih se sastoji jedan proces.
• dokumentuju sekvence zadataka.
• opisuju izuzetke:
– atipične događaje ili alternativne sekvence zadataka.
17.7.2015
Poslovni informacioni sistemi
36
Kako se kreiraju scenariji upotrebe
1. Odrediti preduslove
– neophodne da bi se krenulo u izvršenje scenarija upotrebe
2. Identifikovati posledice uspešno obavljene akcije
3. Razbiti aktivnosti na korake
■ svakog pojedinačnog posla, kako bi posao bio obavljen
4. Identifikovati izuzetke koji se mogu dogoditi na svakom
koraku.
– može biti neophodno da se naprave scenariji upotrebe za
ove izuzetke
5. Identifikovati zahteve na koje scenariji upotrebe ukazuju
6. Identifikovati izvor za scenarija upotrebe na koja se use case
odnosi
17.7.2015
Poslovni informacioni sistemi
37
Zašto kreirati scenario upotrebe trenutnog stanja?
• Trenutno stanje scenarija upotrebe opisuje kako se
poslovne aktivnosti trenutno odvijaju odnosno
kako trenutno proces izgleda.
• Buduće stanje scenarija upotrebe predstavlja željene
buduće aktivnosti odnosno kako bi scenario
upotrebe trebao da izgleda.
• Trenutno stanje scenarija upotrebe pomaže da:
– idetifikujete probleme u sistemu
– odredite ciljeve
– otkrijete nepodudarnosti između percepcije
trenutnog problema i stvarnog problema
17.7.2015
Poslovni informacioni sistemi
38
Objedinjeni jezik modelovanja - UML

Dijagram aktivnosti:
– Prikazuje tok funkcionalnosti u sistemu.
– U modelovanju procesa prikazuju tok samog procesa.
– Definiše gde počinje tok procesa, gde završava i koje se
aktivnosti i u kom redosledu izvršavaju.

Grafički simboli:
–
–
–
–
–
–
Akter:
Aktivnost =
Objekat=
Odluka =
Tok objekta =
Prelaz, odvajanje aktivnosti = |
17.7.2015
Poslovni informacioni sistemi
39
Objedinjeni jezik modelovanja - UML
• Dijagram sekvenci prikazuje:
– funkcionalni tok procesa kroz slučaj upotrebe.
– objekte, a ne klase.
– tok obrade za jedan slučaj upotrebe.
– interakciju objekata i aktera kroz vreme.
• Dijagram saradnje prikazuje:
– interakciju objekata i aktera bez obzira na vreme.
– distribuciju procesa između objekata
– specifikaciju dinamike sistema
– sličan dijagramu sekvenci, ali sa drugačijim pogledom.
17.7.2015
Poslovni informacioni sistemi
40
Objedinjeni jezik modelovanja - UML
• Dijagram klasa (opštih objekata):
– Prikazuje interakciju između klasa koje postoje u sistemu.
– Kreira se za svaku klasu objekta u dijagramu
sekvenci/saradnje.
– Klasa je apstrakcija objekata
(npr., RAČUN – klasa, MILANOV RAČUN - objekat)
• Naziv klase
• Atributi klase
Račun
Broj računa
PIN
Saldo
Otvoren
Povlačenje fonda
Oduzimanje fonda
Verifikacija fonda
• Operacije nad atributima klase
17.7.2015
Poslovni informacioni sistemi
41
Objedinjeni jezik modelovanja - UML
• Dijagram stanja:
– prikazuje različita stanja u kojima se može naći
objekat
– modeluje dinamiku sistema,
– najčešće se kreiraju za veoma složene klase,
– prikazuje ponašanja objekata,
– prelazak objekata iz jednog i drugog stanja
naziva se događaj,
– postoje dva specijalna stanja:
• stanje početka:
• stanje završetka:
17.7.2015
Poslovni informacioni sistemi
42
Objedinjeni jezik modelovanja - UML
• Dijagram komponenti:
– predstavlja fizički pogled na model,
softverske komponente u sistemu i veze
između njih
– pokazuju mapiranje klasa i
implementacione komponente
– za neki sistem može da postoji više
dijagrama komponenti
– može imati dve vrste komponenti:
• izvršne komponente,
• biblioteke programskog koda
17.7.2015
Poslovni informacioni sistemi
43
Objedinjeni jezik modelovanja - UML
• Dijagram razmeštaja:
– prikazuje fizički izgled mreže,
– prikazuje mesta na kojima će se smestiti
komponente
– prikazuje fizička podešavanja sistema
– koriste ga projektanti sistema arhitekti, korisnici i
bilderi sistema da bi razumeli fizički izgled sistema
– svi UML dijagrami zajedno opisuju sistem iz
različitih pogleda na sistem
– svi dijagrami se mogu koristiti i kreirati sa Rational
Rose alatom
17.7.2015
Poslovni informacioni sistemi
44
Primer: UML notacija
17.7.2015
Poslovni informacioni sistemi
45
UML- relacije
Klasa
- Atribut
+ Operacija ()
• Relacije (veze) povezuju objekte, ili klase.
• Relacija zavisnosti:
– promena na jednom objektu utiče na ponašanje drugog
objekta.
– koristi se da pokažemo da jedan objekat koristi drugi.
–
Proizvod
-Težina
-Visina
-Širina
-Dubina
-Boja
Katalog proizvoda
-SkupProizvoda
+DodajNoviProizvod(Proizvod p)()
• UML definiše četiri tipa relacija zavisnosti:
– asocijacije (agregacije i kompozicije),
– multiplikativnosti,
– generalizacije,
– realizacije
17.7.2015
Poslovni informacioni sistemi
46
• Asocijacija: Relacija asocijacije
– pokazuje kada su dve klase konceptualno vezane
– na UML dijagramu predstavlja se punom linijom između dve
klase, sa nazivom asocijacije na vrhu.
Proizvod
-Visina
-Težina
-Širina
-Dubina
-Boja
-OrganizovaniPo
Kategorija
-Organizuje
-KategorijaID
-NazivKategorije
*
*
– postaje kompleksnija uključivanjem više od dve klase u
relaciju
– ponekad veza između dve klase mora biti ispraćena nekim
pravilom - ograničenjem pored linije veze klasa
• Multiplikativnost (višestrukost): specijalan vid asocijacije
– pokazuje broj objekata jedne klase u relaciji sa određenim
brojem elemenata u drugoj klasi
Račun
Klijent
17.7.2015
*
*
Poslovni informacioni sistemi
Super market
47
Kupuje od
Relacija agregacije
• Postoje dva tipa asocijacije: agregacija i kompozicija.
• Agregacija predstavlja vezu između celine i njenih delova.
Primer: Osoba (B) je zaposlena u Kompaniji (A). Agregacija je veza
između dva jaka objekta, gde će objekat B koji je dinamički atribut objekta A
ostati vidljiv i kada objekat A prestane da postoji.
• Agregacija je predstavljena punom linijom sa praznim rombom
na kraju linije koja se povezuje sa celinom:
Kompanija
1
- Osoba može da postoji i da nije
član kompanije.
- Objekat Kompanija ne upravlja
životnim vekom objekta Osoba.
1..*
Osoba
17.7.2015
Poslovni informacioni sistemi
48
Relacija kompozicije
• Kompozicija je veza u kojoj celina upravlja životnim vekom
delova:
– odgovara vezi jakog i slabog objekta u modelu objekti veze
(MOV)
Primer: Objekat B koji je statički atribut objekta A je vidljiv sve
dok objekat A postoji, jer je B egzistencijalno zavistan od A.
• Kompozicija je predstavljena punom linijom sa popunjenim
rombom na kraju linije koja je povezana sa celinom.
Porudžbina
1
0..*
- Poručeni proizvodi ne mogu da
egzistiraju bez postojeće porudžbine.
- Objekat Porudžbina upravlja životnim
vekom objekta PoručeniProizvodi.
PoručeniProizvodi
17.7.2015
Poslovni informacioni sistemi
49
Relacija generalizacije
• Generalizacija je relacija između opštijeg tipa (roditelja) i
određenijih tipova (dete).
• Generalizacija Prikazuje se
koja ukazuje na
roditelja.
Klijent
Prodavac
Kupac
Relacija realizacije


Realizacija - relacija između klasa, gde jedna apstraktna klasa
određuje zadatke koje druga klasa mora da izvrši
predstavlja se
usmerenom na roditelja.
Organizacija
Udruženje
+KreirajRačun()
+ObrišiRačun()
+AžurirajRačun()
17.7.2015
Poslovni informacioni
-Naziv
-Adresa
-Telefon
-Kontakt
-Status
-Komentari
sistemi
+DodajKontakt()
+AžurirajKontakt()
+ObrišiKontakt()
50
Primer:
Dijagram klasa
17.7.2015
Poslovni informacioni sistemi
51
Zaključci
• Objektno-orijentisan pristup koristi se u mnogim profesijama i u
osnovi znači da se na problem gleda preko objekata sistema, njihovih
međudejstava i odnosa sa okruženjem.
• Objektno-orijentisana analiza (OOA) je tehnika koja eliminiše
veštačko razdvojanje podataka (properties) i procesa (methods) koji
su kreirali, čitali, ažurirali i brisali te podatke i posmatra ih integrisane
u objekte sistema.
• Proces OOA sadrži faze modelovanja funkcija sistema, modelovanje
aktivnosti slučajeva korišćenja upotrebom dijagrama aktivnosti,
pronalaženja i identifikovanje poslovnih objekata, organizovanje
objekata i identifikovanje njihovih relacija, a zahteva da se identifikuju
objekti, atributi objekata, ponašanja objekata i relacije objekata koji
podržavaju zadate poslovne zahteve sistema.
• OOM je proveren metod smanjivanja kompleksnosti savremenih IS,
gde su svi objekti aktivni i po potrebi izazivaju načine (metode)
međusobnog ponašanja, čiji su detalji skriveni (enkapsulirani) i
primenjuje princip dekompozicije strukture IKT sistema u manji broj
relativno nezavisnih objekata sa minimalnim brojem međusobnih
veza.
Zaključci (1)
• OOM uključuje sledeće kategorije:
–
–
–
–
–
–
–
–
Klase
Objekte
Atribute
Ponašanja (behaviors), ili servise (methods-specifična ponašanja koje poslovni objekat
mora da izvršava)
Enkapsulaciju (encapsulation) osnovni instrument smanjenja kompleksnosti sistema
Nasleđivanje (inheritance)
Polimorfizam koncept "jednog načina pristupa, više metoda“
Grane objekta
• UML definiše više različitih tipova dijagrama koji zajedno modeluju jedan IS,
ili aplikaciju za sve obuhvatno prikazivanje funkcionalnosti organizacije u
celini. Obezbeđuje i grafičku sintaksu za objektne modele i ima razvijen
CASE alat Rationale Rose.
• Dijagram slučajeva upotrebe poslovnog procesa prikazuje opštu
funkcionalnost sistema, a koriste se za modelovanje poslovnog procesa.
• Dijagrama slučajeva upotrebe prikazuje interakciju slučajeva upotrebe i
aktera i predstavlja funkcionalnosti sistema sa perspektive korisnika.
• Dijagram aktivnosti prikazuje tok funkcionalnosti u sistemu, a u
modelovanju procesa tok samog procesa i definiše gde počinje tok procesa,
gde završava i koje se aktivnosti i u kom redosledu izvršavaju.
Zaključci (2)
• Dijagram sekvenci prikazuje funkcionalni tok procesa kroz
slučaj upotrebe, objekte a ne klase, tok obrade za jedan slučaj
upotrebe i interakciju objekata i aktera kroz vreme
• Dijagram saradnje sličan dijagramu sekvenci, ali sa drugačijim
pogledom, prikazuje interakciju objekata i aktera bez obzira na
vreme i distribuciju procesa između objekata i specifikaciju
dinamike sistema.
• Dijagram klasa prikazuje interakciju između klasa koje postoje
u sistemu.
• Dijagram stanja koristi se da prikaže različita stanja u kojima
se može naći neki objekat i za modelovanje dinamike sistema,
a najčešće se kriraju za veoma složene klase.
• Dijagram komponenti predstavljaju fizički pogled na model, na
softverske komponente u sistemu i veze između njih. Pokazuju
mapiranje klasa i implementacione komponente.
• Dijagram razmeštaja prikazuje fizički izgled mreže, kao i
mesta na kojima će se smestiti komponente.