Introduction to UML



Why Uses UML

Is an open standard

Supports the entire software development lifecycle

Supports diverse applications areas

Is based on experience and needs of the user community

Supported by many tools



UML Partners



What is UML

The UML is a language for

the artifacts of a software-intensive system



System Model

A system is described in several different model types:



Structure of UML

  1. Modeling elements
  2. Relationships
  3. Extensibility Mechanisms
  4. Diagrams



Modeling Elements

Structural elements

Behavioral elements

Grouping elements

Other elements

wpe1.jpg (23260 bytes)








wpe2.jpg (14326 bytes)




Extensibility Mechanisms


Tagged value


wpe3.jpg (14001 bytes)



Models, Views, and Diagrams

wpe4.jpg (42998 bytes)




A diagram is a view into a model

In the UML, there are nine standard diagrams




UML organizes a model in a number of views that present different aspects of a system.

Combination of all the views can create a complete picture of a system.

A view is not a graph ; it may contain many diagrams.







The actual graphs that show model element symbols arranged to illustrate a particular part or aspect of the system.



Use Case Diagram

Captures system functionality as seen by users

wpe5.jpg (31860 bytes)


Captures system functionality as seen by users

Built in early stages of development


Developed by analysts and domain experts



Class Diagram

Captures the vocabulary of a system

wpe6.jpg (30448 bytes)


Captures the vocabulary of a system

Built and refined throughout development


Developed by analysts, designers, and implementers



Object Diagram

Captures instances and links

wpe13.jpg (31014 bytes)


Shows instances and links

Built during analysis and design


Developed by analysts, designers, and implementers



Component Diagram

Captures the physical structure of the implementation

wpe14.jpg (24502 bytes)


Captures the physical structure of the implementation

Built as part of architectural specification


Developed by architects and programmers



Deployment Diagram

Captures the topology of a system’s hardware

wpe15.jpg (31691 bytes)



Deployment Diagram

Captures the topology of a system’s hardware

Built as part of architectural specification


Developed by architects, networking engineers, and system engineers



Sequence Diagram

Captures dynamic behavior (time-oriented)

wpe16.jpg (24654 bytes)


Captures dynamic behavior (time-oriented)




Collaboration Diagram

Captures dynamic behavior (message-oriented)

wpe17.jpg (15275 bytes)



Captures dynamic behavior (message-oriented)




Statechart Diagram

Captures dynamic behavior (event-oriented)

wpe18.jpg (24283 bytes)


Captures dynamic behavior (event-oriented)




Activity Diagram

Captures dynamic behavior (activity-oriented)

wpe19.jpg (26957 bytes)



Captures dynamic behavior (activity-oriented)




Architecture and the UML

wpe1A.jpg (35889 bytes)


Workflows and Models

wpe1B.jpg (47592 bytes)



Analysis & Design Model

wpe1C.jpg (54115 bytes)



Use Case Driven

wpe1D.jpg (33550 bytes)

Drive a number of development activities

Synchronize the content of different models



Use-Case Modeling In UML

Use-Case Modeling: Introduction



Use-Case Model: Components

The primary components of a use-case model are



Use Cases

The functionality is represented by a number of use cases, and each use case specifies a complete functionality.

When the functionality is complete, the use case must handle the entire function, from its initiation by an external actor until it has performed the requested functionality.

A use case must always deliver a value to an actor, the value being whatever the actor wants form the system.

What happens in use cases do not cover the entire system functionality?



Use Cases: Purpose

To decide and describe the functional requirements of the system.

To give a clear and consistent descriptions of what the system should do.

To provide a basis for performing system tests that verify the system.

To provide the ability to trace functional requirements into actual classes and operations in the system.



Use-Case Diagram

A use-case model is described in UML as a use-case diagram.

A use-case model can be divided into a number of use-case diagrams.

The actual description of the use-case contents is usually given in plain text.

An activity diagram may be used instead of textual description of use case.




An actor is someone or something that interacts with the system

An actor is who or what uses the system.

An actor is a type (a class), not an instance.

An actor represents a role, not an individual user of the system.

One person may have different roles in a system.

An actor communicates with the system by sending and receiving messages.



Main Categories of Actors

Principal actors: People who use the main system functions

Secondary actors: People who perform administration or maintenance tasks

External hardware: The unavoidable hardware devices that are part of the application domain and must be used

Other systems: The other systems with which the system must interact.



Finding Actors

Who will use the main functionality of the system (primary actors)?

Who will need support from the system to their daily tasks?

Who will need to maintain, administrate, and keep the system working (secondary actors)?

Which hardware devices does the system need to handle?

With which other systems does the system need to interact?

Who or what has an interest in the results (the value) that the system produce?



Actors in UML

An actor is a class, and is shown as a class rectangle with the stereotype <<actor>>.

The standard stereotype icon of a stickman is normally shown in use-case diagrams. It has the actor name below the figure.

Since actors are classes, they can have the same relationships as classes.

In use-case diagrams, only generalization relationships are used to describe common behavior between a number of actors.



Use Cases

A use case is always initiated by an actor.

A use case provides value to an actor.

A use case is complete. A use case is not complete until the end-value is produced. Be careful in dividing a use case into smaller use cases.

A use case is a class, not an instance.

A use case describes the functionality as a whole, including possible alternatives, errors, and exceptions that can occur during the execution of the use case.




A scenario is an instantiation of a use case.

A scenario represents an actual usage of the system, a specific execution path through the system.

A scenario instance of the use case "Signing Insurance" could be "John Smith contacts the system by telephone and signs for car insurance for the Ford Escort he just bought.



Finding Use Cases

Which functions does the actor require from the system? What does the actor need to do?

Does the actor need to read, create, destroy, modify or store some kind of information in the system?

Does the actor have to be notified about events in the system, or does the actor need to notify the system about something? What does those events represent in terms of functionality?

Could the actor’s daily work be simplified or made efficient through new functions in the system?



Finding Use Cases: Other Questions

What input/output does the system need? Where does this input/output come from or go to?

What are the major problems with the current implementation of this system (perhaps a manual system instead of an automated one)?


Note: All the material in these UML pages are provided by a student as a research project.