Home The art of drawing diagrams
Post
Cancel

The art of drawing diagrams

I have a confession to make, there was one time I was asked to create materials for a Software Modelling class. Seemed like a pretty good idea at the time and a great opportunity add stuff into my CV. At the time, what did I really know about software modelling, not a lot - perhaps spent 20 hours or so in lectures during my final year of university. Barely made it through that class, perhaps this is my redemption to teach the next generation of software engineers.

It’s safe to say that, it wasn’t until 5 years later that the professor, whom was still teaching that class mentioned in passing that they only recently found a mistake in one of the practicals. There was 12 weeks of content that I had to put together utilising an easy to use but quite obscure tool. Umlet it was called, infact they still develop for it, it’s version 15 now, class.

Why use diagrams

Personally, I function better when I picture things and I believe diagrams are great for this. I’m not going to tell people how to diagram, it’s so subjective and it could be the most beautiful looking thing for someone and complete chaos for others. mess

This looks pretty cool, if you didn’t tell me it was suppose to be a software modelling diagram. Keep things simple, or else. That’s it. You will have a bad time. We all been there.

I haven’t done much research or have I sink a lot of time into this topic, but I will list out what has helped me through the years that enable me to be more efficient in building software and also to convey a journey to both fellow engineers and stakeholders that are interested in what we are trying to achieve.

C4 Model

One of my favourite diagrams which I keep going back to using is C4 models. This is built up of 4 levels of diagrams:

  • Level 1 Context
  • Level 2 Container
  • Level 3 Component
  • Level 4 Class

For more information see: c4model

Context diagram

This is my go to diagram when I was to start exploring new systems. Throw up all the bits and bobs that I deem important.

Things that you should consider:

  • Who are the people / consumers / customers using this
  • What are the external systems involved
  • What are essentials - minimal parts required to get it working

You want to keep it simple with minimal noise, if something is not worth talking about, don’t. Keep in mind that this is the highest level of the system, each person within your team or business should understand it. Once you get anywhere, take it to someone (even your mum if you want), get a fresh pair of eyes on it so that you know you are not insane.

c1 diagram

See an example banking system from a random image I found on google, thanks mate.

Container Diagram

This is when you have buy in from the stakeholders to actually start building this. You will find yourself starting to seek out options to do it, but stop. Let’s think about it a little first. Where does everything live and what are the overheads, costs and trade-offs to your decisions. Why not just draw them all out, allow yourself to explore what you actually need to deliver this system. Ensure you bring a friend with you, this now a technical discussion, what do you need, is it a web app, do you need a data store, will SQL do or do you need a document store. These are a great time to discuss this.

Component Diagram

Next step is to really drill into things at a component level. The hows:

  • How will we really shape the information or where is the value to the customer?
  • How will our consumers receive this data?
  • How do each part really talk to each other?

This is essential blueprint for actually building out the parts, you can use this to split of tasks if the engineering team is big, referring back to the components during develop.

Class Diagrams

I have no comment, it’s rarely that I will go this low level. Surely you could if you want.

Summary

Check out c4model, super useful stuff. Add a proper summary to this at some point, will likely extend this to include Event Storming. As we have moved to more of a virtual working environment, at EG we have Google workspace and jamboards has been very great way to stick virtual stickies on a board and start discussing events and flows of a system.

This post is licensed under CC BY 4.0 by the author.