UML in practice – my top fives

I recently came across an interesting publication regarding the adoption and practices of Unified Modeling Language (UML) in the real world. Written by Marian Petre and presented in ICSE’13, titled “UML in practice”. The article stated that,

UML has been described by some as “the lingua franca of software engineering”. Evidence from industry does not necessarily support such endorsements. How exactly is UML being used in industry — if it is? This paper presents a corpus of interviews with 50 professional software engineers in 50 companies and identifies 5 patterns of UML use.

For those that are impartial to reading blog posts, obviously ;), here is great summary of the aforementioned paper from a blog that I follow. http://neverworkintheory.org/2013/06/13/uml-in-practice-2.html.

There are two noteworthy takeaways.

  1. After 20 years, UML is not widely adopted due to its complexity and overhead, difficulties in synchronising code and design, and lack of context (UML often deals with architecture and not the whole system)
  2. When UML are used, only parts of the diagram notation are adopted; class, sequence, activity, state and use case diagrams. These diagrams have the lowest barrier of entry and provides a very useful and flexible tool for communicating particular view of a system.

For me personally, I too fall under the “selective usage” category. I also believe that the informal nature of UML, particularly when juxtaposed with other formal methods, showcases that UML is great for illustrating overarching architectural breakdown but horrible for specifying detailed implementations.

My experience with UML is a very positive one. Here are my top five tips for some UML hackery:

When I use UML, I…

  • follow a particular design methodology, one such as Concurrent Object Modeling and architectural design mEThod (COMET). Doing so will lead to selectively subsetting the notations and diagrams, at the same time applying structure and guidelines for illustrating design and context for the system in question.
  • focus on the diagrams that can be easily understood by stakeholders. No point building a state machine that captures non-determinisms and lambda transitions when no stakeholders cares about it. Do, however, provide useful class breakdowns or entity relations if people finds them useful.
  • formalise the models depending on the system in question. For example, adding Object Constraint Language (OCL) into your requirement models makes it formal. It can be audited and proven. Formalising UML is suitable for AS 61508 classified systems, compliant to certain Safety Integrity Level (SIL) levels.
  • estimation the size of project via use case estimations. This is a great baseline for sanity checks.
  • use a good Computer-aided software engineering (CASE) tool. See the following CASE tool comparisons as an example; https://macyves.wordpress.com/2013/01/17/uml-case-tools-for-the-mac/.

Spend some time and get to know this visual language. You will find a clever and flexible way to communicate your ideas and intent to a wider audience and with improved precision and articulation.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s