Download presentation
1
OBJECT-ORIENTED ANALYSIS PHASE
CHAPTER 12 OBJECT-ORIENTED ANALYSIS PHASE
2
Overview Object-oriented analysis Use-case modeling Class modeling
Dynamic modeling Testing during the object-oriented analysis phase CASE tools for the object-oriented analysis phase Air Gourmet case study: Object-oriented analysis Challenges of the object-oriented analysis phase
3
Object-Oriented Analysis Phase
Object-oriented paradigm Reaction to perceived shortcomings in structured paradigm Problem of larger products Data and action treated as equal partners
4
Object-Oriented Paradigm
Object consists of Data Actions Objects are independent units Conceptual independence Physical independence
5
Object-Oriented Analysis (OOA)
Semi-formal specification technique Many methods exist Booch OMT Objectory Shlaer-Mellor Coad-Yourdon All essentially equivalent Most of OOA is done these days using UML (Unified Modeling Language) Just In Case You Wanted to Know on pg. 367
6
The Three Steps of OOA 1. Use-case modeling
Determine how the various results are computed by the product (without regard to sequencing) Also referred to as functional modeling Generate use-case diagram and associated scenarios action oriented 2. Class modeling (“object modeling”) Determine the classes and their attributes Determine the interrelationships and interactions among the classes Generate class diagram - similar to ER diagram data oriented 3. Dynamic modeling Determine the actions performed by or to each class or subclass Generate state diagram action-oriented Iterative process
7
Elevator Problem: OOA 1. Use-Case Modeling
Use case: Generic description of overall functionality Scenario: Instance of a use case
8
Normal Scenario
9
Exception Scenario
10
More on Scenarios Sufficient scenarios should be generated to give the OOA team a comprehensive insight in the behavior of the system to be modeled Scenarios are used in the class modeling step to determine the classes (objects) Scenarios are also used in the OO design
11
2. Class Modeling Extract classes and their attributes
Represent them using an entity-relationship diagram (ERD) Deduce the classes from use cases and their scenarios Only the attributes of a class are determined (the methods are determined in the OO design) Often there are many scenarios Possible danger: too many candidate classes
12
Two Approaches to Class Modeling
Noun Extraction Three-stage process to extract candidate classes Always works CRC cards Class-responsibility-collaboration (CRD) cards Need to have domain expertise
13
Stage 1. Concise Problem Definition
Noun Extraction Stage 1. Concise Problem Definition Define the product as briefly and concisely as possible, preferably in a single sentence Elevator problem example Buttons in elevators and on the floors control the motion of n elevators in a building with m floors.
14
Noun Extraction (contd)
Stage 2. Informal Strategy Incorporate constraints, express result in a single paragraph Buttons in elevators and on the floors control movement of n elevators in a building with m floors. Buttons illuminate when pressed to request the elevator to stop at a specific floor; illumination is canceled when the request has been satisfied. When an elevator has no requests, it remains at its current floor with its doors closed.
15
Noun Extraction (contd)
Stage 3. Formalize the Strategy Identify nouns in informal strategy (excluding those that lie outside of the problem boundary). Use nouns as candidate classes Nouns button, elevator, floor, movement, building, illumination, illumination, door floor, building, door are outside problem boundary — exclude movement, illumination, illumination are abstract nouns — exclude (may become attributes) Candidate classes: Elevator and Button Subclasses: Elevator Button and Floor Button
16
First Iteration of Class Diagram
Problem Buttons do not communicate directly with elevators We need an additional class: Elevator Controller
17
Second Iteration of Class Diagram
All relationships are now 1-to-many Makes design and implementation easier
18
CRC Cards Used since 1989 for OOA For each class, fill in card showing
Name of Class Functionality (Responsibility) List of classes it invokes (Collaboration) Now automated (CASE tool component) Strength When acted out by team members, powerful tool for highlighting missing or incorrect items Weakness Domain expertise is needed
19
3. Dynamic Modeling Produce UML state diagram
State, event, predicate distributed over state diagram UML “guards” are in brackets
20
Testing during the OOA Phase
CRC cards are an excellent testing technique
21
CRC Cards Consider responsibility
1. Turn on elevator button Totally unacceptable for object-oriented paradigm Responsibility-driven design ignored Information hiding ignored Responsibility should be 1. Send message to Elevator Button to turn itself on
22
CRC Cards (contd) A class has been overlooked Reconsider class model
Elevator doors have a state that changes during execution (class characteristic) Add class Elevator Doors Safety considerations Reconsider class model Then reconsider dynamic model, use-case model
23
Second Iteration of CRC Card
24
Third Iteration of Class Diagram
25
Second Iteration of Normal Scenario
26
Elevator Problem: OOA (contd)
All three models are now fine We should rather say: All three models are fine for now We may need to return to the object-oriented analysis phase during the object-oriented design phase
27
Why Is All This Iteration Needed?
Perhaps the method is not yet mature? Waterfall model (explicit feedback loops) Rapid prototyping model (aim: to reduce iteration) Incremental model Spiral model Latter two explicitly reflect iterative approach Iteration is an intrinsic property of all software production Especially for medium- and large-scale products Expect iteration in the object-oriented paradigm
28
CASE tools for OOA phase
Diagrams play a major role Diagrams often change Need a diagramming tool Many tools go further All modern tools support UML Example Rational Rose Smart Draw
29
Air Gourmet Case Study: OOA
Use-case model for making a reservation
30
Making a Reservation: Extended Scenario
31
Air Gourmet Case Study: OOA
Use-case for returning and scanning a postcard
32
Postcards: Extended Scenario
33
Air Gourmet Case Study: Class Modeling
Stage 1. Concise Problem Definition Define product in single sentence A computerized system is needed to provide information regarding the efficacy of a special meals program.
34
Air Gourmet Case Study: Noun Extraction (contd)
Stage 2. Informal Strategy Incorporate constraints, express result in a single paragraph Reports are to be generated to document the efficacy of the special meals program. The reports concern meals loaded on flights, flights boarded by passengers, names and addresses of passengers, meal quality, and low-sodium meals.
35
Air Gourmet Case Study: Noun Extraction (contd)
Stage 3. Formalize the Strategy Identify nouns in informal strategy. Use nouns as candidate classes Nouns report, efficacy, program, percentage, meal, flight, boarding, passenger, name, address, quality efficacy, program, percentage, boarding, quality are abstract nouns — exclude (may become attributes) name, address are attributes of passenger Question: Should meal and flight be classes? It is easier to add classes than to remove them Candidate classes: Report and Passenger
36
First Iteration of Class Diagram
Problems with this class diagram Data for reports are needed on a per-flight basis Each report has to access multiple flights Each flight has multiple passengers Six reports (not four) are needed
37
Second Iteration of Class Diagram
Cause of our problem Flight should have been a candidate class
38
Air Gourmet Case Study: Dynamic Model
State diagram
39
Challenges of the OOA Phase
Do not cross the boundary into object-oriented design Do not allocate methods to classes yet
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.