Disclaimer

This slide deck tries to give a brief summary of the most important topics covered in my part of the course. However, keep in mind that it's not possible to condense all lecture material into one slide deck, so some things may be missing!

There are more theoretical and more practical lectures. For the theoretical ones, you should have understanding of the key concepts, but you don't need huge amount of detail. For practical ones, you should be able to apply them to sample problem or code.

Module structure (1/3)

Principles (history, open-source, principles, environment)

These lectures cover theoretical material (with the exception of "contributing to open-source" section). You should understand the key principles from the lectures.

These lectures do not follow a textbook, so your best resources are the lectures. Those are based on various books and papers, but often pick only a couple of ideas from a long book.

Module structure (2/3)

Engineering (quality,structure,errors,architecture)

These lectures cover important practical engineering practices. This includes code quality (indentation, naming, error handling) and architectural patterns. You should be able to write code that follows such patterns or find issues in code that does not follow them.

There are good online resources for some of the topics, but the lectures do not directly follow one resource, so it's best to follow lectures and occasionally look elsewhere.

Module structure (3/3)

Processes (agile, testing, theory)

These lectures are about managerial aspects of software engineering. This includes eXtreme programming and Scrum that you should be familiar with as well as testing (and the related Test Driven Development method). For testing, we also covered theory on how to design tests well, which you should also be familiar with.

You can find many more information about all those topics online and elsewhere, but you are not required to know more than what was presented in the lectures.

Key things - Code quality (1/2)

What is good quality code

We talked about naming, comments, whitespace and code structure (the idea of keeping the "happy path" simple). You should be able to point out quality issues in a code snippet.

Keeping good quality

How to keep good quality? There are social methods (pair programming, code reviews) and tools (linters).

Key things - Code quality (1/2)

Refactoring for quality

An important concept is refactoring - code modification that improves quality without changing what code does. You should know where refactoring fits in test-driven development.

We talked about two concrete examples in lectures and classes and you should know about these: "rename" (changing the name of a variable or a function) and "extract function" (move code into a new function).

Key things - Living with errors

Different application domains

We talked about approaches to errors differ for different application domains (business computing, telecommunications, computer art).

Good practices

We looked at specific practices. Why exceptions are better than returning error codes? What are the three ways of handling bad inputs (ignore, recover, fail immediately) and which might be better when?

Key things - Large software architectures

Architectural design patterns

We talked about several architectural patterns: Layered architecture (and three-tier), service-oriented (and microservices), pipeline, blackboard, event-sourcing

You should know when they may be appropriate, what are the benefits they promise and what are possible drawbacks of choosing them.

Code quality - Ticket machine software

The following snippet changes date and time of a ticket. If the ticket has a railcard, it checks whether the railcard can be used on the new date and, if no, removes it.

 1: 
 2: 
 3: 
 4: 
 5: 
 6: 
 7: 
 8: 
 9: 
10: 

public void setTicketDateTime(DateTime d)
{
  // If railcard is null, do more checks
  if (this.railcard != null) {
    RailcardService s = getRailcardService();
    // If railcard is not valid on date time, set it to null
    if (!s.isValidOnDateTime(this.railcard, d))
    this.railcard = null; }
    this.dateTime = d;
}

Code quality - Ticket machine software

Answer the following questions regarding the code snippet on the previous slide:

1. Identify one naming issue in the code snippet and one other code quality issue in the code
2. Describe one refactoring that can be used to fix one of the code issues in the code snippet
3. Propose one way of improving the code using defensive programming techniques to handle invalid inputs

Key things - Agile development

Methodologies We talked about ideas behind development methodologies and their different kinds (managerial vs. engineering, process vs. product-oriented).

Requirements and user stories We covered how to capture requirements using user stories.

Scrum We briefly looked at Scrum (i) team roles, (ii) process with backlog, planning and sprints and (iii) ceremonies, i.e., daily scrum, planning, review and retrospective.

Key things - Testing theory & tools

As part of a process We talked about Verification vs. Validation and roles testing can play in development processes (V-model, TDD)

Mathematical theory We discussed white vs. black-box testing, equivalence class partitioning and boundary value analysis.

Testing in Java We covered basic unit tests (JUnit), testing of I/O code (mocking), property-based testing for covering larger number of cases (jqwick).

Requirements - Ticket machine software

The user of the machine should be able print previously purchased tickets or purchase tickets. When purchasing tickets, they should be able to choose origin and destination, select a date and time for travel, select a railcard and pay for the tickets, either using card or cash.

1) Write a user story for a regular passenger
2) Write a user story for a student with railcard

Equivalence class partitioning - Ticket prices (1/2)

Students with student card get 25% discount on any fare. Those with network railcard get 20% discount, but only on off-peak trains (after 10am or weekends).

1) What are the equivalence classes for computeDiscount? 2) Give best test inputs using boundary value analysis

Code showing the implementation on the next slide.

Equivalence class partitioning - Ticket prices (2/2)

 1: 
 2: 
 3: 
 4: 
 5: 
 6: 
 7: 
 8: 
 9: 
10: 
11: 
12: 

public float computeDiscount
    (bool isStudent, bool hasNetCard, DateTime time) {
  if (time.IsWeekend || (time.HourOfDay < 10)) {
    if (isStudent) return 0.25;
    else if (hasNetCard) return 0.20;
    else return 0.0;
  } else {
    if (isStudent) return 0.25;
    else if (hasNetCard) return 0.0;
    else return 0.0;
  }
}

Property-based testing - Sensible prices (1/2)

Very Sensible Train Company (VSTC) sells tickets so that if you travel from place A to B via C and C is on the way between A and C, then the ticket from A to B costs the same as a pair of tickets from A to C and C to B.

1) Use property-based testing to ensure this actually holds!

Code showing a stub of the test is on the next slide.

Property-based testing - Sensible prices (2/2)

 1: 
 2: 
 3: 
 4: 
 5: 
 6: 
 7: 
 8: 
 9: 
10: 
11: 
12: 
13: 
14: 

@Property
boolean canTravelVia(
  ForAll @IntRange(min=0, max=99) int start,
  ForAll @IntRange(min=0, max=99) int end,
  ForAll @IntRange(min=0, max=99) int mid
) {          
  // Assume 'stations[i]' gives a station name at index 'i'
  // Assume 'ticketPrice(start, end)' gives price
  //   of a journey from 'start' to 'end'
  // Assume 'isBetween(start, end, mid)' is true
  //   if mid is between start and end

  return // ????
}

Key things - Origins and history (1/2)

Why is building software hard?

In what ways are "software systems" different than "algorithms" and why is this making them hard to build?

You can have a quick look at the No Silver Bullet essay, which was mentioned in the lecture, but the summary in the lecture is sufficient.

Key things - Origins and history (2/2)

Software industry crises

The lecture discussed three "crises" that were caused by some developments in the industry (typically societal changes leading to the need to build different kinds of system). Those are 1950s Labour crisis, 1970s Software engineering response and 1990s Application crisis.

You should know what caused these crises and what tools or methods were response to those.

Key things - Open source software (1/3)

History and issues

The lecture compared the culture of "commercial software" and "free software" and discussed some of the issues in open-source community such as sustainability and code of conducts.

You should know that these issues exist and give one or two ways in which the principles behind commercial and free software differ.

Key things - Open source software (2/3)

Different licensing models

We compared a number of licensing models, namely the free software model (free as in freedom), dual licensing model (pay with either money or code), consulting and corporate models (free as in free beer).

You do not need to know any license details, but you should be able to say the differences between GPL and MIT/BSD/Apache. You should also know how different models are typically funded.

Key things - Open source software (3/3)

Contributing to open source

This is a more practical part of the lecture. We talked about how to contribute to open-source software, looking at consistent coding style and minimal, complete, verifiable examples for reporting issue. You should also be able to write code in consistent coding style.

Key things - Software engineering principles (1/3)

Complexity of software systems

We looked at the key points made by Fred Brooks - you should know what the terms "accidental" and "essential" complexity mean.

We also looked at reasons for why building software is hard. You should recall the problem with "non-repeated digital systems" and classification of programs (S, P, E-programs).

Key things - Software engineering principles (2/3)

Environment of software systems

We discussed why are some systems (such as anti-ballistic-missile defence systems) hard to build and discussed characteristics of the environment that make building software hard.

You should remember the conditions under which a system can be "mastered" (what kind of systems in what kinds of environments).

Key things - Software engineering principles (3/2)

Three key principles of software engineering

You should remember the three key principles discussed in the lecture:

First, why is building "programming systems product" 10x harder than "program". Second, why we cannot expect order of magnitude improvement in productivity and, third, why adding manpower to a delayed project makes it later.