UML, or the standard doodling methodology, part 1

I think I've heard you bawl from boredom all the way from your place to mine. Don't worry, I'll try to keep it light.

In order to advance into more specific designs however, it is crucial that I teach you basic communication tools so that we can understand each other. And that is pretty much what UML does.

1.Why UML?
What does UML stand for? Unified Modeling Language. Which means its primary aim is to create a form of communication universally understandable. Of course, clarity is also very important, and it is indeed quite clear, but the main objective is that if I give you a software model in UML, you will understand it too.

You don't have to use it, of course. You can make up your own way of modeling, and that will work just fine; especially if you're in a private company with private projects. But you can't expect anybody to know your private modeling language if you show them a diagram.

2.What does UML offer?
UML is not a form of modeling or developing software, but rather a way of representing it. Like a normal language such as English, you think of what to say, the language simply expresses it!

They generally work as diagrams, with states and relations that lead to them. There are three main kinds of diagrams:

  • Structure: what is needed in the program?
  • Behaviour: how must the program react?
    • Interaction: how must the structure react to itself?
There are many kinds of diagrams, and each is unique in its functions; however for the sake of simplicity and shortness I shall only describe the few that you are most likely to use.

In this first article, I'll describe two Structural diagrams.

Class diagram: extremely important, especially in Object Oriented programs! This defines every class' attributes and methods, and how is every class related to each other.

The class: is divided into the name, the attributes and the methods. The last two can be public (+), private (-), protected (#) or derived (italics), and they and their parameters have types.
Instance relations:
  • Association: general way of telling one class has a relation with another. It's specified in the line.
    • Aggregation: a class contains other classes. The container is independent from the contents.
    • Composition: a class contains other classes. If the container disappears, so do the contents.
Association: a person buys a book
Composition: you destroy a computer, you destroy its CPU
Aggregation: Destroying a house doesn't mean you'll destroy a table that's inside (you can get it out)
Class relations
  • Generalization:  Who is the class' ancestor, from whom it inherits attributes and methods?
  • Realization: a client executes a behavior specified by the supplier.
Realization: a ballerina dances according to a coreography
Generalization: a student is a human (and has human traits)

Package Diagram: simplified from the class diagram, packages contain various classes, and such packages interact with each other.

In the next post, I'll end the tutorial talking about Behavioural diagrams.

1 comentario:

  1. Ben resumit :3

    No sé si tens a mà els apunts de l'assignatura d'Enginyeria del Software, però si no els utilitzes potser et podrien ajudar. Fa poc més d'una setmana m'examinava d'això!

    Que vagi bé la tornada al cole! ^^