Week-15 Overview

Final Project Progress Review & Course Summary

Purpose of This Week

• Consolidate all knowledge gained throughout the semester
• Clarify final project expectations and evaluation criteria
• Provide demonstration guidelines for project presentations
• Prepare students for the final exam
• Answer remaining questions and address concerns

Module A: Course Review -- OOP Fundamentals

Weeks 1-7 Recap

Module A Outline

Course Review -- OOP Fundamentals (Weeks 1-7)

1. Weeks 1-3: Core OOP Concepts
2. Week 4: UML Diagrams
3. Week 5: PlantUML
4. Weeks 6-7: UMPLE
5. Key Takeaways from Each Topic

Weeks 1-3: Core OOP Concepts

The Four Pillars of Object-Oriented Programming

Weeks 1-3: Encapsulation Review

• What: Restricting direct access to an object's internal state and requiring interaction through well-defined methods.
• Why: Protects data integrity, reduces coupling, enables implementation changes without affecting clients.

public class BankAccount {
    private double balance; // hidden internal state

    public double getBalance() {
        return balance;
    }

    public void deposit(double amount) {
        if (amount > 0) {
            balance += amount;
        }
    }

    public boolean withdraw(double amount) {
        if (amount > 0 && amount <= balance) {
            balance -= amount;
            return true;
        }
        return false;
    }
}

Weeks 1-3: Inheritance Review

• What: A mechanism where a child class inherits fields and methods from a parent class.
• Why: Code reuse, establishing is-a relationships, building class hierarchies.

public class Animal {
    protected String name;

    public void eat() {
        System.out.println(name + " is eating.");
    }
}

public class Dog extends Animal {
    public Dog(String name) {
        this.name = name;
    }

    public void bark() {
        System.out.println(name + " is barking.");
    }
}

Weeks 1-3: Polymorphism Review

• What: The ability of objects of different classes to respond to the same method call in different ways.
• Why: Enables flexible, extensible code that works with abstractions rather than concrete types.

public abstract class Shape {
    public abstract double area();
}

public class Circle extends Shape {
    private double radius;
    public Circle(double r) { this.radius = r; }
    public double area() { return Math.PI * radius * radius; }
}

public class Rectangle extends Shape {
    private double width, height;
    public Rectangle(double w, double h) { this.width = w; this.height = h; }
    public double area() { return width * height; }
}

// Polymorphic usage
Shape s = new Circle(5);
System.out.println(s.area()); // calls Circle's area()

Weeks 1-3: Abstraction Review

• What: Defining essential characteristics of an object while hiding the implementation details.
• Why: Simplifies complex systems, focuses on what an object does rather than how it does it.

public interface Sortable {
    void sort(int[] data);
}

public class QuickSort implements Sortable {
    public void sort(int[] data) {
        // Quick sort implementation hidden from clients
        quickSort(data, 0, data.length - 1);
    }
    private void quickSort(int[] arr, int low, int high) { /* ... */ }
}

public class MergeSort implements Sortable {
    public void sort(int[] data) {
        // Merge sort implementation hidden from clients
        mergeSort(data, 0, data.length - 1);
    }
    private void mergeSort(int[] arr, int low, int high) { /* ... */ }
}

Week 4: UML Diagrams Review

Unified Modeling Language

Week 4: Class Diagram Relationships Review

Week 5: PlantUML Review

Key Features

• Text-based UML diagramming tool
• Converts plain text descriptions into UML diagrams
• Supports class diagrams, sequence diagrams, use case diagrams, and more
• Integrates with IDEs, CI/CD pipelines, and documentation tools

@startuml
class Animal {
  - name: String
  + eat(): void
}

class Dog extends Animal {
  + bark(): void
}

class Cat extends Animal {
  + meow(): void
}
@enduml

Weeks 6-7: UMPLE Review

Key Features

• Model-Oriented Programming language
• Adds modeling constructs directly into programming languages (Java, C++, PHP)
• Supports associations, state machines, and design patterns
• Generates executable code from models

class Student {
  name;
  Integer studentId;
  1 -- * Course;
}

class Course {
  title;
  Integer courseCode;
}

Weeks 6-7: UMPLE Associations & State Machines

Associations

State Machines

class TrafficLight {
  status {
    Red { timer -> Green; }
    Green { timer -> Yellow; }
    Yellow { timer -> Red; }
  }
}

Module A -- Takeaway

OOP Fundamentals: Key Points

Remember: OOP is not just about syntax -- it is about thinking in objects, designing clean abstractions, and building maintainable systems.

Module B: Course Review -- Design Patterns & Refactoring

Weeks 9-14 Recap

Module B Outline

Design Patterns & Refactoring (Weeks 9-14)

1. Week 9: Creational Patterns (5 patterns)
2. Week 10: Structural Patterns (7 patterns)
3. Week 11: Behavioral Patterns (10 patterns)
4. Week 12: Code Smells (5 categories, 22 smells)
5. Week 13: Refactoring Techniques (6 categories, 66 techniques)
6. Week 14: Case Studies and Best Practices
7. Pattern Selection Decision Guide

Week 9: Creational Design Patterns Summary

5 Patterns for Object Creation

Week 10: Structural Design Patterns Summary

7 Patterns for Class/Object Composition

Week 11: Behavioral Design Patterns Summary

10 Patterns for Object Communication

Week 12: Code Smells Summary

5 Categories, 22 Smells

Week 13: Refactoring Techniques Summary

6 Categories, 66 Techniques

Week 14: Case Studies & Best Practices

Key Lessons

• Real-world applications of design patterns in industry projects
• Pattern combinations -- how patterns work together in practice
• Anti-patterns -- common mistakes and how to avoid them
• SOLID principles applied alongside design patterns
  • S -- Single Responsibility Principle
  • O -- Open/Closed Principle
  • L -- Liskov Substitution Principle
  • I -- Interface Segregation Principle
  • D -- Dependency Inversion Principle

Pattern Selection Decision Guide

How to Choose the Right Pattern

Is your problem about...

CREATING objects?
  |-- Need one instance only?           --> Singleton
  |-- Need families of related objects? --> Abstract Factory
  |-- Need flexible object construction?--> Builder
  |-- Need to copy existing objects?    --> Prototype
  |-- Need subclass to decide type?     --> Factory Method

STRUCTURING classes?
  |-- Need to adapt an interface?       --> Adapter
  |-- Need to add behavior dynamically? --> Decorator
  |-- Need a simplified interface?      --> Facade
  |-- Need tree structures?             --> Composite
  |-- Need controlled access?           --> Proxy

MANAGING behavior?
  |-- Need to notify on state change?   --> Observer
  |-- Need interchangeable algorithms?  --> Strategy
  |-- Need to encapsulate requests?     --> Command
  |-- Need to traverse a collection?    --> Iterator
  |-- Need state-dependent behavior?    --> State

Module B -- Takeaway

Design Patterns & Refactoring: Key Points

Remember: Design patterns are tools, not rules. Use them when they solve a real problem, not to demonstrate knowledge.

Module C: Final Project Requirements & Evaluation

Project Report Structure, Deliverables & Grading

Module C Outline

Final Project Requirements & Evaluation

1. Project Report Structure (MPR2)
2. Expected Deliverables
3. Evaluation Criteria and Rubric
4. Presentation Guidelines
5. Code Quality Expectations
6. Documentation Requirements

Project Report Structure (MPR2)

Required Report Sections

Expected Deliverables

What You Must Submit

1. Source Code

   • Complete, compilable, and runnable project
   • Hosted on a version control system (e.g., GitHub)
   • Clean commit history showing team contributions

2. Project Report (MPR2)

   • Following the structure described above
   • Minimum 15 pages (excluding appendices)
   • PDF format

3. UML Diagrams

   • Class diagram (mandatory)
   • Sequence diagram for at least 2 key scenarios
   • Use case diagram

4. Presentation Slides

   • 10-15 slides covering key aspects
   • Demo screenshots or video

5. Live Demonstration

   • Working prototype shown during project presentation

Evaluation Criteria and Rubric

Grading Breakdown

Presentation Guidelines

How to Structure Your Presentation

Total Time: ~20 minutes per team

Code Quality Expectations

What We Look For

1. Clean Code Principles

   • Meaningful variable and method names
   • Short, focused methods (no Long Methods)
   • Proper code organization and package structure

2. Design Patterns Usage

   • At least 2-3 design patterns applied appropriately
   • Justification for why each pattern was chosen
   • Correct implementation following pattern structure

3. Proper OOP

   • Encapsulation: private fields with getters/setters where needed
   • Inheritance: meaningful class hierarchies (not forced)
   • Polymorphism: interfaces and abstract classes used effectively
   • Abstraction: clean separation of concerns

4. No Code Smells

   • No duplicate code
   • No long parameter lists
   • No feature envy or inappropriate intimacy

Documentation Requirements

UML Diagrams Required

Report Requirements

• PlantUML or UMPLE preferred for diagram generation (not hand-drawn)
• Diagrams must be consistent with actual code
• All external libraries and frameworks must be documented
• Code snippets in the report should be formatted and explained

Module C -- Takeaway

Final Project Requirements: Key Points

• Your project is evaluated on design quality, not just functionality
• Use at least 2-3 design patterns with proper justification
• Submit clean, well-documented code with proper OOP structure
• UML diagrams must match your actual implementation
• The report should tell the story of your project: problem, design, implementation, testing

Module D: Project Demonstration Guidelines

How to Present Your Project Effectively

Module D Outline

Project Demonstration Guidelines

1. How to Present Your Project
2. Demo Flow Recommendations
3. Q&A Preparation Tips
4. Common Pitfalls to Avoid
5. Grading Rubric for Demonstrations

How to Present Your Project

Preparation Checklist

• [ ] Test everything on the presentation machine beforehand
• [ ] Prepare a backup plan (screenshots, video recording) in case of technical issues
• [ ] Know your code -- every team member should understand all parts
• [ ] Prepare talking points -- do not read from slides
• [ ] Practice the demo at least 2-3 times
• [ ] Time your presentation to stay within limits
• [ ] Assign roles -- who presents which section

Presentation Tips

• Start with the big picture before diving into details
• Show the architecture before showing code
• Use diagrams to explain complex interactions
• Keep slides simple -- use them as visual aids, not scripts

Demo Flow Recommendations

Recommended Demo Structure

1. SETUP (1 minute)
   - Show project structure briefly
   - Mention technologies and tools used

2. CORE FEATURES (3-4 minutes)
   - Demonstrate primary functionality
   - Show the most impressive features first
   - Follow a logical user workflow

3. DESIGN HIGHLIGHTS (1-2 minutes)
   - Show a specific design pattern in action
   - Explain WHY you chose that pattern
   - Show the corresponding UML diagram

4. CODE WALKTHROUGH (1-2 minutes)
   - Show one well-written class
   - Highlight clean code practices
   - Show how patterns are implemented

5. EDGE CASES (1 minute)
   - Show error handling
   - Demonstrate input validation

Q&A Preparation Tips

Common Questions to Expect

Tips for Answering

• Be honest -- if you do not know, say so and explain how you would find out
• Be specific -- reference actual classes, methods, and patterns by name
• Be concise -- answer the question directly, then elaborate if asked

Common Pitfalls to Avoid

What NOT to Do

Grading Rubric for Demonstrations

How Demos Are Evaluated

Grade Descriptors

Module D -- Takeaway

Project Demonstration: Key Points

• Prepare thoroughly -- practice the demo multiple times
• Always have a backup -- record a video of your demo
• Focus on design -- the demo should showcase your OOP and pattern usage, not just features
• Every team member must be able to explain every part of the project
• Anticipate questions -- prepare answers for common Q&A topics

Module E: Final Exam Preparation

Exam Format, Key Topics & Study Guide

Module E Outline

Final Exam Preparation

1. Exam Format and Scope
2. Key Topics to Review
3. Sample Question Types
4. Study Resources and Recommendations

Exam Format and Scope

Final Exam Details

What to Bring

• Student ID
• Pen/pencil
• No electronic devices allowed

Key Topics to Review

High-Priority Topics

Sample Question Types

Type 1: Multiple Choice

Example: Which design pattern ensures a class has only one instance?

a) Factory Method
b) Singleton
c) Prototype
d) Builder

Answer: b) Singleton

Sample Question Types (continued)

Type 2: Code Analysis

Example: Identify the design pattern used in the following code:

public interface Logger {
    void log(String message);
}

public class FileLogger implements Logger {
    public void log(String message) { /* write to file */ }
}

public class ConsoleLogger implements Logger {
    public void log(String message) { /* print to console */ }
}

public class LoggerFactory {
    public static Logger getLogger(String type) {
        if (type.equals("file")) return new FileLogger();
        if (type.equals("console")) return new ConsoleLogger();
        throw new IllegalArgumentException("Unknown type: " + type);
    }
}

Answer: Factory Method (Simple Factory variant) -- creates objects without exposing creation logic to the client.

Sample Question Types (continued)

Type 3: Code Smell Identification

Example: Identify the code smell(s) in the following code and suggest a refactoring:

public double calculatePrice(String type, int quantity, double unitPrice,
                              double discount, boolean isMember,
                              String couponCode, double taxRate) {
    // ... complex calculation
}

Answer:

• Code Smell: Long Parameter List
• Refactoring: Introduce Parameter Object -- create a PriceRequest class to group related parameters.

Sample Question Types (continued)

Type 4: Design Problem

Example: You are designing a notification system that needs to:

• Support multiple notification channels (email, SMS, push notification)
• Allow adding new channels without modifying existing code
• Let users subscribe/unsubscribe from notifications

Question: Which design pattern(s) would you use? Draw a UML class diagram and explain your choice.

Expected Answer:

• Observer Pattern for subscribe/unsubscribe mechanism
• Strategy Pattern for interchangeable notification channels
• Should include a class diagram showing NotificationService, Observer interface, NotificationChannel strategy interface, and concrete implementations

Study Resources and Recommendations

Recommended Study Plan

Key Resources

• Course slides (Weeks 1-14)
• RefactoringGuru: https://refactoring.guru
• Design Patterns (GoF Book): Gamma, Helm, Johnson, Vlissides
• Clean Code: Robert C. Martin

Module E -- Takeaway

Final Exam Preparation: Key Points

• The exam covers all topics from Weeks 1-15
• Focus on understanding concepts, not memorizing code
• Practice identifying patterns in code snippets
• Practice identifying code smells and suggesting refactorings
• Be able to draw UML class diagrams for given scenarios
• Know when to use each pattern, not just what it is

Course Summary

What You Have Learned

CEN206 Object-Oriented Programming
|
|-- FOUNDATIONS (Weeks 1-7)
|   |-- OOP Concepts: Encapsulation, Inheritance,
|   |   Polymorphism, Abstraction
|   |-- UML Diagrams: Visual modeling of software systems
|   |-- PlantUML: Text-based diagram generation
|   |-- UMPLE: Model-oriented programming
|
|-- DESIGN PATTERNS (Weeks 9-11)
|   |-- Creational: 5 patterns for object creation
|   |-- Structural: 7 patterns for composition
|   |-- Behavioral: 10 patterns for communication
|
|-- CODE QUALITY (Weeks 12-14)
|   |-- Code Smells: 22 smells across 5 categories
|   |-- Refactoring: 66 techniques across 6 categories
|   |-- Best Practices: SOLID, Clean Code, Case Studies
|
|-- APPLICATION (Week 15)
    |-- Final Project: Applying all concepts together
    |-- Course Summary: Consolidating knowledge

Final Words

Key Principles to Carry Forward

1. Think in objects -- model real-world entities with classes and relationships
2. Design before coding -- UML diagrams save debugging time
3. Use patterns wisely -- they are solutions to recurring problems, not goals themselves
4. Keep code clean -- refactor continuously, eliminate smells early
5. Follow SOLID -- these principles guide good OOP design
6. Test your code -- untested code is unreliable code
7. Document your design -- future you (and your team) will thank you

Good luck with your final projects and exams!

References

• Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (1994). Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley.
• Fowler, M. (2018). Refactoring: Improving the Design of Existing Code (2nd Edition). Addison-Wesley Professional.
• Martin, R. C. (2008). Clean Code: A Handbook of Agile Software Craftsmanship. Prentice Hall.
• RefactoringGuru. Design Patterns. https://refactoring.guru/design-patterns
• RefactoringGuru. Refactoring Techniques. https://refactoring.guru/refactoring/techniques
• RefactoringGuru. Code Smells. https://refactoring.guru/refactoring/smells

References (continued)

• Lethbridge, T. C., & Laganiere, R. (2004). Object-Oriented Software Engineering: Practical Software Development using UML and Java. McGraw-Hill.
• Booch, G., Rumbaugh, J., & Jacobson, I. (2005). The Unified Modeling Language User Guide (2nd Edition). Addison-Wesley.
• PlantUML. PlantUML Documentation. https://plantuml.com
• UMPLE. UMPLE Online. https://cruise.umple.org/umpleonline
• Freeman, E., Robson, E., Sierra, K., & Bates, B. (2004). Head First Design Patterns. O'Reilly Media.

$End-Of-Week-15-Module$