Design has to start from something. Here the starting point is described by a
mnemomic acronym:
- |-PQRST.
This is short for Purposes, Qualities, Realitites, Techie things, and Systems.
Here is a formal description:
- PQRST::=following
Net
- S::=Sets, Universe of systems,
- s0::S=Current system,
- P::@S=Systems that do everything the client wants,
- Q::Sets,set of qualities, including cost, delivery time, reliability,
etc,...
- R::@S=Systems with objects modelling the relevant part of the real world,
- T:: @(@S>->@S), Techniques, tools, technology, teamwork leading to changes in systems
(End of Net)
Design presumes that the PQRST are already known well enough to proceed. However,
in the process of design any of PQRST may change. It is useful therefore to
maintain a trace of the connection between conclusions and the PQRST that
lead to them[Dasgupta91][Gravell90]. In USA DoD projects this traceability
is a mandated requirement.
Notice that (in theory) P can be expressed as
- (1): P=&\Pi
where \Pi:@@S=Set of partial purposes (use-cases or functions or stories).
Typically the current system 's0' satisfies some of the purposes of the
system, but not all of them:
- (2): For some \pi :@\Pi ( s0 in &\pi ~ P ).
Indeed for any system s:S, we can define
- \pi(s)::={ p:\Pi || s in p }.
Notice that since this is a model of systems rather than a model of designs,
specifications, and implementations it is not natural to make a model of the
relation (1st) implements (2nd). Instead the set of systems that are in P
and/or R may be described by a separate universe of documentation and the
(1st) implements (2nd) connects systems with their documentation. Thus a
hierarchy of refinements may or may not exist between documentation, but
between systems. Loe Freijs has presented an interesting theory of this
relation and the structure of designs[ Freijs93].
Notice that much of the published information on software development
is about the T factors. These define the limitations on what the software
development team can do to produce a better system. Here are some of
the limitations that are subsumed under the T factors:
Net
- (resources): tools, environments, languages, training, people, work places, ...
- (rules): standards, architectures, methods, scripts, processes, procedures, ...
(End of Net)
My focus here is on the
essence of the engineering ethic: making something more effective.
- (above) |- (3): For t:T, t in @S->@S -- map sets of systems into new possibilities,
with some unpredictability.
- (above) |- (4): For all t:T, A,B:@S, t(A) | t(B)==>t(A | B).
- (above) |- (5): For all t:T, A,B:@S, if A==>B then t(A)==>t(B).
By Knaster-Tarski Theorem
[Knaster29]
- (above) |- (6): For all t:T, some F:@S, t(F)=F.
One T is doing nothing(Id(@S)). The T's available to us are a subset of all
possible changes that might be made, and if we can carry out two or more
changes then any sequence of them is also a valid change. So we can
assume that we have a monoid of T's
- |- (7): (monoid)(T, o, Id(@S))==>(@S, o, Id(@S)).
- (7) |- (8): Id(@S) in T.
- (7) |- (9): for t1, t2:T then t1; t2 in T.
Certain operations annihilate the system that they operate on, in the sense
that there are maps in m:@S->@S such that for a given A:@S, m(A)={}. These are
not useful techniques and so we suppose these are not part of those we might
apply,
- |- (10): For all t:T, not {} in post(t).
Abreviation
Define an abbreviation for the special case of applying a change to a single
system rather than a set of them:
- t::S>->@S=map[s:S](t({s})).
A technique can change the purposes that a system satisfies:
Fot t:T, \tau(t)::=rel[ \pi:@\Pi, \pi':@\Pi] (for all s:\pi (t(s) in
\pi').
. . . . . . . . . ( end of section Properties of the T's) <<Contents | Index>>
The values are additive and associated with the qualities[Von Neuman &
Morgenstein].
- v::(S|T)>->(Q>->Real)=value/costs of various systems and changes.
Assume that costs and qualities accumulate as successive changes are made.
- linear::@= v in (monoid)(T,o,Id(@S))->(Q>->Real,+,0).
- V::=set of satisfactory values::@(Q>->Real).
- f::=objective function::(Q>->Real)>->Real. [Operations Research]
A triple in S><T><S can model a particular change to the system, and can have
a value associated with it by:
- For s1:S, t:T, s2:t(s1), v(s1,t,s2)::Q>->Real=v(s2)+v(t) - v(s1).
- conflict_free::@,
- |- (11): conflict_free=( if f(x)>f(y) then for all q, x[q] >= y[q] ).
- ??{Arrow's theorem implies real projects will have conflicts}?
- ??{model of decision making see Cardenas-Garcia & Zelkowitz 91.}?
We have an induced relation between systems:
- For R:@(Real,Real), R::@(S,S)=R mod (v;f).
- (above) |- (12): For s1,s2:S, R:@(Real,Real), s1 R s2 = (s1.v;f) R (s2.v;f).
- G@S::=Global optima::={s:S || for all s1:S( s >= s1)}.
The Travelling Salesperson Problem demonstrates that finding an optimal design
is an NP-complete problem. The Busy Beaver problem for Turing Machines is an
optimization problem as well (longest time), so it is clear that some
Optimization problems are unsolvable.
- (above) |- (13): G={s:S || for all s1:S(f(v(s))>=f(v(s1)))}
If we can treat S as a topological space with
- near::S->@@S, near(x)::=The neighborhoods of x,
- L::=Local_optima::@S={s:S || for some N:near(s), for all n:N (s>=n)}.
Simon's Satisficing heuristic - good enough now, is better than the best
never[Simon 69, Dasgupta 91].
- F::=feasible systems::@S.
- |- (14): F==>&{R, P, &[ q:Q]{s1 || t:T(s1 in t(s0) & v(s0,t,s1)(q) in V(q))} }.
- For s1:S,p:PerCent, safe_steps(s1,p)::={ t:T || for (p%) s2 in t(s)( s2 in P &
R & s1./<) }
A solution is stable with respect to a given quality if all changes can make
it worse.
- stable_wrt(q)::= { s0:S || for some t:T, s1: t(s) ( v(s0,t,s1)(q) < 0 )
}
By analogy with Parieto's economic analysis there is probably a system from
which all changes decrease some quality: