UML sense front page representation

Getting started with UML

Published: February 2, 2023

Home/Writing

Intro

My original plan was to create a website resource that would provide UML-centered information mainly for my own learning benefit. Instead, I'm going to put the project on hold and share what I have learned so far with class diagrams at least.

Basic starting point

I started by researching the content on the topic from various sources. Then after going through the research, I was able to formulate the best way to approach the topic.

Research

I googled and searched for all the top content I could find and then meticulously filtered through the content, making notes as I went. The UML specification documents formed the backbone of most of the content. However, the documents can be quite hard to read.

SourceDescription
Websites Most of the first page SERPs were blog-type articles from software vendors like Lucidchart, Smartdraw, Miro, Visual Paradigm and others all answering typical questions like what is UML, why use it, who uses it etc.

Interestingly, this article by Visual Paradigm provided a valuable list of books and glossary terms.

A very useful website that I found is uml-diagrams.org. The website owner references a lot of the technical information from the original UML specification.
YouTubeI never got around to doing a full review of videos on YouTube. However, I did go through the first part of the freeCodeCamp course. They give quite a valuable run-down of all the different diagrams and what they are used for.
BooksThere is a long list of books (see above) which I went through. I didn't go through the list fully, but I got a hold of 2 particular books through my University which proved to be quite useful
  1. Learning UML 2.0 - A pragmatic introduction to UML
  2. UML 2.0 in a Nutshell
(see reference list at the bottom of this post for details).
Specification

The governing body that maintains the specification is called OMG (Object Management Group). There are a few specification documents DI(Diagram Interchange), OCL(Object Constraint Language), UML Infrastructure, UML Superstructure, and UML Spec.

  • The DI is for sharing UML models between different tools
  • OCL is for writing constraints in the diagrams
  • The infrastructure document specifies low-level, core concepts
  • The superstructure builds on the infrastructure document and provides more technical details at a higher layer of abstraction
  • The superstructure builds on the infrastructure document and provides more technical details at a higher layer of abstraction
  • The UML specification elaborates and tries to group together the finer-grained technical details in the superstructure into something a bit more cohesive and digestible

There are probably a lot more other valuable resources out there, so I only scratched the surface of what is available.

Basics

UML is a visual language primarily for capturing and communicating software design (Pilone & Pitman, 2005). A set of agreed shapes and forms are used to design, visualise, and document complex systems (freeCodeCamp.org, 2021). UML helps to bring new team members up to speed on a project, enables exploration of source code, helps to plan features before writing code, and helps to communicate with technical and non-technical audiences (Lucidchart, n.d.-a)

The Who's Who

Rosenberg & Scott (1999) provide a good explanation of the early beginnings of UML.

Three major schools of thought:

Around 1993, the best in each category seemed to be Rumbaugh's OMT, Jacobson's OOSE, and Booch's method. All three were combined to form UML in 1994. Then in 1997, the Object Management Group (OMG) accepted UML and v1.1 was released.

Diagrams

There are two types of diagrams: Structural and Behavioural, and there are currently 14 different UML diagrams as defined by the UML specification. Structural diagrams show the static structure of objects in a system. Behaviour diagrams show the dynamic behaviour of objects.

UML diagrams

Approach to Learning

There are 14 diagrams which are made up of lots of different components, some of which feature in multiple diagrams. One way I figured was to learn the different components and then learn how to apply them in each UML diagram. This kind of approach doesn't really make practical sense because you aren't going to use every UML diagram ever in your career so learning all the components would be a waste of time really. So I figured the best way is to learn from a diagram point of view, breaking down the main components in the diagram into their constituent parts with basic explanations.


For Example, if you take a look at the class diagram:

I think it's important to know in a broad sense what each diagram is used for so when faced with a situation you can choose the right combination of diagrams that would help to convey the right information. But you don't necessarily have to know everything about the diagram or know about the intricacies of a specific programming language.


It's important to think about the audience that you will be using the diagrams with. If you are doing a report for a manager or a business user, you might use simplistic high level diagrams with less detail to illustrate the main functions. While, if you are writing a detailed specification for a programmer then you will want to include as much detail as you can.


I think the real value is in the translation between different mediums. For example, translating from code to UML diagram and vice versa, translating or relating UML diagrams to business processes or value driven business models, or merely translating system requirements to UML diagram.

Final ideas

Here is a list of ideas for learning or using UML which I'll get back to at some point when I get the time:



References