Citat:
Nije ni jezik, jezik ima nekakvu sintaksu i pravila. UML je gomila simbola kojim se pokusava opisati sve sto se moze zamisliti. Godinama sam crtao dijagrame toka, flowcharts, dok nije doao UML da mi kaze da su to u stvari Activity diagramas. Onda sam crtao sheme implementacije sistema, ono Serevr u sredini, na njemu baza a na to se kace radne stanice. Onda je doao UML i kazao mi da je to implementation dijagram. Isto tako sam crtao dijagrame procesa, 'sta ko radi', a onda mi je UML rekao da se to zove 'swimline diagrams'. To sve nema veze, zovi ga kako hoces, ako vrsi posao. To je klasican trik u maniru Microsofta - ja ti prodam toplu vodu kao najnovije dostignuce.
U načelu, slažem se s tobom - u delu koji sam ja koristila, UML se nije pokazao kao nešto revolucionarno. I ako ne koristim UML dijagram klasa, koristiću Chen-ovu notaciju MOV-a - jaka stvar.
Međutim, ne bih išla dotle da UML nema sintaksu. Recimo, u dijagramu slučajeva korišćenja zna se da postoje slučajevi korišćenja, akteri i veze (dijagram s.k. je graf sa 2 tipa čvorova - akter i slučaj korišćenja). Postoje 4 tipa veza. Između aktera i s.k. moguća je jedino veza asocijacije. Između 2 aktera nije moguća direktna veza, osim u slučaju postojanja apstraktnog aktera, gde je moguća jedino veza generalizacije. Između 2 konkretna (nasuprot apstraktnim) s.k. takođe nije moguća veza asocijacije, dok su veza generalizacije, <<include>> i <<extends>> veza moguće kada se radi o vezi sa apstraktnim s.k. (apstraktni s.k. nema konkretno pojavljivanje, tj. nikada neće biti u direktnoj vezi sa akterom). Eto, ja bih to nazvala nekim sintaksnim pravilima.
Druga je stvar što UML 2.0 ima 13 delimično (ne)povezanih dijagrama. Kažem tako, jer svaki ima sopstveni skup pravila i mogu se praviti jedan nezavisno od drugog, a sa druge strane određeni simboli im se preklapaju. I nekako pretpostavljam da im to, između ostalog, zameraš...?
E, sad, ako si sumnjičav prema toj priči o MOF, MDA i UML-u kao platformski nezavisnoj osnovi, trenutno se ne bih usudila da o tome diskutujem, pošto mi još uvek predstavlja popriličnu nepoznanicu. :)
Citat:
Ovo ne pricam napamet. Imam gomilu knjiga iz UML-a, vecinu sam procitao, uzimao kurseve, kopao levo i desno, nadajuci se da ce mi 'jezik' UML olaksati zivot. Nije se desilo. UML nigde ne objasnjava odakle da pocnem i u kom pravcu da idem. Recimo, pocni nalizu sistema crtajuci Use Case dijagram. Onda sa Use case predji na recimo Class dijagram. E tu je kvaka. Sve i da mi kaze polse Use CAse dolazi Class dijagram, ne kaze mi kako se USe Case mapira u klase. Sta je to na Use Case sto ce postati klasa?
Ja i kažem da UML to ne objašnjava. Zato je jezik za modelovanje ovoga i onoga, a ne metodologija. Mislim da je metodologija ta koja treba da da odgovor odakle se polazi, kamo se ide i šta se koristi. Ako neko hoće da definiše sopstvenu metodologiju koja će u svakoj fazi razvoja IS-a da koristi UML, slobodno. Međutim, ako neko hoće da koristi UML samo za, npr., sekvencni dijagram, ili opet hoće totalno da ga zaobiđe u širokom luku, opet ok. Neko će da krene od SSA, preko normalizacije strukture dokumenata (skladišta i tokova) do relacionog modela. Neko ide od slučajeva korišćenja, preko dijagrama sekvenci, sistemskih operacija do konceptualnog modela predstavljenog dijagramom klasa (boga pitaj kako :)) i sl. Neko će izabrati neku varijantu brzog razvoja, pa će ceo proces izgledati malo drugačije. Programiranje je, da tako kažem, egzaktna stvar; razvoj IS-a - teško. Sve zavisi od potreba i uslova za razvoj, i to negde i sam OMG kaže.
A kako se prelazi sa jednog modela na drugi, sa dinamike na strukturu i sl. meni i dan danas nije najjasnije, nevezano za to da li koristim UML. Sve i da treba da strukturu sistema predstavim preko MOV, isto bi bilo. Jedan moj profesor, recimo, kaže da podvučemo imenice u (verbalno opisanom) scenariju S.K, te da su to kandidati za klase/entitete. Međutim, iz samog verbalnog opisa, teško da se išta može zaključiti o međusobnim odnosima tih entiteta, a isto tako i o njihovoj strukturi (jer se u opisu ne ide toliko detaljno da bi se navodila sva pojedinačna polja svake buduće klase). Za mene, to je ogroman skok - kao, ne znamo mnogo o sistemu, vršimo grubu specifikaciju, a onda nam ona služi za dobijanje gomile drugih informacija čija je veza sa ovim prvim jako slaba. Ali, opet, kapiram, identifikacija strukture je negde prećutno učinjena, iako nigde ne postoji kao zasebna faza. I zbog ovakve stvari nisam pristalica ovog pristupa... ali ne krivim UML, jer, ma koliko bio zastupljen u ovakvom pristupu, jednostavno smatram da to nije njegova odgovornost.
Citat:
Nadam se da ću konkretnim primerom demantovati Zidara da je UML teško primenjiv kod baza podata. Imam primedbu na Zidarevo izlaganje gde kaže da se kod UML-a ne zna početak i kraj. Naravno da se zna, počinje se od zahteva. Takođe ti kažeš da si posle dijagrama korisničnih funkcija krenuo na dijagram klasa što je pogrešno jer svaku korisničku funkciju razrađuješ dijagramima aktivnosti i sekvenci.
Svejedno, možeš ubaciti i dijagram komunikacije, i prelaza stanja, ali i dalje ostaje pitanje - kako iz dijagrama aktivnosti (ili bilo kog dijagrama kojim predstavljaš ponašanje) izvlačiš strukturu za dijagram klasa?
A, inače, to što ti koristiš vrlo je verovatno da se zove Unified Software Development Process ili predstavlja modifikaciju istog. I to nije tvorevina OMG-a, niti deo UML-a, već ljudi koji su razvili ovaj pristup i upetljali UML, ni kriv ni dužan, u celu priču. :) Iako nerado, citiraću:
Citat:
A methodology formally defines the process that you use to gather requirements, analyze them, and design an application that meets them in every way. There are many methodologies, each differing in some way or ways from the others. There are many reasons why one methodology may be better than another for your particular project: For example, some are better suited for large enterprise applications while others are built to design small embedded or safety-critical systems. On another axis, some methods better support large numbers of architects and designers working on the same project, while others work better when used by one person or a small group.
OMG, as a vendor-neutral organization, does not have an opinion about any methodology.
Citat:
hm, kako je moguce praviti dijagram sekvenci ako pre toga nije napravljen dijagram klasa? mozda sam pomesao dijagrame, ko zna
Momo, nemoj da nas brukaš. :) Pouzdano znam da si, ako si išao tačno po skripti iz ProPro, morao prvo raditi sistemske dijagrame sekvenci, ugovore, pa konceptualni model u UML-u. ;)