U ovoj lekciji obrađivaćemo:

  • Klasifikacija UML forme
  • UML notacije
  • Klasni dijagram (class diagram)
  • Dijagram slučajeva korišćenja (use case diagram)
  • Dijagram aktivnosti (activity diagram)

 

Slika 1.

UML je nastao iz napora da se zajedno objedine ideje tri stručnjaka: Grady Booch-a, Ivar Jacobson-a i James Rumbaugh-a. Sam pojam "unified" može na prvi pogled da se odnosi na unificiranje njihovih metodoloških ideja, pre nego da se radi o unificiranju notacija koje čine jezik za modelovanje. Naime, jedna od kritika UML-a je upravo da je taj proces rezultirao u preterano velikom broju zapisa, posebno kada se uporedi sa drugim dizajnerskim praksama. Od 1996, odgovornost za razvoj UML je poverena Object Management Group-u (OMG), te je tako 1997. godine usvojen kao OMG standard, iako se i dalje radi na razvoju i proširenju, kako sama tehnologija napreduje.

Postoji razlika u načinu opisivanja nekoliko notacija. Zapis je mnogo manje karakterističan u poređenju sa drugim zapisima. Za UML već postoji široka literatura, a neke od referenci su Rumbaugh (1999)[1], Stevens i Pooley (2000)[2]. Osim toga, većina udžbenika koji opisuju povezane Unified procese takođe sadrže neke rasprave o UML-u i primere njegovog korišćenja. Drugim rečima, ne postoji jedinstven tekst koji nudi široko priznati opis UML-a i njegove primene. Od domaćih izdanja može se izdvojiti Veljovic (2004)[3].

UML forme

Klasifikacija UML formi je izvršena prema Rumbaugh (1999) na:

  • strukturne forme (odnosi se na elemente sistema)
  • dinamičke forme (tiču se opisa ponašanja sistema)
  • modele upravljanja (odnose se na organizaciju samih modela)

 

Prva dva se mogu prepoznati prema odgovarajućem konstrukcionom, funkcionalnom i gledištu ponašanja.

Ovde ćemo istaći tri od devet UML notacija:

  • klasni dijagram (class diagram) (strukturalni)
  • dijagram slučajeva korišćenja (use case diagram) (strukturalni) 
  • dijagram aktivnosti (activity diagram) (dinamički)

 

U smislu konvencije, korisno je imati na umu da UML čini opsežnu upotrebu formi blokova i linija, a posebno često se koriste varijacije linija i strelica kako bi se razlikovali različiti oblici veza. Po konvenciji, tamo gde je oblik veza potrebno eksplicitno pokazati, on se se nalazi između duplih strelica kao npr. <<extend>>.

Klasni dijagram

Osnovni koncept objektnog modela je fokusiranje na veze koji uključuju klase, gde klasa grubo obavlja ulogu template-a koji opisuje generalni koncept i bilo kojeg objekta koji je kreiran od klase, i koji čine određene instance date klase, sa posedovanjem individualnog stanja i identiteta.

Identifikacija kandidata za klase je jedan od primarnih aktivnosti u praksi objektno orijentisanog dizajna.

UML klasni dijagram, nudi sredstvo pomoću kojeg se opisuju klase, kao i interakcije između njih, pogotovo onih koji se zasnivaju na korišćenim vezama[4] i konceptu nasleđivanja. Slika 2. ilustruje primer jednostavne klase u UML-u, i ova forma se može koristiti u različitim fazama razvoja dizajna. U ranim fazama dizajna, pojedinosti atributa i operacija mogu se izostaviti ili ograničiti na minimum potrebnom da predstavlja odgovarajući logički koncept ugrađen u određenu klasu. U kasnijim fazama, kada se donose odluke o dizajnu, može se proširiti i opis. Sa gledišta modela, to je jedan element koji se koristi za konstrukciono gledište, a bavi se vezama koje postoje između (potencijalnih) implementacionih elemenata, ali na vrlo visokom nivou apstrakcije.


Slika 2. UML notacija klase

Klase mogu biti povezane na razne načine. UML prepoznaje šest oblika veza:

  • zajednica (pridruživanje),
  • zavisnost,
  • tok,
  • generalizacija,
  • realizacija i
  • korišćenje.

 

Slike 3. i 4. prikazuju jednostavna dva primera gore navedenog. Slika 3 pokazuje vrlo jednostavnu zajedničku vezu sa naznakom da bilo koji od klijenta banke može biti povezan sa bilo kojim brojem računa. Zbog jednostavnosti, ograničeno je udruživanje računa na samo dva klijenta. Treba istaći, da su na ovoj slici klase predstavljene samo imenom, kao i to da je izbegnut detaljniji opis ovih veza.

Slika 4. pokazuje primer generalizacije kroz nasleđivanje. Generalna klasa BankAccount gradi osnovu za stvaranje podklasa DepositAccount i CurrentAccount koji, iako imaju različite oblike operacija, i dalje imaju osnovne atribute i operacije od klasa roditelja BankAccount.



Slika 3. Primer zajednice klasa u UML-u


Slika 4. Primer generalizacije klasa preko nasleđivanja u UML-u

Dijagram slučajeva korišćenja (Use Case Diagram)

Iako je koncept scenarija korišćenja sistema jedan od neformalno razvijenih (tokom mnogih godina) u smislu potrebe određivanja kako će se sistem koristiti, rad Ivar Jacobson-a je formalizovan i po pitanju koncepta i njegove uloge u dizajnu procesa[5][6]. Iz tog je nastao uopšteniji koncept slučajeva korišćenja (eng. Use case). Može se povući analogija između veza slučajeva korišćenja/scenarija i programa/izvršenja treda (eng.thread). U tom smilslu, program opisuje opšti skup mogućih akcija, dok je tred jedna instanca ovoga, pa tako slučajevi korišćenja opisuju skup mogućih interakcija između sistema i ostalih učesnika (ljudi, hardver i dr.), dok scenario opisuje određenu sekvencu ovih interakcija.

UML use case diagram izražava ovu ideju na prilično uopštenom nivou. Slika 5. prikazuje osnovne elemente jednog use case dijagrama. Sam use case je prikazan kao ovalan, i predstavlja logički opis jednog dela funkcionalnosti sistema (Rumbaugh, 1999). Korisnici su predstavljeni figurama, a prikane su i četiri vrste odnosa, iako dve od tih dele jedan reprezentativni oblik i stoga treba da budu obeleženi pomoću naznačene forme.


Slika 5. Elementi Use case diagrama (UML)

Klasifikacija dijagrama slučajeva korišćenja sa stanovišta pogleda modela predstavlja veliki izazov. Slučajevi korišćenja se odnose na interakcije koje se javljaju između sistema i njegove okoline, te stoga imaju izgrađen aspekt ponašanja. Međutim, oni su takođe odnose na zadatke koje sistem izvodi, tako da se može pripisati i funkcionalna kategorizacija. Ne postoji nesklad u tome. Dok je okvir gledišta koristan klasifikacioni mehanizam, granice nise čvrste, a mnoge notacije imaju elemente za više od jednog stanovišta.

Slika 6. prikazuje primer use case dijagrama, zajedno sa tekstualnim primerom jedne use case komponente. Može se primetiti da notacije koje su date u UML ne reprezentuju pojedinosti samog use case, u onoj meri kao njegov kontekst. Potpuniji pregled načina na koji se sami use case mogu modelovati dali su Ratcliffe i Budgen (2001)[7].


Slika 6. Jednostavan primer use case modelovanja (UML)

Dijagram aktivnosti (Activity Diagram)

Dijagram aktivnosti se može posmatrati kao varijanta automata sa stanjima. Pre nego modelovanje stanja sistema i događaja koji uzrokuju prelaze između njih, kao u ranijem primeru Statecharts, dijagram aktivnosti je prilično nejasno opisan kao "modelovanje izračunavanja i protoka"[1]. Stevens i Pooley[2] su ponudili prilično jasniji opis, koji se može sažeti kao jedan od načina modelovanja neophodnih zavisnosti i redosleda koji nastaju kada operacija ima višestruke ciljeve.

Dijagram aktivnosti je prema tome koristan za modelovanje tipa "koordinacije" situacija u kojoj dati proračun ne može biti nastavljen sve dok se ne zadovolje određeni uslovi (na primer, novi podaci su dostupni i (logičko I) prethodno izračunavanje je završeno). Tako da stanja u ovakvim dijagramima sada predstavljaju izvršavanje izraza, ili izvođenje akcije, a fokusiranje je na okidanju prelaza između stanja takvog sistema i prema tome na sinhronizaciji i koordinaciji različitih izračunavanje i akcija. Dijagrami aktivnosti stoga liče, bar manjim delom na Petri Net Graph[8]. Može se svrstati prvenstveno kao opis ponašanja u smislu gledišta modela, mada i sa nekim funkcionalnim opisima takođe.

Ključni elementi u notaciji su sledeći:

  • Aktivnost (activity), prikazana kao imenovani okvir sa zaobljenim stranicama
  • Tranzicija (transition) između aktivnosti, prikazana pomoću neoznačenih strelica. Nedostatak oznake je, za razliku od slučaja Statechart, jer prelazi proizlaze iz operacija same aktivnosti, a ne zbog spoljašnjih događaja.
  • Sinhronizacioni bar (Synchronization bar) je debela vodoravna linija koja predstavlja koordinaciju aktivnosti. Kada se svi prelazi u baru završe (koordinacioni bit) onda se aktviraju spoljni prelazi.
  • Romb odluke (decision diamond) efikasno utvrđuje putanju odlazećih tranzicija. Prednost je korišćenje notacija koje pokazuju više mogućih odlazećih tranzicija. Kada se to koristi, neophodno je označiti tranziciju radi indikacije koji uslovi su neophodni za određenu putanju.

 

Slika 7. pokazuje jednostavan primer activity diagram-a, koji opisuje rad (jednim delom) bankomata. Ovde se koriste samo dva sinhronizaciona bara, jedan prikazuje podelu tranzicija (gde se više akcija pojavljuju nakon koordinacije akcija, nazvano račvanje), a drugi suprotan slučaj, gde se operacije nastavljaju tek nakon dve završene tranzicije, nazvano pridruživanje.


Slika 7. Primer UML dijagrama aktivnosti za bankomat

UML gledišta

Jedna od posledica prenapunjenosti UML notacije je da proizvodi maglovitu sliku pogleda. Zaista, jedan od  razočaravajućih aspekata UML-a je nedostatak jasnog okvira za integraciju  različitih pogleda unutar modela. Na neki način, UML pre daje unutrašnji pogled, u tome što je samo notacija vezana za model upravljanja ona koja je zaista namenjena u pomoći pri upravljanju složenosti samog UML, radije nego krajnjeg problema koji je predmet procesa modelovanja.

Reference:

1. Rumbaugh J., Jacobson I. and Booch G. (1999), The Unified Modeling Language Reference Manual. Addison-Wesley
2. Stevens P. and Pooley R. (2000). Using UML: Software Engineering with Objects and  Components.Addison-Wesley
3. Alimpije Veljović (2004), Osnove objektnog modeliranja - UML, Kompjuter Biblioteka
4. Parnas D.L. (1979). Designing software for ease of extension and contraction. IEEE Trans. Software Eng.
5. Jacobson I., Christerson M., Jonsson P. and Overgaard G. (1992). Object-Oriented Software Engineering: A Use Case Driven Approach. Addison-Wesley
6. Jacobson I., Booch G. and Rumbaugh J. (1999). The Unified Software Development Process. Addison-Wesley
7. Ratcliffe M. and Budgen D. (2001). The application of use case definitions in system design specification. Information & Software Technology
8. Stevens W.P. (1991). Software Design: Concepts and Methods. Prentice-Hall

Dodaj komentar Sviđa mi se - (1) Ne sviđa mi se - (1)    

  • UML forma za modelovanje 1
  • UML forma za modelovanje 2
  • UML forma za modelovanje 3