A Quick Guide to The Unified Modeling Language (UML)

This answers some Frequently Asked Questions about a popular notation.

What is the UML

The UML is a common diagrammatic language developed by Rational [ http://www.rational.com/uml/ ] with the support of all the big computer companies. It is now maintained by the Object Management Group. Rational was bought by IBM who now provides many tools.

Why use the UML

Many people think in pictures and a picture can express a lot of ideas in a quick way. UML is a standard way to draw various views of a piece of software: the user's view, the architecture, the internal structure of the software, the source code, and the hardware involved.

If you become familiar with the UML you will find that you will be able to think of more ideas and also to work out how good an idea is. You'll be able to share your idea with others.

UML is becoming valuable in the job market.

When to Use the UML

Use a diagram when you need to think about something, share ideas with someone else, save an idea for the future, show management the work you've been doing, when you can't find a bug in code, or when your teacher/adviser requires it.

You can use the UML to make rough sketches, to express a blueprint of the code, as input to a code generator, or as required documentation of a finished project.

Keep it simple -- only use the UML when you need it. Draw diagrams that give most value. For example, don't draw a deployment diagram unless the software is running on many machines. Don't draw a component diagram when there is only one component -- the main program. Don't worry about packages until you need to have 10 or more classes.

The UML helps with these tasks:

Understanding and planning Procedures	Activity Diagrams
Understanding what user's want to do	UseCase diagrams and Scenarios
Understanding the organization and its problems	Domain
Working out detailed object-oriented designs	Sequence and Communication diagrams. Start analyzing Scenarios with a SSD of one of them.
Working out an algorithm for a complex operation	Activity Diagrams
Designing a data base	Class and Domain models
Designing the software	Class, Object, Activity, and State diagrams
Planning and describing the modules in a complex project.	Component diagrams
Tracking the source, data, and executable files	Artifact and Deployment diagrams
Planning how to use the hardware	Deployment Diagrams
Organizing the work in a project into folders	Package Diagrams

In all diagrams, never draw more detail than you actually need. Omit things that are not important or are uninteresting.

Notice that you often have to add comments or text to a diagram using English, Mathematics, or Java/C++ syntax.

. . . . . . . . . ( end of section When to Use the UML) <<Contents | End>>

How do you draw diagrams in the UML


(howtodraw): First: only draw a diagram when you need to: to clarify your thinking or to record for the future what you've decided.

Second, UML is a flexible set of diagrams. Here are some ways to use them:

Purpose	Tool
In class or working something out by yourself	Draw roughly and quickly by hand with pencil, eraser, and paper.
Working on a problem with others	Use a chalk board with/without post-it notes. Record with a camera.
In a meeting	A laptop+tool+projector.
Preparing a simple diagram for handing in or presenting to others	Use a simple Graphics tool like Dia or Visio. PowerPoint, Word and Corel WordPerfect can do adequate diagrams.
Working on a Complex Project or in a team.	Use a Computer Aided Software Engineering (CASE) tool like Rational Rose. If the team doesn't have its own space look into Web repositories like Google Groups to hold the files.

UML Diagrams

What does the User Want


(UseCase): A use case names a type of user (actors) and something that they want to do (usecase). An actor can be a human, a device, or a piece of software but it must not be part of the system we are producing. The use case describes how an actor achieves a specific tangible goal. The important part of a usecase is the description of the steps that the actors take to achieve their goals and how the system appears to respond to the actors actions. Use any tool to write these Scenarios.

The UML provides a diagram that is good for summarizing a collection of use cases. The actors are drawn as stick figures. The things that they want to do are shown as bubbles. Notice that the icons are drawn just like in the next diagram.



Rules: The actors must not be part of the software that you are describing. They are outside it and use it. They can be people, machines, or other software. Usecase names must describe some activity that an actor wants to do. A simple rule is to start each usecase name with a strong verb: "Review grade", "update record", "Get money from ATM", and "Control nuclear reactor" are good names. "Grades" and "do email" are bad ones. Avoid having a large number of overly simple usecases that can be covered by one simple one: Instead of "add record", "change record", "delete record", "print record",.... etc use "Access and update record", for example. Use Scenarios to show this detail.


(Scenarios): Each use case will need to be described in more detail before you work out how to implement it. A scenario describes, step by step, how a particular user gets what they want from the computer. It says what the user does and what the computer does as a result. However it does not spell out all the details -- things like whether there is a tool bar or the color of the screen is best left out. It also pays to be very specific about the particular user you are describing.

Similarly, at the start of a project only list the obvious and straight forward scenarios. Add special extensions to handle the exceptional cases later.

Student Enrolls in Class:


1. Jo Doe goes to the phone and identifies his/herself.
2. The computer gives a list of things that a student can do to the system.
3. Jo asks for a list of sections in a course.
4. The computer shows Jo the sections he or she is interested in.
5. Jo selects one section to enroll in.
6. The computer records the enrollment and confirms that Jo is enrolled.


(extensions): It is also possible to record the things that can go wrong (extension points) and provide alternate scenarios (extended scenarios) for handling them.

What does the User Think its all about

Many users and usecases share some common ideas or concepts. These form the basis for classes that the software will need. It is also possible to clarify how these classes of objects are related. The links between them define what interactions are possible between different classes of objects. The whole plan is called an architecture.


(Domain): The trick that makes object-oriented designs easier to work with is that we use classes in the code that reflect the world in which our clients and users exist. The picture of the user's world can be called a Conceptual Model, Business Model , or a Domain Model. It is an excellent source of ideas for classes inside an object-oriented program. It is also the perfect model to start the design of a data base.

Both Domain and Architecture models are a collection of boxes which contain just the names of the types of objects you expect to be in the software. Show their interconnections as links between the boxes. You can add more detail if you want -- role names and multiplicities can help clarify the meanings of links.



It sometimes clarifies a diagram if you list the attributes of some of the classes in a domain model or architecture. In a complex project you tabulate the attributes for each enity in your domain model -- the result is called a Data Dictionary.

These diagrams are also drawings of the data base. In some projects you may have to use a more complex notation called an Entity-Relation-Attribute diagram instead.

In a database, domain, or conceptual model avoid all verbs! The names in the boxes should be names of real entities. For example, the name "Enroll" is not a good name for for a box. It describes an action. "Student" is a good name. "Enrollment" is also a good name. Actions appear in usecase scenarios (see above) and operations in sequence charts, collaborations, and class diagrams (see next).

Which Object does What

Thinking about how objects work together to do something for the user is important. In other words we model the Interactions between the objects in the software. UML Interaction Diagrams are Sequence diagrams and Communication diagrams. Both diagrams help you design interactions. Architecture summarizes the result.


(Architecture): An architecture is a picture of the types of objects in a system plus a list of their attributes and operations that these objects will perform to meet the users needs. Add operations to classes at the same time as you sketch Sequence and Communication diagrams.


(Sequence): In a Sequence diagram you show the users (stick figures) and objects at the top. A vertical line goes down from each of these. Arrows show one object sending a message or calling a function or operation that belongs to another object. A big X indicates that an object deletes itself.

What happens in the software when student Jo Doe (jo) drops a section(s):




(Hint when designing): A System Sequence Diagram or SSD is a good first stp towards a design. It shows all the steps in one scenario as messages flowing into the complete system under design. You typically have 1 or more actors and a single ":System" object. Draw one when you start to analyze a scenario to prepare to design objects that implement or realize the scenario. Then draw a Sequence or Communication diagrams for each step in the SSD.


(Communication): In a Communication diagram actors and objects can be anywhere and sequence is shown by numbering the messages that are sent. These show the overall communication pattern but make the sequence of events less clear.

What happens in the system when Jo Doe adds a Section



Note -- in the above diagram I have used the simple numbering scheme used when UML was first invented.

In the more complex CASE tools the Class diagrams and these diagrams are linked together: adding an arrow on a Sequence or Communication diagram helps you to add an operation to the class diagram. Or when you add a new message the CASE tools can list the possible messages (operations or functions) you might want to send.


(Collaboration): This is the old name for what is now called a Communication diagram. They were more complicated, see [ uml.collab.gif ] for an example.

How are the classes organized


(Class): The UML can express most things you can code in C++. A single box represents a class of objects. The name of the class is at the top. In the next part of the box list the data each object contains. In the third part of the class box list the operations (functions) that an object can carry out.



Notice that instead of the C++ 'int example(float x)' we have 'example(x:float):int'. Also omit the word void in all UML diagrams!

Note: you can sketch a UML class quicker than you can write a C++ class.

Many classes can be put on one diagram and connected together with associations:



Here are all the links commonly used in a class diagram:



C++ classes have data members that are part of the state of the whole object. In the UML we can use the dark diamond to indicate that the class is composed of the components. The UML has two or three ways to show this. For example, here is the code for a class called Period:

          class Period {

                  private:

                          Time time[2];

                          vector<Day> day(5);

          };//end class Period

Here are a couple of valid diagrams that show that each Period contains a pair of times and up to 5 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 put at the end of the link. An vector is an ordered collection of variable size.

If the data is accessed via a pointer then a simple arrow should be used to indicate this:



Note: older books used to put an uncolored "Aggregation" diamond at the other end of the association to show a pointer.

Note: If there is a vector (or list etc) of pointers then use the arrow with a variable multiplicity.


(Object): It helps to be able to draw objects as well as classes. The rules are simple: use a box, underline the name of the object and its class, and 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 before and after a particular operation is applied to it.

Class Diagram of Counter



A recently constructed Counter object called the_count.



The same object after being sent a count() message



How and When does an Object change


(State): Often we need to think about how an object changes. Class diagrams give us a static picture of an object and its relations to other objects.

Computer Science developed a theory of automatic machines (automata) that lead to the StateChart notation. This is part of the Unified Modeling Language. It lets us show when and how an object changes its behavior. Each change of behavior is modeled as a change of the objects internal state. The diagram shows these and the allowed changes between them. For example a Student starts out as a Person and then can evolve to be an Undergraduate or an Graduate. Undergraduate can become a Graduate.



Each state is shown as a rectangle with rounded corners. Starting and finishing points are shown as black blobs. Changing state means the object changes it behavior. The change (or transition) is shown as an arrow. Each arrow should be labeled with a mutator method or operation. So the arrows show what operations can be called in a given state, and show you how the operation changes the possible behaviors. Initially we can omit the labels and one state can be used as an abbreviation for a whole pattern of behavior:

You can add a lot of extra information to a State chart -- the operations that trigger changes of state, the conditions governing which transition to follow, and what operations are executed when entering and/or leaving a state.

How is a complex problem solved? What is the Algorithm?


(Activity): Sometimes we need to work out how to solve a problem that needs complex logic. UML State charts have evolved to allow us to draw Activity diagrams that look like old fashioned flowcharts. Below is one form of binary search for a target in a sorted array or vector of items:





[ uml.act.dia ]

How is a complex architecture organized?

When we have a lot of classes (more than 20 say) we need to group them. We would start to organize our code, diagrams, and documents into folders (or directories). In the UML we can also organize our organize our thinking into "folders" called packages(See Package below). We can also group our classes into larger modules called components (see Component below) ready for people to use. A component is plug-compatible: the user knows that it can be replaced by a similar component. A Pckage is more of an aid to the software engineers developing the software. When we code components we produce artifacts(see Artifact below). This is the third way that UML supports organization.


(Component): A component is very like a class. But they are designed to provide certain interfaces and use others. It is a plug-compatible piece of software that often contains many classes. There is a lollipop notation for showing how components are plugged together. Here is an example:



The lollipop indicates the interface between the component and its clients.


(Artifact): In any real project there will be hundreds of files involved. These used to be shown as components but are now documented as artifacts.



The above diagram treats each source, object, and executable file as a separate component. Notice the stereotypes that tell you the kind of artifact that I'm using -- an executable program, a file, a document and so on. Here is a list of standard ones:

Stereotype	Meaning(UML2)
<<file>>	A physical file in the context of the system developed.
<<script>>	A script file that can be interpreted by a computer system.
<<executable>>	A program file that can be executed on a computer system.
<<library>>	A static or dynamic library file.
<<source>>	A source file that can be compiled into an executable file.
<<document>>	A generic file that is not a source file or executable.

We can also show where these artifacts are stored on our computer hardware.


(Package): An icon that looks like a folder. It refers to a collection of other icons and diagrams that are said to be inside the package. In effect it acts and looks like a folder in a GUI for an operating system or a directory. Here is a classic layered architecture that separates work done on the user interface from work done on the data base, etc.



Packages are a way of organizing large projects. We can put use cases, classes, components, artifacts, ..., and even packages inside a package. The dotted lines with stick arrowheads show dependencies. They show that parts of one package depend on the things in the other package. If we change something at the "arrowhead" end then we may be forced to change things at the other end as well. These couplings should be minimized when possible.

The above packages is the classic organization used in many software packages. The user interface decisions are worked on in the top package, and kept separate from understanding and solving the user's domain problems. Separately, at the bottom, we can work on how to use the database ("Persistence") and how to use other servers ("Network").

What Software is running on which device


(Deployment): Use a deployment diagram in the UML to show the hardware that your software uses. You can add information describing operating systems, language interpreters, or details (CPU type for example) if this is valuable to know.



When a component of a software system is completed it becomes an artifact and can be deployed onto a system that can use it. We show this with a deployment diagram that also show the artifacts.

You can show what software runs on a node in a deployment diagram by listing it under the node(UML 1) or inside it(UML2).

You can also make the node bigger and draw the artifact inside the cube. This is a nice way to show how web-based systems work because these typically depend on a browser in the user's PC, server software on a web-server, and a separate data base running on a special data base box.

Here is one way that one of my web applications was deployed until recently:



. . . . . . . . . ( end of section UML Diagrams) <<Contents | End>>

Glossary

1. algorithm::=a detailed and precise description of how a computation is carried out.

2. artifact::=`A software component (typically a file) that can placed (deployed) onto a system and be used their`.

3. component::=a module, a software chip, some code that can be compiled separately from other modules and tested on its own. It provides and uses interfaces.

4. CASE::="Computer Aided Software Engineering".

5. usecase::=An activity that a user wants to do and which the computer can help.

   More

   This is a quick overview. There is a lot more to learn about the UML. Here is a link to some local documentation on the UML:

    	http://www.csci.csusb.edu/dick/samples/uml.html

   [ uml.html ]

   In your future career you may need a text book. If so try:

   ---

   1. Martin Fowler
   2. UML Distilled: A brief Guide to the standard object modeling language
   3. Addison-Wesley Longman, Boston MA 2003 ISBN 0321193687 CR 0408-0893

   ---

. . . . . . . . . ( end of section A Quick Guide to The Unified Modeling Language (UML)) <<Contents | End>>