Projektovanje informacionog sistema biblioteke pomoću UML-a

Analiza i preliminarno projektovanje

U ovom delu prelazimo iz oblasti poslovnih potreba i zahteva u svet projektovanja informacionog sistema. Do ovog momenta bi trebalo da smo iz perspektive korisničkih funkcija stekli dobar uvid u ono što treba da se izgradi. Sada nastavljamo sa logičkim projektovanjem sistema, koje će obezbediti opšti plan onoga što će se graditi.
Naši ciljevi u analizi i preliminarnom projektovanju su:
1. da napravimo takav idejni projekat sistema koji će omogućavati ispunjavanje svih izraženih poslovnih potreba i zahteva;
2. da napravimo opšti plan za sve članove razvojnog tima.

Dijagram klasa
Kao glavna tvorevina prethodnih aktivnosti proizaći će dijagrami klasa sistema. Dijagram klasa, koji prikazuje statičku strukturu sistema, uvek je bio ključni, ako ne i centralni dijagram u mnogim UML i objektno orijentisanim metodologijama. Ali sada u segmentu korišćenja UML-a za projektovanje baza podataka, dijagram klasa postaje još značajniji. Dijagram klasa sada postaje opšti, centralni dijagram koji će kao osnovu u svojim projektima koristiti i tim za aplikacije i tim za bazu podataka.
Dijagram klasa ne samo što ustanovljava glavne entitete u sistemu i njihove međusobne relacije, nego on to sada radi i za entitete u aplikacijama i u bazi podataka. Pošto obe grupe rade zajedno na uspostavljanju dizajna sistema, projektant baze podataka moći će da obezbede potrebne detalje o tajnim klasama u sistemu, umesto da projektanti aplikacija pretpostavljaju koji su podaci raspoloživi. To je od posebnog značaja ako u našem projektu dolazi do promene osoblja.
Posedovanje ovakvog opšteg plana i zajedničkog jezika (UML-a) olakšava promene u upravljanju. U jednom momentu, kada logički model, u obliku dijagrama klasa, postane dovoljno razvijen, dva tima (za aplikacije i bazu podataka) razdvojiće se da dovrše svoje posebne projekte. Projektanti aplikacija nastaviće da razvijaju zajedničke dijagrame klasa do dovoljnog nivoa detaljnosti za programiranje aplikacija (kada tačno dolazi do prelaska na programiranje zavisi od organizacije, kulture, nivoa obučenosti osoblja i drugog). Projektanti baze podataka uzeće zajedničke dijagrame klasa kada većina atributa bude ustanovljena i pretvoriće ih u model baze podataka. Oni će zatim nastaviti sa svojim detaljnim projektovanjem koristeći taj model podataka.
Pitanje: Kako se prelazi od korisničkih funkcija i dijagrama sekvenci na dijagram klasa?
Odgovor: U razvojnim pristupima koji kreću od nivoa podsistema (tj. bez poslovnog modelovanja) obično se primenjuju vrlo opšte smernice za "otkrivanje" kandidatskih klasa za dijagram klasa. Mada su te smernice jednostavne za razumevanje i mogu da se praktično koriste (npr. "izdvoji sve imenice u iskazu koji opisuje problem i napravi od njih kandidatske klase"), ipak one proizvode model klasa u kome se postavlja mnogo pitanja, naročito kod novih korisnika tog pristupa.
Međutim pošto smo u našem projektu prethodno obavili posao na poslovnom nivou, mi smo u prednosti. Ranije smo videli kako se mogu koristiti informacije iz poslovnih modela za unošenje u model poslovnih korisničkih funkcija podsistema, tako da u razvoju tog modela postoji odskočna daska. Sada postižemo sličan princip pri korišćenju informacija iz modela korisničkih funkcija podsistema kao odskočne daske za razvoj dijagrama klasa tog podsistema.


Pošto sam ja već odradio model baze podataka u ERwinu sada sam proširio model, tako što sam dodao još dve tabele (OGRANIČENJE i TIP_OGRANIČENJA), table RADNIK je preimenovana u BIBLIOTEKAR pošto ne želimo da vodimo evidenciju o svim radnicima u biblioteci već samo o bibliotekarima (ove jedne od definicija granice sistema). Tabela RADNO_MESTO koja je bila vezana za tabelu RADNIK je sada izbrisana. Normalizovao sam tabelu CITALAC tako da sam napravio još jednu tabelu MESTO_IZDAVANJA_LK. Preimenovao sam tablelu IZDAVANJE_KNJIGE U IZNAJMLJENE_KNJIGE, a tabelu IZNAJMLJENE KNJIGE sam preimenovao STAVKE_IZNAJMLJIVANJA.

Ova faza u projektovanju je prilično obimna ali ja nisam puno vremena gubio ovde pošto sam već imao model baze podataka, koji sam samo izmenio i proširio u skladu sa novim zahtevima.

Evo dijagrama klasa:

---

primedba: "SUBP" ne moze biti korisnik (actor). SUBP je (uprošteno) sistem za skaldištenje podataka i nije nikakava korisnik informacionog sistema bibilioteke.

Tom logikom bi i sama zgrada u kojoj se nalazi biblioteka bila nekakav korisnik IS-a biblioteke pa bi se mogao napraviti i use case: Čitalac otvara vrata biblioteke.

Ovlaš sam pogledao knjigu koja je navedena na početku teme i ja u njoj nisam video ni jedan dijagram u kojem je SUBP naveden kao korisnik.

---

@ chachka
Mislim da nisi u pravu. Pojam "actor" ne treba shvatiti kao živog korisnika. Bukvalno prevedeno to jeste glumac, učesnik, akter, izvršilac ili činilac. SUBP bi trebalo da bude jedan od učesnika ili još bolje činilaca iz sledećeg razloga. Učesnici su ono što smo u IDEF0 standardu zvali mehanizmi. Znači, ljudi i/ili mašine, pod čijim delanjem se obezbeđuje odvijanje procesa. Otprilike se misli na one složene mašine koje su sposobne da proizvedu neki rad, daju neki rezultat i zamenjiuju čoveka.

Definicija: Actor-izvođač Spoljašnja osoba ili sistem, koji su spregnuti sa datim sistemom (to jest, koriste ga ili mu koriste). strana 25., „UML za projektovanje baza podataka” , Eric J. Naiburg, Robert A. Maksimchuk

http://sparxsystems.com.au/resources/tutorial/use_case_model.html

.......Use Cases are typically related to 'actors', which are human or machine entities that use or interact with the system to perform a piece of meaningful work that helps them to achieve a goal. The set of Use Cases an actor has access to defines their overall role in the system and the scope of their action.

Primer za učesnika - Osiguravajuća kompanija, Spoljašnja ustanova....... (slika 3.6, strana 31. „UML za projektovanje baza podataka”, Eric J. Naiburg, Robert A. Maksimchuk

Definišu se samo use case and actors, koji je od interesa za poslovni proces. Trivijalne radje poput operacije otvaranja vrata biblioteke nisu od interesa. Šta je trivijalno, a šta ne, odlučuje onaj ko opisuje poslovni sistem ili proces.

PS. Dobro je što u ovoj temi izlazimo iz faze funkcionalnog i ulazimo u fazu informacionog modelovanja. To je primerenije forumu "Baze podataka". Nadam se da će kolega biske86, zagristi i onaj deo UML 2.1 kolača koji se odnosi na razvoj.

---

Meni je SUBP tj. sistem za upravljanje bazama podataka (u ovom slučaju Orakl) najbitniji korisnik. On upravlja unosom, ažuriranjem i brisanjem podataka u bazi. Da nije tako morao bi i to da modelujem :). Kao što reče Zidar, ne mora korisnik na dijagramu da bude čovek to mogu da budu i drugi sistemi.

"Actors may represent roles played by human users, external hardware, or other subjects. Note that an actor does not necessarily represent a specific physical entity but merely a particular facet (i.e., “role”) of some entity that is relevant to the specification of its associated use cases. Thus, a single physical instance may play the role of several different actors and, conversely, a given actor may be played by multiple different instances."
en.wikipedia.org/wiki/Actor_(UML)

---

Da se nadovežem na ovo. Na strani 28 knjige "UML za projektovanje informacionih sistema" stoji pasus koji opisuje ovo:
"Na osnovu obezbeđene postavke problema i intervjua sa brojnim osobljem postalo je jasno da cilj kompanije nije da preprojektuje sve poslovne procese. Mi se ne bavimo reiženjeringom poslovnog procesa. Poslovni ljudi žele da se fokusiraju samo na one delove sistema u kojima se koriste klinički zapisi. Usled toga, u poslovnom modelu se neće pojaviti kadrovske službe, poslovi održavanja, naplaćivanje računa i drugi bitni poslovni procesi u EAB-u. Pažnja je usmerena samo na glavni proces tog poslovnog sistema - pružanje zdravstvene nege pacijentima."


Na isti način ja u svom informacionom sistemu ne modelujem događaj da čitalac otvara vrata. Isto tako mogao bih da modelujem infrastrukturu za elektronsku uplatu članarine ali to nisam hteo. Na onom početnom dijagramu "poslovnih korisničkih funkcija" se nalazi spisak stvari koje ja modelujem svojim sistemom. To je u stvari ugovor između mene i naručioca softvera. On je to verifikovao i ne može da mi traži ništa više od onog što se nalazi na tom dijagramu.

---

Nisam u mogućnosti da okačim sliku baze podataka pošto je model prevelik i ne bi mogao da stane na ovako malom prostoru. Tu nisam mnogo problema pošto sam sam prebacio ono što sam imao u dijagramu klasa ispovezivao i postavio primarne i strane ključeve. Što se tiče dijagrama baze podataka imao sam problem kod kreiranja stranih ključeva. Nikako nije hteo da se unese strani ključ. Pitao sam za savet na zvaničnom forumu proizvođača ovog softvera, tamo su mi rekli da za razliku od većine alata (kao što je i ERvin) veza se ne crta od roditelja ka detetu, već obrnuto. Kad sam tako uradio sve je pošlo kako treba.
Stavljao sam tip podataka nvarchar2 umesto varchar2 pošto je jedan od zahteva bio da se knjige (a i ceo interfejs) mogu unositi ćiriličnim pismom.

Odradio sam i dijagram komponenti i dijagram raspoređenosti. Oni nisu komplikovani, pošto mi je zamisao da bi ovaj informacioni sistem bio idealan za implementaciju za neku manju gradsku ili školsku biblioteku. Pošto je tako, te biblioteke sigurno nemaju velika sredstva za ulaganja u ovakve projekte tako da sam pokušao sa što minimalnijim komponentama da radim i sa besplatnim rešenjima. Težio sam da ne radim ove modele po nekom šablonu već kako sam ja to zamislio. Koristio sam Apač veb server, pošto njega znam da instaliram i podignem. Takođe klijenti su na Linuksu što zbog bezbednosti što zbog besplatnosti da ne bi smo nakačili inspekciju na vrat .

Na dijagramu raspoređenosti postoje dve logičke celine. To su LAN i Internet. Deo koji pripada celini Interet može biti realizovan na dva načina. Možemo sami napraviti i imati VEB server (teža varijanta) ili da jednostavno zakupimo neki VEB server (lakša varijanta). Klijent na internetu je čitalac koji pretražuje i skida katalog knjiga. U okviru LAN imamo server baze podataka na Linuksu (stavio sam veoma stabilni i brzi Slekver 12 koji inače koristim). Kontroler diskova na serveru baze podataka je RAID 1. RAID nivoa 1 (disk mirroring) je postupak kojim se za svaki disk u nizu uvodi po jedan rezervni koji u svakom trenutku sadrži sliku originala. RAID 1 uvodi 100% redundanse, zaštita podataka je potpuna, ali je cena sistema diskova duplo veća. Kao što vidite računari u biblioteci nisu zahtevni.
Na forumu proizvođača Enterprajz Arhitekta sam saznao kako da menjam parametre čvorova tj. ovih računara. To se radi tako što pritisnemo desni klik na element, pa odemo na Advanced pa na Set Run State... U prozor koji se pojavljuje potrebno je uneti odgovarajuće informacije..

Moji planovi za ovaj informacioni sistem su da ako budem imao vremena da probam da prebacim u neku besplatnu bazu (mySQL recimo) ili u besplatnu verziju Orakla koja ima ograničenje od 4GB. Možda ovo ograničenje i nije problem za ovako malu bazu. Interfejs bih odradio u Javi pošto mi se sviđa taj jezik i već sam počeo da učim po malo. Vrlo je interesantno. Ali otom potom..Šta vi mislite oko izbora besplatne baze? Meni bi najviše odgovarao Orakl ali ne znam da li je dovoljno 4 GB za podatke.

Evo dijagrama komponenti:



A evo i dijagrama raspoređenosti:




Naravno evo i modela pa pogledajte sve u detalje..

---

Ovde se radi o projektovanju informacionog sistema. Na prvom mestu, šta je to informacioni sistem?

Moje viđenje informacionog sistema je da je to sistem kojeg čine:
- prikupljači podataka,
- podaci,
- metode za pretvaranje podataka u informacije i
- korisnici informacija.
U ovom mom viđenju nema mesta za hardware i software! A zašto?

Hardware i software su alati kojima se služi IS u obavljanju svoje uloge. To je tehnologija koja se koristi u sadašnjem stadijumu razvoja ljudskog društva.

Informacioni sistemi su postojali mnogo pre pojave kompjutera i postojaće i kada (i ako) ljudski rod prevaziđe kompjutere.

Kompjuteri su nastali 40tih godina prošlog veka, a informacioni sistem o stanju faraonovog blaga u starom Egiptu je postojao još pre 4000 godina. Verovatno je bio neprecizan i spor ali je ispunjavao krajnju funkciju informacionog sistema - uvid u informacije koje služe za upravljanje resursima nekog fizičkog sistema.

U prvom svetskom ratu su sve vojske imale sisteme prikupljanja podataka sa terena, slanje tih podataka, obradu i izvlačenje korisnih informacija koje su služile za odlučivanje o daljim akcijama upotrebe vojske. Da li su generalštabovi tih vojski imali SUBP-ove? Naravno da nisu.


Naravno da mašina može da bude korisnik IS-a, ali to nikako nije SUBP! Korisnik IS-a može biti neka "inteligentna" ekspertska mašina koja će na osnovu dostupnih informacija izvući nekakav zaključak i po njemu postupiti (Ko je rekao skynet?)

Uvođenje SUBP-a kao korisnika IS-a je besmisleno, a u prilog ovome govori i recimo sledeći dijagram, kojeg ću pokušati da rastumačim:



1. Administrator obaveštava SUBP da hoće da unese članarinu.
2. SUBP od administratora traži da unese period članarine.
3. Administrator dostavlja SUBP-u period članarine.
4. SUBP od administratora traži da unese vrednost članarine.
5. Administrator dostavlja SUBP-u vrednost članarine.
6. SUBP dobivene podatke o članarini upisuje u bazu podataka.

Da li sada uočavate probleme koji su nastali uvođenjem SUBP-a kao korisnika IS-a?

Evo nekih (uz pretpostavku da je SUBP nekakav SUBP koji podržava SQL):

- U gornjem scenariju SUBP od administratora zahteva da mu se dostave podaci o period i vrednosti članarine. SUBP zahteva! Kako? Kojim to metodama upravljanja bazama podataka taj sistem može da traži podatak o vrednosti članarine? Koji je to SUBP? Oracle, MSSQL? Koji? Kako? Koje su to komande? .... Ah da setio sam se

SUBP od administratora jednostavno nemože da traži vrednost članarine. To nije funkcija SUBP-a, to treba da radi aplikativni softver!

- Administrator šalje SUBP-u podatke o periodu i vrednosti članarine u dve odvojene akcije! Kako? KOje su to komande? Kako to administrator radi? Da li to administrator prvo izvršava INSERT perioda, pa nakon toga UPDATE vrednosti? Kojim to jezikom, kojim protokolom uopšte komuniciraju Administrator i SUBP?

- SUBP podatke o članarini upisuje u bazu podataka! Kako? SUBP grubo rečeno jeste baza podataka! SUBP Upisuje sam u sebe? Moglo bi se reći "SUBP pokreće upisivanje podataka na uređaj za pohranu podataka (hard disk)."

Ja nisam upoznat da postoje SUBP-ovi koji mogu da sprovedu gornji scenario u delo. Ili je možda moja poimanje SUBP-a pogrešno?

Izbacivanjem SUBP-a iz skupa korisnika, u vodu padaju mnogi dijagrami! Ja sam ovde isčitao samo jedan od dijagrama, ali probajte sami da isčitate još po neki i videćete da su dijagrami u kojima figuriše SUBP besmisleni.

Koliko ste to swimline-ova u životu napravili u kojima se kao uloga (izvođač... kako li se već zove?) pojavljuje SUBP?

---

Pošto nisam dovoljno iskusan oko pravljenja informacionih sistema pozivam se na knjigu iz koje učim da ne bi filozofirao sam o nečemu. Ko odgovor na prvu tvoju primedbu citiraću pasus na 155. stranici pomenute knjige:

"Kao što je u ovoj knjizi mnogo puta rečeno, primena UML-a u projektovanju baza podataka znači više nego što je modelovanje struktura tabela, kolona i relacija u bazi podataka - ono znači modelovanje celokupnog projektovanja baze podataka, od zahteva do raspoređivanja. Za ovaj stadijum rešavanja našeg primera bitan je odeljak UML profila za projektovanje baza podataka koji se odnosi na mogućnosti da se modeluje način i mesto smeštanja podataka."

Što se tiče druge primedbe za SUBP nisam siguran.
Recimo kažeš SUBP od administratora ne može da traži vrednost članarine. U pravu si da to treba da čini aplikativni softver, ali moj cilj ovde nije projektovanje aplikacije već samo baze podataka. Možda bi između administratora i SUBP trebalo da stoji aplikacija ali je ja ovde ne modelujem. Tako da sam izvršio neku apstrakciju i mislio sam da je jasno da ne postoji način da upravljamo bilo čime u bazi bez aplikacije.
SUBP upisuje podatke o članarini u bazu podataka. SUBP je sistem za upravljanje bazama podataka, kao što i samo ime kaže. Razlikuje se od pojma baza podataka. Možemo imati više baza podataka a SUBP (recimo Orakl) preko SQL-a unosi podatke u svaku od baza. Znači SUBP ne upisuje sam u sebe.
Još sam neiskusan u pravljenju informacionih sistema i nisam napravio mnogo swimlineova kojima je uloga SUBP ali ovo je moj prvi projekat u UML-u. Kao što znaš radio sam u BPwinu i ERwinu isti projekat za biblioteku. I tamo (u BPwinu) sam imao SUBP kao kontrolu. Možda da se uključi još neko u diskusiju pa da razmotrimo ovo malo bolje jer nisam siguran. Probaću i na forumu sparxsystemsa, da zatražim savet oko ovoga..

---

U fazi funkcionalnog modelovanja treba opisati skup alata i smeštajnih kapaciteta kojima se obraća administrator i s čime komunicira. To još uvek nije ni baza podataka (nju ćemo dobiti u fazi informacionog modelovanja), a nije ni aplikativni softver koji tek treba da dobijemo u fazi aplikativnog modelovanja.
Može biti da je SUBP nesrećan izbor za imenovanje onog s čim administrator komunicira, ali bih voleo da čujem dobar predlog za to, a da ne pati od istih bolesti tipa: „Kojim to jezikom, kojim protokolom uopšte komuniciraju Administrator i ......?“

Ja u principu uzmem SUBP (Msaccess.exe), napravim bazu podtaka, recimo StrukturaTabela.mdb sa svim relacijama i potom nad njom napravim Biblioteka.mdb sa svim ostalim objektima. Ne vidim ni jedan dobar razlog da taj Msaccess.exe u prvoj fazi funkcionalnog modeliranja ne nazovem onim što jeste. SUBP. To je spoljni sistem sa kojim komunicira Administrator i učesnik u poslovnom procesu, onakvom kakvim ga vidi opisivač.



_{[Ovu poruku je menjao Getsbi dana 24.08.2009. u 14:15 GMT+1]}

---

Pregledao sam spomenutu knjigu detaljnije. Nigde se SUBP ne spominje kao korisnik (covek/mašina/drugi sistem) informacionog sistema. U knjizi se spominje "Medical Records Manager" ali to i dalje nije SUBP, to je pre nekakav radnik u arhivi.

Potražite na internetu primere dijagrama aktivnosti, dijagrame sekvenci, swim line dijagrame. Ni u jednom nećete naći eksplicitno pojavljivanje SUBP-a (odnosno DBMS-a), jer to jednostavno nije ispravno.

Getsbi traži da imenujem sa čime to administrator komunicira, i ok evo:
Administrator komunicira sa bibliotekarom i sa samim informacionim sistemom.

Da nebude da samo negiram rad drugih, evo i mog doprinosa u remodeliranju procesa koji se u projektu zove "unos članarine čitaoca":

U projektu je ovaj proces opisan sledećim dijagramom aktivnosti

Model se nepravi samo zbog developera, a UML se reklamira kao jezik kojeg razumeju i netehničke osobe, pa imam pravo da ovaj dijagram laički protumačim:

Ode čitalac u biblioteku i hoćete da uplatite članarinu: "Dobar dan, ja bih da uplatim članarinu.", a bibliotekar će na to: "nema problema, sačekajte da se ja malo poigram sa mojom igračkom zvanom SUBP." Čitalac čekate, bibliotekar nešto kucka, ni ne obraća pažnju na njega, i nakon izvesnog vremena kaže: "U redu je - Vaša članarina je uneta u naš sistem." Čitalac će na to: "Hvala lepo, doći ću i sledeće godine da mi unesete članarinu. Doviđenja."

Na kraju godine pita direktor biblioteke: "A gde su novci od članarina?" "Ups...", odgovara bibliotekar, "bili smo toliko zauzeti novim informacionim sistemom da smo zaboravili da kažemo da čitalac plaća članarinu i sa se za to izdaje priznanica (račun)."

Naravno da proces učlanjenja ne liči na gornje tumačenje, a model bi trebalo da može da protumači svaki actor pa samim tim i čitalac i da na osnovu njega zaključi šta mu je od akcija dostupno. A verujte mi 95% čitaoca neće znati da postoji tamo neki SUBP, pa čak ni 95% bibliotekara to neće znati.

Proces plaćanja članarine više liči na sledeći dijagram kojeg sam sastavio

Pokušajte da protumačite ovaj dijagram i videćete da je daleko sličniji pravom procesu uplate članarine.

---

Sviđa mi se ovaj dijagram aktivnosti koji si napravio. Dobra je ideja da se izda račun kad čitalac uplati članarinu. Samo moraću to nekako da uklopim sa ovim što sam ja radio. Ako budem morao da menjam sve dijagrame onda je to katastrofa. Ima ih baš mnogo.

---

Slažem se da ga nazoveš informacionim sistemom ali se ne slažem da ga izostaviš iz komunikacione linije. Tvoj zadnji dijagram predstavlja samo jednu stranu komunikacije i to onu koju smo imali i pre reinženjeringa poslovnog procesa. Opisujemo poslovni sistem rada biblioteke. Na ovom nivou je nužno opisati učešće svih spoljnih učesnika i svih spoljnih sistema, pa i IS-a koji u njemu učestvuje. Inače ćemo opisati stanje pre reinženjeringa, što nem nije namera.

---

Ako budem morao da menjam sve dijagrame onda je to katastrofa. Ima ih baš mnogo.

Bas tako ima bas mnogo dijagrama i ne daj boze da se nesto pogresi u startu, pa se posle mora menjati...

Svidja mi se cela tema i kako Biske napreduje. Nazalost, desava se ono sto smo svi preziveli. UML dijagrami se sire sve dok skup dijagrama ne postane preveliki za odrzavanje i dok se ne izgubimo u njemu. A onda dodje Chacka i nadje gresku u jednom od osnovnih i trivijalnih zadataka....

UML zaista nudi ogroman broj dijagrama. To ne znaci da su svi potrebni. Ali niko nas ne uci koji nam kada trebaju. Svi dijagrami izgledaju veoma profesionalno, toliko da zamagle sustinu. Drugim recima, kako god da nacrtate dijagram, on izgleda OK. A nije svaki put Ok. Iz licnog iskustva, UML je dobar za crtanje statickih mapa. Ono sto zoves "dijagram rasporedjenosti" mi se svidja. To je lepa staticna slika. Pokazuje nesto sto ce biti ili sto jeste. Korisno, u svakom slucaju. Medjutim, UML ne pomaze bas mnogo kad dodje do dinamickih stvari, a tu bi trebalo da bude najjaci. Dijagrami izgledaju bajno i profesionalno i uglavnom nam ne kazu nista. Dokaz - ovo sto imamo sa naplatom clanarine. Uzmi na premer Sequence dijagram. Neije lak da se nauci i razume, a u sustini mi ne kaze nista. Kaze mi da kada izadm INSERT INTO naredbu, moj SUBP ce da insertuje red u tabelu. To bez sequence dijagrama ne bih mogao da shvatim, zaista.

Najkorisniji od dinamickih dijagrama ispada da je Activity chart (swimlane diagram, crossfunctional chart), ali to nije izmislio UML, to postoji vec nekih 50 godina u oblasti koaj se zove Process Management, Quality Control i slicno. Swimlane diagram, kada se primeni na sam poslovni proces (svi aktori su ljudi) pomaze da se vide relacije medju elementima realnog sistema (ne mislim na infromacioni u uskom smislu). Odatle se lako prelazi na ER dijagram (Peter Chen) i eto ti logickog modela baze podataka. Proigraj operacije unosa i editovanja za svaku operativnu tabelu (koja nije look-up) i ti si na konju. Prosti slucajevi idu sa INSERT INTO, slozeni su transakcije sa nekoliko medjuzavisnih INSERT/UPDATE i to je sve.

Ipak, dobro je proci kroz ceo projekat, posle ces imati sliku sta ti od toga treba, a sta ne. Seti se da si isti projekat prvo uradio bez UML, 'klasicnim' metodama. I uradio si ga. Brzo, efikasno. Da li si siguran da ti UML pomaze da uradis bolji i brzi posao nego bez njega? Druga stvar koju treba da imas na umu jeste to sto radis projekat koji si upravo odradio pa su ti mnoge stvari poznate. Pokusaj da primenis UML na nesto potpuno novo, nesto sto ne poznajes..... Stari dobri peter Chen i Chris Date mnogo brze dovode do resenja.

U svakom slucaju, nastavi da radis, tema je zanimljiva, ima se sta videti.

Necu da zanovetam dalje.

I srecno na ispitu.