Back to Subject
Practice MCQ

Unit 3 - Notes

CSE320

Unit 3: Object-Oriented Software Development and Modeling Techniques

1. The Unified Process (UP)

The Unified Process (UP) is an iterative and incremental software development process framework. It is use-case driven, architecture-centric, and iterative and incremental. The most famous refinement of the UP is the Rational Unified Process (RUP).

1.1 Core Philosophy: Iterative and Incremental

Unlike the Waterfall model, where one phase is completed entirely before the next begins, UP divides the project into smaller "mini-projects" called iterations.

  • Iterative: The process involves repeating a cycle of operations (analysis, design, coding, testing) to refine the system.
  • Incremental: Each iteration results in a release (an increment) that adds more functionality to the system.
  • Risk-Driven: The hardest and riskiest elements are addressed in early iterations to reduce project failure probability.

1.2 The Four Phases of the Unified Process

The life cycle of the Unified Process is divided into four distinct phases. Each phase concludes with a major Milestone.

A. Inception Phase

  • Goal: Establish the business case and scope of the project.
  • Key Activities:
    • Define the vision and scope.
    • Identify critical use cases (approx. 10-20% of primary scenarios).
    • Estimate costs and schedule (rough order of magnitude).
    • Assess risks.
  • Milestone: Lifecycle Objective (LCO). Do stakeholders agree on the scope and cost/benefit analysis?

B. Elaboration Phase

  • Goal: Establish the architectural baseline and address high-risk elements.
  • Key Activities:
    • Refine the majority of use cases (requirements detailing).
    • Design the system architecture (create an executable architectural prototype).
    • Address the highest technical risks.
  • Milestone: Lifecycle Architecture (LCA). Is the architecture stable? are major risks resolved?

C. Construction Phase

  • Goal: Complete the system development.
  • Key Activities:
    • Develop the remaining components and features.
    • Integrate and test components.
    • Produce user documentation.
    • Optimization and refactoring.
  • Milestone: Initial Operational Capability (IOC). Is the product ready for beta testing/deployment?

D. Transition Phase

  • Goal: Deliver the system to the end-users.
  • Key Activities:
    • Beta testing and User Acceptance Testing (UAT).
    • Data migration and conversion.
    • User training.
    • Final deployment and rollout.
  • Milestone: Product Release. Is the user satisfied and the project officially concluded?

1.3 Core Workflows (Disciplines)

UP defines specific workflows that occur across all four phases, though with varying intensity.

  1. Business Modeling: Understanding the organization's structure and dynamics.
  2. Requirements: Eliciting, documenting, and managing requirements (Use Cases).
  3. Analysis & Design: Translating requirements into system architecture and detailed design.
  4. Implementation: Coding and building the system.
  5. Test: Verifying that the system meets requirements.
  6. Deployment: Releasing the software to users.
  7. Configuration & Change Management: Managing versions and change requests.
  8. Project Management: Planning and scheduling.
  9. Environment: Managing tools and infrastructure.

2. UML Modeling

The Unified Modeling Language (UML) is the standard visual modeling language for specifying, visualizing, constructing, and documenting the artifacts of a software system.

2.1 Use Case Diagrams

Purpose: To capture functional requirements by showing the interaction between external entities (Actors) and the system (Use Cases).

  • Components:
    • Actor: Represents a role played by a user or an external system (stick figure).
    • Use Case: A specific functionality or unit of work (oval).
    • System Boundary: A box defining the scope of the system.
  • Relationships:
    • Association: Solid line connecting Actor and Use Case.
    • <>: Base Use Case always uses the included functionality (e.g., "Verify Password" included in "Login").
    • <>: Extended Use Case optionally adds behavior to the base case under specific conditions (e.g., "Display Error" extends "Login").
    • Generalization: Inheritance between actors or use cases.

2.2 Class Diagrams

Purpose: To illustrate the static structure of the system, showing classes, attributes, operations, and relationships. It is the backbone of object-oriented design.

  • Class Notation: A rectangle divided into three parts:
    1. Class Name.
    2. Attributes (Variables/State).
    3. Operations (Methods/Behavior).
  • Visibility Modifiers: + (Public), - (Private), # (Protected).
  • Relationships:
    • Association: A structural link (solid line).
    • Aggregation: "Has-a" relationship; weak ownership (Hollow diamond). If the container is destroyed, the contained object usually survives.
    • Composition: Strong ownership (Filled diamond). If the container is destroyed, the contained object is destroyed (e.g., House and Rooms).
    • Generalization (Inheritance): "Is-a" relationship (Hollow triangle arrow).
    • Dependency: "Uses" relationship (Dashed arrow). Changes in one class affect the other.

2.3 Sequence Diagrams

Purpose: To model the dynamic behavior of objects by showing how they interact over time. It is an Interaction Diagram.

  • Components:
    • Lifeline: Dashed vertical line representing the existence of an object over time.
    • Activation Bar: Thin rectangle on the lifeline indicating when the object is active/processing.
    • Messages: Arrows representing communication.
      • Solid Arrow: Synchronous call (caller waits).
      • Open Arrow: Asynchronous call (caller continues).
      • Dashed Arrow: Return message.
  • Usage: Used to detail the logic of a single Use Case scenario.

2.4 Activity Diagrams

Purpose: To model the workflow or logic flow of a system, similar to a flowchart but with support for concurrency.

  • Components:
    • Initial Node: Filled circle (Start).
    • Action State: Rounded rectangle (Activity/Task).
    • Control Flow: Arrow indicating sequence.
    • Decision Node: Diamond shape (Branching logic).
    • Fork/Join: Thick black bar.
      • Fork: Splits one flow into multiple concurrent flows.
      • Join: Synchronizes multiple concurrent flows back into one.
    • Swimlanes: Partitions the diagram to show which actor/department performs which activity.
    • Final Node: Bullseye circle (End).

3. The Object Modeling Process

The transition from requirements to an object-oriented design involves a systematic process of identifying and refining objects.

Step 1: Identification of Classes and Objects

  • Noun Extraction (Abbott’s Technique): Analyze the requirements text (Use Case descriptions).
    • Proper Nouns Specific Objects.
    • Common Nouns Classes.
    • Verbs Operations/Methods.
  • CRC Cards (Class-Responsibility-Collaborator): Index cards are created for potential classes. The team walks through scenarios to identify Responsibilities (what the class knows/does) and Collaborators (other classes it needs).

Step 2: Identification of Associations

  • Determine how classes relate.
  • Identify multiplicity (1:1, 1:Many, Many:Many).
  • Refine relationships into Aggregation or Composition where appropriate.

Step 3: Identification of Attributes

  • Identify the data required to support the class responsibilities.
  • Filter out attributes that belong to other classes or are derived.

Step 4: Identification of Operations

  • Assign methods based on the verbs in the requirements.
  • Use Sequence Diagrams to discover operations (if Object A sends a message to Object B, Object B must have an operation to handle that message).

4. Model Validation

Validation ensures that the models accurately reflect the requirements and are logically sound before coding begins.

4.1 Consistency Checking

Ensures that different diagrams in the model do not contradict one another.

  • Syntactic Consistency: Adherence to UML rules.
  • Semantic Consistency Examples:
    • If a message is sent to an object in a Sequence Diagram, the corresponding operation must exist in the Class Diagram.
    • An Actor in a Sequence Diagram must be defined in the Use Case Diagram.
    • State transitions in a State Diagram must be triggered by operations defined in the Class Diagram.

4.2 Completeness Checking

Ensures that all requirements are represented in the design.

  • Are all Use Cases detailed in Sequence or Activity diagrams?
  • Are all exceptions and error flows (alternate paths) modeled?
  • Are all classes required to support the Use Cases defined?

4.3 Traceability

The ability to link design artifacts back to requirements and forward to code.

  • Requirements Traceability Matrix (RTM): A table mapping Requirements IDs to Use Cases, then to Classes, and finally to Test Cases.
  • Forward Traceability: Requirement Design Code. Used to check that everything requested is built.
  • Backward Traceability: Code Design Requirement. Used to prevent "gold-plating" (building features that were not requested) and to analyze the impact of changes.

5. Coding Standards and Code Review Techniques

Quality assurance in the Implementation workflow relies heavily on standardization and peer review.

5.1 Coding Standards

A set of guidelines that programmers must follow to write code.

  • Purpose:
    • Maintainability: Uniform code looks like it was written by one person, making it easier to read and modify.
    • Error Reduction: Prevents common pitfalls (e.g., resource leaks).
  • Key Areas:
    • Naming Conventions: (e.g., CamelCase for variables, PascalCase for classes).
    • Formatting: Indentation, spacing, bracket placement.
    • Comments/Documentation: Javadoc/Doxygen standards for API documentation.
    • Best Practices: Limits on function length, cyclomatic complexity limits, variable scope rules.

5.2 Code Review Techniques

The systematic examination of source code.

A. Code Walkthrough

  • Type: Informal.
  • Process: The author leads a team through the code or design.
  • Goal: Educational (knowledge sharing) and basic error detection. The author explains the logic, and peers ask questions.

B. Code Inspection (Fagan Inspection)

  • Type: Formal and rigid.
  • Roles: Moderator, Author, Reader, Recorder, Inspector.
  • Process:
    1. Planning: Overview of the code.
    2. Preparation: Reviewers study code individually.
    3. Meeting: The Reader paraphrases the code; the team finds defects (no fixing allowed during the meeting).
  • Goal: To find defects based on a checklist (e.g., uninitialized variables, boundary errors).

C. Pair Programming

  • Type: Continuous, Real-time.
  • Context: Extreme Programming (XP) / Agile.
  • Process: Two developers work at one workstation.
    • The Driver: Writes the code.
    • The Navigator: Reviews each line as it is typed, thinks strategically, and checks for errors.
  • Goal: Immediate feedback, higher quality code, and collective code ownership.

D. Static Analysis (Automated Review)

  • Using software tools (Lint, SonarQube) to automatically scan code for syntax errors, security vulnerabilities, and adherence to coding standards without executing the program.