Jo a jeste - nepouzivejte UML, jen to zdrzuje. Pokud je neco tak slozite, ze to neudrzite v hlave, tak je to bud blbe navrzene (a chce to dekompozici a zjednoduseni), nebo pouzivate technologii, kde neni mozne na prvni pohled poznat, co ma vlastne trida za atributy. Coz je typicky vyvoj web aplikaci v Jave s temi jejich frameworky (pro pobaveni si prectete treba dokumentaci ke Springu). Konkretne v Rails zadne UML nepotrebujete. Klienti nechteji UML, klienti chteji funkcni aplikaci, at klidne poslou seznam atributu mailem nebo formular v excelu. Programatori taky UML nepotrebuji, protoze jen zdrzuje od prace, kdyz se ma pri sebemensi zmene sahat do vice mist. Stejne pak ty diagramy nejsou aktualni vzhledem k projektu. Samozrejme, ze ve vyvoji SW se najde vzdy hafo vohnoutu, kteri vykazuji praci jako 'aktualizace diagramu', ale tech je dobre zbavit se hned na zacatku. Kdokoli ve vyvoji SW nepise kod, neni treba (krome klienta). Ovsem kdyz si nekdo preje vymenit vice papiru za mene funkcionality, tak prosim.
Jirka Hradil 2011/5/23 Libor Jelinek <[email protected]>: > Dobrý den! > Chtěl bych trochu "společně" zauvažovat nad tématem z předmětu. V každém > projektu se vyskytují nějaké objekty. V první části mapujeme většinou pomocí > UML tzv. business objekty (faktura, zboží, osoba apod.). > > Tyto objektové třídy a vztahy poté mapujeme ručně nebo knihovnami jako JPA > na databázové tabulky. V méně případech mapovat nemusíme, protože používáme > objektové databáze (Bože, děkuji ti za ně :-)). > > V prezentační vrstvě (ať webové či swingové) máme nějaké formuláře nebo > obecně GUI, které business objekty zobrazují, umožňuje vytvářet, editovat a > rušit (zkrátka CRUD operace). > > Naprosto běžné jsou nějaké omezení na vlastnosti objektů - IČ firmy nesmí > být text, RČ nesmí být prázdné, email musí obsahovat znak zavináč atd. atd. > Ač jsou tyto ověření stejné pro jakoukoli vrstvu aplikace, tak se v každé až > příliš často duplikují (v databázi jako SQL constrains, v aplikační vrstvě > kódem v Javě, v prezentační v JavaScriptu). > > Všechny vrstvy tak nějak opakují totéž. Sice se všechny techniky a > frameworky stačí, aby to tak nebylo, ale i tak.... Když se při testech > zjistí, že je možné zadat jako narození datum v budoucnu, pak se obvykle > přesto musí sáhnout do kódu databáze, Java classů a i podpůrných validací ve > webové vrstvě (když nemáme framework, tak zvlášť v webové server-side i > client-side v JavaScriptu). > > Je nedostižným snem, aby se při takové situaci skutečně změnilo jen jediné > místo (jedno XML, anotace tříd, cokoli)? Chci se Vás proto zeptat, jak k > tomu přistupujete Vy, aby jste z jediného místa: > > - vygenerovat/změnit DB s příslušnými constrains (not null, délky varcharů > apod.) > - když ještě budu u DB, tak aby by technologie dokázala provádět jen delta > změny v DB (tj. nevymazala tabulku a data, ale jen přidala/odebrala sloupce) > - vygenerovali/změnit Java classy > - vygenerovat/změnit formuláře vč. kódu k validování vstupu uživatele > > Důraz kladu na nejen vygenerování, ale zejm. následné změny. > > Jako nejbližší tomuto ideálu se mi zdá následující kombinací technologií > (podotýkám, že mám jen teoretické zkušenosti) > - mít model jako obyčejné POJO Java classy > - olepit je JPA anotace entit, které vygenerují DB > - do getterů/setter přidat business logiku (pravidla) > - přidat ještě k fieldům/properties anotace z javax.validation (JavaBeans > Validations) pro ověřovací pravidla. > > Jedinou definicí modelu by byly Java classy ze kterých by se vygenerovali > databázové tabulky. Když je webovová vrstva v JSF, tak JSF umí využít > JavaBeans Validations takéž. Když by byla prezentační vrstva Swing, tak by > asi bylo třeba něco dopsat. > > Ještě jako varianta mě napadá mít jako definici modelu pomocí XML schémat, > ale by mi připadalo jako příliš komplikované (à la EJB) oproti modelu s > POJO. > > Chtěl bych se zeptat těch, kteří se něčím takovým již potýkali/řešeli, zda > zmíněné technologie (nebo obdobné), považujete za vhodné (zda cesta s JPA a > JavaBeans Validation je ta správná). Jestli se můžete dělit se svými > zkušenostmi... > > Díky předem za všechny příspěvky. > > Libor >
