An Introduction to Software

Engineering

LECTURE 1

By Dr Samantha Thelijjagoda
[email protected]

Slide 1
 Objectives
z To introduce software engineering and to explain
its importance
z To set out the answers to key questions about
software engineering
z To introduce ethical and professional issues and
to explain why they are of concern to software
engineers

Slide 2
 Topics covered

z FAQs about software engineering

z Professional and ethical responsibility

Slide 3
 Software engineering
z The economies of ALL developed nations are
dependent on software.
z More and more systems are software controlled
z Software engineering is concerned with theories,
methods and tools for professional software
development.
z Expenditure on software represents a
significant fraction of GNP in all developed
countries.

Slide 4
 Software costs
z Software costs often dominate computer system
costs. The costs of software on a PC are often
greater than the hardware cost.
z Software costs more to maintain than it does to
develop. For systems with a long life,
maintenance costs may be several times
development costs.
z Software engineering is concerned with cost-
effective software development.

Slide 5
FAQs about software engineering
z What is software?
z What is software engineering?
z What is the difference between software
engineering and computer science?
z What is the difference between software
engineering and system engineering?
z What is a software process?
z What is a software process model?

Slide 6
FAQs about software engineering
z What are the costs of software engineering?
z What are software engineering methods?
z What is CASE (Computer-Aided Software
Engineering)
z What are the attributes of good software?
z What are the key challenges facing software
engineering?

Slide 7
 What is software?
z Computer programs and associated documentation such
as requirements, design models and user manuals.
z Software products may be developed for a particular
customer or may be developed for a general market.
z Software products may be
• Generic - developed to be sold to a range of different customers
e.g. PC software such as Excel or Word.
• Bespoke (custom) - developed for a single customer according
to their specification.
z New software can be created by developing new
programs, configuring generic software systems or
reusing existing software.

Slide 8
 What is software engineering?
z Software engineering is an engineering discipline
that is concerned with all aspects of software
production.
z Software engineers should adopt a systematic
and organised approach to their work and use
appropriate tools and techniques depending on
the problem to be solved, the development
constraints and the resources available.

Slide 9
 What is the difference between software
engineering and computer science?

z Computer science is concerned with theory and

fundamentals; software engineering is concerned
with the practicalities of developing and
delivering useful software.
z Computer science theories are still insufficient to
act as a complete underpinning for software
engineering (unlike e.g. physics and electrical
engineering).

Slide 10
 What is the difference between software
engineering and system engineering?

z System engineering is concerned with all

aspects of computer-based systems
development including hardware, software and
process engineering. Software engineering is
part of this process concerned with developing
the software infrastructure, control, applications
and databases in the system.
z System engineers are involved in system
specification, architectural design, integration
and deployment.

Slide 11
 What is a software process?
z A set of activities whose goal is the development
or evolution of software.
z Generic activities in all software processes are:
• Specification - what the system should do and its
development constraints
• Development - production of the software system
• Validation - checking that the software is what the
customer wants
• Evolution - changing the software in response to
changing demands.

Slide 12
What is a software process model?
z A simplified representation of a software process,
presented from a specific perspective.
z Examples of process perspectives are
• Workflow perspective - sequence of activities;
• Data-flow perspective - information flow;
• Role/action perspective - who does what.
z Generic process models
• Waterfall;
• Iterative development;
• Component-based software engineering.

Slide 13
What are the costs of software engineering?

z Roughly 60% of costs are development costs,

40% are testing costs. For custom software,
evolution costs often exceed development costs.
z Costs vary depending on the type of system
being developed and the requirements of system
attributes such as performance and system
reliability.
z Distribution of costs depends on the
development model that is used.

Slide 14
Activity cost distribution

Slide 15
Product development costs

Slide 16
What are software engineering methods?

z Structured approaches to software development which

include system models, notations, rules, design advice
and process guidance.
z Model descriptions
• Descriptions of graphical models which should be produced;
z Rules
• Constraints applied to system models;
z Recommendations
• Advice on good design practice;
z Process guidance
• What activities to follow.

Slide 17
What is CASE (Computer-Aided Software
Engineering)

z Software systems that are intended to provide automated

support for software process activities.
z CASE systems are often used for method support.
z Upper-CASE
• Tools to support the early process activities of requirements
and design;
z Lower-CASE
• Tools to support later activities such as programming,
debugging and testing.

Slide 18
What are the attributes of good software?

z The software should deliver the required functionality and

performance to the user and should be maintainable,
dependable and acceptable.
z Maintainability
• Software must evolve to meet changing needs;
z Dependability
• Software must be trustworthy;
z Efficiency
• Software should not make wasteful use of system resources;
z Acceptability
• Software must accepted by the users for which it was designed.
This means it must be understandable, usable and compatible
with other systems.

Slide 19
What are the key challenges facing software
engineering?

z Heterogeneity, delivery and trust.

z Heterogeneity
• Developing techniques for building software that can cope with
heterogeneous platforms and execution environments;
z Delivery
• Developing techniques that lead to faster delivery of software;
z Trust
• Developing techniques that demonstrate that software can be
trusted by its users.

Slide 20
Professional and ethical responsibility

z Software engineering involves wider

responsibilities than simply the application of
technical skills.
z Software engineers must behave in an honest
and ethically responsible way if they are to be
respected as professionals.
z Ethical behaviour is more than simply upholding
the law.

Slide 21
Issues of professional responsibility

z Confidentiality
• Engineers should normally respect the confidentiality
of their employers or clients irrespective of whether
or not a formal confidentiality agreement has been
signed.
z Competence
• Engineers should not misrepresent their level of
competence. They should not knowingly accept work
which is outwith their competence.

Slide 22
Issues of professional responsibility
z Intellectual property rights
• Engineers should be aware of local laws governing the use of
intellectual property such as patents, copyright, etc. They
should be careful to ensure that the intellectual property of
employers and clients is protected.
z Computer misuse
• Software engineers should not use their technical skills to
misuse other people’s computers. Computer misuse ranges
from relatively trivial (game playing on an employer’s machine,
say) to extremely serious (dissemination of viruses).

Slide 23
 ACM/IEEE Code of Ethics
z The professional societies in the US have
cooperated to produce a code of ethical practice.
z Members of these organisations sign up to the
code of practice when they join.
z The Code contains eight Principles related to the
behaviour of and decisions made by professional
software engineers, including practitioners,
educators, managers, supervisors and policy
makers, as well as trainees and students of the
profession.

Slide 24
 Code of ethics - preamble
z Preamble
• The short version of the code summarizes aspirations at a high
level of the abstraction; the clauses that are included in the full
version give examples and details of how these aspirations
change the way we act as software engineering professionals.
Without the aspirations, the details can become legalistic and
tedious; without the details, the aspirations can become high
sounding but empty; together, the aspirations and the details
form a cohesive code.
• Software engineers shall commit themselves to making the
analysis, specification, design, development, testing and
maintenance of software a beneficial and respected profession.
In accordance with their commitment to the health, safety and
welfare of the public, software engineers shall adhere to the
following Eight Principles:

Slide 25
 Code of ethics - principles
z PUBLIC
• Software engineers shall act consistently with the public
interest.
z CLIENT AND EMPLOYER
• Software engineers shall act in a manner that is in the best
interests of their client and employer consistent with the public
interest.
z PRODUCT
• Software engineers shall ensure that their products and related
modifications meet the highest professional standards possible.

Slide 26
 Code of ethics - principles
z JUDGMENT
• Software engineers shall maintain integrity and independence
in their professional judgment.
z MANAGEMENT
• Software engineering managers and leaders shall subscribe to
and promote an ethical approach to the management of
software development and maintenance.
z PROFESSION
• Software engineers shall advance the integrity and reputation of
the profession consistent with the public interest.

Slide 27
 Code of ethics - principles
z COLLEAGUES
• Software engineers shall be fair to and supportive of
their colleagues.
z SELF
• Software engineers shall participate in lifelong
learning regarding the practice of their profession
and shall promote an ethical approach to the practice
of the profession.

Slide 28
 Ethical dilemmas
z Disagreement in principle with the policies of
senior management.
z Your employer acts in an unethical way and
releases a safety-critical system without finishing
the testing of the system.
z Participation in the development of military
weapons systems or nuclear systems.

Slide 29
 Key points
z Software engineering is an engineering discipline that is
concerned with all aspects of software production.
z Software products consist of developed programs and
associated documentation. Essential product attributes
are maintainability, dependability, efficiency and usability.
z The software process consists of activities that are
involved in developing software products. Basic activities
are software specification, development, validation and
evolution.
z Methods are organised ways of producing software. They
include suggestions for the process to be followed, the
notations to be used, rules governing the system
descriptions which are produced and design guidelines.
Slide 30
 Key points
z CASE tools are software systems which are designed to
support routine activities in the software process such as
editing design diagrams, checking diagram consistency
and keeping track of program tests which have been run.
z Software engineers have responsibilities to the
engineering profession and society. They should not
simply be concerned with technical issues.
z Professional societies publish codes of conduct which set
out the standards of behaviour expected of their
members.

Slide 31
Software Development
Life Cycle-II
Lecture 2

Dr Samantha Thelijjagoda
[email protected]
1
 Learning Objectives
z Object-oriented design
z Unified Modeling Language (UML)
z Use-case modeling:
z How to create use-case diagrams?
z How to create use-case narratives?

2
 Phases of the Systems
Development Lifecycle (SDLC)

3
 Phases of the SDLC
z Project planning: initiate, ensure feasibility,
plan schedule, obtain approval for project
z Analysis: understand business needs and
processing requirements
z Design: define solution system based on
requirements and analysis decisions
z Implementation: construction, testing, user
training, and installation of new system
z Support: keep system running and
4

improve
Some Tools Used in System
Development

5
Some Models Used in System
Development

6
Some Techniques Used in
System Development

7
 Object-oriented design (OOD)
z Object-oriented design (OOD)
z Defines object types needed to communicate
with people and devices in system
z Shows how objects interact to complete tasks
z Refines each type of object for
implementation with specific language of
environment
z Object-oriented programming (OOP)
z Writing statements in programming language
to define what each type of object does
8
The Unified Modeling Language

z Object-oriented modeling notation is

Unified Modeling Language (UML)

z Object Management Group

z Promotes theory and practice of object
technology for development of distributed
systems

z Provides common architectural framework for

OO 9
 Why do analysts use Models?
z Analyst describes information system
requirements using a collection of models
z Complex systems require more than one
type of model
z Models represent some aspect of the
system being built
z Process of creating model helps analyst
clarify and refine design
z Models assist communication with system
10
users
Reasons for Modeling

11
 Types of Models used in IS development

z Different types of models are used in

information systems development

z Mathematical - formulas that describe

technical aspects of the system

z Descriptive - narrative memos, reports, or lists

that describe aspects of the system

z Graphical - diagrams and schematic

12
representations of some aspect of the system
 Logical and Physical Models
z Logical models provide detail without regard to
specific technology

z Physical models provide technical details. They

extend logical models

13
Models Used Models Used
in Analysis in Design

14
 Modeling
z Modeling is a way of thinking about the
problems using models organized around
the real world ideas.
z A modeling method comprises a language
and also a procedure for using the language
to construct models.
z Modeling is the only way to visualize your
design and check it against requirements
before your crew starts to code.
 Introduction- UML
•Is a language. It is not simply a
notation for drawing diagrams, but a
complete language for capturing
knowledge(semantics) about a subject
and expressing knowledge(syntax)
regarding the subject for the purpose
of communication.

References
www.sqae.com/UML.ppt
Unified Modeling Language (UML)
z used for both database and software modeling
z version 1.1 was adopted in November 1997 by the Object
Management Group (OMG) as a standard language for
object-oriented analysis and design
z Initially based on a combination of the Booch, OMT
(Object Modeling Technique) and OOSE (Object-Oriented
Software Engineering) methods, UML was refined and
extended by a consortium of several companies, and is
undergoing minor revisions by the OMG Revision Task
Force.
z Ivar Jacobson is known as the father of Use Cases.

References
http://www.inconcept.com
Long Story of UML
UML Architectural Views and Diagrams
Use Case View
Structural View
Behavioral View
Implementation View
Environment View
 Models used in O-O Approach
z Class diagram – definition of system
components
z Use case diagrams and use case
descriptions – show user roles and how
they use the system
z Systems sequence diagrams (SSDs) –
define inputs and outputs and sequence of
interactions between user and system for
a use case
z Statechart diagrams – describe states of
each object
25
z Activity diagrams – describe user activities
 Use-Case Modeling- Benefits
z Tool for capturing functional requirements:
Identify and define all business processes that
system must support
z Facilitates user involvement
z Assist decompose system scope into
manageable pieces
z Means of communicating with users and other
stakeholders
z Aids estimating project scope, effort and
schedule
z Tool for requirements traceability
z Starting point to identify objects or entities
26
 Use-Case Modelling
Two primary artefacts
z Use-case diagram
A diagram that depicts the interactions between the
system and external systems and users. Graphical
description of- who will use the system? In what ways
the user expects to interact with the system?
z Use-case narrative
A textual description of the business event and how the
user will interact with the system to accomplish the task
Use case analysis used to identify and
define all business processes that system
must support 27
 Use-Case Diagram
Use-Case
A series of actions that a system performs that
result in a defined outcome

A behaviourally related sequence of steps ( a

scenario), both automated and manual, for the
purpose of completing a single business task

A single function performed by system for those

who use that function
Use-case symbol
28
 Use-Case Diagram
Actors
Anything that needs to interact with the system
z Role played by user
z Outside automation boundary and
organisation
z Four types:
z Primary business actor
z Primary system actor
z External server actor
z External receiver actor
Time in temporal events
29
 Use-Case Diagram
Relationships

Use-case symbol

E.g. Associations, Extends, Includes, Inheritance

30
Simple Use-Case with an Actor

31
Use-Case Diagram with System Boundary

32
Use-Case of Customer Support System

33
All Use-Cases Including Customer

34
 <<Includes>> Relationships
z Documents situation where one use case
requires the services of a common
subroutine
z Another use case is developed for this
common subroutine
z A common use case can be reused by
multiple use cases

35
Example of Order-Entry Subsystem with
<<Includes>> Use Cases

36
 Developing a Use-Case Diagram

Step 1: Identify business actors

Step 2: Identify business requirements

Develop flow of activities to identify various

scenarios

(Class discussion)

37
 Developing a Use-Case Diagram
Identify business actors
To look for potential actors- examine:
z Context diagram
z Existing system documentation and user
manuals
z Minutes of project meetings and
workshops
z Existing requirements documents, events
table
38
 Developing a Use-Case Diagram
Identify business actors
To look for potential actors, ask these question:

z Who / What provides inputs to the system?

z Who / What receives outputs from the system?
z Are interfaces required to other systems?
z Any events that are automatically triggered at a
predetermined time?
z Who will maintain information in the system?

39
 Developing a Use-Case Diagram
Identify business requirements/use cases
To look for potential use cases, ask these question:

z What are the main tasks of the actor?

z What information does the actor needs from the
system?
z What information does the actor provide to the
system?
z Does the system needs to inform the actor of any
changes or events that occurred?
z Does the actor needs to inform the system of any
changes or events that occurred?
40
 Use-Case Narratives
Use-case narratives can be of different
levels:
e.g.
z High-level version
z Expanded version

41
Use-Case Narratives: High-level version
Items include :
1. Author
2. Date
3. Version
4. Use-case name
5. Use-case type
6. Use-case ID
7. Priority
8. Source
9. Primary business actor
10. Other participating actors
11. Interested stakeholder(s) 42

12. Description
Use-Case Narratives: Expanded version
Items include:
The items in the high-level version PLUS:
1. Precondition
2. Trigger
3. Typical course of events
4. Alternative course
5. Conclusion
6. Post-condition
7. Business rules
8. Implementation constraints and
specialisations
9. Assumptions 43

10. Open issues

Use Case Diagram for Inventory
System

44
Traditional and Object-Oriented
Views of Activities

45
Advanced Analysis and
Object-Oriented Design

Lecture 2: Part II

Use Case Modeling

Use Case Diagram
 Overview

z The Use Case Diagram

z Components of a use case diagram
z Actor Generalization
z Use Case Relationships

2
Role of Use Case Diagrams in UML

3
 Use-Case Modeling- Benefits
z Tool for capturing functional requirements:
Identify and define all business processes that
system must support
z Facilitates user involvement
z Assist decompose system scope into
manageable pieces
z Means of communicating with users and other
stakeholders
z Aids estimating project scope, effort and
schedule
z Tool for requirements traceability
z Starting point to identify objects or entities
4
 Use-Case Modelling
Two primary artefacts
z Use-case diagram
A diagram that depicts the interactions between the
system and external systems and users. Graphical
description of- who will use the system? In what ways
the user expects to interact with the system?
z Use-case narrative
A textual description of the business event and how the
user will interact with the system to accomplish the task
Use case analysis used to identify and
define all business processes that system
must support 5
 What Is a Use Case?
z A use case represents an activity that the
system must participate in:
z Each use case constitutes a complete course of action
initiated by an actor, and it specifies the interaction that
takes place between an actor and the system.
z Simply written stories.
z Each use case must describe a complete (self-
contained) interaction with the system.
z Acceptable: a member rents a DVD.
z Unacceptable: a membership card is scanned.

6
 Components

z To construct a Use Case diagram, there are

FOUR basic components:
z System: something that performs function(s).
z Actors: the roles adopted by those participating.
z Use Cases: high level activities to be supported
by the system.
z Relationships / Links: which actors are involved
in which use cases

7
Simple Use-Case with an Actor

8
Use-Case Diagram with System Boundary

9
Use-Case of Customer Support System

10
All Use-Cases Including Customer

11
 Components

z To construct a Use Case diagram, there are

FOUR basic components:
z System: something that performs function(s).
z Actors: the roles adopted by those participating.
z Use Cases: high level activities to be supported
by the system.
z Relationships / Links: which actors are involved
in which use cases

12
 Actors
z An actor is simply an entity which:
z is external to the system being modeled;
z interacts with the system.
z Actors can be human or non-human:
zA user e.g. a student logging onto moodle;
z Another software system. e.g. the
database engine for moodle;
z A hardware device (with embedded
software) e.g. the backup server for moodle;
z For a particular use case scenario, the
primary actor is the one that triggers the start
of the scenario. 13
 Human Actors
z Actors must always interact with the software.
z A human actor who:
z is involved in some process performed by the
system, but
z who does not directly interact with the software, is
not a valid actor.
Actors are connected to use cases only by association.
z Example:
z A video library customer is not a valid actor because
customers do not get to leap over the counter and
use the video library software.
z A video library staff member, serving at the counter,
is a valid actor because they do directly interact with
the software. 14
 Non-human Actors
z A non human actor must:
z be an item of hardware or software which is external
to the system.
z have a clearly defined mechanism, usually message
passing, for interacting with objects in the software.
z have behaviour which is:
z totally determined by itself.
z significant in terms of the design (i.e. high level and
relevant).
z Operating systems, files, monitors, mice are
not valid actors.
15
 How to Find Actors
z An actor indicates an external person or system
which is involved in an use case

z The same person or system may play the role of

more than one actor, depending on the context

z An actor may be a set of roles, which are related

z An actor may be involved in more than one use

case
z One actor is normally the initiator of each use
case 16
 Actors: Example
z DVD Renting System
z Shopattendant
z A member is not an actor. Why?

z Your turn
z Identify actors for a banking system

17
 Actor Relationships
z Two kinds of relationships can exist between
actors:
z Association.
z indicates that an actor participates in (i.e. communicates
with) the use case.
z Generalization.
z indicates that an instance of one actor can communicate
with the same use cases as instances of another.

18
 Actor Generalization
z Actor Generalisation is drawn from the
concept of inheritance in Object Oriented
Programming:
z A super class is a more generalized version of a sub class.
z A sub class is a more specialized version of the super class.
z Just like classes, actors can include
generalizations.
z In other words, a child actor:
z Inherits all of the characteristics and behaviour of
the parent actor.
z Can add to, modify, or ignore any of the
characteristics and behaviours of the parent actor.
19
Actor Generalization: Example

20
 Notes on the Example
z The use case diagram is a summary of
which actors participate in which use
cases:
z all three actors can participate in the Loan
DVD, Return DVD and Add Member use
cases;
z the manager can also participate in the Add
DVD and Remove DVD use cases;
z the administrator can also participate in the
Add User and Remove User use cases.
21
 Use-Cases
A series of actions that a system performs that
result in a defined outcome

A behaviourally related sequence of steps ( a

scenario), both automated and manual, for the
purpose of completing a single business task

A single function performed by system for those

who use that function
Use-case symbol
22
 Use Cases
z A Use Case represents a set of sequence of
events(actions) which combine to form some
interaction between the software system
and the outside world.
z Use cases are shown as ellipses, each
with a name based on a verb-noun
phrase.
z Use Cases does something of value to an
actor.

23
 Use Cases - Names
z Every use case must have a name that
distinguishes it from other use case.
z A use case name may be text consisting of.
z any number of letters, numbers.
z In practice, use case names are short active verb
phrases naming some behavior found in the
vocabulary of the system you are modeling.

24
 How to Find Use Cases

z When you are looking for Use Cases you can

ask questions like the following:
z Which functions/services (full functions) does Actors
require from the system? What does the Actor need
to do?
z Does the Actor need to read, create, destroy, modify
or store some kind of information in the system?
z Does the Actor need to get notified when some
events occur in the system?
z Can some Actors daily work be simplified by
functionality in the system? If so what work?
25
 Use Case: Example

z Use Cases for DVD Renting System

z Loan Videos
z Return Videos
z Create membership
z Pay Fine
z Lookup Video Data

Tour Turn
z Identify use cases for the banking system

26
 Relationships

Use-case symbol

E.g. Associations, Extends, Includes, Inheritance

27
 Use Case Relationships
z There are FOUR kinds of relationships can exist between use cases:
z association
z indicates that an actor participates in (i.e. communicates with)
the use case
z include
z indicates that the behavior of one use case includes the
behavior of another
z extend
z indicates that one use case may be extended (subjected to
specific conditions) by the behavior of another
z generalization
z indicates that one use case inherits the properties of another,
with the usual possibilities for overriding and substitution
28
 Association Relationship
z The relationships between actors and
use cases.
z The ONLY relationship between actors and
use cases shown by association.
z connection between actor and use case is
a communication association.
z Example:

29
 Association: Example

• Draw use cases with Association for the

banking system 30
 Include (Uses) Relationship
z Also known as the uses relationship.
z Use Case A calls Use Case B.
z Similar to the concept of sub- modules where module A
calls module B.
z Use Case A can never stand alone. It needs to use Use
Case B to achieve its task just like the calling sub- module
needs the called sub module to achieve its task.
z The separation of behaviours into two Use Cases means
that other Use Cases which require the same set of
actions described in Use Case B can make use of an
includes relationship as well:
z Use Case C, which also requires the actions performed
in Use Case B, can also have an includes (or uses)
relationship with Use Case B. 31
 Include Relationship: Example
z Include relationship is to avoid describing the same
flow of events several times,
z by putting the common behavior in a use case of
its own.
z You render an include relationship as a
dependency, stereotyped as include.
z Draw include relationship for the banking system.

including use case included use cases

32
Example of Order-Entry Subsystem with
<<Includes>> Use Cases

33
 Extend Relationship
z Borrowed from the concept of generalization in
class hierarchies.
z If Use Case A extends Use Case B then:
z The behaviour of Use Case A is similar to, but
more specialised than that of Use Case B.
z The behaviour of Use Case B is more
generalised than that of Use Case A.
z Use Case B is known as the base Use Case.
z The base Use Case is a complete Use Case in its
own right, which may have its behaviour extended
by another Use Case when specific conditions
arise. 34
 Extend Relationship: Example
z An extend relationship is to model the part of a use case
the user may see as optional system behavior.
z In this way, separating optional behavior from
mandatory behavior.
z You render an extend relationship as a dependency,
stereotyped as extend.

extending use case extended use35 case

 Extend Relationship (Cont.)
z The specific conditions are known as Extension Points.
z If Use Case A has an extend relationship with Use Case B
then:
z They are connected with an arc.
z Extension Points must be stated in the base Use Case
as well as the arc connecting the two use cases.
z An extended use case can have multiple extension points
and all of them must be true for a use case to be
extended.
use case name

36
list of extension point
Use Case Relationships:
Include/extend Example
“late fine” is the name of
the extension point in the
Rent Video Use Case

37
 Include/extend: Textual
Description
z The text description of the base Use Case
contains references to any included Use Cases
and any extension point(s).
z Example:
The Rent Video Use Case begins when the member is
identified.
Basic flow: include (Identify Member).
extend(late fine).
The rental transaction is then performed.
include (Process Rental).

38
 Generalization Relationship
z Generalization is a technique used to indicate
inheritance.
z This means that a child use case inherits the
behaviour and meaning of the parent use case.
z The child may add or override the behaviour of the
parent.
z The child may be substituted in any place the parent
may appear in the system.
z Generalisation appears as.

Child Use Parent Use

Case Case
39
Example of Generalization in a
Use Case Diagram
Check
Password

Validate
User

Retinal
Scan

z Generalization can even be hierarchical, where

children use cases of a parent use case can have
their own children. 40
 Use Case Relationships:
Include/extend/generalization

Main flow of events:

Obtain and verify the order number. include (Validate user). For each
part in the order, query its status, then report back to the user. 41
 Developing a Use-Case Diagram

Step 1: Identify business actors

Step 2: Identify business requirements

Develop flow of activities to identify various

scenarios

(Class discussion)

42
 Developing a Use-Case Diagram
Identify business actors
To look for potential actors, ask these question:

z Who / What provides inputs to the system?

z Who / What receives outputs from the system?
z Are interfaces required to other systems?
z Any events that are automatically triggered at a
predetermined time?
z Who will maintain information in the system?

43
 Developing a Use-Case Diagram
Identify business requirements/use cases
To look for potential use cases, ask these question:

z What are the main tasks of the actor?

z What information does the actor needs from the
system?
z What information does the actor provide to the
system?
z Does the system needs to inform the actor of any
changes or events that occurred?
z Does the actor needs to inform the system of any
changes or events that occurred?
44
Use Case Diagram for Inventory
System

45
THE END – Lecture 2

46
Advanced Analysis and
Object-Oriented Design

Lecture 3

Structural Design Artifacts

 Overview
• Class Responsibility and Collaboration
(CRC) Cards.
• UML Structural Design Artifacts:
– defining class structures;
– drawing class diagrams;
– defining object structures;
– drawing object diagrams.
• Traceability Diagrams and
Collaborations.
2
 From Analysis to Design
Analysis Models Design Models
– Activity Diagrams • Design Class Diagrams
– Use Case Diagram • Object Diagrams
– Use Case Scenarios • Sequence Diagrams
– Conceptual Class • Collaboration Diagrams
Diagrams • State Diagrams

3
 OO Design – Where To Start
• In all types of engineering it is necessary to
know what the problem is before an
appropriate solution can be built.
• Do not begin an OO design until at least part
of the use case model has been specified:
– the use case model will provide clues about the
required classes and their functionality;
– it will also hint at how the resulting objects should
interact.
• The use case scenarios drive the OO design.

4
 OO Design – Where To Start
• Consider a use case.

• Something happens inside the use-case.

– The user interacts with the system to perform
an ‘update’.
– The system interacts with the database.
5
OO Design – Where To Start
• Decomposing further

Note that this is NOT valid UML. This diagrams is meant to be for6
illustrative purposes only!
 OO Design – Where To Start
• First, determine what classes are needed,
without accidentally picking:
– there is an infinite number of classes to choose
from.
• Second, determine the responsibilities of the
classes - i.e. what they are supposed to do:
– there are no limitations on the functionality of a
class!
• Third, define the collaborations between
classes: -i.e. the relationships between them;
– limiting the functionality of the classes limits the
interactions that can occur between classes.
7
 OO Design – Where To Start
• The issue is to.
– Determine what C1, C2 … Cn should be.
• This is VERY hard.
– Determine what M1, M2 … Mn should be.
• This is hard.
• Once the basic scenarios have been developed
for the system, it is time to identify candidate
classes and indicate their responsibilities and
collaborations.
• There are ways to make this easier.
– Patterns
– Experience
– CRC Cards
8
 CRC Cards
• Class Responsibility and Collaboration
cards:
– developed by Beck and Cunningham (1989).
• Used to explore class relationships between
classes in a particular use-case scenario.
• Meant to provide a high-level description of a
class.

• A CRC card is not a list of attributes and

methods that the class contains.

9
 CRC Cards
• A CRC is a 4 × 6 inch card divided into three
sections.
– The name of the class on the top of the card.
– The responsibilities of the class on the left of the
card.
– The class collaborations on the right of the card.
• the list of other classes with which the class
collaborates to realize its responsibilities.

10
 CRC Cards
• CRC cards are small to physically limit
what each class can do.
– you can only scribble so much on a card;
– this reflects the fact that a class should
only have a small number of related
responsibilities.
• CRC cards discourage attachment:
– quickly developed;
– quickly discarded (if necessary).
11
 CRC Cards
• There is no point in wildly generating
CRC cards.
– this is no better than wildly generating
classes!
• The easiest way to generate CRC cards
is by using the scenarios in the use case
model:
– no need to examine ALL scenarios, just a
representative sample of them.
• CRC cards are a tool for exploration:
– used to explore possible designs, providing
12
a better insight into the use case model.
 CRC Cards
• CRC cards are used to explore
relationships between classes in use
case scenarios:
– the cards are used to “role play” each
scenario;
– each scenario adds to the responsibilities
and collaborations on several CRC cards.

13
 CRC Cards
• When you consider all scenarios for all use cases:
– You have a set of CRC cards (indicating all the classes
your system requires to realize the use cases).
– For each CRC card, you will have the list of all
responsibilities the class realizes.
– For each responsibility, you will have the list of all
collaborating classes.
• Remember that the list of responsibilities on the CRC
card is not the list of methods in the class.
– A responsibility may be realized by several methods.
– A responsibility may require multiple collaborations.
14
 CRC Cards – Example
• An example of one responsibility requiring
multiple collaborations.

• The DatabaseInterface Class is responsible for

updating the enrolment.
• It collaborates with the Student, Unit and
Course classes to realize this responsibility.
15
 CRC Cards – Example

• The Student class has a responsibility

that is required by the DatabaseInterface
class.

16
 CRC - Example

• One responsibility may requires several

methods to realize it.
• To “update enrolment” the
DatabaseInterface class must call
several methods in other classes.
17
 CRC Cards – Why Bother?
• One of the hallmarks of good class design is
the limitation of the functional domain of the
class:
– CRC cards provide an easy way to check this.
• Responsibilities should not be similar to each
other:
– e.g. if a class is responsible for the user interface it
probably should not be responsible for the database
too!
• CRC cards make it easy to see if a class is
doing too much
– typically no more than 5 -7 responsibilities;
18
 CRC Cards – Why Bother?
• CRC card generation usually results in
multiple cards, each representing a
class.
• From the set of cards, it makes sense to.
– Group classes with similar responsibilities.
• Example: All the classes with database
functionality.
– Group classes that collaborate together.
• Example: Entity classes with data classes.
– The groupings are sometimes conflicting.
19
 CRC Cards – Why Bother?
• A collaboration graph can be
constructed from the CRC cards.
• This helps to identify sub-systems -
sets of classes that tend to collaborate
with each other.

20
 CRC Cards – Why Bother?
• CRC cards are the starting point for drawing
class diagrams.
– If two classes collaborate they must be related in
some way, though the exact type of the relationship
cannot be determined from the CRC card.
– Classes that collaborate with each other are
candidates for an association relationship.
– Classes that share overlapping responsibilities are
candidates for a generalization relationship.
– Classes that offer functionality using other classes
are candidates for composition/aggregation
relationships.
21
Classes & Objects

22
 Class Structures
• A UML class structure describes
several important properties of a class.
– the name (optional multiplicity).
– the attributes (optional).
– the methods (optional).

– There is always exactly one (1) instance of

this Stack class, with 1 attribute and 2
methods.
23
The Class Symbol for the
Class Diagram

24
 Class Structures
• Class multiplicity is specified using the
same rules as for association (next
lecture).
• The attributes anvisibility informationd
methods can be specified with :

25
 Class Attributes

• The attributes of a class can be fully specified

as follows:

Wall
height : Float
width : Float
thickness : Float
LoadBearing : Boolean = false
26
 Class Structures
• The scope of the attributes and
methods can also be defined.
– Instance scope (the default).
• Each instance of the class effectively holds its
own copy of the attribute or method.
– Class scope.
• A single copy of the attribute or method exists for
all instances of the class (static)
• Denoted by underlining the name of the attribute
or the method.
27
 Class Attributes
• Multiplicity of a class attribute is defined
within square brackets (the default is 1).
• There is a tendency to confuse
multiplicity specifications with array
specifications.
– The Array class structure states that
– there are between five (5) and
ten (10) element in Array;
– NOT that there is an array of
element with indices from 5 to 10. 28
 Example – Class Attributes
• This structure defines a class attribute:
– with protected visibility;
– named element;
– of type int;
– there are between 5 to 10 (inclusive)
instances of this attribute in the class;
– the default value for the attribute is 0;
– the attribute is changeable.

29
 Example – Class Attributes
• Properties of an attribute can be.
– changeable.
• The attribute can be modified without restriction.
– addOnly.
• The attribute cannot be deleted or updated but
other values may be added to the attribute
(applies only to attributes with a multiplicity greater
than one).
– frozen.
• The attribute can be initialized, but never
modified. 30
Example – Class Attributes

31
 Example – Class Methods
• The methods in a class can be fully
specified as follows:

• The full specification for a parameter is

as follows:

• Parameters are separated by commas.

32
 Example – Class Methods

• This defines a class structure called Array:

– with a method called add;
– that returns a boolean;
– with a parameter called value –
• that is used only as an import for the method
• that is of type int
• with a default value of 0 if none is specified
33
 Class Types
• Several specialized class types can be
shown.
– Leaf classes cannot have any descendants.
• property {leaf} near the name.
– Utility classes provide common functionality.
• property {utility} near the name.
– Root doesn't have parent class.
• property {root} near the name.
– Abstract classes serve as templates for their
descendants (but cannot be instantiated).
• Name in italics. 34
 Abstract Classes
–defer the implementation of one or more
operations
–have no direct instances
–serve to define the “interface” to an abstraction
Employee

year_to_date earnings
compute pay {abstract}

Salaried Employee Hourly Employee

weekly rate hourly rate
compute pay compute pay
 Abstract Classes
• An abstract class can have independent
functionality:
– functionality in the abstract class that can
be realized by the abstract class itself;
– it does not require attributes or methods
from its descendant classes.
• This functionality is available to all
descendant classes, and does not have
to be re-implemented (though it may be).
36
 Abstract Classes
• An abstract class can have dependent
functionality:
– functionality in the abstract class that
cannot be realized by the abstract class
itself;
– it requires attributes or methods from its
descendant classes.
• The abstract class enforces this
functionality on all dependent classes,
but relies on these descendants to
37
implement it.
 Class Diagrams
• A class diagram is:
– a collection of class structures;
– the relationships between them (next
lecture).

38
 Object Structures
• An object structure represents a class instance:
– it is a snapshot of the state of the instantiated class at
some point during run time.

• Given a class, at some point in the lifecycle of the

system, the class will be instantiated;
– the instantiated class will have attributes;
– these attributes will have values;
– at different points the attribute values will change.

• An object structure describes the object and the values of

its attributes at a point in time.

39
 Example – Object Structure
• LHS: class structure (with inheritance).
• RHS: an example of an Employee
object at some point in time.

40
 Example – Object Structure
• The name of the class in the object structure is
underlined, with a colon in front of it:
– this is the UML notation for an anonymous object;
– if necessary, a name may be placed in front of the
colon.
• The object structure for the Employee object
has both position and name attributes:
– this is because Employee inherits from person.
• It makes no sense to show inheritance in an
object diagram.
41
 Object Diagrams
• An object diagram is:
– a set of object structures;
– the relationships between them.

42
 References
• Page-Jones, M (2004). Fundamentals
of Object-Oriented Design in UML.
– Chapters 3 & 4.
– Chapters 8 - 15.

43
END OF THE SESSION

44
Advanced Analysis and
Object-Oriented Design

Lecture 4

Class Diagrams
 Overview
• Relationships Between Classes.
– More about inheritance.
• Common Misuses of Inheritance:
– with lots of examples!

2
3
 What is a Class Diagram?
• Class diagrams are the most common diagram found
in modeling object-oriented systems. A class diagram
shows a set of classes, interfaces, and collaborations
and their relationships.
• You use class diagrams to model the static design
view of a system. For the most part, this involves
modeling the vocabulary of the system, modeling
collaborations, or modeling schemas. Class diagrams
are also the foundation for a couple of related
diagrams: component diagrams and deployment
diagrams.
• Class diagrams are important not only for visualizing,
specifying, and documenting structural models, but
also for constructing executable systems through
forward and reverse engineering.
4
 Introduction
• In general a UML diagram consists of.
– Entities: e.g. classes, objects, users,
states and behaviours.
– Relationships between entities:
• Dependency: one entity depends on the
behavior of another in some way (dotted line
with open arrow).
• Association: one entity uses another as part of
its behaviour (solid line, with optional
adornments).
• Generalization: one entity is a higher
abstraction of another (solid line, closed
5
arrow).
 Why - Relationships

• The type of relationship provides a semantic

meaning to the relationship between the
classes.
– Example: A generalization relationship has
special meaning between two classes.

6
Relationships - Classes

7
Relationship – Dependency
• Dependency is the simplest form of
relationship between two classes:
– it simply means that one class depends on
another class in some (unspecified) way;
– it implies that a change to one class (Dog)
may affect the other (Person), but not vice
versa.

8
Relationship – Dependency

• The dependency does not mean that a

Person object contains a Dog object (or vice
versa).
– It simply means that a Person object uses a Dog
object somewhere:
– e.g. as a local variable or parameter in one of its
methods.
public class Person.
{
public void walkDog(Dog theDog);
};
9
 Relationship - Association
• Association connects one instance of a class
with another instance of another class.

– The Person class and the Dog class are

associated. The relationship is bi-directional:
– The person is related to the dog in some
way.
– The dog is also related to the person in
some way.
– The exact nature of the association is 10
unknown.
 Relationship - Association
• An association can be given a name:
– this is only shown if it helps to clarify the
association.
• An association can also be directed:

– Given a Person, it is simple to find out which

Dog(s) he or she Owns. (see next slide).
– Given a Dog, it is difficult to find out which
Person(s) the Dog is Owned by. (see next
11
slide).
 Relationship - Association

• The multiplicity of an association can

also be specified:

– One Person object can have 0 or more

Dog objects associated with it.
– Each Dog object is associated with exactly
one Person object.
12
 Relationship - Association
• When a class participates in an association, it
has a specific role that it plays in that
relationship;
– a role is just the face the class at the near end of the
association presents to the class at the other end of
the association.
– a Person playing the role of employee is associated
with a Company playing the role of employer.

13
 Association - Adornments

• Name
• Role
• Multiplicity

14
 Multiplicity
• How many objects of each kind are specified.
• This “How many” is called the multiplicity of an
association’s role.

15
 Relationship - Association
• The association can also be promoted to a class.

• This places the responsibility for maintaining

information pertaining to the association with the
Ownership class.
16
 Relationship - Association
• Promoting an association to a class
allows:
– the addition of attributes specific to the
association into the new class .
• this keeps the associated classes free of this
extraneous information.
– the addition of methods specific to the
association into the new class .
• this keeps the associated classes free of
methods for maintaining the consistency of the
17
association.
 * 0..1

employer
Person Company

Association Class
Employment
period

18
 Relationship - aggregation
• A plain association between two classes represents
a structural relationship between peers, meaning that
both classes are conceptually at the same level, no
one more important than the other.
• Sometimes, you will want to model a "whole/part"
relationship, in which one class represents a larger
thing (the "whole"), which consists of smaller things (the
"parts").
– This kind of relationship is called aggregation,
which represents a "has-a" relationship, meaning
that an object of the whole has objects of the part.
• Aggregation is really just a special kind of
association and is specified by adorning a plain 19
association.
 To Have & To Be

• A university “is a” group of academics and

students.

• A university “has a” group of academics and

students.

20
 To Have & To Be
• Inheritance relationships mean “is a.”
• Whole-part relationships mean “has a.”

• The UML does not attempt to model all kinds

of whole-part relationship, only the most
common:

– in UML there are only two - aggregation and

composition.

21
 Relationship – Aggregation
• Aggregation is a weak form of whole-part
relationship represented by a hollow diamond:

• Implies that the whole can exist without the

parts.
• Frequent flyer club consists of zero or more
members:
– This implies that a FrequentFlyerClub object has a
link to its various member objects.
– This does NOT imply that a Member object has a
link to the FrequentFlyerClub object. 22
 Relationship – Aggregation
• Rules for aggregation.
– Non-exclusive:
• a member can belong to more than one club.
– Non-mandatory:
• a club can exist without any members.
• Multiplicity specifications must allow for this:
– it makes no sense to have an aggregation
relationship with a multiplicity of “1..”

23
 Relationship - Aggregation
• Multiplicity.
– The same rule for multiplicity outlined for
association relationships hold for the aggregation
relationship.

– In this case, every frequent flyer club consists of

zero or more members.
24
Relationship – Composition

• Composition is a strong form of whole-part

relationship represented by a filled diamond:

• Implies that the whole cannot exist without

the parts.
– A flock is composed of at least one sheep.
– As with aggregation, the flock knows about the
sheep but the sheep may not know about the
flock.
25
Relationship – Composition

• Rules for composition.

– Exclusivity
• A sheep can only be part of one flock.
– Mandatory membership
• If there are no sheep, there is no flock.
• The flock is a manifestation of the collection of sheep.
– Multiplicity specifications must allow for this:
• it makes no sense to have a composition
relationship with a multiplicity of “0..”
26
Relationship – Inheritance

• Inheritance is one of the defining concepts of

object orientation:
– it is a powerful technique for organizing and
reusing design concepts in an abstracted
hierarchy;
– without inheritance, polymorphism would not be
possible!
• Unfortunately, inheritance is also the most
misused and misunderstood relationship:
– some common misuses of inheritance are
examined later in this lecture. 27
 Relationship - Generalization
• A generalization is a relationship
between a general thing (called the
superclass or parent)and a more
specific kind of that thing (called the parent
subclass or child).
• Generalization is sometimes called
an "is-a-kind-of" relationship.
– Engineer is a kind of Employee.
• Child inherits the properties of its
parent(s) attributes, operations,
responsibilities, etc.).
– Child often adds additional
properties.
– Child may override parent
property -- polymorphism. children 28
Inheritance – Terminology

29
Inheritance – Terminology

• Class A is a super-class of class B if B directly

inherits from A:
– class A can also be called a parent of class B.
• Class B is a sub-class of class A if B directly
inherits from A:
– class B can also be called a child of class A.
• Class A is an ancestor of class B if A is above
B in the inheritance hierarchy.
– Class B is a descendant of class A if B is below A
in the inheritance hierarchy.
30
 Inheritance – Terminology

• Inheritance is a generalization / specialization

relationship.
• Generalization takes place from sub-class to
super-class:
– the super-class is a generalization of the sub-class.
• Specialization takes place from super-class to
sub-class:
– the sub-class is a specialization of the super-class.

31
Relationship – Inheritance

• Generalization of functionality?
– The sub-class logically contains all of the
methods in the super-class, and more:
• the set of methods in the sub-class is a super-
set of those in the super-class.
• The sub-class is therefore “more
general” in the sense that it has more
methods, and hence a wider range of
potential behaviour. 32
Relationship – Inheritance
• Specialization of functionality:
– The functionality of the child should be a
specialization of the functionality of the
parent.
– e.g. the functionality of the draw method in
Circle is more specific than the one in
Shape (which in this example isn’t even
defined).

33
 Relationship – Inheritance

• Generalization of state?
– The sub-class logically contains all of the
attributes in the super-class, and more:
• the set of states in the sub-class is defined over a super-
set of the attributes in the super-class;
• objects of the sub-class can potentially exhibit all of the
states of super-class objects, and more.
– The sub-class is therefore “more general” in the
sense that it has more attributes and hence more
potential states.

34
Relationship – Inheritance

• Specialization of state:
– The range of values for the attributes that
the child inherits from the parent should be
a specialization of the range of values for
the attributes of the parent.
– e.g. an attribute representing the number of
sides of a super-class polygon has a bigger
range than in a subclass triangle.
35
Relationship - Generalization

36
37
 Misuse of Inheritance #1
• Inheritance in place of aggregation:
– using “is a” instead of “has a”.

• The idea is that an aircraft has all the

functionality of its component parts:
– a plane can do all the things a wing, fuselage and
tail can do (and more).
38
 Misuse of Inheritance #1
• The problem is that an aircraft is not a
wing:
– the class hierarchy implies that an aircraft
can be used wherever a wing is required.
• A better way to represent the
relationship is through aggregation or
composition.?

39
 Misuse of Inheritance #2
• Inverted hierarchy:
– the design (right)
represents a hierarchy in
the real world.
– the idea is that capturing
the real-world hierarchy
via inheritance
relationships will capture
real-world behaviour.

40
 Misuse of Inheritance #2
• In OO design:
– the child class has all the attributes and
methods of the parent (and more);
– the functionality of the child class should
be more specialized than that of the
parent.
• This implies that:
– a Worker can do everything a CEO can
do;
– a Worker is also “better” at doing these
things. 41
 Misuse of Inheritance #2
• The solution may be
simply to reverse the
direction of inheritance:
– in the real-world, the higher
entity in the hierarchy has
the most power.
– in object oriented design,
the higher entity in the
hierarchy has the least
power.
42
 Misuse of Inheritance #3
• Partial inheritance (of domain).

• The idea is to place all the common functionality

for numbers in the Number class and then
specialize out with Even and Odd numbers.
43
 Misuse of Inheritance
#3
• Technically there is nothing wrong with
the class hierarchy as it stands:
– however, problems arise if we try to extend
it.
• Problems:
– Where does zero (which is defined to be
neither odd nor even) fit into the hierarchy?
– How can the hierarchy be extended to
include prime numbers?
44
 Misuse of Inheritance
#3
• The hierarchy might be extended like this:
– zero is in a class by itself;
– all prime numbers are odd. except for 2, so
Prime must inherit from Even and Odd.

45
 Misuse of Inheritance
#3

• Partial inheritance of range:

46
 Misuse of Inheritance
#3
• The OddNumber class has a range of values
that spans all odd numbers:
– the PrimeNumber class should have a range that is
a sub-set of the odd numbers;
– but 2 (a prime) is not in the OddNumber range.
• The EvenNumber class has a range of values
that spans all even numbers:
– the PrimeNumber class should have a range that is
a sub-set of the even numbers:
– but 3 (a prime) is not in the EvenNumber range.47
 Misuse of Inheritance
#3
• A class inheriting from both OddNumber
and EvenNumber should have a range of
values that is a sub-set of the intersection
of the ranges of the two parent classes:
– this is the empty set!
• A possible solution:

48
 Misuse of Inheritance
#3
• The AbstractNumber class specifies only the
common functionality:
– any of the subclasses can be used in place of an
AbstractNumber;
– the four subclasses cover the entire range of
numbers.
• . Problem:
– the range of numbers covered by Prime overlaps
some of the range covered by Odd and Even;
– in reality Prime numbers are a sub-set of the
union of Odd and Even numbers. 49
 Misuse of Inheritance
#3
• A better solution:

• This class structure reflects the disjoint property of

Odd and Even numbers by separating Odd and
50
Even Primes.
 Misuse of Inheritance
#4
• Partial inheritance (of functions).

• In this example, all types of drive inherit

from a Disk class:
– this allows common functionality to be shared
among the sub-classes. 51
 Misuse of Inheritance
#4
• The problem is what to do with functions
like eject() or format( ):
– a CD-ROM cannot be formatted;
• The format method could be duplicated
in Floppy and HardDrive, but this would
be inefficient.
• Alternatively, format() could be defined
to do nothing in the CD-ROM class:
– this is not very elegant because it treats
the symptom rather than effecting a cure.
52
 Misuse of Inheritance
•
#4
A better solution is to add an intermediate abstract
class:

53
 Misuse of Inheritance
#5
• Sub-classing an instance:

• The idea is to distinguish between the two

different types of population..
– but is this really necessary?
54
 Misuse of Inheritance
#5
• The problem is that there is no difference in
functionality between the super and sub-
classes:
– only the names of the classes are different.
• The solution is to eliminate the subclasses,
and add a “nationality” attribute to Population
class.
• It is then possible to instantiate a different
Population object for each population:
Population w = new
Population(Welsh”);
55
Population a = new Population(“Australian”);
 Misuse of Inheritance
• Mixing domains:
#6

• The idea is that a Panda is a type of

Bear and also a type of Endangered
Species.
• The problem is quite subtle, and Page-
Jones. includes a lengthy discussion of56
this example.
 Misuse of Inheritance
#6
• Panda is a type of Bear:
– typical instances of Bear - Paddington, Pooh, Li Li.
• Panda is also a type of Endangered Species:
– typical instances of Endangered Species .
• Tiger, Humpback Whale, Panda.
• Taken individually, there is no problem.
• Taken together - can a Panda be a single animal
(like Pooh) and a species at the same time?

57
 Top 10 Domain
Modeling Mistakes
1. Start assigning multiplicities to associations right
away and religiously.
Do it eventually by all means, but on the second or
third pass.
Much of the time, multiplicities aren’t that
important.
2. Perform noun and verb analysis until you turn blue.
Use your common sense.
3. Assign operations to classes without first exploring
use cases and sequence diagrams
Operations come later; may not appear in domain
models at all! 58
 Top 10 Domain
Modeling Mistakes
4. Optimize for reusability before making sure you’ve
satisfied the user’s requirements.
Reusability is a good thing, but primarily you
are trying to satisfy the user’s requirements.
Recall XP’s “rule of three”; don’t aim for the
most general kind of model you can design.
5. Debate endlessly whether to use strong or weak
aggregation on each “has-a” relationship.
Use your common sense.
6. Presume a specific implementation strategy
without modeling the problem space.
Model domain relationships; leave the 59
EJB/RDBMS decisions until design.
 Top 10 Domain
Modeling Mistakes
7. Use hard-to-understand names for your
classes like cPortMgrIntf instead of
PortfolioManager
Domain models are used for communication!
CASE tools help to minimize typing long
names too often ☺
8. Jump directly to implementation constructs
such sa C++ friendships and parameterized
classes.
These are implementation strategies (not to
mention technology specific!). 60
 Top 10 Domain
Modeling Mistakes
9. Create 1:1 mappings between domain classes and relational
DB tables.
If you’re “forward engineering” you are jumping ahead to
design too quickly.
If you’re “reverse engineering” an existing system, try to
recover the abstract design from the schemas.
Yes, schema migration is expensive and problematic.
10. Perform “premature patternization” that has little or no
relevance to the user’s requirements.
Patterns, as we usually consider them, are clever ways of
creating structural or strategic solutions to problems.
Don’t jump the gun too quickly.
However, there is such as thing as “analysis patterns”
[Fowler]
Recurring structures of problem spaces of particular
domains 61
 References

• An excellent introduction to OO design:

– Page-Jones, M (2000). Fundamentals of Object-
Oriented Design in UML. Chapters 4 & 12.
– More advanced topics, including OO design
metrics are covered in Chapters 8 -15.
• A comprehensive guide to OO design:
– Bertrand Meyer (1997). Object-Oriented Software
Construction (2nd edition). Pages 1-125.

62
Advanced Analysis and
Object-Oriented Design

Lecture 5

Statechart Diagram
1
UML Architectural Views and Diagrams

2
 Visualizing, Specifying, Constructing, Documenting

Use Case Activity Diagram

Diagram Actor A Actor B State Transition
Diagram add file

Use Case 1

Domain [yes]
add file [ numberOffile==MAX ] /

flag OFF
Writing

Deployment
Expert Actor A Use Case 2 Actor B Openning

close file
Closing
close file

Diagram
Reading

Use Case 3
ºÐ»ê ȯ°æÀÇ Çϵå¿þ¾î¹× ³×Æ®¿÷À¸·ÎÀÇ Á¤º¸ ½Ã½ºÅÛ ¿¬°á ¸ðµ¨
- À©µµ¿ì 95 : Ŭ¶óÀ̾ðÆ®
- À©µµ¿ì NT: ÀÀ¿ë¼-¹ö
- À¯´Ð½º ¸Ó½Å: ÀÀ¿ë ¼-¹ö ¹× µ¥ÀÌŸ ¼-¹ö, Åë½Å ¼-¹ö
- IBM ¸ÞÀÎÇÁ·¹ÀÓ: µ¥ÀÌŸ ¼-¹ö, Åë½Å ¼-¹ö

Window95 Windows95
Windows95

¹®¼-°ü¸®
Ŭ¶óÀ̾ðÆ®.EXE
¹®¼-°ü¸® ¾ÖÇø´

9: sortByName ( )
Class Diagram Windows
NT

¹®¼-°ü¸® ¿£Áø.EXE
Solaris

Alpha
UNIX
DocumentList ÀÀ¿ë¼-¹ö.EXE
Document Windows
FileMgr NT
mainWnd : MainWnd add( )
delete( )
name : int
fetchDoc( )
docid : int IBM
sortByName( ) numField : int
1: Doc view request ( ) Mainframe
L
get( )
open( ) read() fill the
close( ) code..
2: fetchDoc( )

4: create ( ) gFile : GrpFile

FileList
fList
read( )
sortFileList( )
create( )
fillDocument( )
Repository µ¥ÀÌŸº£À̽º¼-¹ö

8: fillFile ( ) add( )
delete( )
1

user : »ç¿ëÀÚ
FileManager

User Interface fileMgr : FileMgr

7: readFile ( )
3: create ( )

6: fillDocument ( )

Repository
rep

(from Persistence)

name : char * = 0
File

read( ) GrpFile
Document

Definition
read( )
5: readDoc ( ) readDoc( )
open( )
readFile( )
document : Document create( )
fillFile( )
repository : Repository

GraphicFile File FileList

Collaboration Diagram
Component Diagram
Source Code
mainWnd fileMgr : document : gFile repository
edit, compile,
ƯÁ¤¹®¼-¿¡ ´ëÇÑ º¸±â¸¦
»ç¿ëÀÚ°¡ ¿äûÇÑ´Ù.
user

1: Doc view request ( )

FileMgr

2: fetchDoc( )
Document

debug, link
3: create ( )

4: create ( )

5: readDoc ( )

È-ÀÏ°ü¸®ÀÚ´Â Àоî¿Â 6: fillDocument ( )

¹®¼-ÀÇ Á¤º¸¸¦ ÇØ´ç ¹®¼-
°´Ã¼¿¡ ¼³Á¤À» ¿äûÇÑ´Ù.

7: readFile ( )

8: fillFile ( )

È-¸é °´Ã¼´Â ÀоîµéÀÎ 9: sortByName ( )

°´Ã¼µé¿¡ ´ëÇØ À̸§º°·Î
Á¤·ÄÀ» ½ÃÄÑ È-¸é¿¡
º¸¿©ÁØ´Ù.

Model
Sequence Diagram
space
ForwardEngineering
Forward Engineering
(CodeGeneration)
(Code Generation)and
and Executable System
ReverseEngineering
Reverse Engineering

3
System Model
Š Dynamic model
ƒ Sequence diagrams for collaborating objects
(between objects)
ƒ State diagrams for classes with significant
dynamic behavior (single object)
ƒ Activity Diagrams for work flow behavior of
system (state and sequence of activities)

4
Dynamic Modeling with UML

State Chart Diagram

5
Dynamic Modeling with UML
Š State Chart Diagram:
ƒ A state machine that describes the response of
an object of a given class to the receipt of
outside stimuli (Events).
Š Activity Diagram:
ƒ Special type of statechart where all states are
action states

6
State Chart Diagram vs Sequence Diagram

Š State chart diagrams help to identify:

ƒ Changes to objects over time

Š Sequence diagrams help to identify

ƒ The temporal relationship between objects over
time
ƒ Sequence of operations as a response to one
ore more events

7
Dynamic Modeling
Š Definition of dynamic model:
ƒ A collection of multiple state chart diagrams, one
state chart diagram for each class with important
dynamic behavior.
Š Purpose:
ƒ Detect and supply methods for the object model
Š How do we do this?
ƒ Start with use case or scenario
ƒ Model interaction between objects => sequence
diagram
ƒ Model dynamic behavior of single objects =>
statechart diagram

8
State chart Diagram
Š The State Chart Diagram Shows a behavior that
specifies the sequence of states an object goes
through during its lifetime in response to events,
together with its response to those events.
Š A state is a condition or situation during the life of
an object during which it satisfies some condition,
performs some activity, or waits for events.
Š An event is the specification of a significant
occurrence that has a location and time space. It is Initial state
an occurrence that can trigger a state transition.
Š A transition is a relationship between two states
indicating that an object in the first state will Final state
perform certain actions and enter the second state
when a specified event occurs and a specified
condition are satisfied.
Š An action is an executable computation that
results in a change in state of the model

9
What is an Event?

Š Something that happens at a point in time

Š Relation of events to each other:
ƒ Causally related: Before, after,
ƒ Causally unrelated: concurrent
Š An event sends information from one object to
another
Š One distinguishes between
ƒ The instance of an event : enterItem
ƒ The attributes of an event : itemID, quantity

10
Example

Š A Heater in a home might be in any of four

states: Idle (waiting for a command to
start heating the house), Activating ( its
gas is on, but it’s waiting to come up to
temperature), Active (its gas and blower
are both on) and Shutting down (its gas
is off but its blower is on, flushing residual
heat from the system)

11
State Chart Diagrams

Š Statechart diagrams are useful when

ƒ A class has an interesting or complex life cycle,
e.g. classes that create or delete instances or
associations
ƒ An instance can update its attributes in a variety
of ways as it goes through a life cycle.
ƒ If two classes are depending on each other, in
that one of them can start the other on its life-
cycle, or change the order in which it goes from
state to state.
ƒ If you find that the object’s current behavior
depends on what happened to it before, that is
on its past history.

12
Statechart Diagrams
Š Graph whose nodes are states and whose directed arcs
are transitions labeled by event names.
Š Distinguish between two types of operations:
ƒ Activity: Operation that takes time to complete
• associated with states
ƒ Action: Instantaneous operation
• associated with events
• associated with states (reduces drawing
complexity): Entry, Exit, Internal Action
Š A statechart diagram relates events and states for one
class
ƒ An object model with a set of objects has a set of
state diagrams
13
14
Actions & Activities

15
Basic UML Statechart Diagram

16
Object lifecycle and State Machines

17
Actions on Entry to States

18
Order of Actions: Simple Case
Entry Effect

Entry Effect

Entry and Exit Effects – When you want to perform

some setup action whenever you enter a state or exit a
state.
19
State (“Do”) Activities
Use “do” transition to specify the work that’s to be
done inside a state after the entry action is dispatched.

20
Guard Conditions

A guard condition is evaluated only after the trigger event for its for
its transition occurs
21
Guards

22
State Diagram for a Phone Line

23
Statecharts: Recap

24
Lets Try

Company A has a bug tracking system. This system has a

UserAccount class which represents a user in the system.
Once the System Administrator creates a user, a
UserAccount object will be created with a pending state.
The UserAccount object will be active only when the
System Manager approves the user. If the System
Manager rejects the user, the UserAccount will be in
inactive state. The System Manager can call Activate
User and Deactivate User to move the UserAccount
object to active or inactive state. The system administrator
will periodically call Delete User function to delete the
UserAccount objects, which are in the inactive state.

25
The END

26
 Component Diagram &
Deployment Diagram

Dr Samantha Thelijjagoda
SLIIT

1
AAOOD – Dr Samantha Thelijjagoda-2008 SLIIT
 Topics Covered

 Use Case Diagram- Use case view

 Class Diagram- Structural view
 Statechart Diagram- Behavioral view
 Component Diagram- Implementation view
 Deployment Diagram- Deployment view

2
AAOOD – Dr Samantha Thelijjagoda-2008 SLIIT
 UML Architectural Views and
Diagrams

3
AAOOD – Dr Samantha Thelijjagoda-2008 SLIIT
 Visualizing, Specifying,
Constructing, Documenting
Use Case Activity Diagram
Diagram Actor A Actor B
State Transition
Diagram
Use Case 1
add file

Domain [yes]
add file [ num berOffil e= =MAX ] /
Deployment
Expert
Writing

Actor B
flag OF F

Actor A Use Case 2

Diagram
Openning

close file

close file
Closing
Reading

Use Case 3
ºÐ»ê ȯ°æ ÀÇ Çϵå¿þ ¾î¹ × ³×Æ® ¿÷À¸·ÎÀÇ Á¤º ¸ ½Ã½ºÅÛ ¿¬°á ¸ðµ ¨
- À©µ µ¿ì 95 : Ŭ¶óÀ̾ðÆ ®
- À©µ µ¿ì N T: ÀÀ¿ë ¼­ ¹ö
- À¯´Ð ½º ¸Ó ½Å: ÀÀ¿ë ¼­ ¹ö ¹× µ¥ÀÌŸ ¼­ ¹ö, Åë½Å ¼ ­ ¹ö
- IBM ¸ÞÀÎÇÁ·¹ÀÓ: µ¥ÀÌŸ ¼ ­¹ö, Åë ½Å ¼ ­¹ö

Window95 Windows95
Windows95

¹®¼ ­°ü¸®
Ŭ¶óÀ̾ðÆ®.EXE
¹®¼ ­°ü¸® ¾ÖÇø ´

9: sortByNam e ( )
Class Diagram Windows
NT

¹®¼ ­°ü¸® ¿£Áø.EXE

Solaris

Alpha
UNIX
DocumentList ÀÀ¿ë¼­ ¹ö.EXE
Document Windows
FileM gr NT
mainWnd : Mai nWnd add( )
name : int
fetchDoc( ) delete( )
docid : int IBM
sortByName ( )
1: Doc view r equest ( ) numFi eld : int Mainfr ame
L
get( )
open( ) read( ) fill the
close( ) code..
2: fetchDoc( )

4: create ( ) gFile : Gr pFil e

FileList

fList
read( )
sortFil eList( )
create ( )
fillDocument ( )
Repository µ¥ÀÌŸº£À̽ º ¼­ ¹ö

8: fillFile ( ) add( )
delete( )
1

us er : »ç¿ ëÀÚ
FileManager

User Interface fileMgr : FileMgr

7: read File ( )
3: create ( )

6: fillDocume nt ( )

Repository
rep

(fro m Persist ence)

name : cha r * = 0
File

read( ) GrpFil e
Document

Definition
5: readDoc ( ) readDoc ( ) read( )
readFi le( ) open( )
document : D oc ument create ( )
fillFile ( )
repository : R epositor y

GraphicFile File FileList

Collaboration Diagram
Component Diagram
Source Code
mainWnd fileMgr : document : gFile repository
edit, compile,
debug, link
us er FileMgr Doc ument

ƯÁ¤¹®¼ ­¿ ¡ ´ëÇÑ º¸±â ¸¦ 1: Doc view r equest ( )

»ç¿ëÀÚ°¡ ¿äûÇÑ ´Ù.

2: fetchDoc( )

3: create ( )

4: create ( )

5: readDoc ( )

È­ÀÏ°ü¸®ÀÚ´Â Àоî¿Â 6: fillDocume nt ( )

¹®¼ ­ÀÇ
¡ ¼Á¤º¸
¸¦ ÇØ ´ç ¹®¼ ­Ù.
°´Ã¼¿ ³Á¤À» ¿äûÇÑ´

7: read File ( )

8: fillFile ( )

È­¸é °´Ã¼ ´Â ÀÐ¾îµ éÀÎ 9: sortByNam e ( )

°´Ã¼µé ¿¡ ´ëÇØ À̸ §º°·Î
Á¤·ÄÀ» ½ÃÄÑ È­¸é¿¡
º¸ ¿©ÁØ´Ù.

Model
Sequence Diagram
space
ForwardEngineering
Forward Engineering
(CodeGeneration)
(Code Generation)and
and Executable System
ReverseEngineering
Reverse Engineering

4
AAOOD – Dr Samantha Thelijjagoda-2008 SLIIT
 Implementation View

5
AAOOD – Dr Samantha Thelijjagoda-2008 SLIIT
 Environment View

6
AAOOD – Dr Samantha Thelijjagoda-2008 SLIIT
 UML Physical Diagrams

 Show aspects of model implementation,

including source code structure and run-
time implementation structure
 Kinds
 component diagram
 deployment diagram

7
AAOOD – Dr Samantha Thelijjagoda-2008 SLIIT
 Component Diagram: Why?
 Logical modeling is to visualize, specify, and
document the decisions about the vocabulary of the
domain and the structural and behavioral way those
things collaborate.
 Physical modeling is to construct the executable
system.
 Whereas these logical things live in the conceptual
world, the physical things live in the world of bits…
 that is, they ultimately reside on physical nodes and can be
executed directly or can, in some indirect manner,
participate in an executing system.

8
AAOOD – Dr Samantha Thelijjagoda-2008 SLIIT
 What is a Component
Diagram?
 Is a way to model the physical aspects of an
Object Oriented System.
 A way to visualize and specify component
based systems.
 That is…Explains the structure of a system
 Shows the organizations and dependencies
among software components.
 Collection of
 Components
 Interfaces
 The relationships between them

9
AAOOD – Dr Samantha Thelijjagoda-2008 SLIIT
 What is a UML Component?

 The Rational definition

“A component is a physical and replaceable part
of a system that conforms to and provides the
realization of a set of interfaces”
 A component is a single piece of software…i.e
Physical module of code.
 Graphically denoted as a rectangle with tabs.

10
AAOOD – Dr Samantha Thelijjagoda-2008 SLIIT
 What is a UML Component?

 Key word in the definition is physical.

 A component must be something physical in
the system
 Executables, tables,
 Data file, documents, DLL

 In software, many operating systems and programming

languages directly support the concept of a component.
 Object libraries, executables, COM+ components, and
Enterprise Java Beans are all examples of components that
may be represented directly in the UML by using
components.

11
AAOOD – Dr Samantha Thelijjagoda-2008 SLIIT
 What is a UML Interface?

 An interface is a collection of operations that

are used to specify a service of a class or a
component.
The object has to present a “face” to the
outside world, so that other objects can ask
the object to execute its operations. This face
is the object’s interface
 The relationship between component and
interface is important.
12
AAOOD – Dr Samantha Thelijjagoda-2008 SLIIT
 What is a UML Interface?
 The diagram show the relationship between a
component and its interfaces in one of two ways.

 The first (and most common) style renders the interface

in its elided, iconic form. The component that realizes the
interface is connected to the interface using an elided
realization relationship.

 The second style renders the interface in its expanded

form, perhaps revealing its operations. The component
that realizes the interface is connected to the interface
using a full realization relationship.

13
AAOOD – Dr Samantha Thelijjagoda-2008 SLIIT
 What is a UML Interface?

14
AAOOD – Dr Samantha Thelijjagoda-2008 SLIIT
 Dependency Among
Components
 The components that realize the interface is
connected to the interface using realization
relationship.
 The components that access the services of the
other component through the interface is connected
to the interface using dependency relationship.

15
AAOOD – Dr Samantha Thelijjagoda-2008 SLIIT
 Kinds of Components

 Three kinds of components:

 Deployment components

 These are the components necessary and

sufficient to form an executable system, such
as dynamic libraries (DLLs) and executables
(EXEs).
 I.e. parts of the software system that allows it to
execute.

16
AAOOD – Dr Samantha Thelijjagoda-2008 SLIIT
 Kinds of Components

 Work product components

 Files required to build the software system, consisting of
things such as source code files and data files from
which deployment components are created.
 These components do not directly participate in an
executable system but are the work products of
development that are used to create the executable
system.

17
AAOOD – Dr Samantha Thelijjagoda-2008 SLIIT
 Kinds of Components

 Execution component
 These components are created as a result of
an executing system, such as a COM+ object.

18
AAOOD – Dr Samantha Thelijjagoda-2008 SLIIT
 How – UML Component
 Component structure shows
 Name of component
 Type of component (executable, file, table, document,
library)
 Interfaces to the component

19
AAOOD – Dr Samantha Thelijjagoda-2008 SLIIT
 Organizing Components

 You can organize components by grouping them in

packages in the same manner in which you
organize classes.
 You can also organize components by specifying
dependency, generalization, association
(including aggregation), and realization relationships
among them.

20
AAOOD – Dr Samantha Thelijjagoda-2008 SLIIT
 Background

 Initially components were nothing more than

a well defined set of classes with a clear
interface that required no other objects to
perform a given task

 Later, these classes were packaged into

libraries (the most famous are the DLLs that
came with Windows).

21
AAOOD – Dr Samantha Thelijjagoda-2008 SLIIT
 Background

 The internet accelerated the introduction

of distributed components.
 Three major players have emerged
 Microsoft
 Sun Microsystems
 OMG (Object Management Group)

22
AAOOD – Dr Samantha Thelijjagoda-2008 SLIIT
 Why use a Component
Diagram
 To model
 Source code
 Executable releases
 Physical databases
 Adaptable systems

23
AAOOD – Dr Samantha Thelijjagoda-2008 SLIIT
 To model source code

24
AAOOD – Dr Samantha Thelijjagoda-2008 SLIIT
 To model an executable
release

25
AAOOD – Dr Samantha Thelijjagoda-2008 SLIIT
 To model a physical database

26
AAOOD – Dr Samantha Thelijjagoda-2008 SLIIT
 To model adaptable systems

27
AAOOD – Dr Samantha Thelijjagoda-2008 SLIIT
 Component Diagrams

28
AAOOD – Dr Samantha Thelijjagoda-2008 SLIIT
 Component Diagram Explained

 Shows how the components are related

to each other
 ShoppingSession is dependent on the
methods exposed by the
ShoppingCartHome Interface in the
ShoppingCart component.
 Catalog component consists of
CatalogPK, CatalogInfo and CatalogJAR
components.

29
AAOOD – Dr Samantha Thelijjagoda-2008 SLIIT
 Node
 A node is a physical element that exists at
run time and represents a computational
resource, generally having at least some
memory and, often, processing capability

 Graphically, a node is rendered as a cube

30
AAOOD – Dr Samantha Thelijjagoda-2008 SLIIT
 Node
 A processor is a node that
has processing capability
 It can execute a component
 A device is a node that has no
processing capability
 In general, it represents
something that interfaces to the
real world

31
AAOOD – Dr Samantha Thelijjagoda-2008 SLIIT
 UML Node

 Represented by a name and a type of

the name.
 In the example, the node is an anonymous
Client.
 Components that are deployed within
the node are nested within the node.

32
AAOOD – Dr Samantha Thelijjagoda-2008 SLIIT
 Nodes Versus Components

 Similarities
 Both have names
 May participate in dependency, generalization, and
association relationships
 May be nested
 May have instances
 May be participants in interactions

33
AAOOD – Dr Samantha Thelijjagoda-2008 SLIIT
 Nodes Versus Components

 Differences
 Components are things that participate in the
execution of a system; nodes are things that
execute components
 Components represent the physical packaging of
otherwise logical elements; nodes represent the
physical deployment of components

34
AAOOD – Dr Samantha Thelijjagoda-2008 SLIIT
 Nodes and Components
 A set of objects or components that are
allocated to a node as a group is called a
distribution unit
 Can organize nodes by grouping them in
packages
 Can organize nodes by specifying
dependency, generalization, and
association relationships between them

35
AAOOD – Dr Samantha Thelijjagoda-2008 SLIIT
 What is a Deployment
Diagram?

 Deployment diagrams shows how artifacts are

deployed on system hardware. And how the
pieces of hardware connect to one another.

36
AAOOD – Dr Samantha Thelijjagoda-2008 SLIIT
 What is a Deployment
Diagram?
 Deployment diagrams are one of the two kinds of
diagrams used in modeling the physical aspects of an
object-oriented system
 A deployment diagram shows the configuration of run
time processing elements (nodes) and the components
that live on them
 Deployment diagrams may be used to show which
components may run on which nodes.

37
AAOOD – Dr Samantha Thelijjagoda-2008 SLIIT
 Deployment Diagrams

 Graphically, a deployment diagram is a collection of

vertices and arcs
 Deployment diagrams commonly contains
 Nodes
 Dependency and association relationships
 May contain notes and constraints

38
AAOOD – Dr Samantha Thelijjagoda-2008 SLIIT
 Notations

39
AAOOD – Dr Samantha Thelijjagoda-2008 SLIIT
 Combining the two Diagrams

 Place the Component Diagram on top of

the Deployment Diagram
 Which components run on which nodes?
 System awareness of components
 Component Interface communication details

40
AAOOD – Dr Samantha Thelijjagoda-2008 SLIIT
 How – Deployment Diagram

41
AAOOD – Dr Samantha Thelijjagoda-2008 SLIIT
 Deployment Diagram
Explained

42
AAOOD – Dr Samantha Thelijjagoda-2008 SLIIT
 43
AAOOD – Dr Samantha Thelijjagoda-2008 SLIIT
 Example of Deployment
Diagram

44
AAOOD – Dr Samantha Thelijjagoda-2008 SLIIT
 Why use a Deployment
Diagram
 To model
 Embedded systems
 Client / server systems
 Fully distributed systems

45
AAOOD – Dr Samantha Thelijjagoda-2008 SLIIT
 Embedded systems

46
AAOOD – Dr Samantha Thelijjagoda-2008 SLIIT
 Client / Server systems

47
AAOOD – Dr Samantha Thelijjagoda-2008 SLIIT
 Fully Distributed systems

48
AAOOD – Dr Samantha Thelijjagoda-2008 SLIIT
 Summary

 A well-structured component diagram

 Focuses on communicating one aspects of a
system’s static implementation view.
 A well-structured deployment diagram
 Focuses on communicating one aspects of a
system’s static deployment view

49
AAOOD – Dr Samantha Thelijjagoda-2008 SLIIT
 References:

 The Unified Modeling Language User Guide

 By Grady Booch, James Rumbaugh, Ivar
Jacobson

50
AAOOD – Dr Samantha Thelijjagoda-2008 SLIIT
Example Use Case

Banking System
 Actors
• Customer
• Employees
• Bank Teller
• Technician
• Loan officer
• Bank Computer
 Use Cases
• Withdraw money
• Apply for loan
• Withdraw cash from ATM
• Deposit cash at ATM
• Deposit money
• Service ATMs
• Process a loan
• Update customer database
Include (Uses) Relationship

Apply a loan
Withdraw Money

<<include>> <<include>>

Check User Info

 Extend Relationship
Withdraw Money

<<extends>>

Withdraw Cash
from ATM
Use Case Packages

Customer
Transactions::
update customer
database
 Flow of Events
• For example, in the context of an ATM system,
you might describe the use case ValidateUser
in the following way:
• Main flow of events:
– The use case starts when the system prompts the
Customer for a PIN number.
– The Customer can now enter a PIN number via the
keypad.
– The Customer commits the entry by pressing the Enter
button.
– The system then checks this PIN number to see if it is
valid.
– If the PIN number is valid, the system acknowledges
the entry, thus ending the use case.
 Example (Cont.)
• Exceptional flow of events:
– The Customer can cancel a transaction at any time by
pressing the Cancel button, thus restarting the use case. No
changes are made to the Customer's account.
• Exceptional flow of events:
– The Customer can clear a PIN number anytime before
committing it and reenter a new PIN number.
• Exceptional flow of events:
– If the Customer enters an invalid PIN number, the use case
restarts. If this happens three times in a row, the system
cancels the entire transaction, preventing the Customer from
interacting with the ATM for 60 seconds.
 CRC Cards
• Account.
– Responsibilities.
• Keeps a log of transactions, sorted by date.
• Knows the account balance.
– Collaborations.

• Transaction.
– Responsibilities.
• Knows the amount of a transaction.
• Knows the date of a transaction.
• Knows the amount to change an account balance by.
– Collaborations.
• Deposit.
• Withdrawal.
 CRC Cards
• Deposit.
– Responsibilities.
• Knows the amount to change an account balance by.
– Collaborations
• Transaction
• Withdrawal
– Responsibilities.
• Knows the amount to change an account balance by.
– Collaborations
• Transaction