CS446/CS646/ECE452 S26

Lecture Slides

Mon, 01 Jan 0001 00:00:00 +0000

Overview

Mon, 01 Jan 0001 00:00:00 +0000

Overview #

The project forms an integral part of this course. You will work in teams to design and implement a mobile app, during which you practice the software design and architecture knowledge you learn in class.

Goals #

The goals of the project include:

to create something useful;
to learn about architecture styles and design patterns through application in a development setting;
to leverage current software development technologies;
most importantly, to have fun along the way!

The scope of the project should assume at least 6h/week development time (e.g., 6 team members * 6h/week * ~10 weeks = ~360 hours in total). This should be enough time to complete an interesting project.

Pipe-Filter

Mon, 01 Jan 0001 00:00:00 +0000

Pipe-Filter #

Pipe-Filter is suitable for applications that require a defined series of (mostly) independent computations to be performed on a stream of data entries.

Topology #

Example component diagram:

Component: Filters
- each filter transforms input data entry/entries to output data entry/entries.
- local transformations: no shared state between filters, and minimal knowledge of upstream/downstream.
- incremental processing: outputs can begin before all inputs are consumed.
Connector: Pipes
- carry data between filters (streams, files, in-memory queues).

Pros and cons #

Pros
- Maintainability: filters can be replaced or improved locally, as long as their input and output formats are stable.
- Efficiency (throughput): supports concurrency naturally by parallelization and stream processing.
- Observability: performing throughput and deadlock analyses is possible.
Cons
- Efficiency (latency): (de)serialization and data copying across pipes can be expensive.
  - variant: using different data formats for each pipe, improves efficiency but adds complexity.
- Complexity: debugging end-to-end behaviors across many stages can be non-trivial.
- Not ideal for interactive systems.

Variants #

Pipeline #

This variant requires a linear sequence of filters (i.e., each filter has exactly one input pipe and one output pipe). An example is the pipe operator | in Unix shells, e.g., the following component diagram shows the command ls | grep '.pdf' | wc -l:

Stakeholder Interviews

Mon, 01 Jan 0001 00:00:00 +0000

Workshop: Stakeholder Interviews #

At this point, you may have some rough ideas about what kind of mobile app you want to build. Well, there are many different features you can try to support, and many non-functional requirements that you can target, but how do you know which ones are actually useful? Meeting with your stakeholders is the best way to find out.

In this workshop, we will talk about tips for interviewing stakeholder to discover their needs and constraints. We will also run practice interviews with each other. The goal is to leave the workshop with (1) a few concrete requirements items of your app, and (2) an actionable procedure for turning your project idea into concrete requirements items.

Structural Patterns

Mon, 01 Jan 0001 00:00:00 +0000

Structural Design Patterns #

Structural patterns concern the composition of classes and objects into larger structures. They help ensure that when parts of a system change, the overall structure remains flexible and efficient.

Adapter #

Motivation: We need to use an existing class whose interface is incompatible with what our code expects, and we cannot (or do not want to) modify that class (e.g., because it lives in a third-party library).

Android Toolchain

Mon, 01 Jan 0001 00:00:00 +0000

Workshop: Android Toolchain #

In this workshop we will introduce the toolchain for building Android: the IDE, Android Studio; the programming language, Kotlin; and the build system, Gradle. We will walk through the steps of setting up a hello-world Android project, meanwhile introducing these tools and providing pointers for further learning.

Demo code for this topic is available on GitHub.

Android Studio #

Install Android Studio #

Android Studio is the recommended IDE for building Android apps. It comes with a built-in SDK manager and emulator to help you setup a development environment. It is supported on Windows, Max, Linux, and ChromeOS. The editor experience is based on JetBrains (e.g., IntelliJ IDEA, PyCharm).

Behavioral Patterns

Mon, 01 Jan 0001 00:00:00 +0000

Behavioral Design Patterns #

Behavioral patterns concern the interaction and communication between objects. They help distribute responsibilities among objects and define how they collaborate to carry out complex tasks.

Observer #

Motivation: When a system is partitioned into cooperating classes, a common need is to keep related objects in sync—when one object changes state, others that depend on it should be notified. The Observer design pattern implements the Implicit Invocation architectural style.

Layered

Mon, 01 Jan 0001 00:00:00 +0000

Layered #

Layered architecture is suitable for applications that can be organized into a hierarchy of layers, where each layer provides services to the layer above and uses services from the layer below.

Topology #

Example component diagram:

Component: Layers
- each layer groups components at similar abstraction level (e.g., UI, domain/business, data/infrastructure).
- a layer usually only depends on layers below it.
Connector: method calls (or RPC) across layer boundaries, typically behind interfaces.
Configuration: a common constraint is that communication happens only between adjacent layers.

Pros and cons #

Pros
- Maintainability: it is often possible to swap implementations within a layer (e.g., replace storage) if contracts are kept; changes in one layer affects at most two adjacent layers.
- Readability: each layer has a consistent abstraction level, making the system easier to understand.
Cons
- Efficiency: abstractions in high-level functions can add overhead; performance requirements may force the coupling of high-level functions to their low-level implementations (breaking the encapsulation of the layers).
- Not all systems map cleanly to layered structures.

Variants #

Allowing non-adjacent layer communication (layer bypass) #

This variant relaxes the adjacent-layer constraint: a higher layer may call a lower layer directly (e.g., UI calling the data layer) to reduce overhead or boilerplate. It can improve efficiency and development speed for simple flows, but it tends to erode boundaries over time and makes testing/refactoring harder.

Creational Patterns

Mon, 01 Jan 0001 00:00:00 +0000

Creational Design Patterns #

Creational patterns concern the process of object creation. They help make a system independent of how its objects are created, composed, and represented.

Singleton #

Motivation: Some classes must have exactly one instance (e.g., a file system, a database connection pool, a window manager).

Intent: Ensure a class has only one instance and provide a global point of access to it.

Jetpack Compose

Mon, 01 Jan 0001 00:00:00 +0000

Workshop: Jetpack Compose #

In this workshop, we will introduce the Jetpack Compose framework used for building Android apps. The demo we will be following is a minimal online Notes app. You can clone this code, follow the steps to setup Firebase, then you should be able to run the app yourself as well.

This document will explain several key concepts and steps:

How to create UI with Jetpack Compose, following the MVVM architecture;
How to connect with Firebase, which provides various of backend services including authentication and database.

Jetpack Compose #

UI (Composable) #

In Jetpack Compose, each UI element is called a composable, and creating UI is essentially a top-down process of writing composables that contains smaller composables.

Repository

Mon, 01 Jan 0001 00:00:00 +0000

Repository #

Repository (a.k.a. data-centered) style is suitable when the central challenge is establishing, augmenting, and maintaining a shared body of information.

Topology #

Example component diagram:

Component:
- Repository: persistent central data store representing the current system state.
- Tools and services: independent components that can read and write the repository, monitor changes, and perform concurrent computations.
Connector: data CRUD operations and change notifications.

An example of this style is a code editor: many features interact through a shared document buffer.

Teams and Presentation Schedules

Mon, 01 Jan 0001 00:00:00 +0000

Teams and Presentation Schedules #

You can find your assigned TA and the presentation slots (for P4 and P5) on this page.

TA Assignment #

Each team will be assigned to a TA, who will provide technical guidance and feedback on your project and grade your deliverables. Your TA will provide feedback in the comments returned to your deliverables, and be available during most of the workshop sessions to answer questions. Please reach out to your TA if you need additional feedback (depending on their availability).

Implicit Invocation

Mon, 01 Jan 0001 00:00:00 +0000

Implicit Invocation #

Implicit invocation is suitable when components producing events/data do not directly know which other components will consume them.

Topology #

Example component diagram:

Component
- Publishers: emit events/messages.
- Subscribers: register interest and react when events arrive.
Connector: Events/messages
- often grouped by topic/channel.
- publishers do not call subscribers directly; the runtime delivery mechanism handles the fan-out to current subscribers.

Pros and cons #

Pros
- Maintainability: add/remove subscribers without changing publishers; supports pluggable components at runtime.
- Scalability: asynchronous delivery and buffering can be scaled up to handle spikes.
Cons
- Readability: hidden dependencies between components and unpredictable ordering/timing of execution.
- Debugging/testing: often needs tracing, structured logging, and careful test harnesses to reason about the execution order.

Variants #

Event-based #

This variant introduces a shared event bus. Components publish events to the bus and subscribe to events from the bus. Compared to direct publish-subscribe, the bus makes routing and buffering explicit.

Presentation Tips

Mon, 01 Jan 0001 00:00:00 +0000

Presentation Tips #

Time Management #

Sticking to the 10-minute total time limit for your team is crucial.

During the prototype presentation (6 minutes presentation + 4 minutes Q&A/feedback), we will be slightly flexible as you get used to the classroom equipment, but please try to stay within the limit to ensure there is time for feedback.

During the final presentation (8 minutes presentation + 2 minutes Q&A), the time limit is strict and exceeding it will result in point deductions.

Testing

Mon, 01 Jan 0001 00:00:00 +0000

Workshop: Testing #

In this workshop, we will introduce the fundamentals of software testing, and then demonstrate how to write and run tests in Android (unit tests and UI tests).

Testing Basics #

Testing or Quality Assurance (QA) is the software development phase where we test software against its requirements and validate whether it meets stakeholders’ expectations. Testing help you identify and fix bugs early, before they are exposed to users and cause more serious issues. You should start adding tests as soon as you start coding; some argue that tests should be written before the code is written, as executable specifications of the software requirements (Test-Driven Development).

Continuous Integration

Mon, 01 Jan 0001 00:00:00 +0000

Workshop: Continuous Integration #

In this document, we will introduce continuous integration (CI) and walk through setting up a simple CI pipeline for an Android project using GitHub Actions.

Introduction #

Continuous integration means integrating code changes into a shared main branch frequently (often many times per day) and verifying each integration with an automated build and tests. Everyone on the team pushes to the same main branch regularly, so changes are visible and conflicts are surfaced early. The goal is to avoid the pain of a long, chaotic integration phase at the end of a release; instead, each integration is small and easier to debug.

MVVM (MVC, MVP)

Mon, 01 Jan 0001 00:00:00 +0000

MVVM #

MVVM (Model–View–ViewModel) is a presentation-oriented architectural style commonly used in modern UI applications (including Android). The primary goal is to separate the UI logic (which usually needs to be real-time interactive), UI state, and business logic.

Topology #

Example package/class diagram:

Components
- View: renders UI; listens to user events; reacts to UI state changes.
- ViewModel: holds UI state; redirects user events to business logic; fills data into UI state.
- Model: business logic, network calls, data access, etc.
Connector:
- control flows from View to ViewModel to Model;
- data flows backwards.

Pros and cons #

Pros
- Maintainability: UI logic and business logic are easier to maintain separately.
- Separation of concerns: UI logic and business logic do not mix together; UI elements can have different (usually shorter) lifetimes than the ViewModel and Model classes.
- Reusability: one ViewModel can be shared by multiple Views when needed.
- Testability: ViewModel and Model can be easily unit-tested without rendering UI.
Cons
- Overkill for simple state: the extra abstraction may slow down simple projects.
- Debugging: reactive flows and state propagation can be harder to trace without good tooling.

Variants #

MVC and MVP are older versions of MVVM that aim for similar goals (separation of concerns) but differ in where UI logic/state lives and how tightly the “middle” component is coupled to the view.

Release Engineering

Mon, 01 Jan 0001 00:00:00 +0000

Workshop: Release Engineering #

In this document, we will introduce release engineering and walk through deployment strategies that reduce risk during release, plus pointers for publishing an Android app on Google Play.

Introduction #

Release engineering is the practice of getting built software to users reliably. CI (covered in the Continuous Integration workshop) keeps the Integrate and Build stages healthy; release engineering focuses on the Deploy stage: how to ship a new version without excessive downtime or risk.

Server-Client (Microservices, Serverless)

Mon, 01 Jan 0001 00:00:00 +0000

Server-Client #

Server-client is suitable for applications that involve distributed data and processing across multiple components over a network.

Topology #

Basic component diagram:

Component
- Clients: initiate requests.
- Servers: respond to requests and provide services/data.
Connector:
- request/response (HTTP, REST, RPC) or message-based communication (queues/streams).

Server-client is widely adopted in various applications:

Process-Control

Mon, 01 Jan 0001 00:00:00 +0000

Process-Control #

Process-control (aka feedback-control) style is suitable when the system’s purpose is to maintain certain properties of a process output near a desired reference value (set point), despite disturbances.

Topology #

Example component diagram:

Component
- Controller: computes actions based on the set point and feedback.
- Processor: the (physical or software) component being controlled; it usually comes with some observers/sensors to collect telemetry data as feedback.

Pros and cons #

Pros
- Robustness: can adapt to changing conditions and keep the system within acceptable bounds.
- Autonomy: supports self-correcting behaviors (within designed limits).
Cons
- Cost and complexity: requires monitoring/telemetry, calibration, and control logic.
- Sensitive to latency: delayed or noisy feedback can cause oscillations/instability.

Real-world examples #

Autonomous driving #

Many components in an autonomous driving system are built around the process-control style. Consider steering: given a desired steering angle to follow a trajectory (set point), the system (controller) computes the torque command needed to reach that angle and send it to the vehicle’s steering actuator (processor); a sensor continuously reports the actual angle (feedback) back to the controller, which can be different than the desired angle because of road conditions, so that the controller can adjust the torque command accordingly. The same style applies to other components like throttle and braking.

P0: Team Formation

Mon, 01 Jan 0001 00:00:00 +0000

P0: Team Formation #

Deadline: May 22, 11:59pm Eastern Time

Rules for team formation:

Teams must consist of six students.
- There might be a few exceptions for teams of four/five students when the total number of students is not divisible by six. But in that case, note that a smaller team means more work to do for each member.
Everyone must commit to attending team activities. Make sure to agree on how you plan to meet and collaborate.

Start finding teammates NOW

A1: UML Practice

Mon, 01 Jan 0001 00:00:00 +0000

A1: UML Practice #

Deadline: (updated) Jun 10, 11:59pm Eastern Time

Requirements #

Select one of the following software components/modules, and draw a UML class diagram for it. The options are in different programming languages, so you can pick the one that you are most familiar with.

For each component/module, I will point you to its source code files, and a set of primary classes that must be included in the class diagram.

P1: Project Setup

Mon, 01 Jan 0001 00:00:00 +0000

P1: Project Setup #

Deadline: May 29, 11:59pm Eastern Time

Once your team has been formed, you should create a GitHub repository for your project. This repository should be the central place to access your project’s codebase, artifacts, documentations, meeting notes, etc. For this milestone, we require two important documents to be initialized: a README, and a team contract.

Create GitHub Project #

Create a new GitHub repository for your project. Make sure to follow the following requirements:

A2: Decomposition Practice

Mon, 01 Jan 0001 00:00:00 +0000

A2: Decomposition Practice #

Deadline: Jun 19, 11:59pm Eastern Time

Requirements #

Select one of the following software systems (hypothetical or your project), and write a short report on how you would decompose the system.

Your report should be a PDF document. Formatting requirements: 1–2 pages (including the figures, but excluding acknowledgements and references); letter size; main text font size should be at least 11pt.

The report should include the following parts:

P2: Weekly Updates

Mon, 01 Jan 0001 00:00:00 +0000

P2: Weekly Updates #

Deadline: the first Monday at 11:59pm Eastern Time following the week, for weeks 4-6, 8-12.

Week	Date
4	Jun 01 Mon
5	Jun 08 Mon
6	Jun 15 Mon
8	Jun 29 Mon
9	Jul 06 Mon
10	Jul 13 Mon
11	Jul 20 Mon
12	Jul 27 Mon

Requirements #

Each week, you should submit a brief update on your project, in the form of a plain text document (with markdown-style formatting). Your update should include a list of tasks done during the week, and pointers to the relevant artifacts (e.g., code, requirement documents, meeting minutes, etc.) as the outcome of the tasks.

A3: Architectural Style Example

Mon, 01 Jan 0001 00:00:00 +0000

A3: Architectural Style Example #

Deadline: Jul 10, 11:59pm Eastern Time

Requirements #

We will cover several architectural styles in this course. This assignment is designed to evaluate if you have understood the architectural styles. This assignment requires you to choose one architectural style from the following list and come up with an example.

List of architectural styles allowed for this assignment (including their variants):

Your example can be:

A4: Design Pattern Example

Mon, 01 Jan 0001 00:00:00 +0000

A4: Design Pattern Example #

Deadline: July 24, 11:59pm Eastern Time

Requirements #

We will cover several design patterns in this course. This assignment is designed to evaluate if you have understood the design patterns. This assignment requires you to choose one design pattern from the following list, and describe an example of how the pattern has been / could be applied in a software system.

List of design patterns allowed for this assignment:

P3: Project Proposal

Mon, 01 Jan 0001 00:00:00 +0000

P3: Project Proposal #

Deadline: June 5, 11:59pm Eastern Time

Requirements #

The proposal document should be a PDF document. Formatting requirements: 4–6 pages (including the figures, but excluding acknowledgements and references); letter size; main text font size should be at least 11pt.

The document should include the following sections.

Introduction #

Introduce your project topic in a couple of paragraphs. Focus on answering the following questions:

P4: Prototype Presentation

Mon, 01 Jan 0001 00:00:00 +0000

P4: Prototype Presentation #

June 22/24 in class

By midterm, you should have explored some design options, implemented some basic features, and have a prototype to demonstrate the user experience of your app. The goal of prototype presentation is to evaluate your progress so far (focusing on the requirements and architecture/design phases rather than detailed implementations) and to provide timely feedback on that.

Requirements #

The presentation slot is 10 minutes, including 6 minutes for presentation and 4 minutes for questions and feedback. Check the schedule tables for your assigned slot.

P5: Final Presentation

Mon, 01 Jan 0001 00:00:00 +0000

P5: Final Presentation #

Aug 04/05 in class

The goal of final presentation is to evaluate your final product, namely how well it is designed and implemented and whether it meets the requirements set in the beginning of the project. We will evaluate that through a slideshow (which should be brief) and demonstration (which will be more extensive than the prototype presentation).

Requirements #

The presentation slot is 10 minutes, including 8 minutes for presentation and 2 minutes for questions. Check the schedule tables for your assigned slot.

P6: Final Report

Mon, 01 Jan 0001 00:00:00 +0000

P6: Final Report #

Deadline: Aug 05, 11:59pm Eastern Time

Requirements #

The final report document should be a PDF document. Formatting requirements: 8–12 pages (including the figures, but excluding acknowledgements and references); letter size; main text font size should be at least 11pt.

The document should include the following sections.

App Description #

suggested length: 1 page

Using one paragraph and a few screenshots, describe the app you built and its key features. This should be similar to a front page of the app in the app store.

Bonus Points

Mon, 01 Jan 0001 00:00:00 +0000

Bonus Points #

There are a number of ways to earn bonus points for your project. Some of them are competitive, i.e., awarded to the teams presenting the best artifacts at different stages of the project. Others are non-competitive, i.e., awarded as long as you take extra effort to finalize and release your project. This page documents their requirements.

All value are percentages of the total project grade.

Bonus	Value
Outstanding project proposal	2%
Outstanding prototype presentation	2%
Outstanding final presentation	2%
Uploading demonstration video	4%
Publishing to app store	4%
Best app awards by the audience	6%
Best app awards by the course staff	6%

Outstanding project proposal (2%) #

This is awarded to top-20% of the teams based on the quality of their project proposal. They are nominated by the TAs from their pool of assigned teams, and verified by the course staff.

Graduate Student Project

Mon, 01 Jan 0001 00:00:00 +0000

Graduate Student Project #

This assessment only applies to graduate students enrolled in CS646.

You will perform an individual graduate project. Three types of graduate projects are possible:

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 6-8 pages. It is essential that this summary synthesizes the surveyed literature to identify important themes, findings, and open questions.

Evolution of Software Design and Architecture

Mon, 01 Jan 0001 00:00:00 +0000

Evolution of Software Design and Architecture #

CS446/CS646/ECE452 Software Design and Architecture, Pengyu Nie #

Software Design is a Moving Target #

The bottleneck in software engineering keeps shifting as we solve old problems and discover new ones.