UML Overview 1

UML Overview

UML Overview 2

UNIFIED Modeling Language

OMG adopted UML in November 1997 as the standard for object-oriented modeling

Combines commonly accepted concepts from many OO methods

Seamless from requirements to deployment

Applicable to any domain

Language and platform independent

Usable with any development process

UML Overview 3

Unified MODELING Language All engineering disciplines have adopted modeling techniques

Allows to capture the important aspects of a system while omiting the rest

Model is easier to use than final system

Help all software systems stakeholders understand what the system will be and what are the possible options available

Multiple models reveal different perspectives on the system

UML Overview 4

Unified Modeling LANGUAGE

Language for: Visualizing: Graphical models with precise semantics

Specifying: Models are precise, unambigous and complete to capture all important Analysis, Design, and Implementation decisions.

Constructing: Models can be directly connected to programming languages, allowing forward and reverse engineering

Documenting: Diagrams capture all pieces of information collected by development team, allowing to share and communicate the embedded knowledge.

UML Overview 5

UML Bird’s Eye View

• Building Blocks: Things: abstractions, main concepts in a model

Relationships: tie the things together

Diagrams: group interesting collections of things

UML Overview 6

UML in a Nutshell

Static Structure

Dynamic Behavior

Model Management

Extensibility Constructs

UML Overview 7

Diagrams in the UML• Class diagram• Object diagram• Use case diagram• Sequence diagram• Collaboration diagram• Statechart diagram• Activity diagram• Component diagram• Deployment diagram

UML Overview 8

Things in the UML• Structural Things (7)

static part of a model, conceptual or physical elements

nouns of UML Models• Behavioral Things (2)

dynamic parts of models

verb, representing behavior over time and space

• Grouping Things (1)

Organizational parts of models, decomposition element

• Annotational Things (1)

explanatory parts of models, comments about other elements

UML Overview 9

Behavioral Modeling

Use Cases / Use Cases Diagrams Interactions / Interaction Diagrams Activity Diagrams

UML Overview 10

Use Cases

Description of a set of sequences of actions, that a system performs to yield an observable result to an end-user

Categories of interactions between the system to be built and external actors

Identify high-level services provided by the system

Specify the behavior of a system

Popularized by Ivar Jacobson with Objectory

Have been adopted by or have influenced many methods (eg. OMT, Fusion, Booch)

UML Overview 11

Use Cases (cont.)

Can be applied to whole system as well as part of system such as a subsystem or a class

Sources of integration tests and system tests

May have variants: specialized use cases or extension of use cases.

Do not specify any implementation detail

Main communication tool with end-user

Each use case must have a name (simple or path name)

UML Overview 12

Actors Objects outside the system which play a particular

role

Represent the user(s) of the system

Interact with the system through use cases

May participate in more than one use case

May or may not be represented as a class or object in the object model

Also known as agents (Jacobson)

UML Overview 13

UML Use Case Graphical Representation

Delivery

Collection

StatusClerk

Manager

Storage depot system

Storage

Actor

Use case

UML Overview 14

Why Modeling Use Cases Use Case model describes WHAT the system will do at a

high-level User focus

- Capture requirements from user's perspective. - Users are involved.

Goal is to scope the project and give the application some structure

-Use Cases are the unit of estimation -Uses Cases are smallest unit of delivery-One way of estimating the percentage of requirements captured. -Prioritizing use cases for "phased delivery" according to user's immediate needs. -Better way of estimating the percentage of requirements completed during development

UML Overview 15

Benefits of use cases Good way to start identifying objects from

scenarios. Test plan can be immediately generated based

on use cases. Easier user validation. Helps technical writers in structuring the overall

work on the users manuals at an early stage. Better traceability throughout the system

development process. Quality of the software is improved by identifying

the exception scenarios earlier in the development process.

UML Overview 16

Problems with use cases

What is the right granularity What is a correct Use Case Explosion of different scenarios Focus on functions, with potential for functional

decomposition Too often too informal

UML Overview 17

Use Cases and Scenarios

Scenario is a specific sequence of actions Scenario is one instance of a Use Case Typically many scenarios correspond to one Use

Case Example:

Use Case = Hire Employee

Scenarios- Hire at Job Fair- Hire through newspaper ad- Hire from internal promotion- Hire Temp

UML Overview 18

Use Cases and Collaborations

Use Case captures WHAT the system does Use Cases do not specifies HOW the System does

it Development effort is aimed at implementing the

use cases by creating a society of classes working together

These interacting classes are modeled using Collaborations

A Collaboration is the realization of a Use Case A Collaboration represents how responsibilities

are distributed across objects A Collaboration has a Static and a Dynamic

aspect

UML Overview 19

Organizing Use CasesRelationships: Generalization, Include (Use) and Extend Generalization:

–Like for Classes

Include: - Use: Contains another complete use-case

Extend:- Extends another use-case- used for optional separate flow (exception)

Beware: - Over-use of extends = functional decomposition - Rumbaugh says Use = aggregation and Extend

= inheritance

UML Overview 20

Hints and Tips

• Each Use Case should represent a single, identifiable and reasonably atomic part of the behavior of the system

• Factors Common Behavior by pulling such behavior from other use cases that it includes

• Factors variants by pushing such behavior into other use cases that extend it

• Describe flow of vents clearly enough for anyone to easily understand it

• Each Use Case is described by a number of scenarios that specify the normal and variants

UML Overview 21

Use Case Diagrams

system is represented by a large rectangle

uses cases are represented as ellipses within the system rectangle

actors are represented as stick figure outside the system

an arrow connects the initiating actor to the use case (ending at the use case)

other participating actors are joined by arrows terminating at the actor

UML Overview 22

Banking System Use Case Diagram

open_account

withdraw_cash

loan_application

clear_checks

get_report

Customer

Manager Loan Officer

Clerk

Cash Dispenser

UML Overview 23

Use Case Identification Steps

•Determine the boundary of the system- consider system as a single “black box” object

•Identify who is going to be using the system directly - e.g. hitting keys on the keyboard. These are the Actors

- start by considering physical object-an individual object may play several roles

•Choose One of these Actors and determine the fundamental ways in which each actor uses the system

-each of these is a use case-must be enumerable- for each of those Use Cases decide on the most usual course when that Actor is using the system. What normally happens. This is the basic course

UML Overview 24

Use Case Identification Steps (2)• Describe it as "Actor does something, system does

something. Actor does something, system does something." but keep it at a high level.

do not mention any GUI specifics

only describe things that the system does that the actor would be aware of and conversely you only describe what the actor does that the system would be aware of.

do not worry about the alternate paths (extends) or common courses (uses) - Yet -

• Review each Use Case descriptions against the descriptions of the other Use Cases.

• Once basic course is OK, consider the alternates and add those as extending use cases.

UML Overview 25

Use Case Identification Steps (3)

• Good way of getting started with Use Case modelling.

• Once started and comfortable with this process, next step:

understand the trade-offs that can be made

simplicity versus "completeness"

putting too much in is the most common mistake.

UML Overview 26

Use Case Textual Descriptions

- a clerk requests the system to create a new account

OPEN_ACCOUNT

WITHDRAW_CASH

CLEAR_CHECKS

LOAN_APPLICATION

GET_REPORT

- a customer requests the system to withdraw a specified amount of money from a specified account

- a clerk instructs the system to update all accounts according to specified transactions including checks

- a customer files a loan application

- a manager or loan officer requests a report of the days transactions from the system

UML Overview 27

Use Cases Diagram Hint and Tips

• Put all the Use Cases that describe one aspect of the system together

• Contains only those use cases and actors essential to understanding that aspect

• Diagram should be named to communicate its purpose

• Minimize crossing lines• Don’t draw too many use cases or too many

relationships in one diagram

UML Overview 28

UMLBasic Structural Modeling

UML Overview 29

Basic Structural Modeling• Classes

Attributes, Operations, Responsibilities

• Relationships Dependency, Generalization, Association, Role, Multiplicity, Aggregation

• Common Mechanisms Specifications, Adornments, Common Divisions, Extensibility Mechanisms

• Diagrams Class , Object , Component , Deployment Dagrams

UML Overview 30

Classes

AstronautPlanet

Most important building block of any object-oriented system

Description of a set of Objects

Implements one or more interfaces

Abstraction of the entities existing in the problem domain

Shuttle::Astronaut

simple names path names

UML Overview 31

Attributes named properties of classes that describe a

range of values

represent some property of the thing being modeled

each attribute has one value for each object

listed in the attribute compartment underneath the name box

normally no need for an explicit “ID” attributeShuttle

weight : Integerage : Integerstatus: enum = on-ground

Mission

start : Dateend : Datecost : Dollars

UML Overview 32

Operations implementation of a service that can be requested from

any object of the class

what you can do to/with an object

are listed in an additional box underneath the attribute box

SYNTAX- name (arg1 : type, arg2 : type ...) : result

Shuttle

start_engines()stop_engines()fuel_level() : integerlaunch(t:time)

UML Overview 33

Organizing Attributes and Operations

• Ellided • Empty compartment

drawing an empty compartment makes no statement about the absence of attributes or operations

• Prefix groups with Stereotypes to group together attributes / operations with

common characteristics represent a metaclassification of the

attributes / operations

UML Overview 34

Responsibility• Contract or obligation of a class• Starting point for modeling a class• Responsibilities are translated into a set of

attributes and operations• Free-form text, in separate compartment at the

bottom of the class

Shuttle

Responsibilities-- Carry astronauts and payload to low orbit space

UML Overview 35

Other Features

• When need to separate the implementation of a class from its specification, use Interface

• Advanced features such as attribute or operation visibility

language-specific features

• Common pre-specified classes modeled with active classes

components

nodes

UML Overview 36

Modeling Classes

• What is a Class?

• Where do I find a Class?

• Where do I find Attributes?

• What the difference between a Class and an Attribute?

• How do I set responsibilities within Classes ?

UML Overview 37

Hints and Tips

• Classes should map to relevant abstraction in problem (and solution) domain

• Embodies small set of well defined responsibilities

• Understandable and simple, yet extensible and adaptable

• Contain only the relevant properties

UML Overview 38

Relationships• Connection among things• How Classes are related to one another• (Almost) As important as Classes• Ways things collaborate• Three main type:

Dependencies

Generalizations

Associations

UML Overview 39

Dependency• Using Relationships• A Change in one thing may affect the other

thing that uses it.• Most often between a class that uses another

clas as a parameter to an operation

Shuttle

start_engines()stop_engines()fuel_level() : integerlaunch(t:time)

Engine

UML Overview 40

Generalization• Relationship which organizes classes based on their

similarities and differences• Relationship between a general thing (the

superclass) and a more specific thing (the subclass)• sometimes called “is-a-kind-of” or “is-a” relationship• Child is substitutable for the parent• Child inherit properties of parent• corresponds to inheritance in object-oriented

languages• NOTATION -

an arrow whose head is next to the specialization

ShuttleSpacecraft

UML Overview 41

Subclasses inherit the attributes, operations and

associations of their superclass(es)

must obey all semantic restrictions of their superclass(es)

can override the implementation of an operation

vehiclesizespeed

land vehicle

wheels

water vehicle

draft

UML Overview 42

Ancestors/Descendants the terms ancestor and descendant refer to

generalization across multiple levels.

an instance of a class is simultaneously an instance (transitively) of all its ancestors

fruit

granny smiths

apple

cox

...

...

UML Overview 43

Associations

describe a group of links with common structure and semantics

are to links what classes are to objects

can have a different name in each direction

Dan Goldin NASA

Bill Gates Microsoft

John Smith Rockwell

... ...

Works-forPerson

Organization

Works-for Employs

UML Overview 44

Associations Continued defined solely by the classes which they connect

associations are not part of the participating classes

associations should not be modelled by attributes

AstronautMission

full_name : string Assigned_to

Mission

full_name : string

Astronaut

assigned_to : string WRONG

RIGHT

UML Overview 45

Roles correspond to one end of an association

each end of an association may be assigned a role which serves as its unique identifier

provide a way of traversing a binary association from one object to a set of related objects

represent a form of specialization

are written next to the association line

ExperimentAstronautconducts

mission-specialist

0..*0..*

UML Overview 46

Multiplicity the number of instances of one class that may

be related to an instance of another

constrains the number of links between objects

Class

Class

Class

Class

Class

many (zero or more)

optional (zero or one)

mandatory (one or more)

numerically specified

1..*

2..4, 6..8

exactly one

0..*

0..1

1

UML Overview 47

Aggregation a special form of association between a whole

and its parts

relates an assembly class to its component classes

is transitive but not symmetric (commutative)

depicted by a diamond at the assembly end

two kinds -- a part cannot be in more than one

“whole”physical

catalog - a part can be in several “wholes”

UML Overview 48

Aggregation Examples

Document Sentence Word1..*

Crew Astronaut4..6

Space Center Building

ShuttleWings

2

Engines3

*

*1..*1..*

1..*

UML Overview 49

Aggregation Example - Graphical interface

Window

PaneTitleBar ScrollBar Border

Close Button Title Arrow Indicator

*

2

0..2

UML Overview 50

Aggregation - Tree-like Notation

Window

PaneTitleBar ScrollBar Border

Close Button Title Arrow Indicator

*

2

0..2

UML Overview 51

Lab Work on UML - Part 1

• Review Use Case Development Process from Rational Unified Process

Use Case Finding

Use Case Details

• Develop Use Case Model using Rational Rose• Develop Use Case Specification Document

UML Overview 52

Lab Work on UML - Part 2

• Review Class Diagram Development Process from Rational Unified Process

• Develop Class Model using Rational Rose