CEN206 Object-Oriented Programming¶

Week-15 (Final Project Progress Review & Course Summary)¶

Spring Semester, 2025-2026¶

Download DOC-PDF, DOC-DOCX, SLIDE

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
2. Complete, compilable, and runnable project
3. Hosted on a version control system (e.g., GitHub)

4. Clean commit history showing team contributions

5. Project Report (MPR2)

6. Following the structure described above
7. Minimum 15 pages (excluding appendices)

8. PDF format

9. UML Diagrams

10. Class diagram (mandatory)
11. Sequence diagram for at least 2 key scenarios

12. Use case diagram

13. Presentation Slides

14. 10-15 slides covering key aspects

15. Demo screenshots or video

16. Live Demonstration

17. 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
2. Meaningful variable and method names
3. Short, focused methods (no Long Methods)

4. Proper code organization and package structure

5. Design Patterns Usage

6. At least 2-3 design patterns applied appropriately
7. Justification for why each pattern was chosen

8. Correct implementation following pattern structure

9. Proper OOP

10. Encapsulation: private fields with getters/setters where needed
11. Inheritance: meaningful class hierarchies (not forced)
12. Polymorphism: interfaces and abstract classes used effectively

13. Abstraction: clean separation of concerns

14. No Code Smells

15. No duplicate code
16. No long parameter lists
17. 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 (2^nd 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 (2^nd 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\)