Lecture 3: Analysis and Design Principles

Today

• Joanna from Business School

• Tell a writing story.

• What does readability mean? two functions, one meaning.

Lecture

In this course, we will practice the most fundamental aspects of software development, borrowed from across the spectrum of ideas.

The Abstract Idea

If these principles bring back memories of the design recipe for programs, especially the one for interactive programs, you are a reflective programmer and on your way to growing into a sw architect.

Step 1 Understand the system: its elements and its context.

Start from a thesis and formulate it as a concise phrase. Collect ideas around this phrase, going further and further away from the core, until you know that every extension of this "spiral" points to elements that are way beyond the desired software system.

Now you have a complete picture of the elements of the desired software system and its context.

Draw a boundary between the context and all the pieces that belong to the system as a whole.

Step 2 Find the stimuli and determine appropriate responses.

Software systems are inert. Some event activates it. You know some examples: left swipes, right swipes, mouse movements, key strokes, temperature readings, changes to a camera’s lens, etc.

The event takes place in the context and a “message” about event crosses the boundary between the context and the system. Once stimulated, the system computes. The goal of the computation is to compute a response. Sw Devs call the path from the stimulating event to the effect of the response on the context a use case. (They also speak of a stimulus-response system.)

Your job is to find all—or at least all critical—use cases.

Step 3a Identify software components and their possible interactions along use cases.

Every use case relies on some forms of data and consists of distinct computational steps. The two aspects give us insight on what the key components of the software system are and how they interact. Distinct use cases may use the same component, sometimes in the same way, sometimes in other ways.

A component encapsulates knowledge; interactions between components are about knowledge exchanges, as in, one components “knows” some information that another one needs to make progress.

The word “interface” here is not to be confused with Java’s interface; there is only a loose connection. You will represent knowledge as data. The demand for interactions dictates the shape of the interfaces of the components.

Step 3b Identify different computational concerns.

The components for one and the same use case address different concerns. Separating out different concerns is important because each of them may evolve in different ways over a system’s lifetime.

Step 4 Order the use cases according to importance.

Some uses cases are essential. Others are cosmetic. And the rest of them exists somewhere in between. The ordering should take into account the different concerns; logical concerns should trump communication concerns.

Build the components for the most important uses cases first. Remember to build the components in a bottom-up manner. That is, start with those that can be tested independently, then build the components that rely on the first batch and so on.

Step 5 Iteratively refine the prototype.

Once a prototype can be demoed and satisfies “customers” (your boss, actual customers, focus groups, etc), it is time to deal with additional concerns for existing test cases or additional use cases.

Example: Grocery Store

Imagine a small grocery store that wants to deploy an “information management system” to improve the efficiency of its operation.

This problem is old, basically solved (though improvements will come). Over the past three decades, sw devs have injected software for “points of sale” stations (cash registers), inventory management, accounting, etc. You have been to grocery stores and have interacted with some of that kind of software. Now let your imagination roam.

Example: Game System

Probably skip

Imagine a small circle of hacker friends who play the Take 5 game. They have decided to automate it so that they compare their AI hacking skills. They settle on some programming language and decide to implement a framework into which they can plug their AI players and run games and entire tournaments.

Then they decide that they actually hate the chosen language. Nobody wants to program a player in it. They are okay with writing whatever software is needed to make it all work out. Otherwise they will use TCP to connect independent processes to run their players and communicate with each other. While they are at it, they decide that they are going for a distributed version, allowing them to connect their players from home without leaving the comfort of the great indoors.