Subtopic 1: Introduction
Minitopic: Learning Objectives
(Overview of key concepts and skills to be acquired after studying this chapter)
- Goal: To be able to concisely define, describe, state, compare, model, provide snapshots, recognize usage scenarios, and specify business rules related to object-oriented concepts.
- Key Terms/Concepts to Master:
- Core Concepts: Class, Object, State, Behavior, Encapsulation, Operation
- Operations: Constructor, Query, Update, Class-Scope Operation, Abstract Operation, Method
- Relationships: Association, Association Role, Multiplicity, Association Class, Aggregation, Composition, Generalization
- Class Variations: Abstract Class, Concrete Class
- Attributes: Class-Scope Attribute
- Advanced Concepts: Polymorphism, Overriding, Multiple Classification
- Diagrams: Class Diagram, Object Diagram
- Process: Object-Oriented Development Life Cycle
- Modeling Tools: Unified Modeling Language (UML)
- Rules: Business Rules in a Class Diagram
Minitopic: Comparison with E-R/EER Models
- Foundation: Builds upon concepts from E-R (Entity-Relationship) and EER (Enhanced Entity-Relationship) models learned in Chapters 2 & 3 (Entities, Attributes, Relationships).
- Popularity: Object-Oriented (OO) model is increasingly popular.
- Expressive Power: OO model has more expressive power than the EER model.
- Key Difference - Behavior:
- E-R/EER models focus primarily on data (entities, attributes, relationships).
- OO model is built around Objects.
- An Object encapsulates both data (state) and behavior (operations/methods).
- This allows the OO approach to model not just data structure, but also system behavior and processes acting on that data within a single, integrated notation.
- Complexity Handling: OO is particularly effective for representing complex relationships and capturing both essential data features and system behavior.
- Abstraction: Like E-R/EER, OO models are an abstraction of the real world, focusing on essential features relevant to the organization’s needs.
Minitopic: Object-Oriented Systems Development Life Cycle (OOSDLC)
-
Reference: Figure 13-1 illustrates the phases.
-
Core Idea: Progressively and iteratively developing an object representation.
-
Phases: Consists of three main, iterative phases:
- Analysis
- Design
- Implementation (Similar structure to the general Systems Development Life Cycle from Chapter 1)
-
Iterative Development Model:
- Focus shifts from more abstract aspects (Analysis) to more concrete aspects (Design, Implementation) over the project lifetime.
- Early stages: Model is abstract, focuses on external qualities.
- Later stages: Model becomes detailed, focuses on how the system will be built and function.
- Emphasis should be on front-end conceptual issues (Analysis, Design) rather than premature back-end implementation details.
-
Phase Details:
- 1. Analysis Phase:
- Goal: Develop a model of the real-world application domain.
- Focus: Capturing important properties, abstracting concepts from the domain. Describes what the system must do, not how. Specifies functional behavior independent of the implementation environment.
- Key Activity: Clearly understanding problem requirements.
- Important Note: The focus during analysis is on the real-world domain of interest, not the internal characteristics of the software system itself. Iteratively revisited based on lessons from design/implementation.
- 2. Design Phase:
- Goal: Define how the application-oriented analysis model will be realized in the specific implementation environment.
- Focus: Modeling the software system, heavily informed by the analysis models. Adapting the model considering factors like:
- Performance requirements
- Real-time requirements & concurrency
- Target hardware and systems software
- Chosen DBMS and programming language
- Key Activities:
- Making strategic decisions (DBMS integration, process communication, error handling, library reuse).
- Refining objects: deciding on operations, communication methods, message passing.
- Formalizing object interactions for scenarios.
- Validating analysis results and making necessary changes for the next iteration.
- Reasons for OO Design (Jacobson et al., 1992):
- Analysis model isn’t formal enough for direct implementation.
- System needs adaptation to the implementation environment.
- Analysis results can be validated through design refinement.
- 3. Implementation Phase:
- Goal: Translate the design model into actual code and database structures.
- Process: Follows design activities within each iteration. Relatively straightforward if the design is well-done and incorporates implementation nuances (language, DBMS).
- 1. Analysis Phase:
-
Key Distinction: Seamless Transitions
- Unlike traditional structured approaches (e.g., Data Flow Diagrams in analysis vs. Structure Charts in design) which often have abrupt and disjoint transitions between models lacking a common underlying structure.
- The OO approach provides a continuum of representation.
- The OO analysis model typically serves directly as the foundation for the OO design model, leading to a smoother, more integrated development process.
Minitopic: Motivations and Benefits of Object-Oriented Modeling
(Based on Coad and Yourdon, 1991 and general text)
- Enhanced Modeling Capability:
- Ability to tackle more challenging problem domains.
- Explicit representation of commonality among system components (via inheritance).
- Improved Development Process:
- Improved communication between users, analysts, designers, and programmers (using a common representation).
- Increased consistency among analysis, design, and programming activities.
- Increased consistency among all models developed during analysis, design, and programming (due to seamless transitions).
- Better System Qualities:
- Robustness of systems.
- Efficiency and Productivity:
- Reusability of analysis, design, and programming results (e.g., through inheritance and class libraries).
- Potential for significant productivity gains.