Slide Deck: Reading Design Diagrams
Back in the late 1990s, object-oriented programming was the star of the show. Companies were starting to build everything in Java and computer science departments were quickly switching to OO in either C++ or Java. There was a lot of good reasons to do this, particularly for students. Objects “made sense.” It was easier to explain to students how to program when they could visualize a “thing” that had actions (i.e. methods, functions) and properties (i.e. variables, state). Then, those objects could work with each other to make a fully-featured system.
From a business side, it made a lot of sense because now developers were creating modular code that could more easily be incorporated into other systems. Maintenance became simpler. Costs could (potentially) go down!
With the advent of OO programming, there was a push to have a “better” way to communicate how the modules/components of a system would work together. The Unified Modeling Language (UML) was part of this push.
UML did what was sorely need at the time - it standardized how to draw design diagrams. And this made a lot of sense because UML was basically OO design and there was a lot of OO programming going on… so it just all kinda worked. The newly-growing agile community also jumped on board. What if code could be generated from these diagrams? Could these diagrams replace all that icky documentation that plan-driven systems wanted?
It all seemed to be moving in a positive direction for UML.
In an interesting twist, UML was “out-agiled,” in a sense. UML became a bit too rigid. More and more “types” of UML diagrams were invented for specific use cases. Developers got into weird arguments about which arrow to use on a diagram.
Is it really important that one specific arrow was chosen over another? Well… yes and no.
Yes, because the different arrows communicated different things. Now, does it matter what the arrow actually was? No, of course not. The important thing here was the meaning being conveyed.
In the end, no one really cared what symbols or language was used - as long as whoever was looking at the diagram understood what was going on.
So, companies started adopting their own rules. Many of these rules follow some of the same principles of UML (so, learning UML is not a waste of time!), but you often need a bit more context. The catch, though, is that many companies with software services (e.g., Microsoft, Google, Amazon, etc.) publish these diagrams for developers to reference. Which means learning how to read these diagrams without any extra help is an important skill to develop.