Object-Oriented Analysis and Design

1
Object-Oriented Analysis and Design
Introduction
2
Topics and skills covered
Sample Activities
OO Analysis Design
Principles Guidelines
Topics and Skills
UML notation
Patterns
Case Study
3
OO Technology

• Owning a hammer does not make one an architect
• Knowing an OO language and access to a rich
  library is a necessary but insufficient first
  step in creating object systems
• Analyzing and designing a system from an object
  perspective is also critical

4
Analysis and Design
Analysis Investigation of the Problem
Design Logical Solution
5
OO Analysis and Design

• Emphasis on finding and describing the objects or
  concepts in the problem domain

• Emphasis on defining logical software objects
  that will ultimately be implemented in an OO
  programming language

6
Activities in AD

• 2 most important
• The most single important ability in OO is to
  skillfully assign responsibilities to software
  components
• Must be performed (inescapable) and it has the
  most profound effect on the robustness,
  maintainability, and reusability of software
  components.
• Next is finding suitable objects

7
OO emphasizes objects
Representation in analysis of concepts
Domain Concept
title
Public class Book public void print() private
String title
Representation in an OO programming language
8
OO Versus Function Oriented Analysis and Design
The Library Information System
OO A/D
Catalog
Librarian
Book
Library
9
Is it Analysis or is it Design?
The division between analysis and design is
fuzzy! Some methods classify an activity at
varying points on the continuum.
10
Test Cases
dependency on
11
An Example of OO Analysis and Design
A dice game in which a player rolls two die. If
the total is seven, they win otherwise they lose
12
Defining Use Cases of the Dice Game
For example, in the dice game, here is the Play a
Game use case. Use Case Play a
game Actors Player Description This use
case begins when the player picks up the dice and
rolls the dice. If the dice total seven, they
win otherwise, they lose
13
Conceptual Model of the Dice Game
2
Die
Player
1
Rolls
name
faceValue
1
2
Plays
1
1
Includes
DiceGame
14
Collaboration Diagram Illustrating Messages
Between Software
Play()
1r1 roll()
Player
D1 Die
2r2 roll()
D2 Die
15
Design class diagram of software components
Rolls
2
1
2
1
1
1
Includes
Plays
16
What is Visual Modeling?
Modeling captures essential parts of the
system. Dr. James Rumbaugh
Visual Modeling is modeling using standard
graphical notations
17
Visual Modeling Captures Business Process
Use Case Analysis is a technique to capture
business process from users perspective
18
Visual Modeling is a Communication Tool
Use visual modeling to capture business objects
and logic
Use visual modeling to analyze and design your
application
19
Visual Modeling Manages Complexity
20
Visual Modeling Defines Software Architecture
Model your system independent of implementation
language
21
Visual Modeling Promotes Reuse
Multiple Systems
Reusable Components
22
Key Ingredients
UML

• notation
• modeling tool
• process

Rational Rose
Rational Objectory Process
23
What is the UML?

• Unified Modeling Language
• a modeling language for object-oriented analysis
  and design
• It is not a methodology
• standard notation (v 1.1 11/97)
• metamodel (model of a model)

24
What is the UML?

• The UML combines the best of the best from
• Data Modeling concepts (Entity Relationship
  Diagrams)
• Business Modeling (work flow)
• Object Modeling
• Component Modeling
• The UML is the standard language for visualizing,
  specifying, constructing, and documenting the
  artifacts of a software-intensive system
• It can be used with all processes, throughout
  the development life cycle, and across different
  implementation technologies

25
Rumbaugh Jacobson
Meyer Pre- and post-conditions
Booch
Harel State Charts
Odell Classifications
UML
Wirfs-Brock Responsibilities
Shlaer-Mellor Object Life Cycles
Embly Singleton Classes
Fusion Operation descriptions, message numbering
Gamma et al. Frameworks, patterns,notes
26
History of the UML
Other methods Booch 91 OMT-1 OOSE
27
Goals of UML

• Provide users a ready-to-use, expressive visual
  modeling language so they can develop and
  exchange meaningful models
• Be independent of particular programming
  languages and development processes
• Provide a formal basis for understanding the
  modeling

28
Goals of UML

• Provide a formal basis for understanding the
  modeling language
• Encourage the growth of the OO tools market
• Support higher-level development concepts such as
  collaborations, frameworks, patterns, and
  components
• Integrate best practices

29
Process

• constrained versus. creativity
• discipline versus bureaucracy
• well managed iterative and incremental life cycle
  provides the necessary control without affecting
  creativity
• UML focuses on a modeling language, NOT a
  standard processes

30
Define iteration to address the highest risk
Initial risks Initial project scope
Plan and develop the iteration
Iteration N
Assess the iteration
Risks Eliminated
Revise project plan
Revise risk assessment
31
Modeling Language - Method

• Language
• Syntax
• Notation
• Semantics

• Method
• what to do
• how to do it
• why to do it

Coad/Yourdon
Objectory
Shlaer/Mellor
OMT
Fusion
32
Views of the UML
Component
Logical
Class Package
Use Case
Concurrency
Deployment
Sequence State Diagrams
External Agents Jacobson
33
UML categories
Things
Relationships
Diagrams
34
UML Things
Structural Behavioral Groups Annotational
35
Structural Things

• Nouns of the UML models
• Mostly the static parts of a model, representing
  elements that are either conceptual or physical

36
UML Things
Structural Behavioral Groups Annotational
Classes Interfaces Collaborations Use
Classes Components Nodes
37
Class

• Description of set of object that share the same
  attributes, operations, relationships and
  semantics

Window Origin Size Open() Close() Move() Display
()
38
Interface
interfaces

• Collection of operations that specify a service
  of a class or component.

IThesaurus
ISpell
IUnknown
Wordsmith.dll
component
39
Collaboration

• Defines an interaction and is a society of roles
  and other elements that work together to provide
  some cooperative behavior that is bigger that the
  sum of all the elements.

Chain of responsibility
40
Use case

• Description of a set of sequence actions that a
  systems performs that yields an observable result
  of value to a particular actor

Place Order
41
Component

• A physical and replaceable part of the system
  that conforms to and provide the realization of a
  set of interfaces.
• Typically represents the physical package of
  otherwise logical elements, such as classes,
  interfaces and collaborations.

Orderform.java
42
Node

• Physical element that exists at run time and
  presents a computational resource

server
43
UML Things
Structural Behavioral Groups Annotational
44
Behavioral Things

• Dynamic parts of UML models
• Represent behavior over time and space

45
Interaction

• Behavior that comprises a set of messages
  exchanged among objects within a particular
  context to accomplish a specific purpose

display
46
State Machine

• Behavior that specifies the sequences of states
  an object

Waiting
47
UML Things
Structural Behavioral Groups Annotational
Package
48
Package

• General-purpose mechanism for organizing elements
  into groups.
• Unlike components, which exist at run time, a
  package is purely conceptual

Business rules
49
UML Things
Structural Behavioral Groups Annotational
50
Annotational

• Explanatory parts

Return copy of self
51
UML Relationships
Dependency
Generalization
Association
Aggregation
52
UML Diagrams
Object
Statechart
Collaboration
Class
Sequence
Activity
Use Case
Component
Deployment
53
Diagrams

• Class - Set of classes, interfaces and
  collaborations and their relationships
• Object represents static snapshots of instances
  of things found in class diagrams
• Use case set of use cases and actors
• Interaction shows an interaction consisting of
  a set of objects and their relationships
  (sequence and collaboration are isomorphic)
• Statechart shows a state machine
• Activity special kind of statechart that shows
  the flow from activity to activity within a
  system
• Component organization and dependencies among a
  set of components
• Deployment configuration of run-time processing
  nodes and the components that live on them

54
Case Study Plan and Elaborate Phase
55
Case Study Point-of-Sale
The main case study is a point-of-sale terminal
(POST) system. A point-of-sale terminal is a
computerized system used to record sales and
handle purchases. It includes hardware components
such as a computer and a bar code scanner and
software to run the system We create the software!
56
Understanding the Requirements

• Create requirement phase artifacts, such as
  function specifications
• Identify and categorize system functions
• Identify and categorize system attributes and
  relate them to functions

57
Basic Functions
58
Understanding the Requirements

• Need to grasp
• the domain process
• users/surroundings

59
Grasping the Domain Process

• Use cases (Jacobson)
• a narrative description of a domain process
• a typical interaction between a user and a
  computer system
• captures some user-visible function
• may be small or large
• achieves a discrete goal for the user
• the use case diagram is now part of the UML

Borrow Books from the Library
60
High-level and Expanded Use Cases

• UML does not specify a rigid format
• High Level

Use Case Buy Items Actors
Customer, Cashier Type
Primary Description A Customer arrives at a
checkout with the items
to purchase. The Cashier records the
purchase items and collects payment.
On completion, the
Customer leaves with the items .

61
ACTORS
Someone or something that interacts with the
system
62
Actors

• Not part of the system
• may initiate interaction with the system
• are autonomous from the system
• can be people
• can be other systems

• Electrical or mechanical device
• Is a role
• a role can be played by more than one user
• one user can play more than one role
• documented in the Actor Catalog

63
Actor Catalog

• Actor
• Customer
• Cashier

• Role Description
• buys/returns items
• Process transactions

Customer
Cashier
UML icon for a user case actor
64
Expanded Use Case (Top section)
Use Case Buy Items with Cash Actors
Customer (initiator), Cashier Purpose
Capture a sale and its cash payment Overview
A Customer arrives at a checkout with items to
purchase. The Cashier records
the purchase items and
collects a cash payment. One completion, the
Customer leaves with the
items. Type primary and
essential Cross Refs R1.1, R1.2, R1.3, R1.7,
R1.9, R2.1
65
Explaining Expanded Use Case (Top section)
Use Case Name of the use case. Actors
List of actors(external agents), indicating
who initiates the use
case. Purpose Intention of the use
case Overview Repetition of the high-level
use case, or some similar
summary Type 1. primary, secondary or
optional (later) 2.
essential or real Cross Refs Related use cases
and system functions
66
Expanded Use Case Remaining Sections

• Typical contents - middle section
• how the use case starts and ends
• normal flow of events
• Typical contents - Final section
• alternative flow of events
• exceptional flow of events

67
Expanded Use Case (middle section)
Typical Course of Events Actor Action
System Response
1.This use case begins when a Customer
arrives at a POST checkout with items to
purchase. 2.The Cashier records the identifier
3. Determines the item price for each item.
and adds the
item
information to the running

sales transaction. If there is more
than one of the same item, the Cashier can
enter the The description and price
quantity as well.
of the current item are

presented.
68
Expanded Use Case (middle section continued)
Typical Course of Events Actor Action
System Response
4.On completion of item entry, the
5.Calculates and presents the Cashier
indicates to the POST sale total. that
item entry is complete. 6.The Cashier tells the
Customer the total. 7. The Customer gives a
cash pay- ment -- the cash tendered --
possibly greater than total. 8. The Cashier
records the cash 9.Shows the balance due
back received amount.
to the Customer. Generates
a
receipt.

69
Expanded Use Case (middle section continued)
Typical Course of Events Actor Action
System Response
10. The Cashier deposits the cash 11. Logs
the completed sale. received and extracts
the balance owing. The Cashier give
the balance owing and the printed receipt
to the Customer. 12. The Customer leaves with
items purchased
70
Expanded Use Case (final section)
Alternative Courses Event 2 Invalid identifier
entered. Indicate error. Event 7 Customer
didnt have enough cash. Cancel sales
transaction.
71
Decision Points and Branching

• Use cases may contain decision points.
• Example in Buy Items, the customer may choose to
  pay via cash, credit, or check or payment time
• If one of these decisions overwhelmingly
  represents the typical case and the others are
  rare, then the others should be mentioned in the
  alternatives section

72
Buy Items
Section Main Typical Course of Events Actor
Action
System Response 7. Customer chooses payment
type a. If cash payment, see section
Pay by Cash b. If credit payment, see
section Pay by Credit c. If check
payment, see section Pay by Check
Section Pay by Cash
73
A Common Mistake in Use Cases

• Represent individual steps, operations or
  transactions as use cases.
• Example Printing the Receipt - the printing
  operation is merely a step in much larger use
  case process Buy Items
• can break down activities or portions in sub-use
  cases (abstract use cases) but this is not the
  norm

74
Identifying Use Cases

• Actor-based
• Identify the actors related to a system or
  organization.
• For each actor, identify the processes they
  initiate or participate in.
• Event-based
• Identify the external events that a system must
  respond to.
• Relate the events to actors and use cases.

75
Notation - Naming Use Cases

• Name a use case starting with a verb in order to
  emphasize that it is a process.
• Buy Items
• Enter an Order

76
Examples
Event(process)-based Withdraw cash from
ATM Order a product Register for courses at a
school Check the spelling of a document in a
word processor Handle a telephone call
Actor-based Cashier Log In
Cash Out Customer Buy Items
Refund Items Manager Start
Up Sys-Admin Manage Users
77
Use Case Diagrams
POST
Buy Items
Customer
Cashier
Log In
Refund Items
Start Up
Manager
Manage Users
System Administrator
78
Essential versus Real Use Cases

• Essential
• free of technology and implementation details
• design decisions are deferred and abstracted
  especially related to the user interface
• Real
• concretely describes the process in terms of its
  real current design, committed to specific input
  and output technologies

79
Buy Items Use Case (essential)

• The expanded Buy Items use case already shown
  tends towards being an essential use case. Note,
  it is very non-committal with respect to the
  technical realization.
• Example. The Cashier records the identifier for
  each item.

80
Buy Items Use Case (real)
Real Actor Action
System Response 1. For each item, the
Cashier 2. Displays the item price and
types in the Universal Product and adds the
item infor- Code (UPC) in the UPC input
mation to the running sales field of Window1.
They then transaction, press the
Enter Item button with the mouse or by
pressing The description of the price
ltEntergt.
of the current item are
displayed in
Textbox 2 of
Window 1. 3. Etc.

81
Ranking and the Scheduling of Use Cases

• Completed the artifacts of Requirements Spec and
  Use Cases
• transition to the build phase of the iterative
  development life-cycle
• development cycles are organized around use cases
  - a development cycle is assigned to implement
  one or more use cases or simplified version of
  use cases

82
Ranking Use Classes

• High ranking use classes are tackled early
• Qualities that increase the ranking are
• significant impact on architectural design
• risky, time-critical, or complex functions
• involve significant research, or new technology
• represents the primary line-of-business
• directly support increased revenue or decreased
  cost

83
POST Scheduling

• Buy Items should be tackled first. Also a simple
  version of Start Up to support other use cases
• Buy Items - v1 (cash payments, no inventory
  updates)
• Buy Items - v2 ( allow for all payment types)
• Buy Items - v3 ( complete version including the
  handling of inventory updates)

84
Allocation of Use Cases
Development Cycle 1
Development Cycle 2
Development Cycle 3
Development Cycle 4
Buy Items Version 1 ...
Buy Items Version 2 ...
Buy Items Version 3 ...
Log in ...
Refund Items ...
85
Case Study Analysis Continued