SE2 logo: Software Design and Architecture

Class complete.

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.

Contacttop

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 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.

Tentative Course Scheduletop

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

Deliverable #2 due @ 0800. [Deliverable details] [Tutorial] [Lecture Notes]

Thursday October 14 - Arch and Security. Intro Design

Tuesday October 19 - Design patterns

Thursday October 21 - Design patterns

Tuesday October 26 - Prototype demos

Deliverable #3 due in class. [Deliverable details][Tutorial]

Thursday October 28 - Design patterns

Tuesday November 2 - Mid-Term.

Thursday November 4 - Mid-Term overview, design patterns

Tuesday November 9 - Alloy - Derek Rayside

Deliverable #4 due in class. [Deliverable details] Derek Rayside on Alloy. This will be examinable.

Thursday November 11 - Alloy - Derek Rayside

Derek has provided a [sample Alloy question] from a past exam. If you attended Dr. Rayside's lectures this should be fairly straightforward to answer. More details on Alloy can be found in the Alloy tutorial.

Tuesday November 16 - Process

Thursday November 18 - MVC / MVP

Tuesday November 23 - Cloud Architectures

Thursday November 25 - Cloud / Refactoring

Tuesday November 30 - Final Presentations

Source code due @ 0800. Deliverable #6 due in class. [Deliverable details]

Thursday December 2 - Final Presentations

  1. Event Chimp
  2. Course Planner
  3. Advisor Appointment System
  4. Financial Portfolios
  5. Score Board
  6. Timmy Us

Monday December 6 - NO LECTURE

Deliverable #5 due @ 0800. [Deliverable details] Deliverable #7 due @ 0800.
  1. Waterloo Maps
  2. My Event Organizer
  3. Enrolment System
  4. RendezVous
  5. Study Group Finder
  6. RoadTrip

December 13 @ 16:00 -- Final Exam

Tutorial Scheduletop

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 Readingstop

Projecttop

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).

Assessmenttop

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.

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).