© Osman Haque, Myriad Solutions Inc., 2001 The Unified Modelling Language An OMG Standard .

© Osman Haque, Myriad Solutions Inc., 2001

The Unified Modelling Language

An OMG Standardwww.omg.org


Unified Modelling Language (UML)

• Unified Modelling Language is an international standard to capture and express Requirements and System Designs

• UML is a standard of the Object Management Group (OMG) which has more than 800 members

• At this stage, UML is a language for expressing models - it is not a process

• Together with a Process, it is an Excellent way of Capturing Requirements and Translating them into Design


The Origins of the UML• Plethora of Development Methods

– 63 official methods in 1994

• Grady Booch - the Booch method

• Jim Rumbaugh - the Object Modelling Technique (OMT)

• Ivar Jacobson - the Object-Oriented Software Engineering (OOSE) method

• Jacobson writes Cease the Methodologies Wars, in JOOP, 1994


Inputs to UML

Fusion

Operation descriptions,Message numbering

UML

Meyer

Before and after conditions

Harel

State charts

Wirfs-Brock

Responsibilities

Embley

Singleton classes, High-level view

Odell

Classification

Shlaer - Mellor

Object Lifecycles

Gamma, et.al

Frameworks, patterns,notes

Booch

JacobsonRumbaugh

Henderson-Sellers

Aggregation;Metamodel


UML Modelling DiagramsBehavioural

• Use Case Diagram

• Sequence Diagram

• Collaboration

Diagram

• Statechart Diagram

• Activity Diagram

Structural

• Class/Object

Diagram

• Component Diagram

• Deployment Diagram


UML WALKTHROUGH

Use Case

Activity

Sequence

Class

State Chart

Collaboration

Component

DeploymentA use case is a sequence of transactions performed by a system that yields a measurable result of value for a particular actor.

Validate

Bank

OpenAccount

Transact

uses

CloseAccount

Client


UML WALKTHROUGH

Use Case

Activity

Sequence

Class

State Chart

Collaboration

Component

DeploymentActivity Diagrams depicts Flow

within and between Use Cases; Multithreads can be Shown;

[Next Transaction]

WithdrawsCash

[Amount>Balance]

CustomerIdentifies

AccountOverdrawn

TransactionComplete

PrintReceipt

[Amount<Balance

]


UML WALKTHROUGH

Use Case

Activity

Sequence

Class

State Chart

Collaboration

Component

Deployment A diagram depicting Sequence of Interactions A diagram depicting Sequence of Interactions between Objects and/or between Actor/Systembetween Objects and/or between Actor/System

Business : Client Loans : Loans Rules Assets : Assets

RegisterforLoanValidateRules

CalcAssetValue


UML WALKTHROUGH

Use Case

Activity

Sequence

Class

State Chart

Collaboration

Component

Deployment

A description of a group of objects with common properties,common behavior,common relationships to other objects and common semantics.

Borrowing

CreditCardLoans


UML WALKTHROUGH

Use Case

Activity

Sequence

Class

State Chart

Collaboration

Component

Deployment Depicts the State of an Object; And the Events that Effectuate a Change in State;

Open

Suspended

Closed

WithdrawCash( amount )

OverDrawn[ amount > balance ]

Close(balance)

balance >= 0

SuspendAcct( flag=1 )

SuspendAcct( flag=0 )


UML WALKTHROUGH

Use Case

Activity

Sequence

Class

State Chart

Collaboration

Component

DeploymentA diagram that shows object A diagram that shows object interactions organized around the interactions organized around the objects and their links to each other.objects and their links to each other.

action()

1

1.1

1.21.3


UML WALKTHROUGH

Use Case

Activity

Sequence

Class

State Chart

Collaboration

Component

DeploymentA diagram that shows the composition, organization and dependencies among software components.

Account Customer


UML WALKTHROUGH

Use Case

Activity

Sequence

Class

State Chart

Collaboration

Component

DeploymentA diagram showing how the system will be deployed in operation: It shows processes and nodes in the physical design of a system.

459 Elm St. ATM

ATMClient.exe

Regional ATM Server

ATMServer.exe

<<Private Network>>

125 First St. ATM

ATMClient.exe

<<Private Network>>

Printer

Banking Database Server

Oracle Server

<<LAN>>


Use Casesand

Use Case Diagrams

Prime & Popular Mechanisms for

Requirements Engineering


Why Use Cases and Use case Diagrams?

• Extremely Popular Mechanism for Requirements Engineering

• Users are Directly able to Relate to the Diagrams and Descriptions

• Formalizes the otherwise Unstructured Requirements

• Enables Organization, Reuse, Quality and Extension of Requirements

• Supported by CASE tools


Things to Understand

• Use Cases– and their Documentation

• Actors

• Use Case Relationships– Include, Extend

• Use Case Diagrams

• Classifying and Packaging Use Cases


What is a Use Case?• A series of interaction of a User with the System,

which provides some concrete, measurable results to the User

• Documentation of that interaction as a series of steps - which may be atomic

• Pre- and Post-conditions, Context and other details related to the interaction between “Actor” and the system

• Has a strong Functional flavor and may be (has been) used for Non-OO, and even Non-IT purposes


UML Notation For Use Case

CustomerWithdrawsCash


Sources of Use Cases

• User Workshops – Following the Joint Application Design style– Play acting various Scenarios with Users– Critical Requirements Analysis

• Formal and Informal Problem Statements• Knowledge of Domain Experts• Interviews and Discussions• Existing Systems (esp. Legacy)• Use Case Patterns/Published Literature/ URLs


Actor

Any ‘thing’ that Triggers

an Interaction


Who is an Actor?• The User of the system is usually the Actor

• The Actor (and not the User) is shown sending and

receiving messages to and from the System

– Example: John the Branch Manager, John the Customer

and John the Teller may be one and the same person

• External Devices may also be Actors

– e.g. ATM Machines, Keypads, Printers

• External Systems may also be Actors

– e.g.A Mainframe


UML Notation For An Actor

Customer


Actor: Variations

• Primary Actor: – The first or main Actor who uses the system (e.g. Teller)

– The main Actor who benefits from the system (e.g. Customer)

• Secondary Actor:

– The Actor who derives indirect benefits from or uses the system

(e.g. Branch manager); Depends on Perspective

• Abstract and Concrete Actors:

– Due to Generalization to reduce Complexity


Actors can be Generalized(to handle complexity in use case diagrams)

Borrower

Personal Borrower

Small Business Borrower

Large Corporate Borrower


How to Find Actors?– Who provides/uses Information to/from the System?

– Who Supports this Functionality?

– Which other Systems will this System Interact with?

– The External Devices (Keypads, Printers etc.) that the system will Interact with

Process Comment: Produce first cut of the list of Actors, then Cull them after drawing Initial Use Case diagrams


Actor: Practical Tips

• Customer makes Inquiry by Phone – In this Scenario, Customer does not Directly interact

with the System. Is this Customer an Actor?

– Yes, because this Customer is direct beneficiary

• System sends Messages to backend Database

– This entire backend system may not have any direct

user; The External system may become an actor;

Otherwise, the use case diagram will be without actors.


Internet Actor:The e-Business Customer

• May Remain Unknown for Long, and even

Forever - except through Internet access!

• Business Analysis has to discover/invent:

– Benefits derived by an unknown Customer

– Classification of such an Actor• by Age, Sex, Income, Expenditure and such Criteria

• Choices of such Actors (Language, Colors, Styles)

– Geographical/Time/Cultural boundaries

• 24 x 7 x 360o


What is a Use Case Diagram?

• Primarily used to visualize the Use cases, corresponding

Actors, and their interactions

• Notations: Actor, Use case, Relations

• Relations:

– Relations in a Use case diagram are powerful mechanism to

organize and reuse Requirements

– Includes; Extends; Generalize

• Context in a Use case diagram indicates the boundary of

the system (between the Actor and the System)


UML Notation for Use Case Relationships

<<include>>

<<extend>>

<<inherits>>A

B

Use case A <<include>> Use case BUse case A <<extend>> Use case BUse case A <<inherit>> Use case BIt is Recommended that Inherits NOT be used in Use Case Relationships as it is not mature


Include Relationship

• When Requirements tend to Exhibit Common behavior, they should be Factored out

• These Common Behaviours form a Use case of their Own

• They are then “included” in the Original Use cases, and many more

• Tip: Include implies Mandatory


Include Relationship: Example

• was “uses” in earlier UML versions

A10-Passenger

10-BuysTicket

30-ChecksAvailability

<<include>>


Extend Relationship

• Describes extensions to an Existing Use case

• The Extended use case describes one Specialised set of Interactions

• Enables extending the Use case diagrams for new Requirements without disturbing Existing diagrams

• Tip: Extend implies Optional


Extend Relationship: Example

TicketAvailabilityByPhone

ChecksTicketAvailability

<<extend>>

<<extend>>

<<extend>>

TicketAvailabilityByAgent

TicketAvailabilityByInternet


Use Case diagram for Booking AirTickets

20-MakesEnquiry

A20-Staff

3010-PhoneAvailability

3020-InternetAvailability

3030-AgentAvailability

30-ChecksAvailability

<<extend>>

<<extend>>

<<extend>>

A10-Passenger

10-BuysTicket

<<include>>


Use Case Diagrams: Common Pitfalls!

• Treated as Data Flow Diagrams– Use Activity Diagrams to Show the Flow

• Look like a Spider’s web– Abstract both Actors and Use cases and draw separate

‘abstract’ use case diagrams

• Too Coarse or Too Fine Granularity– Experience needed to Get it Right– Perhaps Use Case Diagram Patterns can Help?

• Use Case Diagrams treated as Deliverables– More than 50% work is Documenting Use Cases

• Force fitting Actors that Don’t Exist


Relating to CRA

• Each Functional CPA (Critical Performance Area) should be seen from the Actor’s Viewpoint

• Then, it is potentially a Use Case

• Need to Scope it, and give it due Importance


Use Case Documentation

The Flow Within a Use Case


Use Case Documentation• The Flow within a Use case is the Behavioral

aspect of the System

• This flow can be documented as:– Organized Text

– Pseudocode

– Sequence Diagrams

– occasionally Activity diagrams

• Organized Text is the Primary means of this

Documentation; It is based on a pre-decided template


Template: Documenting Use CasesUse Case Thumbnail

<Number and Name of the Use Case>

Use Case Description<A short description of the use case>

Stereotype and Package<Description of the Stereotype and Package to which this use case belongs>

Pre-Conditions<Conditions that must be satisfied before this use case can begin - may include a

list of other use cases>

Post-Conditions<Conditions that must be met at the end of this use case>

Actors<A list of the actors involved in this use case>

Use Case Relationships<Thumbnails of other Use Cases that are Included, Extended and Inherited>


Template: Documenting Use Cases...Use Case Text

1.0 <description of step>2.0 <description of step> (A1, E1, E2)3.0 <description of step> (A2, E3)INCLUDE <Thumbnail of Use case/s Included>EXTEND <Thumbnail of Use case/s Extended>

Alternative Courses<A1> <A2>

Exceptions<E1><E2>

Constraints<special constraints/limitations in executing the use case>


Template: Documenting Use Cases...

User Interface Specifications<Number and Name of UI specifications related with this use case, including web-

screen specifications>

Metrics<Measurements related to this use case - if relevant to the programme; Also,

perhaps, complexity factor>

Priority<The importance of the functionality described by this use case

High/Medium/Low>

Status<The state of completeness of the documentation of this use case -

Initial/Major/Final>

Author & History<Original Author and Modifiers of this Use Case>

Reference Material<Relevant reference materials and sources for details>


Use Case Analysis and Testing

• Business Analysts should plan to ‘reuse’ parts of Requirements Model for Testing

• There are some similarities between RM and Test Creation Processes

– The Steps within Use Cases provide the First cut of Black box Test Cases

– Augment them with Operational Test Cases (performance, stress testing)

– A Good Test Architecture should reflect understanding of good Application Architecture


Activity Diagrams

Flows within Use Cases, WorkFlows, Multithreads


Purpose of Activity Diagrams

• Primary purpose is to show the flow of Activities – Within the requirements (use cases)

– In the System

– For the Overall Business

• A highest level Activity Diagram can be used as a Context-diagram– showing how various business processes are related


About Activity Diagrams

• Capable of showing Sequentially Dependent Business Objectives

• They can be Used to Show

– Multiple Threads

– Work Flows with Deliverables

• They do not have separate Documentation within UML


Things in Activity Diagrams

• Activities

• Transitions

• Starting and End points

• Sync Points

• Decision points

• Guard Conditions


ActivitiesThings happening within the System or within the Flow of a Use Case

CustomerIdentifies

WithdrawsCash

TakesReceipt


Transitions

CashWithdrawn

Flag Overdrawn

Amount > Balance

This is a Transition:It can be triggered by a user action, or by meetinga certain Criteria/condition


Activity Diagrams(Like Flow Charts)

WithdrawsCash

[Amount>Balance]

[Next Transacti

on]

CustomerIdentifies

AccountOverdrawn

TransactionComplete PrintReceipt

[Amount<Balance]


A typical Activity Diagram for Receiving and Dispatching Orders

ReceiveOrder

CancelOrder

AuthorizePayment

CheckLine Item

Assign toOrder

DispatchOrder

ReorderItem

[for each lineitem on order]

[failed]

[succeeded]

[in stock]

[need toreorder][stock assigned to

all line items andpayment authorised]

*


Class Diagrams

Formalized from Object-oriented Technology


Class Diagrams in Business Analysis

• Class Diagrams are used to describe the Business Object Model

• They are an ideal static description of Entities in Business Domain

• Important:– Classes are used at a high-level in Business Analysis

– Not all features of classes are relevant in BA; They apply in System Design


Class Diagrams in Business Analysis

• Used to Document

– Key Domain Entities

– Design Structure

– Logical Grouping resulting into Components

• Class has three parts: Identification, Attributes and

Operations

• Relationships: Inheritance, Aggregation,

Association


• Analyse the Use Case Diagrams and Documentation

• Determine the Key Business Entities (Candidate Classes)

• Refine the Candidate Classes• Determine the Relationships between Classes• Determine Abstraction Level

– through Inheritance hierarchy

Class Diagram:Iterative Steps..


Class Diagram: Iterative Steps

• Define/Qualify the Classes– provide Attributes and Types– provide Responsibilities

• Which will eventually translated into Operations

• Describe states of Objects for that Class, if important

• Statecharts are Optional so we don’t use them


Class Notation

Course

name : charID : int

getname (): BOOL

Name of the Class

Attributes of the Class

Operations of the Class

Business Analysis:Specifying Attribute Types may be helpful

Business Analysis:Specifying Operations ReturnValues may not be necessary (too technical; for Sys.Design)


Naming Classes

• Class Names should be created Formally

– BAs, Users, Developers should (Preferably) agree on

names

• Singular Common Noun, representing a ‘core’ or

‘definable’ entity (mostly)

• Abstract Nouns will appear for Abstract entities

(e.g. Transaction)


OO v/s Non-OO (Similarities and Differences)

• Non-Object-oriented (Traditional)– Data and Procedures are kept Separate

– Procedures work on Data to produce results

• Object-oriented– Focus on Responsibilities - to be satisfied

by Objects

– Responsibilities translate into Data and Functions within a Object

– Objects have Behavior

Data

Procedures

Procedures

Data


Class v/s ObjectClass v/s Object

• Object is an instance of Class• Class is effectively a definition for object

characteristics, such as:– properties; behavior– relationships; semantics– data structures

• Thus, Class is a blueprint for creating infinite objects

• Object is an instance of Class• Class is effectively a definition for object

characteristics, such as:– properties; behavior– relationships; semantics– data structures

• Thus, Class is a blueprint for creating infinite objects


Object NotationObject NotationFor Classes Named Course and Professor

Objects are ‘proper nouns’ shown belonging to Class

Course Professor

rectangles contain class names

Oscar:ProfessorMaths:CourseEnglish:Course

rectangles contain object and class names, underlined


AttributesAttributes

• Attributes describe the characteristics of an object

• Thus, Attributes describe characteristics which define a class of objects

• Attributes represent data values of objects belonging to a class

• Attributes have one value for each class instance (object)

• Attributes describe the characteristics of an object

• Thus, Attributes describe characteristics which define a class of objects

• Attributes represent data values of objects belonging to a class

• Attributes have one value for each class instance (object)


Attributes - NotationsAttributes - Notations

Course

name : charcredit : integerduration : integer

attributes

Typically, there is no need for an explicit “ID” attribute.


OperationsOperations• Operations define the behaviors of objects of a

particular class.• Operations are defined for a class only. Each

object of that class type has the same operations.• Operations change the state of attribute values and

are applied to instances of a class.• Operations are implemented by methods.• Operations are listed in the operations

compartment of the class box beneath the attributes compartment.

• Operations define the behaviors of objects of a particular class.

• Operations are defined for a class only. Each object of that class type has the same operations.

• Operations change the state of attribute values and are applied to instances of a class.

• Operations are implemented by methods.• Operations are listed in the operations

compartment of the class box beneath the attributes compartment.


Operations - NotationOperations - Notation

start-engines()stop-engines()get_fuel-level()operations

Course

name : charcredit : integerduration : integer

add-name()change-credit()change-duration()


Categories of ObjectsCategories of Objects

• Domain Objects

• Application Objects

• Implementation Objects

• Domain Objects

• Application Objects

• Implementation ObjectsBusiness Analysts would Mostly Deal with Domain Objects,at times with Application Objects but hardly with Implementation Objects


Domain ObjectsDomain Objects

• Carry real-world semantics of the application.

• Exist independently of the application.

• Are meaningful to Business Analysts and Domain Experts.

Examples: course, professor, student

• Carry real-world semantics of the application.

• Exist independently of the application.

• Are meaningful to Business Analysts and Domain Experts.

Examples: course, professor, student


Application ObjectsApplication Objects

• Are user-visible components of computer solution.

• Represent part of the Solution Domain and not Problem Domain

• May be Reused across Domains

Examples: User interface, printer interface

• Are user-visible components of computer solution.

• Represent part of the Solution Domain and not Problem Domain

• May be Reused across Domains

Examples: User interface, printer interface


Implementation ObjectsImplementation Objects

• Internal components used to implement system

• Invisible to the user

• Of No Interest to Business Analysts

Examples - database, hash table

• Internal components used to implement system

• Invisible to the user

• Of No Interest to Business Analysts

Examples - database, hash table


Sequence Diagrams

The Dynamic Aspect of Requirements Modeling


Sequence Diagram• A Dynamic Diagram to record Messages and their

sequences

• A pictorial representation of a Scenario/Example

for a Use Case

• A tool to Identify missing Classes in a Class

Diagram through Objects

• Part of Interaction Diagrams

– the other one being Collaboration Diagram


UML Notation For Object(In a Sequence Diagram)

SampleObject


Axes Axes

Tim

e

Different objects

These are the ‘semantics’ of the messages we want to show.In practice, return messages are not shown as they are implicit


UML Notation For Object Message

: Actor1

SampleObject1

1: Message sent by actor to an object


Sequence Diagram for Registering for Loans

Business : ClientLoans : Loans Rules Assets : Assets

RegisterforLoanValidateRules

CalcAssetValue

© Osman Haque, Myriad Solutions Inc., 2001 The Unified Modelling Language An OMG Standard .

Documents

case toolsthings

sequence of interactions

sequence of transactions

use cases multithreads

object interactions

group of objects

unified modelling languagean

common properties