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.
Important dates and information will be posted to the course twitter feed.
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.
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.
Software Design Process Models (3h)
Arch/Design Representations (9h)
Design Plans/Arch (9h)
Design Strategies and Methods (6h)
Design Assessment (3h)
Design Verification (3h)
Monday Jan 7 - Introduction & project description
Wednesday Jan 9 - Kitchen design activity
Friday Jan 11 - Architecture introduction
Monday Jan 14 - RIM Guest Lecture
Wednesday Jan 16 - Architecture Basics
Friday Jan 18 - Views and NFPs
Monday Jan 21 - Proposal presentations
Presentation order listed below:
- B Smart
- Lazy Scholar
- Point (2% bonus)
- Friend Tracker
- Of Course (2% bonus)
Wednesday Jan 23 - Arch Styles
Friday Jan 25 - Arch Styles
Monday Jan 28 - Arch Styles
Wednesday Jan 30 - Arch Styles
Friday Feb 1 - Arch of LLVM & Audacity
Monday Feb 4 - Arch Style Review / D2
Wednesday Feb 6 - Arch representations
Friday Feb 8 - Snow Day
Monday Feb 11 - Design QualitiesDeliverable #2 (project architecture) due @ 0800. [Deliverable details]
Wednesday Feb 13 - Design Pattern Intro
Friday Feb 15 - Design Patterns (Singleton)
Monday Feb 18 - No class (reading week)
Wednesday Feb 20 - No class (reading week)
Friday Feb 22 - No class (reading week)
Monday Feb 25 - Design patterns (Adapter & Facade)
Wednesday Feb 27 - Prototype demos
- Friend tracker
- Drink It
- Of Course
Friday Mar 1 - Prototype demos
- Demention (2% most complete bonus)
- Lazy Scholar
Monday Mar 4 - Design Patterns (Template Method & Strategy)
Wednesday Mar 6 - Design Patterns (Command)
Friday Mar 8 - Design Patterns (Observer & Composite), Design Principles
Monday Mar 11 - Cloning designs (Wei)
Wednesday Mar 13 - Designing for Testability (Laura)
Friday Mar 15 - Class Cancelled
Monday Mar 18 - Architecture in Practice (Chrome)
Wednesday Mar 20 - MVP/MVC + Dependency Injection
Friday Mar 22 - Cloud Architectures
Monday Mar 25 - Activity (please be on time!)
Wednesday Mar 27 - Activity (please be on time!)
Friday Mar 29 - No class (Good Friday)
Monday Apr 1 - Final Presentations
- Lazy Scholar
- Scary Game
Wednesday Apr 3 - Final Presentations
- Don't Break the Chain
Friday Apr 5 - Final Presentations
- Friend Tracker
- OfCouse (2% best app bonus)
The project forms an integral part of this course. The goal of the project is to produce a significant piece of software that performs some useful function. This software must have a considered and defensible design and architecture. There are only two 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); also, 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).Your app must be executable on the BB10 Dev Alpha device; one device will be provided to each team. This device must be returned at the end of the course. You are free to use any of the BB10-compatible development platforms (these are listed online). Please choose the platform that best matches the needs of your app. You will be asked in the architecture deliverable to rationalize your platform choice.
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. Each of the deliverables for the project can be considered assignments. Bonus points will be awarded to teams who are able to get their app accepted into Blackberry World by the time the final exam period ends.
Projects will have a difficulty scale applied to them by the instructor and TAs. The scale formula will be:
(project + bonus) * scale = final project gradeScale 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
- Best pitch
- Best prototype demo
- Best final demo
- Accepted to Blackberry World
Design Impressions: Pass/Fail
Deliverable #1: Project proposalPass/Fail
Deliverable #5: Project implementationPass/Pass (cancelled)
You must pass the final exam and all pass/fail assignments to pass the course.
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:
- 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.
- 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.
- 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:
- 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 October 3 @ 0800 via email.
- 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 December 05 @ 0800 via email.
- 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.]
- 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.
- 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.
- 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).