Software Design

1
Software Design

• An Introduction to Object Oriented Analysis and
  Design Using the Unified Modelling Language

Bill Keller Spring 2004
2
Lecture 1 Introduction

• Introduction
• What the course is about
• What the course is not about
• Aims and Outcomes
• Teaching and Assessment
• Design Case Study
• Design Task
• Recommended Reading

3
What the course is about

• An introduction to object-oriented analysis and
  design
• The software development process
• Object-orientation
• Requirements analysis and modelling
• Software quality
• The Unified Modelling Language (UML)
• Use case diagrams
• Static structure and the class model
• Object collaboration and interaction
• Object state and behaviour
• Team-working
• Managing the process

4
What the course isnt about

• To keep the course manageable, we wont cover
• Requirements capture
• Interface design and HCI Issues
• Deployment and maintenance
• Some UML dealt with only briefly or not at all
• Packages and components
• Deployment diagrams
• Object constraint language

5
Course Aims
This course aims to provide first year students
with

• An introduction to fundamental concepts of
  object-oriented analysis and design of software
• practical experience of software modelling and
  design techniques
• experience of team-working
• an introduction to the Unified Modelling Language

6
Learning Outcomes

• On successful completion of the course students
  should be able to
• Appreciate the problems inherent in the design of
  high-quality software
• Demonstrate the skills needed to model software
  components using basic elements of the UML
• Work effectively as a part of a software design
  team
• Document design decisions appropriately

7
Why UML?

• UML is a visual modelling language which
• supports analysis and modelling at all stages
• is an emerging standard for software modelling
• Is process neutral i.e. is not tied to any one
  particular design process
• We will cover core aspects of UML, including
• Use-case diagrams,
• Class diagrams,
• Interaction diagrams collaboration/sequence
• Statechart and activity diagrams

8
Teaching Sessions Lectures

• Generally there will be two lectures each week
• Monday ?? in the Biology Lecture Theatre
• Wednesday ?? in the Biology Lecture Theatre

9
Lecture Topics

• Collaborations and Interactions
• Object Behaviour
• Other UML Notations
• Design Quality
• Product Quality
• Software Patterns

• Introduction
• Software Development
• Object Orientation
• Requirements and Use Cases
• An Overview of UML
• Class Models and Diagrams
• More About Class Diagrams
• Collaboration

10
Design Case StudyAutomated Teller Machine (ATM)

• Statement of purpose
• An ATM is an electronic device designed for
  automated dispensing of money. A user can
  withdraw money quickly and easily after
  authorization. The user interacts with the system
  through a card reader and a numerical keypad. A
  small display screen allows messages and
  information to be displayed to the user. Bank
  members can access special functions such as
  ordering a statement

11
Teaching SessionsDesign Workshops

• There will be a design workshop each week
• work together in small teams
• focus on a single design task
• Based around structured design exercises
• work through the development process
• hands-on experience of design techniques
• develop understanding of lecture material

12
Formal Assessment

• Assessment for the course
• is based entirely on coursework
• focuses on a single software design task
• Assessed work will consist of
• two submissions of design documentation
• an oral presentation
• Each submission for assessment will involve
• a team component
• an individual component

13
Design TaskOnline Bookshop
Statement of Purpose The eVersity online bookshop
allows students and staff to purchase course
books quickly and easily. A user is able to
browse the book catalogue or search for
individual items by title or author. Required
books may be added to a purchase order. Payment
is by debit card although college staff can also
pay by salary deduction. College tutors can order
in textbooks for courses that they teach.
14
Why Teamwork?

• Software design is usually a team effort
• Real-world software systems too large and complex
  to be tackled by a single individual
• good design requires various sorts of expertise
• Successful design projects need
• planning,
• communication
• management
• Teamwork plays a central role in this course

15
Course Texts

• Key text
• Pooley, R and Stevens P (1998) Using UML
  Software Engineering with Objects and Components,
  Addison-Wesley
• Recommended texts
• Lunn, K. (2003) Software Development with UML,
  Palgrave
• Bennet, S, McRobb, S, and R Farmer (2002)
  Object-Oriented Systems Analysis and Design,
  McGraw-Hill
• Bennet, S, Skelton, J and K Lunn (2001) UML,
  Schaums Outlines series, McGraw-Hill
• Budgen, D (1994) Software Design, Addison-Wesley

16
Other Resources

• The course web site
• Course outline information
• Lecture notes
• Seminar notes
• Details of design task and exercises
• Etc. etc.
• Look under
• Informatics home gt teaching gt course directory
• or
• http//www.cogs.susx.ac.uk/users/billk/sd.html

17
Summary

• The course covers key ideas in
• object oriented analysis and design
• UML
• Teaching is provided by a combination of
• lectures
• hands-on design workshops
• Assessment is entirely by coursework
• Based on a single design task
• Students work together in design teams

18
Lecture 2 Software Development

• Software Development Terminology
• Design Objectives and Design Problems
• Why Do Things Go Wrong?
• Project Life Cycles
• The waterfall model
• The spiral model
• The Unified Process

19
Software DevelopmentTerminology

• Systems Analysis
• Process of seeking to understand organization of
  system
• Investigation and modelling of system
  requirements
• Software Design
• Process of producing solution to analysed
  requirements
• Specifying detail of how system will meet
  requirements
• Software Engineering
• Application of a systematic, disciplined approach
• Adherence to high standards of professional
  ethics

20
What Do We Need?

• We need software that is
• Useful and usable fit for purpose
• Reliable free of bugs
• Flexible can adapt to changing needs of users
• Affordable to buy and to maintain
• Available delivered, portable and maintainable
• Objectives are
• Easy to state, but
• may be hard to achieve in practice!

21
What Are the Problems?

• Total failure of software
• The London Ambulance Service
• TAURUS stock trading system
• ARIANE 5 Launcher
• August 14th 2003, east coast USA power blackout
• Failure can be catastrophic and very costly
• but, its the exception rather than the rule
• Nature of problem depends on stakeholder you ask
• The end users
• The clients
• The software developers

22
The End-users Perspective

• The new system doesnt
• do the right thing
• wrong tasks
• incomplete
• do things right
• dreadful to use
• poor interface
• doesnt arrive
• vapourware!

23
The Clients Perspective

• I would never have agreed if
• Id known the cost
• Development costs way over budget
• Id know how long it would take
• It was needed months ago
• The system is already obsolete
• Id had a choice
• I didnt want it in the first place!

24
The Developers Perspective

• Dont blame me
• Its what you said you wanted
• I cant help it if youve changed your minds
• Its the best I could do in the time available
• Ive never done Java/OOA/GUI design/etc.
  before
• I always said it was impossible anyway
• I dont know how its supposed to work
• The systems fine
• its the users!

25
Why Do Things Go Wrong?

• No one reason for failure
• Complexity of software
• Complexity of development process
• Failures broadly due to
• Unacceptable quality
• Poor productivity

26
Avoiding the Problems

• We need to
• Adopt a well-defined development process
• Clear phases with deliverables
• Built in verification and validation
• Effective management
• Be clear about project requirements
• Make use of relevant knowledge
• Make sensible use of tools

27
Project Life Cycles

• The development process can be divided into
  various phases
• A number of different models
• The traditional waterfall life cycle
• The spiral model (Boehm 1988)
• The unified process

28
The Waterfall Life Cycle
Waterfall model process moves from one stage to
another, but never back!
Analysis
Design
Construction
Testing
Deployment
Maintenance
29
Pros and Cons of the Waterfall

• Advantages
• Highly structured with clear phases and
  deliverables
• Easy to evaluate project progress
• Can be effective for risk management
• Disadvantages
• Requires perfect decision-making
• Projects rarely follow a simple sequence
• Iterations and revisions are almost inevitable

30
Waterfall with Iteration
Analysis
Models ability to revise earlier stages in the
process.
Design
Construction
Testing
Deployment
Revision can be costly and difficult to manage
Maintenance
31
The Spiral Model (Boehm 1988)
Evaluate
Design, deploy, test
Analyse risks and plan
Analyse requirements for this iteration
32
Advantages of the Spiral Model

• Iteration
• embraces iterative nature of process
• Prototyping
• each loop of the spiral leads a system prototype
• Risk analysis
• adds notion of risk management as a central
  concept

33
The Unified Process(Booch, Jacobson, Rumbaugh)

• Four distinct phases
• Inception determine scope and purpose of the
  project
• Elaboration requirements capture and system
  architecture
• Construction build software system
• Transition installation
• Workflows within each phase
• Requirements, Analysis, Design, Deployment, Test

34
The Unified Process

• Project passes through four stages in a
  sequential manner (phases)
• Iterations occur within each phase (spiral model)
• Each iteration involves a series of different
  activities (workflows)
• Amount of work spent on each activity changes
  between phases/iterations

35
Other Process Models

• Phased release model
• Waterfall extended to include incremental
  development
• The evolutionary model
• Emphasizes overlap in loops of spiral model
• Makes explicit differing amounts of effort
  needed
• Concurrent engineering model
• Accounts for the divide and conquer principle
• Extreme programming

36
Summary

• Software development is a complex process
• Many possible paths from start to end-product
• Involves balancing needs of various stakeholders
• Development has distinct stages (waterfall)
• Software life cycle iterative (e.g. spiral)
• Prototyping
• Risk management
• There is no one best process model
• Different methodologies suit different projects

37
Lecture 3 Object-Orientation

• What is object-orientation?
• Analysis, Design and Programming
• Why object-orientation?
• Objects concepts
• State, behaviour and identity
• Abstraction and Encapsulation
• Modularity
• Classes and inheritance
• Summary

38
What is Object Orientation?

• An approach to problem-solving which
• organizes process and data around discrete,
  coherent units known as objects
• represents real-world entities in terms of
  objects and their composition
• models system behaviour in terms of object
  interaction

39
OOA, OOD and OOP

• OO Analysis uses object concepts to analyse a
  particular problem domain or existing system
• OO Design uses objects to model static and
  dynamic aspects of a proposed application
• OO Programming uses objects and classes to
  organize code

40
Why object-orientation?In the beginning

• First computer languages mixed process and data
• machine code, assembler language
• difficult to produce limited in application
• Second generation languages separated data from
  process
• Cobol, Fortran, Pascal, C
• programs data structures algorithms
• Batch data-processing applications served well
• large-scale banking applications scientific
  calculation

41
Why object-orientation?Batch and Interactive
Systems

• Batch systems process lots of similar data at
  once
• e.g. run all the payroll calculations overnight
• fixed process with little variation from run to
  tun
• Modern interactive systems do things differently
  
• small sets of relevant data processed almost
  instantly
• event-driven user interfaces with much
  flexibility
• This needs different organization of software
• group bits of processing and related data
  together
• organize software around collaborating objects

42
Why object-orientation?

• Object-oriented languages emerged in modern form
  around 1980
• Smalltalk and OO window system released by Xerox
• Subsequently C, Java etc.
• Objects provide a natural and productive way of
  developing interactive systems
• Natural to think of GUIs in terms of different
  objects
• Objects can be linked to provide complex
  behaviours
• Objects support code re-use

43
What is an object?

• Objects are the building blocks of OO systems
• An object
• has attributes that define its state
• has operations that define its behaviour
• has an identity distinct from other objects
• A well-designed object
• Provides a coherent view of something
  (abstraction)
• Limits access to just what is needed
  (encapsulation)

44
State, Behaviour and Identity

• State all the data that an object encapsulates
  (values of attributes)
• what do I know?
• Behaviour the way in which an object reacts to
  messages that it understands
• what can I do?
• Identity objects persist you can refer to
  object by name identity versus equality
• who am I?

45
Abstraction

• Object typically represent real-world entities
• Physical things (buildings, people, peripherals)
  
• Conceptual entities (dates, plans)
• Objects abstract away from inessential details
• Procedural abstraction
• dont need to know how a procedure is
  implemented, just how to communicate with it
• Data abstraction
• collect together relevant data

46
Example Objects and Abstraction
samEmployee
dob 17.02.80 address 20, Foobar
Road height 5 feet 8 inches
weight 112lb eye_colour blue
hair_colour brown shoe_size 8
..


47
Encapsulation

• Details of objects implementation hidden
• Only way that an object can be manipulated is
  through its operations
• Consequently, users dont need to know
• State how data is represented or structured
• Behaviour how operations are implemented
• Object has a well-defined interface
• public provide access to essential data and
  methods
• private for internal use only

48
Example Object and Interface
An object has a public and a private interface
Attributes hidden from view
All interaction with the object must go through
the operations
49
Modularity

• Modular systems have discrete units with
• high cohesion package together
  relevant/coherent information (abstraction)
• low coupling provide clean and limited
  interface (encapsulation)
• Modular systems are easier to
• understand (high cohesion is intuitive)
• modify (low coupling/dependency between modules)
• extend

50
Class, Instance and Object

• Objects may have much in common
• e.g. employees of a company share certain
  properties and behave in similar ways
• In class-based OO languages
• Classes describe commonality
• Objects belong to classes (are instances of
  classes)
• Ensure consistency of behaviour
• Provide for type-checking

51
Classes and Inheritance
Classes organized hierarchically
Employee
Manager
Technician
Classes lower down inherit properties of those
higher up.
ProjectManager
52
Summary

• Object orientation is an approach to problem
  solving
• Object orientation grew from the need for
  interactive software systems
• Objects have behaviour, state and identity
• abstraction (high cohesion)
• encapsulation (low coupling)
• Classes capture common properties of objects
• Inheritance hierarchy

53
Lecture 4 Requirements and Use Cases

• Requirements capture
• Requirements modelling
• Use-cases
• UML Use-Case Diagrams
• Basic notation
• Use-Case Descriptions
• Other notation generalizes, includes, extends

54
Requirements Capture

• Aim to develop system to meet user needs
• Capture user requirements capture through
• Background reading/research
• Interviews with users/clients
• Observation of current practices
• Sampling of documents
• Questionnaires
• This is hard!

55
Functional and Non-Functional Requirements

• Functional requirements
• What processing system must perform
• Details of inputs and outputs
• Details of data held by system
• Non-functional requirements
• Performance criteria (time/space)
• Security
• Usability requirements
• HCI issues

56
ATM Case StudyStatement of Purpose

• The design task is to implement an Automated
  Teller Machine (ATM)
• An ATM is an electronic device designed for
  automated dispensing of money. A user can
  withdraw money quickly and easily after
  authorization. The user interacts with the system
  through a card reader and a numerical keypad. A
  small display screen allows messages and
  information to be displayed to the user. Bank
  members can access special functions such as
  ordering a statement

57
ATM Case StudyRequirements Summary

• To allow card holders to make transactions
• To view and/or print account balances
• To make cash withdrawals
• To allow bank members to access special services
• To order a statement
• To change security details
• To allow access to authorized bank staff
• To re-stock the machine
• To keep track of how much money it contains

58
Use Cases

• Use cases used to model functionality
• What system does, not how
• Focus on functionality from users perspective
• not appropriate for non-functional requirements
• UML use case diagrams
• Document system functionality
• Useful for communicating with clients/users
• Supported by more detailed descriptions of system
  behaviour (e.g. text documents, other UML
  diagrams)

59
UML Use Case Diagrams
Communication association
Withdraw Cash
(Sub)system boundary
Check Balance
CardHolder
Actor
Use case
60
Basic Notation

• Use case diagrams show
• Actors people or other systems interacting with
  system being modelled
• Use cases represent sequences of actions
  carried out by the system
  
• Communication between actors and use cases

• Withdraw
• Cash

61
Behaviour Specifications

• Document sequence of actions carried out by
  system to realize a use case
• Other UML diagrams e.g.
• sequence diagrams (lecture 9)
• activity diagrams (lecture 11)
• Textual description
• use-case descriptions
• use-case scenarios

62
Simple Use Case Description

• Outline of typical sequence of activities
• The primary flow or path
• ATM system example

63
Elaborated Use-Case Description
Actor
System
64
Scenarios

• Use case represents a generic case of interaction
• A particular course that a use-case instance
  might take is called as scenario
• For example, there may be many Withdraw Cash
  scenarios where no cash is withdrawn!
• Card holder has insufficient funds on account
• ATM cannot connect to banks system
• ATM does not contain enough cash
• Customer cancels the transaction for some reason

65
Example Scenarios

• CardHolder Mary Jones selects the cash withdrawal
  menu. She changes her mind, cancels the
  transaction and takes her card
• CardHolder Peter Smith selects the cash
  withdrawal menu. He selects a cash amount, but is
  refused because he has insufficient funds on his
  account. His card is returned

66
Other Types of Relationship

• Generalizes
• Permits actors/use cases to inherit properties of
  more general actors/use cases
• Include
• Permits use case to include functionality of
  another use case
• Extend
• Allows for optional extensions of use case
  functionality

67
Generalizes Relationship
BankMember specializes CardHolder
Withdraw Cash
CardHolder
Check Balance
Order Statement
Generalizes Relation
BankMember
68
Include Relationship
Select Account is included in each of the use
cases
Withdraw Cash
include
include
Check Balance
Select Account
BankMember
Order Statement
include
Note include was formerly called uses
69
Extend Relationship
CardHolder has the option of printing out a
balance when the Check Balance use case is
invoked.
Print Balance
extend
Check Balance
Extend relationship
CardHolder
70
Summary

• Use case analysis often a first step in system
  development
• provide high-level view of system functionality
  (what rather than how) and its users
• Model generic activities
• Particular instances of use-cases are termed
  scenarios
• UML use case diagrams
• Contain actors, use cases and associations
• supported by behaviour specifications (e.g.
  use-case descriptions)

71
Lecture 5 An Overview of UML

• Background to UML
• A little history
• What UML is, and what it is not
• Models and Diagrams
• Use-case diagram
• Activity diagram
• Class diagram
• Interaction diagram
• UML Tools

72
A Little History

• Late 1960s
• Emergence of OO programming languages
• Simula-67, Smalltalk (1970)
• 1970s
• Appearance of first OOAD methodologies
• 1980s and early 1990s
• Many competing general development methods and
  modelling languages (over 50)
• The methods wars

73
Emergence of UML

• By the mid 1990s three key methods had become
  prominent
• Rumbaugh Object Modelling Technique
• Booch Booch 93 OO Analysis and Design
• Jacobson OO Software Engineering
• 1995 Rumbaugh, Booch and Jacobson join forces in
  Rational
• Develop the (Rational) Unified Process
• Develop the Unified Modelling Language (UML)

74
UML is.

• A ready-to use visual modelling language
• A language, not just a notation
• For OO analysis and design of (software) systems
• UML diagrams provide for various views of systems
• Simple and expressive
• UML has core set of expressive concepts/notations
• Extensible
• allows specialization/addition of
  concepts/notations
• An emerging standard for modelling systems

75
UML is not

• A visual programming language
• UML is for modelling/conceptualizing/visualizing
  systems, not for implementing them
• Not tied to a particular programming language
• A development process
• UML is process neutral
• Not tied to a particular process (e.g. Unified
  Process)
• A development tool
• A guarantee of success

76
System, Design, Model, Diagram

• Important to be clear about terminology
• System program or collection of programs meeting
  user requirements end goal of the development
  process
• Design collection of decisions about how to
  build system end product of the design process
• Model abstract representation of system or
  design from a particular viewpoint a product of
  some stage of the design process
• Diagram visual representation of (part of) model
  

77
Models and UML Diagrams

• Use case model describes the high level
  functionality of system from users point of view
• UML use case diagram UML activity diagram
• Static model describes the elements of system
  and their organization and relationships
• UML class diagram UML package diagram
• Dynamic model describes behaviour of system over
  time
• UML collaboration diagram UML sequence diagram
  UML statechart diagram

78
UML Use Case Diagram
Check Balance
extend
Print Balance
include
CardHolder
Withdraw Cash
Select Account
include
Order Statement
include
BankMember
79
UML Activity Diagram
ATM Customer
ATM System
Select withdrawal
Display menu
Insufficient funds
Select amount
Sufficient funds
User takes card
Notify user
Return card
Dispense cash
80
UML Class Diagram
1..3

CardHolder
holds
Simple ATM class diagram, showing static
structure for banking domain
Debit
Credit
81
UML Collaboration Diagram
Collaboration diagram with interactions realizing
the Withdraw Cash use case
82
UML Sequence Diagram
ATMUI
CashDispenser
ATMControl CardHolder Account
select withdrawal menu
select amount
withdraw sum
withdraw sum
Debit
add debit
debit account
dispense sum
return card
83
UML State Diagram
exit /balance 0
withdraw(sum) /balance -sum
withdraw(sum) /balance -sum
withdraw(sum) sum gtbalance /balance -sum
inDebit entry/balance - pen
inCredit
deposit(sum) sum gt balance /balance sum
deposit(sum) /balancesum
deposit(sum) /balancesum
close
close
84
UML CASE Tools

• Poseidon UML Standard Edition
• A professional UML Case tool provided on lab PCs
• Poseidon UML Community Edition
• A cut-down version of the above that is freely
  downloadable from http//www.gentleware.com/
• Rational Rose
• Can be run from Sun machines. In .login file add
  the line source /local/global/rational_logi
  n
• To run, at prompt do
  rose
• Eclipse Omohondro plug-in
• Useful if you like Eclipse, though not fully
  featured as yet.

85
UML Drawing Tools

• Some drawing tools incorporate UML diagrams
• e.g. dia http//dia-installer.sourceforge.net/
• But for small design tasks, any half-way decent
  drawing package will probably do
• All the UML drawing in these lectures were
  produced with Windows AutoShapes
• Or you could just use paper and pencil
• Remember the goal is good design rather than
  pretty pictures!

86
Summary

• UML is a an expressive and flexible visual
  modelling language
• Emerged in the mid 90s,
• Combines ideas from several notations
• Should distinguish between
• System, design, model and diagram
• UML supports modelling from different viewpoints
• Functional view
• Static view
• Dynamic view

87
Lecture 6 Class Models and Diagrams

• Class models
• What makes a good class?
• Developing the class model
• Finding classes and associations (Part 1)
• Noun identification
• Basics of UML Class Diagrams
• Class notation
• Associations
• ATM Case Study initial class model

88
What is a Class Model?

• Model of the static structure of a system
• What classes are there?
• How are these classes related?
• Allocation of class responsibilities
• Management of data within the system
• Behavioural responsibilities of classes
• May not be immediately concerned with
• functional requirements
• how classes interact to achieve behaviour

89
What Makes a Good Class Model?

• A good class model consists of classes that
• can provide all of the required system behaviour
• represent (as far as possible) enduring domain
  objects
• If 1 is self-evident, 2 is more like an act of
  faith
• part of the object oriented design philosophy
• modelling the application domain can provide a
  good basis for developing the required software
• in practice, need to compromise between 1 and 2

90
Developing the Class Model

• Class model typically developed in stages
• Analysis phase
• Classes in problem domain of primary interest
• Basic relationships between classes
• Little detail about class responsibilities
• Design phase
• Additional classes provided for implementation
• Class responsibilities (attributes, operations)
  refined
• Relationships between classes refined

91
Finding Classes and Associations

• How do we find classes?
• Doesnt really matter, as long as the resulting
  class model is good!
• Were unlikely to get it right first time
• Probably shouldnt even try!
• Finding classes and associations is a process of
• Evolution
• Revolution

92
Noun Identification

• A way of finding enduring domain objects
• A data driven development (DDD) method
• Useful in early stages of development (analysis)
• Provides first-cut set of problem classes
• Useful in analysis of requirements
• Pick out all nouns/noun phrases in requirements
  documentation
• Filter out inappropriate expressions
• Use remaining phrases as candidate classes

93
ATM Case StudyFinding Candidate Domain Classes

• Step 1 underline nouns/noun phrases
• An ATM is an electronic device designed for
  automated dispensing of money. A card holder can
  get a balance, or withdraw money from an account
  after authorization. Customers interact with the
  system through a simple interface consisting of a
  display screen, a card reader and a numeric
  keypad. Cash is obtained from a dispenser. Bank
  members are card holders who can access
  additional functions such as ordering a statement
  from the bank

94
ATM Case Study Finding Candidate Classes

• Stage 2 Discard candidates that are
• Events dispensing of money, authorization
• Vague function, device
• Meta-language terms system
• Redundant terms customer same as card holder
  cash same as money
• Outside scope of system bank
• but retain actors such as card holder?
• Constitute everything ATM (system)
• Avoid monolithic design!

95
ATM Case Study Finding Candidate Classes

• Remaining nouns represent candidate domain
  objects/classes
• Actor/Role entities card holder, bank member
• Boundary (interface) objects interface, card
  reader, keypad, display screen, cash dispenser
• Entity (domain) objects balance, money,
  account, statement
• This analysis provides the initial set of classes
  in the ATM class model.

96
Basics of UML Class Diagrams

• Notation for documenting class models
• Notation for classes
• Rectangle with class name (minimally)
• Details of attributes and operations
  (additionally)
• Notation for relationships
• Associations model dependencies between classes
• Generalizations model is a relationships
  between classes
• Model represented by one or more class diagrams

97
Basics of UML Class Notation
Only class name shown
Operations shown
CardHolder
Both attributes and operations shown, with type
information
98
Basics of UML Associations
In the banking domain each CardHolder has an
Account
Simple association between classes
holds
Named association
99
What Do Associations Imply?

• An association implies collaboration between
  instances of two classes
• Classes A and B are associated if an instance of
  A needs to know about an instance of B
• A needs to know about B if an instance of A
• sends a message to an object of class B, or
• has an attribute with a value of class B, or
• creates an object of class B, or
• receives a message with an object of class B as
  an argument

100
ATM Case Study Initial Class Model
Initial class diagrams for the ATM System
101
Summary

• Class model represents static structure of system
• Classes and their relationships
• Developing class model is a staged process
• May begin by identifying classes in application
  domain
• Later add classes required for implementation
  reasons
• Noun identification is a simple analysis
  technique for finding domain classes
• UML class diagrams used to document class model

102
Lecture 7More About Class Diagrams

• More about associations
• navigability
• multiplicity
• aggregation and composition
• The generalizes relationship
• More about attributes and operations
• type information and visibility
• ATM Case Study
• Refining the ATM class model and refactoring

103
Navigability

• Consider CardHolder and Account again
• The diagram does not specify which way the
  association is supposed to be navigated
• Does CardHolder know about Account?
• Does Account know about CardHolder?
• In the absence of more specific information
• Each knows about the other

104
Showing Navigability

• Navigability may be shown with an arrow

CardHolder knows about Account (not vice-versa)

• Named association usually implies direction

Direction given by arrow head
105
Multiplicity

• So far, associations tell us nothing about how
  many objects are involved
• Does a CardHolder hold
• just one Account ?
• several Accounts ?
• Can one Account belong to many CardHolders?

106
Adding Multiplicities

• Specify number of objects involved
• An exact number, such as 1, 3 or 100
• A range of numbers, such as 1..10
• An arbitrary number

Each CardHolder holds one or more Account
Each Account is held by exactly one CardHolder
1
1..
107
Aggregation and Composition

• Provide detail about the kind of association
• Aggregation
• Records whole-part structure
• Composition
• as aggregation, but
• implies strong ownership

108
Using Aggregation
Use when there is clear part-whole structure
The aggregate (whole) end of the association
Each account consists of or includes debits and
credits
1
1
Aggregation symbol
0..
0..
Each debit and credit is part of one account
The part end of the association
109
Using Composition

• Used to indicate strong ownership
• coincident lifetime of objects
• part cannot exist without whole and vice-versa

Notation for composition
ATMUI
1
1
1
CardReader
Screen
KeyPad
110
Generalization

• A conceptual relationship between classes
• the kind-of or is-a relation
• e.g. BankMember is a kind of CardHolder
• Makes a strong claim about behaviour
• a BankMember can do anything a CardHolder can do
• the classes conform to the same interface

111
Notation for Generalization

• Any BankMember is a CardHolder (but not
  necessarily vice-versa).
• This implies that a BankMember object
• should behave appropriately if treated as a
  CardHolder
• will exhibit additional behaviours

112
Generalization and Inheritance

• In OOP, generalization is implemented as
  inheritance
• Powerful mechanism for code re-use, but beware
• may increase dependency between classes
• not always appropriate

public class BankMember extends CardHolder . .
. .
113
More On Attributes and Operations

• Refining details of class responsibilities

114
ATM Case Study Refining the Class Model

• Adding navigability, multiplicities, aggregation
  and generalization

CardHolder
Balance
1..3
1
authorize()
BankMember
115
Design Note Refactoring
It seems that the Debit and Credit classes have
quite a bit in common. Is there an alternative
way of structuring things? Does this lead to
better design and if so, how?
116
Design Note Refactoring
The new Transaction class factors out the common
elements of the Debit and Credit classes. This is
known as refactoring. Is the refactored design
better and if so, in what way?
117
Summary

• Development of class model is to some extent a
  process of refinement
• Navigability (direction of association)
• Multiplicities (cardinality of associations)
• Aggregation and composition (part-whole)
• Generalization relationship between classes
• Promotes code-reuse
• Refactoring

118
Lecture 8 Collaboration

• Views and Diagrams
• Responsibility-Driven Design (RDD)
• Class-Responsibilities-Collaborators (CRC) Cards
• Using CRC cards
• Collaboration
• What is collaboration
• UML Notation for Objects and Links
• Basics of UML Collaboration Diagrams
• Collaboration and Interaction
• Showing interaction
• Realizing use cases

119
Views and Diagrams

• Different views of software system
• Functional (user) view
• use case diagram
• Structural (static) view
• class diagram
• Behavioural (dynamic) view
• collaboration diagram
• sequence diagram
• state-chart diagram

interaction diagrams
120
Responsibility-Driven Design

• Responsibility-Driven Design (RDD)
• Responsibility for data
• Responsibility for behaviour
• Based on examination of
• collaboration between classes
• interaction needed to fulfil some required
  behaviour
• Develop class model by identifying
• operational requirements of classes
• collaboration between classes

121
Class-Responsibility-Collaboration (CRC) Cards

• A simulation technique
• enact collaboration between classes
• e.g. walk-through a use-case scenario
• Useful technique for allocating responsibilities
• required attributes and operations
• new classes required for implementation
• May be used at various stages in development
• early on, to develop initial class diagram
• later, to model object interaction

122
CRC Card Example
Class name
Brief list of responsibilities
Brief list of collaborators
123
Using CRC Cards

• Group role-play activity
• Brainstorm to identify roles/objects involved in
  required behaviour (e.g. a use-case)
• Create CRC cards for roles/objects
• Allocate each role/object to a team member
• Enact the behaviour
• Identify/record missing responsibilities
• Go back to 4., if needed

124
What is Collaboration?

• In object-oriented systems
• individual objects are responsible for only a bit
  of overall functionality
• useful high-level behaviour (use cases) realized
  by objects working together
• objects interact by sending messages to each
  other
• Collaboration is working together for the
  purpose of providing some useful behaviour
• documented by collaboration diagrams

125
ATM Case Study Withdrawal Use-Case Realization
Withdraw Cash
ATMCustomer
126
ATM Case Study Identifying Collaborating
Classes
The dashed line indicates that this class
participates in the collaboration
Collaboration icon
Withdraw cash
ATMUI
Debit
Account
CashDispenser
CardHolder
127
UML Collaboration Diagrams

• Collaboration diagrams involve
• Objects instances of classes
• Links instances of associations
• Actors things/people interacting with the
  system
• A collaboration will also usually show
• Interactions the sequence of messages passing
  between objects

128
UML Notation for Objects
An object named user391
An anonymous object of class CardHolder
CardHolder
user391
Objects are notated rather like classes, but
attributes and operations are omitted
user391CardHolder
An object named user391 of class CardHolder
129
UML Notation for Links
Links drawn as for associations.
Links may have multiplicities
Links are instances of associations in the class
model Links represent message passing between
collaborating objects
130
ATM Case Study Classes Involved in the Use Case
Portion of the class model involved in realizing
the Withdraw Cash use case.
ATMUI
CardHolder
CashDispenser
Account
Debit
131
ATM Case StudyWithdrawal Collaboration Diagram
ATMUI
CardHolder
ATMCustomer
Tentative collaboration diagram for Withdraw Cash
use. Note the structural similarity to the class
model shown previously.
CashDispenser
Account
Debit
132
Collaboration and Interaction

• Individual objects have local responsibilities
• For data
• For behaviour
• Objects interact to achieve global behaviours
• Use case realization
• Collaboration diagrams show interaction through
• Structural relationship objects and links
• Interaction messages flowing along links

133
UML Notation for Interactions
Message number
Message name
7 get balance()
CardHolder
Account
Messages are sent between objects along the links.
Message flow has direction of arrow
134
ATM Case StudyCollaboration with Interaction
Collaboration diagram with interactions realizing
the Withdraw Cash use case
135
Summary

• Individual objects are responsible for small
  pieces of behaviour
• High-level functionality is achieved through
  object collaboration
• UML Collaboration Diagrams show
• Participating objects and links between objects
• Interactions (messages sent between objects).
• Stereotypes provide a mechanism for
  distinguishing between different sorts of object.

136
Lecture 9 Collaborations and Interactions

• Object stereotypes
• Entity, boundary and control objects
• Basics of Interaction Sequence Diagrams
• Objects and life-lines
• Messages and control
• ATM Case Study the withdrawal use-case
• Collaboration diagram with interactions
• Interaction sequence diagram

137
More about UML Objects Stereotypes

• Provide a means of indicating that certain
  objects have special roles
• UML has three distinct stereotypes
• entity objects model things in the application
  domain that the system needs to keep information
  about.
• boundary objects mediate communication with the
  outside world.
• control objects organize complex behaviours
  involving various boundary and entity objects.

138
Entity and Boundary Notations
Named entity object
Alternative notations for stereotyped classes
ATMUI
Boundary object
139
ATM Case StudyEntity and Boundary Collaboration
1select withdrawal menu 2select amount
ATMCustomer
Withdraw cash use case collaboration showing
boundary and entity objects
140
Design Note Responsibility-Driven Design
Do the responsibilities of the CardHolder class
seem coherent and reasonable? How do they compare
to the CRC card we drew earlier? Is there a
better way of sharing out the behaviour?
3withdraw sum
6dispense sum
ATMUI
CardHolder
CashDispenser
4debit account
141
Design NoteResponsibility-Driven Design
CardHolder collaborates with Account But should
it need to know about the CashDispenser?
142
Design NoteResponsibility-Driven Design
1select withdrawal menu 2select amount
3withdraw sum
7dispense sum
8return card
ATMUI
CashDispenser
ATMControl
ATMCustomer
4withdraw sum
5debit account
New ATMControl object mediates between boundary
and entity objects
6add debit
CardHolder
143
Interaction Sequence Diagrams

• An alternative to collaboration diagrams
• Show objects involved in a collaboration
• but, not the structural relationships between
  objects
• underlying collaboration is left implicit
• Show order of interaction graphically
• c.f. textual representation in collaboration
  diagrams using message numbering
• Visual representation of time can be clearer

144
Basics of UML Sequence Diagrams

• Interaction sequence diagrams show
• Objects and actors
• just as for collaboration diagrams
• Object life-lines
• represent time as seen from a given object
• time passes as we move from top to bottom of
  diagram
• Messages and control
• messages flow between object life-lines
• focus of control changes as messages are sent

145
Notation for Objects and Lifelines
objects
Objects are shown along the top of the diagram
time
Object life-lines are shown as dashed lines
running from top to bottom of diagram
146
Notation for Messages and Control
ATMUI
CardHolder
debit account
Focus of control shown as narrow rectangle
Message shown using an arrow from sender to
receiver
Focus of control passes from one object to
another as messages flow between them
147
ATM Case StudySequence Diagram for Withdrawal
CashDispenser
ATMUI
CardHolder
Account
ATMControl
select withdrawal menu
select amount
withdraw sum
Debit
withdraw sum
add debit
debit account
dispense sum
return card
148
Withdrawal Use CaseEntity, Boundary and Control
ATMUI
CashDispenser
ATMControl CardHolder Account
select withdrawal menu
select amount
withdraw sum
withdraw sum
Debit
add debit
debit account
dispense sum
return card
149
ATM Case StudyRestructuring the Class Model
CardHolder getBalance withdraw
1..
1
1

0..
1
1
1
ATMControl
ATMUI
1
1
CashDispenser
Credit
Debit
150
Summary

• Objects interact by passing messages
• Interaction diagrams document behavioural view
• Collaboration diagrams
• show messages passing between objects along links
• provide textual representation of control flow
• Interaction sequence diagrams
• Show objects and life-lines
• Provide visual representation of control flow

151
Lecture 10 Object Behaviour

• The Behavioural view
• state and behaviour
• Basics of UML Statechart Diagrams
• states, transitions and events
• guard conditions
• actions
• ATM Case Study
• State Diagram for the Account Class
• Activity Diagrams

152
The Behavioural View

• The behavioural view describes
• Interactions between objects to realize
  high-level functionality
• Collaboration diagrams
• Interaction Sequence diagrams
• Behaviour of individual objects in response to
  events
• Statechart diagrams

153
State and Behaviour

• In lecture 3 we saw that objects have
• State all the data that an object encapsulates
  (values of attributes)
• Behaviour the way in which an object reacts to
  messages that it understands
• Object behaviour
• depends on state
• involves changes of state

154
Some Questions about State

• What is meant by the state of an object?
• Depends on attribute values, but
• State is an abstraction
• Should objects have lots of states, or a few?
• Too many states makes object behaviour difficult
  to characterize/understand
• Can consideration of state inform class design?
• Split classes with too many states into simpler
  classes

155
Basics of Statechart Diagrams

• Describe the behaviour of individual model
  elements
• mostly used to model behaviour of objects
• but, can be used for other things
• Statechart diagrams consist of
• States of objects
• Transitions between states
• Events driving transitions
• Actions performed by objects

156
States and Transitions
Simple states
Start state
Transitions
Basic statechart diagram for the Account class
End state
157
Transitions and Events

• transitions are triggered by events

Name of event triggering the transition
open
Transitions between states depend on events
close
close
158
Guard Conditions

• Written alongside associated event
• event guard
• e.g.
• Condition must hold for event to trigger
  transition

159
Actions

• Events typically bring about actions
• Events are things that happened to an object
• e.g. receipt of a message
• Actions are things that an object does
• e.g. sending a message
• Actions may be shown either
• on transitions
• on states

essentially equivalent
160
Actions on Transitions

• Written alongside event
• event / action
• event guard / action
• e.g.
• Use where action depends on the transition

withdraw(sum)/balance balance - sum
inCredit
inDebit
deposit(sum)/balance balance sum
161
Actions on States

• Written within state
• entry / action
• exit / action
• e.g.
• Use where action depends on state

162
ATM Case Study State Diagram for Account Class
exit /balance 0
withdraw(sum) /balance -sum
withdraw(sum) /balance -sum
withdraw(sum) sum gtbalance /balance -sum
inDebit entry/balance - pen
inCredit
deposit(sum) sum gt balance /balance sum
deposit(sum) /balancesum
deposit(sum) /balancesum
close
close
163
Summary

• Objects have state and behaviour
• behaviour depends on state
• Statechart diagrams describe object behaviour
• events trigger transitions between states
• transitions may depend on guard conditions
• events can result in actions
• Activity diagrams
• share much notation with state diagrams
• different purpose

164
Lecture 11Other UML Notations

• Activity Diagrams
• Documenting workflows
• Basic Notation
• ATM Case Study withdrawal use-case
• Packages and Subsystems
• Implementation Diagrams (very briefly)
• Component diagrams
• Deployment diagrams

165
UML Activity Diagrams

• Used to document workflows
• Modelling business activities or systems
• Modelling activities within/between use-cases
• Detailed description of operations in classes
• Similar notation to UML statechart diagrams
• Activities (action states)
• States
• Transitions

166
Activity Diagrams Basic Notation
Start state
Activities
Transitions
Simple Activity Diagram with start and stop states
Final state
167
Activity Diagrams Decision Points
De