SE2 logo: Software Design and Architecture

SE2: Software Design and Architecture is the second course of the three software engineering capstone project courses, offered jointly by the David R. Cheriton School of Computer Science and the Department of Electrical and Computer Engineering at the University of Waterloo.

SE2 is offered under course codes CS446, SE464, and ECE452.

Lectures are held Tuesday and Thursday from 1000 to 1120 in MC 2034. My office hours are TBD but will be held in DC 3351. Official administrative entry.

Important dates and information will be posted to @cs446. The official syllabus can be found here.

While the course does not have a required textbook, much of the materials will be sourced from the first two texts; additional books are supplementary.

  • Richard N. Taylor, Nenad Medvidovic, and Eric Dashofy. Software Architecture. Foundations, Theory, and Practice. Available in the library or for purchase (e.g., through Amazon.ca). Slides for this book are available online.
  • Ian Gorton. Essential Software Architecture. Available online or for purchase (e.g., through Amazon.ca). Slides for this book are available online.
  • Fred P. Brooks Jr. The Mythical Man Month. Available in the library or for purchase (e.g., through Amazon.ca).
  • Fred P. Brooks Jr. The Design of Design. Unfortunately not in the library but still available through Amazon.ca.

Contacttop

The best way to get help is via email. You can reach me at rth.se2(at)gmail. Please try not to leave your questions until the last minute.

Course Scheduletop

The course is broadly broken down into three components:

Architecture

The architecture component will comprise the first half of the course. ** represents slides from last year that have not yet been updated but represent placeholders for your reference.
DateVideosSlidesIn Class
Jan 6
Introduction Lecture
Jan 8 Architecture intro Kitchen Design
Jan 13 Architectural views & decomposition System Decomposition
Jan 15 Non-functional properties NFP Alternatives
Jan 20 - - Game Show
Jan 22 - - Game Show
Jan 27 - Project Proposals
  • Fami
  • GroupGrub
  • iFoundClassmate
  • Mango
  • Mezzo
  • Motcha
  • Motivatr
  • Musio
  • OneRun
  • Ourdea
  • PoolMe
  • SoundScope
  • Tutoo
  • Unbreakable
Jan 29 Styles intro Survey
D2/D4 signup
Feb 3
  • Client Server
  • Pipe & Filter
  • Layered
Architectural Styles (complete)
  • [Motivatr]
  • [Ourdea]
  • [PoolMe]
Feb 5
  • Event Based
  • Peer to Peer
  • Publish Subscribe
-
  • [GroupGrub]
  • [Musio]
  • [Mango]
Feb 10
  • Mobile Code
  • Interpreter
  • Blackboard
-
  • [SoundScope]
  • [Mezzo]
  • [Fami]
Feb 12 -
Feb 17 - Reading Week -
Feb 19 - Reading Week -

Design

The design component will comprise the second half of the course.
DateVideosSlidesIn Class
Feb 24 - Sample Midterm
Design Introduction
Midterm Review
Design Introduction
Feb 26 - CLASS CANCELLED -
Mar 3 - Prototype Demos
  1. Mango
  2. Motcha
  3. Unbreakable
  4. Tutoo
  5. Mezzo
  6. Motivatr
  7. iFoundClassmate
Mar 5 - Prototype Demos
  1. Fami
  2. Ourdea
  3. SoundScope
  4. OneRun
  5. Musio
  6. GroupGrub
  7. PoolMe
Mar 10 - Design Patterns
  • Proxy - [OneRun]
  • State - [iFoundClassmate]
  • Facade
Mar 12 - Design Patterns
  • Observer - [Tutoo]
  • Composite - [Motcha]
  • Decorator
Mar 17 - Design Patterns
  • Command - [Unbreakable]
  • Strategy
  • Visitor
Mar 19 - MVC / MVP -
Mar 24 - Dependency Injection
  • Dependency Injection
  • Open/Close Principle
Mar 26 - Cloud / Quick Recap
  • Composition vs. Inheritance
  • Cloud Architectures
  • REST Architectures
Mar 31 - Final Demo Tuesday's order:
  1. Motivatr
  2. Musio
  3. Fami
  4. iFoundClassmate
  5. Ourdea
  6. Mango
  7. Tutoo
Apr 2 - Final Demo Thursday's order:
  1. OneRun
  2. SoundScope
  3. Mezzo
  4. Motcha
  5. PoolMe
  6. GroupGrub
  7. Unbreakable
Apr 22 Final Exam April 22 @ 1600 PAC 4

Projecttop

The project forms an integral part of this course. The goal of the project is to produce a significant mobile app that performs some useful function. This software must have a considered and defensible design and architecture. There are only three real restrictions on the app idea itself: no database management apps will be accepted (e.g., simple CRUD apps that do not make sense in a mobile context); apps that require crowd buy-in are not acceptable (e.g., apps that would require large numbers of people to contribute content to be viably useful); apps that require a complex server infrastructure are also not acceptable.

You must demo your app on a mobile device (iOS, Android, BB10, WP8, or FirefoxOS). While the app can be HTML5-based, it must be deployable in a standard app container. I have several BB10 devices that can be used; the library also has iOS and Android devices that can be signed out. After the prototype demo we will provide a 'pivot' to each group; this will consist of a new or modified requirement for your app that you will have to include for the final demo (and write about in the architecture and design deliverable).

The projects will be completed in teams of four. You are free to select your own team; if you do not have a team or your team has less than four members, please talk to me and I will set you up.

Projects will have a difficulty scale applied to them by the instructor and TAs. The scale formula will be:

(project + bonus) * scale = final project grade
Scale will range between 0.75 and 1.0. The components of the scaling mark will be determined by:
  • 5: completeness (compared to proposal)
  • 5: utility
  • 5: polish
  • 10: difficulty
There will also be various sources of bonus marks during the term; each will be worth 2%:
  • Best pitch
  • Best prototype demo
  • Best final demo
  • Accepted to curated App Store (iOS, Blackberry, Windows Phone)
NOTE: The expectation is that you will work approximately 12 hours per week on this course; at least 5 of these hours should be on the project. Given that the course lasts 13 weeks, each team member is expected to work on the project at least 65 hours. You should be able to accomplish something pretty great in this time; please make the most of this opportunity.

Assessmenttop

Deliverable Date Format Value
Design Impressions Jan 6 In Class Pass/Fail
Project Groups Jan 15 E-Mail Pass/Fail
D1: Proposal Presentations Jan 26 (email); Jan 27 In Class (+ email) 5%
D2: Architecture Activity Feb 3/5/10/12 In Class Pass/Fail
D3: Prototype Demo Mar 2 (email); Mar 3/5 In Class (+ email) 5%
D4: Design Activity Mar 10/12/17/19 In Class Pass/Fail
D5: Arch + Design Mar 23 (email); Mar 23-27 Oral Exam (+ email) 30%
D6: Presentation + Video Mar 30 (email); Mar 31/Apr 1 In Class (+ email) 10%
Final Exam April 22 @ 1600 PAC 4 50%

2014 Project Videos

A selection of project videos from 2014 are included in this playlist to help you get an idea of the scope of projects suitable for the course.

You must pass the final exam and all pass/fail assignments to pass the course.

Graduate Student Projecttop

For graduate students only: in addition to the mobile project, you will perform an individual graduate project. The graduate project is worth 25% of your grade; this will come by compressing the value of your final and project grade to 75% of your total mark.

Three types of graduate projects are possible:

  1. Build a Software Tool:

    The goal of this style of project is to identify some problem developers encounter in practice, find some solution, and validate that the solution helps with the initial problem. I would recommend drawing upon your experience as you write code to identify some problem that has inhibited you in the past and fix it.

    The outcome of this project will be a short (5-6 page) paper describing the problem, your solution, a comparison to related approaches, and some form of validation.

  2. Literature Survey:

    The goal of this kind of project is to gain a more complete understanding of a topic relevant to this course. The outcome of this project will be a critical summary of the state-of-the-art on your selected topic; this summary should be 8-10 pages. It is essential that this summary synthesizes the surveyed literature to identify important themes, findings, and open questions.

  3. Use an Advanced Software Development Tool

    The goal of this project is to provide a validation of some previously-existing development tool from the research community. The tool you validate must be related to the course material. The outcome of this project will be a 6-8 page paper describing your experience with the tool outlining its strengths, weaknesses, and avenues for future improvement.

There are two deliverables for the graduate project:

  1. Project proposal. Before you undertake your project you will need to submit a proposal for approval. The proposal should be short (1-2 pages in ACM format). The proposal should include a problem statement, the motivation for the project, a set of objectives you aim to accomplish, and a set of milestones. I will read these and provide comments. The proposal is not for marks but _must_ be completed in order to pass the course. This will be due on Feb 3 @ 0800 via email.
  2. Written report. The required length of the written report varies from project to project; all reports must be formatted according to the ACM format and submitted as a PDF. This artifact will constitute 100% of the graduate project grade. This will be due on Apr 03 @ 0800 via email.

Nominal Course Outlinetop

This is the high-level outline provided by the department; while this is general guideline the course will be adjusted according to your feedback, interests, and experience.

Introduction (1h)

Why design? Input, output, and constraints of the design process. Types of design. Relationship to software quality and evolution. Design in more mature implementation technologies.

Software Design Process Models (3h)

Design as search. Design spaces. Design state, goal structure, generative design operations, early quantitative evaluations, control of design process. Basic models of design (transformational, plan/architecture driven). Relationship to other life-cycle activities.

Arch/Design Representations (9h)

What should be represented (structure, behaviour)? Informal representations of design, examples of design notations. Formal representation of design. Domain specific architecture descriptions. Role of standards, reference architectures. Design documentation.

Design Plans/Arch (9h)

Review of small/medium scale plans (data structures, programming language structures, concurrency). Plans/architectures for common types of software systems (translators, embedded, real-time, user interface).

Design Strategies and Methods (6h)

Design strategies. Selected methods: object modelling technique, structured design, real-time, user interfaces. Methods for design with off-the-shelf components.

Design Assessment (3h)

Assessment dimensions and factors affecting their relative importance. Design tradeoffs. Evolvability/understandability criteria. Design complexity metrics. Assessment strategies (analytical, simulation, rapid prototyping), example: response time/throughput estimation.

Design Verification (3h)

Design reviews, scenarios and test cases, testing of executable design representations. Verification of properties.

Policiestop

Academic Integrity

  • In order to maintain a culture of academic integrity, members of the University of Waterloo community are expected to promote honesty, trust, fairness, respect and responsibility. [See the academic integrity site for more information.]

Grievance

  • A student who believes that a decision affecting some aspect of his/her university life has been unfair or unreasonable may have grounds for initiating a grievance. Read Policy 70, Student Petitions and Grievances, Section 4.
  • When in doubt please be certain to contact the department’s administrative assistant who will provide further assistance.

Discipline

  • A student is expected to know what constitutes academic integrity to avoid committing an academic offence, and to take responsibility for his/her actions.
  • A student who is unsure whether an action constitutes an offence, or who needs help in learning how to avoid offences (e.g., plagiarism, cheating) or about “rules” for group work/collaboration should seek guidance from the course instructor, academic advisor, or the undergraduate Associate Dean.
  • For information on categories of offences and types of penalties, students should refer to Policy 71, Student Discipline.
  • For typical penalties check Guidelines for the Assessment of Penalties.

Appeals

  • A decision made or penalty imposed under Policy 70 (Student Petitions and Grievances) (other than a petition) or Policy 71 (Student Discipline) may be appealed if there is a ground.
  • A student who believes he/she has a ground for an appeal should refer to Policy 72 (Student Appeals).