Posted 21 years ago on 3/17/2003 and updated 12/12/2008
Take Away: This introduction to the UML covers symbol usage, definitions, and creating diagrams. The UML standardizes what diagrams with what symbols for what situation. The UML is complete with diagrams for analysis, design, and coding. Use use case diagrams to document how users (actors) use a system (a use case). Use class and object diagrams for the design and coding of a system. A class is the prototype for an object. An object has attributes (properties) and the current values of those properties is the current state of the object.
The UML is an architecturally centric methodology for documenting object oriented systems. The UML brings together and defines several different and complimentary methods for creating views (diagrams) of a system. The types of diagrams include both non-technically oriented diagrams such as Use Case and Deployment diagrams as well as technical diagrams that represent the architecture of a system (for example class hierarchy and state diagrams).
This article is intended to be an introduction and overview of the Unified Modeling Language (UML) and assumes you have a good understanding of object orientation. For a complete and thorough introduction to object orientation, read the following article:
This article will give you a good understanding of the basic UML diagrams and how to use them to represent an object oriented system. This article is based primarily on UML 1.4 that was recently adopted by the Object Management Group. I strongly recommend you download the latest version from http://www.omg.org.
Use Case Diagrams
You use a Use Case diagram to represent the requirements (the functionality) of a system, a subsystem, or a class. Use Case diagrams do not document the internal logic of your program, but rather the external actors with the system. By themselves they have limited usefulness. You capture the details of the Use Case diagram in the Use Case text. The combination of the Use Case diagrams and supporting Use Case text represents an accurate non-technical view of the system. If you are comfortable with traditional text only requirements documents, then you will quickly become comfortable with the combination of using a Use Case diagram along with its Use Case text. Use Case diagrams are also a great source for creating test scripts and user documentation.
Use Case Notation
Use Case diagrams are comprised of actors and use cases.
Actor
An actor represents a role (not a specific person). You represent an actor with a labeled stick figure as follows:
Use Case
Each use case with a Use Case diagram represents a coherent unit of functionality provided by a system, subsystem, or a class as used by one or more actors. You represent a use case as follows:
The diagram itself
Use Case diagrams show the relationships among actors and use cases within a system. For example, the following is from the UML 1.4 draft specification:
Relating Use Cases and Actors
The only relationship between an actor and a use case is an association (a solid line) as follows (optionally you can specify adornments such as multiplicity):
Relating Use Cases
Within your Use Case diagram you can define the relationships among the use cases any of three standard relationship types. These relationship types are include, extend, and generalization.
Include and Extend Relationships
An include relationship from use case A to use case B indicates that use case A includes all the functionality within use case B. An extend relationship from use case C to use case D indicates that use case C may (depending on specific logic) include the functionality of use case D. You represent both an include and extend relationship with a dashed line with an open arrow. You label the line with the include or extend keywords within guillemots (refer to figure above).
Memory Guide:
Include = included functionality
Extend = optional functionality depending on logic
Generalization Relationship
A generalization relationship from one use case to another is the same as for classes (an "is-a" relationship). For example, a generalization from use case E to use case F indicates that use case E is a specialization of use case F. You use the same solid line with a hollow arrowhead pointing to the parent use case as you do with class relationships.
Relating Actors
The only relationship allowed among actors is a generalization. A generalization from actor A to actor B indicates that actor A can communicate with all the use cases that actor B can communicate with. For example, in the following diagram, a Supervisor actor can communicate with all the same use cases as a salesperson. The Supervisor can both establish credit and place an order while the Salesperson can only place an order.
Use Cast Text
A good way to organize your supporting Use Case text is to divide the document into sections (or chapters) with each section representing one Use Case diagram.
Translating from Use Cases to Class Diagrams
There are several techniques for converting Use Case diagrams and Use Case text into Class diagrams. I'll document one or two methods in the final version of this article.
Nouns = potential classes
Verbs = potential operations
Adjectives = potential attributes
Static Structure Diagrams (Class and Object Diagrams)
Static structure diagrams represent the static view of a system and come in two basic flavors: class diagrams and object diagrams.
Class Diagrams
A class diagram represents the static structure of a system while an object diagram represents a snapshot of the system at a given time. From the static structure of a system you instantiate objects that represent the current state of the system. For example, the various code frameworks provided by specific tools are static in nature. In Delphi and Kylix this includes the VCL and CLX object hierarchy and for .NET this includes the .NET framework. When you use these various frameworks you instantiate objects that become the current state of the system.
Notation
You represent a class in a box as follows:
You can add boxes to the class object to represent operations and attributes (methods and properties) as follows:
Optional Compartments
Optionally, you can add a fourth box that represents the classes' responsibilities. In fact, the UML is flexible in that you can add additional boxes to represent tool specific needs such as published properties in Delphi if you wanted to distinguish between public and published visibilities. If the compartment definitions is unclear, you can label the departments as follows:
Specifying Roles
Small box in upper right of class box.
Specifying a Method Body
Optionally, you can specify a method body using a UML note as follows:
As you can see, a note in UML is indicated with a box with the upper right corner turned down and is an effective way to add clarifying text to any UML diagram.
Stereotypes
You can use stereotypes to categorize your classes. To use a stereotype you include it in guillemots. There are several common stereotypes predefined within the UML. For example, the following is how you would represent a utility class:
Object Diagrams
Although less important from a system documentation point of view, object diagrams are handy for documenting a current state of a system. This would include the current values of all documented attributes.
Relating Classes
There are quite a few details to relating classes. This section will cover some of the basics but you will need to get a hold of the UML 1.4 standard to go over all the relationships in more detail.
Generalizations
Generalizations are represented by a solid line with a hollow arrowhead pointing to the parent class as follows:
Dependency
A dependency indicates that a change to the target class may require a change in the source class. A dependency is indicated with a dashed line with an open arrow. For example, to indicate an element of class A depends on an element of class B, you would draw an arrow from class A to class B (the arrowhead pointing at class B).
Composition (Aggregation)
A composite aggregation relationship is indicated by a solid line with a solid diamond head pointing to the part class. Alternatively, you can show this relationship graphically with the part class nested in the whole class. The following two diagrams represent the same composite aggregation relationship:
Interaction Diagrams (sequence and collaboration diagrams)
Interaction diagrams (sequence and collaboration diagrams) describe behavior within a system. This includes both the structural description of the participants and the description of the communication patterns.
Sequence Diagrams
You use a Sequence diagram to document message calls among objects.
Notation
A Sequence diagram represents time going down the diagram vertically with each horizontal line indicating an instance of the system. Each object is listed across the top and arrows are used to indicate a message call from one object to another. Each column is called a swim lane. The following is an example of a sequence diagram from the UML 1.4 standard:
Object Lifeline
Within a sequence diagram each object has a lifeline indicated by the vertical box. If no vertical box is indicated or the vertical box extends the full length of the diagram (as in the sequence diagram above), you can assume the instance of the object lives for the duration of the system. Alternatively, an X can be used to indicate the destruction of an object. For example:
Collaboration Diagrams
You use a Collaboration diagram to present either of the following two:
a set of roles to be played by instances (including the instances given relationship in a given context).
a set of instances and their relationships.
Collaboration diagrams are often used to help design procedures and show navigation using arrows and sequence numbers. A Collaboration diagram without either sequence numbers or navigation arrows shows the context in which interaction can occur.
Statechart Diagrams
You use a Statechart diagram to model the behavior of a model element such as a class or object. You can also use a Statechart diagram to model the specific behavior of other entities such as a use case, actor, or method.
Notation
Statechart notation is often referred to as lollipop notation because it resembles a series of lollipops lined up. You use three primary symbols: initial state, state, and end state. You connect the states with arrows.
Initial State
The initial state of a system is represented by small solid circle.
State
A particular state of the system is represented by a box with curved corners.
End State
The end or final state is represented by a solid circle within a slightly larger circle.
Activity Diagrams
Like a Statechart diagram, you use an Activity diagram to diagram the behavior of a model element.
Notation
Action
An action is represented by a long flat oval as follows:
Subactivity State
A subactivity state represents another nested Activity diagram. A subactivity state symbol is represented just like an Action but with the inclusion of an icon in the lower right corner as follows:
Decision
A decision is represented by a small triangle (very similar to triangles in flow charts).
Process Splitting
You represent a process split (or coming together) with a think line.
Optional Swim Lanes
Optionally you can organize the Activity diagram in swim lanes. In this case, the swim lanes represent states of the system.
Implementation Diagrams (Component and Deployment)
Implementation diagrams are used to describe how the system will be physically implemented. There are two types of implementation diagrams: Component and deployment. A Component diagram shows the structure of a component and a deployment diagram shows the final nodes the components will reside.
Component Diagrams
A Component diagram shows the dependencies among software components as follows:
A Component diagram is what you would use to document a Delphi project including the DPR, PAS, and DFM files.
Deployment Diagrams
Use a deployment diagram to indicate what nodes (computers) you will place the various software.
Packages
You use a Package to group model elements. A Package is represented by a tabbed folder as follows:
Analyst
Print This
Tags:
Article: 
Link: 
Definition: 
KB Post: 
