Mini-review: Seamless Object-oriented Architecture

Contents

Review

I ran into postings by one of the authors in comp.object, and was enthusiast about his goals: Well, the book is clever, technologically up-to-date, and pragmatic: alltogether applicable.

My enthusiasm however diluted progressively after the first chapters, in the details of the method and the notation, which however probably better than what I have seen so far (Coad/Yourdon, Rumbaugh, Booch, and yes, including OMT++) didn't manage to convince me that a method would be more of a help than of a burden.

In short, I can recommend to read all the part I and the chapter 6.

Posting by one of the authors

BON promotes the following ideas:
  1. Seamlessness through pure object-oriented concepts. Most other published O-O methods are hybrids which include ERD diagrams, state/transition diagrams or data flow diagrams as part of their standard notation. This breaks the seamlessness, keeps the barrier between specification and implementation, and prevents large scale reuse. (Most O-O methods today hardly even mention polymorphism and dynamic binding, but only concentrate on the simple encapsulation part. This is not enough.)
  2. Software contracting.
    A software components industry requires well specified and correct products. We believe the Design by Contract paradigm invented by Bertrand Meyer is absolutely crucial for increasing software quality and changing the general attitude of software designers and programmers. BON emphasizes the contracting part and includes special notation for it. Again, other published methods at best mention specification by contracting, but do not give it the attention it deserves.
  3. Typed interface descriptions.
    Static typing is not only a means to generate more efficient code or catch certain types of implementation errors. It is just as much an aid for classification and precise specification. Instead of relying on ambiguous naming conventions, important information can be spelled out exactly. Also, any kind of formal specification becomes nearly impossible to use with an untyped notation.
  4. Scalability.
    To be useful in real-life situations a notation must scale up from the simplified text book examples. We need views on different levels of detail, and with different aspects emphasized. BON uses recursive clustering to achieve a scalable notation; all graphical elements used have both an abstracted and an expanded form. By selectively abstracting or expanding various parts in a system, many different views can be created.
  5. Simplicity and space economy.
    BON takes a minimalistic view both regarding the number of notational elements and the space they occupy. For example, we only use two basic relations: inheritance and client/supplier (the latter with variants for aggregation and shared resources). These relations are then generalized to also cover relations between clusters and classes/clusters (with clearly specified semantics).
    To get any kind of overview, a user needs to be able to see more than just a few classes on one page.
  6. Basis for intelligent case tools.
    We believe there is a potential for much more automatic support in object-oriented case tools (and also a much greater need, because of the higher compression of information in O-O systems).
    With typing and contracts, tools can be made much more intelligent, whereas with untyped notations things are pretty much limited to pure textual browsing, since there is simply not enough semantic content in the descriptions.

BON keeps the static and dynamic aspects of modeling separate. Instead of using state/transition diagrams for the dynamic part, (which in most cases has no natural mapping to and from the eventual implementation anyway), the BON dynamic notation is designed to describe scenarios with message passing between objects and thus serve as a complement to the static model both for finding classes and for checking that a proposed static architecture will indeed be able to fulfill the required behavior.

Kim Walden
Enea Data AB, Sweden
[email protected]

Excerpts

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
Reviews ToC
[email protected]
Last modified: Sat Apr 3 10:29:47 EETDST 1999