Why use the UML? (1) Many people think in pictures. (2) You'll be able to share your ideas with others. (3) A picture can express a lot of words. (4) UML is becoming valuable in the job market. (5) You will think of more ideas and be able to spot bad ones.
There are four ways people use the UML:
Table
| Purpose | Tool |
|---|---|
| A rough sketch of an idea. | Chalk board. Pencil and paper. Hint. Leave boxes open to the right and bottom. |
| A blueprint of some software | A drawing program like Dia or Visio. Some word processors can also do graphics. |
| Generating a program | A CASE tool like Pegasus or Rational Rose |
| Required documentation | Either use a CASE tool to reverse engineer the diagram from code, or a drawing tool. |
As a rule: keep it simple. Omit things on a diagram that are neither important nor interesting.
Only do a diagram if you can see some value for you or your client. For example it is worth planning the classes you will be programming and how they interact before you start coding them. You can often earn credit in CSE classes by drawing UML diagrams to explain what you have done. Many clients/companies have standards that require you to document your code to help other maintain it.
Here is a simple model of a person with a name, address, and age:
For example a triangle has three Points....
Notice that instead of the C++ 'string name;' we write 'name : string'. More, we omit the word void.
Notice that private items (like the vertexes above) are marked with a minus sign. Public items are marked with a plus sign.
The constructors are underlined to show that they are not applied to objects. Some people omit the underline. You can also write <<constructor>> if you want to be very correct.
You don't have to show all the details unless you need to. You can omit the underlining of constructors. You can even omit constructors unless they are special in some way. Any of the two lower compartments can be left out. For example the following are also pictures of the Triangle class with details suppressed.
We can be more precise and say that a Triangle must have three Points called vertexes:
You can sketch a class in the UML quicker than you can write a C++ class.
The rules are simple: (1) use a box, (2) underline the name of the object and its class -- name:class, and (3) put attributes in a compartment under the name. Here for example is a simple Counter class plus object diagrams of of an object the_count (perhaps from Sesame St.?) before and after the count operation is applied to it.
Suppose we've defined a class called Counter:
Then a recently constructed Counter object called the_count.
The same object after being sent a count() message
Some example code is in [ counter.cpp ] for example
Notice -- the rounded corners on the activities, the diamonds where decisions are made or resolve, and the use of square brackets about conditions -- [ condition ].
This notation can be used to show that a class has a data member or field. It is called composition.
For an example, here is the code for a class called Period as part of an application modelling this campus:
class Period {
private:
Time time[2];//start and finish Times
vector<Day> days;//Days in the week
};//end class PeriodHere are a couple of valid diagrams that show that each Period contains a pair of times and variable number of days.
A simple composition with a multiplicity of one indicates a simple data member in the C++ class. A fixed multiplicity suggests an array. A range of multiplicities or an asterisk suggests a more complex data structure such as a vector, list, or set. If the order is important, then the constraint "{ordered}" should be added.
Here is a link to my local documentation on the UML: [ uml.html ]
In your future career you may need a text book. If so try: Martin Fowler and K. Scott, "UML Distilled: A Brief Guide to the Standard Object Modeling Language," 3rd Ed., Addison-Wesley, 2005.
. . . . . . . . . ( end of section Experiments on the UML) <<Contents | End>>
. . . . . . . . . ( end of section Review Questions) <<Contents | End>>
. . . . . . . . . ( end of section A Beginners Guide to The Unified Modeling Language (UML)) <<Contents | End>>