Agile UML
Following on from the Disrespecting UML post, I've been thinking about what "UML" means to different people and what I want from UML tools. Martin Fowler references these three classifications for thinking about the UML:
There's certainly more possible variations of these classifications such as:
My preference is more towards UmlAsSketch i.e. as a means of communicating the complexities of a design or large block of code without having to go into the nitty gritty details. There's a great post on Models by Hal Pierson (got there via Scoble).
For me, this is the key to approaches such as the UML or Microsoft's DSL/Whitehorse initiative. It allows software developer's to deal with higher level abstractions and communicate those abstractions to other developers. My ideal is to be able to do the following with a UML (or similar) tool:
At the start of a project, use high level diagrams to describe the architecture and/or design of a proposed software system. Those diagrams could be done on a white board, hand sketched on paper, hand sketched on tablet PC or entered into some development environment.
After a planning phase, any high level diagrams can be converted to code with a minimum of effort.
Once code exists for a project, it should be easy to generate a modeling diagrams from the existing code base. There shouldn't be any major manual effort or processing time to get these diagrams. The manual effort should be limited to defining what portions of the code/classes go on what diagrams and possibly some manually tweaking of positioning.
The API or class documentation for the code should be able to be generated from the code and include the model diagrams as part of the documentation automatically i.e. sort of like ndoc but with UML and other modeling diagrams mixed in.
If a developer needs to get familiar with a block of new source code, it should be possible to just point a modeling tool to the code and get back models of the code e.g. class diagrams, sequence diagrams in the case of UML.
The Together modeling tool did a number of these "ideals" very well. I regularly used the community edition to be able to understand a new block of Java or C++ source before Borland bought them out and the community edition disappeared. The reverse-engineering ability for C++ and the automatic diagramming positioning was amazing, though the cost was prohibitive and the start up time was very frustrating (it's a Java Swing app). I've given up on the Together tool because of the cost and start up time issues.
These days I use Enterprise Architect from Sparx Systems. It's reasonably priced but the problems I have with it is that it keeps a separate relational database as a copy of the structure that's in the code and it's auto-diagramming/reverse engineering isn't as good as Together. Flywheel from Velocitis looked promising, but it may be effectively trounced by the functionality in Visual Studio.NET 2005. At some point in the near future I'll look into the VS.NET 2005 functionality in detail and post how I go.
In summary, UML and other modeling approaches such as Microsoft's Whitehorse initiative don't have to be straight jackets. They can be used in an agile manner especially if tools truly automate as much as possible so that the software developer doesn't end up just doing "busy work" that doesn't directly contribute to putting running reliable software "on the table".
There's certainly more possible variations of these classifications such as:
- UmlAsTheOneTrueWay
- UmlWeDontDoThatHere
- UmlIsJustSomePrettyPicturesGiveMeRealCode
- UmlIsForQuicheEaters
- UmlAsaStraightJacketInTheRupAsylum
My preference is more towards UmlAsSketch i.e. as a means of communicating the complexities of a design or large block of code without having to go into the nitty gritty details. There's a great post on Models by Hal Pierson (got there via Scoble).
Models allow us to focus on some aspects of a structure while ignoring others.
For me, this is the key to approaches such as the UML or Microsoft's DSL/Whitehorse initiative. It allows software developer's to deal with higher level abstractions and communicate those abstractions to other developers. My ideal is to be able to do the following with a UML (or similar) tool:
The Together modeling tool did a number of these "ideals" very well. I regularly used the community edition to be able to understand a new block of Java or C++ source before Borland bought them out and the community edition disappeared. The reverse-engineering ability for C++ and the automatic diagramming positioning was amazing, though the cost was prohibitive and the start up time was very frustrating (it's a Java Swing app). I've given up on the Together tool because of the cost and start up time issues.
These days I use Enterprise Architect from Sparx Systems. It's reasonably priced but the problems I have with it is that it keeps a separate relational database as a copy of the structure that's in the code and it's auto-diagramming/reverse engineering isn't as good as Together. Flywheel from Velocitis looked promising, but it may be effectively trounced by the functionality in Visual Studio.NET 2005. At some point in the near future I'll look into the VS.NET 2005 functionality in detail and post how I go.
In summary, UML and other modeling approaches such as Microsoft's Whitehorse initiative don't have to be straight jackets. They can be used in an agile manner especially if tools truly automate as much as possible so that the software developer doesn't end up just doing "busy work" that doesn't directly contribute to putting running reliable software "on the table".