Let’s Model!

Picture of that shooting
Dany. Photo by me.

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 Tower of Babel. Image from Wikimedia Commons

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.

Resultado de imagen para old chinese manuscript
1500 years old Chinese manuscript, photo by Wikipedia . Since Chinese was simplified (Unifying all the different most used dialects into one language), the people who can read Chinese is able to read documents which are even 2000 years old!

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.

State 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.

Symbol

Initial state – Use a black filled circle represent the initial state of a System or a class


State Symbol

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

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

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

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.


Notation

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

Final state – Use a filled circle within a circle notation to represent the final state in a state machine diagram.


Self transition

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

  1. Identify the initial state and the final terminating states.
  2. Identify the possible states in which the object can exist (boundary values corresponding to different attributes guide us in identifying different states).
  3. Label the events which trigger these transitions.

Package Diagram

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

Meaning:

Different notations

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.

Deja un comentario

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s

A %d blogueros les gusta esto: