In my last post I explained some basic UML diagrams and why they’re important for developing software. If you haven’t read it already I recommend checking it out here. In this post I’m going to continue and explain some of the more abstract UML diagrams.
The State Machine Diagram
The State Machine Diagram is used for modeling the changing states of objects in a system and the events that causes these state changes. As you see in the model above the states are represented by rectangular shapes, between these states there are arrows with text on them pointing back and forth. These are the so called transition events. In the ATM example above you can see for example that the ”in card” and ”cancel” event changes the objects state between active to idle.
The starting point of the states will have a filled circle with an arrow pointing to it as shown in the model. Normally there’s also an endpoint that the final state points to which is represented by a filled circle surrounded by another circle, but in this example there is none. This diagram is a very simplistic example, other diagrams might be more descriptive and include a lot of notations to describe the events and states.
A Packages Diagram is a very simplistic type of structural diagram. It’s used for organizing large scale system which contains many elements such as diagrams, documents and other key deliverables. With this diagram all the logically related elements are grouped into packages, which are displayed as folders. These are then connected with dotted arrows that represent the dependencies between the packages. In the diagram above we have two types of dependencies, access and import. these are the most common types of dependencies. the import dependency means that one package imports the functionality of other package and the export dependency means that one package requires functions of another package in order to function properly.
This diagrams is very useful for larger projects where you really need to have a good overview and understanding on how everything is connected.
The Component diagram works in a similar way as the package diagram. But instead of displaying packages this diagram displays components and how they are wired togheter to form the different parts of the software.
A Component is a logical unit blocks of the system, it’s a bit more abstract than classes and objects. They can represent a group of classes and Normally a component is represented by a rectangles with a smaller rectangle in its upper right corner. In order for them to carry out functions they use interfaces.
The interfaces (small circle or semi-circle on a stick) are located between the components. They describes what operations are required or provided by the components. A full circle means that the interface is provided by the component. A semi-circle represents that the component requires an interface from another component, like for example a user’s input. Similar to the package diagram this diagram also displays dependencies between the components with arrows.
One of the most important parts of software design in my opinion is knowing what responsibilities your objects should have. You need to know if and how the objects are obligated to perform some tasks or know certain information. A good guideline for this is the General Responsibility Assignment Software Patterns known as GRASP. It contains a set of 9 patterns and responsibilities that I think every programmer should be familiar with.
1. Information Expert
4. Low Coupling
5. High Cohesion
8. Pure Fabrication
9. Protected Variations
If you’re visual learner like me then i recommend watching this video as it explains all the patterns with practical examples.
Don’t like youtube tutorials?
Then heres a more detailed explanation in text by Kamil Grzybek.