Software Engineering

These notes are for a version of the class taught by professor Ivan Marsic in the spring of 2017.

You can find the course materials here

Syllabus Here

Lecture 1 - 1/17/17

Software engineering is the bridge from customer requirements to implementation.

First law of software engineering: Software engineers are willing to learn the problem domain. (or a problem cannot be solved without first gaining an understanding of it.)

Software engineers need to take customer problems or requirements and be able to analyze those requirements and turn that into a robust implementation. Good engineers will be able to combine their understanding of the requirements that a customer is asking for and use that and their background knowledge to come up with great implementations. They should be able to argue why their solution is the best.

There are three different types of people when creating software projects.

Many times the software engineer and programmer’s tasks will interweave with one another.

Software Engineering Blueprints - UML diagrams are like blueprints for a program. They allow us to visually represent our software

Second Law of Software Engineering - Software should be written for people first.

Lecture 2 - 1/27/2017

See my blog post on git

Notes From Syllabus - Lecture 2

Lecture 3 - 1/24/2017

Understanding the Problem and Dividing Work

Why we want to Subdivide Problems/Project

How Beginners Divide Work

Decomposition vs Partitioning

Projection-based decomposition helps us understand the components in the context of their use, relative to other parts of the system.

Example: Restaurant Automation Decomposition by Projection

They are combined by the “shared infrastructure”. After dividing sub-projects you can find the shared-infrastructure. You must be able to understand the whole project and the subproblem in order to identify the shared infrastructure.

Always ensure that your “mini-project” can be demonstrated standalone and achieves something interesting.

Only after that can you ensure that other team members’ contributions can be integrated and the whole project demonstrated for the greatest success.

We assume that software helps the user achieve a business goal in the problem domain.

Lecture 4 - 1/27/2017

Requirements Engineering

The process of completing an engineering project should at a minimum always consists of:

When writing requirements it is important to be specific and identify what exact requirements are going to be referenced throughout the document.

One way to do this is to label each requirement with an identifier, the priority of each requirement, and a short description of the requirements in as exact language as possible.

We should also think about user stories when designing our requirements. This means focusing on the user of the system and how they will use the system.

I.e. “As a tenant, I can unlock the doors to enter my apartment.

This is similar to building system requirements, but focuses on the benefits that the user gains instead of on the features of the systems’s solution to problems.

Dynamic Prioritization of User Stories

Define a number of user stories, i.e. ST-1, ST-2, ST-3, ST-4….

For each story assign an estimated number of days to complete and assign a number of points to each story to prioritize the feature development.

Lecture 5 - 1/31/2017

Hierarchical Organization of Software

It is like a tree (List top of tree to bottom)

Software is not one long list of program statements but it has structure. The hierarchical organization above represents a taxonomy of structural parts to a software system.

Why Decompose?

Software Architecture - A set of high-level decisions that determine th structure of the solution

Given the size of a system, a decision is architectural if it can be made only by considering the present scope of the system


Architecture vs Design

Architectural Decisions Often Involve Compromise

Architectural Styles - Constituent Parts

MVC - Model View Controller

Fitting the Parts Together

Lecture 6 - 2/3/2017

Use Cases

Used for functional requirements analysis and specification

You can build use cases from the user stories that are written as a part of the system requirements.

Types of Actors

Initiating Actor - (Also called primary actor or simply “user”): Initiates the use case to achieve a goal.

Participating Actor (also called secondary actor): Participates in the use case but does not initiate it.

Some times it is useful to draw diagrams of use cases in order to visualize exactly how the system operates between a system of multiple users in order to visually represent and follow the set of logic and steps that are required of the system in a specific use case.

You should be able to discern the basic function of a system from a single diagram which displays the different actions, use cases, and actions of the software system.

Lecture 7 - 2/7/2017

Domain Modeling


Why Domain Modeling?

We model domains in order to understand how the software system will work

How? - we do domain modeling based on sources

Building Domain Model From Us Cases

  1. Identify the boundary concepts.
    • Software concepts that interact with our actors of the system
  2. Identify the internal concepts.

Lecture 8 - 2/10/2017

Object-Oriented Design

We create system sequence diagrams to see how objects interact with one another within the software system.

Types of Object Responsibilities

Given a use case you need to “connect the dots” between the objects in order to figure out how the system-to-be will function. Ask the questions

Characteristics of Good Design

Design Principles

Responsibility-Driven Design

  1. Identify the responsibilities
    • Domain modeling provides a starting point
    • Some will be missed at first and identified in subsequent iterations
  2. For each responsibility identify the alternative assignments.
    • If the choice appears to be unique then move to the next responsibility.
  3. Consider the merits and tradeoffs of each alternative by applying design principles.
    • Select what you consider the “optimal” choice.
  4. Document the process by which you arrived to each responsibility assignment.

Lecture 9 - 2/17/17

Note: Last lecture was cancelled.

Software Testing

Testing is Hard

Accepteance Tests


Test Coverage:

Practical Aspects of Unit Testing


  1. Create the thing to be tested, the driver, and the stubs
  2. Have the driver invoke an operation on the fixture
  3. Evaluate that the actual state equals the expected state.

Junit and Other Frameworks

Integration Testing

Software Engineering - zac blanco