Objektno orjentisana analiza i projektovanje sa UML-om

dr Zoran Jeremi

zoran.jeremic@gmail.com

1

Analiza i projektovanje Svrha faze analize i projektovanja:

Prevoenje zahteva u dizajn sistema Razviti robusnu arhitekturu sistema Prilagoditi dizajn okruenju implementacije, projektovati za performanse

Analiza i projektovanje Ulazni artifakti su use case model, renik i

dodatne specifikacije iz faze Zahteva Rezultat analize i projektovanja je model

projektovanja (design model) koji prikazuje kako e biti struktuiran i napisan izvorni kod

Dizajn model se sastoji od klasa koje su

struktuirane u pakete; takoe sadri opise o tome kako rade objekti ovih klasa da bi izvrili use case (use case realizacija)

Aktivnosti projektovanja (dizajna) su centrirani oko arhitekture

Arhitektura se predstavlja pogledima (view) koji sadre glavne odluke o strukturi dizajna reenja Arhitektura je pojednostavljenje itavog dizajna reenja Arhitektura je dokumentovana u dokumentu arhitekture (Architecture document)

Analiza vs. Dizajn (projektovanje) Analiza

Fokus na razumevanje problema Idealizovanje dizajna Ponaanje Struktura sistema Funkcionalni zahtevi Mali model

Cilj je razumevanje problema i poetak

razvoja vizuelnog modela o tome ta treba da se izgradi, nezavisno od implementacije i tehnologije

Fokus je na prevoenju funkcionalnih

zahteva u softverske koncepte Ideja je da se dobiju grubi objekti, ali sa

fokusom na ponaanje

Projektovanje (dizajn) Fokus na razumevanje reenja Operacije i atributi Performanse Pribliavanje realnom kodu ivotni ciklus objekta Nefunkcionalni zahtevi Veliki model

Cilj je preraivanje modela radi razvoja

modela dizajna koji e omoguiti prelaz u fazu kodiranja; u dizajnu se podeavaju okruenja implementacije i uvoenja

Analiza i dizajn nisu top-down ili bottom-up

ta je arhitektura? Arhitektura softvera obuhvata skup stratekih odluka

o organizaciji softverskog sistema, pravila ili paterna (ablona) koji ine dizajn i konstrukciju reenja

Arhitektura softvera: model 4+1 pogled Arhitektura sistema se razvija iterativno u fazi razrade sistema

Glavne aktivnosti arhitekte obuhvataju definisanje arhitekture softvera, odravanje integriteta softvera, procenjivanje tehnikih rizika u projektu, definisanje redosleda i sadraja uzastopnih iteracija zajedno sa planiranjem svake iteracije, davanje saveta raznim timovima i dr.

Softverska arhitektura nije jednodimenzionalna ona je sainjena od vie paralelnih prikaza:

Ne zahtevaju svi sistemi sve poglede

Aktivnosti i odgovornosti

Odgovornosti arhitekte softvera Arhitekta mora da poseduje:

iskustvo, zrelost viziju, Poznavanje domena, razumevanje zahteva Sposobnost za liderstvo u razliitim timovima i donoenje odluka pod pritiskom,

Odgovornosti projektanta (dizajnera) Projektant mora da poznaje:

tehnike modelovanja sluajeva korienja, sistemskih zahteva, tehnike projektovanja softvera (tehnike objektno-orijentisane analize i projektovanja i UML) Dobro razumevanje arhitekture sistema (prikazanih u dokumentu arhitekture softvera) Tehnologije u kojima e se sistem implementirati

Uloga projektanta definie

odgovornosti, operacije, atribute i relacije klasa i odreuje kako e one biti prilagoene okruenju implementacije

ta je realizacija use case-a? Realizacija use case-a opisuje kako e odreeni use case biti realizovan u okviru modela

projektovanja Realizacija use case-a odreuje koje klase se moraju izgraditi da bi implementirale svaki use case Simbol realizacije use case-a u UML-u je u obliku takaste elipse Realizacija use case-a se u okviru UMLa moe predstaviti korienjem skupa dijagrama koji modeluju klase/objekte koji implementiraju use case i njihove relacije (dijagram klasa) i interakcije saradnje (dijagrami saradnje i sekvenci) koji pokazuju u kakvoj su interakciji klase/objekti kada izvravaju use case

Iteration n Iteration n + 1

Use Case A Scenarios 1 & 2

Use-Case Realization A

Start of iteration

End of iteration

Use Case B Scenario 1

Use-Case Realization A

Use Case A Scenario 3

Use-Case Realization B

Analiza i dizajn u iterativnom procesu

Analiza arhitekture

Analiza arhitekture Analiza arhitekture

podrazumeva definisanje globalne arhitekture sistema

Fokus je na viim slojevima sistema

Definisanje arhitekture kandidata Cilj: definisanje kandidata za

arhitekturu sistema na osnovu iskustva sa prethodnim sistemima ili u slinim problemima.

Ulazni artifakti (input artifacts): Use case model Dodatna specifikacija Renik Model projektovanja (design model) Referentna arhitektura Dokument vizije Smernice projekta Dokument arhitekture softvera

Rezultujui artifakti:

Dokument arhitekture softvera Model projektovanja (design model) Model uvoenja (deployment model)

Podseanje: ta je paket? Paket (package) je mehanizam

opte namene koji slui da organizuje elemente u grupe

to je element modela koji moe da sadri druge elemente modela

Paket se moe koristiti: Za organizovanje modela u toku razvoja Kao jedinica menadmenta konfiguracije

People info

Interfaces

UniversityArtifacts

Relacije izmeu paketa: Zavisnost Paketi mogu biti povezani relacijom zavisnosti Elementi u paketu mogu importovati elemente iz drugih paketa to se i prikazuje relacijom

zavisnosti u UMLu Ukoliko je paket A zavisan od paketa B, to znai da je jedna ili vie klasa iz paketa A zapoinje

komunikaciju sa jednom ili vie javnih klasa iz paketa B Paket A se naziva klijentski paket (client package), a paket B se naziva snabdevaki paket

(supplier package) Relacije izmeu paketa se takoe otkrivaju ispitivanjem scenarija i relacija klasa u sistemu koji

se razvija Relacija zavisnosti podrazumeva

Promene kod paketa Dobavlja moe uticati na paket Klijent Paket Klijent se ne moe koristiti nezavisno jer zavisi od paketa Dobavlja Klase u paketu Klijent mogu pristupati klasama u paketu Dobavlja

Relacije generalizacije meu paketima su dozvoljene

Primer: Relacije izmeu paketa u problemu registracije kurseva U scenariju Add a Course Offering klasa

AddCourseOffering alje poruku klasi ProfessorCourseManager, to ukazuje na to da postoji relacija izmeu paketa Interfaces i paketa UniversityArtifacts

Interfaces

UniversityArtifacts PeopleInfo

Logiki prikaz arhitekture Logiki prikaz arhitekture odnosi se na funkcionalne zahteve sistema ta sistem

treba da obezbedi u smislu usluga svojim korisnicima

Logika arhitektura se odslikava u dijagramima klasa pomou onih klasa i relacija koje predstavljaju kljune apstrakcije razvijanog sistema

Izradi ovog prikaza se pristupa u ranoj fazi razrade, pravljenjem klasa i paketa koji predstavljaju glavne apstrakcije datog domena

Tokom vremena se tom modelu dodaje vie klasa i paketa da bi reflektovale donete odluke u pogledu kljunih mehanizama sistema (jedan od kljunih mehanizama je odluka u vezi sa optim standardima, opredeljenjima i postupcima)

Interfaces

UniversityArtifacts PeopleInfo

GUI Controls

Databases Error HandlingFoundations

Izbegavanje krunih zavisnosti Veoma je vano izbei krune zavisnosti izmeu paketa u

okviru analize arhitekture Problem se reava tako to se jedan paket razbija na dva manja

Paterni i okviri Na izbor viih slojeva arhitekture moe uticati izbor paterna i

okvira arhitekture: Paterni (pattern)

Obezbeuje opte reenje za opti problem Paterni analize/projektovanja

Obezbeuje reenja za tehniki problem Obezbeuje fragment reenja

Okvir (framework) je mikro-arhitektura koja obezbeuje nepotpuni ablon za aplikacije u razliitim domenima.

Definie generalni pristup reavanju problema Obezbeuje kostur reenja Omoguava skalabilnost razvoja (sposobnost brzog razvoja i isporuke sistema)

ta je patern arhitekture? Patern arhitekture (architectural pattern) je jedna fundamentalna ema

strukturne organizacije za softverske sisteme Obezbeuje skup predefinisanih podsistema, odreuje njihove odgovornosti i ukljuuje

pravila i smernice za organizovanje relacija meu njima Slojevi (layers) paterni slojeva dele aplikaciju na razliite slojeve apstrakcije. Slojevi idu od

slojeva odreenih aplikacijom na vrhu do slojeva odreenih implementacijom/tehnologijom na dnu

Model-view-controller (M-V-C) MVC paterni dele aplikaciju na tri particije: model (poslovna pravila i podaci), pogled (kako se informacije prikazuju korisnicima) i regulator koji obrauje inpute korisnika

Cevi i filteri (Pipes and filters) u okviru ovog paterna, podaci se obrauju u tokovima (streams) koji teku kroz cevi od filtera do filtera; svaki filter obrauje te podatke

Tabla (blackboard) - nezavisne aplikacije sarauju kako bi proizvele reenje, radei na zajednikoj strukturi podataka

U jednoj arhitekturi moe biti vie paterna; svaki od prethodnih paterna reava odreene probleme i odnosi se na odreene karakteristike sistema, karakteristike performansi i procese i distribuciju

Paterni arhitekture: Slojevi Veliki sistemi se moraju

dekomponovati

Sistem mora da vodi rauna i o hardveru i o optim servisima i domenu problema itd. Nije poeljno pisati vertikalne

komponente koje rade na svim nivoima

Delovi sistema treba da budu zamenjivi

Promene u komponentama ne bi trebalo da se osete

Sline odgovornosti bi trebalo grupisati zajedno

Veliina komponenti kompleksne komponente bi trebalo dekomponovati

Struktuirati sistem u grupe komponenata koji formiraju slojeve

Modeliranje slojeva arhitekture Slojevi arhitekture se mogu

modelovati kao paketi sa stereotipom

Opis sloja se ukljuuje u dokumentaciju odreenog paketa Na primer: sloj aplikacije sadri

elemente dizajna koji su specifini za aplikaciju Registrovanje na kurs

Primer, desno, prikazuje slojeve aplikacije i poslovne logike za sistem Registrovanje na kurs

Primer troslojne arhitekture

Model-View-Controller (MVC) pattern Deli aplikaciju u tri razliite komponente:

Model sadri osnovne funkcionalnosti i podatke View prikazuje informacije korisniku Controller upravlja input/output podacima

Ukljuuje i mehanizam za izmene i propagiranje Obezbeuje konzistentnost izmeu korisnikog interfejsa i

modela

float sales[3][4]; model:

controller :

views:

Model-View-Controller (MVC) pattern

Model-View-Controller (MVC) Model sadri jezgro funkcionalnosti i podatke i nezavisna je od izlazne

prezentacije ili ponaanja inputa View prikazuje informacije korisnicima; sadri podatke iz modela Controller rukuje korisnikim inputima View i controller-i zajedno obezbeuju korisniki interfejs Osnovna svrha MVC patterna je da odvoji model od pogleda tako da se

promene na pogledu mogu implementirati ili ak kreirati dodatni pogledi, bez izmene samog modela

Slike, ispod prikazuju osnovne MVC relacije

MVC implementacija

Cevi i filteri (Pipes and filters) Reava problem niza transformacija koje se izvravaju nad

nekim skupom podataka, a koje se mogu kombinovati i ponovo upotrebljavati u razliitim aplikacijama nezavisno jedna od druge. Mnoge aplikacije obrauju ogromne koliine slinih skupova

podataka (sistemi za prodaju, naplata telekomunikacionih usluga...)

Obrada podataka se moe podeliti u niz individualnih transformacija.

Funkcionalna dekompozicija transformacije ne menja transformaciju.

Cevi i filteri (Pipes and filters)

Primer: Printing Web service

Primer:UNIX Command Pipelines

33

cat sort gzip mail

fall.txt

win.txt

cat fall.txt win.txt | sort | gzip | mail fred@byu.edu

Primer: Obrada slike

34

Primer: Kompajliranje koda

35

Lexical Analyzer

Parser

Source File

ASCII Text

Token Stream

Semantic Analysis

Abstract Syntax Tree

Code Generator

Augmented Abstract Syntax Tree

Optimizer

Object Code

Object File

Optimized Object Code

Tabla (Blackboard) Koristi se za reavanje problema kod kojih ne postoji specifino

reenje koje reava problem. Nekoliko specijalizovanih podsistema objedinjuje svoje znanje

kako bi obezbedili delimino ili priblino reenje.

Problem Kompletna pretraga svih reenja nije mogua u realno vreme.

Npr. ako pokuavamo da kreiramo fraze od deset rei koristei renik od hiljadu rei, broj moguih permutacija je reda 100010

S obzirom da je domen jo neistraen, mogue je eksperimentisanje sa razliitim algoritmima za isti zadatak. U tu svrhu individualni moduli bi se trebali jednostavno zamenjivati.

Postoje razliiti algoritmi koji delimino reavaju problem. Input, trenutni i konani rezultati mogu imati razliite

reprezentacije, a algoritmi su implementirani korienjem razliitih paradigmi.

Algoritam se obino zasniva na rezultatima drugih algoritama.

Reenje Ideja Blackboard arhitekture je kolekcija nezavisnih programa

koje rade kooperativno na zajednikom skupu podataka. Svaki program je specijalizovan za reavanje dela kompletnog zadatka i svi programi zajedno rade na reenju.

Use Case analiza

Use Case analiza Ciljevi:

Identifikovati klase koje izvravaju use case tok dogaaja Distribuirati use case ponaanja na klase Razviti use case realizacije koje modeluju kolaboracije izmeu instanci

identifikovanih klasa

Koraci: Za svaku use case realizaciju

Pronai klase za use case ponaanja Distribuirati use case ponaanja na klase

Za svaku rezultujuu klasu Opisati odgovornosti Opisati atribute i asocijacije Odrediti mehanizme analize

Ujediniti klase analize

Gde smo

Pregled use case analize

Input artifakti Renik Dodatne spec. Use case Use case model Use case realizacija Dokument arhitekture softvera Analiza klasa Analiza modela Smernice projekta

Rezultujui artifakti

Klase analize Model analize Use case realizacije

Namena use case analize Identifikovati klase koje izvravaju use case-ove tokove

dogaaja Da bi distribuirali use case ponaanja prema klasama,

koristi se use case realizacija Identifikovati odgovornosti, atribute i asocijacije klasa Uoiti upotrebu mehanizama arhitekture

Dodatni opisi use case-ova Opis svakog use case-a ponekad nije dovoljan za

pronalaenje klasa i njihovih objekata Ove dodatne detalje je dovoljno opisati u Word

dokumentu

ta je use case realizacija? Use case realizacija je projektovanje use case-a

Za svaki use case u okviru use case modela postoji use case realizacija u modelu projektovanja (dizajna) sa relacijom zavisnosti ka use case-u (stereotip )

Use case realizacija prikazuje use case u obliku objekata saradnje (collaborating objects) Simbol za kolaboraciju je elipsa koja sadri naziv kolaboracije Simbol za use case realizaciju je takasta verzija simbola kolaboracije

Use case realizacija povezuje use case-ove iz use case modela sa klasama i relacijama iz dizajn modela Odreuje koje se klase moraju izgraditi da bi implementirale use case

Use case realizacija U okviru UMLa, use case realizacija se moe predstaviti

skupom dijagrama koji modeluju sadraj kolaboracije (klase/objekti koji implementiraju use case i njihove relacije - dijagrami klasa) i interakcije kolaboracije (u kakvoj su interakciji ove klase/objekti da bi izvrile use case - dijagrami kolaboracije i sekvenci)

Broj i tip dijagrama zavisi od toga ta je sve potrebno da bi se dobila kompletna slika razvoja projekta

ta su kljune apstrakcije? Nakon identifikovanja mehanizama analize, pristupa se

identifikovanju kljunih apstrakcija (key abstractions) Kljuna apstrakcija je koncept, koji nije pokriven u

Zahtevima Nije cilj razviti kompletni model klasa, ve samo definisati

neke kljune apstrakcije i osnovne relacije Identifikovane klase e se najverovatnije menjati tokom

projekta Definisanje kljunih apstrakcija:

Definisati klase i njihove relacije Modelovati klase i relacije na dijagramu klasa Mapirati klase ka mehanizmima analize

Profesor: osoba koja poduava studente na univerzitetu Student: osoba koja je upisana na univerzitet Raspored: kursevi koje je student upisao u semestru Katalog kurseva (CourseCatalog, na slici): katalog svih kurseva koje nudi

univerzitet Program kursa (CourseOffering, na slici): program kursa koji ukljuuje dane u

nedelji i vremena Kurs (Course): kurs koji se izuava na univerzitetu

Neki od ovih apstrakcija se podudaraju sa akterima u use case modelu

Ovo je apsolutno prihvatljivo, jer je neophodno odravati informacije i o akterima u sistemu

Ove apstrakcije koje odgovaraju spoljnim entitetima (tj. akterima), nazivaju se surogatima (surrogates)

Primer: Kljune apstrakcije

Da li je klasa dobro dizajnirana?

Obavlja puno posla, teko ju je odravati i nije dovoljno jasno ta klasa tano radi

Koliko klasa LiftController

sadri kljunih apstrakcija? Svaka klasa treba da sadri samo jednu kljunu apstrakciju, tj. da predstavlja jednu stvar iz realnog ivota Klasa LiftController pokuava da modeluje bar 3 odvojene kljune apstrakcije, i to Alarm, Vrata, Log

+startUp()+openDoors()+closeDoors()+getFloor()+setTrip()+moveLift()+reset()+displayLog()+shutDown()+raiseAlarm()+emergencyProcedure()

LiftController

Identifikovanje kljunih apstrakcija na primeru klase Lift

+startUp()+getFloor()+setTrip()+moveLift()+shutDown()

LiftController+raiseAlarm()+emergencyProcedure()

Alarm

+displayLog()+reset()

Log

+openDoors()+closeDoors()

Door

can raise

can write to

Identifikovanje kljunih apstrakcija na primeru klase LiftController

Identifikovanje klasa Klasa je opis za grupu objekata koji imaju iste osobine

(atribute), ponaanja (operacije) i semantiku Klasa obuhvata tri dela:

Prvi deo sadri naziv klase Drugi deo prikazuje strukturu (atribute) Trei deo prikazuje ponaanja (operacije)

Dijagrami klasa Svaki objekat u sistemu ima tri karakteristike i to:

Stanje definie ga skup atributa sa vrednostima kao i relacije koje objekat moe imati sa drugim objektima

Ponaanje odreuje kako objekat odgovara na zahteve drugih objekata i tipizira sve to on moe da uradi. Ponaanje objekta se realizuje kroz skup operacija, npr. u sistemu za registraciju, objekat ponuda kursa bi mogao imati ponaanja: dodaj studenta i izbrii studenta

Identitet oznaava da je svaki objekat jedinstven ak i kada je njegovo stanje identino stanju drugog objekta. Npr., Matematika 1 i Matematika 2 su dva objekta u sistemu za registraciju kurseva, iako su oba ponude kursa, svaki od njih ima jedinstveni identitet

Na primer, klasa CourseOffering moe biti definisana sledeim karakteristikama: Atributi lokacija, ponueno vreme

Operacije prikai lokaciju, prikai doba dana, dodaj studenta na spisak

Matematika 1 i matematika 2 su objekti koji pripadaju klasi CourseOffering

Ime klase treba da bude imenica u jednini koja najbolje karakterie apstrakciju

Kompletno ponaanje use case-a mora da se raspodeli na klase Kao rezultat ove faze dobija se Analysis Class Diagram (Conceptual

Model)

Analiziranje klasa

Pronalaenje klasa Dokument sa korisnikim zahtevima je dobar izvor koncepata,

Fiziki ili drugi opipljivi objekti, mesta, transakcije uloge ljudi (kupac, prodavac...) kontejneri za druge koncepte, drugi eksterni sistemi (udaljena baza podataka), abstraktne imenice (koliina, vest, informacija), organizacije, dogaaji, pravila/regulative, zapisi/logovi.

Prikupljanje koncepata na mehaniki nain nije dobra praksa, Potrebno je i ukljuivanje korisnika.

Klase predstavljaju objekte koje elimo da budui sistem podri

Tehnika za pronalaenje klasa koristi

tri razliite perspektive sistema: Granica izmeu sistema i aktera granine klase (Boundary class) Informacije koje sistem koristi klase entiteta (Entity class) Logika kontrole sistema kontrolne klase (Control class)

RegistrationForm

Boundary

CourseOffering

Entity

RegistrationManager

Control

exceptionRegistrationError

Analiziranje klasa

Granine klase(boundary class) Bave se komunikacijom izmeu okoline sistema i njegove unutranjosti; mogu da

obezbede interfejs korisniku ili drugom sistemu (akteru)

Granine klase izoluju sistem od promena u okruenju (npr., promene u interfejsima kod drugih sistema i promene u korisnikim zahtevima), uvajui ostatak sistema od posledica ovih promena

Sistem moe da ima nekoliko tipova graninih klasa: Klase korisnikog interfejsa (user interface classes) klase koje posreduju u komunikaciji sa ljudima,

korisnicima sistema

Klase interfejsa sistema (system interface classes) klase koje posreduju u komunikaciji sa drugim sistemima.

Klase interfejsa ureaja (device interface classes) klase koje obezbeuju interfejs ka ureajima koji detektuju spoljne dogaaje

Za inicijalnu identifikaciju graninih klasa preporuuje se jedna granina klasa po paru akter/use-case

Granine klase se koriste za modelovanje sistemskih interfejsa

Uloga granine klase Granina klasa (boundary class) se koristi za modeliranje

interakcije izmeu okruenja sistema i njegove unutranje funkcionalnosti Modeluju delove sistema koji zavise od okruenja Olakavaju razumevanje sistema Npr., izmena GUIa ili protokola komunikacije podrazumeva

menjanje samo granice klase, a ne i entiteta i klase kontrole

Primer: Granina klasa RegisterForCoursesForm prikazuje listu kurseva za tekui

semestar od kojih student moe da bira kurseve koje eli da doda na svoj raspored

CourseCatalogSystem je interfejs izmeu legacy sistema koji obezbeuje katalog svih kurseva na univerzitetu Ova klasa menja apstrakciju CourseCatalog koja je

identifikovana u analizi arhitekture

Smernice: granina klasa Kada identifikujete i opisujete klase analize, ne treba provoditi previe

vremena na detaljima Klase analize pojanjavaju razumevanje problema i predstavljaju pokuaj da se doe do

idealnog reenja.

Klase korisnikog interfejsa Koncentrisati se na to koje informacije su prezentovane korisniku

Nemojte se koncentrisati na UI detalje

Cilj nije GUI dizajn, u analizi, ve izdvojiti sva ponaanja koja su zavisna od okruenja

Modelujte samo kljune apstrakcije sistema, nemojte modelovati svaki button, list i druge elemente GUIa

Klase interfejsa sistema i ureaja Koncentrisati se na to koji protokoli se moraju definisati

Nemojte gubiti vreme o tome kako e protokoli biti implementirani

Ukoliko ve dobro definisan interfejs ka postojeem sistemu ili ureaju, onda bi granina klasa trebala da bude direktno izvedena iz te definicije interfejsa

Ukoliko ve postoji razraena komunikacija sa spoljnim sistemima ili ureajima, trebalo bi to notirati zbog kasnijeg dizajniranja sistema

Koncentriite se na odgovornosti, a ne na detalje!

Entitetske klase Entitetske klase predstavljaju kljune koncepte sistema koji se razvija

modeluju informaciju i pridrueno ponaanje koje je obino dugorono,

mogu da odslikavaju realni entitet

Izvori za kreiranje klasa entiteta su: Renik (razvijen tokom zahteva)

model domena poslovanja (razvijen tokom modeliranja poslovanja)

use case tok dogaaja (razvijen tokom zahteva)

kljune apstrakcije (identifikovanih u analizi arhitekture)

Uloga entitetske klase Entitetske klase predstavljaju skladita

informacija u sistemu Obino se koriste za predstavljanje

kljunih koncepata

Koriste se za uvanje i auriranje informacija o nekoj pojavi, kao to su dogaaj, osoba ili objekat iz realnog ivota Obino su perzistentni, sadre atribute i

ponaanja u toku ivotnog veka sistema

Glavne odgovornosti entiteta klase su skladitenje i upravljanje informacijama u sistemu

Tipini primeri entiteta klase u jednom sistemu bankarskog poslovanja su Raun i Klijent

Primeri kod sistema umreavanja su vor i link

Primer: kandidati entitetskih klase

Sistem registracije na kurs odrava informacije o studentu, to je nezavisno od toga to je student i akter u sistemu

Ova informacija o studentu se skladiti u klasi Student, bez obzira da li je ili ne student akter u sistemu

Kontrolna klasa Kontrolna klasa (control class) je

klasa koja se koristi za modelovanje ponaanja koje je specifino za jedan ili vie sluajeva korienja Kontrolna klasa enkapsulira

ponaanje odreenog use case-a Predstavljaju dinamiku sistema jer

rukuju sa glavnim zadacima i tokovima kontrole

Ponaanje kontrolne klase je usko povezano sa realizacijom odreenog use case-a

Kada sistem izvrava use case, tada se kreira i objekat kontrole koji nestaje kada se use case izvrava

Ne zahtevaju svi use case-ovi kontrolne klase

Uloga kontrolne klase Kontrolne klase obezbeuju ponaanje koje je:

Nezavisno od okruenja (kada se okruenje menja, klase kontrole se ne menjaju)

Definie logiku kontrole (redosled izmeu dogaaja) i transakcija izmeu use case-a

Malo se menja kada se interna struktura ili ponaanje entiteta klase menja

Koristi ili postavlja sadraj klase entiteta tako da mora da koordinira ponaanje ovih entiteta klase

Ne izvrava se uvek na isti nain

Identifikovati jednu klasu kontrole po use case-u Sloeniji use case-ovi mogu da zahtevaju i vie klasa kontrole Svaka klasa kontrole je odgovorna za kontrolisanje procesa koji implementira funkcionalnost use case-a

U primeru, klasa kontrole RegistrationController je definisana da vodi proces Register for courses unutar sistema

Primer pronalaenja klasa kontrole

Za svaku realizaciju use case-a, postoji jedan ili vie dijagrama klasa Dijagrami klasa osiguravaju da postoji konzistentnost u use case implementaciji kroz granice podsistema.

Primer: Ukupna analiza klasa

Raspodela use case ponaanja na klase Do sada smo identifikovali kandidate klasa analize, a sada treba da dodelimo

odgovornosti use case-a klasama analize i da to modelujemo tako to emo opisati nain saradnje instanci klasa u toku izvravanja use case-a

Moete kreirati dijagrame interakcije za svaku varijantu toka dogaaja use case-a Dijagrami interakcije pokazuju interakcije sistema sa akterima Dijagrami interakcije su dijagram sekvenci i dijagram saradnje (kolaboracije) Interakcije treba da ponu sa akterom, jer akter uvek poziva use case Ukoliko imate nekoliko instanci aktera na istom dijagramu, trudite se da ih stavite du

ivica dijagrama Interakcije izmeu aktera ne treba modelovati, jer po definiciji, akteri su spoljni i van su

domena sistema koji se razvija Znai, za svaki tok dogaaja use case-a:

Identifikovati klase analize Raspodeliti odgovornosti use case-a na klase Modelovati interakcije klasa analize na dijagramima interakcije

Smernice Moete koristiti stereotipove klasa analize kao vodilju:

Klase granice Ponaanja koja ukljuuju komunikaciju sa akterom

Klase entiteta Ponaanja koja ukljuuju podatke enkapsuliranih u apstrakciji

Klase kontrole Ponaanja specifinih za use case ili koja su deo veoma vanog toka dogaaja

Ko sadri podatke koji su neophodni za izvravanje ponaanja? Ukoliko jedna klasa sadri podatke, dodati i ponaanja

Najbolji sluaj je kada jedna klasa sadri sve informacije koje su potrebne za izvravanje ponaanja

Ukoliko vie klasa sadri podatke: Pridruiti ponaanja jednoj klasi i dodati relacije ka drugima

Kreirati novu klasu i dodati joj ponaanja i relacije ka drugim klasama

Staviti ponaanja u klasu kontrole i dodati relacije ka klasama koje su potrebne za izvravanje tih ponaanja

Dijagrami interakcije

Sekvencijalni dijagrami

Dijagram sekvenci Dijagram sekvenci (sequence diagram) opisuje interakcije

izmeu objekata ureenih hronolokim redom Pokazuje objekte koji uestvuju u interakciji i poruke koje alju vizuelizuje jedan scenario ili odreeno ponaanje poslovnih

procesa u vremenu Objekat (object) je prikazan kao vertikalna takasta linija

koja se zove lifeline Lifeline (ivotna linija) prikazuje postojanost objekata u

odreenom vremenu U simbolu objekta se navodi naziv objekta i njegove klase

odvojenih dvotakom i podvuenih Poruka (message) je komunikacija izmeu objekata koji

prenosi informaciju Poruka se prikazuje kao horizontalna linija od lifeline jednog

objekta do lifeline drugog objekta Strelica je oznaena nazivom poruke i njenim parametrima, a

moe biti oznaena i sa rednim brojem Fokus kontrole (focus of control) se obeleava kao uzak

pravougaonik i predstavlja vreme kada je kontrola fokusirana na objekat

Hijerarhijsko numerisanje (hierarchical numbering) - npr., poruka 1.1 zavisi od poruke 1.

Tekstovi (scripts) tekstualno opisuju tok dogaaja

Kada objekat alje poruku drugom objektu, to se prikazuje kao strelica izmeu njihovih ivotnih linija (lifelines) koja nosi naziv i parametre poruke

Sinhrone poruke (Synchronous message) Sinhrone poruke se koriste onda kada poiljalac eka dok primaoc ne zavri obradu poruke, tek

nakon toga pozivaoc moe da nastavi Veina metoda poziva u objektno orijentisanim programskim jezicima su sinhrone Zatvoren i popunjen vrh strelice oznaava da je poruka sinhronizovana Pravougaonik na ivotnoj liniji klase primaoca oznaava da se on odazvao na poruku Ukoliko hoete da prikaete da je primaoc zavrio obradu poruke i vratio kontrolu poiljaocu,

nacrtajte isprekidanu liniju od primaoca do poiljaoca Da bi dijagram bio lak za itanje, poeljno je prikazati povratnu strelicu jedino ukoliko vraa

vrednost poiljaocu, u drugim sluajevima je ne bi trebalo prikazivati

Poruke (messages)

Trenutne poruke (Instantaneous message) Poruke se smatraju trenutnim ukoliko je vreme koje je potrebno da stignu do pimaoca

zanemarljivo Nekim porukama je potrebno odreeno vreme da stignu do primaoca (npr. preko

mree) takve poruke se crtaju kosom linijom Ovakve poruke bi trebalo crtati jedino ukoliko se eli naglasiti da poruka putuje

sporim komunikacionim kanalom (i eventualno se eli dati iskaz o moguem kanjenju poruke)

Poruke

Pronaena poruka (Found message) Pronaena poruka je poruka kod koje pozivaoc nije prikazan (ili poiljaoc

nije poznat ili nije relevantno za interakciju ko je poiljaoc) Prikazuje se kao pun krug na vrhu strelice

Poruke

Asinhrone poruke (Asynchronous messages) Kod asinhrone poruke poiljaoc ne eka primaoca da zavri obradu poruke,

ve odmah nastavlja sa slanjem drugih poruka Poruke koje se alju u drugom procesu ili pozivu zapoinju novu nit su

primeri asinhronih poruka Asinhrona poruka se prikazuje kao otvorena strelica

Poruke

Povratna poruka (Message to self) Treba imati na umu da je svrha dijagrama sekvenci da prikae interakciju

izmeu klasa, te s toga treba dobro razmisliti kada se dodaju povratne poruke na dijagram

Poruke

Kreiranje i unitenje (Creation and destruction) Objekti koji se kreiraju na poetku interakcije se stavljaju pri vrhu dijagrama,

a svaki naredni se nastavljaju na prethodni, u trenutku njihovog nastajanja ivotna linija (lifeline) objekta se protee dokle god objekat egzistira Ukoliko se objekat tokom interakcije uniti, ivotna linija se prekida i stavlja

se oznaka X

Poruke

Uslovne interakcije (Conditional interaction) Poruka moe da ukljui uslov to oznaava da se poruka alje samo ukoliko je

ispunjen odreeni uslov Uslov se ispisuje u srednjoj zagradi ispred naziva poruke

Uslovne interakcije (Conditional interaction)

Kombinovani fragment opt (opt combined fragment) Ukoliko se nekoliko poruka alje pod istim uslovom onda se koristi opt kombinovani

fragment Kombinovani fragment se prikazuje kao veliki pravougaonik sa operatorom opt i

uslovom, i sadri sve uslovne poruke koje treba da se dogode pod datim uslovom Uslovne poruke ili opt kombinovani fragment je slian if konstrukciji u programskim

jezicima

Uslovne interakcije

Kombinovani fragment alt Ukoliko se ele prikazati nekoliko alternativnih interakcija, koristi se alt kombinovani fragment alt kombinovani fragment sadri operand za svaku alternativu Svaka alternativa ima uslov i sadri interakcije koje se dogaaju kada se eljeni uslov ispuni Najmanje jedan operand treba da se dogodi 'alt' kombinovani fragment je slian ugnjedenim if-then-else ili switch/case konstrukcijama kod

programskih jezika

Uslovne interakcije

Ponavljajua poruka Ukoliko ispred naziva poruke stoji simbol '*, znai da se poruka alje

uzastopnim ponavljanjem Uslov ukazuje pod kojim stanjem se poruka ponovo alje Dok god je uslov ispunjem poruka se ponavlja

Ponavljajua interakcija (Repeated interaction)

Slanje ponavljajue poruke elementima kolekcije Ponavljajua poruka koja se ee koristi je slanje iste poruke razliitim

elementima u kolekciji U ovakvom scenariju, primaoc ponavljajue poruke je viestruki objekat, a

uslov ukazuje na stanje koje kontrolie ovo ponavljanje Svaki element u kolekciji prihvata poruku Za svaki element pre nego to mu se poalje poruka proverava se stanje Obino, stanje predstavlja filter koji probira elemente iz kolekcije (npr., novi

klijenti, odrasli, svi filteri za kolekciju objekata Osoba)

Ponavljajua interakcija (Repeated interaction)

loop kombinovani fragment Ukoliko se vie poruka alje u istoj iteraciji, koristi se loop kombinovani

fragment Operator kombinovanog fragmenta je petlja (loop), a uslov predstavlja

stanje koje kontrolie petlju Primaoc ponavljajue poruke je kolekcija, a uslov uglavnom predstavlja

odreeni filter za elemente kolekcije

Ponavljajua interakcija

Definisanje proirenih notacija na dijagramu sekvenci

MVC

Dijagram predstavlja interakciju objekata koji podravaju kreiranje rasporeda (Create a Schedule), deo toka use case-a Register for Courses:

RegisterForCoursesForm zna koji podaci joj trebaju i kako da ih prikae, ali ne zna gde da ih potrai, to je odgovornosti RegistrationController Jedino je RegisterForCoursesForm u interakciji sa akterom Student RegistrationController razume kako su povezani Students i Schedules Jedino je klasa CourseCatalogSystem u interakciji sa spoljnim legacy Course Catalog System Uvoenje aktera je vano jer dijagram modeluje one elemente koji komuniciraju sa spoljnim svetom

Primer dijagrama sekvenci

Primer 1: Iznajmljivanje filma

Primer 2. Enroll in Seminar

Primer 3. Kreiranje zapisa i pretraga knjiga

Korisnik unosi karticu u ATM ATM zahteva PIN Korisnik unosi PIN Uneti PIN proverava sistem

banke Sistem vraa poruku o

validnosti ATM sistemu ATM nudi korisniku opcije Korisnik bira podizanje novca ATM zahteva unos iznosa

Primer 4. ATM

Kada korisnik ukuca URL u Web browser, browser e komunicirati sa Web serverom kako bi dobio dokument index.html

HTTP definie komunikacioni protokol za ovu komunikaciju izmeu Web browsera i Web servera.

Kada korisnik unese URL, Web browser

kreira HTTP zahtev, koji predstavlja paket informacija ukljuujui ime Web servera, naziv dokumenta i druge informacije o zahtevima.

Web browser onda alje taj HTTP zahtev

preko mree ka Web serveru. Web server pregleda web page

index.html i vraa ga kao deo odziva (paket informacija koji ukljuuje zahtevani dokument ili poruku o greci i druge meta podatke)

Kopira sadraj zahtevanog HTML fajla u HTTP odziv

Web browser interpretira i prikazuje

HTML

Primer 5

Klijent zahteva Logon (requestLogon()) sa SecurityLogon interfejsa koji zatim prikazuje Logon ekran (displayLogonScreen())

Klijent unosi name, pass u LogonScreen-u

Izvrava se petlja pod sledeim uslovom [while valid==false]:

Interfejs SecurityLogon alje na proveru user i pass (isValid(name, pass)) ka bazi account-a (AccountDB) AccountDB proverava da li naziv postoji u bazi (isInDatabase(name) u Sistemu (System) Sistem vraa tip korisnika (userType) AccountDB vraa info o validnosti (valid) Interfejs SecurityLogon prikazuje poruku o greci (displayErrorMessage()) Ponovo otvara tj. prikazuje Logon ekran (displayLogonScreen())

SecurityLogon proverava uslov: Ukoliko je [userType==admin] onda prikazuje Admin (displayAdmin()) Ukoliko je [userType==user] onda prikazuje user-a (displayUser())

Primer 6 Log-on scenario

Dijagrami interakcije

Dijagrami saradnje (komunikacije)

Dijagram saradnje (collaboration diagram) opisuje interakcije izmeu objekata prikazujui njihove veze i poruke koje mogu poslati jedni drugima

Objekat se predstavlja na jedan od tri naina:

NazivObjekta:NazivKlase NazivObjekta :NazivKlase

Veza (link) je relacija izmeu objekata koji mogu da alju poruke

Prikazuje se kao puna linija izmeu objekata Jedan objekat je u interakciji sa drugim objektima kroz njihove veze Veza se definie kao instanca asocijacije

Poruka (message) je komunikacija izmeu objekata koja prenosi informaciju

Oznaava se kao imenovana strelica pored linka, to znai da se link koristi za prenos ili za implementaciju predaje poruke ciljnom objektu Strelica ukazuje na pravac ciljnog objekta (onoga ko prima poruku) Brojevi redosleda se koriste radi oznaavanja redosleda poruka u interakciji

Dijagram saradnje (kolaboracije ili komunikacije)

Primer, prikazuje saradnju objekata koji podravaju use case Register for Courses i njegov tok dogaaja Create a Schedule

Dijagram saradnje olakava sagledavanje saradnje izmeu objekata. Npr., instance klase granice se nalaze na ivicama dijagrama, klase kontrole u sredini i klase entiteta prema dnu

Objekti se prikazuju prema svojim odgovornostima

Primer dijagrama saradnje

Treba modelovati veinu tokova dogaaja kako bi se osiguralo da su identifikovani svi zahtevi za operacijama klasa

Ponite sa opisivanjem osnovnog toka, koji je opti ili najvaniji tok dogaaja Zatim opiite varijante kao to su tokovi izuzetaka Trivijalne tokove, koji se odnose samo na jedan objekat, bi trebalo zanemariti

Primeri tokova izuzetaka: Rukovanje sa grekama: ta bi sistem trebao da radi kada bi se pojavila greka? Isticanje vremena: Ukoliko korisnik ne odgovori u odreenom periodu, onda bi use case trebao da preuzme odreene mere Pogreni inputi

Primeri opcionih tokova: Akter odluuje, od brojnih opcija, ta sistem sledee treba da radi Naredni tokovi dogaaja zavise od vrednosti atributa ili relacija Zavisi i od tipa podataka koji treba da se obradi

Jedan dijagram interakcije nije dovoljan

Dijagrami saradnje Istiu strukturu saradnje objekata i

pruaju jasniju sliku o relacijama i kontrolama koje postoje izmeu objekata koji uestvuju u use case-u

Dijagrami sekvenci Prikazuju jasnu sekvencu poruka i

bolje su za sloena scenarija u realnom vremenu

Ukljuuju hronoloku sekvencu, ali ne i relacije objekata

Vremenska dimenzija je veoma laka za itanje; operacije i parametre je lake predstaviti i lake se upravlja velikim brojem objekata

Dijagrami saradnje i sekvenci prikazuju sline informacije, ali na razliite naine Izbor je lini, mada RUP predlae da se dijagrami saradnje koriste u fazi analize, a

dijagram sekvenci kod projektovanja

: ProfessorCourseManager Math - Section 1: CourseOffering

Add professor (Professor)

: ProfessorCourseManager

Math : CourseOffering

1: Add professor (Professor)

Dijagrami saradnje vs. Dijagrami sekvenci

Dijagram komunikacije: log-on scenario

Veba 1: Napraviti dijagram komunikacije

Veba 1: Dijagram komunikacije

Veba 2: Napraviti dijagram saradnje za scenario best-case kod use case-a Buy soda

Veba 2: Dijagrama komunikacije (saradnje)

Veba 3: Car reservation

Veba 3: Dijagram komunikacije

Veba 4.

Veba 4.

Dijagrami aktivnosti

ta je dijagram aktivnosti?

Dijagram aktivnosti u use-case modelu se koristi za sagledavanje svih aktivnosti u use case-u i predstavljaju dinamiku sistema

Aktivnost predstavlja izvoenje nekog ponaanja u procesu rada Tok poslova (workflow) use-case-a opisuje ta je potrebno da sistem uradi kako bi obezbedio

vrednosti koje akter trai sastoji se od sekvence aktivnosti koje zajedno proizvode neto za aktera tok poslova se obino sastoji od osnovnog toka i jednog ili nekoliko alternativnih tokova

Struktura toka poslova se moe grafiki opisati uz pomo dijagrama aktivnosti Mogu predstaviti tok preko svih use case-ova ili tok unutar use case-a

Dijagram aktivnosti Dijagram aktivnosti moe da

ukljui sledee elemente: Stanja aktivnosti (activity

states) predstavljaju performanse aktivnosti u okviru toka posla

Tranzicija (trasitions) pokazuje koje stanje aktivnosti ide nakon prethodne aktivnosti

Odluke (decisions) ocenjuju stanja definisanih uslovima (guard conditions)

Uslovi odreuju koje aktivnosti e se izvriti

Odluke se koriste i tamo gde se niti ponovo spajaju

Odluke i uslovi omoguavaju da se prikau alternativne niti u toku poslova

Sinhronizacioni bar (synchronization bars) prikazuje paralelne podtokove

Omoguavaju prikazivanje konkurentnih (istovremenih) niti u toku poslova use case-a

Dijagram aktivnosti za korisniki servis

Start

Fork

decision

merge

Join Final Node

Action

Tokeni Konceptualni model dijagrama aktivnosti je zasnovan na

tokenima.

Tokeni

Svaki fork vor generie tokene prema broju putanja.

Inicijalni vor kreira jedan token

Svaki join prikuplja dobijene tokene i proizvodi jedan token na izlazu

Akcija zahteva token da bi se izvrila i proizvodi token kada se zavri

Tokovi objekata Objekti opisuju interfejs izmeu akcija

Call Data Receive Call Log Call

Receive Call Log Call

Objektni tok

Pinovi Call data Call data

Initiate Call

Call data

Pinovi Pinovi deklariu interfejs izmeu dve akcije.

Input Pin

Output Pin

Transformacija parametara

Objekti sa stanjem Objektni vorovi omoguavaju modelovanje promene

stanja

Call Data [created] Receive Call

Find Customer Type

Call Data [classified]

Data Store Datastore je stereotip za objekat koji trajno skladiti objekte.

Hvatanje signala Vremenski signal Dogaaj (prijem i slanje)

Tokovi kada je vremenski iskaz taan

Tokovi kada se desi neki dogaaj

alje se dogaaj kada se ue u tok

Primer dijagrama aktivnosti use case-a: Kreiranje kataloga

ProfessorRegistrar

Create Curriculum Select courses to teach

Assign professor to courses

Create catalog

Place catalog in book store Mail catalog to student

Open registration

No All professors assigned?

Yes

Primer: Obrada porudbine

Diskutovati razlike sa prethodnim dijagramom aktivnosti

Konceptualni dijagram klasa

Do sada smo identifikovali klase analize i dodelili im odgovornosti sluajeva korienja

Sada je vreme da se obrati panja na svaku klasu analize i da se sagleda ta svaki use case zahteva od njih

Osnovni cilj ovog fokusa je da se dokumentuje ono to klasa zna i ono ta radi

Koje su odgovornosti (ponaanja) klase? Ponaanje je iskaz onoga to se trai da objekat obezbedi Ponaanja ukljuuju jednu ili vie operacija klase u projektovanju i mogu biti opisane kao:

Akcije koje objekat moe da izvrava Znanje koje objekat odrava i prua drugim objektima

Kako pronai ponaanja? Mogu se izvui iz poruka sa dijagrama interakcije (za svaku poruku treba ispitati objekat klase kome je poruka poslata) Druga ponaanja se mogu izvui iz nefunkcionalnih zahteva

Ponaanja klase se mogu dokumentovati na dva naina:

Operacije: ukoliko se koristi ovaj pristup, onda je vano da se koristi neka konvencija imenovanja jer e se najverovatnije ukljuiti u dizajnu reenja Tekstualno: dokumentuju se u opisu klasa analize

Fokus na klase

Primer ponaanja klasa

Odravanje konzistentnosti Obratite panju na klase koje rade sve!

Svaka klasa bi trebala da ima nekoliko odgovornosti Klasa sa samo jednom operacijom je verovatno suvie

jednostavna i postavlja se pitanje emu slui Klasu koja ima previe operacija bi trebalo razdvojiti u nekoliko

klasa

Obezbediti da ne postoje dve klase sa slinim odgovornostima Treba ih kombinovati i aurirati dijagram interakcije

ta je atribut?

U toku analize ne treba gubiti vreme na signaturu atributa

Pronalaenje atributa Svojstva/karakteristike identifikovanih klasa, Informacije koje uvaju identifikovane klase, Imenice koje nisu postale klase,

Informacija ija je vrednost znaajna Informacija koja predstavlja jedinstveno svojstvo objekta, Informacija koja nema ponaanje.

ta je asocijacija? Asocijacija predstavlja relaciju izmeu dva ili vie objekata

razliitih klasa Veina asocijacija je jednostavna (izmeu tano dve klase) i

prikazuje se kao puna linija izmeu simbola klasa Ponekad klasa ima asocijaciju na samu sebe

Uglavnom oznaava da jedna instanca klase ima asocijaciju ka drugoj instanci iste klase

Naziv asocijacije treba da bude glagol

Fokusirajte se samo na asocijacije koje su neophodne za realizaciju use case-a Svakoj asocijaciji treba dati nazive i multiplikativnosti

Pronalaenje relacija

ta je agregacija? Specijalni oblik asocijacije koja modeluje relacije izmeu celine i njenih delova

Prazan romb je na strani celine ukazuje na relaciju agregacije Kada je klasa u relaciji agregacije sa samom sobom, to znai da jedna instanca klase se

sastoji od drugih instanci iste klase Relaciju agregacije bi trebalo koristiti kada je:

Jedan objekat fiziki sainjen od drugih objekata (npr., kola su fiziki sainjena od motora, tokova i dr.)

Jedan objekat logiki sastavljen od drugih objekata (npr., porodica je sastavljena od roditelja i dece)

Jedan objekat fiziki sadri druge objekte (npr., avion fiziki sadri pilota) Na slici, relacija izmeu studenta (Student) i rasporeda (Schedule) je modelovana

kao agregacija, jer je raspored nerazdvojivo vezan za odreenog studenta Raspored van konteksta studenta nema nikakvog smisla u sistemu Course Registration Relacija od Schedule do CourseOffering je asocijacija jer kursevi mogu da se pojave na vie

rasporeda

Asocijacija ili agregacija? Ukoliko su dva objekta usko povezana relacijom celina-deo, onda je relacija

agregacija Ukoliko modelujete prodavnicu kola, onda relacija izmeu kola i vrata treba da bude

modelovana kao agregacija, jer kola uvek dolaze sa vratima, a vrata se nikad samostalno ne prodaju

Ukoliko su dva objekta nezavisna onda je relacija asocijacija Ukoliko modelujete prodavnicu auto delova, onda relacija izmeu kola i vrata moe da

bude asocijacija, jer onda telo kola moe da se pojavi nezavisno od vrata

Relacija kompozicije je slina relaciji agregacije samo to se kod unitavanja objekta unitava i klasa koja je deo tog objekta

Kompozicija

ta su role (uloge)? Asocijacije sadre neku ulogu u relaciji izmeu klasa

Uloga ili rola se ispisuje na krajevima linije asocijacije Uloga mora imati naziv (obino imenica)

Multiplikativnost Za svaku rolu se navodi multiplikativnost klase Multiplikativnost je broj objekata klase koji se moe pridruiti jednom

objektu druge klase Kada je multiplikativnost nula, onda je takva asocijacija opciona Belei se na oba kraja relacije Multiplikativnost odgovara na dva pitanja:

Da li je asocijacija obavezna ili opciona? Koji je minimalni, a koji maksimalni broj instanci koje mogu biti povezane ka drugoj

instanci?

Primer viestruke asocijacije

Kada postoje viestruke asocijacije izmeu dve klase, onda bi one trebalo da prikazuju razliite uloge, a ne pozivanje razliitih operacija Obavezno je imenovanje asocijacija

Primer pronalaenja relacija

Primer generalizacije

Primer konceptualnog dijagrama klasa

Poreenje modela podataka (ERD) i dijagrama klasa

Primer grupisanja klasa u pakete

Poreenje konceptualnog i dijagrama klasa

Dijagram klasa

Poreenje sa dijagramom klasa

Veba 1: Nacrtati dijagram Fakultet ima vie Katedri

Nastavnici mogu biti pridrueni odgovarajuim katedrama

Nastavnik moe biti ef katedre

Na katedri se drzi vie kurseva

Studenti su lanovi fakulteta

Studenti pohaaju kurseve

Klijent (ime, adresa, id) rezervie avio kartu

Za odreeni let moe da se izda vie avio karata

Klijent pravi rezervaciju boravka (od, do)

Rezervacija hotela (br sobe, od, do, broj noi) se vri za odgovarajueg klijenta

Boravak (od, do) klijenta mora da bude usaglaen sa avio kartom i rezervacijom hotela

Veba 2.

Dijagram klase prema slojevima arhitekture

Problem 1

Vrti Radosno detinjstvo

Opis problema (1) Opis problema podrazumeva veoma precizno vodjenje i

auriranje evidencije dece mladje od 6 godina u informacionom podsistemu predkolske ustanove Radosno detinjstvo.

Vodjenje i auriranje evidencije dece predstavlja vodjenje matine knjige dece (ime i prezime, datum i mesto roenja, ime roditelja odnosno staratelja, matini broj, adresu i mesto stanovanja sa brojem telefona roditelja, duinu boravka deteta u predkolskoj ustanovi, naziv obrazovnog programa koji se realizuje, naziv objekta u kojem dete boravi, datum upisa deteta u ustanovu, datum ispisa iz ustanove i sl), kartona sa podacima o razvoju dece, otvaranje zdravstvenog kartona dece.

Opis problema (2) Vrti upisuje decu nakon raspisivanja oglasa za upis.

Za upis je potrebno popuniti zahtev i doneti potvrdu od pedijatra.

Ukoliko vrti pohaa dvoje dece iz iste porodice prvo dete plaa punu cenu, a drugo dete ima 20% popusta na punu cenu.

Ukoliko vrti pohaa troje dece iz iste porodice prvo dete plaa punu cenu, drugo dete ima 20% popusta na punu cenu, a tree dete ima 30% popusta na punu cenu.

Upisivanje dece Prijava dece podrazumeva razmatranje pristiglih prijava za upis na

osnovu uslova konkursa, formiranje preliminarne liste primljene dece, formiranje liste odbijene dece koje se nakon toga objavljuju.

Odobrenje popusta.Nakon objavljene konane rang liste primljene dece, vri se provera njihovih podataka,kako bi se utvrdilo da li imaju pravo na popust. To se postie pretragom ve postojeih podataka roditelja dece koja pohadjaju vrti.

Reklamacija na odluku podrazumeva ponovno razmatranje pojedinih odbijenih prijava i mogue auriranje preliminarne rang liste.

Zavodjenje u matinu knjigu podrazumeva unos podataka o deci i njihovim roditeljima u matinu knjigu.

Uplata za upis predstavlja evidenciju svih uplata vezanih za upis, u smislu akontacije i kolarine.

Generisanje izvetaja podrazumeva spisak primljene dece, spisak odbijene dece, izvetaja o svim uplatama.

Logika arhitektura sistema

Identifikovanje uesnika Roditelj Uprava vrtia Komisija za upis Sekretar

Specifikacija sluaja upotrebe Ime sluaja korienja Zavoenje u matinu knjigu Opis Svako dete mora biti zavedeno u svojoj starosnoj grupi, a ifre

roditelja i njihovog deteta se moraju podudarati. Takoe,

neophodno je da budu uneti svi podaci o detetu, koji se trae. Preduslovi Obavezna je provera godine roenja deteta Zadovoljavajui ishod uslova Dete je zavedeno u svojoj starosnoj grupi Nezadovoljavajui ishod

uslova Dete nije zavedeno

Primarni akteri Sekretar Sekundarni akteri Nema Okida Sekretar konsultuje sistem za unos novih podataka Glavni tok (osnovni scenario) Koraci Akcija

1 Sekretar trai od sistema prikaz forme za unos u matinu knjigu

2. Sistem otvara prozor i trai unos godine roenja deteta 3. Sekretar unosi traeni podatak. 4. Sekretar pritiska taster za potvrdu (taster Dodeli) i poziva

sistem da dodeli ifru za unetu godinu. 5. Sistem prihvata zahtev .

Specifikacija sluaja upotrebe (2) Glavni tok (osnovni scenario) Koraci Akcija

6. Sistem automatski dodeljuje grupu za unetu godinu rodjenja.

7. Sistem dozvoljava unos podataka sa prikazanom ifrom deteta.

8. Sekretar unosi ime,prezime i ostale line podatke deteta.

9. Sekretar izabere pol, datum upisa i datum rodjenja deteta

10. Sekretar unosi ime i ostale podatke roditelja deteta. 11. Sekretar pritiska taster za potvrdu(dugme Snimi) 12. Sistem pamti novo dete. 13. Sistem obavetava o uspenosti evidencije

Alternativni scenario 10.1. 10.2. 10.3.

Sekretar pogresno unese podatke Sekretar trai ponitenje unosa Sistem mu odobrava ponitenje

Alternativni scenario 2 3.1. 3.2.

Sekretar ne unese godinu roenja, a pritisne taster dodeli. Sistem mu javi da je dolo do greke.

Identifikovanje kljunih apstrakcija Konceptualni model sluaja upotrebe

Analiza sluaja upotrebe Izrada sekvencijalnog dijagrama Izrada dijagrama komunikacije Izrada dijagrama klasa

Objektno orjentisana analiza i projektovanje sa UML-omAnaliza i projektovanjeAnaliza i projektovanjeAnaliza vs. Dizajn (projektovanje)Analiza i dizajn nisu top-down ili bottom-upta je arhitektura?Arhitektura softvera: model 4+1 pogledAktivnosti i odgovornostiOdgovornosti arhitekte softveraOdgovornosti projektanta (dizajnera)ta je realizacija use case-a?Analiza i dizajn u iterativnom procesuAnaliza arhitektureAnaliza arhitektureDefinisanje arhitekture kandidataPodseanje: ta je paket?Relacije izmeu paketa: ZavisnostPrimer: Relacije izmeu paketa u problemu registracije kursevaLogiki prikaz arhitektureIzbegavanje krunih zavisnostiPaterni i okvirita je patern arhitekture?Paterni arhitekture: SlojeviModeliranje slojeva arhitekturePrimer troslojne arhitektureModel-View-Controller (MVC) patternModel-View-Controller (MVC) patternModel-View-Controller (MVC)MVC implementacijaCevi i filteri (Pipes and filters)Cevi i filteri (Pipes and filters)Primer: Printing Web servicePrimer:UNIX Command PipelinesPrimer: Obrada slikePrimer: Kompajliranje kodaTabla (Blackboard)ProblemReenjeUse Case analizaUse Case analizaGde smoPregled use case analizeNamena use case analizeDodatni opisi use case-ovata je use case realizacija?Use case realizacijata su kljune apstrakcije? Primer: Kljune apstrakcijeIdentifikovanje kljunih apstrakcija na primeru klase LiftIdentifikovanje kljunih apstrakcija na primeru klase LiftControllerIdentifikovanje klasaDijagrami klasaAnaliziranje klasaPronalaenje klasaAnaliziranje klasaGranine klase(boundary class)Uloga granine klasePrimer: Granina klasaSmernice: granina klasaEntitetske klaseUloga entitetske klasePrimer: kandidati entitetskih klaseKontrolna klasaUloga kontrolne klasePrimer pronalaenja klasa kontrolePrimer: Ukupna analiza klasaRaspodela use case ponaanja na klaseSmerniceDijagrami interakcijeDijagram sekvenciPoruke (messages)PorukePorukePorukePorukePorukeUslovne interakcije (Conditional interaction)Uslovne interakcijeUslovne interakcijePonavljajua interakcija (Repeated interaction)Ponavljajua interakcija (Repeated interaction)Ponavljajua interakcijaDefinisanje proirenih notacija na dijagramu sekvenciMVCPrimer dijagrama sekvenciPrimer 1: Iznajmljivanje filmaPrimer 2. Enroll in SeminarPrimer 3. Kreiranje zapisa i pretraga knjigaPrimer 4. ATMPrimer 5Primer 6 Log-on scenarioDijagrami interakcijeDijagram saradnje (kolaboracije ili komunikacije)Primer dijagrama saradnjeJedan dijagram interakcije nije dovoljanDijagrami saradnje vs. Dijagrami sekvenciDijagram komunikacije: log-on scenarioVeba 1: Napraviti dijagram komunikacijeVeba 1: Dijagram komunikacijeVeba 2: Napraviti dijagram saradnje za scenario best-case kod use case-a Buy sodaVeba 2: Dijagrama komunikacije (saradnje)Veba 3: Car reservationVeba 3: Dijagram komunikacije Veba 4. Veba 4. Dijagrami aktivnostita je dijagram aktivnosti?Dijagram aktivnostiDijagram aktivnosti za korisniki servisTokeniTokeniTokovi objekataPinoviObjekti sa stanjemData StoreHvatanje signalaPrimer dijagrama aktivnosti use case-a: Kreiranje katalogaPrimer: Obrada porudbineDiskutovati razlike sa prethodnim dijagramom aktivnostiKonceptualni dijagram klasaFokus na klasePrimer ponaanja klasa Odravanje konzistentnosti ta je atribut?Pronalaenje atributata je asocijacija?Pronalaenje relacijata je agregacija?Asocijacija ili agregacija?Kompozicijata su role (uloge)?MultiplikativnostPrimer viestruke asocijacijePrimer pronalaenja relacijaPrimer generalizacijePrimer konceptualnog dijagrama klasaPoreenje modela podataka (ERD) i dijagrama klasaPrimer grupisanja klasa u paketePoreenje konceptualnog i dijagrama klasaDijagram klasaPoreenje sa dijagramom klasaVeba 1: Nacrtati dijagramVeba 2.Dijagram klase prema slojevima arhitektureProblem 1Opis problema (1)Opis problema (2)Upisivanje deceLogika arhitektura sistemaIdentifikovanje uesnikaSpecifikacija sluaja upotrebeSpecifikacija sluaja upotrebe (2)Identifikovanje kljunih apstrakcijaAnaliza sluaja upotrebe