Chapter 11 Object-Oriented Analysis Phase

11.1 Object-Oriented versus Structured Paradigm

Structured Paradigm:

  • Data-oriented technique: Jackson system development (the structure of actions conforms to the structure of the data), entity relationship modeling (ERM)
  • Action-oriented technique: Finite State Machine, Structured system analysis , Data Flow Diagram (data is secondary to the action)

Object-Oriented Paradigm: an action comprises both data and actions (equal weight to data and actions)

  • The data: attributes, state variables, instance variables, fields, data members
  • The actions: methods, member functions

Why the object-oriented paradigm is superior to the structured paradigm?

  • A well-designed object (with low coupling and high cohesion, model all aspects of one physical entity)
  • The details of implementation are hidden (communication with an object is through message sent to that object)  independent unit with a well defined interface
  • Easily and safely maintainable (reduced a regression fault)
  • Reusability (independence and inheritance)
  • Safer to construct a large-scale product

Questions to think about…

  • If the structured paradigm is so inferior to the object-oriented paradigm, why has the structure paradigm had so many successes?
  • How do we know for certain that the object-oriented paradigm is superior to all other present-date techniques?
  • Is it possible that someday there will be something better than the object-oriented paradigm?

11.2 Object-Oriented Analysis

  • Semiformal specification technique
  • Over 50 different OOA techniques
  • UML (Unified Modeling Language): combination of

(1994)

  • Object Modeling Technique (OMT) [Rumbaugh, et al., 1991] at GE
  • Booch at Rational, inc

(1995)

  • Ivar Jacobson: Object-Oriented Software Engineering (OOSE) based on Use cases

UML 1.0 (1997)

  1. Use Case Modeling

Use case diagram, scenarios, functional modeling

  1. Class Modeling: determine classes, their attributes, and the interrelationships between the classes (entity-relationship diagram, class diagram)
  2. Dynamic Modeling: determine the actions performed by or to each class or subclass (finite state machine, state diagram)

Three steps are effectively performed in parallel. The OOA is a modeling technique

  • To make use of diagrams for specifying the results of the tree modeling steps.
  • To specify the target product to be built
  • To understand data, action, and the interplay between data and actions (using the variety of modeling techniques)
  • By the end of the OOA phase, to combine the views (different aspect of the target product) from different techniques to obtain an overall understanding of the product.

11.3 Elevator Problem: Object-Oriented Analysis

 Group 2: Experiment

11.4 Use-Case Modeling

  • Use case: a generic description of the overall functionality of the product (the overall interaction between the classes and the actors of the products)
  • Scenario: specific instantiations of the use case (one particular set of interaction between specific objects and users)

Figure 11.1 & 11.2 & 11.3

11.5 Class Modeling

  • The classes and their attributes are extracted and represented using entity relationship diagram. (vs. methods are assigned to the class during OOD phase)
  • Deduction of classes from the use cases: identify the items that plays a role in the use cases

11.5.1 Noun Extraction

The developers without domain expertise

  • Stage 1: Concise Problem Definition
  • Stage 2: Informal strategy
  • Stage 3: Formalize the strategy

Figures 11.4 & 11.5

11.5.2 CRC Cards

Class Responsibility Collaboration (CRC) card [Wirfs-Brock, Wilkerson, Wiener, 1990]: fill in a card showing

  • the name of the class,
  • the functionality of that class (responsibility),
  • a list of the other classes invokes in order to achieve the functionality (collaboration)

Strength:

  • The interaction between the members can highlight missing or incorrect items in a class
  • Distribution of the cards among the team members, who act out the responsibilities of their classes, can be an effective means of verifying that the class diagram is complete and correct.

Weakness:

  • Requires considerable domain knowledge and experience in the relevant domain.

11.6 Dynamic Modeling

  • To produce a state diagram, a description of the target product similar to a finite state model, for each class.
  • Differences between DM and FSM:
  • Semi-formal (graphical) techniques
  • State, event, and predicate are distributed over the UML diagram.

Figure 11.6 & 11.7

11.7 Testing during the Object-Oriented Analysis Phase

  • Two major problems (figure 11.6 & 11.7):
  • Turn on elevator button  send a message to elevator button to turn on button (OO)
  • State (door open)  model as a class (Elevator doors) and it possesses a state (open or closed)
  • Modification of the class diagram (Figure 11.8)  re-exam Use-case diagram, the set of state diagram, CRC card (Figure 11.9)
  • OO Analysis  OO Design

11.8 CASE Tools for the Object-Oriented Analysis Phase

CASE Tools:

  • Draw all the relevant diagrams and CRC cards
  • easy to perform each of modeling steps
  • simpler to modify a diagram
  • supports the graphical aspects of OOA (OMT [Rumbaugh, 1991], Booch [Booch, 1994], UML [1997]).
  • A change to the underlying model is automatically reflected in all the different diagrams.
  • E.g.: Rose and Software through Pictures.

11.9 Osbert Oglesby Case Study: Object-Oriented Analysis

 Reference for Project 4

11.10 Osbert Oglesby Case Study: Software Project Management Plan (Appendix F)

 Reference for Project 4