SE2: Software Design and Architecture - CS 446, CS 646, ECE 452: Sec 001, 002

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.

Lectures are held Monday and Wed.
Sec 001: 01:00-02:20
Sec 002: 02:30-03:50
in MC 2035. My office hours are by appointment at DC 3349. Official administrative entry.

Important dates and information will be posted here on this website. The official syllabus is also the contents on this website. You can reach this website from the corresponding entry in learn.uwaterloo.ca.

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).
• 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. Please try not to leave your questions until the last minute. Prefix the subject line with CS446/ECE452/CS646 for a prompt reply.

• Instructor: Mei Nagappan - mei.nagappan@uwaterloo.ca (DC3349). Office hours by appointment
• TA: Achyudh Ram Keshav Ram - achyudh.keshav.ram@uwaterloo.ca (DC2555).
• TA: Aswin Vayiravan - avannamalai@uwaterloo.ca (DC2555). Office hours TBD
• TA: Wenhan Zhu (Cosmos) - cosmos.zhu@uwaterloo.ca (DC2555).
• TA: Ivens Portugal - iportugal@uwaterloo.ca (DC2517).

The class will use the Learn system for all submissions, grades, and discussion. Once you are registered, you will be able to access learn and check the dropboxes for submissions, view your grades, and post to the discussion board. Please check the guidelines for posting in Learn before you post your question.

The course is broadly broken down into two components:

Architecture

The architecture component will comprise the first half of the course.

Date	Topics	Notes
May 6	Introduction
May 8	Architecture Overview
May 13	Architectural views & decomposition
May 15	Non-functional properties
May 20	Victoria Day (No Class)
May 22	Arch styles intro	D2/D4 signup
May 27	Intro to building Android apps - Part 1	Attendance Compulsory Hello World Demo
May 29	Intro to building Android apps - Part 2	Attendance Compulsory Second Demo
Jun 3	Project Proposal Presentations
Jun 5	Project Proposal Presentations
Jun 10	Arch Styles (D2)	Client Server Pipe & Filter Layered
Jun 12	Arch Styles (D2)	Event Based Peer to Peer Publish Subscribe
Jun 17	Arch Styles (D2)	Mobile Code Plug-in Blackboard
Jun 19	Project time
Jun 24	Project Prototype Demo (D3)
Jun 26	Project Prototype Demo (D3)

Design

The design component will comprise the second half of the course.

Date	Topics	Notes
Jul 2	Design Introduction	Note: July 1 is a holiday.
Jul 3	Design Patterns (D4)	Proxy State Facade
Jul 8	Design Patterns (D4)	Observer Composite Decorator
Jul 10	Design Patterns (D4)	Command Strategy Visitor
Jul 15	Class cancelled for orals
Jul 17	Class cancelled for orals
Jul 22	Final Demo
Jul 24	Final Demo
Jul 29	Final Exam Review
TBD	Final Exam (Open book, open notes, and anything on paper)

The project forms an integral part of this course. One requirement for the implementation of the app is that it should be a Native Android app (i.e., not built using an app builder or a framework like React/Node.js or HTML5). The two goals of the project is to

• produce a significant mobile app that performs some useful function
• have a defensible design and architecture that can be presented to us explicitly

There are only three soft 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 an Android device. The library has 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.

Project grades need not be the same for all team members. Each team member will get a score based on effort. Projects will have a difficulty scale applied to them by the instructor and TAs. The scale formula will be:

(total project score for the team member across all deliverables + bonus) * scale = final project grade

Scale will range between 0.5 and 1.0. The components of the scaling mark will be determined by:
• 10: completeness (compared to proposal)
• 10: utility
• 10: polish
• 10: difficulty
• 10: pivot
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 the Google Play Store
NOTE: The expectation is that you will work approximately 12 hours per week on this course; at least 8 of these hours should be on the project. Given that the course lasts 12-13 weeks, each team member is expected to work on the project at least 100 hours. You should be able to accomplish something pretty great in this time; please make the most of this opportunity.

2017 Project Videos

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

All deliverables are due at Noon on the day of submission. No late submissions shall be graded.

Deliverable	Date	Format	Value
Project Groups	May 15	E-Mail me and TAs (one per group with all members in CC)	Pass/Fail
Intro to Android App building	May 27/29	Attendance in class	Pass/Fail
D1: Proposal Document	Jun 3	Upload to Learn	5%
D1: Proposal Presentations	Jun 3/5	In class	Pass/Fail
D2: Architecture Activity (updated June 11, 2019)	Jun 10/12/17 (Document due by noon on day of presentation)	Presentation (in class) and upload document to Learn	10%
D3: Prototype Document	Jun 24	Upload to Learn	5%
D3: Prototype Demo	Jun 24/26	In class	Pass/Fail
D4: Design Activity (updated June 11, 2019)	Jul 3/8/10 (Document due by noon on day of presentation)	Presentation (in class) and upload document to Learn	10%
D5: Arch + Design Document	Jul 15	Upload to Learn	10%
D5: Arch + Design Oral Exam	Jul 15-19	Oral exam location DC 3349	10%
D6: Final Documentation + Video	Jul 22	Upload to Learn	5%
D6: Presentation	Jul 22/24	In Class	5%
Final Exam	TBD	Location TBD	50%

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; your final exam grade will only account for 25% of your final grade instead of 50%.

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 May 31 via email to me.
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 Aug 02 via Learn.

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)

Software Design Process Models (3h)

Arch/Design Representations (9h)

Design Plans/Arch (9h)

Design Strategies and Methods (6h)

Design Assessment (3h)

Design Verification (3h)

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