BorrowBox, and how to answer a COMP 410 question

BorrowBox — the system this course thinks with

Every worked example, figure and model answer in this course runs on one system, because an examiner rewards a concrete example and inventing a fresh one under a three-hour clock is expensive. BorrowBox is a neighbourhood tool library. Members browse and reserve a power tool in a mobile app; a reservation holds one specific copy for two hours; the member walks to a locker bank on the high street and opens a door with a one-time code; they return the tool to any locker; a librarian inspects it, grades its condition and returns it to circulation. Late returns attract a fee, damage is reported, and a copy can be taken out of service.

Learn its cast now, because it recurs for thirteen modules. The actors are Member, Librarian and Depot Admin, plus two external ones — the Locker Controller and the Payments Gateway. The things that matter are Member, Reservation, Tool, ToolCopy, Locker, DamageReport and LateFee. Two properties make it a good exam subject: it has a physical, irreversible failure mode (a door opens, or it does not, in front of a member standing in the rain), and it depends on one external hardware vendor you do not control. Those two facts will supply the risk, the security, the testing and the architecture examples for the rest of the course.

The five-beat definition answer

A definition question is worth seven marks and asks you to define and explain a term as well as provide examples or more detailed information. A single crisp sentence scores badly; so does two pages of context with no definition in it. The shape that earns the marks has five beats:

1. Name the category. Is this a measure, an activity, a technique, a document, a model? One mark, and it frames everything after it.
2. Give the definition, with its load-bearing qualifiers intact. Two marks — and the qualifiers are usually where the marks are hiding.
3. Place it. What it belongs to, what it complements, what it is assessed by. One mark.
4. Elaborate. The internal structure: the categories, the levels, the steps, the list. One to two marks.
5. Give a concrete example, carried far enough that the concept is visibly doing work. Two marks.

A definition with no example caps at roughly five out of seven no matter how well written it is. That yields a technique: write the example first, in note form, then build the definition around it. It guarantees the two easiest marks and it stops you committing to a definition you cannot actually illustrate.

The four-beat compare answer

Six of the questions are short answers worth ten marks each, and most are compare/contrast: "X and Y are related but fundamentally different — explain both and how they differ." The shape is:

1. Define both terms crisply — about four marks, two each.
2. Say how they are similar — about two marks. This is asked explicitly and it is the most-skipped part of the paper.
3. Say how they differ, on named axes — about three marks. "X is bigger than Y" is not an axis; "X is intra-component, Y is inter-component" is.
4. Give one divergent example — a case where one holds and the other does not. One to two marks, and it is what separates a 7 from a 9.

The failure mode is answering half the question: defining both and never comparing, or comparing without ever defining. Budget the page before you write — two paragraphs, one per pair of beats.

The twelve-mark thinking answer

One question applies the course to a real project. Its marks split roughly: two for framing the project and naming the attributes that drive your decision; four for applying the named concepts precisely, with correct terms and correct definitions in passing; four for the argument — why this, why not the alternatives, and what it costs you; and two for acknowledging a limitation, a residual risk, or the condition under which you would change your mind. The failure mode is a chapter summary with the project name sprinkled through it. Marks come from decisions traceable to attributes.

Worked example — "define an umbrella activity", badly and well

Badly. "Umbrella activities are things like quality assurance, risk management and configuration management that happen during a project." That is true and worth about two marks. It names no category, keeps no qualifier, places the term against nothing, and has no example.

Well. "An umbrella activity is one of the two kinds of activity in a software process framework — the kind applied throughout a project rather than at one point in it, whose purpose is to let a team manage and control progress, quality, change and risk. It complements the five framework activities (communication, planning, modeling, construction, deployment), which are stages of work; umbrella activities are bands drawn across all of them. Eight are typically named: project tracking and control, risk management, software quality assurance, technical reviews, measurement, software configuration management, reusability management, and work product preparation. On BorrowBox, configuration management is plainly not a phase: the requirements model is baselined during modelling, the locker firmware image is a controlled item during construction, and the change authority still meets during deployment when a vendor patch shortens the token window."

Same knowledge. Five beats instead of one, and an example that could only be written by someone who had thought about a real system. That gap — between knowing a term and being able to produce it — is what the next twelve modules are for.