What the heck is UML?

UML is the Unified Modeling Language. Personally I don’t know why it’s called a
Language, because it’s not really a language persay. The Unified Modeling Language
was formed in attempt to unify the best (or most popular in this case) methods in Object-
Oriented Analysis and Design. Those concepts come from the leaders in the field of OO:
Grady Booch, James Rumbaugh and Ivar Jacobson. The different models are pulled from
each of the individual methods and bring in a contribution from each one. For example,
the class model is very similar to OMT or the Rumbaugh method. The Use Case Model
is brought in from Ivar Jacobson and the implementation model is from Booch. Some
models, such as State and Sequence, are a combination of a few methods, taking concepts
from each of the methodologies and even adding some new concepts.

Why do I need to use UML when I can just construct all the GUI and classes in my
IDE Environment?

Probably this is the largest excuse for not using Object Modeling, but the truth is, there is
something to be said for modeling your software before you actually code it. Just try it
once and see if your design doesn’t come out 100x better. There is always that reluctance
to see the big picture up front, but it will make a difference in the long run and probably
shorten your development cycle.

My project is rushed. I don’t have time to document everything, my boss wants it

tommorrow! This UML stuff is a waste of my valuable time!

Again, a good up front design will actually shorten the development cycle, give you an
idea of the resources you need, and how to break up the project. It will also make the
amount of support you do in the long run a little easier (although support is job security
;-) )

Why UML, why not just pad and paper? I often have the whole design in my head
anyway.

It’s nice to have a standard model to work from. This way if you have a team of
developers, everyone on the team now speaks the same language. A design in your head
doesn’t do the rest of the people you work with any good.

Ok, now that we’ve addressed why you should bother learning UML in the first place,
below is an introduction to what UML is all about:

The Class Model

The Unified Modeling language has several models that help you describe the software
system you are trying to represent. Each model represents a different aspect of the
software description. The Class Model is the static architectural representation of your
software and often a good starting point. It allows you to see the overall object structure
of the software system. Below is a class represented in UML:

Fig 1.

The Account is the name of the class representing the definition of an Account. The
Value is an attribute of the Account representing the amount of money in the account.
Withdraw and Deposit are methods to

Add/Delete money to the account. The – and + signs are visibility indicators used to
show encapsulation. The minus says that Value is a private member of class Account and
can only be seen by methods of the Account class. The plus represents public members,
so WithDraw and Deposit can be accessed outside the Account class. The void after the
colon are the return types from the class.

UML Can also represent the relationships between classes:

Fig 2.

Inheritance is represented by a triangle and

SavingsAccount is a subclass of Account, inheriting all of the Attributes and Operations
of the Account Class. Aggregation is represented by a diamond. A Bank has many
Accounts. The asterisk near the Accounts represents many and the 1 near the bank
represents one.
Anotherwords there is a one to many relationship between Bank and Accounts.
Aggregation is a whole-part relationship. A Bank has Accounts, so the diamond is
positioned near the container to represent the accounts are the parts of the bank. Noticed
we also added another subclass CheckingAccount to represent another type of account in
are system. The below diagram shows that our bank has many accounts some of which
are savings accounts and some which are checking accounts.

Fig 3.

A system which represents a group of related classes can often be placed together in what
is called a package. Below is the representation of our Banking System as part of the
Banking Package. Packages help us to organize our class diagrams and represent them at
a higher level.
 Fig 4.

Packages can group together libraries, gui objects or other related classes. Note the
<<subsystem>> indicator under the banking package. This <<>> indicator is called a
stereotype. Stereotypes are used profusely throughout UML and basically are a way to
enhance the description of any UML model component. For example Attributes,
Operation, and Classes can all have stereotypes to describe further the category they are
in. The dotted arrow is called a dependency. It is used to show that one UML Element
depends upon another. Dependencies can be used to describe the relationship between
classes, packages, or components.
 Fig 5.

There is much, much more detail that can be described with the UML model, but we are
only giving an introduction here, so we will move on to another useful model called the
sequence diagram.

The sequence diagram describes the flow of messages being passed from object to
object. Unlike the class diagram, the sequence diagram represents dynamic message
passing between instances of classes rather than just a static structure of classes. In some
ways, a sequence diagram is like a stack trace of object messages. Below is a sample
sequence diagram

Fig 6.

The Sequence diagram allows the person reading the documentation to follow the flow
of messages from each object. The vertical lines with the boxes on top represent instances
of the classes (or objects). The label to the left of the colon is the instance and the label
to the right of the colon is the class. The horizontal arrows are the messages passed
between the instances and are read from top to bottom. Here we have a customer (user)
depositing money into MyAccount which is an instance of Class SavingsAccount. Then
MyAccount object Validates the account by asking the Bank object, MyBank to
ValidateAccount. Finally, the Customer Asks the ATM object for a Receipt by calling the
ATM’s operation GetReceipt. The white rectangle indicate the scope of a method or set
of methods occurring on the Object My Bank. The dotted line is a return from the
method ValidateAccount.

Another useful model of UML is the Use Case Diagram. So what is a Use Case you may
ask? Personally, I feel a use case was a way for UML people to introduce structured
design into an object design model, but who am I to judge? Anyway, a use case is a
bubble describing a particular an activity that a User Performs.

Each Use Case could be thought of as having a sequence scenario behind it. A Use Case
is acted upon by a user or actor. Below is a use case for depositing a check

Fig 7.

The Ovals represent the different actions of each of the actors. The Customer Deposits a
check, the ATM prints the receipt. Note that Use Case don’t represent any sequence or
time events, they just tell you the list of cases and how each user acts upon that case. Use
cases can be more descriptive by using extend and uses relationships. Below is an
example of how the Print Receipt Case is extended. An extended case is a subtype of the
existing case. Here we extended case Print Receipt in two ways: (1) Print a Receipt on
the screen, (2) print the receipt on a piece of paper. Both cases are still printing a receipt
so they are of the same type.
Fig 8.

Also we have a “uses” relationship. Below a “Deposit Check” Case consists of the
subcases Validate Check and Transfer Check to the Account. These cases are not of the
type Deposit Check, but are tasks that compose the entire task of Depositing a Check.
Fig 9.

State Diagrams are another model in UML that allow you to actually describe the timing
taking place in your system. State Diagrams have been around a long time in logical
design and have proved very useful for concurrent and real-time systems. A state
diagram consists mostly of states and transitions. It often represents the different states a
class can undergo and the events that effect a change in state in the class

In our ATM machine example the key entry of a users password can be represented as a
set of states:
Fig 10.

The initial state is represented by a small black circle, wait states are represented by
rounded rectangles, and the final state is represented by a small black circle surrounded
by a white circle. Transitions are the arrows going from one state to another. A
transition is triggered by an event. An event can be a key press, mouse movement or a
menu selection for example. The event is an activity either from the user or the system
that causes a change of state. In the example above, # pressed and Cancel pressed are
examples of events from the user. Usually an event causes some sort of action to occur
when the system is changing state. The action is represented by the slash followed by the
action, e.g. /Display. Display is most likely an operation in a class to tell the screen to
display the key being pressed. Another characteristic of transitions is known as a
condition. Conditions can be coupled with an event to determine if a change of state
occurs. In our example, in order to go from the ‘Start’ state to the ‘NextNumber’ state a
key must be pressed (the event) and the first digit must be greater than 0 (the condition).
Conditions are represented in UML surrounded with square brackets [ ].

Another model coming out of UML which I often think of as the brother to the state
diagram, is the Activity Diagram. The Activity Diagram in some ways is like a flowchart
with states. With the activity diagram you can follow flow of activities in your system in
the order that they take place. Below is an activity diagram for making a deposit.
Fig 11.

Note the activity diagram looks like a cross between a state diagram, a use case diagram
and a flowchart. Activities look similar to states but they are a bit more rounded. They
are stateless in that they take place and automatically transition to the next state upon
finishing. The diamond is a conditional branch that determines which activity to
transition too based on a condition and it is also stateless. In our example, if the
deposited check is valid, a receipt is printed. Otherwise, if its not a valid check then the
activity is to reject the deposit. The solid black bar is a synch state. This state simply
synchs up existing activities so that they transition to the next activity at the same time.

Well this concludes part one of the beginning of our understanding of UML. In Part II we
will describe some more UML models that you can add to your design arsenal.