Chapter 4: Concept Structure

So far a 'conncept' is something vague and general.

in this chapter, how to structure the definition of a concept.

structure will clarify

- what concepts are and are not.
- a roadmap for defining concepts
- define each concept precisely

concepts don't make design problems go away, but they help to localize them by
recognizing them as specific to specific components (_ or interaction between
specific components)

a concept becomes a container for

- the behaviors it embodies
- all accumulated knowledge about its design.
- issues that have arisen on deployment
- various ways in which designers have dealt with them

Apple's Trash Concept

At first glance, the trash icon seems to offer (nothing more than) an intuitive
gesture to delete files and folders - by dragging them to trash, rather than by
issuing a more conventional (text based? ) command.

The real innovation is however not that you can move things into it, but that you
can then move things *out*. The ***purpose*** of the trash concept is not allowing
deletion but rather the undoing of deletion.

You have to be able to delete files permanently too to free space. This is done by
"emptying" the trash.

In summary, you when you want to delete an item, you move it to the trash. To
restore it, you take it out of the trash. You empty the trash when you want to
permanently delete its contents.

A way to describe concepts precisely and succinctly.

1. Name (of the concept) : (running example) Trash

2. Purpose: a pithy statement: allow reversal of deletion

3. State : organizes the components of the concept into structures.

For trash these are two *sets* (_ the sets are the 'structures') - accessible,
trashed.
'accessible' - the set of things outside trash that can potentially be moved
into it or out of it.
'trashed' - the items in the trash, which have been deleted, but not peramantly
removed.

4: Actions:
describe the dynamics/behavior of the concept.
 (KEY) describe how state is updated when the behavior occurs. e.g: when an item
is deleted, it moves from accessible to trashed.
includes any precondidions on when an action may occur
(the full description of trash includes a create action that creates the items
that are eventually deleted)

5. Operational Principle :
shows how the purpose (1) is fulfilled through its actions (4).
comprises one or more archetypal (??) scenarios
For trash: 2 scenarios
1. restoring: after you delete an item, you can restore it and then
it is accessible
2. permanent removal: after you delete an item you can 'empty the
trash' and then item will be in neither the accessible set, nor in the trash.

In a narrow technical sense, the op is not required since it just a sequencing

of actions, and any such scenario can, in theory, be inferred from action
descriptions. but for understanding (1) why the concept is defined the way it is
and (2) how it is expected to be used, the operational principle is fundamental
(pdf page 68)

therefore definition of trash is

Concept # ....

Name : Trash

Purpose : To allow undoing of deletions

State: accessible, trashed - Sets of Item

Actions:
1. create (x :item) - when x is not in accessible, or trashed, add x to
Accessible

2. delete (x : Item)

3. restore (x : Item)

4. empty ()

Operational Principle
a.

b.
 Note 43 (pdf page 306)

the operational principle can be viewed as a theorem about the concept, asserting
that the concept has some key property (Example?) or equivalently (the operational
principle can be viewed as) a generalized test case. But theorems and test cases
are used to *verify* a program or specification and are therefore secondary. The
operating principle is primary and placed front and centre to *explain* the essence
of the concept.

Thought Experiment: suppose you had to explain how a toaster works to Isaac Newton.
He sees a knob going from light to dark. a level you can press down. a button
marked cancel. (assuming connected to power etc)

You don't explain the *state* of the toaster - the cooking time (set by the dial's
position.turning the dial changes the value of this state componont. the on/off
state of the heating element. state of the timer - time remaining till ejection of
the bread slice)

You don't start with *actions* (that can be done on the toaster) - e.g that turning
the dial (re) sets the state component that corresponds to the cook time.

Instead you tell Newton what the *toaster is for* aka its *purpose*

and you tell him *how to use it* ( == its operational principle - a sequence of
actions) - e.g : you put two slices of bread in it, set the knob halfway, push the
lever down.

you can extend the operational principle to a second scenario. Set the knob too
high. Press cancel button to eject the bread when bread begins to burn.
Thus (KEY) though the state and actions together define the behavior of the concept
fully, they don't provide the key missing parts that both users *and* designers
need. The need for the concept (driven by the purpose- the why) and the
demonstration of *how* that need *is fulfilled* (the operational principle)

The operational principle comes from the work of Polanyi via Michael Jackson.
Polanyi says "the operational principle of a machine specifies how its
characteristic parts - its organs - fulfill its special function by *combining to
an overall operation which achieves the purpose of the machine"

The toaster example is based on Polanyi's observation that the laws of physics
can't (by themselves) explain the machine. This is a fundamntal difference between
science and engineering.

Engineering includes the operational principles *of machines*, and some knowldege
of physics *bearing on those principles* . Physics and Chemistry don't by
themselves describe how a given object is a machine or not, if so how it operates,
and for what purpose. (but engineering does).

Thimbleby's Partial Theorems

Harold Thimbleby says that users *infer behavioral theorems* by observing their
interactions with systems and then come to rely on such behavioral theorems. This
works if theorems are either true (and so are - most of the time- helpful to users)
or false (users recognize their invalidity)

The trouble comes with partial theorems- theorems that are true *most of the
time*, but users come to believe it holds *universally* and so will get misled one
day and get a nasty surprise

e.g : the belief that all sent messages are in the sent folder (untrue because they
can be moved into other folders)
sent folder contains only messages that were sent (can be invalidated by
moving random unsent messages into them)

For the apple macintosh trash concept, emptying the trash does not *always* remove
all files in the trash. (i.e there are circumstances in which all files are not
removed)

Operational Principles vs Use Case and User Stories

Scenarios are popular in many approaches to software development - e.g Ivar

Jacobson and his "use cases" an approach to requirements that involves scenarios in
which each the user interacts with the system as a whole and achieves some (user)
goal.

Operational Principles have a different goal - explaining the essence of the

design (?) vs (use cases) (a) desribe functionality in its entirety and (b) is
applied to specific concepts . user stories are applied at system level.

To describe a system there are often hundreds of use cases, including for abnormal
cases.
E.g:
(some) style concept elided

Use cases are often used in agile development as units of incremental development.
But focusing on one or a few usecases may lead to an implementation that cannot be
extended to the next use case.

(style concept use cases example elided)

(KEY) concepts provide a better granularity for incremental development because

they are (a) self contained (b) (KEY) largely independent of each other.

(style concept extended example stuff elided)

Note #44 Concept Formalism

The concepts in this book are described in plain English. In practice, better to
use a formal notation that is formal and unambigous. e.g: Alloy, Z, VDM, B

Concept Semantics : some notes on concept semantics focusing on concept *behavior*.

Concept purpose not so easily formalizable.
In the simplest case, a concept's behavior can be seen as a state machine. (e.g:
state machine of trash behavior. Each state is a configuraton of the accessible and
trashed sets. IntialState = both states are empty.)
transitions are create(i0), delete(i0), restore(i0), empty()

To define the concept (KEY) start with the initial state, consider each action in
turn. If the action definition is allowed in a state, you add a transition to the
state it prescribes, repeating this for each possible action. This might produce
new states. Find the outgoing transitions for any new states produced.

Transition Relations, Preconditions and Deadlock.

Mathematically the meaning of an action is a *relation*.

Given a concept *with a set of states* S, an action A with an argument drawn from
the state Y, resulting in state T has an associated relation

transition(A) subsetOf (S X Y X T). To account for multiple arguments consider

members of Y to be tuples.

The transition relation need not be total. The set of pairs (S, Y) of prestates,
arguments, for which a post state T exists is called the *precondition* of the
action. When the precondition does not hold, the action is not enabled, and may not
occur. (This is subtly different from the precondition of a function in
programming, where a function can be *called* even if the precondition does not
hold, and if this happens, anything can happen)

in any given state, any number of actions can be enabled.

(KEY) It is possible to design a concept in which a state can be reached from which
no action is enabled. This is called deadlock and is undesirable in a concept
because it means that the concept can never do anything else again.

Usually a concept embodies a collection of objects. (KEY) the lifetime of any given
object may come to an end, but the behavior of the concept as a whole continues
because the concept itself is not bounded (?).

The reservation concept, for example, handles the lifetimes of individual resources
- e.g a dinnertime slot at specific restaurant - which comes to an end when a
resource is used. But a new resource can always be added, so the concept as a whole
continues to execute (_ with new resources) and so there is no deadlock.

lots of notation elided. Alloy, other semi mathematical notation. LTL, TLA,
interprted and uninterpreted types etc.