How relevant is UML modeling today?

Posted by Jeremy Miller on September 12, 2009

This isn’t flame bait, I sincerely want to know.  UML hit big in the late 90′s about the time that I was first starting to lift my head out of the VBScript/VBA morass and seeing the bigger software world.  I grew up reading the old Software Development magazine and the Rational website.  For a long time and even into my early Agile years I considered UML modeling to be a key skill for anybody leading software teams and definitely for anybody who was serious about learning about software design.  Not so much because designing with UML is useful, but because it’s such a common communication tool in books and between developers.  Or let me put that another way, I don’t find UML frequently helpful for figuring out what to do, but UML is very helpful in communicating or visualizing ideas.

I’m working up my book and I’m thinking about how to present certain ideas.  My question to you is how helpful are UML diagrams to you in learning or understanding code level design constructs and concepts?  I don’t see much use for static class diagrams in the book material so far, but I’ve always thought that sequence diagrams would help for some of the complex interactions. The problem for me is whether or not UML is still relevant to most developers now and in the near future.  UML isn’t useful if the audience doesn’t get it.

 

Side question, I’m actually thinking I’m going to use CRC cards in place of class diagrams because I think it conveys more useful information and it’s easier on me.  Anybody have an opinion about that?

 

Thanks in advance,

Jeremy

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at http://codebetter.com/jeremymiller.
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • kamathln

    UML is like a classic book. Most people want to have read it. But few do read it.

  • kamathln

    UML is like alphabets. If we limit ourselves to learning UML, individuals or groups among us will end up inventing our own language over UML, which sort of misses the point of having UML. Teach us how to use UML to speak about design patterns and architectural patterns(words and sentences). Teach how to use UML in conjunction with best practices and other wisdom in the Software Craftsmanship (good manners, communication skills,etc).

    Also teach us how to use UML when maintaining, re-designing, existing software, and various ways UML can be used during project management, like for example change request. Or if there is something that can’t be done using UML, say for example optimization, project cost estimation, etc., mention it clearly and how best to complement UML with something else for the same.

    One of the non-communicated misconceptions(or is it a right conception?) of outsiders to the UML field is that UML is better suited for top-down approaches.

    One of the problems of UML is, there is no easy plan to learn it from the beginning.
    make such a plan.

  • kamathln

    Also, what do the “software craftsmen” say?
    http://en.wikipedia.org/wiki/Software_craftsmanship

  • http://www.visionsoftonline.net Ali

    Working in the industry for so many years, I haven’t seen it used a lot and most of the people don’t get it. Personally I feel its an overhead to create all the pretty pictures.

    Its good if the process is very complex which you are trying to implement but why not just a flow chart.

    Business users and alot of developers don’t get these complex diagrams. There are so many diagrams available to use so sometimes its hard to pick which ones should be done or not.

    I think it’ll be good for a software house but not for enterprises who have IT departments with alot of change requests coming in. More documentation and diagrams are hard to maintain like dead comments is your code when your project is touched by so many developers over number of years.

    I think Agile is very practical and just doing white boards and keeping a track of them makes more sense. Usually when we do white boarding with business users, we take a picture (sometimes with a cellphone) and keep it for our record with our project documentation when we need to look at it.

  • http://nileshgule.blogspot.com Nilesh

    I agree with you that with many organizations adapting Agile methodologies UML has lost its shine a bit. I still find it relevant to use Sequence diagram to depict a complex interaction. Other than that may be component diagram describing different classes that go into various components or sub systems might be helpful.

    I would suggest using very less UML and demostrate more using code in a truly Agile manner.

  • CapableObjects

    Look at wonderful ECO 5 by Capable Objects

    http://www.capableobjects.com/

    Pena

  • http://www.kent-website-designer.co.uk/ Website Design Kent

    Hmmm, depends on the system its representing. Logical approach still remains the best goals.

  • vonjovi

    Andrew — that article is truly brilliant!

    I take back everything I said, and now I’m moving to Tibet to study transcendental programming.

  • Andrew

    This reminds me of an old article about UML from a university student’s point of view:

    http://archive.eiffel.com/doc/manuals/technology/bmarticles/uml/page.html

  • vonjovi

    I agree with Francois that the whiteboard is the most valuable weapon in the arsenal since we often have to deal with “retrospecs,” however it saves a lot of time and confusion if everyone speaks a common language (e.g. UML) from the beginning.

    I also agree with Steve that it’s not usually necessary or effective (unless you’re under legal constraints) to completely design systems down to the code level ahead of time, but It’s pretty scary to think that any team would just jump in and start coding without having a pretty darn good idea of what everyone else is building and where the pieces will come together (i.e. the public interfaces). Unfortunately telepathic coders are just too hard to recruit ;)

  • Juraj

    UML is good tool in case that everybody – I mean every member of the develop team – keep the discipline: keep always documentation up to date and keep the status that everybody really understand every part of model that can continue the work on solid previous base. And this is the problem I think.

  • bolyard

    In general I agree with your comments. Basic UML is still the defacto standard for diagramming.

  • http://www.ashraful.net/ Ashraful Alam

    .NET Application Modeling Language (http://code.msdn.microsoft.com/naml) — this is my 2 coins in this regard, UML is having the lack to show low level illustration when needed. I know it overkills to go to the implementation details on modeling sometimes, but it requires sometimes pretty well

  • http://florioux.blogspot.com Francois Lorioux

    I have been involved in large projects (several millions of lines of code) for 15 years. Because of strong operational constraints we had no time to maintain an up-to-date documentation.

    Adding new functionality or correcting bugs requires a correct understanding of the way the system behaves. This may become a difficult task in case of a complex workflow (workflow involving a large number of classes for instance) or in case of spaghetti code.

    I use a small subset of the UML notation for partial reverse engineering and for refactoring actions. I built some sort of hybrid diagram with elements borrowed from class diagram and other ones from collaboration diagram. This diagram with both static dependencies and messages helps me for discovering bad design smells (cyclic dependencies, responsibility assigned to a wrong class,…).

    I mainly use CRC cards at the very beginning of a new project as a tool to spread responsabilities between classes.

    The whiteboard has proven to be for me the most valuable tool to communicate with other people in the team.

  • Steve Py

    Software != Architecture. Writing software should be more closely compared to arts such as writing a book or producing a show or movie. It requires planning, process, and discipline, but the end result is *adaptive* to the circumstances that develop through the process. Architecture implies clear-cut, do not cross under pain of lawsuit requirements, and does battle with the laws of nature and regulation. Software, by its very nature is “soft”.

    CRC modelling suits software very well because it helps the overall picture of the software remain soft. High priority feature are solidified in turn and produced into visible results. The product can evolve, it’s not “locked down” because change isn’t within the scope of the original complete design / model.

    In my experience, working with customers directly, discussing features at high-level then getting their input as features are turned into function gives immediate feedback on how money is spent. They see and touch the real, not what a designer predicted.

    Blueprints are a necessity of architecture, but having purchased houses off blueprints, the end result often leaves many areas of disappointment, it doesn’t always come out the way you expected on paper.

  • vonjovi

    Based on 20+ years of experience designing, building, and maintaining software systems…

    No sane person would consider building a new home without first having an architect draw up a detailed set of blueprints (just ask any mortgage banker!). Similarly building applications and systems that are anything beyond the most trivial should start with some sort of detailed modeling. UML provides the most flexible and widely accepted set of tools for modeling software applications and systems.

    The CRC card approach with Use Case analysis is extremely helpful to start designing systems. If the top level CRC card objects, methods, and attributes have names that are familiar in the users’ domain, and if you can walk users through the Use Cases without them getting glassy eyed your chance of success (i.e. building a system that is truly useful to and appreciated by users) is much greater. Propagating those “user friendly” names throughout a system also makes the system more maintainable and extensible.

    A combination of UML Class Diagrams and Instance Diagrams (aka Object Diagrams) should be used to refine and test the public interfaces to objects at all levels. The Class Diagram itself only tells part of the story. Working through Use Case and test case examples with Instance Diagrams very quickly exposes flaws in the design model, and it’s definitely much less costly (time, money, and headaches) to fix the design model rather than trying to rework the code during system integration and test.

    For the most complicated parts of the system UML Interacion Diagrams should be generated to make sure that the roles and responsibilities of each object in the communications chain are fully understood and are testable.

    In short, UML tools can and should be used in the appropriate combination when designing applications of any complexity.

  • zihotki

    My vote goes to CRC cards! UML diagrams contains too much noise. UML is good for documentation but it seems to me that it’s not useful for explaining ideas because you have to deal with several types of diagrams (class, sequence, collaboration and so on) to give a good explanation of the idea.
    It’s much more easier to understand CRC in comparison with UML.

  • Dinkar

    I think UML modeling and UML diagrams are two different topics. Models are welcome anyday and the model does explain the concepts with much more ease than typical bare code.

    UML diagrams on the other hand are both good and bad. Good in the sense that majority of software community understands its notations and thus its easier to draw and be understood in terms of notation. Bad in the sense that majority of diagrams are not explainatory unless these are looked into withi the UML tool. A static UML diagram on a page doesn’t convey much but when the same diagram is explored within the UML tool (say Rational’s) it’s much easier to relate and drill down. In terms of UML, I would highly recommend using diagrams with stereotyped elements. Unless the role of the elements (class, object, component) are clear there’s not point in drawing a UML diagram. therefore my recommendation would be a simple meta-model class diagram and then other UML diagrams where each element is annotated with the role defined in meta model.

    I personally am a big fan of CRC cards as an alternative to showing code to people. This helps me tell them “what and why” first. I can always refer to code later and then annotate the code example with C R and Cs relatign back to CRC card. The best part about CRC is that this form/template can be applied to components, classes, use cases, deployment units etc with equal ease.

  • http://ggreig.livejournal.com/ Gavin Greig

    Use the right tool for the job. For a book, where you don’t have quite the same opportunity to flesh things out by talking about them, I think that’s more likely to bias the choice towards UML, because it’s well defined, comprehensive, and widely read (if not authored).

    I wouldn’t let that rule out CRC cards when they help to make a particular point clear, but I don’t think they should be the default choice.

  • http://codebetter.com/members/Ian-Cooper/default.aspx Ian Cooper

    We use CRC cards to create shared understanding in the team. They are great fro a number of reasons:

    There is something about passing a token between people as you talk through the flow of control that makes it easier to generate understanding for the whole team.

    They are obviously throw-away. We tend to use CRC cards to generate shared understanding prior to implementing the story, but during the story are happy to ignore them if the tests reveal a better path. In addition folks are happy to tear up a card when the design does not look good, more so than they are to re-draw a diagram. Somehow not having a UML model makes them feel more temporary.

  • http://colinjack.lostechies.com Colin Jack

    A simple non-formal class diagram showing just the relationships between key classes can be useful. Never been a fan of sequence diagrams, mainly cause they quickly turn into a mess, however they can be useful and I sometimes also find activity diagrams explain things well.

  • http://weblogs.asp.net/mehfuzh Mehfuz

    @Jeremy

    UML is still a tool for software designing in most mainstream development still today[I think, its even tought in many universities]. To me, i think Sketch flow will do a great job than UML designer. But arnt Sequece diagram and Use cases provide better understanding still today ?

    Just my few cents.

  • Kishork

    +1 for CRC

    We currently using “UML as Sketch” as defined at: http://martinfowler.com/bliki/UmlAsSketch.html

  • Raj

    One situation where visual and sequence diagrams (UML or non-UML) play a key role is when we have distributed teams. In that case its better to represent your design ideas visually rather than explaining in words.

  • Dennis Kozora

    +1 for sequence diagrams TIP: http://www.websequencediagrams.com/

    I don’t care much for UML but doesn’t excuse not knowing it though.

    I’d much rather learn/communicate the intended behavior through BDD style specifications instead of UML behavior diagrams.

    Designing a “good picture(diagram)” to convey a software design has been very important to my clients. They tend to prefer a good picture over a long document. That said, UML diagrams aren’t the prettiest things to look at. :)

  • http://jfranzoi.wordpress.com jacopo

    I still consider basic UML knowledge important to discuss and share ideas, in front of a whiteboard or on paper while pair programming. mandatory UML subset for me is
    * interaction diagrams (instead of sequence)
    * class and object diagrams, in particular association cardinality and navigation

    being *behaviour* what we need to model (more than static structure), CRC cards are a great tool too, because they show in a compact way roles and interactions between objects (as I also tried to explore here: http://jfranzoi.wordpress.com/2009/05/10/there-s-more-than-one-way-to-skin-a-cat).

  • http://www.neverindoubtnet.blogspot.com/ Ward Bell

    A few thoughts:

    * Loose UML class diagrams are helpful when there are no more than 5 blocks. Do not indulge the fancy symbols that require a guidebook (“What kind of arrow head is that again?”).

    * Sequence diagrams rock … when the labels are clear. They take no training to read.

    * CRC cards are great. They do the job and take almost no training to read.

    You can tell that I favor pictures that tell a story without requiring the reader to be an Egyptologist too.

    Still, nothing beats code.

  • Evan

    I think it’s really going to depend here.

    For me, UML (usually with very loose semantics) is reserved for the whiteboard.

    That being said, use the appropriate tool for the info you are trying to explain.

    For example, the abstract factory pattern would be a bit hard to explain without class diagrams (as it’s mostly about communicating the structure of the collaborating types–inheritance hierarchy, etc). Sequence diagrams work best when talking less about structure and more about runtime message passing (behavior)

    I think CRCs would work great as long as the structure isn’t complex (ala abstract factory), and you can always mix in a sequence diagram if the runtime behavior needs additional explanation.

  • Devaiah Kokkalemada

    I would say it is a personal thing. Some understand text better and some relate better to visual representation – UML or otherwise. And I don’t think either of the camps is better than the other. I personally prefer CRC cards any day.

    That said, having UML in your book won’t hurt. After all, you don’t want folks shying away from buying your book because of that do you? :)

  • http://thisismichaels.blogspot.com Michael Hedgpeth

    I’m not sure CRC cards would broaden your readership beyond the usual suspects who know who you are and who frequent the ALT.NET scene.

    I’m in a company with a lot of non-ALT.NET people and they would probably expect UML in there. It subconsciously serves as a legitimizer for people. Then again, if you ask them to write UML themselves they would be fumbling…

  • http://thesoftwaresmpleton.blospot.com Paul Cowan

    For me, it has to UML.

    UML turned out to be great for documenting and “after the fact” not before.

  • Eagan R. Wiley

    At my current job, the boss expects some UML diagrams as part of “The Documentation”, but we don’t really model. The only guy I know who takes a modeling approach and embraces UML is a slow producer and weak technically, but he always has a ton of diagrams!

    I also don’t get the indication that modeling is big with the people at the local .NET UG.

    I’d dare say that actual modeling as an approach to forward design and construction isn’t in active use.

    However! I’d say visual representation and diagramming /is/ relevant! I mean this as a much less specific skill than a full blown model-first approach.

    I think a good strategy would be to pick diagrams that speak for themselves and just happen to be (mostly) valid UML. I think this is a scenario where you WANT to shoot for the bikeshed effect.

  • George Spofford

    I find class, object, sequence and collaboration to be most useful. UML standards leave out much that is useful (am I missing the UML ORM mapping diagram, among many limitations). Also, to tell the appropriate story with a diagram, I’m often combining types such as class and object or object and sequence. CRC is really useful, wish the tool I used the most (Sparx EA) supported them.

    As a potential reader, feel free to stay close to UML where you can, but don’t hew slavishly to it if something else will help you convey your information. For example, the GOF patterns book had little code snippet callouts that aren’t part of any prominent standard but I found really helpful in understanding method relationships.

  • Matt Baker

    I was actually just discussing this yesterday with a buddy of mine. We were both in agreement that while it’s important to be able to read UML and understand diagrams for code-level constructs (e.g. class diagrams) is important, knowing how to make them feels less important. There are so many tools that just automatically reverse engineer your existing code into UML that it often doesn’t make sense to waste time doing it by hand.

    However, class diagrams are only a very small part of UML. Use cases are modeled using UML which still appears to be important in agile. Depending on the type of system you’re building, collaboration and sequence diagrams can be useful for modeling the behavior of a system. It all depends on whether it will cost more to fix it later or get it right now as to whether you invest your design types in formal modeling such as UML.

  • http://blogs.ythos.net Matthew Adams

    Sequence diagrams I find very useful for analysing a codebase you’ve inherited from somewhere else, and they’re also quite useful for communicating a complex interaction to another developer (so actually, a book is one of the few places I’d expect to see them).

    Static structure and sequence diagrams are also also quite useful post-mortem (or, rather, pre-refactoring) tools, too.

    However, the one I use most is the package diagram. It is a great way of communicating structure at that level, and showing the directionality of dependencies between assemblies and subsystems, and how subsystems are split across assemblies.

  • http://webgambit.com Karthik Hariharan

    I think some UML diagrams have their place (sequence diagrams being one of them). The reason UML fell out of a favor is that it tried to become too encompassing and less approachable over time.

    Stick with the simple UML that you don’t have to read “UML Distilled” to understand and you’ll be fine.

  • Kent Sharkey

    I’d definitely vote for CRC cards. I always found them more useful tools than UML models for working development. Plus, I think they work better with teams.

    As for UML, I agree with our opinions on class diagrams. Formal UML that is, I think just about every developer uses a form of class diagrams whenever they hit a whiteboard. I’m less convinced about the usefulness of sequence diagrams, however.

    I’m not sure why UML never continued its growth – perhaps some combination of “committee-ization” or “one supplier” issues.