bon

Seamless Object-Oriented Software Architecture
Analysis and Design of Reliable Systems
by Kim Waldén and Jean-Marc Nerson

Note:
 Walden.
Note:
 Marc's comments.

p 11
Contrary to the somewhat resigned attitude found also in many
object-oriented camps about the attainability of massive reuse, we
claim that this is indeed the major goal of the technique.

p 17
To promote reuse and achieve true seamlessness, the core elements of a
notation for analysis and design should represent concepts that are
directly mappable not only to, but also from, an executable
object-oriented language.

p 19 Typed interface descriptions
What many analysis and design approaches fail to recognize is that
static typing not only permits early type checking and implementation
efficiency - it is also an essential aid for system specification.
Assigning types to entities is really classification, which increases
the information content of a set of interface descriptions
considerably.

p 22 Simplicity
Citation from Antoine de Saint-Exupéry [Terre des hommes, 1937]:
"It seems that perfection is reached, not when there is nothing more
to add, but when there is no longer anything to remove."

p 32 System charts
There are [many] subtle cases where our cultural background makes it
all too easy to automatically assign meaning to words and symbols also
in contexts where we are not supposed to.

p 52 The BON predicate logic
Replacing so-called defensive programming by clearly defined
responsibilities and a large number of executable assertions is
perhaps the most generally efficient way available today for reducing
the cost of test and error repair.

p 75 Links involving generic suppliers
One characteristic of genericity is that it is generally not possible
to conclude the client dependencies of a generic class by simply
inspecting its interface (and possibly private features), as can be
done with non-generic classes in a typed environment. The information
needed is distributed among the clients, and the dependencies are
therefore deduced by the supporting compiler environment.
[...] the BON notation does not support all possible uses of
genericity. [...] a very detailed graphical notation would require the
target language to be fixed.

p 125 What is problem and what is solution?
Physical objects in the problem domain, which many books recommend as
a starting point, are often too special to be suitable as classes at
the highest level in the resulting analysis model.

p 127 Planned vs. accidental reuse
[I]f all reuse were planned beforehand there would not be any point in
calling it "reuse", since it would be plain usage. [...]
Second, the fact that the word reuse has a flavor of unplannedness
about it is no coincidence, but an important strategic point. The
reason to move from traditional to object-oriented techniques is not
only to get more flexibility for building families of abstraction from
scratch, but also to get out of the straitjacket of deciding too much
too soon.

p 131
Routine verbosity always hide relevant information.

p 135 Roles of analysis objects
Moving to a computarized solution usually opens up entirely new
possibilities.

p 136
Object-oriented abstraction supports free classification, and it
must remain free if we are to take full advantage of its potential.

p 138 Several levels of interface
For example, assume we have a library metaphor offering the mental
picture of a set of books [...]. The internal system model actually
handling the books may view them differently -as sortable objects, as
copyrighted material, as stock items of certain size and weight, as
assets with certain values- but the users view them as books.

p 141 System usage
[W]hen the requirements (as is usually the case) are vague and
incomplete, it may simply not be cost-effective to spend a large part
of the project budget on the systematic elaboration of many volatile
use cases.

p 196 Cohesion and coupling
[One] principle (mentioned already in 1968 in a short essay by Larry
Constantine) is to maximize cluster cohesion and minimize cluster
coupling.
Maximizing cohesion means putting classes which collaborate closely in
tha same cluster, while minimizing coupling means having as few
dependencies as possible between classes in different clusters. The
rationale behind the principle is obvious: a cluster defines a local
context in some sense, and it is desirable that local contexts can
evolve in parallel without interfering too much with each other.

p 206 Design by contract
The general feeling of distrust [...] has led to a desperate style of
blind checking known as defensive programming, which leads to even
less understandable software with more errors because of the
complexity introduced by the added redundant code.

p 207
Usually the context will lead the client to know without testing that
the precondition is indeed fulfilled, something which is never true
for the supplier.

p 217 Class interface documentation
Two important tools are needed to produce useful class interface
documentation from class text: a class abstractor and a class
flattener.

p 222
Trying to guard against all types of change [...] will only lead to
weak design or no design at all [...] Therefore, minimizing the number
of client dependencies for each class by systematically encapsulating
all collaborative behavior needed in just a few supplier classes, as
for example advocated by the Law of Demeter, represents a driving
force towards less consistent global design. Instead of grdually
leading to a system in which many classes trust a small number of
strong abstractions enough to call them directly, the evolution tends
to favor many weak abstractions each calling only a small number of
other weak abstractions.

p 235
[W]e will deliberately accept incomplete specifications and will see
that despite the fuzziness of our initial set of requirements, we can
still organize our development around a few simple abstractions.

p 288
[T]here is no objective reality. Models only exist in relation to what
you want to do with them.

p 291 Figure 11.1 Various persistency schemes
1. extended object creation mechanism
2. extended type declaration of entities referring to objects
3. extended class declaration mechanism
4. common persistent class ancestor
5. persistent container

p 292 Two principles regarding persistency
Principle 1
  There should be no syntactic distinction between persistent and
  transient data in terms of how they are defined and used.
Principle 2
  The persistent object model should be designed as a seamless part of
  the full static model.

p 294 Integrity constraints
- Domain integrity refers to type checking between the values used in
  query expressions and the declared types of the corresponding
  entities.
- Referential integrity has to do with the consistency of references
  between schema elements
- User-defined integrity [...] is part of the object-oriented data
  description.