Arranging the work when several of you build it

Building software is divided into large units called phases. The names and order run roughly like this.

• Requirements definition … deciding what has to be possible. Not yet talking about how to build it
• External design … deciding the face the user sees (screens and printed forms)
• Internal design … deciding the internals (what parts to split into)
• Programming … actually writing the code
• Testing … confirming it works as decided
• Operation and maintenance … keeping it running and keeping it fixed

The exam likes asking which phase a task belongs to. Tell them apart by what is being decided: what you want to do is requirements definition, what it looks like is external design, and how to split into parts is internal design.

Design being split in two is confusing at first. The dividing line is whether the user can see it.

External design decides the face the user sees: screen layouts, the order of input, the printed forms. Being visible, this is the phase where the result is shown to the user (the customer) for approval.

Internal design decides the internals: what parts (programs) the functions split into, how the data is held. The user cannot see it, so the builders can decide it among themselves.

The exam also uses stiffer wording. Software architectural design is the phase that "converts the requirements into a form expressing the top level structure and identifying the components", the entrance to internal design. Going finer, down to the processing of each line, is software detailed design.

The oldest way of proceeding is the waterfall model. As the name says, it is a waterfall: the previous phase finishes, and its deliverable is used to go on to the next. No code is written until the design is done.

Its strength is visibility. Each phase ends clearly, so progress is easy to count and easy to divide among many people.

There are two weaknesses. One is that going back is expensive. Decide something wrongly upstream and the downstream code and the manuals all have to be redone — and you usually only notice the mistake once you are downstream.

The other is that nothing that runs appears until the end. The user cannot check until it is finished, so "this is not what I imagined" surfaces last.

The ways devised to fill in the weaknesses of the waterfall come up often in the exam.

Prototyping builds a trial article early, shows it to the user and works it up after taking their impressions. It is a method for finding "this is not what I imagined" sooner.

The spiral model repeats a full turn from requirements analysis to implementation, part by part. It builds the high-priority parts first and widens the scope little by little, spiralling outwards.

The two are close in purpose but asked about differently. "Show a trial article" is prototyping; "repeat the development process" is the spiral.

Pushing the idea of repeating further gives agile development: build something that runs in a short period and show it, over and over. It values working software over thick specifications, and adapting to change over sticking to the plan.

One of its ways is scrum. There are many words, so learn them split into roles and events.

• Sprint … a short division of one to four weeks. You build and show within it
• Product backlog … a list of what you want to do, in priority order
• Daily scrum … a short gathering at a fixed time each day, sharing progress and troubles
• Sprint review … showing what was built at the end of a sprint
• Retrospective … looking back not at what was built but at the way of working itself

The names for people are fixed too. The product owner decides the contents and order of the backlog, the scrum master supports the way of working, and the developers build.

Within agile, the one that lists what to do as concrete habits is XP (extreme programming). Here are the notable ones.

• Pair programming … two people write one program, swapping roles and checking each other, so communication flows and quality rises
• Test-driven development … write the test first, then write the code that passes it
• Refactoring … tidy the internal structure without changing the behaviour seen from outside
• Coding standards … make the writing uniform so anybody can read anybody
• Continuous integration … integrate and test repeatedly rather than waiting

Refactoring is easy to get wrong, so be careful. The promise is that the external specification does not change. Change the behaviour and it is an addition or a fix, not refactoring.

A large program is built by splitting it into parts called modules. It is the same thing as pulling code out into functions and classes as you have been doing.

There are two measures for saying whether a split is good, and the directions are easy to reverse, so learn them with their reasons.

Cohesion (module strength) is how far the inside of one module gathers around one purpose. Stronger is better. With only one purpose inside, there is only one reason to change it, so a change touches one place. A module stuffed with everything gets opened again and again for unrelated errands.

Coupling is how deeply modules are entangled with each other. Weaker is better. Shallow entanglement means fixing one does not require reading the other.

Remember it as tight inside, loose outside. With both in place, the module is said to have high independence.

Coupling is not only weak or strong; the degrees have names. Weakest (best) first.

• Data coupling … only the data items needed are passed as arguments (parameters). The weakest and the best
• Stamp coupling … a whole clump of data is passed, exposing items that are not used
• Control coupling … an argument is passed to switch the other side processing, so the callee behaviour is dictated by the caller
• External and common coupling … exchange through a common (global) area, so who changed what becomes untraceable
• Content coupling … looking into or altering the internals of the other directly. The strongest and the worst

The dividing line is whether the exchange finishes with arguments alone. Arguments only is data coupling; the moment a common holding place is involved it strengthens sharply.

From here it is about the class you wrote. It is only a matter of translating into exam vocabulary.

class Dog { ... } is the blueprint, the class. What new Dog() produces is an instance (an object). There is one class but you can make any number of instances. Conversely, one instance is never made from several classes.

The relation of class to instance is the relation of kind to example. If "park" is the class, "Yoyogi Park" is an instance.

Gathering the data (attributes) and the processing (behaviour, that is, methods) into one within that class, and not letting the details be touched from outside, is encapsulation. What is welcome is that changing the internals hardly affects the users outside. It is also called information hiding.

What you wrote with extends is inheritance. A subclass (derived class) takes over the attributes and functions of the original class (the superclass or base class). The marker is that a subclass is "a kind of" the other. A lorry is a kind of motor vehicle, so it is a subclass; but a tyre and an engine are parts, which is not inheritance.

Then polymorphism: the same call behaves differently depending on the class of the other. Write speak() and a dog barks its way and a cat mews its way.

The tool that realises it is overriding: remaking a method of the same name in the subclass. The similarly named overloading is lining up methods of the same name with different argument types or counts, a different thing, so do not mix them.

Handing a design to somebody fails if everyone draws differently. So the ways of drawing were made uniform, giving UML. Learn the notable diagrams split into those showing structure and those showing behaviour.

Diagrams showing structure.

• Class diagram … classes and the relations between them. Inheritance (generalisation) is drawn here too
• Object diagram … the relations between instances rather than classes

Diagrams showing behaviour.

• Sequence diagram … exchanges between objects laid out in time order
• Use case diagram … the exchanges between users and the system, drawn from outside
• Activity diagram … the flow from one behaviour to the next
• State transition diagram … what triggers a change of state

Incidentally, extracting design information from a finished program and turning it into diagrams is reverse engineering — reverse because it runs backwards.