UML, or the standard doodling methodology part 2

In the second part of this tutorial I'll describe the basic behavioural diagrams.

State diagram: a more sophisticated version of a state diagram. Basically, the states are places where a question must be asked, and the transitions are the answer that is given. A non-UML state diagram supports this structure UML contemplates more elements than that. For instance:

  • Filed circle: start of the system.
  • Hollow circle: end of the system.
  • Arrows: transitions. The names included are what the transitions do, in brackets. What comes after an / is a conditional (optional).
  • Rectangles: states. You can write the name and the actions taken in that state, dividing it with a line.
  • Thick lines: denote forks or joins

An example provided by Wikipedia would be:

The simulator will run when asked to or started. You cannot stop the
simulator when paused or retrieving data. Stopping means the end of the

Sequence diagram: they describe interactions between two or more elements in a certain timeline, telling what actions they delegate to each other in specific timemarks. The elements are:

  • Timeline: represents the life of each element
  • Method box: boxes at the timeline, represent a single process being executed
  • Sync calls: arrows with filled heads.
  • Async calls: arrows with stick heads
  • Return messages: dashed arrows

An example could be a checkout. For the sake of understanding method boxes, in this case the ticket will be printed judging from the last operation, and is optional:
Notice that everything is asynchronous, as human interactions tend to be (pesky humans...), and that the proces are more or less scaled in the timeline (the cashier will take their time checking every item's price, the costumer will need time to look for money in their wallet).

Use case diagram: Okay, this is a notable one, as it introduces the concepts of actors. Without further ado, the elements are:

  • The actors: external to the system, these are the people that interact fairly directly with the system in design.
  • The system: how is our system going to react to the actors?
    • Use case: processes that can be provided inside the system as long as the actors trigger them
    • Relations: how can an actor interact with a system's use case?
      • Communication: unidirectional association actor - use case
      • Extension: we can extend a use case from another
      • Use: a use case includes another use case in its execution
      • Generalization: inheritance.
Again, Wikipedia provides us with an example:

This is all I had in mind about teaching UML. Perhaps I'll talk about more models in the future or will go into greater detail about the ones I've already explained; but for now this will do. 

I wish to insist that these tools help greatly in the designing stages and that you should grown used to them. For example, I am considering redoing all of a design of mine because I could not bother to grab a pen and start drawing diagrams the first time around, and just went going according to what I had in my mind, which shifted every time a problem arose.

I hope you've found this little tutorial of aid and interesting. Until next time, rock on!

No hay comentarios:

Publicar un comentario en la entrada