05 Analiza, Modelovanje Objekata

Usi

ng

UM

L, P

atte

rns,

and J

ava

Ob

ject

-Ori

ente

d S

oft

wa

re E

ng

inee

rin

g

Poglavlje 5 Analiza

Usi

ng

UM

L, P

atte

rns,

and J

ava

Ob

ject

-Ori

ente

d S

oft

wa

re E

ng

inee

rin

g

Aktivnosti u razvoju i odgovarajući proizvodi

Prikupljanje

zahteva

Analiza

Dizajn sistema

Izjava problema

Funkcionalni

model

Nefunkcionalni

zahtevi

Objektni

model analize

Dinamički

model

Dijagram klasa

Dijagram slučajeva

korišćenja

Dijagram stanja

Dijagram sekvence

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 3

Analiza

• Rezultat Analize je model sistema koji treba da bude tačan, kompletan i nedvosmislen.

• Programeri formalizuju specifikaciju zahteva koja je dobijena u koraku prikupljanja zahteva i proučavaju detaljno granične uslove i izuzetne slučajeve.


Optička iluzija

• Ako je ovaj crtež specifikacija zahteva, koji model biste napravili?

• Formalizacija pomaže da se identifikuju područja dvosmislenosti kao i nekonzistencija i propusti u specifikaciji zahteva.

• Kada programeri identifikuju probleme u specifikaciji, oni zahtevaju dodatne informacije od korisnika i klijenta.

• Prikupljanje zahteva i analiza su iterativne i inkrementalne aktivnosti koje se obavljaju konkurentno..

Šta vidite? Dva lica koja

gledaju jedno u drugo? Ako

se fokusirate na beli prostor,

videćete vazu umesto toga.


Analiza

• Analiza se fokusira na stvaranje modela sistema (model analize) koji je tačan, kompletan, konzistentan i koji se može proveriti. Analiza se razlikuje od prikupljanja zahteva u tome što se programeri fikusiraju na strukturiranje i formalizaciju zahteva prikupljenih od korisnika.


Model Analize

• Model analize se sastoji iz tri modela: funkcionalni model, predstavljan slučajevima korišćenja i scenarijima, objektni model, predstavljan klasnim i dijagramom objekata, i dinamički model, predstavljen dijagramom sekvence i dijagramom stanja.


Analiza – Modeli Objekata i Dinamički modeli

• Model u koraku Analiza predstavlja sistem, koji se razvija, gledan sa strane korisnika. Model objekata je deo modela analize i fokusira se na koncepte sa kojima sistem manipuliše, njihove osobine i veze. Model objekata, koji se opisuje UML klasnim dijagramom uključuje klase, atribute i operacije. Model objekata je vizuelni rečnik glavnih koncepata koji su vidljivi korisniku.

• Dinamički model se fokusira na ponašanje sistema. Dinamički model je opisan dijagramom sekvence i dijagramom stanja. Dijagram sekvence predstavlja interakciju između skupa objekata za vreme jednog slučaja korišćenja. Dijagram stanja predstavlja ponašanje jednog objekta (ili grupe jako povezanih objekata). Dinamički model služi da doda odgovoronosti individualnim klasama i, u tom procesu, identifikuje nove klase, asocijacije i atribute koji bi se dodali objektnom modelu.

Usi

ng

UM

L, P

atte

rns,

and J

ava

Ob

ject

-Ori

ente

d S

oft

wa

re E

ng

inee

rin

g

Poglavlje 5, Analiza: Modelovanje objekata


Pregled

Podsetnik:

Modelovanje sistema = Modelovanje funkcija+ Modelovanje Objekata+Dinamičko modelovanje

Poslednja lekcija: Modelovanje funkcija (slučajevi korišćenja i scenariji)

• Sada: Modelovanje objekata

• Aktivnosti za vreme modelovanja objekata

• Identifikacija objekata

• Tipovi objekata

• Entitet, granični i kontrolni objekti

• Abottova tehnika

• Pomaže u identifikaciji objekata


Aktivnosti za vreme modelovanja objekata

Glavni cilj: Pronaći važne apstrakcije

• Koraci za vreme modelovanja objekata

1. Identifikacija klasa

• Pretpostavljamo da možemo da pronađemo apstrakcije

2. Pronaći atribute

3. Pronaći operacije

4. Pronaći asocijacije između klasa

• Redosled koraka

• Cilj: pronaći željene apstrakcije

• Redosled koraka je manje bitan

• Šta se dešava ukoliko pronađemo pogrešne apstrakcije?

• Vraćamo se i prerađujemo model.


Identifikacija klasa

Identifikacija klasa je presudno u objektno-orientisanom modelovanju

• Pomaže da se identifikuju važni entiteti u sistemu

• Podsetnik: Klase predstavljaju korisnički koncept a ne obavezno i softverske klase

• Primer: Klase Baze, Podsistemi, MenadžerSesije ne treba da se nađu u modelu analize, pošto klijent i ne treba da zna ove koncepte

• Većina klasa iz modela objekata će i odgovarati jednoj ili više klasa iz izvornog koda

• Klase u analizi su apstrakcije na višem nivou koje će se realizovati u više detalja kasnije


Identifikacija klasa

• Pristupi

• Pristup iz domena primene

• Pitati eksperta iz domena primene da identifikuje relevantne apstrakcije

• Sintaksni pristup

• Početi od slučajeva korišćenja

• Analizirati tekst da bi identifikovali objekte

• Izvući učestvujuće objekte iz toka događaja

• Pristup iz šablona dizajna

• Identifikovati relevantne apstrakcije koje mogu biti ponovo korišćene (primeniti znanje o dizajnu)

• Pristup baziran na komponentama

• Identifikovati postojeće klase rešenja


Identifikacija klasa je težak problem

• Problem1: Definicija granica sistema:

• Koje apstrakcije su izvan a koje unutar granica sistema?

• Učesnici su izvan sistema

• Klase/Objekti su unutar sistema

• Problem2: Klase/Objekti se ne nalaze samo na osnovu slike scene ili domena

• Domen primene treba da bude analiziran

• Zavisno od svrhe sistema, različiti objekti mogu da se nađu

• Kako da se identifikuje svrha sistema?

• Scenarija i slučajevi korišćenja => Funkcionalni model.


Postoje različiti tipovi objekata

• Entiteti

• Predstavljaju perzistentnu informaciju koja se prati u sistemu (Objekti u domenu primene, nazivaju se i “Biznis objekti”)

• Granični Objekti

• Predstavljaju interakciju između korisnika i sistema

• Kontrolni objekti

• Predstavljaju kontrolne zadatke koje sistem obavlja.


Primer: 2BWatch Modelovanje

Year

Month

Day

ChangeDate

Button

LCDDisplay

Entity Objects Control Object Boundary Objects

Da bi u modelu razlikovali različite tipove objekata koristimo UML stereotip


Imenovanje tipova objekata u UML-u

<<entity>>

Year <<control>>

ChangeDate

<<boundary>>

Button

<<entitity>>

Month

<<entity>>

Day

<<boundary>>

LCDDisplay

Entitet Objekti Kontrolni Objekti Granični Objekti


Ikonice za Tipove Objekata: Entitet, Kontrolni i Granični Objekti

• Možemo koristiti i ikonice za identifikaciju stereotipa

• Kada se stereotip primenjuje u UML modelu, ikonica se prikazuje pored ili iznad imena.

Entitet Objekat Kontrolni Objekat Granični Objekat

Year ChangeDate Button

Učesnik

WatchUser

Granica

sistema


UML je proširiv jezik

• Stereotipovi dozvoljavaju proširenje rečnika UML-a tako da se mogu kreirati novi elementi modela, izvedeni iz postojećih

• Drugi primeri:

• Stereotipovi mogu da se koriste za klasifikaciju metoda npr. <<constructor>>, <<getter>> ili <<setter>>

• Da bi naznačili interffejs ili podsistem sistem,a možemo koristiti stereotip <<interface>> (Dizajn Sistema za Učenje)

• Stereotipovi mogu da se predstavljaju sa ikonama kao i grafički:

• Ovim se povećava čitljivost UML dijagrama.


Grafika za Stereotipove

• Mogu se koristiti i grafički simboli za identifikaciju stereotipa

• Kada se stereotip primeni na elementu UML modela, tada slika zameni podrazumevanu sliku za elemen t dijagrama.

• Primer: Kada modelujemo mrežu, možemo da definišemo grafičke simbole koje predstavljaju klase tipa Switch, Server, Router i Printer.

Slika za klasu

Router

Slika za klasu

Switch Slika za klasu

Server


Tipovi objekata nam omogućavaju da se suočimo sa promenama

• Podela na tri vrste objekata model će biti otporniji na promenu

• Interfejs sistema se pre menja nego kontrola

• Način na koji se kontroliše sistem se pre menja nego entiteti u domenu aplikacije

• Tipovi objekata su nastali iz Smalltalk-a:

• Model, View, Controller (MVC)

Model <-> Entitet Objekat

View <-> Granični Objekat

Controller <-> Kontrolni Objekat

• Sledeća tema: Pronalaženje objekata.


Pronalaženje učestvujućih objekata u slučajevima korišćenja

• Izabrati slučaj korišćenja i pratiti tok događaja

• Uraditi analizu teksta (analiza imenica-glagol)

• Imenice su kandidati za objekte/klase

• Glagoli su kandidati za operacije

• Ova tehnika ima naziv Abbott-ova Tehnika

• Nakon pronalaženja objekata/klasa, identifikovati njihove tipove

• Identifikovati entitete iz realnosti koje sistem treba da prati (TerenskiRadnik Entitet Objekat)

• Identifikovati procedure iz realnosti koje sistem treba da prati (PlanHitneSluzbe Kontrolni Objekat)

• Identifikovati artifakte interfejsa (PolicijskaStanica Granični Objekat).


Primer korišćenja tehnike

Klijent ulazi u radnju da kupi igračku.

Igračka mora da se svidi njegovoj ćerki i mora da košta manje od 50 eura.

On proba video-igru koja koristi rukavicu i ekran na glavi. Svidja mu se.

Asistent mu pomaže. Prikladnost igre zavisi od uzrasta deteta. Njegova ćerka ima 3 godine.

Asistent predlaže drugu vrstu igre, društvena-igra, „Monopol“

Tok događaja


Mapiranje gramatičkih konstrukcija na modelovanje komponenti (Abbot-ova Tehnika)

Gramatički

konstrukt

Imenica

Imenica

Komponenta

UML modela

objekat

klasa

Primer

“Monopol”

Igračka

Glagol operacija Kupuje, preporučuje

Glagol nasleđivanje je

Glagol agregacija ima

Glagol ograničenje mora biti

pridev atribut opasan

Glagol operacija ulazi

Glagol ograničenje, klasa,

asocijacija

zavisi od


video-igra

Klijent ulazi u radnju da kupi igračku.

Igračka mora da se svidi njegovoj ćerki i mora da košta manje od 50 eura.

On proba video-igru koja koristi rukavicu i ekran na glavi. Svidja mu se

Generisanje klasnog dijagrama na osnovu toka događaja

Asistent mu pomaže. Prikladnost igre zavisi od uzrasta deteta. Njegova ćerka ima 3 godine. Asistent predlaže drugu vrstu igre, društvena-igra, „Monopol

Klijent ulazi

zavisi

radnju

Klijent

?

ulaz()

igračka

ćerka

pogodna

*

manje od 50

radnja

ulaz()

igračka

kupi()

igračku

uzrasta

video-igru

ćerki

društvena-igra

Tok događaja:

igračka

cena

kupi()

svidi()

kupi

vrstu igre

društvena-igra

ćerka

uzrast

Klijent


Načini za pronalaženje objekata

• Sintaksna pretraga uz pomoć Abbotove tehnike:

• Tokovi događaja u slučajevima korišćenja

• Izjava Problema

• Koristiti druge izvore

• Poznavanje aplikacije: Krajnji korisnici i eksperti znaju apstrakcije u domenu primene

• Poznavanje rešenja: Apstrakcije u domenu rešenja

• Opšte poznavanje: Opšte znanje i intuicija


Redosled aktivnosti za identifikaciju objekata

1. Formulisati nove scenarije uz pomoć krajnjih korisnika ili eksperta u domenu primene

2. Izdvojiti slučajeve korišćenja iz scenarija, uz pomoć eksperta u domenu primene

3. Onda nastaviti u paraleli sa sledećim:

• Analizirati tok događaja u svakom slučaju korišćenja koristeći Abbottovu tehniku za analizu teksta

• Generisati UML klasni dijagram


Koraci u kreiranju Dijagrama Klasa

1. Identifikacija klasa (analiza teksta, ekspert domena)

2. Identifikacija atributa i operacija (ponekad i pre nego što su klase pronađene)

3. Identifikacija asocijacija između klasa

4. Identifikacija multiplikativnosti

5. Identifikacija uloga

6. Identifikacija nasleđivanja


Ko koristi dijagrame klasa?

• Namena dijagrama klasa

• Opis statičkih osobina sistema

• Korisnici dijagrama klasa:

• Ekspert u domenu primene

• Koristi klasni dijagram da modeluje domen primene (uključujući taksonomije)

• Za vreme prikupljanja zahteva i analize

• Programer

• Koristi klasni dijagram za vreme razvoja sistema

• Za vreme analize, dizajna sistema, dizajbna objekata i implementacije.


Ko ne koristi dijagrame klasa?

• Klijent i krajnji korisnik obično nisu zainteresovani za klasne dijagrame

• Klijent se više fokusira na menadžment projekta

• Krajnji korisnici su više zainteresovani za funkcionalnost sistema


Rezime

• Modelovanje sistema

• Modelovanje funkcija+modelovanje objekata + dinamičko modelovanje

• Modelovanje funkcija

• Iz scenarija i slučajeva korišćenja do modelovanja objekata

• Modelovanje objekata je centralna aktivnost

• Identifikacija klasa je glavna aktivnost u modelovanju objekata

• Abbottova Tehnika

• Klasni dijagrami su “centar univerzuma” za objektno-orjentisanog programera

• Krajnji korisnik se fokusira više na funkcionalni model i upotrebljivost


Delovi modela objekata

• Klase i njihove instance (“objects”)

• Atributi

• Operacije

• Asocijacije između klasa i objekata


Asocijacije

• Tipovi asocijacija

• Kanoničke asocijacije

• Deo-od Hijerarhija (Agregacija)

• Vrsta-od Hijerarhija (Nasleđivanje)

• Generička asocijacija


Atributi

• Detekcija atributa se određena primenom

• Atributi u jednom sistemu mogu biti objekti u drugom

• Pretvaranje atributa u klase i obratno


Operacije

• Izvori operacija

• Slučajevi korišćenja u finkcionalnom modelu

• Opšte znaenje

• Generičke operacije Get/Set

• Šabloni korišćenja

• Operacije specifične za primenu

• Akcije i aktivnosti u dinamičkom modelu


Objekti vs Klase

• Objekti (instance): Tačno jedna stvar

• Klasa opisuje grupu objekata sa sličnim osobinama

• Igra, Turnir, mehaničar, auto, baza

• Dijagram objekata: Grafička notacija za modelovanje objekata, klasa i njihovih relacija

• Klasni dijagram: Šablon za opis više instanca podataka.

• Dijagram instance: Određeni skup objekata koji su u međusobnoj vezi. Koristan za diskutovanje scenarija, test slučajeva i primera


Developeri imaju različite poglede na dijagrame klasa

• U zavisnosti od aktivnosti, programer igra različite uloge:

• Analitičar

• Dizajner Sistema

• Dizajner Objekata

• Implementator

• Svaka od ovih uloga ima različit pogled na klasni dijagram (model objekata).


Pogled Analitičara

• Analitičar je zainteresovan za

• u klasama aplikacije: Asocijacije između klasa su veze između apstrakcija u domenu primene

• Operacije i atribute u klasama aplikacije

• Analitičar koristi nasleđivanje u modelu za prikaz taksonimija u domenu primene

• Taksonomija: vrsta-od hijerarhija apstrakcije u domenu primene

• Analitičar nije zainteresovan za:

• Tačan potpis operacija

• Klase u domenu primene


Pogled Dizajnera • Dizajner se fokusira na rešenja problema, domen

rešenja

• Asocijacije između klasa su sad reference (pokazivači) između klasa u aplikaciji ili domenu rešenja

• Važni zadaci dizajniranja je specifikacija interfejsa:

• Dizajner opisuje interfejs klasa i podsistema

• Podsistemi nastaju od modula (termin često korišćen za vreme analize):

• Moduo: kolekcija klasa

• Podsistem: Kolekcija klasa sa interfejsom

• Podsistemi se u UML modeluju paketima


Zadatak Dizajnera

• Najvažniji zadatak je upotrebljivost dizajna i ponovno korišćenje

• Upotrebljivost dizajna: interfejsi se koriste od strane što više klasa u sistemu

• Ponovno korišćenje dizajna: Interfejsi su dizajnirani tako da se mogu ponovo koristiti u drugim sistemima

=> Biblioteke klasa

=> Frameworks

=> Design patterns.


Pogled Impelemntatora

• Implementator klasa

• Realizuje interfejs klasa u programskom jeziku

• Zainteresovan je za odgovarajuće strukture podataka (za atribute) i algoritme (za operacije)

• Proširivač klasa

• Zainteresovan kako da se proširi klasa da bi se rešio novi problem ili da primeni promenu u domenu aplikacije

• Korisnik klasa

• Korisnik klase je zaintersovan za potpise operacija i uslove pod kojima se one pozivaju

• Korisnik klasa nije zaintersovan za njenu implementaciju.


Zašto pravimo razliku u korisnicima dijagrama klasa?

• Modeli često ne prave razliku između klasa primene i klasa rešenja

• Razlozi: Jezici za modelovan je, kao UML, dozvoljavaju oba tipa klasa u istom modelu

• “adresa“, “niz"

• Poželjno: Bez klasa rešenja u modelu analize

• Mnogi sistemi ne razlikuju specifikaciju i implementaciju klase

• Razlog: OO jezici dozvoljavaju simultano korišćenje specifikacije i implementacije klase

• Poželjno: Razlikujemo model analize i model dizajna objekata. Model dizajna ne sadrži specifikacije implementacije.


Model analize vs. Model dizajna Objekata

• Model analize se kreira za vreme faze analize

• Glavni učesnici: Krajnji korisnik, klijent, analitičar

• Klasni dijagram sadrži samo klase iz domena primene

• Model dizajna objekata (model specifikacije) je kreiran za vreme dizajna objekata

• Glavni učesnici: specifikatori klasa, implementatori klasa, korisnici klasa i proširivači klasa

• Dijagram klasa sadrži klase iz domena primene kao i klase iz domena rešenja.


Model analize vs. Model dizajna Objekata...

• Model analize je osnova za komunikaciju između analitičara, eksperta domena primene i krajnjeg korisnika

• Model dizajna objekata je osnova za dizajn između developera i implementatora


Rezime

• Modelovanje sistema

• Modelovanje funkcija+modelovanje objekata + dinamičko modelovanje

• Modelovanje funkcija

• Iz scenarija i slučajeva korišćenja do modelovanja objekata

• Modelovanje objekata je centralna aktivnost

• Identifikacija klasa je glavna aktivnost u modelovanju objekata

• Abbottova Tehnika

• Klasni dijagrami su “centar univerzuma” za objektno-orjentisanog programera

• Analitičari, dizajneri i implementatori imaju različite potrebe modelovanja

• Postoje tri vrste implementatora sa različitim ulogama: • Implementator klase, proširivač klase, korisnik klase

Documents

05 Analiza, Modelovanje Objekata