Radim po knjizi "UML za projektovanje baza podataka" koju su pisali Eric J. Naiburg i Robert A. Maskimchuk. Knjiga je prevedena kod nas i može se kupiti u CET-u a izdavač originalnog izdanja je Addison Wesley. Ja imam originalno izdanje na engleskom u pdf-u i knjigu na srpskom.
Često ću se u svojim objašnjenjima pozivati na ovu knjigu.

Pa da krenemo. U prilogu se nalazi model pa pogledajte ono što sam do sada uradio.
Razumeti neku kompaniju i njene poslove veoma je težak zadatak. Potrebno je da razumete šta kompanija radi i koje su aktivnosti obuhvaćene, koje informacije postoje, ko su klijenti i partneri i još mnogo toga. [UML za projektovanje baza podataka]
Kao i kod izrade svakog informacionog sistema najpre je potrebno sakupiti zahteve. To se vidi na Requirements modelu. Tu postoje funkcionalni i nefunkcionalni zahtevi.
Paket funkcionalnih zahtevi prikazuje zahteve koji opisuju kako ce dati sistem obradjivati i cuvati informacije. Prikazuje karakteristike i pravila koji moraju da budu predstavljeni da bi potpuno implementirali zeljenu funkcionalnost.
Paket nefunkcionalni zahtevi prikazuje razlicite operacione parametre koji definisu okruzenje u kome ce sistem postojati. To su kriterijumi koji definisu nivoe performansi, prosirivosti, pravljenja rezervne kopije (backup), oporavka posle pada sistema (disaster recovery) i ostalih operativnih zahteva.

Dobra stvrar koja je urađena u ovom enterprajz arhitektu je što za svaki zahtev možemo staviti neku od oznaki. To činimo tako što dva puta kliknemo na neki zahtev i u polju status izaberemo jednu od ponuđenih opcija (proposed, aproved, implemented,..). Za svaki od ovi statusa postoji odgovarajuća boja (primetićete da su neki zahtevi plavi a neki žuti). Prethodno moramo da omogućimo prikazivanje statusnih boja. To činimo tako što odemo u Tools/Options pa kliknemo na Objects i štikliramo opciju "Show status colors on diagrams". Obratite pažnju još na paket funkcionalni zahtevi unutar paketa karakteristike. Tu je za svaki zahtev prikazano koja korisnička funkcija realizuje koji zahtev.

Najbolje način da razumemo informacije dobijene od mnogo učesnika je da modelujemo njihove opise. Vizuelizacija poslovnog sistema, umesto da se samo čitaju reči, može da bude od velike pomoći.
Odmah nakoh završetka skupljanja zahteva krećemo na izradu poslovnog modela. Prvi deo poslovnog modela je model poslovnih korisničnih funkcija, koji je fokusiran na to kako se sistem vidi od strane spoljašjnih izvođača i njihovih interakcija sa tim sistemom. Spoljašnji izvođači, koji modu da budu ljudi ili sistemi, nazivaju se poslovnim izvođačima. Bilo da ove definicije izvođača jesu ili nisu očigledne poslovnim ljudima sa kojima radite, svakom poslovnom izvođaču treba da bude dodeljena definicija.
Dijagram korisničkih funkcija poslovnog sistema je dijagram predviđenih funkcija u tom sistemu i koristi se u poslovnom modelovanju kao polazna osnova za identifikovanje uloga u usluga u datoj organizaciji.
Da bi smo kompletirali model poslovnih korisničkih funkcija, moramo detaljno da razradimo odvijanje poslova u svakoj poslovnoj korisničkoj funkciji. To činimo pomoću dijagrama aktivnosti na kojima se prikazuje odvijanje poslovnih procesa i ko izvodi razne delove tih procesa.

Hvala na trudu :-)

Mozes li da prebaci slike u neki format koji se lakse cita, PNG il JPEG ili PDF, tako da mozemo da ih vidimo.

@ Zidar
Čak i da napravi slike (mnogo bi ih bilo), teško da možeš da dobiješ sveobuhvatni uvid. Jedino da ovde skineš trial verziju Enterpise Arhitect:http://www.sparxsystems.com.au/products/ea/trial.html
Ja sam skinuo taj softver i pogledao. Imam neke primedbe, ali čekam da vidim kompletan funkcionalni model u nekoj od sledećih Ivanovih poruka.

Stvarno nema svrhe da okačim sve dijagrame ali okačiću samo nekoliko njih kao ilustraciju.
Kao što sam rekao najpre sam sakupio zahteve i uneo ih na dijagramu zahteva (Requirements). Postojalo je dosta zahteva tako da sam ih organizovao po paketima. Evo i primera.
Kao što rekoh najpre sam pravio zahteve. Evo primera funkcionalnih zahteva:


Dobra stvar kod zahteva je što možemo napraviti dijagram tako da vidimo koja korisnička funkcija realizuje koji zahtev kao što je prikazano na prethodnoj slici. Takođe napominjao sam upotrebu boja, što je dobro kod sakupljanja zahteva ne od strane jednog čoveka već tima ljudi.

A evo i nefunkcionalnih zahteva:


Kada završimo sa sakupljanjem zahteva idemo sa izradom dijagrama korisničkih funkcija.


Za svaku korisničku funkciju pravimo dijagram aktivnosti. Evo primera dijagrama aktivnosti za korisničku funkciju "Unos i azuriranje čitaoca".


Završio sam i drugi deo poslovnog sistema.
Drugi deo modela poslovnog sistema je poslovni objektni model, koji je fokusiran na to kako ljudi unutar poslovnog sistema (radnici u sistemu) izvršavaju poslovne procese. Prva komponenta poslovnog objektnog modela je dijagram klasa koji sadrži poslovne izvođače, radnike u sistemu, poslovne entitete, kao i njihove međusobne asocijacije, potrebne za ostvarivanje razmatrane poslovne korisničke funkcije.
Poslovna korisnička funkcija daje nam polaznu tačku za poslovni objektni model, tj. daje nam spoljašnje entitete i radnike u sistemu od kojih polazimo. Na primer kada kliknemo na plusić pored "Use Case Model" i izaberemo "PoslovanjeBiblioteke" videćemo ko su radnici i spoljašnji entiteti. Na primer za korisničku funkciju "Unos i ažuriranje citaoca" radici su Bibliotekar i SUBP (sistem za upravljanje bazama podataka). Na osnovu ovoga smo napravili dijagram klasa. Možemo ga pogledati tako što izaberemo "Use Case Model", zatim "Primarne korisničke funkcije", "Unos i azuriranje citaoca", i kliknemo na plavu ikonicu "Unos i ažuriranje čitaoca". Otvoriće nam se dijagram klasa odgovarajuće korisničke funkcije.


Napomena:Novi dijagram dodajemo tako što pritisnemo desni klik na korisničku funkciju a zatim idemo na Add i izaberemo tip dijagrama koji želimo da dodamo.
Pošto dijagram klasa prikazuje odnos između odgovarajućih entiteta u ovoj poslovnoj funkciji, potrebno je da budu opisani detalji vezani za unutrašnje procese. To se čini dijagramom sekvenci. Za neke dijagrame klasa imamo po jedan a za neke po dva dijagrama sekvenci. Čitava poenta je opisati sistem što bolje tj. pokupiti od korisnika budućeg sistema što više informacija. Usput, dijagrami sekvenci se čitaju vertikalno, odozgo na dole. Evo primera dijagrama sekvenci za dijagram klasa "Unos i ažuriranje čitaoca".






Rezime dosadašnjeg rada
Gledajući modele poslovnih korisničkih funkcija poslovne objektne modele, projektant baze podataka (opet ja) počeće da razume koji su podaci potrebni za izradu baze podataka. Naravno, ti podaci treba da se razrade i mnogi još nedostaju, ali ovo je dobra polazna tačka. Koristeći UML, timovi mogu zajednički da koriste sakupljene informacije i primenjuju ih u svom delu posla.

_{[Ovu poruku je menjao biske86 dana 04.08.2009. u 22:51 GMT+1]}

Prethodne slike su malo velike ali šta je tu je. Zaboravio sam da okačim model, pa evo ga u prilogu.

Kada je Objektno orjentisana analiza u pitanju, bez obzira što je UML 2.0 drugačiji standard od IDEF0 i što se bitno razlikuju, jer je UML pravljen da svi članovi tima (analitičari, developeri, programeri), učestvuju u izradi dokumentacije da bi je sa lakoćom koristili u svom delokrugu, a IDEF0, IDEF1X kao i neki drugi standard su okrenuti pojedinim stručnjacima, nemože se zaobići činjenica da se poslovna analiza radi dvosmerno (Top Down i Bottom Up).

Top Down su Poslovni slučajevi upotrebe-Busines Use Case. To je onako, kako rukovodioc vidi poslovni proces. Poslovni slučajevi upotrebe (poslovni izvođač i poslovne korisnčke funkcije........) razlažu se na dijagrame poslovnih aktivnosti. Ovo bi bio pandam dijagramu konteksta u u BpWin-u.

Bottom Up su Sistemski slučajevi upotrebe-Use Case. To je onako kako pojedini korisnik sistema vidi svoj deo poslovnog procesa. Sistemski slučajevi upotrebe (izvođači i korisničke funkcije.......) razlažu se na dijagrame sistemskih aktivnosti. Ovo bi bilo pandam dijagramima dekompozicije u BpWin-u.

Pošto rukovodioc ne mora da zna kako u tančine korespondiraju korisnici i funkcije već ko je za koju funkciju zadužen, tako je i Busines Use Case manje detaljan u odnosu na Use Case, te se kod ovog drugog modeluju dinamički apekti sistema (Dijagrami interakcije u obliku dijagrama sekvenci i dijagrama saradnje).

Primedbe:

Zato bi u Project Browser-u trebalo da postoji Busines Use Case i Use Case sa tačno primenejenim svojim simbolima. Obrati pažnju na dve vrste izvođača i dve vrste korisničkih funkcija. Poslovne i obične. Ne poznajem dobro alat kojim se služiš (EA) ali bi trebalo da postoje različiti simboli.

Imaš plivačku staze i učesnike: Rezervna kopija, Izveštaji ...... Takvi učesnici u spisku ne postoje. A i da postoje, oni ne "delaju". SUBP se naravno može shvatiti kao izvođač. U vrh plivačkih staza se upisuju izvođači. Rezervna kopija i Izveštaji su izlazi u IDEF0 standardu, a ne mehanizmi. Spominjem stalno IDEF0 da bi ti bilo jasnije o čemu govorim, jer si to već apsolvirao.

Sad, ne moraš da uzmeš moje primedbe zdravo za gotovo, ali se posavetuj sa mentorom kako nebi došao u situaciju da suviše kasno (kad odmakneš u modelovanju), prepravljaš dokumentaciju.


_{[Ovu poruku je menjao Getsbi dana 05.08.2009. u 08:03 GMT+1]}

Mislim da ne postoje razlike između poslovnih izvođača i običnih izvođača u ovom alatu koji koristim. Tako je i profesor rekao. Ipak evo postavio sam pitanje na zvaničnom forumu proizvođača ovog programa pa ću da vidim šta mi oni kažu. U ovoj knjizi po kojoj radim posebno se crtaju poslovni učesnici i obični tj. unutrašni učesnici.


To nisu učesnici to su zasebni entiteti. I oni mogu da komuniciraju na ovakvom dijagramu. Evo i primera iz knjige "UML za projektovanje baza podataka". Obrati pažnju na entitet "Clinical Records".

Ipak postoje različiti simboli. Ovo sam izvadio iz tvojih slika. Kad sam napisao Poslovni i obični izvođači, pod poslovnim-Busines Use Case sam mislio na simbol , a pod običnim-Use Case na ovaj
. I u jednom i u drugom slučaju to su:Bibliotekar, Administrator, Čitalac...., ali sa različitih aspekata posmatranja. A tako je i u tvojoj knjizi. Pogledaj stranu 19.

Primedba oko učesnika-izviđača se odnosila na plivačke staze dijagrama aktivnosti, a ne sekvencijalnih dijagrama. Sekvencijalni dijagrami treba da su takvi, kako si okačio sliku. Sekvencijalni dijagrami i dijagrami saradnje spadaju u grupu dijagrama interakcije. Dijagrami interakcije imaju jednog izvođača-učesnika i objekte sa kojima taj izvođač-učesnik interaguje.

Dakle da rezimiram moje primedbe. Prva se odnosila na neadekvatnu upotrebu simbola jer si na trećoj slici, koja predstavlja Poslovni slučaj upotrebe koristio »neposlovne« ili kako ti kažeš unutrašnje izvođače.
Druga se odnosila na dijagrame aktivnosti gde mogu da budu u zaglavlju plivačkih staza samo izvođači.





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

Sasvim si u pravu. To sam hteo da kažem da postoje poslovni i obični korisnik. Poslovni korisnik se razlikuje od običnog po tome što ima jednu kosu crtu preko kružića. Ti si u prethodnom postu prikazao uporedo ova dva simbola. Ja samo kažem da ne postoji takav simbol u ovom Enterprise Architectu koji ja koristim.
Probaću da ispravim ove nedostatke o kojima si govorio. Hvala..

Uspeo sam da ubacim poslovnog korisnika. Ne postoji simbol već je potrebno dodati običnom korisniku stereotip "business actor". To činimo na sledeći način: Napravimo običnog korisnika tako što ga prevučemo sa leve strane (Actor). Desni klik na njega pa Properties. Otvara se prozorčić sa svojstvima. Pored polja Stereotype postoji dugme sa tri tačke. Kliknemo na njega. Pojavljuje se novi prozor u kome kliknemo na dugme New i ukucamo "business actor" i kliknemo na OK. Ponovo kliknemo na OK i izaberemo u polju Stereotype vrednost "business actor" i potvrdimo na OK. Pojavljuje se "čičagliša sa kosom crtom".
Na sličan način je moguće napraviti poslovnu korisničku funkciju. Kad ispravim model javljam se.

Da li ima neko iskustva sa ovim poslovnim korisnicima. Meni nešto nije najjasnija definicija iz knjige. Da li da zamenim sve korisnike poslovnim korisnicima na ovom poslovnom modelu?

Ne , naravno. Samo tamo gde model opisuješ Top Down, iz ugla rukovodioca. Pogled na realnost se nije izmenila prelaskom sa IDEF0 na UML standard. Zahteve si i dalje prikupljao odzgo na dole intervjuišući direktora biblioteke i odozdo na gore, posmatrajući dokumenta (evidenciju izdavanja knjiga, čitalačke kartice...). Pogledaj moj post od 05.08.2009. u vezi poslovnihi sistemskih slučajeva upotrebe.

U tvom slučaju ja bih simbole za poslovne korisnike i poslovne funkcije (one sa crticom) primenio samo na onom dijagramu koga si ti nazvao "Poslovanje biblioteke". Taj paket (package) bih nazvao Bussines Use Case Model i imao bi posebne simbole sa crticama. Drugi paket koji bih nazvao recimo samo Use Case Model, imao bi posebne simbole za obične korisnike i funkcije bez crtica. U Project Browseru možeš da koristiš metodu prevlačenja (drag and drop) za prepravke, da nebi crtao sve iz početka.

Alat koji koristiš je moderan, bar ova verzija koju sam ja skinuo sa neta (EA 7.5.846 Trial 30 day). Zasnovan je na UML 2.1. Ovaj standard omogućuje razvoj za razliku od starijih UML alata koji su služili samo za grafičko-tekstualnu dokumentaciju. Ne znam koje ti je izdanje knjige ali mislim da ona pokriva period do 2003 godine i vreme UML 1.4 ili 1.5. kad je to bio samo jezik za dokumentaciju.

Ja inače češće koristim IDEF0 i IDEF1X standarde jer sam „solista“. UML je nekako više okrenut timskom radu. Nema klasične hijerahijske strukture u dokumentovanju modela, što doprinosi tome da svako može da opiše svoj deo posla i da ga nalepi kroz odgovarajući dijagram. I dalje postoji rukovodioc projekta koji prikuplja fajlove svih saradnika i konstruiše glavni model. Prednost je što niko nikog ne mora da čeka i svi mogu da čitaju tuđe delove (glavni model) jer koriste isti jezik. To doprinosi da članovi tima (rukovodioc projekta, analitičar, inženjer baze podataka, programer...) razumeju one segmente koji nisu njihova uska specijalnost.

_{[Ovu poruku je menjao Getsbi dana 08.08.2009. u 11:32 GMT+1]}

Koliko sam shvatio na dijagramu "Poslovanje biblioteke" treba da stvi poslovne učesnike. Takodje na dijagmima klasa i dijagramima sekvenci. Na drugom delu modela je potrebno ostaviti obicne učesnike a ne poslovne. Taj drugi deo modela su podsistemi. Evo pogledajte šta ono što sam prepravio. Za prva dva podsistema "Pravljenje rezervne kopije i oporavak baze podataka" i "Pretraživanje i preuzimanje kataloga" sam stavio obične učesnike. Da li sam u pravu?
Još mi treba pomoć oko preimenovanja korisničke funkcije "Unos bibliotara i ograničenja za čitaoce". Naime sad sam se setio da bi u toj korisničkoj funkciji trebalo da stoji i aktivnost unos članarine za određeni period tako da ovo ime ne odgovara novoj situaciji. Možda nešto kao "Administriranje biblioteke"? Šta mislite?
Model je u prilogu.

Verujem da nisam bio dovoljno jasan i bojim se da da su ti se pomešale informacije.

Prvo da usatnovimo da su: korisnik, učesnik, izvođač i actor sinonimi za isti pojam kako bismo se razumeli.
Drugo, tebi trebaju dve vrste pogleda na poslovanje biblioteke. I funkcije i korisnici imaju iste nazive u oba pogleda, samo se razlikuju po vrsti simbola.

Prva vrsta pogleda odozgo na dole, iz oka direktora biblioteke koji je samo rukovodioc. On poznaje poslovni proces, zna ko šta radi, ali ne baš detaljno. To i nije njegov posao. Detalje saznaješ od zaposlenih i iz dokumenata. Praviš prvi paket koji se zove 'Poslovni slučaj upotrebe’. U ovom paketu nema mnogo detaljizovanja. Pobrojiš poslovne korisnike, poslovne korisničke funkcije i napraviš „Dijagram poslovnog slučaja upotrebe“. Taj dijagram ti već imaš. Zove ti se „Poslovanje biblioteke“ stim što sve u njemu treba da je sa crticama. Recimo, da je to sve što si saznao od direktora i to je ono što si ti u IDEF0-BpWin zvao dijagram konteksta.

Druga vrsta pogleda je odozdo na gore, iz očiju zaposlenih i iz dokumentacije. Ovo je mnogo detaljnije. Od njih si više i saznao. Praviš drugi paket koji se zove „Sistemski slučajevi upotrebe“. U ovom paketu pobrojiš obične korisnike, obične korisničke funkcije i svaku funkciju opišeš dijagramima aktivnosti i dijagramima sekvenci. Ovo sve imaš manje-više ispod dela koji ti se zove „Primarne korisničke funkcije“. Ovde treba da su ti svi elementi bez crtica. Ovo dogovara dijagramima dekompozicije u IDEF0-BpWin.

Nacrtao sam ti šemu kako to treba da izgleda. U dijagramima nema elemenata. Ti popuni ostalo. Nadam se da ti je sad jasnije. Oko preimenovanja ne mogu da te savetujem, jer ti poznaješ mnogo bolje poslovni proces. To i nije veliki problem. Model ćeš stalno da nadograđuješ novim idejama.

Savet:
Nemoj da insistiraš na svemu što vidiš u alatu Entrprise Architect.

Getsbi, hajde da malo razjasnimo ovo pošto je veoma bitno da ne nastavim u pogrešnom pravcu. Naime, po uputstvima iz knjige kako sam shvatio poslovni objektni model se sastoji iz dva dela. Prvi deo je glavni dijagram poslovnih korisničkih funkcija i dijagrami aktivnosti koji opisuju svaku korisničku funkciju. Dijagrami aktivnosti treba da budu jednostavni a ne opširni. Drugi deo je dijagram klasa i odgovarajući dijagrami sekvence. Svi ovi dijagrami treba da budu jednostavni tj. da izražavaju poslovnu logiku. Ne treba ovde detaljisati uopšte. Samo da bude jasno svim projektantima da recimo čitalac dodje u biblioteku, bibliotekar ispituje da li je učlanjen ili ne, ako nije unosi ga u sistem, ako jeste pita koju knjigu hoće da iznajmi i ako je knjiga dostupna iznajmljuje je čitaocu. Znači svi ovi dijagrami spadaju u "poslovni objektni model".
Sada deo gde je potrebno krenuti sa detaljnim opisivanjem sistema su u paketu "podsistemi". Svaka korisnička funkcija postaje podsistem. Za svaki posistem imamo po jedan dijagram korisničkih funkcija. Na tom dijagramu postoji naravno nekoliko korisničkih funkcija. Na primer za podsistem "unos i ažuriranje knjiga" imamo korisničke funkcije "unos knjige", "ažuriranje knjige" i "unos pozicije knjige". Ove korisničke funkcije nisu poslovne nego obične korisničke funkcije. I korisnici koji ih koriste bi trebalo da budu obični korisnici.
Dugo sam prelistavao knjigu i ove redove što si napisao kao i model koji si okačio uz poruku i pokušavao sam da pohvatam kako ispravno postupiti. Ova knjiga mi je prilično teška za čitanje, nije sve baš jasno napisano. Takođe imam još dva primera projekta koji su radili moje kolege tako da su oni radili ovako sa posistemima ali oni nisu koristili poslovne korisnike nigde u modelu već su samo imali obične korisnike pošto do skora nisam ni ja znao da postoje poslovni korisnici u ovom Enterprise Architectu. Šta kažeš ti Getsbi na ovo?

Vidi, da ja ne ispadnem kriv i da te ne zavedem, najbolje je da to što si do sada uradio pokažeš mentoru na konsultacijama. Ono što ja znam je, da je ovaj deo koji si do sad uradio, pripada OOA (Objektno Orjentisanoj Analizi), a da dijagramai klasa koje spominješ pripadaju OOD (Objektno orjentisanom dizajnu). Klase se definišu na osnovu definisanog koncepta i dijagrama interakcije. Moj savet ti je da potražiš mentora. Na kraju, on je taj od čijeg mišljenja ti zavisi ishod ispita.

Nema šta ti da ispadaš kriv, ja samo tražim mišljenje od tebe. Problem sa mentorom je što je na odmoru tako da ne može da pregleda ovo što sam do sad odradio. Ali pošto imam dva primera odrađena gde je modelovano kao što sam napomenuo u prethodnom postu onda ću i ja tako da radim. Ako i nešto ne valja nije teško da promenim stereotip za svakog korisnika ili korisničku funkciju. Ne znam ni ja zašto se zove dijagram klasa kad tu učestvuju izvođači i entiteti ali pratim knjigu po kojoj radim. Možda je loš prevod. Meni ono više liči na dijagram saradnje. Pravi dijagram klasa dolazi tek kasnije. Tek bilo kako bilo nastavljam sa projektom. Napraviću ove podsisteme pa kad završim okačiću da vidimo šta sam uradio.
Hvala na trudu.

Da bi se umanjio rizik od promašaja u projektu, pre nego što počnemo da pravimo važno je da znamo šta hoćemo da napravimo. Zato se moraju jasno definisati zahtevi (tj. željene sposobnosti sistema). Gradimo i ispitujemo prema tim zahtevima. Oni su naš osnov za promene i naš ugovor sa poslovnim klijentima. Oni nisu samo reči na papiru. Oni su od suštinskog značaja. Naši ciljevi pri definisanju zahteva su:
1. da se utvrde okviri sistema koga treba da pravimo;
2. da se postigne precizno razumevanje željenih sposobnosti sistema;
Utvrđivanje okvira sistema često je veliki lični izazov za rukovodioca razvoja ili vođu projektnog tima. To može da bude i veliki kulturni šok za neku organizaciju. U toj ranoj fazi razvojnog životnog ciklusa, naši kupci (tj. poslovni ljudi za koje pravimo taj sistem) često su kao deca u prodavnici slatkiša. Hteli bi sve. Kao i deca, izgleda da nikad nemaju para da sve to plate. Nažalost, mi koji smo na strani razvoja često moramo da igramo ulogu strogog roditelja, koji uskraćuje slatkiše našim kupcima. Taj zadatak, ako se ne obavlja prikladno i blago, može da se plati karijerom, pa zato moramo da ispunimo i drugi cilj - precizno razumevanje željenih sposobnosti sistema. To zaista obezbeđuje osnovu za postizanje prvog cilja - utvrđivanja okvira sistema.

Model korisničkih funkcija
Glavna tvorevina koja proizilazi iz definisanja zahteva jeste model korisničkih funkcija sistema. Ali, zar nismo već razvili model korisničkih funkcija kada smo modelovali poslovni sistem? Jesmo, ali model korisničkih funkcija koji treba sada da razvijemo je model podsistema koga će koristiti radnici u sistemu i poslovni izvođači u svojim svojim specifičnim poslovnim funkcijama.
Izobilje elemenata modela otkrivenih tokom modelovanja poslovnog sistema mora da se prenese u model korisničkih funkcija podsistema. Prvi korak u tom procesu može da bude sasvim neposredan, jer mnogi elementi iz poslovnog sistema direktno ulaze u model korisničkih funkcija. Na primer, u dabeli ispod navedene su neke mogućnosti transformacije, koje se preporučuju u okviru Rational Unified Process.


U poslovnom modelu U modelu korisničnih funkcija

Poslovne korisničke funkcije postaju Podsistemi
Poslovni izvođači postaju Izvođači
Radnici u sistemu postaju Izvođači ili korisničke funkcije
Aktivnosti radnika u sistemu postaju Korisničke funkcije

Kada se obave početna prevođenja, poslovni ljudi imaju veoma važnu ulogu u overavanju i razradi.
Jedno upozorenje: potrebno je biti veoma obazriv pri razvoju modela korisničkih funkcija. Ako u svom modelovanju koristimo stereotipe "extends" ili "includes", potrebno je izbegnuti ulaženje u funkcionalnu dekompoziciju. Korisničke funkcije se ne sastoje od većeg broja korisničkih funkcija nižeg nivoa. Poslovna korisnička funkcija može da bude bude "realizovana" pomoću brojnih podsistemskih korisničkih funkcija, ali se ona ne dekomponuje na te podsistemske korisničke funkcije, niti se te podsistemske korisničke funkcije dekomponuju na manje korisničke funkcije. Potrebno je imati na umu da svaka korisnička funkcija prestvavlja kompletan tok događaja koji za izvođača proizvodi neki vredan rezultat. Ako dekomponujemo korisničku funkciju, razbićemo njenu "kompletnost". Na primer, ako kod automatske blagajničke mašine imamo korisničku funkciju Preuzmi Gotovinu, ta korisnička funkcija se ne dekomponuje na korisničke funkcije kao što su Ubaci Karticu, Unesi PIN, Izaberi Račun i slične. Nijedna od ovih funkcija nije pojedinačno kompletan tok niti pojedinačno obezbeđuje vrednost za izvođača.

Evo i primera nekih od dijagrama.






Dijagram podsistema:



Evo i nekoliko dijagrama korisničkih funkcija podsitema.

















Evo i prikaza korisnika podsistema:




Za svaku korisničku funkciju je izrađen dijagram aktivnosti, kao i dijagram analize i sekvenci.








Svaka korisnička funkcija u podsistemu trebalo bi da ima sopstveni opis korisničke funkcije. Deo tog opisa je i scenario. Potrebno je imati makar jedan scenario tj. osnovni tok. Takođe moguće je uneti više scenarija tj. alternativnih tokova.




U prilogu se nalazi i model pa pogledajte. Sledeća faza je izrada dijagrama klasa. Iz dijagrama klasa proističe dijagram baze podataka sa tabelama. Pošto ja već imam veći deo modela odrađen ovaj deo posla neće mi oduzimati puno vremena. Kao što sam na početku rekao imam model u BPwinu i ERwinu ali je sadašnji model proširen tako da ču morati da ubacujem nove klase odnosno tabele.

<sub>[Ovu poruku je menjao biske86 dana 20.08.2009. u 22:46 GMT+1]


[Ovu poruku je menjao biske86 dana 20.08.2009. u 22:57 GMT+1]</sub>

Evo i projekta.

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.