den laver klasse diagrammet for dig, så højre klikker du på den metode som du vil se et sekvens diagram for og den spørger dig hvilke pakker du vil tage med i sekvens diagrammet... og så laver den det... og så kan together en masse andre nice ting, helt sikkert det bedste der uml værtkøj der findes.. men meget dyrt.
rational rose kan genere klasse diagram fra kode, den kan foreslå dig metoderne når du laver sekvens diagrammet, men ikke lave det selv. men den kan lave colloaborations diagram fra sekvens og omvendt.
jeg har selv altid været ret glad for at udforske programmer som kan klare opgaver for mig.. og jeg er selv mega dårlig til at lave sekvens diagrammer.. så mit råd vil være at du laver dem selv.. så kan du altid generere senere og sammenligne. Det kunne jo være at dit eget sekvens diagram var rigtigt og din kode var forkert ;)
ja det spørger jeg også mig selv om nogen gange ;D men det kommer nok med tiden? i starten skal du vel lave det hele for at lære, senere vil jeg tro at du til kan lave efter behov.. altså de diagrammer du mener du får noget ud af. Til rigtigt store projektet vil det helt sikkert hjælpe med at give et overblik, og gøre det nemmere at sætte nye personer ind i systemet, eller efter noget tid hvis man selv har glemt det.
Det eneste sted jeg selv har fundet det rigtigt hjælpsomt er når der har været noget kompilceret logik hvor et statechart eller aktivitets diagram har gjordt det nemmere at diskutere problemet uden at tale forbi hinanden... og så lige et klasse diagram til at have overblikket.
jeg har aldrig været ude i den rigtigte verden og se det i brug, måske arne ved mere om det :)
Diagrammer er ofte meget bedre end tekst til at give overblikket.
UML er en standard for diagrammer som alle bør kunne forstå.
UML diagrammer bruges faktisk ude i den virkelige verden (omend nok ikke altid i samme omfang som det anbefales i fine bøger).
Og et sequence diagram er efter min mening særdeles godt til at beskrive high level logik (og jeg bruger dem en del).
Men det er også grunden til at jeg ikke tror på auto genererede sequence diagrams. Jeg vil ikke se hver eneste kald - jeg vil kun se det væsentlige. Og det generer ikke mig at lave en enkelt call pil med teksten "multiple calls to X" fordi jeg bruger dem til overblik ikke til at generere kode fra.
jep det er netop problemet med de autogenererede sekvensdiagrammer, den tager simpelthen alt med, så skal du selv sidde og finde ud af hvad der er væsenligt.
Fujaba er rigtigt godt. Jeg har selv lige downloadet det for et par dage siden, så jeg ved ikke helt hvad det kan endnu. Men den kan ihvertfald lave uml klasse diagrammer ud fra en java kode.
men ud over at together kan lave diagramemr, ser jeg den som et ret godt læremiddel. Den kan f.eks checke din kode efter for god kode skik, og om der er steder som ikke ser særligt objektorienterede ud efter nogen regler og point den tildeler. Så er det hurtigt og se om der måske er noget galt et sted.
Angående UML diagrammer, og hvad de kan bruges til:
Jeg læser selv til ingeniør inden for it, og jeg kan slet ikke forestille mig at lave et system, hvor man ikke modelere det først ved hjælp af UML og andet.
Det gør det nemmere at sætte sig ind i, for en der skal arbejde videre på din kode. Er man flere om et projekt, giver det også et overblik over, hvad de forskellige dele af det system man laver skal kunne.
Personligt deler jeg Arnes skepsis mht. autogenererede sekevnsdiagrammer. Jeg synes desuden en vigtig pointe i den forbindelse er at UML ikke er skabt til "reverse" engineering, men primært den anden vej. Reverse kan derimod være et godt middel til at opdatere sine dokumenter efterfølgende, men bør bestemt aldrig laves efter et projekt er kodet som led i dokumentationen til en rapport.
Jeg ser UML som et meget godt værktøj på et mere conceptuelt plan i designfasen (herudover er det naturligt genialt i analysefasen på en helt anden måde). Det vil sige at man bruger det til at fastlægge de mere overordnede designs man vil anvende i sit system, og bruger det som en slags guide til at bestemme hvad retning koden skal gå i. Måske laver man nogle generelle sekvensdiagrammer og statecharts osv. Her mener jeg så man bør stoppe med fokus på UML. Man har alligevel ikke overblik til at forudse alle metodekald osv inden man kommer igang med selve implementationen.. Hvis man så løbende har brug for nogle mere konkrete diagrammer til at genskabe overblikket er det fint.. Det med bagefter at skabe diagrammer der går helt ned i detaljer med hvad alle metodekald osv går tror jeg heller ikke bliver brugt ret meget i det virkelige liv..
Hvis ens kode iøvrigt er velstruktureret og objektorienteret er det andre har brug for typisk et overblik over det interface man tilbyder, hvilket javadoc er helt genialt til hvis man tager sig tiden.. (hvilket med diverse IDE's som Eclipse og IntelliJ ikke tager mange sekunder)
Man bruger UML mange steder. Men absolut ikke alle steder.
Citat fra en tråd på Computer Worlds debat forum:
<citat start>
Det er sælger John som kommer hjem til firmaet og har solgt jeres system, med mulige features som du aldrig har hørt om før, og det skal leveres om 14 dage, og der er ikke nogen kravspecifikation!
Det er virkeligheden. Der ER IKKE NOGEN Kravspecifikation, GLEM DET! Der er heller IKKE NOGEN ANALYSE, GLEM DET! OBJECT DOMAIN ANALYSE? HVAD snakker du om? Det er Code-Like-Hell som praktiseres ude i virkeligheden, hvorfor tror i at systemudviklere brænder sammen som 35 årige - fordi de et ustyrligt pres liggende på sig, et pres placeret af amatører som leger edb folk!
Det er den virkelig som alle nyuddannede kommer ud til. Ikke alt teoretiske geil som ingen får lov til at lave alligevel.
Ups, der var da lige et spm jeg har glemt at lukke her
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
Ny bruger
Nybegynder
Opret
Preview
