Page-6

A refinement is a relation between two descriptions, an abstract model and a concrete model. Everything described in the abstract is still true about the concrete, provided you re-interpret the concrete terms via some mapping that Justifies the refinement.

A refinement does not imply a top-down development sequence!

To help un-cross your eyes, here is a little quote from the book:

Suppose you ask a hotel for "a room with a nice view, for five people; it should not be noisy in the morning" - an abstract requirement, A.

The clerk responds by assigning you "a deluxe penthouse suite overlooking Niagara Falls; its three bedrooms each have two double beds; and it has a built-in Jacuzzi and gym" - a realization (or concrete model), B.

B is a refinement of A - that is, it conforms to A, provided the hotel can justify that (1) overlooking Niagara Falls constitutes "a nice view", (2) the humble penthouse suite can suffice as "a room"; (3) the six double beds will serve to accommodate your party of five; (4) the roar of millions of gallons of water will, in fact, be a soothing background whisper; (5) the built-in Jacuzzi and gym do not conflict with anything you've asked for.

Note that there are mappings involved in the justification: overlooking the falls maps to a nice view; penthouse suite maps to room; and so forth.

Many hotels will falsely justify a variety of refinement claims. Similarly, many pieces of code cannot be justified as meeting their interface specs; many delivered software systems fail to meet requirements; and many requirements fail to meet the users needs. Done sensibly, refinement can serve as the basis for lots of good stuff(tm) in a simple and systematic way, addressing the above problems without requiring the use of formal methods.

In particular, a refinement:

	May be validated by examples.
	Forms the basis for test: each test case, written at the level of the concrete model (or implementation), must meet the corresponding specification which was written in terms of the abstract model, when mapped via the refinement mapping.
	Is the focus of design reviews: if that is the specification of what you were supposed to build; this is your design solution. Show us how your design solution maps to (meets) the specification.
	Forms the basis of traceability from business level to code
	Can, in extreme cases, be used for formal verification of correctness

Associated with any refinement is a corresponding architecture, which defines the concrete model constructs (i.e. design or implementation elements) and the rules for applying those constructs to meets any requirements. The architecture may be more or less fully defined; here are 3 interesting points in the spectrum:

	No architecture: the design emerges from pure creativity and there are no standard or recurring patterns, rules, or uniformities recognizable in it. Justification, inspection, and testing has to cover each part of the design as a new and unique piece. Too much software is done this way.
	Some constraints on the design: the architecture recommends, prescribes, or prohibits certain usages of standard design and implementation elements and patterns. A given design can be shown to conform to (or violate) that archtiecture as specified. To the extend there are resulting uniformities in the design, we have reduced the burden of justification, inspection, and testing. Some software has clearly defined architectures that are visible in the design and implementation.
	Fully specified architecture: the rules about design are so completely determined that you could write a compiler to translate from the requirements to the corresponding implementation.