hernad

Glavna priča vodi se o UML-u(*) .

Kada sam se prije 6-7 godina susreo sa UML-om, mislio sam da je to pravi "silver-bulet" analize i dizajna. Sjećam se da sam bio pravi UML entuzijasta. Ali sada mi je taj entuzijazam splasnuo ... Ne ne - ne radi se o kritici OOAD-a kao predmeta,  ako ste to pomislili :).

Radi se percepciji UML-a kao alata za modeliranje.

Za ispit sam se priprema zajedno sa Emirom. Obojica smo suglasni u jednom:

Previše je mogućih varijanti za jednu te istu stvar ...

Naime, koji god primjer uzmemo, previše smo dumali kako bi to najbolje bilo uraditi. Sama sintaksa jezika nije problem, ali ipak mi nešto tu fali ... Znam, znam - sve je stvar treninga, ali opet ... očekivao sam da će mi ovo biti puno logičnije. Prije 5 godina jeste ?!

Ostarilo se - ko zna, možda je to razlog.

Drugi mogući razlog je činjenica da mi se "gerilski" sistem analize i dizajna sistema više sviđa. Pod tim mislim na raznorazne metode agilnog razvoja software-a (TDD, BDD(**) ...). U sklopu ovih metodologija analize i implementacije software-a puno manje se polaže na alate.

Komad papira, neki crtež slobodnom rukom - to sve predstavlja sasvim dozvoljen način opisivanja modela. Pri tome se UML ne zabranjuje, ali se ni ne forsira ... Agile developeri i dizajneri začudo vrlo malo koriste UML. Je li začudo ili je to očekivano ?

Nemam pojma.

Ali vratimo se pripremi ovog ispita. Za prvi parcijalni se obrađuju ovi dijagrami:

• Use case
• Sequence (sekvencijalni)
  • System sequence diagram(***)
• Collaboration/Communication (kolaboracijski)
• Dijagram klasa i objekata
  • Domain dijagram (****)

 

Primjer Use: case Web oglasi

Modelirati sistem koji omogućava korisniku objavljivanje i pregled oglasa na Web-u. Sistem će koristiti tri tipa korisnika: administrator, korisnik i korisnik-urednik.

Na korisničkoj strani imamo korisnika i korisnika-urednika.

Nakon što se korisnik uspješni identificira omogućeno mu je da: preda oglas, pregleda oglase, promjeni lične podatke i da se odjavi.

Korisnika-urednika kreira administrator i on definiše osnovnu strukturu oglasa. Nakon što se uspješno identificiraju korisnici-urednici mogu: pregledavati vlastite kategorije, kreirati nove kategorije, brisati kategorije, pregledavati zatvorene vrste oglasa, odobriti članstvo, pregledati najčitanije oglase, pregledati najaktivnije čitaoce i odjaviti se.

Administrator ima najveća ovlaštenja i upravlja sistemom. On može da kreira urednike-korisnike, mijenja njihove podatke ako je potrebno i ažurira sadržaj baze podataka.

Odobrenje članstva:

Urednik vidi ko traži članstvo, pa mu odobrava ili odbija članstvo za tu vrstu kategorije. Ako je odobreno članstvo, kreira novi objekat korisnik i šalje mu se email sa objavještenjem o odobrenju, a ukoliko nije odobreno članstvo dobija email sa obavlještenjem da je odbijen.

Zadaci:

a) modeliraj funkcije sistema usecase dijagramom

b) napravi specifikaciju slučaja upotrebe: "odobrenje članstva"

Ovo sam popunio na odgovarajućem usecase-u u PowerDesigner-u:

https://gist.github.com/925682

c) nacrtati sekvencijalni dijagram za slučaj "odobrenje članstva"

d) generišite dijagram saradnje (kolaboracijski dijagram)

Napomene, komentari:

Uočio sam da nedostaje asocijacija administratora na usecase "management kategorija" (na osnovu: ... definiše osnovnu strukturu oglasa).

Pri rješavanju dijela b)

Iskreno nisam siguran da li je zamišljeno da se ovo popunjava na ovaj način.

Moje dileme:

• Da li je odbijanje "Exception" slučaj ? po menij nije, nego regularan alternativni slučaj.
• Postcondition - ja sam naveo glavni proizvod ove funkcije - kreiranje novog korisnika.  Na to se misli ?

c) d)

U ovim dijagramima se prijazuju objekti. Notacija za prikaz je objekat:Klasa, ili samo :Klasa. Znači "user_1:User", ili samo ":User".

U mojim primjerima postoji greška (u odnosu na uobičajene konvnecije) - imena klasa su prikazana malim slovima, a trebalo je velikim: :Urednik, :Screen, :Zahtjev, :Korisnik, :EmailGateway. Inače ova notacija čita se npr: "neki objekat klase Urednik".  

---

(*) UML - unified modeling language

(**) TDD, BDD - Test driven development, Behaviour driven development.

(***) actor <-> sistem; kompletan sofverski sistem je jedan objekat - black-box

(****) konceptualni dijagram klasa - bavi se samo najbitnijim klasama domena (sistema) koji se modelira