UML
Created | Updated Jan 28, 2002
UML is a notation used with object-oriented methods to make pretty pictures of systems. It is usually used for IT systems, but is not limited to them.
Where did it come from?
Once upon a time, software projects went wrong. Then SSADM was invented to fix it. Later on, object-oriented methods were created to fix SSADM.
The problem was, several rival methods appeared. This meant people didn't know which one to use. So some of the people who had created the various earlier methods worked together to create UML , the Unified Modelling Language. This will cause all future projects to come in on time, hit their budget, work and be exactly what the people ordered :) There is still some disagreement, or choice, as it is also known.
The Object
The basic concept of modelling in an object-oriented way is to represent the system as a set of interacting objects. This can be something concrete, like a car, or abstract, like an event such as a conference. Each object has a state (colour, registration number, make, model etc.) and events (accelerate, brake, fill with petrol etc.)
When Are They Appropriate
More diagrams will always help a little, if they are the ones that help you to understand. If you are developing in an OO way, the UML diagrams will tie in nicely. If you are working in a structured way, or a structured language, it can still help, as you still have data and functions - which == a class still.
Use Case Diagrams
A use case diagram for a restraunt:
O /----------\ O
-+- ----------- | | -------------- -+-
/ \ \----------/ / \
customer order food waiter
\ /
\ /---------\ /
\------| |------------/
\---------/
pay bill
The little stick figures are "actors" , and the ovals are "use cases". The waiter and customer are both connected to the use cases because in all cases, they are both involved. If there was an "eat meal" use case, only the customer would be linked. However, a restraunt system is unlikely to model the customer eating their meal, so this should not be shown on the diagram.
Collaboration Diagrams
customer waiter
| |
|-| |
| |------------>|-|
|-| wanted food | |
| | |
|<-------------|-|
| expected time |
This diagram shows how different classes interact with one another. Here the customer sends information about a food order, and the waiter replies with the expected time. The boxes on the vertical lines represent which class has control at any one point.
WIP - last updated 11th July 2001
See also Executable UML. The author has made a few helpful comments about the article.
