CSC 330 Object Oriented Software Design Software Analysis Phase 1
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 2
Object-Oriented Oriented Analysis (OOA) Phase Object-oriented paradigm Reaction to perceived shortcomings in structured paradigm Problem of larger products Data and action treated as equal partners 3
Object-Oriented Oriented Paradigm 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 4
Object-Oriented Oriented Analysis cont d 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) 5
The Three Steps of OOA 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 6
Elevator Problem: OOA 1. Use-Case Modeling Use case: Generic description of overall functionality Scenario: Instance of a use case 2. Get comprehensive insight into behavior of product 7
Normal Scenario 8
Exception Scenario 9
Class Modeling Extract classes and their attributes Represent them using an entityrelationship diagram Deduce the classes from use cases and their scenarios Often there are many scenarios Possible danger: too many candidate classes 10
First Iteration of Class Diagram Problem Buttons do not communicate directly with elevators We need an additional class: Elevator Controller 11
Second Iteration of Class Diagram All relationships are now 1-to-n Makes design and implementation easier 12
Class-Responsibility Responsibility-Collaboration (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 13
Dynamic Modeling Produce UML state diagram State, event, predicate distributed over state diagram UML guards are in brackets 14
Testing during the OOA Phase CRC cards are an excellent testing technique 15
CRC Cards 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 16
CRC Cards cont d 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, usecase model 17
Second Iteration of CRC Card 18
Third Iteration of Class Diagram 19
Second Iteration of Normal Scenario 20
Elevator Problem: OOA cont d All three models are now fine We should rather say: All three models are fine for now We may need to return to the objectoriented analysis phase during the object-oriented design phase 21
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, 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 22
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 Rose 23
Example 24
Air Gourmet Case Study: OOA Use-case model for making a reservation 25
Making a Reservation: Extended Scenario 26
Air Gourmet Case Study: OOA Use-case for returning and scanning a postcard 27
Postcards: Extended Scenario 28
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. 29
Air Gourmet Case Study cont d 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 lowsodium meals. 30
Air Gourmet Case Study cont d 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 31
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 32
Second Iteration of Class Diagram cont d Cause of our problems Flight should have been a candidate class 33
Air Gourmet Case Study: Dynamic Model State diagram 34