ObjectOriented Programming and Unified Process

1
Object-Oriented Programming and Unified Process

• Shyh-Kang Jeng
• Department of Electrical Engineering/
• Graduate Institute of Communication Engineering
• National Taiwan University

2
Reference

• R. C. Lee and W. M. Tepfenhart, UML and C, A
  Practical Guide to Object-Oriented Development,
  2nd ed., Prentice Hall, 2001
• G. Booch, J. Rumbaugh, and I. Jacobson, The
  Unified Modeling Language User Guide, Addison
  Wesley, 1999.
• I. Jacobson, G. Booch, and J. Rumbaugh, The
  Unified Software Development Process, Addison
  Wesley, 1999.
• S. W. Ambler, The Unified Process Elaboration
  Phase, RD Books, 2000.
• F. P. Brooks, Jr., The Mythical Man-Month
• Essays on Software Engineering,
  Addison-Wesley, 1975

3
Jengs First Principle of Engineering Design
Functions determine forms
4
Jengs Second Principle of Engineering Design
Divide and conquer
5
Jengs Third Principle of Engineering Design
Model through abstraction levels
6
Jengs Fourth Principle of Engineering Design
Focus on critical components
R. Koch ??, ???? , 80/20??, ????, 1998
7
Jengs Fifth Principle of Engineering Design
Prototype and iterate
8
Jengs Sixth Principle of Engineering Design
Always test
9
Key OO Concepts

• Encapsulation
• Information hiding
• Message passing
• Instantiation
• Inheritance
• Polymorphism

10
Object-Oriented Thinking

• What is the required function of the system?
• What are the objects/classes in the system (to
  provide this function)?
• How is the required system behavior distributed
  among these objects/classes (to provide this
  function)?

11
Results of the Object-Oriented Thinking

• Structure
• Inheritance
• Association
• Behavior
• Static
• Dynamic

12
Major OOP Activities

• Bound the domain
• Find the objects and related services
• Identify classes and related attributes
• Specify static behavior
• Specify dynamic behavior
• Identify relationships
• Design
• Implement

13
Bound the Domain usingUse Cases

• Specifies a sequence of actions, including
  variants, that a system performs and that yields
  an observable result of value to a particular
  actor
• Ease discussions between stakeholders and
  analysis/developers
• Typically written using business terms that are
  natural to the majority of stakeholders

14
Jengs First Principle of Expression
A picture is worth thousands of words
15
Use Case Diagram
16
Flow of Events

• Example ATM Validate User
• Main flow of events
• Exceptional flow of events
• Customer cancel a transaction
• Customer clear a PIN number
• Customer enters an invalid PIN number

17
Scenarios

• A use case describes a set of sequences in which
  each sequence in the set represents one possible
  flow through all these variations.
• Each sequence is called a scenario.
• A scenario is a specific sequence of actions that
  illustrates behavior.

18
Guidelines for Developing Use Cases

• Avoid analysis paralysis
• Identify actors
• Identify high-level and essential use cases
• Develop use case details
• Identify supporting use cases

19
Detailed Description of Use Case

• Precondition
• Flow of Events
• Basic Path
• Alternative Paths
• Statechart Diagrams for States and Transitions
• Activity Diagrams for Sequence of Actions
• Interaction Diagrams for Interactions between Use
  Case and the Actors

20
Activity Diagrams
21
Find Objects Using Nouns

• Use the nouns, pronouns, and noun phrases to
  identify objects and classes
• Singular proper nouns and nouns of direct
  reference (the sixth player, the one-millionth
  purchase) are used to identify objects
• Plural nouns and common nouns are used to
  identify classes
• Verbs and predicate phrases are used to identify
  the services

22
Object Categories According to Coad and Yourdon

• Structure
• Kind-of and Part-of
• Other systems
• External systems
• Devices
• Events remembered
• A historical event that must be recorded
• Roles played
• The different role(s) that users play
• Locations
• Organization units
• Groups to which the user belongs

23
Object Categories According to Shlaer and Mellor

• Tangible
• Cars, telemetry data, sensors
• Roles
• Mothers, teachers, programmers
• Incidents
• Landing, interrupt, collision
• Interactions
• Loan, meeting, marriage
• Specification
• Product specifications, standards

24
Object Categories According to Ross

• People
• Human who carry out some function
• Places
• Areas set aside for people or things
• Things
• Physical objects
• Organizations
• Collection of people, resources, facilities, and
  capabilities having a defined mission
• Concepts
• Principles or ideas not tangible, per se
• Events
• Things that happen (usually at a given date and
  time), or as steps in an ordered sequence

25
Identify Services

• In a sentence in the form subject-action
  verb-object, the verb usually defining a method
  that must be provided by the object of the
  sentence
• Example
• A person hit the ball
• The ball object must have a prototype service,
  e.g., beingHit(), to receive the hit message
  request from a person object
• Try to be as generic as possible for an
  opportunity to find abstract classes

26
Algorithmically Simple Services

• Create
• Creates and initializes a new object
• Connect
• Connects an object with another object
• Access
• Gets or sets attribute values
• Disconnect
• Disconnects an object from another object
• Delete
• Deletes an object

27
Algorithmically Complex Services

• Calculate
• Calculations that the object is responsible for
  performing on its values
• Monitor
• Monitors that the object is responsible for in
  order to detect or respond to external system or
  device or internal object
• Query
• Computes a functional value without modifying the
  object

28
Identify Objects Using CRC Cards

• Start the effort as a brainstorming session for
  classes
• Use the use cases to generate scenarios for the
  system
• Position all of the classes on a white board and
  draw association arcs between the classes to
  represent the collaboration

29
CRC Card for an Object
Object Name withdrawManager
Collaborators
Responsibilities Ask user for amount to
withdraw Verify amount with
AccountManager Tell cash dispenser to release
cash
accountManager cashDispenser
30
UML Notation for an Object

• Example

31
Identify Classes

• Group objects with the same services into a class
• Refine later
• Can be modified

32
CRC Card for a Class
Class Name WithdrawManager
Collaborators
Responsibilities Ask user for amount to
withdraw Verify amount with
AccountManager Tell CashDispenser to release
cash
AccountManager CashDispenser
33
UML Notation for a Class

• Example

34
Instances

• Example

35
Properties of Attributes

• Must capture a characteristic that is consistent
  with the semantic domain in which the object
  resides
• An instance has exactly one value for each
  attribute at any given time
• Must not contain an internal structure
• Must be a characteristic of the entire entity and
  not a characteristic of its composite parts

36
UML Notations for Attributes

• Example

37
Specifying Static Behavior

• Behavior is the set of actions that an object is
  responsible for a specific service
• Usually captured as a method in the object
• A static behavior is implemented as the operation
  (code) within the method, and is not affected by
  any internal or external events
• Use interaction diagrams to document the static
  behavior
• Pseudo code and/or other support documents may be
  necessary to specify complicated behavior

38
Messages

• Examples

39
Sequence Diagrams

• Example

40
Collaboration Diagrams

• Example

41
Specifying Dynamic Behavior

• Dynamic modeling mechanisms provide a way to
  capture the behavior of objects, and thus the
  behavior of the application, over time
• Events
• The stimuli
• States
• Object configurations that exist between events

42
A Simple Statechart Diagram
43
Implementing States

• enum MachineState INITIAL, IDLE, RUNNING, FINAL
  
• enum Event KEY_PRESS, FINISHED, SHUTDOWN
• class Machine
• //
• MachineState state
• //
• void respond( const Event e )
• //

44
Implementing State Transitions

• void respond( const Event e )
• switch( state )
• case INITIAL
• state IDLE
• break
• case IDLE
• if( e KEY_PRESS ) state RUNNING
• break
• case RUNNING
• if( e SHUT_DOWN ) state FINAL
• if( e FINISHED ) state IDLE
• break
• case FINAL

45
Statechart Diagrams

• Example

46
Identifying Relationships

• Objects typically depend on other objects for
  services and possibly for error handling,
  constant data, and exception handling
• Interdependencies of objects are called
  relationships
• Major relationships
• Generalization
• Association
• Link
• Aggregation

47
Class Diagrams

• Example

48
Generalization
49
Implementing Generalization

• class Shape
• //
• Class Rectangle public Shape
• //
• class Square public Rectangle
• //

50
Association Name, Role, Multiplicity

• Example

1..

Works for
Company
Person
employee
employer
51
Implementing Association

• class Person
• //
• Company employer
• //
• class Company
• //
• Person employee
• //

52
Association Object

• class WorksForPair
• //
• Person employee
• Company employer
• //
• class WorksFor
• //
• WorksForPair w
• //

53
Association Aggregation

• Example

Company
1

Department
54
Modeling Structural Relationships

• Example

55
Implementing Aggregation

• class School
• //
• Department departments
• // created and destructed by School objects
• Student students
• // created and destructed outside the
• // School objects
• //

56
Preparation for Design and Implementation

• Form
• Class diagrams for relationship
• Function
• Interaction diagrams for static behavior
• Statechart diagrams for dynamic behavior
• Pseudo code and/or other support documents when
  necessary

57
Dependency

• Example

58
Visibility

• Example

59
Notes

• Examples

60
Case Study

• Statement of the Problem

61
Use case diagram
Simulate Operation
62
Use case description

• The user starts by entering the fabrication
  mode of every machine and execution time. The
  system then simulates the production line for the
  entered execution time. After that the system
  reports the sizes of all queues. The user
  decides to quit or continue. If continue, the
  user enters the fabrication modes and execution
  time again, and the system repeats. The system
  stops when the user decides to quit.

63
List of Object Candidates

• production line
• m1, m2
• rm, q1, q2, q3

64
Initial Class Diagram
ProductionLine
5
2
Queue
Machine
4
Connects to
2 input queues 2 output queues
65
Statechart Diagram for Machine
66
Statechart Diagram for Machine Modes
Input Queue is Empty
67
Collaboration Diagram
1decrease
4increase
3decrease
2increase
2increase
4increase
3decrease
1decrease
68
Flow-of-Events Description

• First, machine m1 responds according to the
  statechart diagrams related to its fabrication
  mode and state. If in Idle state and the input
  queue is not empty, decrease the input queue (1).
  If in InProduction state and the In Production
  Hour reaches the Required Work Hours, increase
  the output queue (2). Similarly, machine m2
  responds according to the statechart diagrams
  related to its fabrication mode and state (3,4).

69
Initial Class Design -- ProductionLine
ProductionLine
Responsibilities -- simulate one hour -- set
fabricate modes -- add raw material
70
Initial Class Design Queue
71
Documents Required (1)

• To use a program
• Purpose
• Environment
• Domain and range
• Function realized and algorithms used
• Input-output formats
• Operating instructions
• Options
• Running time
• Accuracy and checking

72
Documents Required (2)

• To believe a program
• Test cases
• Mainline cases
• Barely legitimate cases that probe the edge of
  the input data domain
• Barely illegitimate cases that probe the domain
  boundary from the other side

73
Documents Required (3)

• To modify a program
• Design documents
• Descriptions of the algorithms used, or else
  references to such descriptions in the literature
• Explanation of the layout of all files used
• Discussion of modifications contemplated in the
  original design

74
Views of a Software System
Logical View
Implementation View
Use Case View
Process View
Deployment View
75
Subsystems
User Interface
Utility
Business Object
Database
76
Use Case View

• Understandability
• Usability
• Use case diagrams (structural modeling)
• Activity diagrams (behavioral modeling)

77
Logical View

• Functionality
• Class diagrams (structural modeling)
• Interaction diagrams (static behavioral modeling)
• Statechart diagrams (dynamic behavioral modeling)

78
Implementation View

• Software management
• Reuse
• Portability
• Component Diagrams

79
Component Diagram

• Example

Registration.exe
Database.dll
Mfc.dll
80
Process View

• Performance
• Scalability
• Availability
• Fault tolerance

81
Deployment View

• System topology
• Performance
• Availability
• Fault tolerance
• Scalability
• Delivery and installation
• Deployment diagram

82
Deployment Diagram

• Example

83
Workflows for Software System Development

• Requirements
• Analysis
• Design
• Implementation
• Test

84
Case Study

• Example ATM System

85
Architectural View of the Use-Case Model

• Example ATM System
• Withdraw Money is the most important use case.
• The Withdraw Money use case should be implemented
  in full during the elaboration phase. No other
  use case is deemed interesting for architectural
  purpose.
• Withdraw Money should be fully described.

86
Use Case Specification

• Example Withdraw Money
• 1. The Bank Customer identifies himself or
  herself
• 2. The Bank Customer chooses from which account
  to withdraw money and specifies how much to
  withdraw
• 3. The system deducts the amount from the account
  and dispenses the money

87
Analysis Model from Use Cases

• Example Withdraw Money

88
Use-Case Realization - Analysis

• Example ATM System

89
Use-Case Realization - Analysis

• Example Withdraw Money

90
Flow of Event Description

• Example Withdraw Money
• A Bank Customer chooses to withdraw money and
  activates the Cashier Interface object. The Bank
  Customer identifies himself or herself and
  specifies how much to withdraw and from which
  account (1). The Cashier Interface verifies the
  Bank Customers identity and asks a Withdrawal
  object to perform the transaction (2).

91
Design Model from Analysis Model

• Example Withdraw Money

92
Use-Case Realization - Design

• Example Withdraw Money

93
Use-Case Realization Design

• Example Withdraw Money

94
Grouping Classes into Subsystems

• Example ATM System

95
Architectural View of the Design Model

• Example ATM System

96
Architectural View of the Deployment Model

• Example ATM System

97
Implementation Model from Design Model

• Example ATM System

98
Test Cases from Use Cases

• Example Withdraw Money Basic Flow
• Input
• The Bank Customers account 12-121-1211 has a
  balance of 350.
• The Bank Customer identifies himself correctly.
• The Bank Customer request to withdraw 200 from
  account 12-121-1211.
• There is enough money (at least 200) in the ATM.
• Result
• The balance of the Bank Customers account
  12-121-1211 decreases to 150.
• The Bank Customer receives 200 from the ATM.

99
The Tar Pit
100
Evolution of the Programming Systems Product
101
Schedule Disaster (1)
102
Schedule Disaster (2)
103
Schedule Disaster (3)
104
The Babel Tower
105
The Man-Month
Months
Men
Months
Months
Men
Men
106
Software Development Process

• What is a software development process?
• Effective Process
• Provides guidelines
• Reduces risk
• Increase predictability

107
Waterfall Process
108
The Only Constancy isChange Itself

• Accept the fact of change as a way of life,
  rather than an untoward and annoying exception
• Both the actual need and the users perception of
  the need will change as programs are built,
  tested, and used
• Not all changes in customer objectives and
  requirements must, can, or should be incorperated
  in the design
• A threshold has to be established, and it must
  get higher and higher as development proceeds, or
  no product ever appears

109
Unified Process

• Iterative and Incremental
• Use-Case-Driven
• Architecture-Centric

110
Life Cycle
111
Iterative Development
112
Risk Reduction
113
Primary Model Set
114
Jengs Fourth Principle of Engineering Design
Focus on critical components
R. Koch ??, ???? , 80/20??, ????, 1998
115
Reims Cathedral
116
Conceptual Integrity

• Conceptual integrity is the most important
  consideration in system design
• It is better to have a system omit set certain
  anomalous features and improvements
• To reflect one set of design ideas, than to have
  one that contains many good but independent and
  uncoordinated ideas

117
Architecture Baseline
118
Layered Architecture
119
Resource Distribution
120
Millss Surgical Team
121
Workers
122
Generic Iteration Workflow
123
Inception Phase

• Goal
• Launch the project
• Works
• Define the system scope
• Outline the candidate architecture
• Forestall a fiasco

124
Focus of the Inception Phase
125
Evaluation Criteria

• Resolve system scope
• Resolve ambiguities in the requirements
• Establish a candidate architecture
• Mitigate the critical risks
• Establish an initial business case
• Obtain the assent of the stakeholders

126
Jengs First Principle forResources Allocation
Put first thing first
S. Covey, The 7 Habits of Highly Effective
People, Fireside, 1990 ??? ???, ?????, ????,
1995
127
Risk Management

• Priority
• Impact
• Monitor
• Responsibility
• Contingency
• Develop related use cases
• Implement prototypes to prove the concept

128
Capturing the Requirements

• List candidate requirements
• Feature list
• Understand system context
• Business or domain model
• Capture functional requirements
• Use-case model
• Capture nonfunctional requirements
• Supplementary requirements or individual use cases

129
Vision of the System

• Example Interbank Consortium (1/3)
• The Interbank Consortium is facing major changes
  due to deregulation, new competition, and
  capabilities enabled by the World Wide Web. The
  Consortium plans to develop new applications to
  support the rapidly changing finance markets. It
  has directed its software development subsidiary,
  Interbank Software to initiate the development of
  these applications.

130
Vision of the System

• Example Interbank Consortium (2/3)
• Interbank Software decides to design the Billing
  and Payment System in collaboration with some of
  its main bank customers. The system will use the
  Internet for sending orders, invoices, and
  payments between buyers and sellers. The banks
  motivation for developing the system is to
  attract new customers by offering a low
  payment-processing fee. The bank will also be
  able to reduce its wage costs by processing
  payment requests automatically through the
  Internet instead of manually through cashiers.

131
Vision of the System

• Example Interbank Consortium (3/3)
• The motivations for buyers and sellers are to
  reduce costs, paperwork, and processing time.
  For example, they will no longer have to send
  orders of invoices by paper mail. The payment of
  invoices will be handled between the buyers
  computer and the sellers computer. Buyers and
  sellers will also have a better overview of the
  status of their invoices and payments.

132
Feature List

• Example Billing and Payment System
• Use Internet to send the following items between
  buyers and sellers
• Orders
• Invoices
• Payments

133
Business Model

• Goal reach consensus between project
  stakeholders
• Contents
• Context model
• High-level use case model
• Glossary of key terms
• Optional high-level class diagrams
• High-level activity diagrams

134
Use-Case Prioritization

• Risks Specific to a Particular Project
• Translate them into use cases
• Risk of Not Getting the Architecture Right
• Seek the architecturally significant use cases
• Other categories secondary, ancillary, optional
• Risk of Not Getting the Requirement Right
• Do the requirements workflow right
• Build prototypes and get feedback on it as early
  as possible

135
Deliverables

• Feature list
• Business model
• Use-case model
• Candidate architecture description
• Prototype for demonstration
• Risk list and use-case ranking list
• Beginning plan of the entire project
• Business case

136
Elaboration Phase

• Goal
• Make the architecture baseline
• Work
• Capture most of the remaining requirements
• Formulate the functional requirements as use
  cases
• Establish a sound architectural foundation
• Continue monitor remaining critical risks
• Identify significant risks to estimate their
  impacts

137
Focus of the Elaboration Phase
138
Evaluation Criteria

• Extend the requirements
• Establish baseline architecture
• Mitigate the significant risks
• Refine the business case

139
Logical User-Interface Design

• Example Pay Invoice

140
Physical User-Interface Design
141
Analysis

• Take care of the use cases that are
  architecturally significant (lt 10 of the use
  case mass).
• Analyze about 20 40 more mass use cases to
  understand them more.

142
Analyze a Class

• Based on Use-Case Realization-Analysis and
  Analysis Class outlined to obtain Analysis
  Class complete
• Identify responsibilities
• Identify attributes
• Identify associations and aggregation
• Identify generalization
• Capture special requirements

143
Design a Class

• Outline the Design Class
• Identify Operations
• Identify Attributes
• Identify Associations and Aggregations
• Identify Generalization
• Describe Methods
• Describe States
• Handle Special Requirements

144
Design a Subsystem

• Maintain the subsystem dependencies
• Maintain the interfaces provided by the subsystem
• Maintain the subsystem contents

145
Layer Structure of the System
User Interface Classes
System Classes
Controller
Business/Domain Classes
Persistence Classes
Persistent Store(s)
146
Integrate System

• Example Integration Build Plan

147
Implement a Class

• Outline the file components
• Generate code from a Design Class
• Implement operations
• Make the component provide the right interface

148
Perform Unit Test

• Perform Specification Tests
• Example Withdrawing from an Account
• Normal values e.g., 4, 3.14, 5923
• Boundary values e.g., 0, smallest and largest
  possible positive numbers
• Values outside the possible range
• Illegal values e.g., -14, A
• Perform Structure Tests

149
Plan Test

• If it isnt worth testing, then it isnt worth
  creating
• Describe a test strategy
• Estimate the requirements for the testing effort,
  such as the human and system resources needed
• Schedule the test

150
Design Test

• Design integration test cases
• Design system test cases
• Design regression test cases
• Identify and structure test procedures

151
Test in the Large
Regression Test
Alpha/Beta Test
Installation Test
Operations Test
User Acceptance Test
System Test
User Test
Record Defects
152
Test in the Small
Regression Test
Walkthrough Models
Review Prototypes
Boundary Coverage Check
Use-Case Scenario Test
OO Test
153
Deliverables

• Preferably a complete business model
• New version of all models
• Executable architectural baseline
• Architectural description
• Update risk list
• Project plan for the construction and transition
  phases
• Preliminary user manual (optional)
• Complete business case, including business bid

154
Construction Phase

• Goal
• Lead to initial operational capability
• Work
• Detail the remaining use cases and scenarios
• Modify the architectural description
• Continue the workflows through additional
  iterations
• Integrate the subsystems and test them
• Integrate the entire system and test it

155
Focus of the Construction Phase
156
Deliverables

• Project plan for the transition phase
• Executable software, the initial-operational-capab
  ility release
• All artifacts, including models of the system
• Maintained and minimally updated architecture
  description
• Preliminary user manual in enough detail to guide
  beta users

157
Transition Phase

• Goal
• Complete product release
• Work
• Find out whether the system really does what the
  business and its users request
• Discover unanticipated risks
• Note unresolved problems
• Find failures
• Fix ambiguities and gaps in the user
  documentation
• Focus on areas in which users appear to be
  deficient and in need of information or training

158
Evaluation Criteria

• Did the beta users cover the key functions
  involved in the successful operation of the
  product in the field?
• Did the product pass acceptance tests conducted
  by the customer? The test criteria are set by
  the contract.
• Is the user material of acceptable quality?
• Is required course material ready to use?
• Do customers and users appear to be satisfied
  with the product?

159
Installing the Beta Release

• Normally a large number of beta sites
• Transition staff are not present
• Issue specific instructions as to how to install
  the software, how to operate it, what
  problems/issues beta customers and users should
  focus on, and how to report faults or other
  problems found

160
Responding to the Test Results

• Failures
• Is the defect likely to be related to other
  defects not yet discovered?
• Can it be corrected without affecting
  architecture or design?
• Has it been corrected without introducing new
  defects?
• Broader problems
• Important to maintain the architectural integrity
  of the system while correcting problems and
  defects

161
Adapting the Product to Varied User Environments

• Marketplace relationship
• Single-client relationship
• Data migration or conversion

162
When Does the Project End?

• Marketplace relationship
• The project manager concludes that the vast mass
  of customers will be satisfied when the project
  has acted upon the feedback from the beta tests
• Single-client relationship
• The project manager concludes that the customer
  is satisfied when the system passes acceptance
  testing

163
Deliverables

• Executable software, including installation
  software
• Legal documents such as contracts, license
  documents, waivers, and warranties
• Completed and corrected product release baseline
  including all models
• Completed and updated architecture description
• Final user, operator, and system administrator
  manuals and training materials
• Customer support references and web references

164
Homework

• Apply the Unified Software Development Process to
  conduct the Inception Phase work for a software
  system, which may or may not be related to your
  term project.