1. Object-Oriented Analysis
Lecture 5
Object-Oriented Analysis

2. Disclaimer and Copyright Notice
This work is subject to copyright. All rights are reserved.
This course material is developed in conjunction with the courseware of Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001.
The material provided is for reference only. It should not be redistributed with prior written consent. Proceeding beyond this notice implies willingness to comply with the terms.

3. Key OO Concepts classes and class hierarchies objects messages
instances
inheritance
abstraction and hiding
objects
attributes
methods
encapsulation
polymorphism
messages

4. Polymorphism Class columnchart extends chart { Graphics draw (…) {} }
Class chart {
Graphics draw (…) {} } .
charttype myChart;
myChart.draw();
Class piechart extends chart {
Graphics draw (…) {} }
Class barchart extends chart {
Graphics draw (…) {} }

5. SOURCE OF DOMAIN KNOWLEDGE
Domain Analysis
GOAL: to find or create, within the context of a specific application domain (i.e. current project), those classes that are broadly applicable, so that they may be reused.
SOURCE OF DOMAIN KNOWLEDGE
DOMAIN ANALYSIS
DOMAIN ANALYSIS MODEL
class taxonomies
reuse standards
functional models
domain languages
technical literature
existing applications
customer surveys
expert advice
current/future requirements

6. OOA- A Generic View define use cases extract candidate classes
establish basic class relationships
define a class hierarchy
identify attributes for each class
specify methods that service the attributes
indicate how classes/objects are related
build a behavioral model
iterate on the first five steps

7. Use Cases a scenario that describes a “thread of usage” for a system
actors represent roles people or devices play as the system functions
users can play a number of different roles for a given scenario

8. Developing a Use Case
What are the main tasks or functions that are performed by the actor?
What system information will the the actor acquire, produce or change?
Will the actor have to inform the system about changes in the external environment?
What information does the actor desire from the system?
Does the actor wish to be informed about unexpected changes?

9. Unified Modeling Language
User model view This view represents the system (product) from the user’s (called “actors” in UML) perspective.
Structural model view Data and functionality is viewed from inside the system. That is, static structure (classes, objects, and relationships) is modeled.
Behavioral model view This part of the analysis model represents the dynamic or behavioral aspects of the system.
Implementation model view The structural and behavioral aspects of the system are represented as they are to be built.
Environment model view The structural and behavioral aspects of the environment in which the system is to be implemented are represented.

10. Use-Case Diagram

12. Use Case Example Activate System
The homeowner observes the SafeHome control panel to determine if the system is ready for input. If the system is not ready, the homeowner must physically close windows/doors so that the ready indicator is present. [A not ready indicator implies that a sensor is open; i.e., that a door or window is open.]
The homeowner uses the keypad to key in a four-digit password. The password is compared with the valid password stored in the system. If the password is incorrect, the control panel will beep once and reset itself for additional input. If the password is correct, the control panel awaits further action.
The homeowner selects and keys in stay or away to activate the system. Stay activates only perimeter sensors (inside motion detecting sensors are deactivated). Away activates all sensors.
When activation occurs, a red alarm light can be observed by the homeowner.

13. CRC Modeling class name:
class type: (e.g., device, property, role, event, ...)
class characteristics: (e.g., tangible, atomic, concurrent, ...)
responsibilities:
collaborators:

14. Selecting Classes retained information needed services
multiple attributes
common attributes
common operations
essential requirements

15. Class Types and Characteristics
External entities, things, occurrences, events
Roles
Organisational units
Places
Structures
Devices
Properties
Interactions
Characteristics
Tangibility: real or abstract
Inclusiveness: atomic or aggregate
Sequentiality: concurrent or sequential
Persistence: transient, temporary or permanent
Integrity: corruptible or guarded

16. Guidelines for Allocating Responsibilities to Classes
System intelligence should be evenly distributed.
Each responsibility should be stated as generally as possible.
Information and the behavior that is related to it should reside within the same class.
Information about one thing should be localized with a single class, not distributed across multiple classes.
Responsibilities should be shared among related classes, when appropriate.

17. Reviewing the CRC Model
All participants in the review (of the CRC model) are given a subset of the CRC model index cards.
All use-case scenarios (and corresponding use-case diagrams) should be organized into categories.
The review leader reads the use-case deliberately. As the review leader comes to a named object, she passes the token to the person holding the corresponding class index card.
When the token is passed, the holder of the class card is asked to describe the responsibilities noted on the card. The group determines whether one (or more) of the responsibilities satisfies the use-case requirement.
If the responsibilities and collaborations noted on the index cards cannot accommodate the use-case, modifications are made to the cards.

18. CRC Example class name: Control Panel class type: Device
class characteristics: Tangible
responsibilities:
collaborators:
Determine-sensor-status: set sensor status to “not ready” if sensors are open
Sensor

19. Generalization-specialization
Class Diagrams
Generalization-specialization
Composite aggregates

20. Package Reference dependency composition SafeHome 6. control panel
keys
Display area
lite
keypad
PKs
LCD display
Graphics
Messages
subsystem
(package)
reference
composition
SafeHome
6. Control Panel
2. System
5. Audible alarm
3. Sensor event
4. Sensor

21. Relationships Between Objects
contains
system
control panel
sensor
sensor event
audible alarm
produces
polls
recognises
1:1
1:m
0:k
0:n

22. Object-Behavior Model
Evaluate all use-cases to fully understand the sequence of interaction within the system.
Identify events that drive the interaction sequence and understand how these events relate to specific objects.
Create an event trace for each use-case.
Build a state transition diagram for the system
Review the object-behavior model to verify accuracy and consistency.

23. Use Case Example Activate System
The homeowner observes the SafeHome control panel to determine if the system is ready for input. If the system is not ready, the homeowner must physically close windows/doors so that the ready indicator is present. [A not ready indicator implies that a sensor is open; i.e., that a door or window is open.]
The homeowner uses the keypad to key in a four-digit password. The password is compared with the valid password stored in the system. If the password is incorrect, the control panel will beep once and reset itself for additional input. If the password is correct, the control panel awaits further action.
The homeowner selects and keys in stay or away to activate the system. Stay activates only perimeter sensors (inside motion detecting sensors are deactivated). Away activates all sensors.
When activation occurs, a red alarm light can be observed by the homeowner.

24. State Transition control panel compare password = incorrect “reenter”
“at rest”
“comparing”
“selecting”
“reenter”
compare password = incorrect
password entered
compare password = correct
activation successful

25. Event Trace Homeowner Control Panel System system ready
enters password
ready for activation/deactivation
selects stay/away
ready for next action
initiates beep
beep sounded
activate/deactivate sensors
sensors activated/deactivated
red light on request
red light on
system ready
Homeowner
Control Panel
System

26. Ready for activation/deactivation
Event Flow Diagram
Selects stay/away
Enters password
Homeowner
Control Panel
System ready
Ready for next action
Ready for activation/deactivation
Beep sounded
Sensors activated/
deactivated
Red light on
Initiates beep
Activate/deactivate
sensors
Red light on request
System

27. Collaboration Diagram
[condition]
2.1: message2
1: message1
object1
object2
object3
return value 2
[condition]
2.2: message3
return value 1
object4

28. Sequence Diagram object1 object2 object3 object4 message 1 [condition]
return value 1
return value 2

29. Activity Diagram A B C F
Object
[state] D E

30. UML Summary Static Behaviour: Use Case/Use Case Diagram
Class-Responsibility-Collaborator Modelling
Class Diagram
Dynamic Behaviour:
State diagram
Event trace
Sequence diagram
Collaboration diagram
Activity diagram