UML es open source

A tema egyreszt erdekes masreszt duhito. Erdekes, mert egy csomo olyan kerdest felvet, ami a nyilt es zart forraskodu szoftverfejlesztes modszertani kulonbsegeihez elvezethet. Legalabbis ezt a tezist lehet amoge az egyszeru teny moge felepiteni, hogy nincs egy normalis open source UML tool. Ami pedig rettenetesen duhito. (Ugye nem baj, ha az irjal jobbat duma most nem erdekel.)

Az a megfigyelesem (lehet, hogy teves), hogy a bazar tipusu open source fejlesztesi modellnek nem igazan van szuksege tervezoeszkozre, sot bizonyos mas szoftverfejlesztesi eszkozokre sem. (Hogy miert, azt itt most nem reszleteznem.) Valoszinuleg ennek koszonheto a relativ elmaradottsag a tervezoseszkozok teren, mikozben elvileg az open source legfontosabb motivacioja, hogy szoftverfejlesztok onmaguk szamara fejlesztenek.

Ergo tele vagyunk editorokkal, make programokkal, es millio egyeb apro eszkozzel, amik a szoftverfejlesztest szolgaljak. Ugyanakkor komplexebb eszkozokbol hiany van. Kis tulzassal: van 1 db fordito, van 1 db debugger, statikus kodelemzokben sem bovelkedunk, de erdekes modon az integralt fejlesztoeszkozok is meglehetosen nehezen jutottak el a hasznalhatosag szintjere. (Nem akarok nagyon elkanyarodni a tematol, de evekig probalgattam a KDevelopt, az Anjutat, az Eclipset, de valahogy nem tudtam egyiket sem megszeretni. Jo, hogy vegre itt a Codeblocks, ami mar kezd olyan lenni, ami nekem kezreall. Persze egyetlen olyan sincs meg - kiveve a fizetos viPlugint Eclipsehez -, ami pl. integralna vim-et, ami pedig ugye letszukseglet ;-)) Erdekes lenne meg kiterni a fejlesztesi dokumentacio kerdesere az open source projektekben, de most maradjunk annyiban, hogy aki probalt mar bekapcsolodni open source projektbe, az tudja, hogy mire gondolok. ;-)

Na es akkor eljutottunk a mai nyavajgas targyahoz az UML eszkozokhoz. En ugyanis szeretnek ilyet hasznalni. Sot almom a round-trip engineering. De azert ennel egyszerubb feladatokon is elbukik a nagy tobbseg. Nezzunk meg nehanyat (a rajzoloprogramok itt nem fociznak):

Umbrello: evek ota maszirozzak, de meg nem volt olyan verzio, ami valahol ne szallt vola el, vagy ne produkalt volna idegtepo hibajelensegeket. A bugzillaban erdemes a "crash"-re rakeresni. Hat hogy lehet az, hogy elvileg programtervezessel foglalkozo emberek ilyen gyalazatos crash-halmazt tudnak csak kihozni. Most eppen ott tartunk, hogy az ujabb verzio szimplan a regebbi verzioval keszitett allomany megnyitasakor nemes egyszeruseggel elszall. Siralmas.

ArgoUML: velemenyem szerint jelenleg a legjobb UML eszkoz, ket apro hibaval: Java alpau eroforrastemeto, es sajnos csak az 1.4-es szabvanyt tamogatja.

BOUML: probalgatom, probalgatom, de valahogy furcsa. Nem all kezre, es nem igazan merek bele idot fektetni. Bar folyamatosan fejlesztik, valahogy a fejlesztes menete kevesse kovetheto, mert eddig meg nem nagyon sikerult a fo fejlesztonek egy kerek angol mondatot osszehoznia. (Ld. changelog, ja bocs nala historic)

FUJABA: erdekes projekt a round-trip engineering igeretevel, de csak Javahoz. Kar.

VisualParadigm: hat o ugyan nem open source, de az egyetlen tool, aminek meg van ingyenes verzioja. Az eszkoz tenyleg profi, csak hat az ingyenes verzio megkotesei nem tul elonyosek, na es hat szinten Javas eroforrastemeto.

Tudom, hogy van szamtalan eszkoz meg ezeken kivul, de ezekkel jutottam el a kiprobalas szintjeig. De a teljeserteku hasznalhatosagot sajnos egyik sem hozta, szemben pl. a munkahelyemen hasznalt 200$-os (de sajnos win only) EnterpriseArchitect-tel.

Altalanos tapasztalat meg, hogy az XMI (szabvany? hahaha) ellenere eselytelen egyik eszkozzel keszitett modellt egy masik eszkozbe importalni. Szoval valodi kiprobalashoz heteket kene dolgozni mindegyik eszkozzel. Na hat erre jellemzoen nincs ido. A masik, hogy a Javahoz szabott eszkozokbol lenyegesen nagyobb a valasztek, de engem ezek jelenleg hidegen hagynak, mert nem Javaban fejlesztek.

Hozzászólások

dia kicsit fapados, es meg csak most probalom en is elsajatitani az UML alapjait, mondj mar rola valami velemenyt legyszi ;)

asd

Dia az nem igazan case tool, hanem rajzoloprogram, ami tud UML diagramokat. Ha nem akarod, hogy a modell kapcsolatban legyen a koddal, akkor egy rajzoloprogram is alkalmas lehet, de:
1. a karbantartas folyamatos kinlodas, hiszen, amit valtoztatsz a modellben, nem lesz meg a kodban, es forditva (ez a problema sajnos bizonyos szinten a legtobb case toolnal is fennall, hiszen a teljes asszociativitast csak a round-trip engineering hoz)
2. rajzoloprogram eseten viszont meg a modellen belul sincs integritas, tehat ha egyszer definialtal pl. egy osztalyt a statikus modellezes soran, az nem fog megjelenni mondjuk egy sequence diagramban a dinamikus modellezesnel. Ezzel az a problema, hogy az osszes "modellelemet" (rajzolasnal nem beszelhetunk valodi modellezesrol) neked kell kezzel karbantartani. Pl. megvaltozik az osztaly neve, vagy egy fuggveny neve, es az osszes helyen javithatod ki kezzel.

Nekem az sem vilagos, hogy ha azt mondod, hogy irsz egy postfix kaliberu smtp szervert, akkor mi a buvalbelelt banatra tudnad hasznalni hozza az uml-t. Gyozzon mar meg valaki, hogy mindenkeppen meg kell baratkoznom vele, mert akkor jobb lesz az eletem...

ASK Me No Questions, I'll Tell You No Lies

Nagyjabol ugyanarra, mint barmelyik szoftvernel. Szabvanyos modellezo nyelv, magasabb szinten, mint mga a kod. Egyszeruen mas nezeteid vannak a szoftverrol, ad egy csomo attekintest, vegiggondolasi lehetoseget. Ha persze a folyamatot onnan nezzuk, hogy celszeru lenne elobb elkesziteni a modellt, akkor az emebr nem az implementacio soran "tervez" on-the-fly, hanem elore. Rengeteg munkat es folosleges refaktoralast lehet vele megsporolni. (Na meg persze teves ahsznalat eseten eloidezni. ;-))

En szivesen megforditanam a kerdest: te hogyan allsz neki egy szoftverfejlesztesi munkanak?

Ez kisebb feladatoknal tenyleg hatekony, de azert nagyobb projekteknel elegge elcsuszhat a dolog. A scrum (ha modszerre gondolsz) pedig eddig meg nem aratott osztatlan sikert a fejlesztok koreben. Intenziv es automatizalt modulteszt kotelezo (ami nem rossz, de pont ebben a tipusu processzben nincs ra igazan ido/lehetoseg), es nagyon gyakran ganyolasra kenyszerit. A fejlesztok idegesek, es nem elvezik az alkotot munkat. Leglabbis nekem eddig ezek a tpasztalatok jottek le. A folyamatos refaktoralas vegulis jellemzo az open source-ra is, de szerintem az osszes iterativ (es be kell, hogy valjuk, hogy a nem iterativ ;-)) fejlesztesi modszerre, szoval ezt nem mondanam feltetlenul hatranynak.

Azert kivancsi lennek pozitiv peldakra is a scrum-ot illetoen.

Nekem a Netbeans UML kiegészítése tetszett (igaz, nagyon ritkán használom, papír&ceruza rulz :) )

Andi, really. Take it from me. If I tell you something, I'm usually right.

Az általad linkelt oldalon szerepel, bár az ott linkelt oldal halott:

JUDE

Esetleg próbáld ki. A community edition ingyenes.