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

Announcements

All Class announcements will be made on Learn.

Winter 2024 (Term 1241)

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 [Sec 001] E2 1736 2:30pm-3:50pm or [Sec 002] MC 2035 8:30am-9:50am.
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 on Learn.

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.

  • Partha Chakraborty - p9chakra@uwaterloo.ca
  • Farshad Kazemi - f2kazemi@uwaterloo.ca
  • Albert Shi - g7shi@uwaterloo.ca
  • Vikram Subramanian - vnsubram@uwaterloo.ca
  • Instructor: Pengyu Nie - pynie@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
Jan 08 Introduction to the Class, Expectations, Admin
Jan 10 Introduction to Software Architecture
Jan 15 Non-Functional Properties
Jan 17 Human Values in Software Engineering
Jan 22 UML Intro
Jan 24 Architectural Views & Decomposition
Jan 29 Project Proposal Presentation
Jan 31 Project Proposal Presentation
Feb 05 Intro to Building Android Apps - Part 1
Feb 07 Intro to Building Android Apps - Part 2
Feb 12 Arch Styles Intro
Feb 14 Arch Styles - Part 1
Feb 19 No Class - Reading Week
Feb 21 No Class - Reading Week
Feb 26 Arch Styles - Part 2
Feb 28 Arch Styles - Part 3
Mar 04 Project Prototype Demo
Mar 06 Project Prototype Demo
Mar 11 Design Patterns Introduction
Mar 13 Design Patterns - Part 1
Mar 18 Design Patterns - Part 2
Mar 20 Design Patterns - Part 3
Mar 25 Release Engineering
Mar 27 No Class - Final Project Finalization
Apr 01 Final Project Presentation
Apr 03 Final Project Presentation

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 4 teams
  • Best final demo - To top 4 teams
  • Accepted to the Google Play Store - To any team that gets through
  • 3-6 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 11:59pm Eastern Time on the respective day. Late submissions will be graded only on a case-by-case basis.
Deliverable Date Format Value
Project Team Selection Jan 19 On Learn and Github No Grade
D1: Proposal Document Feb 02 Upload to Learn 5%
D2: Buddy Team's Evaluation Feb 16 Upload to Learn 5%
D3: Prototype Demo Mar 04/06 Present in Class 5%
D3: Prototype Document Mar 08 Upload to Learn 5%
D4: Architecture Style Examples Mar 22 Upload to Learn 10%
D5: Design Pattern Examples Mar 29 Upload to Learn 10%
D6: Final Presentation Apr 01/03 Present in Class 5%
D6: Arch + Design Document Apr 05 Upload to Learn 15%
D7: Final Status Report Apr 08 (Last Day, Monday) Upload to Learn 5%
Final Exam Apr 19 7:30pm-9:30pm at M3 1006 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 Jan 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 Apr 08 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

Generative AI

Generative artificial intelligence (GenAI) trained using large language models (LLM) or other methods to produce text, images, music, or code, like Chat GPT, DALL-E, or GitHub CoPilot, may be used for assignments in this class with proper documentation, citation, and acknowledgement. Recommendations for how to cite GenAI in student work at the University of Waterloo may be found through the Library. Please be aware that generative AI is known to falsify references to other work and may fabricate facts and inaccurately express ideas. GenAI generates content based on the input of other human authors and may therefore contain inaccuracies or reflect biases.
In addition, you should be aware that the legal/copyright status of generative AI inputs and outputs is unclear. Exercise caution when using large portions of content from AI sources, especially images. More information is available from the Copyright Advisory Committee.
You are accountable for the content and accuracy of all work you submit in this class, including any supported by generative AI.

Territorial Acknowledgement

The University of Waterloo acknowledges that much of our work takes place on the traditional territory of the Neutral, Anishinaabeg and Haudenosaunee peoples. Our main campus is situated on the Haldimand Tract, the land granted to the Six Nations that includes six miles on each side of the Grand River. Our active work toward reconciliation takes place across our campuses through research, learning, teaching, and community building, and is centralized within the Office of Indigenous Relations.

Inclusive Teaching-Learning Spaces

The University of Waterloo values the diverse and intersectional identities of its students, faculty, and staff. The University regards equity and diversity as an integral part of academic excellence and is committed to accessibility for all. We consider our classrooms, online learning, and community spaces to be places where we all will be treated with respect, dignity, and consideration. We welcome individuals of all ages, backgrounds, beliefs, ethnicities, genders, gender identities, gender expressions, national origins, religious affiliations, sexual orientations, ability - and other visible and nonvisible differences. We are all expected to contribute to a respectful, welcoming, and inclusive teaching- learning environment. Any member of the campus community who has experienced discrimination at the University is encouraged to seek guidance from the Office of Equity, Diversity, Inclusion & Anti-racism (EDI-R) via email at equity@uwaterloo.ca. Sexual Violence Prevention & Response Office (SVPRO), supports students at UWaterloo who have experienced, or have been impacted by, sexual violence and gender-based violence. This includes those who experienced harm, those who are supporting others who experienced harm. SVPRO can be contacted at svpro@uwaterloo.ca

Religious & Spiritual Observances

The University of Waterloo has a duty to accommodate religious and spiritual observances under the Ontario Human Rights Code. Please inform the instructor at the beginning of term if special accommodation needs to be made for religious observances that are not otherwise accounted for in the scheduling of classes and assignments. Consult with your instructor(s) within two weeks of the announcement of the due date for which accommodation is being sought.

Respectful Communication and Pronouns

Communications with Instructor(s) and TAs should be through recommended channels for the course (e.g., email, LEARN, Piazza, Teams, etc.) Please use your UW email address. Include an academic signature with your full name, program, student ID. We encourage you to include your pronouns to facilitate respectful communication (e.g., he/him; she/her; they/them). You can update your chosen/preferred name at WatIAM. You can update your pronouns in Quest.

Mental Health and Wellbeing Resources

If you are facing challenges impacting one or more courses, contact your academic advisor, Associate Chair Undergraduate, or the Director of your academic program. Mental health is a serious issue for everyone and can affect your ability to do your best work. We encourage you to seek out mental health and wellbeing support when needed. The Faculty of Engineering Wellness Program has programming and resources for undergraduate students. For counselling (individual or group) reach out to Campus Wellness and Counselling Services. Counselling Services is an inclusive, non-judgmental, and confidential space for anyone to seek support. They offer confidential counselling for a variety of areas including anxiety, stress management, depression, grief, substance use, sexuality, relationship issues, and much more.

Intellectual Property

Be aware that this course contains the intellectual property of their instructor, TA, and/or the University of Waterloo. Intellectual property includes items such as:
  • Lecture content, spoken and written (and any audio/video recording thereof).
  • Lecture handouts, presentations, and other materials prepared for the course (e.g., PowerPoint slides).
  • Questions or solution sets from various types of assessments (e.g., assignments, quizzes, tests, final exams); and
  • Work protected by copyright (e.g., any work authored by the instructor or TA or used by the instructor or TA with permission of the copyright owner).
Course materials and the intellectual property contained therein are used to enhance a student’s educational experience. However, sharing this intellectual property without the intellectual property owner’s permission is a violation of intellectual property rights. For this reason, it is necessary to ask the instructor, TA and/or the University of Waterloo for permission before uploading and sharing the intellectual property of others online (e.g., to an online repository).
Permission from an instructor, TA or the University is also necessary before sharing the intellectual property of others from completed courses with students taking the same/similar courses in subsequent terms/years. In many cases, instructors might be happy to allow distribution of certain materials. However, doing so without expressed permission is considered a violation of intellectual property rights and academic integrity.
Please alert the instructor if you become aware of intellectual property belonging to others (past or present) circulating, either through the student body or online.

Continuity Plan - Fair Contingencies for Unforeseen Circumstances (e.g., resurgence of Covid)

In the event of emergencies or highly unusual circumstances, the instructor will collaborate with the Department/Faculty to find reasonable and fair solutions that respect rights and workloads of students, staff, and faculty. This may include modifying content delivery, course topics and/or assessments and/or weight and/or deadlines with due and fair notice to students. Substantial changes after the first week of classes require the approval of the Associate Dean, Undergraduate Studies.

Declaring absences (undergraduate students and/or courses only)

Regardless of the process used to declare an absence, students are responsible for reaching out to their instructors as soon as possible. The course instructor will determine how missed course components are accommodated. Self-declared absences (for COVID-19 and short-term absences up to 2 days) must be submitted through Quest. Absences requiring documentation (e.g., Verification of Illness Form, bereavement, etc.) are to be uploaded by completing the form on the VIF System. The UW Verification of Illness form, completed by a health professional, is the only acceptable documentation for an absence due to illness. Do not send documentation to your advisor, course instructor, teaching assistant, or lab coordinator. Submission through the VIF System, once approved, will notify your instructors of your absence.

Rescheduling Co-op Interviews

Follow the co-op process for rescheduling co-op interviews for conflicts to graded assignments (e.g., midterms, tests, and final exams). Attendance at co-operative work-term employment interviews is not considered to be a valid reason to miss a test.

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 their 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 their 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 they have 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.

Turnitin.com:

Text matching software (Turnitin®) may be used to screen assignments in this course. Turnitin® is used to verify that all materials and sources in assignments are documented. Students' submissions are stored on a U.S. server, therefore students must be given an alternative (e.g., scaffolded assignment or annotated bibliography), if they are concerned about their privacy and/or security. Students will be given due notice, in the first week of the term and/or at the time assignment details are provided, about arrangements and alternatives for the use of Turnitin in this course.
It is the responsibility of the student to notify the instructor if they, in the first week of term or at the time assignment details are provided, wish to submit alternate assignment.

Acknowledgements

Many thanks to Mei Nagappan and Shane McIntosh for preparing and sharing the course materials from previous offerings of this course.
Toggle Menu