Modelovanje Aplikacije Koriscenjem UML

1

Modelovanje aplikacije korišćenjem UML-a

2

Objektno modelovanje - UML

UML (Unified Modeling Language) - objedinjeni vizuelni jezik za

poslovno i softversko modelovanje u svim fazama razvoja i za sve

tipove sistema, kao i za generalno modelovanje kojim se definišu

statičke strukture i dinamičko ponašanje.

Standardni jezik za:

vizuelizaciju

specifikaciju

konstruisanje i

dokumentovanje softverskih sistema

UML kombinuje najbolje iz:

Koncepta “Data Modeling” (Entity Relationships Diagrams)

Poslovnog modelovanja (work flow)

Objektnog i komponentnog modelovanja

3

UML

UML je projektovan kao vrlo fleksibilan i prilagodiv jezik, koji

omogućava vrlo različite vrste modelovanja, uključujući:

modele koji olakšavaju razumevanje poslovnih procesa,

odvijanja tokova događaja,

sekvenci upita,

aplikacija,

baza podataka,

arhitektura i drugog.

4

UML

UML je nastao kao rezultat evolucije objektno orijentisanih jezika za modelovanje.

Razvila ga je kompanija Rational Software objedinjavanjem tri vodeće metode objektno orijentisanog modelovanja:

Booch koji je razvio Grady Booch,

OMT (Object Modeling Technique) koji je razvio Jim Rambaugh i

OOSE (Object-Oriented Software Engineering) koji je razvio Ivar Jacobson.

5

Arhitektura softverskih sistema

Kako je sistem

struktuiran?

Koje su funkcije

sistema? Kako izgraditi

sistem?

Gde instalirati?

Kako je sistem

predstavljen?

Kako se sistem

ponaša?

6

Kategorije korisnika

UML koriste sledeće kategorije korisnika:

Sistem analitičari i krajnji korisnici – specifikacija

zahtevane strukture i ponašanje sistema

Arhitekte sistema – projektanti sistema koji će

zadovoljiti zahteve

Razvojni inženjeri (developers) – transformišu

arhitekturu u izvršni kod

Kontrolori kvaliteta – provera strukture i ponašanje

sistema

Rukovodioci projekta (menagers) – vode i usmeravaju

kadrove i resurse

7

UML dijagrami

Dijagram u UML-u – grafička predstava skupa elemenata - iscrtan kao graf čvorova (stvari) i lukova (relacija)

Dijagrami UML-a prikazuju sistem iz više uglova:

Dijagram slučajeva upotrebe (Use-Case Diagram)

Dijagram klasa (Class Diagram)

Dijagram objekata (Object Diagram)

Dijagram sekvenci (Sequence Diagram)

Dijagram saradnje (Collaboration Diagram)

Dijagram promene stanja (State Diagram)

Dijagram aktivnosti (Activity Diagram)

Dijagram komponenti (Component Diagram)

Dijagram razvoja (Deployment Diagram)

8

Gradivni blokovi UML-a

Stvari (things)

Relacije (relationships)

9

Things

Postoje 4 vrste stvari (things):

Stvari strukture – statički delovi modela koji reprezentuju konceptualne ili fizičke elemente (imenice)

Stvari ponašanja – dinamički delovi modela koji reprezentuju ponašanje kroz prostor i vreme (glagoli)

Stvari grupisanja - organizacioni delovi modela

Stvari anotacije – opisni delovi modela, komentari koji se primenjuju na bilo koji dokument

10

Statički delovi modela

Fizički i zamenljivi deo sistema koji obezbeđuje realizaciju

skupa interfejsa

Komponenta

OpisSimbolIme

Čvor

Aktivne

klase

Slučaj

upotrebe

Korisnik

Kolaboracija

(Saradnja)

Interfejs

Klasa

Fizički element koji postoji u vreme izvršavanja i predstavlja

računarski resurs – ima memoriju i mogućnost procesiranja.

Klase čiji objekti poseduju jedan ili više procesa ili niti –

mogu inicirati kontrolnu aktivnost.

Opis skupa sekvenci akcija koje sistem izvodi da bi izvršio

neki zahtev korisnika.

Spoljašnji entitet koji komunicira sa sistemom, obično osoba.

Definiše interakciju i udružuje uloge i druge elemente tako da

rade zajedno i obezbeđuju kolaborativno ponašanje.

Kolekcija operacija koje opisuju servise klase ili komponente.

Opis skupa objekata koji dele iste atribute, operacije, veze i

semantiku. Implementira 1 ili više interfejsa.

11

Dinamički delovi UML modela

OpisSimbolIme

Prikaz stanja

Interakcija

Ponašanje specificirano sekvencom stanja objekta ili

neke interakcije.

Ponašanje prilikom razmene skupa poruka između

skupa objekata da bi se objasnile specifične namene.prikaz

Čekanje

12

Organizacioni delovi UML modela

OpisSimbolIme

Paket

Grupe na koje model može biti dekomponovan.

Mehanizam opšte namene, za organizovanje elemenata

u grupe.

Paket je čisto konceptualan – postoji samo u vreme

razvoja.

13

Delovi za objašnjenja

OpisSimbolIme

Anotacija

Komentari kojima opisujemo, objašnjavamo i

naznačavamo bilo koji element u modelu.

Osnovna vrsta anotacije je napomena (note).

14

Relacije (relationships)

Semantička relacija između klasifikatora, gde jedan

klasifikator specificira ugovor koji drugi klasifikator

garantuje da će ispuniti.

Objekti specijalizovanih elemenata (dete)

predstavljaju zamene za objekte generalizovanih

elemenata (roditelj).

Vrh strelice na roditelju.

Strukturna relacija koja opisuje skup veza kojim se

postavlja veza između objekata.

Semantička relacija između nezavisne i zavisne

stvari. Nezavisna stvar utiče na semantiku zavisne.

Usmerenje – iz zavisnog slučaja.

Opis

Realizacija

Generalizacija

SimbolIme

Asocijacija

Zavisnost

0..1 *

radi radj

15

Alati za izradu UML dijagrama

16

Alati za izradu UML dijagrama

Rational Rose

Microsoft Visio

System Architect

Describe Enterprise

17

Rational Rose

18

Dijagrami slučajeva upotrebe (korišćenja)

19

Dijagram slučajeva upotrebe(Use-Case Diagram)

Omogućavaju krajnjim korisnicima da razumeju sistem

Pogled korisnika na funkcionisanje sistema (šta sistem radi, a

ne kako sistem funkcioniše)

Razvoj dijagrama slučajeva upotrebe definiše se sledećim

aktivnostima:

Definisanjem učesnika

Definisanjem slučajeva upotrebe

Definisanjem tipova veza između učesnika i slučajeva upotrebe

Izradom dijagrama slučajeva upotrebe

Učesnik

Asocijativni naziv

Slučaj upotrebe

20

Primer 1.

Potrebno je napraviti aplikaciju koja će omogućiti korisniku

da preko Interneta rezerviše bioskopske ulaznice za željene

projekcije.

Takođe je potrebno omogućiti korisniku stalan uvid u

bioskopski repertoar i informacije o bioskopu u kojem

željeni film igra.

21

Dijagram slučajeva upotrebe

korisnik

Pregled filmova

Pregled bioskopa

Rezervacija

22

Dijagram slučaja upotrebeprocesa rezervacije

Odabir filma

Odabir bioskopa

Odabir termina

Rezervacija karata

Potvrda rezervacije

Unos podataka

korisnik

23

Definisanje učesnika

Korisnik je čovek koji koristi sistem, dok je učesnik specifična

uloga koju korisnik ima u komunikaciji sa sistemom

Učesnik – osoba ili veštački entitet (softver ili sistem) koji

učestvuje u slučaju upotrebe

24

Definisanje učesnika

Učesnika je moguće identifikovati na osnovu odgovora na sledeća

pitanja:

Ko će koristiti osnovnu funkcionalnost sistema (primarni

učesnici)

Ko treba da upravlja, administrira i održava sistem (sekundarni

učesnici)

Kome će biti potrebna podrška sistema u obavljanju dnevnih

zadataka

Kojim hardverskim uređajima sistem treba da upravlja

Sa kojim drugim sistemima dotični sistem treba da bude u vezi

Ko ili šta je zainteresovan za rezultate koje sistem proizvodi

25

Definisanje slučajeva upotrebe

Slučaj upotrebe – definiše funkcionalnost sistema sa

stanovišta učesnika – šablon ponašanja delova sistema

Pitanja za učesnika – identifikuju slučajeve upotrebe:

Koje funkcije učesnik zahteva od sistema – šta učesnik treba da

radi?

Da li učesnik treba da čita, kreira, briše, izmeni ili da unese

neke informacije u sistem?

Da li učesnik treba da bude obavešten o događajima u sistemu?

Da li svakodnevni rad učesnika može da se pojednostavi kroz

nove funkcije sistema?

26

Definisanje veze između učesnika i slučajeva upotrebe

Veze koje se uspostavljaju u dijagramu slučajeva upotrebe:

Asocijacija (Association)

Asocijacija između slučajeva upotrebe tipa <<include>>

Asocijacija između slučajeva upotrebe tipa <<extend>>

Generalizacija (Generalization-Inheritance)

Zavisnost (Depedency)

27

Asocijacija

Bidirekciona veza – linija koja spaja učesnike i slučajeve upotrebe

Asocijacija između samih učesnika ili slučajeva upotrebe, definiše

povezanost tih elemenata

Menadžer projekta

Inženjer razvoja

Razvoj sistema

28

Upotreba tipa <<include>>

Slično ponašanje deli se između sličnih slučajeva upotrebe

Veza <<include>> opisuje odnos između slučajeva upotrebe u

kojem jedan slučaj upotrebe koristi usluge drugog

<<include>> <<include>>

<<include>>

Razvoj softvera

Operacije sistema

Razvoj sistemaDefinicija problema

Menadžer projekta Inženjer razvojaklijent

Krajnji korisnik

29

Upotreba tipa <<include>>

Korisnik LoginPristupa Webu

<< include>>

30

Upotreba tipa <<extend>>

“Proširivanjem” jednog slučaja upotrebe opisuje se neka

složenija funkcija sistema

Proširivanje se vrši sa jednim ili više drugih postojećih

slučajeva upotrebe

Ako slučaj A proširuje slučaj B:

i slučaj A i slučaj B mogu da postoje sami

slučaj B može (a ne mora) da bude proširen slučajem A

A B<<extend>>

31

Upotreba tipa <<extends>>

<<extend>> Praćenje finansija

Praćenje dnevnog kumulativaPeriodična kontrola

<<extend>>

32

Generalizacija

Generalizacija – veza između roditelja i deteta – vezana za pojam nasleđivanja – dete nasleđuje osobine roditelja

Generalizacija učesnika – izvedeni učesnik ima sve osobine i ponašanje osnovnog (apstraktnog) učesnika, ali može dodati osobine ili redefinisati ponašanje

zaposlen

Rukovodilac Knjigovođa Kontrolor

33

Generalizacija

Generalizacija slučajeva upotrebe – izvedeni slučaj upotrebe ima

sve osobine i ponašanje apstraktnog slučaja upotrebe, ali može

dodati osobine ili redefinisati ponašanje

Novčane transakcije

UplataIsplata

34

Primer 2.

Operator

Korisnik

Banka

sesija

transakcije

uplata isplata transfer izveštaj

35

Primer 3.

službenik

pacijent

Zakazuje pregled

Otkazuje pregled

Provera pacijentove

dokumentacije

Zahteva lečenje

Različliti načini plaćanja

Plaćanje računa

Tačke proširenja

Naredni tretmani

kartoteka

doktor

Polisa osiguranja

36

Elektronska prodavnica knjiga

Primer 4.

37

Analiza sistema

Analiza sistema treba da omogući odgovor na pitanje: “Koja je prioritetna funkcija koju treba da ostvari sajt namenjen elektronskoj trgovini?”

Jedan od načina za realizaciju sajta je uočavanje poslovnih ciljeva, na osnovu kojih se razvija lista funkcionalnosti sistema i zahteva za informacijama.

38

Analiza sistema

Poslovni ciljevi predstavljaju jednostavnu listu mogućnosti koje od sajta očekujemo.

Funkcionalnosti sistema predstavljaju listu mogućnosti informacionog sistema koje su potrebne da bi se ostvarili poslovni ciljevi.

Informacioni zahtevi za sistem predstavljaju informacione elemente koje sistem mora da produkuje da bi se realizovali poslovni ciljevi.

Tako formirane liste moraju se dostaviti programerima da bi znali šta menadžer od njih očekuje.

39

Broj posetilaca, posećene stranice,

kupljeni proizvodi.

Sistem za praćenje i izveštaj o

sajtu

Razumeti efikasnost

marketinga.

Inventar proizvoda, ID i kontakt

izdavača.

Upravljanje inventaromMogućnost lakog ažuriranja i

proširivanja kataloga

Korisnikov ID, knjige, datum

porudžbine.

Baza podataka o

porudžbinama

Obezbediti podršku

potrošaču nakon kupovine

knjiga.

Ime, adresa, telefon i e-mail svakog

potrošača. Online registracija

korisnika.

Baza podataka potrošačaPrikupiti podatke o

potrošaču.

Naziv, autor, cena, izdavač i kratak

opis svake knjige.

Baza podataka knjigaNeposredno pretražiti katalog

i dodati knjige u potrošačku

korpu.

Upis svakog korisnika koji pristupi

sajtu.

Veza sa potrošačemPersonalizovati/kastomizovati

svaku knjigu.

Opis knjige, broj zaliha, nivo

inventara.

Baza podataka knjigaObezbediti detaljnije

informacije o knjigama.

Dinamičan tekst i grafički katalog.Digitalni katalogPrikazati knjige.

Informacioni zahteviFunkcionalnost sistemaPoslovni ciljevi

40

Specifikacija zahteva

Korisnika

Registraciju novih korisnika

Prijavljivanje starih korisnika

Pregled kataloga

Pretragu kataloga

Postavljanje odabranih knjiga u potrošačku korpu

Modifikaciju potrošačke korpe

Pražnjenje cele korpe

Administratora

Registraciju novog administratora

Izmenu lozinke registrovanog administratora

Brisanje administratora

Postavljanje novih kategorija u katalog

Uklanjanje kategorija iz kataloga

Postavljanje novih knjiga u katalog

Editovanje atributa knjige u katalogu

Uklanjanje knjiga iz kategorija

Premeštanje knjiga iz jedne u drugu kategoriju

Postavljanje novih izdavača

Modifikaciju atributa postojećih izdavača

41

Prikaz opštih slučajeva upotrebe

Login

Registracija

Pretraga kataloga

Formiranje porudžbine

Modifikacija porudžbine

Pražnjenje cele korpe

Login

Registracija

Modifikacija kategorija

Modifikacija knjiga

Modifikacija administratora

Modifikacija izdavača

korisnik administrator

42

Slučaj korišćenja: Modifikacija podataka

43

Slučaj korišćenja: Pretraga

44

Slučaj korišćenja: Logovanje administratora na sistem

Unos lozinke

provera lozinke

45

Dijagrami aktivnosti

46

Razvoj dijagrama aktivnosti

Poslovni proces – slučaj upotrebe – posmatra se kao sistem koji ima svoja stanja u kojima se obavljaju aktivnosti, dok prelaze iz jednog u drugo stanje koje diktiraju događaji

Prikazuje sekvencijalni tok aktivnosti

Sastoji se od:

Stanja

Akcija

Prelaza

Proces Razvoja dijagrama aktivnosti sadrži:

Definisanje plivačkih staza

Definisanje stanja dijagrama aktivnosti

Definisanje tranzicija

47

Definisanje stanja dijagrama aktivnosti

Stanje dijagrama aktivnosti može da predstavlja:

Akciju – ne može biti dekomponovana, traje kratko vreme, ne

može se prekidati

Aktivnost – ima trajanje, može se prekidati zbog nekih

događaja, može se dekomponovati

Pseudostanje ili

Stanje toka objekta

Oznaka stanja je jedinstvena:

Naziv stanja

48

Definisanje stanja dijagrama aktivnosti

Definisanje pseudostanja – stanja prelaza

Početno stanje

Krajnje stanje

Stanje odluke - grananje

Sinhronizacija

49

Definisanje tranzicija

Tranzicija - prelazak iz jednog u drugo stanje – prouzrokuje (okida) neki događaj

Događaji mogu da budu:

Spoljni – generišu se van sistema – generišu ga učesnici

Kraj aktivnosti

Vremenski – spoljni ali bez učesnika

Upravljački – generiše rukovodilac posla

Tranzicija prouzrokuje događaj koji sadrži uslove, argumente i akcije

Događaj – poruka – ako su očigledne ne prikazuju se na dijagramu

Događaj 1 (argument) [uslov 1] / Akcija 1

50

Prikaz grananja

A

C

[uslov]

[not uslov]

B

grananje

51

Prikaz grananja

postavi iterator

radi()

promeni iterator

[kraj]

[not kraj]

početno stanje

završno stanje

52

Sinhronizacija

Sinhronizacija – zadebljana horizontalna linija

Račvanja (fork) i udruživanja (join) niti – obavljaju se u

sinhronizacionim tačkama

Tranzicije koje ulaze u sinhronizaciju su uslov za paralelno

obavljanje tranzicija koje iz nje izlaze – jedna aktivnost

“čeka” na ispunjenje uslova (“pristizanje” svih događaja) za

njeno izvršenje

53

Prikaz sinhronizacije

Priprema

Aktivnost 1 Aktivnost 2

Finalizacija

Sinhronizaciona tačkaRačvanje (fork)

Udruživanja (join)

54

55

Definisanje plivačkih staza

Dijagram aktivnosti deli se u odgovarajuće logičke celine –

plivačke staze – definišu odgovornost pojedinih objekata za

izvršenje odgovarajućih akcija

Svaka staza – navode se učesnici, aktivnosti – “radna lista” –

definisana u okviru opisa radnog mesta prilikom opisa organizacije

Stanja pripadaju stazama, a tranzicije mogu da prelaze iz jedne

staze u drugu

56

Definisanje plivačkih staza

Ime 1 Ime 2 Ime 3

A

B

C

D

Plivačka

staza

57

Primer

Isporuka

korisnik prodaja magacin

Zahtev za isporukom

Prijem porudžbine

Plaćanje

Isporuka Preuzimanje

robe

Order [placed] Order

[entered]

Order [filled]

Order [delivered]

Priprema isporuke

58

Korisnik Automat Banka

Postavi karticu

Unesi PIN

Podižem iznos

Preuzmi novac

Uzmi karticu

Identifikacija

Provera stanja na računu

Umanji iznos na računu

Prikazuje stanje na računu

Vraća karticu

59

Dijagrami aktivnosti