We typically use UML for one of the following reasons:

Communication - A great benefit of UML is that it is a precise language, and therefore has specific rules. For those of us who understand those rules, UML diagrams can be very effective in helping communicate visually. I know it's much easier for me if another developer can provide a visual depiction of the structure of her code over just describing it to me. But in most cases, I only need the visual for a short period of time. Once I gain that initial level of understanding, I want to view the source code. The source code is the only artifact that doesn't lie. So once I have that initial understanding, you can toss the diagram and show me the source.

Documentation - Seemingly a bit redundant with communication, but I separate the two with the distinction that documentation is supposed to survive long-term. Supposed to! We document what we've done so that when it comes time for others to familarize themselves with the system, they have reference material. Not a good idea. It's highly unlikely anyone takes the time to ensure the documentation stays up-to-date with the source code. If you are using UML for documentation, do it as late as possible in the lifecycle...ideally only when someone actually needs it. When possible, automate generation of this type of documentation as part of your automated and repeatable build. Then, it'll always be up-to-date. Only create manually what you cannot generate automatically.

Design - It's common that early in the lifecycle, you'll create UML class and sequence diagrams with the idea that by putting more thought into the design up front, you'll end up with a more resilient design. Not likely. Good design (and architecture) has nothing to do with UML, and a lot more to do with understanding object-oriented design principles and patterns. Assuming you aren't familar with the open-closed principle, dependency inversion, and acyclic dependencies, you'd be better studying these concepts over mastering UML. Knowing all this, UML is helpful for establishing vision early. But beyond that, Test Driven Development and Design combined with a good share of refactoring is your better bet for allowing a design to emerge that is truly resilient, extensible, and maintainable.

Can UML be used in an agile fashion? It sure can. AgileModeling.com is an exhaustive resource describing ways modeling can be done in an agile way, effectively coupling UML to process. That's valuable. Knowing what diagrams to create is also helpful. For instance, I find great value in creating class and sequence diagrams that illustrates an application's defacto standard approach in using Struts, Spring, Hibernate or some other framework. I'll also use UML during meetings to discuss complex frameworks, or the relationships between the deployable units. It's also important that members of my team and I each have a consistent understanding of how UML maps to our implementation environment. For me, that's critical. But I also rely on other practices, such as an automated build, to enforce my design and architectural decisions. UML is a wonderful complement to many agile practices.

UML is a toolset, albeit an important one in some situations. However, there are many other practices, techniques, and toolsets that are as effective, if not more so, in certain situations. It's important to know what problem you are trying to solve with UML, and then make sure you know what alternative techniques will help contribute to your effectiveness.

Trackback(0)

TrackBack URI for this entry

Comments (0)

Write comment

Show/hide comment form

Name

Comment

smaller | bigger

Subscribe via email (registered users only)

Write the displayed characters

Add Comment Preview