Title: Software Design
1Software Design
- An Introduction to Object Oriented Analysis and
Design Using the Unified Modelling Language
Bill Keller Spring 2004
2Lecture 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
3What 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
4What 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
5Course 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
7Why 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
8Teaching Sessions Lectures
- Generally there will be two lectures each week
- Monday ?? in the Biology Lecture Theatre
- Wednesday ?? in the Biology Lecture Theatre
Weeks of term Lectures
1 4 1 8
5 no set lectures
6 8 9 14
9 no set lectures
10 no set lectures
9Lecture 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
10Design 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
11Teaching 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
12Formal 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
13Design 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.
14Why 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
15Course 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
16Other 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
17Summary
- 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
18Lecture 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
19Software 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
20What 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!
21What 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
22The 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!
23The 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!
24The 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!
25Why Do Things Go Wrong?
- No one reason for failure
- Complexity of software
- Complexity of development process
- Failures broadly due to
- Unacceptable quality
- Poor productivity
26Avoiding 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
27Project 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
28The Waterfall Life Cycle
Waterfall model process moves from one stage to
another, but never back!
Analysis
Design
Construction
Testing
Deployment
Maintenance
29Pros 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
30Waterfall 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
31The Spiral Model (Boehm 1988)
Evaluate
Design, deploy, test
Analyse risks and plan
Analyse requirements for this iteration
32Advantages 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
33The 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
34The 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
35Other 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
36Summary
- 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
37Lecture 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
38What 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
39OOA, 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
40Why 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
41Why 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
42Why 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
43What 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)
44State, 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?
45Abstraction
- 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
46Example 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
..
47Encapsulation
- 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
48Example 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
49Modularity
- 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
50Class, 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
51Classes and Inheritance
Classes organized hierarchically
Employee
Manager
Technician
Classes lower down inherit properties of those
higher up.
ProjectManager
52Summary
- 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
53Lecture 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
54Requirements 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!
55Functional 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
56ATM 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
57ATM 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
58Use 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)
59UML Use Case Diagrams
Communication association
Withdraw Cash
(Sub)system boundary
Check Balance
CardHolder
Actor
Use case
60Basic 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
61Behaviour 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
62Simple Use Case Description
- Outline of typical sequence of activities
- The primary flow or path
- ATM system example
63Elaborated Use-Case Description
Actor
System
1 User selects cash withdrawal option System displays cash withdrawal menu
2 User selects cash amount System checks cash is available returns card
3 User takes card System dispenses cash
4 User takes cash System returns to start menu
64Scenarios
- 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
65Example 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
66Other 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
67Generalizes Relationship
BankMember specializes CardHolder
Withdraw Cash
CardHolder
Check Balance
Order Statement
Generalizes Relation
BankMember
68Include 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
69Extend 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
70Summary
- 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)
71Lecture 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
72A 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
73Emergence 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)
74UML 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
75UML 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
-
76System, 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
77Models 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
78UML Use Case Diagram
Check Balance
extend
Print Balance
include
CardHolder
Withdraw Cash
Select Account
include
Order Statement
include
BankMember
79UML 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
80UML Class Diagram
1..3
CardHolder
holds
Simple ATM class diagram, showing static
structure for banking domain
Debit
Credit
81UML Collaboration Diagram
Collaboration diagram with interactions realizing
the Withdraw Cash use case
82UML 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
83UML 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
84UML 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.
85UML 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!
86Summary
- 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
87Lecture 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
88What 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
89What 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
90Developing 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
91Finding 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
92Noun 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
93ATM 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
94ATM 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!
95ATM 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.
96Basics 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
97Basics of UML Class Notation
Only class name shown
Operations shown
CardHolder
Both attributes and operations shown, with type
information
98Basics of UML Associations
In the banking domain each CardHolder has an
Account
Simple association between classes
holds
Named association
99What 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
100ATM Case Study Initial Class Model
Initial class diagrams for the ATM System
101Summary
- 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
102Lecture 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
103Navigability
- 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
104Showing 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
105Multiplicity
- 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?
106Adding 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..
107Aggregation and Composition
- Provide detail about the kind of association
- Aggregation
- Records whole-part structure
- Composition
- as aggregation, but
- implies strong ownership
108Using 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
109Using 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
110Generalization
- 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
111Notation 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
112Generalization 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 . .
. .
113More On Attributes and Operations
- Refining details of class responsibilities
114ATM Case Study Refining the Class Model
- Adding navigability, multiplicities, aggregation
and generalization
CardHolder
Balance
1..3
1
authorize()
BankMember
115Design 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?
116Design 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?
117Summary
- 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
118Lecture 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
119Views 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
120Responsibility-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
121Class-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
122CRC Card Example
Class name
Brief list of responsibilities
Brief list of collaborators
123Using 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
124What 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
125ATM Case Study Withdrawal Use-Case Realization
Withdraw Cash
ATMCustomer
126ATM 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
127UML 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
128UML 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
129UML 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
130ATM 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
131ATM 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
132Collaboration 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
133UML 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
134ATM Case StudyCollaboration with Interaction
Collaboration diagram with interactions realizing
the Withdraw Cash use case
135Summary
- 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.
136Lecture 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
137More 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.
138Entity and Boundary Notations
Named entity object
Alternative notations for stereotyped classes
ATMUI
Boundary object
139ATM Case StudyEntity and Boundary Collaboration
1select withdrawal menu 2select amount
ATMCustomer
Withdraw cash use case collaboration showing
boundary and entity objects
140Design 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
141Design NoteResponsibility-Driven Design
CardHolder collaborates with Account But should
it need to know about the CashDispenser?
142Design 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
143Interaction 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
144Basics 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
145Notation 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
146Notation 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
147ATM 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
148Withdrawal 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
149ATM Case StudyRestructuring the Class Model
CardHolder getBalance withdraw
1..
1
1
0..
1
1
1
ATMControl
ATMUI
1
1
CashDispenser
Credit
Debit
150Summary
- 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
151Lecture 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
152The 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
153State 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
154Some 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
155Basics 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
156States and Transitions
Simple states
Start state
Transitions
Basic statechart diagram for the Account class
End state
157Transitions and Events
- transitions are triggered by events
Name of event triggering the transition
open
Transitions between states depend on events
close
close
158Guard Conditions
- Written alongside associated event
- event guard
- e.g.
- Condition must hold for event to trigger
transition
159Actions
- 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
160Actions 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
161Actions on States
- Written within state
- entry / action
- exit / action
- e.g.
- Use where action depends on state
162ATM 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
163Summary
- 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
164Lecture 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
165UML Activity Diagrams
- Used to document workflows
- Modelling business activities or systems
- Modelling activities within/between use-cases