If you want a mark breakdown, email me from your quest account and I will send you your final mark tabulation for the course. If you would like to pick up an assignment, send me a message and we can work something out for after Jan 4.
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 SE464, CS446, and ECE452.
Lectures are held Tuesday and Thursday from 16:00 to 17:20 in MC 4063. Tutorials are held Friday from 14:30 to 15:20 in MC 4063. My office hours are TBD but will be held in DC 3351. Official administrative entry.
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
.
Contact
The best way to get help is via email. You can reach Sarah Nadi at snadi(at)cs.uwaterloo, Wei Wang at w65wang(at)cs.uwaterloo address, or Reid Holmes at rth.se2(at)gmail. Please try not to leave your questions until the last minute.
Nominal Outline
Introduction (1h)
Software Design Process Models (3h)
Arch/Design Representations (9h)
Design Plans/Arch (9h)
Design Strategies and Methods (6h)
Design Assessment (3h)
Design Verification (3h)
Tentative Course Schedule
It is important to note that this schedule is very susceptible to change based on your interests and how the class is progressing.
Tuesday September 14 -- Introduction
Thursday September 16 - Architecture introduction
Tuesday September 21 - Proposal presentations
Thursday September 23 - Arch foundations
Tuesday September 28 - Arch styles
Thursday September 30 - Arch styles
Tuesday October 5 - Arch styles / representations
Thursday October 7 - Arch of GWT / Arch NFPs
Tuesday October 12 - Arch NFPs
Thursday October 14 - Arch and Security. Intro Design
Tuesday October 19 - Design patterns
Thursday October 21 - Design patterns
Tuesday October 26 - Prototype demos
Thursday October 28 - Design patterns
Tuesday November 2 - Mid-Term.
Thursday November 4 - Mid-Term overview, design patterns
Tuesday November 9 - Alloy - Derek Rayside
Thursday November 11 - Alloy - Derek Rayside
Tuesday November 23 - Cloud Architectures
Thursday November 25 - Cloud / Refactoring
Tuesday November 30 - Final Presentations
Thursday December 2 - Final Presentations
- Event Chimp
- Course Planner
- Advisor Appointment System
- Financial Portfolios
- Score Board
- Timmy Us
Monday December 6 - NO LECTURE
- Waterloo Maps
- My Event Organizer
- Enrolment System
- RendezVous
- Study Group Finder
- RoadTrip
December 13 @ 16:00 -- Final Exam
Tutorial Schedule
A tutorial will not be presented every week. On the weeks a tutorial is not being presented the TAs will conduct office hours in DC 3334 (the SWAG lab). The tutorial is an excellent time to meet with the TAs with any questions, concerns, or problems. The tutorial / office hour list will be updated as the term progresses; announcements about Friday's tutorial will always be available by the start of class on Tuesday.
- Friday, Sept 17: Tutorial on GWT.
- Friday, Sept 24: Tutorial on Deliverable #2.
- Friday, Oct 22: Tutorial on Deliverable #3. ...
- Friday, Oct 29: Tutorial on Deliverable #4. ...
- Friday, Nov 26: Tutorial on Deliverable #5 and #6. ...
Supplemental Readings
These required readings augment the course material.
Project
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. The software must be runnable on a mobile device although I would prefer if it would run on multiple mobile platforms. Obviously this requirement suggests developing your system using some kind of cross-platform development methodology which leads to the one of the only limitations being placed on the project: you will use Google's GWT framework to build your app. GWT allows you to write your application in Java and automatically cross-compiles the result to javascript that works on multiple browsers and platforms; UI theming is done via HTML/CSS. GWT provides a good platform to build on and will force each team to consider their architecture more carefully as your system must interoperate with various frameworks and deal with various limitations of being deployable to a handheld device. Your application can still work on a full browser as well if you wish.
The projects will be completed in teams, preferably in groups 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 try to help. Each of the deliverables for the project can be considered assignments.
Deliverable #1: Project Proposal. DUE September 21 @ 08:00. [Details]
An initial project proposal is due via email to rth.se2@gmail on September 21 @ 0800.Deliverable #2: System Architecture. DUE October 12 @ 08:00. [Details] [Tutorial]
Your system architecture is due on October 12 @ 0800 to rth.se2@gmail. There are both group and individual components to this assignment.Deliverable #3: Prototype. DUE October 26 In Class. [Details]
An initial prototype is due on October 26 in class. Each team will spend 5 minutes demoing their prototype implementation at this time. Each team should be able to show that at least one major piece of their system works. Emphasis should be placed on demonstrating round-trip functionality rather than a single aspect of the UI or back end.Deliverable #4: Detailed Design. DUE November 9 @ 08:00. [Details]
Deliverable #5: Final Implementation. DUE December 5 @ 08:00. [Details]
The final implementation of your project (the zip file) is due on November 30 @ 0800. The report is due on December 5 @ 08:00. This deliverable should include three parts: 1) a zip file containing of all of your development resources (e.g., your workspace); 2) a zip file containing a deployable version of your system; and 3) your final report.
The final report should describe in moderate detail how your final implementation compares in terms of functionality, architecture, and design (vs. Deliverable #1, #2, and #4 respectively). Both commonalities and differences should be noted. Where major divergences have occurred, they should be explained. NOTE: divergences are allowed, as long as they can be adequately justified. The final report should be in PDF format; concise reports that accurately describe the commonalities and differences are preferred (e.g., one full page per deliverable is fine, more if figures and diagrams are included).
Deliverable #6: Final Demonstration. Nov 30 / Dec 2 In Class. [Details]
No matter how elegant your design may be, you must be able to communicate its strengths and weaknesses to your coworkers and peers. Each group will have the opportunity to provide a short demonstration of their application to the class along with an overview of the system's architecture and an explanation of the key design decisions that made the project possible. There will be an opportunity for each team to answer questions about their system and design as well.Deliverable #7: Team Assessment. Dec 3 @ 08:00.
Each team member will be allocated $1,000 in virtual funds to allocate to each of the members of the team (including themselves). This is an opportunity for team members who feel that the distribution of effort on the group project was not fair to express their concern. This assessment should be confidentially emailed to rth.se2@gmail.com by the due date. The email should include the team name and a simple table consisting of team member names and dollar values. The maximum penalty that can be applied is 25% of the project (10% of the overall score); this scaling will only be applied to a team member if their allotted share is less than (1,000 / n) with a 10% buffer (e.g., penalties will only be applied if the team members indicate a significant problem).Assessment
Design Impressions: Pass/Fail
Deliverable #1: Pass/Fail
Deliverable #2: 10%
Deliverable #3: Pass/Fail
Deliverable #4: 10%
Deliverable #5: 10%
Deliverable #6: 10%
Mid-Term: 10%
Final: 50%
You must pass the final exam and all pass/fail assignments to pass the course. Deliverable #7 will be used to scale the scores for the project. For graduate students: your midterm will be pass/fail. In lieu of this, you will perform a short library research project due on the last day of classes (worth 10% of your final grade). The project will culminate in a 15-20 page written tutorial, complete with references. The project can be on any research topic relating to software design and architecture. Example topics include design / architecture recovery, architectural evolution, architectural/design modelling, architectural/design analysis.Policies
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).