Object-Oriented Software Engineering
Development of object-oriented software systems: theory and practice. Topics include: Computer ethics, software development processes, requirement specification, class and scenario modeling, state modeling, UML, design patterns, traceability. Students are to complete a team project.
Study notes
Independent, AI-drafted study guide · Public sources linked below · Added November 5, 2026
Original study guide aligned to the public Fall 2026 course outline. The outline establishes topic scope; explanations, examples, and practice here are independently written. These are general engineering explanations, not a reproduction of the instructors' slides or project specifications.
Requirements that can guide a design
A requirement states an externally meaningful capability or constraint. Functional requirements describe behavior; quality requirements describe measurable properties such as latency, reliability, or accessibility. A user story is a useful conversation starter, but acceptance criteria make its intended result assessable. Separate stakeholder goals from proposed technology. For a booking system, prevent overlapping reservations is a domain rule; use a particular database is a design constraint only when an actual external obligation requires it.
References: Valente — Software Engineering: A Modern Approach, requirements
Use cases, scenarios, and domain models
A use case captures a goal and the interactions needed to achieve it. A scenario is one particular path, including exceptional outcomes. A domain model identifies concepts and relationships without prematurely turning every noun into a database table or controller. Multiplicity constrains valid associations: one reservation belongs to one customer, while a customer may have many reservations. Check models against the same scenarios so that class diagrams, state changes, and written requirements tell a coherent story.
References: Valente — models and UML
Architecture and responsibility assignment
Architecture groups responsibilities behind boundaries so that likely changes have limited impact. A user interface should not own every business rule merely because it receives the user's input. Put a rule where the relevant knowledge and invariant can be maintained. Dependency inversion makes high-level policies depend on abstractions rather than a specific storage mechanism. Evaluate a boundary by asking what must change when the interface, persistence technology, or business rule changes independently.
- High cohesion keeps related responsibilities together.
- Low coupling limits assumptions crossing a boundary.
References: Valente — design principles
Patterns express forces and tradeoffs
A design pattern names a recurring design problem and a possible organization of collaborators. Strategy makes interchangeable behavior explicit; Observer distributes notifications; Adapter reconciles incompatible interfaces. A pattern is useful only if its indirection solves a real source of change. For example, a fare calculator can delegate to a pricing strategy rather than repeat a switch across multiple screens. The cost is more objects and interfaces, so explain the expected variation before adding that structure.
References: Valente — design patterns
State models and a worked reservation example
Model a reservation as Draft, Confirmed, Cancelled, or Completed. A confirm event should require both available capacity and valid payment authorization. A transition specifies the event, guard, resulting state, and side effects. Cancelling a confirmed reservation may release capacity; cancelling a draft need not reverse a payment that never occurred. Record these distinctions in tests. This model exposes a design question that a class diagram alone misses: which component prevents confirmation and cancellation from violating the same capacity invariant?
References: Valente — models and UML
Traceability, integration, and professional practice
Traceability connects a stakeholder need to requirements, design decisions, implementation, and verification evidence. It helps a team assess the consequence of a change instead of treating documentation as a separate deliverable. Version control, review, automated builds, and small integrations reduce the cost of combining work. Define done with observable behavior and quality checks. Ethical review belongs in engineering decisions: ask who bears a failure's cost, what data is necessary, and whether a claimed capability is supported by evidence.
References: Valente — DevOps · ACM Code of Ethics and Professional Conduct
Practice & worked answers
Original exercises for this guide.
1. A checkout screen calculates tax, updates inventory, and writes SQL. What boundary would you introduce?
Show worked answer
Move checkout policy into an application or domain service and put persistence behind an interface. The screen collects input and presents results. This allows tax rules and database details to change independently, while one service coordinates the inventory invariant.
2. A requirement says the application must be fast. How can it become testable?
Show worked answer
Choose a user operation, workload, environment, and threshold, such as 95% of booking searches completing within a defined latency under a stated concurrent load. The actual target requires stakeholder agreement; inventing a number does not validate the requirement.
Public notes & references
Course sources establish the scope above. Reference materials support the explanations; linked lecture notes and books remain with their authors.
Topics
- Computer ethics
- software development processes
- requirement specification
- class and scenario modeling
- state modeling
- design patterns
- traceability
Course catalogue
Prerequisites & course information
Precludes additional credit for SYSC 3020 , SYSC 3120 , SYSC 4120 . Prerequisite(s): COMP 2401 with a minimum grade of C- , ( COMP 2404 or SYSC 3010 or SYSC 3110 ) with a minimum grade of C- , and ( COMP 2406 or SYSC 4504 ). Lectures three hours a week.