Comparison of Booch, Jacobson, and Rumbaugh Approaches to Object-Oriented Design - Prof. K, Study notes of Computer Science

Download Comparison of Booch, Jacobson, and Rumbaugh Approaches to Object-Oriented Design - Prof. K and more Study notes Computer Science in PDF only on Docsity!

Lecture 16: Object-Oriented Design Methods

Kenneth M. Anderson University of Colorado, Boulder CSCI 4448/6448 — Lecture 16 — 10/18/ © University of Colorado, 2007

Goals for this Lecture

• Review various OO design methods (software development life cycles)
• Briefly review two additional UML diagrams
  • Activity Diagrams
  • State Diagrams

Life Cycle Characteristics

• Life cycles make software development
  • predictable
  • repeatable
  • measurable
  • efficient
• High-quality processes should lead to high-quality products
  • at least it improves the odds of producing good software

Survey of OOA&D Methods

• Generalization
  • Taken from “SE: A Practitioner’s approach, 4th ed.” by Roger S. Pressman, McGraw-Hill, 1997
• The Booch Method
• The Jacobson Method
• The Rambaugh Method
• The Unified Software Process

Detailed comparisons

• What follows is a barebones description of each method, detailed comparisons can be found in: - Graham, I. Object-Oriented Methods, Addison-Wesley, Third Edition, 2001

Background on OO Methods

• An OO Method should cover and include
  • requirements and business process modeling
  • a lightweight, customizable process framework
  • project management
  • component architecture
  • system specification
    • use cases, UML, architecture, etc.
  • component design and decomposition
  • testing throughout the life cycle
  • Software quality assurance
  • Configuration management

Booch, continued

- Identify relationships among classes and objects - Define dependencies that exist between objects - Describe the role of each participating object - Validate by walking through scenarios - Conduct a series of refinements - Produce appropriate diagrams for the work conducted above - Define class hierarchies as appropriate - Perform clustering based on class commonality - Implement classes and objects - In analysis and design, this means specify everything!

The Jacobson Method

• Object-Oriented Software Engineering
  • Primarily distinguished by the use-case
  • Simplified model of Objectory
    • Objectory evolved into the Rational Unified Software Development Process
  • For more information on this Objectory precursor, see
    • Jacobson, I., Object-Oriented Software Engineering, Addison-Wesley,

Jacobson, continued

- Build analysis model - Identify interface objects using actor-interaction information - Create structural views of interface objects - Represent object behavior - Isolate subsystems and models for each - Review the model using use cases as scenarios to determine validity

The Rumbaugh Method

• Object Modeling Technique (OMT)
  • Rumbaugh, J. et al., Object-Oriented Modeling and Design, Prentice-Hall, 1991
• Analysis activity creates three models
  • Object model
    • Objects, classes, hierarchies, and relationships
  • Dynamic model
    • object and system behavior
  • Functional model
    • High-level Data-Flow Diagram

Rumbaugh, continued

- Construct a functional model for the system - Identify inputs and outputs - Use data flow diagrams to represent flow transformations - Develop a processing specification for each process in the DFD - Specify constraints and optimization criteria

• Iterate

Rational Unified Process: Overview

PHASES PRODUCT CYCLES CORE WORKFLOWS CYCLE 1 CYCLE 2 CYCLE 3... CYCLE N INCEPTION ELABORATION CONSTRUCTION TRANSITION iteration 1 iteration 2 iteration 3 iteration 4 iteration 5 iteration 6

... iteration n - 1 iteration n Requirements Analysis Design Implementation Test ITERATIONS

Elaboration

• Develop requirements and initial design
• Develop Plan for Construction phase
• Risk-driven approach
  • Requirements Risks
  • Technological Risks
  • Skills Risks
  • Political Risks

Requirements Risks

• Is the project technically feasible?
• Is the budget sufficient?
• Is the timeline sufficient?
• Has the user really specified the desired system?
• Do the developers understand the domain well enough?