Uml Diagram
Uml DiagramUML diagrams are great. They show the relationships between entities in the system in pictorial fashion. The UnifiedModelingLanguage is an excellent language for describing the entities in the system, particularly classes.
UML has got a very bad press, though, because of projects who use it as a major part of their BigDesignUpFront. I've built my development methods around the use of ExtremeUml?. I use TogetherJ as my development environment which lets me sketch out my classes as diagrams and then fill in the details in the editor. The diagrams are always up to date because with TogetherJ the code is the model - the tool uses the .java files directly rather than converting to an internal representation. UML is now a major part of my 'design a little, code a little' cycle and TogetherJ even has a plug-in which will create skeleton UnitTest classes for me and add them to the testing hierarchy.
-- DougClinton?
It's perfectly OK to use UML diagrams in ExtremeProgramming and any other AgileProcesses. They are just diagrams, not the methodologies. Many XPers use UML diagrams, just without the use of any fancy case tool to make them pretty. Quickly draw them on whiteboard, or paper, use it to communicate with your team, your customer, or yourself, then you don't need them any more.
--AdamLi
I think the key to really effective use of UML is that it must be ExecutableUml. If diagrams are the source, then you never need look at the generated plain-text code. XP can then be practiced on this graphical language. To get maximum benefits, also apply XP to the translator that converts the diagrams to text-code. Maintaining both Diagrams and Translator as part of the same project is vital to achieve efficient and maintainable code. It also helps reverse the tendency towards fragmentation that is often seen when OnceAndOnlyOnce is applied to plain-text code.
In some environments, tools that use UML as an alternate syntax for structural elements of a programming languages are also beneficial. (i.e. a rectangle with a name is an alternative syntax to "class <name> { ... };"). These tools exhibit a round-trip behavior to suck any code changes back into the diagrams. However, this may constrain the code-hacker to the subset of the language that is known to the reverse-engineering engine.
The thing you don't want to do is to create non-executable UML as documentation. White-boards are one thing, but maintaining dead-documents becomes a chore.
--DaveWhipp.
I guess there are 2 kinds of people: ones who "like" diagrams.. they'll probably like UML and others who prefer "source code".. ThierryCros
I like code when I want to know what the system is actually written to do, and I like diagrams when I want to see how all of the pieces of code, often scattered across multiple source files, work together. Good, up-to-date diagrams present a different view of the code than you get by reading the code itself, and depending on the diagram, differing insights can be gained from the views than from the code itself. (OTOH, there are actually 10 kinds of people: those who understand binary and those who don't.) --DavidJaquay
The whole point is to get the people who can't read code to talk to the people writing the code in the same UnifiedModelingLanguage --DennisDaniels
That is one point of view. I have never found that UML is any better for communication (with non-programmers) than pure, well-factored, textual source code (neither work). The advantage of UML is that it gives a different viewpoint. A big problem with OO source code is fragmentation. a 2-d diagram brings that fragmentation together, allowing the human brain the perform its chunking magic (SevenPlusOrMinusTwo). But this is pointless unless the UML is part of your source code. OAOO still applies. Its just a different syntax. --DaveWhipp
Come to think of it, has there ever been a technical endeavor that did not use diagrams of some form?
Topics:
EditText of this page
(last edited November 18, 2014)
or FindPage with title or text search