The Unified Modeling Language or UML notation is probably the most well known and regularly used visual representation of programs that you’ll find in software development. There are a wide range of diagrams to help you specify your data and processes before you start programming. They help you clarify requirements and limitations, speed up the implementation, provide a guide for thorough testing, and prevent bugs from sneaking in throughout the entire software development process.
If you aren’t using them, why not? 😉
In previous posts, you have seen two examples of behavioural diagrams (use case models and activity diagrams). I’d like to jump to the other category of UML diagrams – structural diagrams. Probably the most well known structural diagram are class diagrams, which specify the data structures and their relationships within your program.
Of course, you can develop the different UML diagrams in the order that you prefer. But as you work on later diagrams, especially those in the other category, you’ll almost certainly find you have missed things. It’s perfectly normal to need to correct or modify your earlier diagrams – think of it as parallel diagramming!
Class diagrams are not just used for programming
For example, business analysts can model the company structure of assets and processes associated with them.
UML class diagram notation
Unsurprisingly, your program’s classes go into a class diagram, including their attributes (variables) and methods (functions). These diagrams form the foundation of object oriented programming.