Download presentation
Presentation is loading. Please wait.
Published byDylan Forth Modified over 10 years ago
1
Slide 12.1 © The McGraw-Hill Companies, 2002 Object-Oriented and Classical Software Engineering Fifth Edition, WCB/McGraw-Hill, 2002 Stephen R. Schach srs@vuse.vanderbilt.edu
2
Slide 12.2 © The McGraw-Hill Companies, 2002 CHAPTER 12 OBJECT-ORIENTED ANALYSIS PHASE
3
Slide 12.3 © The McGraw-Hill Companies, 2002 Overview l Object-oriented analysis l Use-case modeling l Class modeling l Dynamic modeling l Testing during the object-oriented analysis phase l CASE tools for the object-oriented analysis phase l Air Gourmet case study: Object-oriented analysis l Challenges of the object-oriented analysis phase
4
Slide 12.4 © The McGraw-Hill Companies, 2002 Object-Oriented Analysis Phase l Object-oriented paradigm –Reaction to perceived shortcomings in structured paradigm –Problem of larger products –Data and action treated as equal partners
5
Slide 12.5 © The McGraw-Hill Companies, 2002 Object-Oriented Paradigm l Object consists of –Data (attributes, state variables, instance variables, fields, data members), and –Actions (methods, member functions) l Objects are independent units –Conceptual independence –Physical independence
6
Slide 12.6 © The McGraw-Hill Companies, 2002 Object-Oriented Analysis (contd) l Semi-formal specification technique l Multiplicity of different methods –Booch –OMT –Objectory –Shlaer-Mellor –Coad-Yourdon l All essentially equivalent l Nowadays, we represent OOA using UML (unified modeling language)
7
Slide 12.7 © The McGraw-Hill Companies, 2002 The Three Steps of OOA l 1.Use-case modeling –Determine how the various results are computed by the product (without regard to sequencing) –Largely action oriented l 2.Class modeling (object modeling) –Determine the classes and their attributes –Purely data-oriented l 3.Dynamic modeling –Determine the actions performed by or to each class –Purely action-oriented l Iterative process
8
Slide 12.8 © The McGraw-Hill Companies, 2002 Elevator Problem: OOA l 1. Use-Case Modeling –Use case: Generic description of overall functionality –Scenario: Instance of a use case l Get comprehensive insight into behavior of product
9
Slide 12.9 © The McGraw-Hill Companies, 2002 Normal Scenario
10
Slide 12.10 © The McGraw-Hill Companies, 2002 Exception Scenario
11
Slide 12.11 © The McGraw-Hill Companies, 2002 Class Modeling l Extract classes and their attributes l Represent them using an entity-relationship diagram l Deduce the classes from use cases and their scenarios l Often there are many scenarios –Possible danger: too many candidate classes
12
Slide 12.12 © The McGraw-Hill Companies, 2002 Two Approaches to Class Modeling l Noun extraction –Always works l CRC classes –Need to have domain expertise
13
Slide 12.13 © The McGraw-Hill Companies, 2002 Noun Extraction l 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.
14
Slide 12.14 © The McGraw-Hill Companies, 2002 Noun Extraction (contd) l 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
Slide 12.15 © The McGraw-Hill Companies, 2002 Noun Extraction (contd) l Stage 3. Formalize the Strategy –Identify nouns in informal strategy. Use nouns as candidate classes l 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) l Candidate classes: Elevator and Button l Subclasses: Elevator Button and Floor Button
16
Slide 12.16 © The McGraw-Hill Companies, 2002 First Iteration of Class Diagram l Problem –Buttons do not communicate directly with elevators –We need an additional class: Elevator Controller
17
Slide 12.17 © The McGraw-Hill Companies, 2002 Second Iteration of Class Diagram l All relationships are now 1-to-n –Makes design and implementation easier
18
Slide 12.18 © The McGraw-Hill Companies, 2002 CRC Cards l Used since 1989 for OOA l For each class, fill in card showing –Name of class –Functionality (responsibility) –List of classes it invokes (collaboration) –Now automated (CASE tool component) l Strength –When acted out by team members, powerful tool for highlighting missing or incorrect items l Weakness –Domain expertise is needed
19
Slide 12.19 © The McGraw-Hill Companies, 2002 3. Dynamic Modeling l Produce UML state diagram l State, event, predicate distributed over state diagram l UML guards are in brackets
20
Slide 12.20 © The McGraw-Hill Companies, 2002 Testing during the OOA Phase l CRC cards are an excellent testing technique
21
Slide 12.21 © The McGraw-Hill Companies, 2002 CRC Cards l Consider responsibility –1.Turn on elevator button l Totally unacceptable for object-oriented paradigm l Responsibility-driven design ignored l Information hiding ignored l Responsibility 1.Turn on elevator button should be 1.Send message to Elevator Button to turn itself on
22
Slide 12.22 © The McGraw-Hill Companies, 2002 CRC Cards (contd) l A class has been overlooked –Elevator doors have a state that changes during execution (class characteristic) –Add class Elevator Doors –Safety considerations l Reconsider class model l Then reconsider dynamic model, use-case model
23
Slide 12.23 © The McGraw-Hill Companies, 2002 Second Iteration of CRC Card
24
Slide 12.24 © The McGraw-Hill Companies, 2002 Third Iteration of Class Diagram
25
Slide 12.25 © The McGraw-Hill Companies, 2002 Second Iteration of Normal Scenario
26
Slide 12.26 © The McGraw-Hill Companies, 2002 Elevator Problem: OOA (contd) l All three models are now fine l We should rather say: –All three models are fine for now l We may need to return to the object- oriented analysis phase during the object- oriented design phase
27
Slide 12.27 © The McGraw-Hill Companies, 2002 Why Is All This Iteration Needed? l Perhaps the method is not yet mature? –Waterfall model (explicit feedback loops) –Rapid prototyping model (aim: to reduce iteration) –Incremental model, and –Spiral model l Latter two explicitly reflect iterative approach l Iteration is an intrinsic property of all software production –Especially for medium- and large-scale products –Expect iteration in the object-oriented paradigm
28
Slide 12.28 © The McGraw-Hill Companies, 2002 CASE tools for OOA phase l Diagrams play a major role l Diagrams often change –Need a diagramming tool –Many tools go further l All modern tools support UML –Example »Rose
29
Slide 12.29 © The McGraw-Hill Companies, 2002 Air Gourmet Case Study: OOA l Use-case model for making a reservation
30
Slide 12.30 © The McGraw-Hill Companies, 2002 Making a Reservation: Extended Scenario
31
Slide 12.31 © The McGraw-Hill Companies, 2002 Air Gourmet Case Study: OOA l Use-case for returning and scanning a postcard
32
Slide 12.32 © The McGraw-Hill Companies, 2002 Postcards: Extended Scenario
33
Slide 12.33 © The McGraw-Hill Companies, 2002 Air Gourmet Case Study: Class Modeling l 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
Slide 12.34 © The McGraw-Hill Companies, 2002 Air Gourmet Case Study: Noun Extraction (contd) l 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
Slide 12.35 © The McGraw-Hill Companies, 2002 Air Gourmet Case Study: Noun Extraction (contd) l Stage 3. Formalize the Strategy –Identify nouns in informal strategy. Use nouns as candidate classes l 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? l It is easier to add classes than to remove them l Candidate classes: Report and Passenger
36
Slide 12.36 © The McGraw-Hill Companies, 2002 First Iteration of Class Diagram) l 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
Slide 12.37 © The McGraw-Hill Companies, 2002 Second Iteration of Class Diagram (contd) l Cause of our problems –Flight should have been a candidate class l BUT, we all have 20–20 hindsight
38
Slide 12.38 © The McGraw-Hill Companies, 2002 Air Gourmet Case Study: Dynamic Model l State diagram
39
Slide 12.39 © The McGraw-Hill Companies, 2002 Challenges of the OOOA Phase l Do not class the boundary into object-oriented design l Do not allocate methods to classes yet
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.