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

Announcements

All Class announcements will be made on Learn.

Spring 2023 (Term 1235)

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.

Class will be in-person on Monday & Wednesday at MC 2035 8:30-9:50 or at MC 2035 10:00am-11:20am or at MC 2034 1:00pm-2:20pm unless the university decides to move to virtual. If we go virtual, at the same times we will meet in a zoom room whose link I will email all of you.
This will be a flipped classroom. I will post slides with scripts and the corresponding video recordings on Learn at least two days before class. I will strive to get them on earlier.
In class we will do exercises and quiz type questions and group discussions. Note that these are not evaluated. You are welcome and encouraged to attend at they will certainly make the material covered in the slides and recordings more concrete and meaningful. But you are not required to.

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.

Contact

This term we will be using Learn for class discussion. Rather than emailing questions to the teaching staff, I encourage you to post your questions on Learn.

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 Learn. If there is a specific need to actually talk to a TA, please email them to set up a time. Otherwise their office hours are below.

  • Partha Chakraborty - p9chakraborty@uwaterloo.ca. office hours TBD
  • Yiwen Dong - yiwen.dong@uwaterloo.ca. office hours TBD
  • Farshad Kazemi - f2kazemi@uwaterloo.ca. office hours TBD
  • Akinbowale Akin-Taylor - aakintay@uwaterloo.ca. office hours TBD
  • Deborah Etsenake - detsenak@uwaterloo.ca. office hours TBD
  • Joy Idialu - j2idialu@uwaterloo.ca. office hours TBD
  • Favour Kio - gn2kio@uwaterloo.ca. office hours TBD
  • Albert Shi - g7shi@uwaterloo.ca. office hours TBD
  • Vikram Subramanian - vnsubram@uwaterloo.ca. office hours TBD
  • Instructor: Mei Nagappan - mei.nagappan@uwaterloo.ca. Office hours by appointment

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.

Course Schedule

DateTopicsNotes
May 08 Introduction to the Class, Expectations, Admin
May 10 Introduction to Software Architecture
May 15 Non-Functional Properties.
May 17 Human Values in Software Engineering
May 23 UML Intro
May 24 Architectural views & decomposition
May 29 Project Proposal Presentation
May 31 Project Proposal Presentation
June 05 Intro to building Android apps - Part 1
June 07 Intro to building Android apps - Part 2
June 12 Arch Styles Intro
June 14 Arch Styles - Part 1
June 19 Arch Styles - Part 2
June 21 Arch Styles - Part 3
June 26 Project Prototype Demo
June 28 Project Prototype Demo
July 03 No Class
July 05 Design Patterns Introduction
July 10 Design Patterns - Part 1
July 12 Design Patterns - Part 2
July 17 Design Patterns - Part 3
July 19 Release Engineering - Continuous Experimentation
July 24 Final Project Presentation
July 26 Final Project Presentation
July 31 Final Exam Review

Project

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 public repository.
  • The app should use at least 2 architectural styles and 2 design patterns (other than singleton) that have been discussed in class.

The three goals of the project is to

  • produce a significant mobile app that performs some useful function
  • does not cause harm to any population of users
  • have a defensible design and architecture that can be presented to us explicitly

When coming up with your own app there are only two hard and soft restrictions on the app idea itself:
Hard Restrictions

  • Simple CRUD apps that do not make sense in a mobile context are not allowed;
  • No games
Soft Restrictions
  • 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 or crowd set up so that you can demo the app and we can test it too.

Human values: In the proposal, you will detail the functional requirements, non-functional properties, and human values that your app addresses. You will also state who some of your stakeholders are and which population of users that your app is useful for.

Buddy team evaluation: You will receive the proposal of another team. Your goal is to look at the proposal and find out which populations could be harmed and what harm could be created by the features of the app. You are expected to think critically and come up with an exhaustive list. The instructor and TAs will also come up with a list. You are evaluated on how similar you are to our list.

Pivot: The lists of harm that exist in the app created by the instructor team and the buddy team will be shared with the team that proposed the project by the prototype demo stage. When you receive your list, you are expected to make changes in the project so that the harm is mitigated. This change has to be documented by the final demo and written deliverable.

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 Learn discussion thread.

All project grades taken together (D1, D2, D3, D6, D7) need not be the same for all team members. Each team member will get a score based on effort. Please only commit your personal contribution to the repository. Do not commit for another team member. Commits to the repo are an important signal to us. Additionally, projects will have a difficulty scale applied to them by the instructor and TAs. The scale formula will be:

(total score for the team member across all project deliverables D1, D2, D3, D6, D7 + 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 time and GitHub logs
There will also be four sources of bonus marks during the term; which will each be worth 2%:
  • Best prototype demo - To top 2 teams per section
  • Best final demo - To top 2 teams per section
  • Accepted to the Google Play Store - To any team that gets through
  • 3 minute video of the app demo uploaded to Youtube
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 R ( API 33 ). As soon as you install 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.

Assessment Breakdown and Schedule

Most 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
Project Team Selection May 19 On Learn and Github No Grade
D1: Proposal Document June 02 Upload to Learn 5%
D2: Buddy team's evaluation June 16 Upload to Learn 5%
D3: Prototype Demo June 26/28 Present in Class/Upload to Learn 5%
D3: Prototype Document June 30 Upload to Learn 5%
D4: Architecture Style Examples July 14 Upload to Learn 10%
D5: Design Pattern Examples July 21 Upload to Learn 10%
D6: Final Presentation July 24/26 Present in Class 5%
D6: Arch + Design Document July 28 Upload to Learn 15%
D7: Final Status Report Aug 1 (Last Day, Tuesday) Upload to Learn 5%
Final Exam TBD 35%

Graduate Student Project

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

Nominal Course Outline

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.

Administrative Notes

Land Acknowledgement

As a settler, I want to acknowledge that I live and work on the traditional territory of the Attawandaron (Neutral), Anishnawbe and Haudenosaunee peoples. The University of Waterloo is situated on the Haldimand Tract, the land promised to the Six Nations that includes six miles on each side of the Grand River. Truth & Reconciliation Response Projects.

Mental Health Support

The Faculty of Math encourages students to seek out mental health support if needed. On-campus Resources:

  • Campus Wellness
  • Counselling Services: counselling.services@uwaterloo.ca/ 519-888-4567 ext 32655
  • MATES: one-to-one peer support program offered by Waterloo Undergraduate Student
  • Association (WUSA) and Counselling Services: mates@wusa.ca
  • Health Services: located across the creek from the Student Life Centre, 519-888-4096.
Off-campus Resources:
  • Good2Talk (24/7): Free confidential helpline for post-secondary students. Phone: 1-866-925-5454 (Ontario and Nova Scotia only)
  • Here 24/7: Mental Health and Crisis Service Team. Phone: 1-844-437-3247 (Waterloo Region only)
  • OK2BME: Set of support services for lesbian, gay, bisexual, transgender or questioning teens. Phone: 519-884-0000 extension 213 (Waterloo Region only)
  • EMPOWER ME  1-833-628-5589 for Cdn./USA other countries see: http://studentcare.ca/rte/en/IHaveAPlan_WUSA_EmpowerMe_EmpowerMe
  • EMPOWER ME in China: China North 108007142831; China South 108001402851

Diversity

It is our intent that students from all diverse backgrounds and perspectives be well served by this course and that students’ learning needs be addressed both in and out of class. We recognize the immense value of the diversity in identities, perspectives, and contributions that students bring, and the benefit it has on our educational environment. Your suggestions are encouraged and appreciated. Please let us know ways to improve the effectiveness of the course for you personally or for other students or student groups. In particular:
  • We will gladly honour your request to address you by an alternate/preferred name or gender pronoun. Please advise us of this preference early in the term so we may make appropriate changes to our records.
  • We will honour your religious holidays and celebrations. Please inform of us these at the start of the course.
  • We will follow AccessAbility Services guidelines and protocols on how to best support students with different learning needs.

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. [Check the Office of Academic Integrity 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. , Student Petitions and Grievances, Section 4.

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. [Check the Office of Academic Integrity for more information.] 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).

Note for students with disabilities

AccessAbility Services, located in Needles Hall, Room 1401, collaborates with all academic departments to arrange appropriate accommodations for students with disabilities without compromising the academic integrity of the curriculum. If you require academic accommodations to lessen the impact of your disability, please register with AccessAbility Services at the beginning of each academic term.
Toggle Menu