PROJEKTOVANJE SOFTVERA

Transkript

1 Elektrotehniči fakultet Univerziteta u Beogradu Katedra za računarsku tehniku i informatiku skripta za predmet PROJEKTOVANJE SOFTVERA Igor Tartalja Beograd, Besplatan primerak This copy is not for sale Ova skripta je objavljena u okviru projekta WUS Austria MSDP 2011 The publishing of this script is part of the project MSDP 2011 finansiranog od strane Austrijske agencije za razvoj financed by Austrian Development Agency through WUS Austria

2

3 Predgovor 3 Predgovor Projektovanje softvera je inženjerska disciplina i ključna faza u razvoju softvera. Ono se zasniva na principima koji se odnose prvenstveno na modeliranje strukture i ponašanja softvera, kao i na primenu projektnih uzoraka u rešavanju problema. Kao i svaki drugi inženjerski proizvod, softver u svome nastajanju prolazi kroz prepoznatljive faze, od specifikacije zahteva, pa do instalacije na ciljne mašine. Instalacijom tek počinje životni vek softvera kao tehničkog proizvoda. Život softverskog proizvoda se sastoji od njegovog korišćenja, popravki i unapređenja. Iskustva stečena u toku životnog veka softverskog proizvoda često dovode do nastanka novih proizvoda, njegovih funkcionalnih naslednika. Ako se ta iskustva formalno dokumentuju kroz model i prepoznate projektne uzorke, mogu se primeniti i mnogo šire. Praktično isti principi projektovanja softvera se primenjuju, kako na razvoj novog proizvoda, tako i na održavanje i unapređivanje postojećeg proizvoda u toku njegovog životnog veka. Predmet Projektovanje softvera, koji se drži na osnovnim i master studijama Softverskog inženjerstva i Računarske tehnike i informatike na Elektrotehničkom fakultetu, Univerziteta u Beogradu se koncentriše na dva centralna aspekta projektovanja softvera. To su modeliranje objektno-orijentisanog softvera i primena projektnih uzoraka u koncipiranju arhitekture softvera. Ova skripta sadrže materijale koji se koriste na predavanjima iz predmeta Projektovanje softvera. Skripta su nastala sa željom da se studentima koji pohađaju ovaj predmet stave na raspolaganje materijali koji se koriste na predavanjima. Predavanja se drže uz korišćenje elektronskih prezentacija sa slajdovima, te je sadržaj skripti praktično jednak sadržaju slajdova koji se koriste na predavanjima. Prvobitni tekst skripti je predstavljao samo podsetnik nastavniku za držanje predavanja. Posle višegodišnjeg iskustva u držanju nastave iz ovog predmeta, te doterivanja materijala kroz više iteracija, autor se odlučio da objavi skripta u ovom obliku i stavi ih na raspolaganje studentima koji pohađaju predmet. Zato se skreće pažnja čitaocima da su skripta namenjena praktično samo onima koji prate predavanja na predmetu. Ona ne predstavljaju samostalan udžbenik iz kojeg se predmet može valjano naučiti. Ona su praktični podsetnik na materiju koja se izlaže na predavanjima. Treba imati u vidu da se na predavanjima daju i mnoga usmena objašnjenja pojmova i principa koji su samo pomenuti u skriptama. Bez praćenja predavanja, takvi pojmovi i principi se teško mogu dobro razumeti samo na osnovu čitanja skripti. Takođe, pretpostavlja se da čitaoci ovih skripti dobro vladaju pojmovima i principima koji se prethodno izučavaju na predmetima iz proceduralnog i objektno-orijentisanog programiranja. U pripremi skripti korišćena je literatura navedena na kraju skripti. Najveći deo teksta na jezgroviti način, kroz teze, izlaže materiju iz te literature. Ujedno, navedeni izvori predstavljaju udžbenike i dopunsku literaturu predmeta Projektovanje softvera. Osim uvoda u projektovanje softvera, skripta sadrže dva dela. Prvi deo je posvećen objektno-orijentisanom modeliranju na jeziku UML (Unified Modeling Language). Drugi deo je posvećen primeni projektnih uzoraka u projektovanju softvera. Iako je materija u skriptama izložena na navedeni način, metodologija držanja predmeta je takva da se teme iz ove dve šire oblasti Projektovanje softvera

4 4 Predgovor kombinuju, tako da se na predmetu simultano napreduje kroz obe oblasti. Na taj način se studentima omogućava da vrlo rano počnu da uvežbavaju metodologiju projektovanja na jeziku UML uz korišćenje projektnih uzoraka. Iz tog razloga su i projektni uzorci izloženi redosledom primerenim blagovremenom uvežbavanju, počeviši od onih koje je lakše razumeti i primeniti, kombinujući ih sa do tada obrađenim dijagramima jezika UML. Autor se zahvaljuje svima koji su na bilo koji način doprineli nastanku ovih skripti. Posebnu zahvalnost autor duguje kolegi mr Laslu Krausu. Dugogodišnja saradnja i plodne diskusije o problematici, kako ovog predmeta, tako i predmeta iz objektno-orijentisanog programiranja, pomogle su autoru da izgradi terminologiju i razvije metodologiju rada na predmetu. Kompletiranje završne verzije ovih skripti pomogla je Austrijska agencija za razvoj, kroz projekat Master Studies Development Program (MSDP 2011), WUS Austrija. Recenzenti izveštaja na projektu MSDP 2011, Johann Höchtl i Sylvia Purgathofer-Müller, dali su korisne savete da skripta dobiju konačni oblik. Konačno, autor se zahvaljuje studentima ranijih generacija koji su ukazali na propuste i greške u ranijim materijalima na osnovu kojih su nastala skripta u ovom obliku. U uverenju da će skripta biti od koristi studentima koji prate predmet Projektovanje softvera, autor se nada da će im izložena materija biti interesantna i podsticajna, kako za pripremu ispita, tako i za buduću inženjersku praksu. Moli ih da čitaju pažljivo, a za sve propuste i greške koje otkriju i prijave mu, biće im veoma zahvalan. Beograd, Autor Elektrotehnički fakultet u Beogradu

5 Sadržaj 5 Sadržaj Predgovor...3 Sadržaj...5 Uvod...13 Osnovni pojmovi Objektno-orijentisana analiza Objektno-orijentisano projektovanje Objektno-orijentisano programiranje Objektno-orijentisani jezik Principi OO modela Apstrakcija i kapsulacija Modularnost i hijerarhija Tipizacija i polimorfizam Konkurentnost i perzistencija Model i modeliranje Ciljevi modeliranja OO model i pogledi na model Dijagrami Logički i fizički aspekti modela Statički i dinamički aspekti modela Notacija za opis modela Alati za modeliranje Pregled jezika UML...18 Standardni jezik za modeliranje UML Korisnici UML-a Praistorija UML-a Istorija UML-a Konceptualni model UML-a Stvari Stvari strukture klase i interfejsi Stvari strukture slučaj korišćenja i saradnja Stvari strukture komponenta i čvor Stvari ponašanja Stvari organizacije i anotacije Relacije Dijagrami Statički dijagrami Projektovanje softvera

6 6 Sadržaj Dinamički dijagrami Pravila UML-a Opšti mehanizmi UML-a Specifikacije Ukrasi Opšte podele Mehanizmi proširivosti Stereotipovi Obeležene vrednosti Ograničenja Prvi primer Uvod Primer na Javi Ključne apstrakcije Grupisanje Ponašanje Komponente Dijagrami klasa Uvod Klasifikator Klasa Simbol klase Atributi i operacije Dodatne mogućnosti Tipovi podataka Osobine klasa Sintaksa atributa Sintaksa operacije Relacije Zavisnost Generalizacija Asocijacija Realizacija Primer osnovnih relacija Ukrasi asocijacije Multiplikativnost Agregacija Elektrotehnički fakultet u Beogradu

7 7 Kompozicija Primer asocijacija Navigacija Pravo pristupa preko asocijacije Ugnežđivanje Dijagrami paketa...36 Uvod Paket Imenovanje paketa i elemenata Vlasništvo i pravo pristupa Notacija Relacije Principi modeliranja Stereotipovi paketa Dijagrami objekata...40 Uvod Namena Objekti Veze Primer uzorak Kompozicija Primer - relacija pohađa Dijagrami interakcije...42 Uvod Kontekst interakcije Poruka Vrste dijagrama interakcije Dijagrami sekvence i komunikcije Uloge i njihove linije života Konektori Slanje i prijem poruke Sekvenciranje poruka Sekvenciranje poruka u nitima Sintaksa poruke Životni vek objekata i veza Događanje izvršenja (fokus kontrole) Primer Bankomat dijagram sekvence Primer Bankomat dijagram komunikacije Projektovanje softvera

8 8 Sadržaj Iteracije i grananje Fragment (okvir) interakcije Operatori kombinovanih fragmenata Primer operatora okvira interakcije Dijagrami slučajeva korišćenja Uvod Slučajevi korišćenja Ponašanje slučaja korišćenja Primer opisa ponašanja Akteri Relacija komunikacije Relacija uključivanja Primer korisnici foruma Relacija proširivanja Tačke proširenja slučaja korišćenja Relacija generalizacije Okvir subjekta Primer Info sistem fakulteta Dijagrami aktivnosti Uvod Odnos prema drugim dijagramima Aktivnosti i akcije Aktivnosti Akcije Elementi dijagrama aktivnosti Pseudočvorovi, tranzicije, konektori Sekvencijalna grananja Primeri grananja i iteracije Konkurentna grananja Tok objekata Primer Plivačke staze Hijerarhijske staze i particije Primer dijagrama aktivnosti Izuzeci Signali i događaji Primer slanja i prihvatanja signala Elektrotehnički fakultet u Beogradu

9 9 Oblast ekspanzije Centralni bafer Skladište podataka Dijagrami stanja...66 Uvod Kontekst primene automata stanja Elementi dijagrama stanja Stanja i podautomati stanja Elementi stanja Primer stanja Pseudostanja i specijalna stanja Prelazi Primer dijagrama stanja Mealy i Moor automati Primer automata Mealy-jevog tipa Složena stanja Sekvencijalna podstanja Primer sekvencijalnih podstanja Stanje sa istorijom Konkurentna podstanja Primer konkurentnih podstanja Slanje signala Dijagrami klasa napredniji pojmovi...73 Aktivne klase Procesi i niti Aktivne klase - notacija Šabloni Šabloni - notacija Izuzeci Klasa asocijacije N-arna asocijacija Kvalifikacija Specifikator interfejsa (UML 1) Generalizacioni skupovi Notacija i primer Metaklasa Powertype Projektovanje softvera

10 10 Sadržaj Konteksti relacije realizacije Parametrizovana kolaboracija Projektni uzorci Standardni stereotipovi klasifikatora Standardni stereotipovi relacije zavisnosti Standardni stereotipovi ostalih relacija Dijagrami složene strukture Uvod Notacija: delovi i portovi Konektori Primer Multiplikativnost Saradnja Događanje saradnje Dijagrami komponenata Uvod Najčešće primene Komponenta Grafička notacija Artefakt Komponente i klase/interfejsi Port Port i interfejsi Vrste artefakata i stereotipovi Paketi i relacije zavisnosti Primer dijagrama komponenata Dijagrami raspoređivanja Uvod Najčešće primene Čvorovi Organizovanje čvorova Čvorovi, komponente i artefakti Uređaji i izvršna okruženja Veze Primer hardverska konfiguracija Primer čvorovi i artefakti Dijagrami interakcije - napredniji pojmovi Elektrotehnički fakultet u Beogradu

11 11 Dijagrami pregleda interakcije Razlike od dijagrama aktivnosti Grafička notacija Primer dijagram pregleda interakcije Vremenski dijagrami Grafička notacija Primer vremenskog dijagrama Arhitektura metamodeliranja...94 Uvod Četvoronivoska arhitektura Opis nivoa arhitekture Primer Meta-metamodel Metamodel Model Korisnički objekti Analogija Uvod...97 Elementi uzorka...97 Naziv uzorka Postavka problema Opis rešenja Posledice Primer primene uzoraka: MVC...98 Model View komunikacija Komponovanje prikaza Model Controller komunikacija Klasifikacija projektnih uzoraka Kriterijum namene Kriterijum domena Karakteristike vrsta uzoraka Drugi odnosi između uzoraka Prostor projektnih uzoraka Katalog projektnih uzoraka UML notacija za opis uzoraka Unikat Kompozicija Projektovanje softvera

12 12 Sadržaj Prototip Posmatrač Iterator Dekorater Strategija Šablonski metod Adapter Stanje Podsetnik Muva Fabrički metod Apstraktna fabrika Fasada Posrednik Zastupnik Most Komanda Lanac odgovornosti Graditelj Posetilac Interpreter Literatura Elektrotehnički fakultet u Beogradu

13 Uvod 13 Uvod Osnovni pojmovi Svaki ozbiljniji projekat prolazi kroz faze: analiza, projektovanje, implementacija, testiranje slično je sa SW projektima, kroz faze se prolazi iterativno Objektno-orijentisana metodologija razvoja dominantna u proizvodnji softvera danas Pojmovi objektno-orijentisana analiza OOA objektno-orijentisano projektovanje OOD objektno-orijentisano programiranje OOP objektno-orijentisani jezik OOL Objektno-orijentisana analiza Tradicionalne tehnike strukturirane analize fokus na toku podataka u sistemu Booch (1994): Objektno-orijentisana analiza je metod analize koji ispituje zahteve iz perspektive klasa i objekata pronađenih u rečniku iz domena problema Proizvod OOA konceptualni model - ulaz u fazu OOD Objektno-orijentisano projektovanje Tradicionalno strukturirano projektovanje fokus na algoritamskim apstrakcijama Booch (1994): Objektno-orijentisano projektovanje je metod projektovanja koji obuhvata proces OO dekompozicije notaciju za predstavljanje logičkih i fizičkih statičkih i dinamičkih aspekata modela sistema koji se projektuje Proizvod OOD model projektovane aplikacije ili sistema ulaz u fazu OOP Objektno-orijentisano programiranje Tradicionalno strukturirano programiranje fokus na implementaciji algoritama Booch (1994): Objektno-orijentisano programiranje je metod implementacije po kojem su: programi organizovani kao kolekcije objekata koji sarađuju svaki objekat predstavlja instancu neke klase i sve klase su članovi neke hijerarhije klasa u kojoj su klase povezane relacijama nasleđivanja Proizvod OOP izvršna aplikacija ili sistem Projektovanje softvera

14 14 Uvod Objektno-orijentisani jezik Cardelli & Wegner (1985): Jezik je objektno-orijentisan ako i samo ako ispunjava: da podržava objekte koji su apstrakcije podataka sa interfejsom preko imenovanih operacija i skrivenim lokalnim stanjem da objekti imaju pridružen tip (klasu) da tipovi (klase) mogu nasleđivati atribute nadtipa (natklase) Ako jezik samo ne podržava nasleđivanje naziva se objektno-baziranim jezikom Objektno-orijentisani jezici su: Simula, Smalltalk, Object Pascal, Eiffel, Python, Ada95, C++, Java, C#, Visual Basic.NET,... Objektno-bazirani jezici Ada83, VisualBasic v6,... Principi OO modela Booch OOA&D (1994): Osnovni (obavezni) Dodatni (neobavezni) apstrakcija tipizacija kapsulacija konkurentnost modularnost perzistencija hijerarhija Modifikacija: Osnovni (obavezni) Dodatni (neobavezni) apstrakcija konkurentnost kapsulacija perzistencija modularnost hijerarhija polimorfizam Apstrakcija i kapsulacija Shaw (1984): Apstrakcija je uprošćeni opis ili specifikacija sistema koja naglašava neke od detalja ili osobina, dok potiskuje druge Booch (1994): Apstrakcija ističe esencijalne karakteristrike objekta koje ga razlikuju od drugih vrsta objekata i tako definiše jasne konceptualne granice iz perspektive posmatrača Kapsulacija je proces sakrivanja onih elemenata apstrakcije koji definišu strukturu i ponašanje Kapsulacija služi da razdvoji konceptualni interfejs od implementacije apstrakcije Modularnost i hijerarhija Modularnost je osobina sistema da se razlaže na skup kohezivnih i slabo spregnutih modula Moduli su fizičke jedinice (nezavisno prevođenje) predstavljaju komponete sistema mogu se održavati nezavisno Elektrotehnički fakultet u Beogradu

15 Uvod 15 Hijerarhija je rangiranje ili uređivanje apstrakcija Nasleđivanje - is a hijerarhija jednostruko/višestruko potpuno (javno)/strukturno (privatno) Sadržanje - part of hijerarhija po vrednosti/po referenci (relevantno u C++, ali ne u Javi) agregacija/kompozicija Tipizacija i polimorfizam Tipizacija je osobina da se objekti različitih klasa ne mogu uopšte ili se mogu zamenjivati na ograničene načine stroga i slaba tipizacija statička i dinamička tipizacija (vezivanje) Dinamička tipizacija i dinamičko vezivanje tenički preduslov za ispoljavanje polomorfizma Polimorfizam je osobina da se objekat kojem se pristupa kao objektu osnovne klase ponaša različito: kao objekat osnovne klase ill kao objekat izvedene klase ponašanje zavisi od dinamičkog tipa objekta, ne statičkog tipa reference Polimorfizam objekta se zasniva na virtuelnim metodama Konkurentnost i perzistencija Principi koji se dobro uklapaju u OO paradigmu Nisu suštinski principi koji određuju da li je softver OO OO softver ih nemora posedovati Softver koji nije OO ih može posedovati Konkurentnost je osobina koja razlikuje aktivne objekte od pasivnih proces - ima vlastiti adresni prostor (tipično njime upravlja OS) nit - deli isti adresni prostor sa drugim nitima Perzistencija je osobina po kojoj se postojanje objekta proteže kroz vreme (obj. nastavlja da živi nakon nestanka njegovog stvaraoca) kroz prostor (obj. se premešta iz adresnog prostora u kojem je stvoren) Model i modeliranje Model je pojednostavljenje realnosti Model nekog sistema je apstrakcija tog realnog sistema iz određenog ugla posmatranja Osnovna namena modela da se sistem koji se razvija bolje razume Modeliranje je važnije što je sistem kompleksniji kompleksnost je odlika današnjih SW sistema Savremena metodologija razvoja softvera Model Driven Development (MDD) Projektovanje softvera

16 16 Uvod Ciljevi modeliranja Model pomaže da se sistem vizuelizuje Model omogućava da se specificira struktura sistema ponašanje sistema Model daje šablon koji usmerava konstrukciju sistema Model dokumentuje projektne odluke koje se donose Model omogućava ispitivanje projektnih odluka po relativno niskoj ceni OO model i pogledi na model Model OO analize i projektovanja obuhvata više pogleda na sistem koji se razvija Dve dimenzije pogleda na sistem: logički/fizički aspekti statički/dinamički aspekti AiP OO sistema se obavlja u terminima klasa, objekata, njihovih relacija i interakcija Tokom AiP koriste se različiti uglovi gledanja na model sistema u datom 2D prostoru Dijagrami Za svaki pogled na model sistema može se definisati adekvatan dijagram Svaki dijagram predstavlja jednu projekciju modela Primer - aplikacija sa 100 klasa: potrebno je više klasnih dijagrama (svaki prikazuje jedan pogled na model) Jedno ime na svakom dijagramu označava isti entitet (sa izuzetkom operacija zbog preklapanja imena) Logički i fizički aspekti modela Logički model sistema opisuje ključne apstrakcije i mehanizme koji obrazuju prostor problema ili definišu arhitekturu sistema definiše strukturu i relacije između klasa relacije i interakcije između objekata Fizički model sistema opisuje konkretnu softversku i hardversku kompoziciju definiše arhitekturu modula i arhitekturu procesa Statički i dinamički aspekti modela Statički aspekti modela se fokusiraju na strukturu sistema Dinamički aspekti modela se fokusiraju na ponašanje sistema Realni sistemi uvek imaju dinamičko ponašanje: objekti se kreiraju i uništavaju objekti šalju poruke drugim objektima nekim redosledom spoljašnji događaji izazivaju reakcije izvesnih objekata Elektrotehnički fakultet u Beogradu

17 Uvod 17 Notacija za opis modela Nekoliko notacija zaslužuju posebnu pažnju: Booch i OMT notacija (iz istorijskih razloga) UML notacija (standard) Pogodnosti standardne formalne grafičke notacije: olakšava se komunikacija između korisnika i članova razvojnog tima projektant se rasterećuje od nebitnih detalja i koncentriše se na bitne omogućava se upotreba automatizovanih alata za proveru konzistencije i korektnosti projekta ili izvršavanje modela Nije neophodno koristiti celu notaciju na primer Booch Lite, UML Basic (UML User Guide) Potrebno je da notacija omogućava različit stepen detaljnosti (ponekad samo grube skice) Notacija treba da bude nezavisna od programskog jezika neki elementi notacije nemaju direktnu podršku u konkretnom jeziku Alati za modeliranje IBM Rational: Software Architect (Rose, Rose XDE Developer, Software Modeler) Borland: Together Gentleware: Poseidon for UML Open Source: StarUML Altova: Umodel Omondo: EclipseUML Sparx Systems: Enterprise Architect Visual Paradigm: Visual Paradigm for UML Embarcadero Technologies: ER/Studio Software Architect Pregled alata: Projektovanje softvera

18 18 UML Pregled jezika Pregled jezika UML Materijal prireman na osnovu: Booch,G., Rumbaugh,J., Jacobson,I., The Unified Modeling Language User Guide, 2 nd Edition, Addison Wesley, May 2005 Rumbaugh,J., Jacobson,I., Booch,G., Unified Modeling Language Reference Manual, 2 nd Edition, Addison-Wesley, 2004 Fowler,M., UML Distilled: A Brief Guide to the Standard Object Modeling Language, 3 rd Edition, Pearson Education, 2004 UML 2 Infrastructure Specification, OMG UML 2 Superstructure Specification, OMG Standardni jezik za modeliranje UML UML (Unified Modeling Language) je grafički jezik za: vizuelizaciju specifikaciju konstruisanje i dokumentovanje softverski-intenzivnih sistema UML omogućava konstruisanje šema koje modeliraju sistem opisujući: konceptualne stvari npr. proces poslovanja i funkcije sistema konkretne stvari npr. klasne tipove, šeme baza podataka, softverske komponente Sajt: Korisnici UML-a Sledeće kategorije korisnika UML-a se uočavaju: sistem-analitičari i krajnji korisnici: specificiraju zahtevanu strukturu i ponašanje sistema arhitekti: projektuju sistem koji zadovoljava zahteve razvojni inženjeri (developers): transformišu arhitekturu u izvršni kod kontrolori kvaliteta (quality assurance personel): proveravaju strukturu i ponašanje sistema bibliotekari (librarians): kreiraju i katalogiziraju komponente rukovodioci projekata (managers): vode i usmeravaju kadrove i upravljaju resursima Praistorija UML-a Jezici za OO modeliranje se pojavljuju još od sredine 70ih uzrok njihove pojave je pojava nove generacije OO jezika i povećana kompleksnost softverskih sistema U periodu : broj OO metoda je porastao sa manje od 10 na više od 50 Metode koje su ostvarile najveći uticaj na oblast OO modeliranja su: Booch metoda OMT (Object Modeling Technique, Rumbaugh) OOSE (Object Oriented Software Engineering, Jacobson) Fusion Shlaer-Mellor Coad-Yourdon Elektrotehnički fakultet u Beogradu

19 UML Pregled jezika 19 Istorija UML-a 1994: početak rada na UML-u - Rumbaugh se pridružio Booch-u u firmi Rational Oktobar 1995: pojavila se verzija 0.8 drafta UM-a (Unified Method) Jesen 1995: Jacobson se pridružio Rational-u rad na objedinjenju UM sa OOSE Jun 1996: pojavila se verzija 0.9 UML-a Važniji partneri (učestvovali u definisanju verzije 1.0): DEC, HP, IBM, Microsoft, Oracle, Rational, TI,... U januaru 1997: OMG-u (Object Management Group) podnet predlog std. UML 1.0 Grupa partnera je proširena drugim podnosiocima predloga: npr. ObjecTime, Ericsson,... Jul 1997: podnet predlog UML 1.1 koji je prihvaćen od OMG Jun 1998: verzija UML 1.2 Jesen 1998: verzija UML 1.3 Septembar 2001: verzija UML 1.4 (v => ISO std :2005) 2002: verzija UML 1.5 (akciona semantika) Jun 2003: v 2.0, februar 2007: v 2.1, februar 2009: v 2.2, maj 2010: v 2.3 Konceptualni model UML-a Tri osnovna elementa UML modela su: Osnovni gradivni blokovi Pravila za povezivanje gradivnih blokova Opšti mehanizmi koji se primenjuju u UML-u Gradivni blokovi UML-a Stvari (things) apstrakcije koje su "građani prvog reda" u modelu Relacije (relationships) povezuju stvari Dijagrami (diagrams) grupišu interesantne skupove povezanih stvari Stvari Stvari strukture - statički delovi modela, reprezentuju konceptualne ili fizičke elemente (imenice) Stvari ponašanja - dinamički delovi modela, reprezentuju ponašanje kroz prostor i vreme (glagoli) Stvari grupisanja - organizacioni delovi modela, kutije u koje model može biti dekomponovan Stvari anotacije - objašnjavajući delovi modela, komentari koji se primenjuju na bilo koji element Projektovanje softvera

20 20 UML Pregled jezika Stvari strukture klase i interfejsi Klasa je opis skupa objekata koji dele zajedničke karakteristike (atribute i operacije), ograničenja i semantiku x y Tacka rastojanje() Aktivna klasa je klasa čiji objekti imaju vlastitu nit kontrole i tako mogu da započnu neku upravljačku aktivnost Alarm postavivreme() ukljuci() iskljuci() Ponašanje objekta aktivne klase je konkurentno sa drugim aktivnim objektima Interfejs je kolekcija operacija koje specificiraju servis klase ili komponente IStek Interfejs opisuje ponašanje elementa koje je spolja vidljivo Interfejs definiše skup specifikacija (prototipova) operacija ali ne i njihove implementacije Klasa i komponenta mogu da implementiraju više interfejsa Stvari strukture slučaj korišćenja i saradnja Slučaj korišćenja (use-case) je opis skupa sekvenci aktivnosti koje obavlja sistem da bi proizveo vidljiv rezultat vredan za pojedinog aktera Prikaz rasporeda casova Jedna sekvenca aktivnosti instanca slučaja korišćenja (scenario) Slučaj korišćenja reprezentuje funkcionalnost sistema (mada se neki autori ne slažu sa tim) Koirsti se da bi se strukturirale stvari ponašanja u modelu Realizuje se kroz saradnju (kolaboraciju) Saradnja (collaboration) definiše zajednicu i interakciju aktera i drugih elemenata koji dejstvuju zajedno Elektrotehnički fakultet u Beogradu

21 UML Pregled jezika 21 da ostvare kooperativno ponašanje koje je kvalitativno novo u odnosu na prostu sumu ponašanja elemenata Posmatrac Saradnja ima strukturalnu, kao i dimenziju ponašanja Projektni uzorci (design patterns) se predstavljaju kao saradnje Stvari strukture komponenta i čvor Komponenta je fizički i zamenjivi deo sistema koji ostvaruje realizaciju skupa interfejsa <<component>> Servis.jar Servis.jar Komponenta je tip koji ima ponuđene i zahtevane interfejse U sistemu mogu postojati razne vrste izvršnih komponenata, npr. ActiveX ili Java Beans, ili fajlovi izvornog koda Komponenta obično predstavlja fizičko pakovanje drugih logičkih elemenata kao što su klase, interfejsi i saradnje Čvor (node) je fizički element koji postoji u vreme izvršenja i reprezentuje resurs obrade Server Čvor poseduje neku memoriju i, često, mogućnost procesiranja Skup komponenata može biti u čvoru, a može i migrirati sa čvora na čvor Prvih pet stvari reprezentuje konceptualne ili logičke stvari, dok poslednje dve (komponenta i čvor) reprezentuju fizičke stvari Sve navedene stvari osim saradnje predstavljaju klasifikatore: mehanizme koji opisuju strukturne i karakteristike ponašanja Stvari ponašanja Interakcija je ponašanje koje obuhvata skup poruka koje se razmenjuju između skupa objekata unutar posebnog konteksta da se ostvari specifična svrha Interakcija uključuje određen broj elemenata: poruke (priložen grafički simbol) prikazi() sekvence akcija (ponašanje izazvano porukom) veze (komunikacione putanje između objekata) Projektovanje softvera

22 22 UML Pregled jezika Automat stanja je ponašanje koje specificira sekvence stanja kroz koje prolazi jedan objekat ili jedna interakcija za vreme svog životnog veka, kao posledice događaja, zajedno sa njegovim odgovorima na te događaje Cekanje Automat stanja uključuje određen broj elemenata: stanja (priložen grafički simbol), tranzicije (prelaze između stanja) događaje (stvari koje izazivaju tranziciju) aktivnosti (odgovore na tranzicije) Stvari organizacije i anotacije Paket je opštenamenski mehanizam za organizovanje elemenata u grupe awt Stvari strukture, ponašanja, pa čak i druge stvari grupisanja mogu biti smeštene u paket Za razliku od komponente, paket je čisto konceptualna stvar (egzistira samo u vreme razvoja) Pored paketa postoje i sledeće stvari grupisanja: radni okviri (frameworks), modeli Napomena je simbol za prikazivanje komentara pridruženih jednom elementu ili kolekciji elemenata FIFO Relacije Zavisnost je semantička relacija između dve stvari u kojoj izmena jedne (nezavisne) stvari može uticati na semantiku druge (zavisne) stvari Asocijacija je strukturna relacija koja opisuje skup veza između objekata +poslodavac 1 +zaposleni 1..* sadržanje je specijalna vrsta asocijacije koja reprezentuje strukturnu relaciju između celine i njenih delova često grafički simbol sadrži ukrase kao što su multiplikativnost i imena uloga Elektrotehnički fakultet u Beogradu

23 UML Pregled jezika 23 Generalizacija je relacija specijalizacije/generalizacije u kojoj su objekti specijalizovanog elementa (deca) zamene za objekte generalizovanog elementa (roditelja) dete deli strukturu i ponašanje roditelja Realizacija je semantička relacija između klasifikatora u kojoj jedan klasifikator specificira ugovor koji drugi klasifikator ostvaruje Sreće se: između interfejsa i klasa ili komponenata koje ga realizuju između slučajeva korišćenja i saradnji koje ih realizuju Dijagrami Dijagram je grafička reprezentacija skupa povezanih elemenata najčešće se pojavljuje u obliku grafa temena (stvari) povezanih granama (relacijama) Dijagrami se crtaju da bi se sistem vizualizovao iz različitih perspektiva Vrste dijagrama u UML-u: dijagrami za prikaz statičkih aspekata sistema dijagrami za prikaz dinamičkih aspekata sistema Statički dijagrami Dijagram klasa (class diagram) prikazuje logičku strukturu apstrakcija: skup klasa, interfejsa, saradnji i njihovih relacija Dijagram objekata (object diagram) prikazuje logičku strukturu instanci: skup objekata (instanci klasa) i njihovih veza Dijagram komponenata (component diagram) prikazuje fizičku organizaciju i zavisnosti između skupa komponenata Dijagram raspoređivanja (deployment diagram) prikazuje konfiguraciju čvorova obrade i komponenata koje žive na njima Dijagram paketa (package diagram) [UML 2] prikazuje statičku strukturu grupisanja elemenata modela u pakete Dijagram složene strukture (composite structure diagram) [UML 2] prikazuje hijerarhijsko razlaganje primerka klase, komponente ili saradnje na delove Dinamički dijagrami Dijagram slučajeva korišćenja (use case diagram) prikazuje skup slučajeva korišćenja, aktera (specijalne vrste klasa) i njihovih relacija Dijagram interakcije (interaction diagram) prikazuje jednu interakciju koju čine skup objekata i njihovih veza sa porukama koje razmenjuju Dijagram sekvence (sequence diagram) je dijagram interakcije koji naglašava vremenski redosled poruka Dijagram komunikacije (communication diagram) je dijagram interakcije koji naglašava strukturnu organizaciju objekata koji šalju i primaju poruke; Dijagram pregleda interakcije (interaction overview diagram) [UML 2] je dijagram interakcije koji definiše interakcije kroz vrstu dijagrama aktivnosti (kombinacija d. aktivnosti i d. sekvence) Projektovanje softvera

24 24 UML Pregled jezika Vremenski dijagram (timing diagram) [UML 2] je dijagram interakcije koji prikazuje promenu stanja objekata u vremenu Dijagram aktivnosti (activity diagram) prikazuje tok od jedne do druge aktivnosti u sistemu (nije specijalna vrsta dijagrama stanja u UML 2) Dijagram stanja (statechart diagram) prikazuje konačni automat koji obuhvata stanja, tranzicije, događaje i aktivnosti Pravila UML-a UML ima pravila koja specificiraju kako izgleda dobro formiran model Dobro formiran model je semantički konzistentan u harmoniji sa korelisanim modelima UML ima semantička pravila za: Imena - kako se nazivaju stvari, relacije i dijagrami Doseg - koji kontekst daje specifično značenje imenu Vidljivost - gde se imena mogu videti i koristiti od strane drugih Integritet - kako se stvari propisno i konzistentno korelišu prema drugim stvarima Izvršenje - šta to znači za izvršenje ili simulaciju dinamičkog modela Tokom razvoja se ne prave samo modeli koji su dobro formirani, već mogu biti i: Skraćeni (elided) - izvesni elementi su sakriveni da se pojednostavi izgled Nekompletni - izvesni elementi nedostaju Nekonzistentni - integritet modela nije garantovan Pravila UML-a vode kroz vreme ovakve modele prema dobro formiranim Opšti mehanizmi UML-a Gradnja je jednostavnija i harmoničnija ako se poštuju opšti uzorci Postoje četiri opšta mehanizma koja se primenjuju konzistentno kroz jezik: specifikacije ukrasi opšte podele mehanizmi proširivosti Specifikacije Iza svakog dela grafičke notacije UML-a leži specifikacija koja obezbeđuje tekstualni iskaz sintakse i semantike tog gradivnog bloka Iza grafičkog simbola (sličice, ikone) klase stoji specifikacija koja navodi: potpun skup atributa potpun skup operacija (uključujući kompletne potpise) ponašanje Grafički simbol može pokazivati samo mali deo potpune specifikacije Može postojati i drugi izgled iste klase koji prikazuje drugi skup delova iste klase konzistentan sa specifikacijom UML grafička notacija se koristi za vizuelizaciju UML specifikacija se koristi da se saopšte detalji sistema Modeli se mogu graditi: Elektrotehnički fakultet u Beogradu

25 UML Pregled jezika 25 najpre pomoću crtanja dijagrama, a zatim dodavanjem semantike u specifikaciju (tipično za direktni inženjering pri kreiranju novog sistema) direktnim kreiranjem specifikacije pa naknadnim kreiranjem dijagrama koji su njene projekcije (tipično za reverzni inženjering postojećeg sistema) Ukrasi Detalji specifikacije se prikazuju kao grafički ili tekstualni ukras osnovnog grafičkog elementa Na primer: za klasu se može naglasiti da je apstraktna tako što se ime piše italic slovima vidljivost (pravo pristupa) atributa i operacija se može naglasiti pomoću simbola: + (javni), # (zaštićeni), (privatni) i ~(paketni) Agregacija se predstavlja dodatnim simbolom na simbolu asocijacije Opšte podele Dve osnovne podele: apstrakcije i instance interfejsi i implementacije Primeri prve podele: klase/objekti (klasa je apstrakcija, a objekat instanca te apstrakcije) slučajevi korišćenja/instance slučajeva korišćenja (scenarija) komponente/instance komponenti Primeri druge podele: interfejsi/komponente slučajevi korišćenja/saradnje operacije/metodi U UML-u se razlika između apstrakcije i instance pravi tako što se imena instanci podvlače Interfejs deklariše ugovor, a implementacija reprezentuje jednu konkretnu realizaciju ugovora Mehanizmi proširivosti UML je otvoren za proširenja jezika na kontrolisani način Mehanizmi proširivosti uključuju: Stereotipove Obeležene vrednosti Ograničenja Projektovanje softvera

26 26 UML Pregled jezika Stereotipovi Stereotip proširuje rečnik UML-a dopuštajući kreiranje novih vrsta gradivnih blokova specifičnih za problem Novi gradivni blokovi su izvedeni iz postojećih Stereotop se prikazuje kao ime uokvireno znacima << i >> smešteno iznad imena odgovarajućeg elementa Na primer, izuzeci su klase čiji se objekti mogu bacati i hvatati <<exception>> Prekoracenje Može se definisati i grafički simbol za određeni stereotip <<interface>> Merljiv +meri() +meri() Merljiv Obeležene vrednosti Obeležene vrednosti proširuju osobine UML gradivnog bloka dopuštajući dodavanje nove informacije Obeležene vrednosti se prikazuju kao string okružen zagradama { i } ispod imena odgovarajućeg elementa String sadrži ime (tag), sepearator (simbol =) i vrednost Na primer, verzija i autor klase nisu primitivni koncepti u UML-u, a mogu se dodati bilo kom gradivnom bloku kao što je klasa Ograničenja Ograničenja proširuju semantiku UML gradivnog bloka dopuštajući da se dodaju nova pravila ili promene postojeća Ograničenja se mogu pisati: kao slobodan tekst na OCL (Object Constraint Language) RedCekanja {verzija=4.0 autor=...} RedCekanja dodaj() ukloni() isprazni() {red uredjen} Elektrotehnički fakultet u Beogradu

27 UML Prvi primer 27 Prvi primer Uvod Najbolji način učenja UML-a je kroz kreiranje modela na UML-u Većina programera kada uči novi jezik prvo napiše program koji ispiše "Hello, World!" Početak učenja modeliranja na jeziku UML model za "Hello, World!" program uz mehanizme Jave koji omogućavaju izvršenje Primer na Javi Primer: trivijalni aplet koji ispisuje: "Hello, World! import java.awt.graphics; class HelloWorld extends java.applet.applet{ public void paint(graphics g){ g.drawstring("hello, World!", 10, 10); } } Iako je primer programa trivijalan, infrastruktura potrebna da bi aplet radio nije trivijalna Ključne apstrakcije Osnovni klasni dijagram: HelloWorld +paint() g.drawstring("hello, World!", 10, 10); Klasa HelloWorld ima jednan metod (operaciju) paint() redefinisni metod klase Component koji "iscrtava" datu komponentu na željeni način metod se poziva iz okruženja (ne poziva ga programer) i to inicijalno kao i pri pomeranju, otkrivanju, promeni veličine komponente Komentar (note) kaže šta radi operacija paint() Osnovne relacije: Applet HelloWorld +paint() Graphics +drawstring() Klasa HelloWorld se izvodi iz klase Applet, a koristi klasu Graphics klasa Graphics se pojavljuje kao tip formalnog argumenta metode paint() (zavisnost) klasa Graphics omogućava crtanje i pisanje na komponentama (grafički kontekst) grafičke operacije menjaju bite samo unutar clipping regiona vezanog za objekat Graphics crtanje i pisanje se obavlja korišćenjem tekućih atributa datog Graphics objekta Projektovanje softvera

28 28 UML Prvi primer Hijerarhija nasleđivanja HelloWorld +paint() Applet Panel Container Componenet Object ImageObserver ImageObserver je interfejs preko kojeg se primaju obaveštenja o konstrukciji slike interfejs sadrži (callback) metod imageupdate() preko kojeg se javlja progres/status konstrukcije slike Grupisanje applet java awt lang Ponašanje Dijagram sekvence (originalni primer je nešto kompleksniji) target : HelloWorld g : Graphics : Korisnik : Browser : JVM otvorihtmlstranu() run() paint() drawstring() Komponente <<artifact>> Hello.htm <<artifact>> HelloWorld.class <<artifact>> Hello.java <<artifact>> Hello.jpg Elektrotehnički fakultet u Beogradu

29 UML Dijagrami klasa 29 Dijagrami klasa Uvod Dijagram klasa prikazuje skup klasa, interfejsa, saradnji i njihovih relacija Dijagram klasa je graf sačinjen od temena (stvari) povezanih granama (relacijama) Specificira logičke i statičke aspekte modela Elementi dijagrama klasa stvari: klase, interfejsi, saradnje, paketi, objekti (izuzetno) relacije: zavisnosti, generalizacije, asocijacije, realizacije Dijagrami klasa su najčešći u objektnom modeliranju Većina alata podržava generisanje skeleta koda iz dijagrama klasa Klasifikator Klasifikator je klasifikacija primeraka (instances) sa zajedničkim karakteristikama mehanizam koji opisuje strukturu i ponašanje (ima atribute i operacije) apstraktna metaklasa prostor imena tip koji je moguća generalizacija ili specijalizacija drugog potencijalno ugnežden u drugi klasifikator Ne pojavljuju se svi klasifikatori na dijagramima klasa Konkretni klasifikatori su: klase, interfejsi, tipovi podataka, komponente, čvorovi, slučajevi korišćenja,... Klasifikator ima odeljke, koji se ne moraju svi prikazati Klasa odeljci mogu imati svoje nazive, da bi se izbegla dvoznačnost kada neki odeljak nedostaje UML 2.0 definicija: klasa je opis skupa objekata koji dele istu specifikaciju karakteristika (features), ograničenja (constraints) i semantike karakteristike: atributi i operacije Klasa implementira jedan ili više interfejsa Klase opisuju apstrakcije iz domena problema kao i apstrakcije iz domena rešenja Koriste se da reprezentuju softverske stvari, hardverske stvari i konceptualne stvari Simbol klase Simbol klase je pravougaonik podeljen horizontalnim linijama u odeljke odeljak može imati i naziv odeljka naveden kao stereotip GeometrijskaFigura -karakteristicnatacka +pomeri() +promenivelicinu() +crtaj() responsibilities -- geometrijska svojstva figura u ravni naziv atributi operacije odgovornosti Projektovanje softvera

30 30 UML Dijagrami klasa Naziv klase jednostavan: <naziv> sa putanjom: <naziv paketa>::<jednostavan naziv> npr: java::awt::rectangle Odgovornosti klase neformalna semantika u zasebnom odeljku slobodan tekst svaka počinje sa -- Svaka dobro strukturirana klasa bi trebalo da ima barem jednu i ne više od nekoliko odgovornosti Atributi i operacije Atributi su imenovana svojstva klase koja opisuju opsege vrednosti koje instance tog svojstva mogu sadržati Drugi nazivi: članovi podaci (C++), polja (Java) Atributi su strukturne karakteristike (features) klase Notacija: ime, opciono sa tipom i podrazumevanom vrednošću Primer: izbor:boolean=false Operacije su servisi koji se mogu zahtevati od nekog objekta klase Notacija: potpis koji sadrži listu argumenata sa eventualnim tipovima i podrazumevanim vrednostima, kao i tipom rezultata Primer: pomeri(novapozicija:pozicija=koordinatnipocetak):pozicija Dodatne mogućnosti Simbol klase može sadržati prazne odeljke, a može biti i bez odeljaka Potrosac Potrosac Prazan odeljak atributa/operacija ne znači da ih klasa nema, već da nisu relevantni za dati pogled (dijagram) Mogu se koristiti i tri tačke (...) da naznače postojanje dodatnih atributa/operacija Atributi/operacije se mogu grupisati, a svakoj grupi može da prethoditi opisni prefiks Apstraktna klasa i apstraktna operacija naziv se piše italicom ili {abstract} Zajednički članovi (atributi i operacije) klase pišu se podvučeno Pravo pristupa članu (vidljivost, visibility): znak se piše ispred atributa/operacije: javni član: + (podrazumevano) zaštićeni član: # paketski član: ~ privatni član: - Elektrotehnički fakultet u Beogradu

31 UML Dijagrami klasa 31 Tipovi podataka Tipovi podataka (datatype) su tipovi čije vrednosti nemaju identitet Vrste tipova podataka: primitivni tipovi postojeći prosti tipovi podataka u jeziku implementacije nabrojivi tipovi uzimaju vrednost iz definisanog skupa simboličkih imena Osobine klasa Multiplikativnost je osobina klase koja ograničava broj njenih instanci Multiplikativnost se navodi u gornjem desnom uglu Specifične vrednosti multiplikativnosti: 0 uslužna klasa, sadrži samo zajedničke (statičke) atribute i operacije 1 unikatna (singleton) klasa Podrazumevani slučaj je proizvoljan broj instanci Koren hijerarhije klasa (root) je klasa koja nema roditelje List hijerarhije klasa (leaf) je klasa koja nema potomke, tj. ona iz koje se ne može izvoditi Osobine {root} i {leaf} se pišu u odeljku naziva klase Sintaksa atributa Sintaksa atrubuta: [pravo_pristupa] [/] ime [:tip] [multiplikativnost] [=inicijalna_vrednost][{osobina}] Simbol / označava da je atribut "izveden" (može se "izračunati" na osnovu drugih) Multiplikativnost se primenjuje na atribute klase specificira se kao interval celih brojeva, gornja granica može biti neograničena piše se u uglastim zagradama, na primer: consoleport:port[2..*] Osobine atributa (neke): readonly vrednost se ne može menjati, dodavati ni uklanjati nakon inicijalizovanja ordered vrednosti su uređene unique vrednosti elemenata (u jednom objektu) su jedinstvene bag dozvoljava ponavljanje elemenata (nije skup) seq ili sequence isto što i ordered bag (uređen niz elemenata sa ponavljanjem) composite atribut složene strukture redefines ime redefiniše ime subsets ime podskup skupa atributa ime Sintaksa operacije Sintaksa operacije: [pravo_pristupa] ime ([lista_argumenata]) [: tip_rezultata] [{osobina}] Sintaksa argumenta u listi: [smer] ime : tip [multiplikativnost] [ = podrazumevana_vrednost] [{osobina}] Projektovanje softvera

32 32 UML Dijagrami klasa Smer može biti: in ulazni argument, ne sme biti modifikovan (podrazumevano) out izlazni argument, mora se inicijalizovati inout ulazno-izlazni argument, može se modifikovati Osobine operacije: query izvršenje ne menja stanje objekta, operacija je čista funkcija bez bočnih efekata exception lista operacija može da baca izuzetke iz liste leaf operacija nije polimorfna i ne može se redefinisati u izvedenoj klasi concurrency = vrednost šta garantuje operacija pri izvršenju u konkurentnoj sredini Relacije sequential pozivaoci moraju obezbediti da je samo jedna nit u jednom trenutku poziva guarded operacija garantuje sekvencijalizaciju svih poziva svih štićenih operacija concurrent operacija se izvršava kao atomska Na klasnim dijagramima se pojavljuju sve četiri (prve tri su češće) vrste relacija: zavisnost (dependency) asocijacija (association) generalizacija (generalization) realizacija (realization) Zavisnost Povezuje stvari kod kojih izmena nezavisne stvari utiče na ponašanje zavisne stvari Zavisna stvar koristi nezavisnu stvar Grafička notacija: klasa A zavisi od klase B A B Često se koristi kad je jedna klasa (B) tip parametra operacije druge klase (A) Generalizacija Povezuje opštije (superklasa ili roditelj) sa specijalizovanim (subklasa ili dete) stvarima Grafička notacija: klasa A je dete, B je roditelj A B Drugi nazivi relacije: vrsta (is-a-kind-of), izvođenje (A se izvodi iz B), nasleđivanje, proširivanje Generalizacija znači da se objekti dece mogu pojaviti gde god se očekuje objekat roditelja Deca nasleđuju osobine svojih roditelja, naročito atribute i operacije Operacija deteta koja ima isti potpis kao operacija roditelja redefiniše operaciju roditelja Redefinicija operacije omogućava njeno polimorfno ponašanje Klasa koja ima samo jednog roditelja koristi jednostruko nasleđivanje Klasa koja ima više roditelja koristi višestruko nasleđivanje Elektrotehnički fakultet u Beogradu

33 UML Dijagrami klasa 33 Asocijacija Specificira da li su instance jedne stvari povezane sa instancama druge stvari Asocijacija je strukturna relacija Asocijacija je (ako se drugačije ne kaže) bidirekcionalna veza (dvosmerna navigabilnost) Dozvoljena je i asocijacija sa samim sobom (postoje veze između objekata iste klase) Uobičajeno je da asocijacija povezuje dve klase (binarna asoc.) Moguće je da asocijacija povezuje i više klasa (n-arna asocijacija) Grafička notacija: klasa A je u asocijaciji sa klasom B A B Realizacija Semantička relacija između klasifikatora od kojih jedan specificira ugovor a drugi garantuje njegovu implementaciju Grafička notacija: kanonička forma: K <<interface>> I skraćena forma: Korišćenje interfejsa (relacija zavisnosti) kanonička forma: K I Kijent skraćena forma (ball & socket): <<interface>> I K Primer osnovnih relacija Kijent I K Prozor +otvori() +zatvori() +pomeri() +prikazi() +obradidogadjaj() Dogadjaj Konzolni prozor Dijalog Komponenta Projektovanje softvera

34 34 UML Dijagrami klasa Ukrasi asocijacije Na asocijaciji se mogu pojaviti sledeći ukrasi: Iime, smer čitanja, uloge, navigabilnost, multiplikativnost, sadržanje (agregacija ili kompozicija), pravo pristupa (vidljivost) kraju preko asocijacije Multiplikativnost Naziv Sadržanje 1..* Radi za 1 Osoba Kompanija Odeljenje -zaposlen -poslodavac 1 * Uloga Asocijacija Multiplikativnost Na jednoj strani asocijacije označava se broj objekata sa te strane koji su u vezi sa tačno jednim objektom sa druge strane relacije Može biti: nijedan (0), tačno jedan (1), proizvoljno mnogo, uključujući nijedan (*), opseg (npr. 2..*) UML 2.0 više ne dozvoljava izraze sa diskontinuitetom npr. 0..1,3..4,6..* - proizvoljan broj osim 2 i 5 Agregacija Vrsta asocijacije kod koje jedna strana igra ulogu celine a druga ulogu dela (whole/part) Celina sadrži delove ("has-a" relacija) Agregacija ne govori ništa o uzajamnom odnosu životnih vekova celine i dela Deo u agregaciji može biti zajednički deo više celina Grafička notacija: Kompozicija Celina Asocijacija kod koje postoji odnos celina/deo, ali je celina odgovorna za životni vek dela Deo Agregacija sa strogim vlasništvom i koincidentnim životnim vekom dela u odnosu na celinu Deo može nastati u toku života celina i može biti uništen pre uništenja celine Deo u kompoziciji može biti deo samo jedne celine Grafički notacija: Celina Deo Elektrotehnički fakultet u Beogradu

35 UML Dijagrami klasa 35 Primer asocijacija Fakultet 1..* studira ima 1 1..* 1..* odgovara za Katedra 0..1 upravlja 1 -jedinca radi pri * * -clan pohadja -kurs -predavac * * * predaje 1..* 1 -sef * Student Predmet Nastavnik Navigacija Strelica označava navigabilnost u naznačenom pravcu Krstić označava da nema navigabilnosti prema označenoj strani Za asocijaciju bez ukrasa navigabilnosti se smatra da je navigabilnost neodređena Grafička notacija: A B A B A B A B Pravo pristupa preko asocijacije Ograničava vidljivost (visibility) objekata u asocijaciji za spoljašnji svet Označava se sa +, #, -, ~ ispred imena uloge odgovarajuće strane relacije + znači da objektima sa te strane mogu pristupati svi objekti preko objekta sa druge strane - znači da objektima klase sa te strane mogu pristupati samo objekti klase sa druge strane # znači da i objekti klasa izvedenih iz klase sa drugog kraja asocijacije imaju pristup ~ znači da i objekti klasa iz istog paketa kao klasa sa drugog kraja asocijacije imaju pristup Primer: +korisnik GrupaKorisnika Korisnik Lozinka * * Podrazumevan je javni vizibilitet uloge u asocijaciji Ugnežđivanje -vlasnik Označava pojam kada je klasa B deklarisana u prostoru imena klase A 1 -kljuc 1..* A + B Projektovanje softvera

36 36 UML Dijagrami paketa Dijagrami paketa Uvod Dijagrami paketa se koriste da prikažu dekompoziciju modela u organizacione jedinice i njihove zavisnosti Dijagrami paketa pomažu: da se uoče zavisnosti između logičkih celina i da se te zavisnosti drže pod kontrolom Primer: P1 <<import>> C P2 PP D P3 B Paket Paket je organizaciona stvar koja se koristi za grupisanje elemenata Paket predstavlja prostor imena i element koji se može pakovati, tako da se može sadržati u drugim paketima Definicija uz UML RM: paket je opšti mehanizam za organizovanje elemenata u grupe, koji uspostavlja vlasništvo nad elementima i obezbeđuje jedinstvenost imena elemenata Paketi se koriste uobičajeno za grupisanje logičkih apstrakcija modela (klasa) mogu se koristiti i za grupisanje fizičkih stvari (komponenata ili čak čvorova) Paket može da obuhvata druge pakete i proste elemente obično postoji jedan paket u korenu hijerarhije paketa koji predstavlja ceo model Koncept paketa odgovara istoimenom konceptu u jeziku Java konceptu prostora imena u jezicima C++ i C# Imenovanje paketa i elemenata Jedno ime elementa mora biti jedinstveno u okviru paketa ali se može koristiti za označavanje drugih elemenata iz drugih paketa Jednoznačnost imena se odnosi na puna (kvalifikovana) imena puna imena sadrže redom imena svih paketa u hijerarhiji od korenog paketa do datog elementa - lista u stablu, razdvojena simbolom :: Primer: klasa Panel koju sadrži potpaket awt paketa java nosi puno ime java::awt::panel Elementi kojima se unutar paketa može obraćati jednostavnim (nekvalifikovanim) imenima su: sopstveni elementi paketa, uvezeni elementi i elementi iz obuhvatajućih (spoljašnjih) prostora imena (paketa) Elektrotehnički fakultet u Beogradu