RAZVOJ POSLOVNIH APLIKACIJA UML MODELOVANJE Branko Latinovi UVOD

RAZVOJ POSLOVNIH APLIKACIJA UML MODELOVANJE Branko Latinović

UVOD UML (Unified Modeling Language, 1996. g. ) je nastao objedinjavanjem tri metode modelovanja: Booch-ove, OMT (Object Modeling Technique, Rumbaugh) i OOSE (Object Oriented Software Engineering, Jacobson) ideja: prevazilaženje problema neusaglašenosti postojećih metoda i formiranje jedinstvenog jezika za modelovanje koji bi bio opšte prihvaćen kao standard UML je skup grafičkih notacija zasnovanih na jedinstvenom metamodelu. grafička notacija: skup grafičkih elemenata koji definišu sintaksu jezika metamodel: dijagram koji opisuje koncepte jezika za modelovanje ni grafička notacija, ni metamodel ne moraju se strogo primenjivati veći broj dijagrama za modelovanje (UML 2. 4 iz 2011. g. 14 dijagrama) i OCL jezik za specifikaciju ograničenja

UML DIJAGRAMI Dijagram klasa Dijagram strukture ◄ Dijagram profila Dijagram komponenata Dijagram složene strukture ◄ Dijagram raspoređivanja ◄ Dijagram objekata Dijagram paketa Dijagram ponašanja Dijagram aktivnosti ◄ Dijagram slučajeva korišćenja ◄ Dijagram mašine stanja Dijagram interakcije Dijagram sekvence Dijagram komunikacije Dijagram pregleda interakcije ◄

SLUČAJEVI KORIŠĆENJA Slučajevi korišćenja su načini prikupljanja funkcionalnih zahteva sistema. Oni opisuju uobičajene interakcije između korisnika i sistema u obliku priče. Slučaj korišćenja je skup scenarija povezanih jednim ciljem korisnika. Scenario je niz koraka koji opisuje interakciju između korisnika i sistema. Primer tri scenarija: 1) Kupac pregleda katalog i dodaje proizvode u korpu. Kada hoće da plati, on daje informacije o načinu dostave i platnoj kartici i potvrđuje kupovinu. Sistem proverava ispravnost podataka o platnoj kartici i potvrđuje prodaju. 2) Podaci o kartici su netačni. 3) Ako je kupac redovan, nije potrebno uzimati podatke o dostavi i kartici. Razlika između slučaja korišćenja i funkcija sistema je u tome što imaju različitu namenu. Funkcije opisuju sistem, a slučajevi korišćenja opisuju kako korisnici koriste sistem.

SADRŽAJ SLUČAJA KORIŠĆENJA Primer uobičajenog zapisa Način pisanja sadržaja slučaja korišćenja nije standardizovan, pa format zavisi od slučaja. Postupak pisanja 1. Navesti osnovni uspešni scenario u vidu numerisanih koraka. 2. Navesti sva odstupanja od osnovnog scenarija, tj. proširenja, sa referisanjem na mesta povratka (ako ih ima). Korisni saveti • Svaki korak predstavlja deo interakcije učesnika i sistema. • Opis koraka mora biti jasan i da ukazuje na njegovog izvršioca. • Korak pokazuje nameru učesnika, a ne način kako se nešto ostvaruje. Kupovina proizvoda Nivo cilja: osnovni Osnovni uspešan scenario: 1. Kupac pregleda katalog i bira proizvode koje hoće da kupi 2. Kupac završava pregled kataloga 3. Kupac unosi podatke o isporuci (adresa, isporuka kroz tri dana) 4. Sistem prikazuje sve podatke o troškovima (sa poštarinom) 5. Kupac unosi podatke o platnoj kartici 6. Sistem proverava podatke o načinu plaćanja 7. Sistem odmah potvrđuje prodaju Proširenja: 3. a Kupac je redovan : 1 Sistem prikazuje podatke o isporuci, cenama i iznosu računa : 2 Kupac potvrđuje ili menja podrazumevane vrednosti, povratak na korak 6. 6. a Podaci o platnoj katrici nisu ispravni : 3 Kupac može ponovo uneti podatke o kartici ili prekinuti rad

UKLJUČENI SLUČAJEVI KORIŠĆENJA jedan, složeniji slučaj korišćenja može da uključuje (includes) druge, jednostavnije slučajeve korišćenja ne postoji standardan način tekstualnog prikazivanja uključenog slučaja korišćenja, ali se kao pogodna mogućnost preporučuje podvlačenje koje ukazuje na hipervezu Primer Kupovina proizvoda Kada se koriste uključeni SK? Nivo cilja: osnovni Osnovni uspešan scenario: • Kupac pregleda katalog i bira proizvode koje hoće da kupi • Kupac završava pregled kataloga • . . Pogodni za opisivanje složenih koraka koji bi zauzeli puno prostora u osnovnom scenariju. Pogodni za opisivanje koraka koji se ponavljaju u više slučajeva korišćenja. Nije pogodno praviti više nivoa ugnježdavanja.

DODATNE INFORMACIJE Slučaju korišćenja mogu se dodati i sledeće opšte informacije: preduslov (pre-condition) opisuje šta mora biti ispunjeno pre nego što sistem dopusti da počne slučaj korišćenja garancije (guarantee) opisuju stanje sistema na kraju slučaja korišćenja okidač (trigger) određuje događaj koji dovodi do započinjanja slučaja korišćenja Saveti: Količina neophodnih detalja zavisi od rizika u posmatranom slučaju korišćenja. Elemente treba oprezno dodavati, jer slučaj korišćenja mora bit sažet i čitljiv (detaljni opisi se obično ne čitaju).

UČESNICI Učesnici su korisnici sistema koji izvode slučajeve korišćenja. veći broj ljudi može predstavljati jednog učesnika (na primer kupci) Ko može biti učesnik? jedna osoba se može nalaziti na mestu više učesnika (na primer direktor prodaje može obavljati i ulogu prodavca) učesnik ne mora biti ljudsko biće (može, na pr. biti računar) Odnos učesnik – slučaj korišćenja? jedan učesnik može izvoditi više slučajeva korišćenja jedan slučaj korišćenja može imati više učesnika. Glavni učesnik (primary actor) je onaj koji traži uslugu od sistema. Ostali učesnici sa kojima sistem komuncira u datom slučaju korišćenja su sporedni učesnici (secondary actors)

DIJAGRAM SLUČAJEVA KORIŠĆENJA Dijagram slučajeva korišćenja je grafički prikaz sadržaja skupa slučajeva korišćenja. Ukazuje na granice sistema i njegovu interakciju sa spoljnim svetom. Prikazuje učesnike, slučajeve korišćenja i veze između njih: koji učesnici izvršavaju koje slučajeve korišćenja koji slučajevi korišćenja uključuju druge slučajeve korišćenja Ažuriranje podataka o računima Definisanje ograničenja Komercijalni direktor Analiza rizika Utvrđivanje cene «include» uključuje Sistem naplate Utvrđivanje vrednosti Komercijalista učesnik Utvrđivanje potražnje Prodavac slučaj korišćenja granica sistema

NIVOI SLUČAJEVA KORIŠĆENJA Slučajevi korišćenja se mogu razvrstati po sledećim nivoima: Osnovni nivo (sea-level) – centralni slučajevi koji obično predstavljaju pojedinačne interakcije između glavnog učesnika i sistema. Oni daju rezultat značajan za glavnog učesnika. Niži nivo (fish-level) - slučajevi korišćenja uključeni u slučajeve osnovnog nivoa. Viši nivo (kite-level) – obično poslovni slučajevi korišćenja koji pokazuju kako se slučajevi osnovnog nivoa uklapaju u širi kontekst poslovnih interakcija. Najveći broj slučajeva korišćenja treba da bude na osnovnom nivou.

DIJAGRAMI KLASA Dijagram klasa opisuje tipove objekata u sistemu i različite vrste statičkih veza koje postoje među njima, kao i ograničenja u načinu njihovog povezivanja. dijagrami klasa su najčešće korišćeni dijagrami UML-a najbogatiji skup tehnika za modelovanje u UML-u imaju upravo dijagrami klasa Model klase Primer klase Ime klase Porudžbina Atributi klase datum. Naručivanja: Date[0. . 1] plaćeno. Unapred: Boolean[1] Broj: String[1] cena: Novac Operacije klase pošalji zaključi

SVOJSTVA KLASE Svojstva klase predstavljaju strukturne karakteristike klase. Načini predstavljanja na dijagramu Upotreba Atributi za predstavljanje manje važnih svojstava, kao što su datumi ili logičke promenljive Asocijacije za eksplicitno isticanje važnih klasa u sistemu Svojstva klase Većina informacija se može prikazati ravnopravno na oba navedena načina, mada postoje i neke razlike među njima. Izbor načina prikazivanja se ne zasniva na značenju pojmova, već na tome šta želimo da naglasimo na dijagramu.

KARDINALNOST Kardinalnost pokazuje na koliko objekata se odnosi neko svojstvo. Definiše se donjom (DG) i gornjom granicom (GG) u obliku DG. . GG, za koje važe sledeća pravila: donja granica može biti bilo koji pozitivan broj ili 0. gornja granica može biti bilo koji pozitivan broj ili * (znači da nema ograničenja). ako su donja i gornja granica jednake, može se koristiti jedan broj. umesto 0. . *, što je čest slučaj, može se koristiti samo *. Primeri 2. . 4 1 0. . 1 * (pr. U timu mogu da učestvuju 2 do 4 programera. ) (pr. Jedna porudžbina mora imati tačno jednog kupca. ) (pr. Za klijentsku firmu može biti zadužen poseban predstavnik, ali ne mora. ) (pr. Kupac može poslati nula ili više porudžbina, nema gornje granice. ) UML 2 ne dozvoljava kardinalnost sa prekidima (bilo dozvoljeno u UML 1).

ATRIBUTI KLASE (1) Atribut opisuje neko svojstvo u jednom redu teksta unutar odgovarajućeg dela klase. Potpuni oblik zapisa atributa vidljivost ime: tip kardinalnost = podrazumevana-vrednost {opis-svojstva} Objašnjenje vidljivost (visibility) označava da li je atribut javni (+) ili privatni (-) ime (name) određuje ime atributa u klasi tip (type) ukazuje na tip atributa u klasi kardinalnost (multiplicity) ukazuje na broj objekata na koje se odnosi atribut podrazumevana-vrednost (default value) je vrednost atributa u novom objektu opis-svojstva (property string) definiše dodatne osobine atributa

ATRIBUTI KLASE (2) Primer 1 -name: String [1] = “Bez naslova” {read. Only} Primer 2 Porudžbina + datum. Naručivanja: Date[0. . 1] + plaćeno. Unapred: Boolean[1] + stavke: Stavka. Porudzbine[*] {ordered}

ASOCIJACIJE Asocija opisuje neko svojstvo punom linijom između dve klase, usmerenom od izvorne klase ka odredišnoj. Ime svojstva je na odredišnom kraju asocijacije, kao i njena kardinalnost. Odredišna klasa određuje tip svojstva. Kardinalnost asocijacije može biti definisana na oba kraja linije. ime svojstva Izvorna klasa kardinalnost Odredišna klasa Primer Date 0. . 1 + datum. Naručivanja Porudžbina 1 izvor odredište * stavke {ordered} Stavka. Porudžbine + plaćeno. Unapred 1 Boolean

OPERACIJE KLASE (1) Operacije su aktivnosti koje klasa može da obavi. operacija klase metod klase Vrste operacija: Upiti deklaracija procedure telo procedure ne menjaju stanje sistema, tj. nemaju sporedne efekte vraćaju pročitanu vrednost iz klase Primer polimorfizma redosled izvršavanja im se može Nadtip operacija menjati, a da se ne promeni ponašanje sistema metod Modifikatori Podtip operacija metod 1 metod 2 metod 3 menjaju stanje sistema obično nemaju rezultat

OPERACIJE KLASE (2) Sintaksa operacija na UML-u vidljivost ime (lista-parametara) : tip-rezultata {opis-svojstva} Primer operacije + stanje. Na (datum: Datum) : Novac vidljivost označava da li je operacija javna (+) ili privatna (-) Objašnjenje ime je niz znakova lista-parametara je lista parametara operacije Sintaksa parametara operacije je: smer ime: tip = podrazumevana-vrednost • ime, tip i podrazumevana-vrednost imaju isto značenje kao u sintaksi atributa • smer pokazuje da li je parametar ulazni (in), izlazni (out), ili ulazno-izlazni (inout) tip-rezultata ukazuje na tip rezultata operacije opis-svojstva ukazuje na svojstva operacije (pr. query)

GENERALIZACIJA Generalizacija podrazumeva smeštanje zajedničkih osobina u opštu klasu koja predstavlja nadtip. Sve što važi za klasu koja je nadtip, važi i za klasu koja je podtip. Nadtip Podtip 1 Podtip 2 Generalizacija se realizuje nasleđivanjem (inheritance). Važne posledice nasleđivanja su: zamenljivost (substitutability) koja omogućava da se umesto nadtipa može koristiti objekat bilo kog podtipa te klase polimorfizam koji omogućava dobijanje različitih odgovora ne vodeći računa o pozivanju od strane klijenta

ZAVISNOSTI Zavisnost između dva elementa postoji ako promene definicije jednog elementa, tzv. davaoca (supplier), mogu izazvati promene drugog elementa, tzv. klijenta (client). Razlozi zavisnosti između klasa: Primer jedna klasa šalje poruku drugoj jedna klasa sadrži drugu klasu klijent Prozor za pregled bonusa objekat jedne klase prosleđuje objekat druge klase kao parametar neke operacije Upravljanje zavisnostima je vrlo važno jer se svaka promena u sistemu reflektuje na druge elemente koji se onda moraju menjati. Izmene u klasama se reflektuju samo preko interfejsa. zavisnost davalac Zaposleni Podaci o zaposlenima Podaci o bonusima

OGRANIČENJA Ograničenja u sistemu se u velikoj meri opisuju osnovnim elementima dijagrama klasa kao što su atribut, asocija i generalizacija. Ipak, ne mogu se sva ograničenja prikazati na taj način. UML dopušta proizvoljan opis ograničenja uz jedino pravilo da taj opis mora biti između vitičastih zagrada. Predstavljanje ograničenja prirodni jezik (neprecizan, ali se preporučuje) programski jezik OCL (Object Constraint Language) UML-ov formalni jezik ograničenja (neophodno dobro razumevanje jezika) Primer {onemogućiti neregularnost: student mora položiti ispit pre upisa ocene}

DIJAGRAMI SEKVENCE Dijagram sekvence (DS) opisuje saradnju objekata prilikom neke aktivnosti. DS uspešno prikazuju saradnju, tj. interakciju između objekata, ali nisu pogodni za precizno definisanje ponašanja objekata. Korisni su kada treba analizirati više slučajeva korišćenja. DS opisuju interakciju pomoću: Ime klase linije života (lifeline) – vertikalna isprekidana linija života linija koja predstavlja učesnika u interakciji poruka poruke (message) – linije završene strelicom koje se čitaju odozgo na dole trake aktivnosti (activation bar) – pravougaonik na liniji života koji pokazuje kada je učesnik aktivan u interakciji traka aktivnosti

PRIMER Imamo porudžbinu i hoćemo da joj uputimo komandu koja će izračunati cenu. Da bi izvršila komandu, porudžbina mora da pregleda sve svoje stavke i izračuna njihove cene na osnovu pravila formiranja cena odgovarajućih proizvoda. Kada obradi sve stavke, porudžbina izračunava ukupan popust na osnovu pravila koja važe za kupca.

CENTRALIZOVANO UPRAVLJANJE porudžbina računaj. Cenu primljena poruka stavka porudžbine uzmi. Količinu proizvod kupac učesnik uzmi. Proizvod proizvod uzmi. Podatke. OCeni povratak računaj. Osnovnu. Cenu povratni poziv računaj. Popuste uzmi. Podatke. OPopustima Kod centralizovanog upravljanja, jedan učesnik obrađuje najveći deo podataka, dok ga drugi učesnici snabdevaju njima. Ovaj način upravljanja je jednostavniji i pogodan za početnike, s obzirom da se celokupna obrada odvija na jednom mestu.

DISTRIBUIRANO UPRAVLJANJE porudžbina stavka porudžbine proizvod kupac računaj. Cenu parametar računaj. Cenu uzmi. Cenu(količina: number) uzmi. Cenu. Sa. Popustom(porudžbina) uzmi. Osnovnu. Cenu povratak cena. Sa. Popustom Kod distribuiranog upravljanja, obrada je raspoređena između više učesnika, od kojih svaki izvršava deo algoritma. Ovaj način upravljanja je manje pregledan, ali je efikasan i obično ga koriste iskusniji projektanti.

PETLJE I USLOVI Notacija za prikazivanje petlji porudžbina proizvod stavka kupac Uvode se okviri interakcije (interaction frames) koji obuhvataju deo dijagrama sekvence (fragment). loop uzmi. Količinu Svaki okvir sadrži operator, a može mu biti pridružen i uslov. [for each stavka] operator uslov uzmi. Proizvod proizvod uzmi. Podatke. OCeni računaj. Osnovnu. Cenu računaj. Popuste uzmi. Podatke. OPopustima okvir interakcije Napomena: Dijagrami sekvence nisu pogodni za prikazivanje petlji i uslova, pa je za njihovo modelovanje bolje koristiti dijagrame aktivnosti ili kod.

KREIRANJE I BRISANJE UČESNIKA Notacija za pravljenje učesnika Nacrtati strelicu poruke koja je povezana neposredno sa oznakom učesnika. Ime poruke se može zadati (nov), ali ne mora. Ako učesnik odmah po nastanku započne aktivnost, traka aktivnosti se crta neposredno ispod oznake učesnika. Upravljač upit nad bazom podataka nov Upit pravljenje Naredba baze podataka izvrši Notacija za brisanje učesnika rezultati izdvoj rezultate Oznaka za brisanje učesnika je X. Brisanje jednog učesnika od strane drugog označava se strelicom poruke. X na kraju linije života znači da učesnik briše samog sebe. nov zatvori rezultati brisanje samog sebe brisanje iz drugog objekta

DIJAGRAM AKTIVNOSTI Dijagrami aktivnosti služe za opisivanje logike procedura, poslovnih postupaka i toka posla. grananje odluka uslov Akcije spajanje Paralelno ponašanje Akcije stapanje Uslovno ponašanje Postoji razlika između aktivnosti i akcije. Aktivnost predstavlja niz akcija, pa dijagram aktivnosti prikazuje aktivnost koja je sačinjena od akcija. Čvorovi u dijagramu aktivnosti su akcije, a ne aktivnosti.

PRIMER početni čvor Primljena narudžbenica grananje akcija Priprema proizvoda [prioritetna narudžbina] Slanje fakture odluka [else] Hitna isporuka tok/ivica Obična isporuka Naplaćivanje stapanje spajanje Zaključivanje narudžbenice završni čvor

RAZLAGANJE AKCIJA Akcije se mogu razložiti u podaktivnosti (subactivities). Dijagram podaktivnosti se može prikazati primenom simbola račve. Ime aktivnosti Primljena narudžbina Isporuči narudžbinu [else] Obična isporuka Narudžbina [prioritetna narudžbina] Narudžbina Hitna isporuka Pomoćni dijagram aktivnosti Pošalji fakturu Isporuči narudžbinu izlazni prametar ulazni parametar Pripremi naručeno račva ukazuje na dijagram podaktivnosti Naplati Zaključi narudžbinu Poziv aktivnosti sa pomoćnog dijagrama

SPECIFIKACIJA SPAJANJA Obično se podrazumeva da spajanje dozvoljava izvršavanje izlaznog toka kada svi ulazni tokovi dođu do tačke spajanja, ali je nekad korisno uvesti složenije pravilo. Specifikacija spajanja je logički izraz koji se pridružuje spajanju. Vrednost izraza se računa svaki put kada neki tok dođe u fazu spajanja i ako je uslov ispunjen, ide se na sledeću akciju. Primer Izaberi piće A Sipaj piće Ubaci novac B {join. Spec = A i B i vrednost ubačenog novca >= cena izabranog pića}

PARTICIJE Dijagrami aktivnosti pokazuju šta se dešava, ali ne i ko šta radi. Da bi se prikazalo ko izvršava koje akcije, dijagram aktivnosti se deli u particije. Particije (partitions) pokazuju koje akcije izvršava jedna organizaciona celina. Magacin Korisnička služba Računovodstvo Primljena narudžbina Pripremi naručeno Pošalji fakturu Isporuči narudžbinu Postoje jednodimenzionalna (često se zove plivačka staza) i dvodimenzionalna podela na particije. Naplati Zaključi narudžbinu

SIGNALI Signali omogućavaju interakciju sa spoljnim procesima. Ukoliko aktivnost prima događaj iz spoljnog procesa, ona neprekidno osluškuje signale, a na dijagramu je opisano kako aktivnost reaguje nakon prijema signala. Oznake za prijem mogu imati i ulazni tok čime se označava da osluškivanje započinje tek kada tok aktivira prijem. Aktivnost može i da pošalje poruku, pa da sačeka odgovor pre nego što nastavi sa radom. Vremenski signal nastaje zbog protoka vremena. Primer 1 Primer 2 vremenski signal Dva sata pre poletanja Paku j stvari Rezerviši mesto Kreni na aerodrom Pošalji plan prijem signala Potvrđen plan Stiže taksi prijem signala slanje signala Čekaj 48 sati Potvrdi putovanje Odustani od putovanja

TOKOVI Tok ili ivica su sinonimi za opisivanje veze između dve akcije. Četiri ekvivalentna načina za prikazivanje ivica: 1. Obična linija sa strelicom između dve Primi fakturu Plati akcije. Ivici se može dodeliti ime, ali ne mora. 2. Veznik (connector) olakšava crtanje i mora se koristiti u parovima. Oba veznika moraju biti isto obeležena. Po jedan veznik se crta za ulazni i izlazni tok. 3. Prosleđivanje objekata duž ivice crtanjem simbola klase. 4. Prosleđivanje objekata duž ivice dodavanjem nožica simbolima akcija. veznik Primi fakturu A A Plati čvor objekta Primi fakturu Narudžbina nožica Primi fakturu Narudžbina Plati

NOŽICE I TRANSFORMACIJE Akcije mogu imati parametre, kao što ih imaju metode. Informacije o parametrima se po potrebi mogu prikazivati pomoću nožica. Transformacija parametara se naznačava u slučaju kada izlazni parametri jedne akcije ne odgovaraju ulaznim parametrima sledeće akcije. Izraz za transformaciju ne sme proizvoditi sporedne efekte. To je u stvari upit na izlaznom delu nožice, a tip rezultata upita treba da odgovara ulaznoj nožici. Primer Otkaži pregled Pregled nožica za parametar «transformation» pregled. obaveštenje. OOtkazivanju «transformation» pregled. pacijent Poruka Pacijent Obavesti pacijenta Izraz za transformaciju

OBLAST PRIMENE AKCIJA U situaciji kada nakon neke akcije treba više puta izvršiti drugu akciju, koristi se oblast primene koja predstavlja deo dijagrama aktivnosti u kome se akcije izvršavaju po jednom za svaki element kolekcije. Na sledeću akciju se prelazi nakon kompletiranja izlazne kolekcije. Brojevi elemenata u ulaznoj i izlaznoj kolekciji ne moraju biti isti (ako se oblast primene ponaša kao filtar). Dva načina obrade elemenata ulazne kolekcije 1. Paralelna obrada (označava se rezervisnom rečju concurrent), kada se elementi obrađuju istovremeno. 2. Iterativna obrada, kada se elementi moraju obrađivati jedan za drugim. Primer rezervisana reč oblast primene lista tema «concurrent» Napiši tekst Pregledaj tekst Objavi bilten nožica u obliku liste

ZAVRŠETAK TOKA Završetak toka ukazuje na kraj jednog toka, bez prekidanja cele aktivnosti. Primer Izaberi teme lista tema Zahvaljujući završetku toka, omogućeno je da se oblasti primene ponašaju kao filtri, jer izlazna kolekcija može biti manja od ulazne. oblast primene «concurrent» Napiši tekst Pregledaj tekst [prihvatanje] [odbijanje] završetak toka Objavi bilten

DIJAGRAMI KOMPONENATA Dijagrami komponenata opisuju fizičku organizaciju softverskih komponenata u sistemu i zavisnosti koje postoje između njih. primeri komponenata: biblioteke, paketi, datoteke, . . . najčešće se koriste u fazi implementacije i prilikom održavanja sistema Elementi dijagrama Stvari • komponente • klase • artefakti • interfejsi • portovi • podsistemi Relacije • zavisnosti • generalizacije • asocijacije • realizacije

KOMPONENTE I KLASE (1) Komponenta je apstrakcija fizičkog, zamenljivog dela sistema. kapsulira sadržaj koji je okruženju vidljiv samo kroz interfejse Komponenta «component» Komponenta komponenta može da sadrži deo u kome su navedene klase koje realizuje klasa je logička apstrakcija, a komponenta fizička realizacija komponente predstavljaju fizičko pakovanje različitih logičkih apstrakcija klase imaju atribute i operacije, a komponente samo operacije koje su dostupne preko interfejsa Klasa 1 Komponenta «realizations» Klasa 1 Klasa 2 Komponenta Klasa 2

KOMPONENTE I KLASE (2) mnoge vrste sistemskog softvera (na primer, OS ili programski jezici) podržavaju koncept komponenata Standardni stereotipovi za komponente: executable – označava komponentu koja se može izvršavati library – označava statičku ili dinamičku objektnu biblioteku file – označava datoteku sa proizvoljnim sadržajem document – označava dokument script – označava skript source – označava datoteku sa izvornim kôdom

ARTEFAKTI Artefakt je fizička informacija koja nastaje ili se koristi u procesu razvoja, procesu izvršavanja programa, ili pri isporuci softvera. primeri artefakta: modeli, izvorni kôd, razni dokumenti, resursi, datoteke sa ekstenzijom. dll, . exe, . jar, razne tabele «artifact» obrada. jar obrada artefakt može da predstavlja manifestaciju komponente «manifest» obrada «artifact» obrada. jar

INTERFEJSI (1) Interfejs je skup operacija koji specificira servise komponente. jedna komponenta može da realizuje jedan ili više interfejsa interfejsi odvajaju implementaciju od ponašanja komponente komponentama se može pristupati samo preko interfejsa jedna komponenta može, bez ikakvih popravki, da bude zamenjena drugom komponentom sa istim interfejsom «interface» Interfejs Komponent a

INTERFEJSI (2) Vrste interfejsa Import (zahtevani) Eksport (ponuđeni) • komponenta ga realizuje • pokazuje koje servise komponenta nudi drugim komponentama • komponenta ga koristi • omogućava nadgradnju komponente • ukazuje na servise koji su datoj komponenti potrebni od strane drugih komponenata Komponenta ponuđeni zahtevani Komponenta može da ima više interfejsa obe vrste. Veznik sklopa Exe Dll

ZAVISNOSTI Zavisnosti opisuju veze između komponenata. Modul 1 Modul 2 komponenta Modul 1 koristi neke servise koji su obezbeđeni u okviru komponente Modul 2

PORTOVI I PODSISTEMI Port predstavlja tačku interakcije sa okruženjem. komponenta može da ispoljava interfejse preko porta portu se mogu pridružiti interfejsi koji specificiraju prirodu interakcije komponente sa okruženjem «component» Komponenta ime. Porta: Tip. Porta Podsistemi predstavljaju fizičke podsisteme u sistemu. mogu da sadrže komponente ili druge podsisteme najčešće reprezentuju direktorijume u sistemu datoteka «subsystem» Čuvanje. Podataka

PRIMER DIJAGRAMA Proizvod Kôd. Proizvoda Nalog Plaćanje Detalji. OKupcu Detalji. ORačunu Račun Kupac

DIJAGRAM RASPOREĐIVANJA Dijagrami raspoređivanja opisuju fizičku organizaciju sistema, prikazujući njegovu hardversku i softversku arhitekturu. jasno navedeno koje hardverske i softverske komponente postoje u sistemu jasno navedeno koja softverska komponenta se izvršava na kojoj hardverskoj komponenti jasno definisane veze između različitih delova sistema Elementi dijagrama Čvorovi Artefakti Veze

ČVOROVI (1) Čvor je apstrakcija fizičkog objekta koji predstavlja resurs obrade. Čvorovi mogu da budu: uređaji (računar, mobilni telefon) izvršna okruženja (softver - operativni sistem, kontejnerski procesi, vituelna mašina) web serveri, serveri baze podatka, aplikativni serveri Računar A 1 sala: Računar Čvor Instanca čvora

ČVOROVI (2) Serveri Paketi Web. Server Aplikativni. Server više fizičkih čvorova koji obavljaju logički srodne poslove Klijenti Laptop Ugnježdeni čvorovi jedan čvor sadrži drugi Desktop «device» Server Baze Podataka «execution environment» RDBMS Server. Baze. Podataka

ARTEFAKTI I VEZE Artefakti su softverske komponente koje se izvršavaju u čvorovima. mogu biti datoteke - izvršne (. exe, . dll, . jar, itd), datoteke sa podacima, konfiguracione datoteke, HTML dokumenti i dr. predstavljaju se u vidu pravougaonika unutar čvorova na koje su alocirani Računar «artifact» main. c Veze predstavljaju komunikacione putanje između različitih delova sistema. prikazuju se pomoću asocija

PRIMER DIJAGRAMA «device» PDA «device» Web server «artifact» Web sajt «device» Terminal «artifact» IMSClient. jar «device» Aplikativni server «artifact» IMS. jar «artifact» ORM. jar «device» Server BP «artifact» My. SQL server