Вы находитесь на странице: 1из 39

Slide 12.

Object-Oriented and
Classical Software
Engineering
Fifth Edition, WCB/McGraw-Hill, 2002

Stephen R. Schach
srs@vuse.vanderbilt.edu

© The McGraw-Hill Companies, 2002


CHAPTER 12 Slide 12.2

OBJECT-ORIENTED
ANALYSIS PHASE

© The McGraw-Hill Companies, 2002


Overview Slide 12.3

● 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

© The McGraw-Hill Companies, 2002


Object-Oriented Analysis Phase Slide 12.4

● Object-oriented paradigm
– Reaction to perceived shortcomings in structured
paradigm
– Problem of larger products
– Data and action treated as equal partners

© The McGraw-Hill Companies, 2002


Object-Oriented Paradigm Slide 12.5

● Object consists of
– Data (attributes, state variables, instance
variables, fields, data members), and
– Actions (methods, member functions)
● Objects are independent units
– Conceptual independence
– Physical independence

© The McGraw-Hill Companies, 2002


Object-Oriented Analysis (contd) Slide 12.6

● Semi-formal specification technique


● Multiplicity of different methods
– Booch
– OMT
– Objectory
– Shlaer-Mellor
– Coad-Yourdon
● All essentially equivalent
● Nowadays, we represent OOA using UML
(unified modeling language)

© The McGraw-Hill Companies, 2002


The Three Steps of OOA Slide 12.7

● 1. Use-case modeling
– Determine how the various results are computed by the
product (without regard to sequencing)
– Largely action oriented
● 2. Class modeling (“object modeling”)
– Determine the classes and their attributes
– Purely data-oriented
● 3. Dynamic modeling
– Determine the actions performed by or to each class
– Purely action-oriented

● Iterative process
© The McGraw-Hill Companies, 2002
Elevator Problem: OOA Slide 12.8

● 1. Use-Case Modeling
– Use case: Generic description of overall functionality

– Scenario: Instance of a use case


● Get comprehensive insight into behavior of
product © The McGraw-Hill Companies, 2002
Normal Scenario Slide 12.9

© The McGraw-Hill Companies, 2002


Exception Scenario Slide 12.10

© The McGraw-Hill Companies, 2002


Class Modeling Slide 12.11

● Extract classes and their attributes


● Represent them using an entity-relationship
diagram
● Deduce the classes from use cases and their
scenarios
● Often there are many scenarios
– Possible danger: too many candidate classes

© The McGraw-Hill Companies, 2002


Two Approaches to Class Modeling Slide 12.12

● Noun extraction
– Always works
● CRC classes
– Need to have domain expertise

© The McGraw-Hill Companies, 2002


Noun Extraction Slide 12.13

● Stage 1. Concise Problem Definition


– Define product in single sentence
» Buttons in elevators and on the floors control the motion of
n elevators in a building with m floors.

© The McGraw-Hill Companies, 2002


Noun Extraction (contd) Slide 12.14

● 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.

© The McGraw-Hill Companies, 2002


Noun Extraction (contd) Slide 12.15

● Stage 3. Formalize the Strategy


– Identify nouns in informal strategy. Use nouns as
candidate classes
● Nouns
– button, elevator, floor, movement, building, illumination,
illumination, door
– floor, building, door are outside problem boundary —
exclude
are abstract nouns —
– movement, illumination, illumination
exclude (may become attributes)
● Candidate classes: Elevator and Button
● Subclasses: Elevator Button and Floor Button

© The McGraw-Hill Companies, 2002


First Iteration of Class Diagram Slide 12.16

● Problem
– Buttons do not communicate directly with elevators
– We need an additional class: Elevator Controller
© The McGraw-Hill Companies, 2002
Second Iteration of Class Diagram Slide 12.17

● All relationships
are now 1-to-n
– Makes design and
implementation
easier

© The McGraw-Hill Companies, 2002


CRC Cards Slide 12.18

● 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

© The McGraw-Hill Companies, 2002


3. Dynamic Modeling Slide 12.19

● Produce UML state


diagram
● State, event, predicate
distributed over state
diagram
● UML “guards” are in
brackets

© The McGraw-Hill Companies, 2002


Testing during the OOA Phase Slide 12.20

● CRC cards are an excellent testing technique

© The McGraw-Hill Companies, 2002


CRC Cards Slide 12.21

● Consider responsibility
– 1. Turn on elevator button
● Totally unacceptable for object-oriented
paradigm
● Responsibility-driven design ignored
● Information hiding ignored
● Responsibility
1. Turn on elevator button
should be
1. Send message to Elevator Button to turn itself on

© The McGraw-Hill Companies, 2002


CRC Cards (contd) Slide 12.22

● A class has been overlooked


– 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

© The McGraw-Hill Companies, 2002


Second Iteration of CRC Card Slide 12.23

© The McGraw-Hill Companies, 2002


Third Iteration of Class Diagram Slide 12.24

© The McGraw-Hill Companies, 2002


Second Iteration of Normal Scenario Slide 12.25

© The McGraw-Hill Companies, 2002


Elevator Problem: OOA (contd) Slide 12.26

● 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

© The McGraw-Hill Companies, 2002


Why Is All This Iteration Needed? Slide 12.27

● Perhaps the method is not yet mature?


– Waterfall model (explicit feedback loops)
– Rapid prototyping model (aim: to reduce iteration)
– Incremental model, and
– 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

© The McGraw-Hill Companies, 2002


CASE tools for OOA phase Slide 12.28

● Diagrams play a major role


● Diagrams often change
– Need a diagramming tool
– Many tools go further
● All modern tools support UML
– Example
» Rose

© The McGraw-Hill Companies, 2002


Air Gourmet Case Study: OOA Slide 12.29

● Use-case model for making a reservation

© The McGraw-Hill Companies, 2002


Making a Reservation: Extended Scenario Slide 12.30

© The McGraw-Hill Companies, 2002


Air Gourmet Case Study: OOA Slide 12.31

● Use-case for returning and scanning a postcard

© The McGraw-Hill Companies, 2002


Postcards: Extended Scenario Slide 12.32

© The McGraw-Hill Companies, 2002


Air Gourmet Case Study: Class Modeling Slide 12.33

● 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.

© The McGraw-Hill Companies, 2002


Air Gourmet Case Study: Noun Extraction
(contd) Slide 12.34

● 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.

© The McGraw-Hill Companies, 2002


Air Gourmet Case Study: Noun Extraction
(contd) Slide 12.35

● 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
are abstract
– efficacy, program, percentage, boarding, quality
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
© The McGraw-Hill Companies, 2002
First Iteration of Class Diagram) Slide 12.36

● 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
© The McGraw-Hill Companies, 2002
Second Iteration of Class Diagram (contd) Slide 12.37

● Cause of our
problems
– Flightshould
have been a
candidate
class
● BUT, we all
have 20–20
hindsight

© The McGraw-Hill Companies, 2002


Air Gourmet Case Study: Dynamic Model Slide 12.38

● State diagram

© The McGraw-Hill Companies, 2002


Challenges of the OOOA Phase Slide 12.39

● Do not class the boundary into object-oriented


design
● Do not allocate methods to classes yet

© The McGraw-Hill Companies, 2002

Вам также может понравиться