Notes from Lecture 1 – Goals and skills
1 What is the course about?
The goal of the course is to lift your software development skills from working with small programs (think EECS111) to designing and building software systems.
Supports configuration for adapting to the requirements of its environment;
Comes with a start-up phase for setting up the connections between its different pieces and its environment and preparing for interaction with its users;
Maintains a stable operational phase even under adversarial load;
Supports graceful termination even under irregular conditions.
Let its users configure whether players use a GUI or a textual interface, or whether the rules checker will use this or that version of the rules;
Come with a start-up phase of popping up its GUI, opening ports to listen for connections from remote players and setting up everything users will need to interact with the game;
Maintain an operational mode where users can register, initiate and play games etc even when some users attempt to cheat or connections drop;
Terminate without damaging the host environment or the users’ environment (those are not always the same ...) both when termination is intentional or unexpected.
The above example illustrates that building a software system involves dealing with dimensions of design complexity that go well beyond those you encountered when writing small programs. To make matters worse, decisions that developers make as early as when the system is still a prototype such as the programming language usually stick around. See for instance all the legacy COBOL code in bank software systems. It is still there under layers of wrappers of C++ and Java.
So how can you cope with this greatly complex setting? You need to develop a set of skills that will help you take good care of your code as it grows from a a prototype to a full fledged system.
2 What skills the course aims to develop?
Software construction focuses on three kinds of skills: technical, process and personal skills.
Top-down design from goals to components;
Bottom-up construction from components to systems;
Modular development;
Design of interfaces and protocols;
Integration of (heterogeneous) components in a system;
(continuous) Testing with systematically constructed test harnesses.
What is the goal of our system?
What are the actors-pieces that are involved in our system and how do they relate to it (internal/external)?
What are the use cases of the system?
Focusing on one use case (the most important), how do external actors interact with the system and how this external interaction triggers internal ones to complete the corresponding workflow?
How can we represent the information that moves between the actors of the use case as one or more components and what is their interface?
Can we implement these components?
Can we gain confidence that each component in separation is correct (e.g. unit testing)?
Can we integrate the components in an operational prototype?
Can we gain confidence that the integration is correct(e.g. integration testing)?
What is the next use case we should analyze?
Our goal is to implement a system that allows to automate the sales, inventory and accounting operations of the store;
The actors-pieces include: customers(external), sales persons (external), inventory employees (external), accountants (external) registry(internal), printer(internal), inventory(internal), bank (external)
Some uses cases are: a customer wants to buy some products, inventory employees want to make orders to restore the storage, the accountants want to inspect the books, balance them and pay bills;
We will focus first on the purchase-of-products use case: the customer brings products to the registry, the sales person rings them in, the customer swipes credit card, the registry contacts (i) the bank to get acknowledgment for available funds and charge the customer’s account; (ii) the printer to output the receipt and (ii) the inventory to alert it that the purchased products have been removed from the shelves of the store;
One component involved is a shopping cart component that collects the information of all the products that customers bring to the registry and offers an interface to add a product, remove a product, ask for total value of its contents, and pay for the products it holds;
We implement and unit test the shopping cart and each other component;
We connect the components and test their connections;
We move to the next use case.
Personal skills are necessary for a software developer as software development is only partly a technical discipline. A big part of software development is communicating with other people. First developers have to communicate with each other since they work mostly in teams and often inherit code or use components that others have built. Moreover they have to communicate with their managers to explain them what they have built, requirement engineers to understand what the clients need and QA engineers to understand issues with their code. Put differently a software developer needs to be able (i) to explain effectively their code both at a high-level and with all the nitty-gritty details; (ii) provide constructive feedback to others code on the fly for a problem they understand well and (iii) be open to continuous critique.
This last part is particular important as a developers ego can be an important obstacle to delivering successful artifacts. Programmers should disassociate themselves from their code and examine it and let others examine it as if it was a newly found artifact from the depths of history.
Members of a team of two who will practice pair programming and learn to communicate (and cope) with a partner on a daily basis;
Codewalkers who will explain their code and especially its bugs, issues and imperfections to your peers and be open to accept continuous constructive criticism;
Panelists who will have to understand and provide constructive feedback to code they see for the first time;
Scribes who will works as a team to compile a succinct memo with feedback for the codewalkers.