UML till kod

Hepp

Sitter med Telelogic Tau G2 och försöker få till (java) kodgeneringen från UML (use-cases, klassdiagram e.t.c). Har hitills fått till det så att det blir skelett på varje klass och dess metoder, men Tau ska klara att ge komplett kod och det vore förträffligt om jag kunde få även det. Det finns visserligen en möjlighet att ange "body" i textfiler, men det är ju inte direkt "automatisk kodgenerering". Försöker nu via sekvensdiagram få till det, men lyckas inget vidare. Sökningar på nätet ger NADA (om man bortser från diverse presentationer om hur förträffligt Tau ska vara).. :OO

Guide me :)

Ja du !
Vi är nog flera av som lyssnat på alla sagor om UML .
UML är och förblir bra som medel att kommunicera mellan flera deltagare i ett projekt.
Och jag tror att vi kan gå i mål snart (Har nog trott det i 10-15 års tid nu.
Tyvärr har jag inte personlig erfarenhet Tau men jag kan kolla upp det närmare.
Varje metod och program har sina fördelar. Ett steg på vägen.

Jovisst. Jag har jobbat med flera olika verktyg tidigare, men inget av dem har tidigare deklarerat att de klarar att generera komplett och kompilerbar kod. Man kan tydligen gå en 2-dagars kurs för 1100 EUR i hur man gör det, men det är föga intressant för en fattig student som bara använder programmet till design i ett större software engineering projekt på högskolan och nu vill ta del av alla features eftersom det blir en hel del klasser i den del av projektet som jag och min kollega pular med. Ska det gå att generera komplett kod vore det själva f:n om inte vi skulle kunna det också (utan att betala 1100 EUR för en kunskap) ;)

PeW skrev:

Jovisst. Jag har jobbat med flera olika verktyg tidigare, men inget av dem har tidigare deklarerat att de klarar att generera komplett och kompilerbar kod.

Nej, ett skelett, som du har lyckats fixa, brukar de klara av. Hur skulle de kunna göra mer än så? Det borde ju förutsätta att du på något vis kan lägga in själva algoritmerna i UML-diagrammet. Men då har du ju snarare en hel utvecklingsmiljö, än ett UML-verktyg.

Hur skulle de kunna göra mer än så?

Utifrån kombinationen av genom klassdiagrammet, väl definerade klasser och state charts eller sequence diagram. Det är ingen omöjlighet, problemet ligger mer i hur stort kodgenerations-programmet får vara med avseende på komplexitet (inbyggd AI m.m).

Tau har kodgenerering, kompilering och exekverering i menyn, bland mycket annat. Och som sagt, det är det enda programmet hitills som jag stött på som skrutit med att det ska klara av hela ledet. Dessvärre är informationen om det hur bristfällig som helst och programmet är i övrigt halvjobbigt att använda.. men det som vi har att tillgå i skolan (för UML-design).. Rational Rose är trevligare, men ska man följa kursens direktivt så... Nåja. Jag tänker inte lägga ned mer tid på att få programmet att fungera som det är utlovat än vad det tar att manuellt knacka koden (vi har trots allt en deadline) Men det hade varit intressant med lite input om från någon med erfarenhet från det (Enligt vad jag förstått så används det på exempelvis Ericsson).

redigering:
Förtydligan för att förhindra tvetydighet

Borland har ett UML verktyg för .Net som heter ECO II.
Du hittar mer information om ECO på Borlands hemsida

Jag kan förstå att det är intressant att kontrollera om de håller vad de lovar. Men samtidigt så förstår jag inte vitsen med ett UML-verktyg som ska klara alla leden. Som Lasp så riktigt kommenterade:

UML är och förblir bra som medel att kommunicera mellan flera deltagare i ett projekt.

Är man då beoende av att få färdigkompilerad kod så är inte frågan om man kan UML-vektyget tillräckligt väl utan om det finns de kunskaper om programmering inom projektet som behövs för att kunna genomföra det.

Jag har använt Borland Together för liknande projekt och det har fungerat ganska bra. Där gick det att generera rätt mycket kod från sekvensdiagrammen (den skapade klasser, metod-stubs, instansvariabler etc) men den gick inte alltid att kompilera rakt av. Tyvärr har jag ingen erfarenhet av Tau...

Till missModesty: Varför är det en nackdel om man kan generera kod från de diagram man ritat? Jag tycker att UML bäst kommer till sin rätt då koden är modellen. Att rita UML-diagram är ju trevligt men det är först när koden verkligen implementerar det som man ritat de är något att ha. Generar man då koden med samma verktyg som man ritar med och diagrammen skapas utifrån koden så kan verkligen utnyttja den fina modell man ritat.

Nu menade jag inte att "kasta ut babyn med badvattnet" som man brukar säga. Jag motsäger mig inte till att man får stöd genom att verktyget genererar viss kod. Det kan både vara bra som garanti för att modellen efterföljs och tidssparande. Vad jag ifrågasatte var hur stor del av kodandet som ska läggas på själva verktyget.

Kul med lite diskussion :)

Får väl tillägga att varken jag eller min kollega är nybörjare på att koda i Java så det är inget problem - egentligen. Vi har tidigare även använt en drös med andra UML-verktyg i andra kurser så vana vid det finns också. Men nu var vi mer eller mindre låsta vid Tau eftersom det är det UML-verktyget som är från iår installerat i skolan. I det projekt vi arbetar med så är hela software-engineering stegen med så därför, tillsammans med ett verktyg som utlovar att den kan generera komplett kod, vore det en elegant och intressant lösning att få till detta. Nu har vi dock skippat den grejen eftersom tiden rinner iväg och vi ägnar oss just nu åt att manuellt bygga på de skelett som Tau spottar fram :)

Intressant tråd.

Jag har inte suttit med Tau, men jag har jobbat en del med att gå från modell till färdig kod. Det vi använde oss då var en implementation av MDA konceptet. MDA står för model driven architecture och går ut på att använda sig av "körbara" modeller (även om det finns en hel del andra definitioner av hur och vad MDA är). OMG har en del information och länkar om det på sin sida, http://www.omg.org
Den implementation av MDA vi använde oss av var xUML (Executable UML) och verktyget vi använde var BridgePoint. Det går i princip inte att komma ifrån att man på någon nivå måste skriva själva business logiken, och i det här fallet använder man sig av ACL som är ett slags högnivåspråk som är ganska likt SQL i sin syntax (jo faktiskt).
Har för mig att de som tillverkar BridgePoint blev uppköpta för nåt år sen, men här är en länk till en svensk sida iallafall som beskriver verktyget en del och vad man kan ha det till.
En del intressanta grejer med verktyget är att man kan testexekvera sina projekt redan innan man har genererat "riktigt" kod, dvs kod som tex Java, C, C++ eller vad man nu har för modellkompilator.

http://www.nrt.se/nrt/umltools.htm

Lite böcker om man är intresserad:
* MDA distilled
* Executable UML - A Foundation for Model-Driven Architectur

Och jo faktiskt konceptet fungerar, vi lyckades skapa ett system helt genom att använda oss av MDA/xUML och dess modeller och statemaskiner. Kunde testköra/debugga systemet utan att generera kod, och slutligen generera källkod som var klar för kompilering.
Jag kan tänka mig att det kommer att bli större med tiden, har redan under det senaste året gått framåt på en del fronter men det har en ganska bra bit kvar innan det kommer i närheten av att ersätta utvecklingsmetoder som används idag.

Meningen med ett bra UML verktyg är ju att man på sikt skall kunna skapa en itterativ process där man kan gå in och ändra var som helst, i koden eller i beskrivningen och få ett genomslag.
Vi skall inte heller undervärdera funktionen att köra rekursivt dvs att ta en befintlig kod för att få en modell som man kan förbättra.
Idag vet vi väl att man inte kan skapa en bra grej direkt från början.
Så oavsett vad jag skrev i inledningen tror jag på fortsatt modelering och beskrivning av våra projekt.