As a photographer, I can tell you that working with models is way easier than shooting with normal people. Once, I had a shooting with two girls for some social media advertisement. The shoot was amazing, we were on an awesome location and the production team was just good vibes. However, one of those girls was indeed a model, and the other one not. Shooting the model was easy, we got a lot of pics in a very short amount of time; shooting with the other girl who was unfamiliar to this, was a little bit more difficult. We got the job done, but it was easier and quicker working with the model. Well, the same goes to the software: «Working with models is going to make your life easier and your productivity will increase».
The software engineers were aware of this, but there was a little problem: with the born of the object oriented paradigm, a rush of new modeling languages came in, just like there were several network protocols. The world of computers needed a standardization so the developers could integrate with different teams and get a common language to communicate their ideas.
James Rumbaugh, Grady Booch and Ivar Jacobson decided to merge various existing modeling languages into one common standard; this way, UML was born. The Unified Modeling Language is a graphic language that is intended to represent this:
- Individual objects (basic elements)
- Classes (Combining elements with the same properties)
- Object Relationships (Hierarchy and behaviors, communication between objects)
- Activity (Complex combination of actions / behavior modules)
- Interactions between objects and interfaces (even human interaction)
UML is a multimodeling Language, meaning that you can make different models from the same thing, it depends on which level of abstraction you want to represent something.
UML has 13 different types of diagrams. We are going to categorize them by their functions.
Structural diagrams: This type of diagram, makes emphasis on the elements that may exist into the modeled system.
- Class diagram
- Component diagram
- Object diagram
- Composite Structure diagram
- Deployment diagram
- Package diagram
Behavioural diagrams: Describes what has to happen into the modeled system.
- Activity diagram
- Use Cases diagram
- State diagram
Interaction diagram: This are a subtype derived from the behavioural diagrams, centered into the control and data flow into the system.
- Sequence diagram
- Communication diagram
- Timing diagram
I bet you are into this right now so, let me explain some diagrams.
This one is used to model the dynamic behavior of a class in response to time and changing external stimuli. We can say that each and every class has a state but we don’t model every class using State diagrams.
Initial state – Use a black filled circle represent the initial state of a System or a class
State – Use a rounded rectangle to represent a state. A state represents the conditions or circumstances of an object of a class at an instant of time.
Transition – Use a solid arrow to represent the transition or change of control from one state to another. The arrow is labelled with the event which causes the change in state.
Fork – Use a rounded solid rectangular bar to represent a Fork notation with incoming arrow from the parent state and outgoing arrows towards the newly created states. The fork notation is used to represent a state splitting into two or more concurrent states.
Join – Use a rounded solid rectangular bar to represent a Join notation with incoming arrows from the joining states and outgoing arrow towards the common goal state. use thise join notation when two or more states concurrently converge into one on the occurrence of an event or events.
Composite state – Use a rounded rectangle to represent a composite state. A composite state is a state which has an internal structure consisting of a set of states, transitions and other components.
Final state – Use a filled circle within a circle notation to represent the final state in a state machine diagram.
Self transition – Use a solid arrow pointing back to the state itself to represent a self transition. There might be scenarios when the state of the object does not change upon the occurrence of an event. Use self transitions to represent such cases.
Steps to draw a state diagram
- Identify the initial state and the final terminating states.
- Identify the possible states in which the object can exist (boundary values corresponding to different attributes guide us in identifying different states).
- Label the events which trigger these transitions.
Package diagrams are used to simplify complex class diagrams, you can group classes into packages. A package is a collection of logically related UML elements.
Package diagram follows hierarchal structure of nested packages. Atomic module for nested package are usually class diagrams. There are few constraints while using package diagrams, they are as follows.
- Package name should not be the same for a system, however classes inside different packages could have the same name.
- Packages can include whole diagrams, name of components alone or no components at all.
Check the syntax
We need a way to represent code dependencies, this is what we have to do.
There are two sub-types involved in dependency. They are <<import>> & <<access>>. Though there are two stereotypes users can use their own stereotype to represent the type of dependency between two packages.
<<import>> – one package imports the functionality of other package
<<access>> – one package requires help from functions of other package.
Now that you know how this works, check this example:
This is a little overview on how UML is used to model the systems. This is a powerful tool for project development and of course, if you want to be a good software engineer, you must have to have understanding on this diagrams. If you want to learn more, there are always books and wonderful websites with tons of knowledge waiting to be read.