Chapter 05 A

Modelling Concepts
Based on Chapter 5 of Bennett, McRobb and

Farmer:
Object Oriented Systems Analysis and Design
Using UML, (2nd Edition), McGraw Hill, 2002.
03/12/2001 © Bennett, McRobb and Farmer 2002 1

In This Lecture You Will Learn:
 What is meant by a model
 The distinction between a model and a
diagram
 The UML concept of a model
© Bennett, McRobb and Farmer 2002 2

What is a Model
 Like a map, a model represents
something else
 A useful model has the right level of
detail and represents only what is
important for the task in hand
 Many things can be modelled: bridges,
traffic flow, buildings, economic policy

Why Use a Model?
 A model is quicker and easier to build
 A model can be used in a simulation
 A model can evolve as we learn
 We can choose which details to include
in a model
 A model can represent real or imaginary
things from any domain
Modelling Organizations
Organizations are human activity systems.
 The situation is complex
 Stakeholders have different views
 We have to model requirements
accurately, completely and
unambiguously
 The model must not prejudge the
solution
What is a Diagram?
 Abstract shapes are used to represent
things or actions from the real world
 Diagrams follow rules or standards
 The standards make sure that different
people will interpret the diagram in the
same way
40°

Author Reviewer Typesetter Printer
An Example Write Chapter
of a Diagram Review Chapter
 An activity Revise Chapter
[book not
diagram of the complete]
[book complete]
tasks involved Typeset Book
in producing a
book. Correct Proofs
Reset Book
Print Book

Author Reviewer Typesetter Printer
Hiding Write Chapter
Write Chapter
Detail
Plan Chapter
Produce
First Draft Review Chapter
Revise Draft
Revise Chapter
[book not
[not satisfied]
complete]
[satisfied]
[book complete]
Add Exercises
Typeset Book
Add References
to Bibliography
Correct Proofs
Reset Book
Print Book

Diagrams in UML
 UML diagrams consist of: Write Chapter
– icons Plan Chapter
– two-dimensional symbols Produce

First Draft
– paths Revise Draft
– Strings [not satisfied]
[satisfied]
 UML diagrams are defined in Add Exercises
the UML specification. Add References

to Bibliography

Diagrams vs Models
 A diagram illustrates some aspect of a
system.
 A model provides a complete view of a
system at a particular stage and from a
particular perspective.
 A model may consist of a single diagram, but
most consist of many related diagrams and
supporting data and documentation.

Examples of Models
 Requirements Model
– complete view of requirements
– may include other models, such as a Use
Case Model
– includes textual description as well as sets
of diagrams

Examples of Models
 Behavioural Model
– shows how the system responds to events
in the outside world and the passage of
time
– an initial model may just use Collaboration
Diagrams
– a later model will include Sequence
Diagrams and Statecharts

Models in UML
 A system is the overall thing that is being
modelled
 A sub-system is a part of a system
consisting of related elements
 A model is an abstraction of a system or
sub-system from a particular perspective
 A model is complete and consistent at
the chosen level of abstraction
Models in UML
 Different models present different views
of the system, for example:
– use case view
– design view
– process view
– implementation view
– deployment view
(Booch et al., 1999)

Packages, Sub-systems and
Models
 UML has notation for showing sub-
systems and models, and also for
packages, which are a mechanism for
organising models (e.g. in CASE tools)
Use Cases Campaign Use Case
Management Model
Package Sub-system Model

Developing Models
 During the life of a project using an
iterative life cycle, models change along
the dimensions of:
– abstraction—they become more concrete
– formality—they become more formally
specified
– level of detail—additional detail is added as
understanding improves
Development of the Use Case
Model
Staff Management
Iteration 1
Add a new staff
member
Staff Management
Add a new staff

member
Add a new staff
grade
Add a new staff

grade
Change the
rate for a
staff grade
Obvious use cases.

Accountant Change the
rate for a
staff grade Change the
grade for a
staff member
Accountant
Change the
grade for a
staff member
Calculate staff
bonuses
Calculate staff
bonuses
Simple use case descriptions.

Staff Management
Add a new staff

member
Staff Management
Iteration 2
Add a new staff
member
Staff Management
Add a new staff
grade
Add a new staff Campaign Selection

member
Add a new staff
grade
Change the
Campaign Selection
rate for a
staff grade Client: Holborn Motors
Add a new staff Campaign Selection Lynch Properties
grade
rate for a Client: Holborn Motors
Yellow
Yellow Partridge
Partridge
staff grade Change the LynchZeta
Properties
Systems
grade for a
Additional use cases.

staff member
Client: Holborn Motors
Yellow
Yellow Partridge
Partridge
Spring Jewellery Campaign 1997
Campaign:LynchZeta
Properties
Systems
rate for a
staff grade Change the
grade for a Spring Jewellery Campaign 2001
Yellow Partridge
staff member
Spring Jewellery
Spring
Zeta Systems Campaign
Jewellery 1997 2002
Campaign
Accountant Calculate staff
Campaign:
Change the
bonuses
Spring Jewellery
Summer Campaign
Collection 2001
1998
grade for a
Spring
Spring Jewellery
Jewellery Campaign
Campaign 2002
staff member
Campaign:
Calculate staff
2002
Summer Collection 1998
bonuses
OK Quit
Calculate staff
bonuses
OK Quit
Simple use case descriptions.

OK Quit
Prototypes.
Iteration 3
Campaign Management
Assign staff
to work on
a campaign «include»
Find campaign
Campaign Management
Assign staff «include»

to work on
a campaign
Add a new
adv ert to
«include» Campaign Selection
a campaign
Find campaign«include»
Campaign Management
Assign staff
to work on
Campaign
Manager Add a new
«include»
Campaign Selection
a campaign advert to
«include»
a campaign
Check campaign
«include»
Find campaign budget Client: Holborn Motors
Campaign «include»
Campaign Selection Lynch Properties
Manager Add a new
advert to
Check campaign
«extend» «extend»
Client: Holborn Motors
Yellow
Yellow Partridge
Partridge
Structured use cases.

a campaign
«include»
budget
LynchZeta
Properties
Systems
Print campaign
Holborn Motors
Print campaign
Campaign
Manager
summary invoice
Client: Yellow
Yellow Partridge
Partridge
Check campaign
budget Accountant Campaign:LynchZeta
Properties
Systems
Print campaign Print campaign
Yellow Partridge
summary inv oice
Spring
Zeta Systems Jewellery
Spring Campaign
Jewellery 1997 2002
Campaign
Campaign:
Accountant Spring Jewellery
Summer Campaign
Collection 2001
1998
Print campaign Print campaign
Spring
Spring Jewellery
Jewellery Campaign
Campaign 2002
summary invoice
Campaign:
2002
Summer Collection 1998
Accountant OK Quit
OK Quit
Structured use case descriptions.

OK Quit
Prototypes.
Summary
In this lecture you have learned about:
 What is meant by a model
 The distinction between a model and a
diagram
 The UML concept of a model

References
 Booch, Rumbaugh and Jacobson (1999)
(For full bibliographic details, see Bennett,
McRobb and Farmer)

Activity Diagrams

Farmer:

 The purpose of activity diagrams
 The notation of activity diagrams
 How to draw activity diagrams

Drawing Activity Diagrams
 Purpose
– to model a task (for example in business
modelling)
– to describe a function of a system
represented by a use case
– to describe the logic of an operation
– to model the activities that make up the life
cycle in the Unified Process
Notation of Activity Diagrams
 Activities Add a New
Client
– rectangle with rounded ends
– meaningful name
Assign Staff
 Transitions Contact
– arrows with open

arrowheads

 Start state Add a New
Client
– black circle
 Decision points Assign Staff
Contact
– diamond
[no campaign to add]
 Guard conditions
– in square brackets
[campaign to add]
 Final state Add New

Campaign
– black circle in white circle

 Alternative notation for Add a New
Client
branching:
– alternative transitions Assign Staff [no campaign to add]
Contact
are shown leaving the [campaign to add]
activity with guard Add New
conditions Campaign
 Note that guard conditions do not have

to be mutually exclusive, but it is
advisable that they should be
 Object flows :Campaign
[Active]
– dashed arrow
Record completion
 Objects of a campaign
:Campaign
– rectangle [Completed]
– with name of object

underlined
– optionally shows the
state of the object in
square brackets
Campaign Accountant Client
Manager
 Swimlanes
– vertical columns
Record Completion
of a campaign
– labelled with the Issue invoice
person, organisation
or department Pay invoice
responsible for the

activities in that Record client
payment
column

 What is the purpose?
– This will influence the kind of activities that
are shown
 What is being shown in the diagram?
– What is the name of the business process,
use case or operation?
 What level of detail is required?
– Is it high level or more detailed?

 Identify activities
– What happens when a new client is added
in the Agate system?
 Add a New Client
 Assign Staff Contact
 Add New Campaign
 Assign Staff to Campaign
 Organise the activities in order with
transitions
Drawing Activity
Diagrams Add a New
Client
Assign Staff
Contact
Add New
Campaign
Assign Staff
to Campaign

 Identify any alternative transitions and
the conditions on them
– sometimes there is a new campaign to add
for a new client, sometimes not
– sometimes they will want to assign staff to
the campaign, sometimes not
 Add transitions and guard conditions to
the diagram
Drawing Activity
Diagrams Add a New
Client
Assign Staff [no campaign to add]

Contact
[campaign to add]
Add New [no staff to assign]

Campaign
[staff to assign]
Assign Staff
to Campaign

 Identify any processes that are
repeated
– they will want to assign staff to the
campaign until there are no more staff to
add
 Add transitions and guard conditions to
the diagram

Drawing Activity
Diagrams Add a New
Client

Contact
[campaign to add]

Campaign
[staff to assign]
[no more staff to assign]

Assign Staff
to Campaign
[more staff to assign]

 Are all the activities carried out by the
same person, organisation or
department?
 If not, then add swimlanes to show the
responsibilities
 Name the swimlanes
 Show each activity in the appropriate
swimlane
Administrator Campaign Manager
Add a New
Client

Contact
[campaign to add]

Campaign
[staff to assign]
Assign Staff
to Campaign

 Are there any object flows and objects
to show?
– these can be documents that are created
or updated in a business activity diagram
– these can be object instances that change
state in an operation or a use case
 Add the object flows and objects

Administrator Campaign Manager
Add a New :Client

Client [New]

Contact
[campaign to add]
:Campaign Add New [no staff to assign]

[Commissioned] Campaign
[staff to assign]
Assign Staff
to Campaign

Summary
 The purpose of activity diagrams
 The notation of activity diagrams
 How to draw activity diagrams

References
 Booch, Rumbaugh and Jacobson (1999)
 Rumbaugh, Jacobson and Booch (1999)
McRobb and Farmer)

Development Process

Farmer:

 About the Unified Software Develop-
ment Process
 How phases relate to workflows in an
iterative life cycle
 An approach to system development
 Major activities in the development
process
Unified Software
Development Process
 Developed by the team that created
UML
 Embodies best practice in system
development
 Adopts an iterative approach with four
main phases
 Different tasks are captured in a series
of workflows
Best Practice
 Iterative and incremental development
 Component-based development
 Requirements-driven development
 Configurability
 Architecture-centrism
 Visual modelling techniques

Four Phases
 Inception
 Elaboration
 Construction
 Transition

Phases, Workflows
and Iterations
 Within each phase activities are
grouped into workflows
 The balance of effort spent in each
workflow varies from phase to phase
 Within phases there may be more than
one iteration

Project
Phases
Inception Elaboration Construction Transition
1 2 3 4 5 6 7 8
Iterations within
each phase
Requirements
Analysis
Design
Implementation
Test
Workflows Size of square

relative to time
spent on
workflowh
Difference from
Waterfall Life Cycle
 In a waterfall life cycle project the phases and
the workflows are linked together
 In the Requirements phase, only
Requirements workflow activities are carried
out
 All Requirements activity should be completed
before work starts on Analysis
 In an iterative life cycle project it is
recognised that some Requirements work will
be happening alongside Analysis work
Requirements Design Test
Analysis Implementation
Requirements
Analysis
Design
Implementation
Test

Major Activities of the
Development Process
Activity Techniques Key Deliverables
Requirements Requirements Use Case Model
Capture and Elicitation Requirements List
Modelling Use Case Prototypes
Modelling Glossary
Prototyping

Development Process
Requirements Collaboration Analysis Models
Analysis Diagrams
Class and Object
Models
Analysis
Modelling

Development Process
System Deployment Overview Design
Design Modelling and
Component Implementation
Modelling Architecture
Package
Modelling
Architectural
Modelling
Development Process
Class Design Class and Object Design Models
Modelling
Interaction
Modelling
State Modelling
Design Patterns

Development Process
User Class and Object Design Models
Interface Modelling with Interface
Design Interaction Modelling Specification
State Modelling
Package Modelling
Prototyping
Design Patterns
Development Process
Data Class and Object Design Models
Management Modelling with Database
Design Interaction Specification
Modelling
State Modelling
Package
Modelling
Design Patterns
Development Process
Construction Programming Constructed
Component Re- System
use Documentation
Database DDL
Programming
Idioms

Development Process
Testing Programming Tested System
Test Procedures

Development Process
Implementation Installed System

Summary
 The Unified Software Development
Process
 How phases relate to workflows in an
iterative life cycle
 An approach to system development
 Major activities in the development
process
References
 Jacobson, Booch and Rumbaugh (1999)
 Kruchten (1999)
 Chapter 22 of Bennett, McRobb and
Farmer includes more detail about the
Unified Process
McRobb and Farmer)

Chapter 05 A

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Chapter 05 A

Uploaded by

Copyright:

Available Formats

Modelling Concepts

Based on Chapter 5 of Bennett, McRobb and

03/12/2001 © Bennett, McRobb and Farmer 2002 1

© Bennett, McRobb and Farmer 2002 2

© Bennett, McRobb and Farmer 2002 3

© Bennett, McRobb and Farmer 2002 6

An Example Write Chapter

of a Diagram Review Chapter

 An activity Revise Chapter

diagram of the complete]

tasks involved Typeset Book

© Bennett, McRobb and Farmer 2002 7

Hiding Write Chapter

© Bennett, McRobb and Farmer 2002 8

– icons Plan Chapter

– two-dimensional symbols Produce

– paths Revise Draft

– Strings [not satisfied]

the UML specification. Add References

© Bennett, McRobb and Farmer 2002 9

© Bennett, McRobb and Farmer 2002 10

© Bennett, McRobb and Farmer 2002 11

© Bennett, McRobb and Farmer 2002 12

© Bennett, McRobb and Farmer 2002 14

Package Sub-system Model

Add a new staff

Add a new staff

Obvious use cases.

Simple use case descriptions.

Add a new staff

Add a new staff Campaign Selection

Additional use cases.

Simple use case descriptions.

Assign staff «include»

Structured use cases.

Structured use case descriptions.

© Bennett, McRobb and Farmer 2002 18

© Bennett, McRobb and Farmer 2002 19

Based on Chapter 5 of Bennett, McRobb and

03/12/2001 © Bennett, McRobb and Farmer 2002 20

© Bennett, McRobb and Farmer 2002 21

– arrows with open

© Bennett, McRobb and Farmer 2002 23

 Final state Add New

– black circle in white circle

 Note that guard conditions do not have

– with name of object

– labelled with the Issue invoice

responsible for the

© Bennett, McRobb and Farmer 2002 27

© Bennett, McRobb and Farmer 2002 28

© Bennett, McRobb and Farmer 2002 30

Assign Staff [no campaign to add]

Add New [no staff to assign]

© Bennett, McRobb and Farmer 2002 32

© Bennett, McRobb and Farmer 2002 33

Assign Staff [no campaign to add]

Add New [no staff to assign]

[no more staff to assign]

© Bennett, McRobb and Farmer 2002 34

Assign Staff [no campaign to add]

Add New [no staff to assign]

© Bennett, McRobb and Farmer 2002 36

© Bennett, McRobb and Farmer 2002 37