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

All Class announcements will be made here.

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 notes will be posted in Learn on Monday and Wednesday by 10 AM (I will strive to upload them even before but if you look into Learn by 10 AM on Mon/Wed you should be able to see them).
Anecdotal Winter 2020 feedback from students indicate that detailed lecture notes were more useful than long videos. That is what I will strive to do in this course. In places where I deem videos will be useful, I will make them available. Otherwise it will be detailed slides with possible annotation from me.

Official administrative entry and outline.

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, the following are good readings on this subject.

• Richard N. Taylor, Nenad Medvidovic, and Eric Dashofy. Software Architecture. Foundations, Theory, and Practice. Slides for this book are available online.
• Ian Gorton. Essential Software Architecture.
• Fred P. Brooks Jr. The Mythical Man Month.
• Fred P. Brooks Jr. The Design of Design.

This term we will be using Piazza for class discussion. The system is highly catered to getting you help fast and efficiently from classmates, the TA, and myself. Rather than emailing questions to the teaching staff, I encourage you to post your questions on Piazza.
If you have any problems or feedback for the developers, email team@piazza.com.
Find our class page at: https://piazza.com/uwaterloo.ca/spring2020/cs446ece452cs646/home

If you need to ask a question regarding the grades or something personal then please email the instructor. Prefix the subject line with CS446/ECE452/CS646 for a prompt reply.

All TAs will be answering questions mostly only on piazza. If there is a specific need to actually talk to a TA please email them to get a virtual meeting link that can be used. They have preferred times set up (below). Please try to schedule during these times as much as possible.

• TA: Wenhan Zhu (Cosmos) - cosmos.zhu@uwaterloo.ca. Virtual office hours on Monday. 10 - 11 PM EST.
• TA: Achyudh Ram Keshav Ram - achyudh.keshav.ram@uwaterloo.ca. Virtual office hours on Tuesday. 10 - 11 AM EST.
• TA: Reza Nadri - rnadri@uwaterloo.ca. Virtual office hours on Wednesday. 10 - 11 AM EST.
• TA: Yiwen Dong - yiwen.dong@uwaterloo.ca. Virtual office hours on Thursday. 10 - 11 AM EST.
• TA: Shivasurya Sankarapandian - s5sankarapandian@uwaterloo.ca. Questions on Android development on Piazza.
• Instructor: Mei Nagappan - mei.nagappan@uwaterloo.ca. Virtual office hours on Friday. 10 - 11 AM EST.

The class will use the Learn system for all submissions and grades. Once you are registered, you will be able to access learn and check the dropboxes for submissions and view your grades.

Date	Topics	Notes
May 11	Introduction to the Class, Expectations, Admin	Slides
May 13	Introduction to Software Architecture.	Slides
May 18	Victoria Day. No Class.
May 20	Non-Functional Properties.	Slides
May 25	Intro to building Android apps - Part 1
May 27	Intro to building Android apps - Part 2
June 1	UML Intro	Slides
June 3	Architectural views & decomposition	Slides
June 8	Project Scheduling	Slides
June 10	Cost Estimation	Slides Additional Optional Reading
June 15	Project Proposal Prep. No class.
June 17	Project Proposal Prep. No class.
June 22	Arch Styles Intro	Slides
June 24	Arch Styles - Part 1	Slides
June 29	Arch Styles - Part 2	See Above.
July 1	Canada Day. No Class.
July 6	Project Prototype Demo Prep. No Class.
July 8	Project Prototype Demo Prep. No Class.
July 13	Design Patterns Introduction	Slides
July 15	Design Patterns - Part 1	Slides
July 20	Design Patterns - Part 2	Slides
July 22	Design Patterns - Part 3	Slides
July 27	Project finalization Prep. No class.
July 29	Project finalization Prep. No class.
Aug 3	Civic Holiday
Aug 5	Evaluate final demo and choose best project
Aug 7 - 14	Oral Exam Week

The project forms an integral part of this course. Here are some of the hard requirements:

• The app should be implemented as a Native Android app (i.e., not built using an app builder or a framework like React/Node.js or HTML5).
• The code should be hosted in Github as a private repository. You can choose to open source it after the class if you want. But during the time of the class it shall be private. You will need to add the following user as a collaborator with full privileges: uw-cs446-s20. This is github account for the instructor and TA.
• The app should use at least 2 architectural styles and 2 design patterns that have been discussed in class.

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. If your app has any of these components, then you are responsible to have the DB or server infrastructure of crowd set up so that you can demo the app and we can test it too.

If after the proposal, we feel that the app idea is too simple or too easy, then we will provide the team with a basic idea. The teams will then have to implement our suggested idea. We highly encourage the teams to come up with their own creative ideas. See below for some great ideas from the past.

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

Here is the document with the Pivot for each team.

The projects will be completed in teams of six. If it has less than six or more than six, you will need to explicitly get permission from the instructor. You should select your own team; if you do not have a team or your team has less than six members, please post on the appropriate Piazza thread.

Project grades need not be the same for all team members. Each team member will get a score based on effort. Additionally, 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/100) = final project grade

Scale will range between 0 and 100. The components of the scaling mark will be determined by:

• 10: completeness (compared to proposal)
• 10: utility
• 10: polish
• 10: difficulty
• 10: pivot
• 50: individual effort - will be based on peer evaluation and our assessment based on oral exam and github logs

There will also be two sources of bonus marks during the term; which will be worth 2%:

• Best final demo - To two teams
• Accepted to the Google Play Store - To any team that gets through

NOTE: The expectation is that you will work approximately 9 hours per week on this course; at least 6 of these hours should be on the project. Given that the course lasts 12 weeks, each team member is expected to work on the project at least 75 hours. As a team of six that will be 450 hours. You should be able to accomplish something pretty great in this time; please make the most of this opportunity.

Installing Android Studio

https://developer.android.com/studio/install

Use the above link to start installing Android Studio in Linux/Win/Mac Machines beforehand. The download size may vary based on the operating system/region and locale ( 800 MB ) for Android Studio alone. Always choose the latest version of Android Studio and corresponding Gradle plugin to build APK files, which helps in reviewing code and evaluation.

SDK Installation: Use the latest Stable Android Version for SDK Compilation rather than the beta version. The preferable version can be from Android M ( API 23 ) to Android Q ( API 29 ). As soon as installing the Android Studio, start selecting the preferred android version ( at least 1 ) and download the corresponding emulator, SDK Library, SDK Build Tools, and other utilities. Kindly allocate around 20 GB physical space for Android Studio and SDK Installation and a stable internet connection to complete all the installation setup in advance.

Emulator vs. Android Phone: Kindly use Android Mobile phone for testing by connecting it via USB for debugging, which will have a low impact on system resources while building Android apps. Otherwise, kindly install x86 Google Play/Google API Supported Android emulator for instant access and testing. Do not install ARM or other arch types that are not optimized for cold startup/booting.

Reliable Network Connection: Kindly ensure about reliable network connection for downloading Android Studio and SDK Libraries. Additional data will be required while using third party libraries to build an application or while syncing via Gradle.

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.

In order to check if you as a student has gone through the class slides every week, we will have various quizzes and assignments. In total there will be 6 quizzes and 2 assignments.

The quizzes should take no more than 10-15 minutes each if you have gone through the material. They will be multiple choice, T/F type quizzes on that weeks material. The quizzes are individual and not for teams.

The two assignments will be to assess how much of the architecture styles and design patterns you have understood from the lecture slides. They will be group assignments.

There will be no written finals in this course. Instead we will do an oral exam. Details are below:

1. Sign up for meeting slot in the online sign up sheet . Make sure your whole team can attend.
2. Meeting will be virtual and we will provide a meeting room here.
3. The signup is first come, first served; please sign up using your team name.
4. The slot is 60 minutes. You will start by giving a 10 minute oral description of your system’s architecture and design. You can use screen share any material (slides/previous documents)
5. The remainder of the slot will be used to discuss your architecture and design.
6. Some questions will be for the group, others will be for specific individuals.
7. Being able to clearly and unambiguously justify your architectural and design decisions will be fundamental to success here.
8. Be prepared to defend your system’s design. We will also likely ask about how your design could adapt to specific given evolutionary constraints (e.g., ‘you must now support XYZ, how would you do that?’). This would involve knowing other similar styles or patterns.

All deliverables are due at 5 PM EST on the respective Friday. Late submissions will be graded only on a case by case basis.

Deliverable	Date	Format	Value
Quiz 1	May 15	On Learn	5%
Quiz 2	May 22	On Learn	5%
Project Team Selection	May 22	Create on Learn	No Grade
Quiz 3	June 5	On Learn	5%
Quiz 4	June 12	On Learn	5%
D1: Proposal Document	June 19	Upload to Learn	5%
D2: Architecture Style Examples	July 3	Upload to Learn	10%
Quiz 5	July 3	On Learn	5%
D3: Prototype Document + Demo	July 10July 17	Upload to Learn	10%
D4: Design Pattern Examples	July 24	Upload to Learn	10%
Quiz 6	July 24	on Learn	5%
D5: Arch + Design Document	July 31Aug 3	Upload to Learn	10%
D6: Final Documentation + Video	Aug 5 (Note this is a Wed)	Upload to Learn	5%
Oral Exam	Aug 7 - 14	Virtually	20%

For graduate students only: in addition to the project and other assessments above, you will perform an individual graduate project. The graduate project is worth 25% of your grade; your final grade will be calculated by scaling down the above assessments from 100% to 75%.

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 email to me.

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