The Unified Modeling Language, as stated in the last post called UML_ (Part 1), is a set of diagrams to standardize the modeling languages and help to develop software systems so developers can visualize, construct, and document the whole process in a short and standardized way. The UML is a collection of engineering practices to successfully develop complex systems with object oriented or development process features. Because of the graphical notations, teams can collaborate correctly and use those visualizations to validate and create potential designs of the software.
This definition which was explained in the last blog post is key to understand all types of diagrams that make the whole UML what it is. The main objective of part 1 was to understand the meaning of it and answer the question of why it is important to use it. There were some basic diagrams to understand by example the application of it but now the focus will be only on diagrams. Some of them are more complex and others with some peculiar attributes.
The state diagram, also called state machine diagram, is used in UML to describe the behavior of systems. It is based in states and transitions which describe the main cycle of the system by analyzing all of its states and behaviors. The focus of it is to have an initial state which by transitions changes states until it gets to a final one.
The package diagram, as the name says, it involves packages within the system by making relations with dependencies. These dependencies are used to make a multi-layered application which transforms this type of diagram in a multi-layered model.
Similar to the package diagram, the component diagram is used in UML to create complex systems with components and dependencies to illustrate architectures, but in this case, components can be made by more components and vice-versa. So, when creating large components with dependencies, a system is created. The components used in this type of diagrams are executable.
One can analyze that the images shown for the diagrams and the explanation from this post and the last one, there are similarities in the way de UML expresses each one of the diagrams. The squares and lines are always present in each of them, but there is one in particular which changes the rules so that the generic UML symbols change into the Model View Controller symbols. The main purpose of the MVC is to improve the readability and usefulness of UML diagrams. So, it states three main symbols which are used in conjunction to make operations and communication between them.
To make interactions and communication there are a set of rules in the MVC that must be applied. Alvin Alexander’s blog describe the following rules for the MVC, I personally recommend reading his entry for more deep learning on MVC diagrams.
- Users interact with View objects
- View objects and Controller objects talk to each other
- Different Controller objects talk to each other
- Controller objects talk to Model objects
- No other forms of communication between objects are allowed
The last point to take note before the UML topic ends takes care of the following step after making a diagram. UML helps us to code with a clearer idea and in a simpler way. Most of the times, UML makes a transition in code with OOP (Object-Oriented Programming) and this is because of the big comparison between a diagram and an OOP application. That’s where GRAPS comes into play.
General Responsibility Assignment Software Patterns, by the short name of GRASP, is a set of patterns and responsibilities that every programmer and designer should know. The importance of these patterns is that they help us to make responsible software. By responsible I mean that the approach to the code is with obligations to perform tasks or to know information.
The list of the 9 GRASP patterns are the following:
- Information Expert
- Low Coupling
- High Cohesion
- Pure Fabrication
- Protected Variations
To understand each one of them I recommend taking a look at Kamil Grzybek’s blog post which explains in a very detailed way each pattern.
The importance of GRASP and MVC topics is to start to move forward when finishing a well-made UML diagram. With these and other diagrams one can model a system with such a great scope and structure that coding becomes just another step and not the biggest obstacle in software development.
There are no limits on what you can achieve with your life, except the limits you accept in your mind