From the book Bon By Walden and Nerson
The control structures
of languages like Pascal and C embody abstractions that the assembly
programmers were already using mentally (often occurring as comments in some
pseudo-Algol notation), so the big payoffs were immediate. When the tedious
and error-prone translations of these constructs into sequences of machine
instructions were no longer needed, work could proceed as before, only much
faster.
pg 10 Fortunately, in recent years a very promising method has been proposed to
bring elements from the research fields of abstract data types and formal
specification into standard use in software engineering. This is the theory of
software contracting [Meyer 1992c]. The idea is to use assertions to define the
semantics of each class. The prerequisites and resulting behavior of each
operation are specified through pre- and postconditions, and the overall class
consistency through the class invariant. These semantic specifications then
form the basis for a contract between each class, the supplier, and all classes
using its operations, the clients.
Many existing methods for analysis and design, probably the majority, include
either data modeling using some variant of the entity−relationship approach (ER
modeling [Chen 1976]) or finite state machines (FSM modeling), or both, as a
significant part of their high-level system description.
With FSM modeling, the impedance mismatch is obvious
since there is no easy mapping between the state transition graphs and an
eventual implementation (unless we actually model every object as a state
machine, thereby giving up all abstractional power of the class concept).
Consider the entity
EMPLOYEE and the concept of being the most popular person in a service
department. Clearly, being most popular is a personal property, but modeling it
as an attribute of EMPLOYEE may be quite wrong from the system’s point of
view. The employee abstraction may not know about its condition, and the only
way this knowledge will manifest itself may instead be as a combination of
attributes of other entities, perhaps STATISTICS and CUSTOMER_POLL.
BON has been designed to follow a different track. Rather
than trying to include concepts from traditional data modeling or the so-called
structured techniques with all their accompanying drawbacks, a more fruitful
alliance is sought: the combination of object-oriented flexibility with the clarity
and expressive power of strong typing and formal contracts between classes.
p. 17 BON has been designed to follow a different track. Rather
than trying to include concepts from traditional data modeling or the so-called
structured techniques with all their accompanying drawbacks, a more fruitful
alliance is sought: the combination of object-oriented flexibility with the clarity
and expressive power of strong typing and formal contracts between classes.
Formalisms from other fields, which are often adapted and used as part of
proposed object-oriented analysis and design methods, such as state transition
diagrams, process diagrams, Petri nets, entity−relationship diagrams, data flow
charts, etc., are therefore not addressed in BON.
of languages like Pascal and C embody abstractions that the assembly
programmers were already using mentally (often occurring as comments in some
pseudo-Algol notation), so the big payoffs were immediate. When the tedious
and error-prone translations of these constructs into sequences of machine
instructions were no longer needed, work could proceed as before, only much
faster.
pg 10 Fortunately, in recent years a very promising method has been proposed to
bring elements from the research fields of abstract data types and formal
specification into standard use in software engineering. This is the theory of
software contracting [Meyer 1992c]. The idea is to use assertions to define the
semantics of each class. The prerequisites and resulting behavior of each
operation are specified through pre- and postconditions, and the overall class
consistency through the class invariant. These semantic specifications then
form the basis for a contract between each class, the supplier, and all classes
using its operations, the clients.
Many existing methods for analysis and design, probably the majority, include
either data modeling using some variant of the entity−relationship approach (ER
modeling [Chen 1976]) or finite state machines (FSM modeling), or both, as a
significant part of their high-level system description.
With FSM modeling, the impedance mismatch is obvious
since there is no easy mapping between the state transition graphs and an
eventual implementation (unless we actually model every object as a state
machine, thereby giving up all abstractional power of the class concept).
Consider the entity
EMPLOYEE and the concept of being the most popular person in a service
department. Clearly, being most popular is a personal property, but modeling it
as an attribute of EMPLOYEE may be quite wrong from the system’s point of
view. The employee abstraction may not know about its condition, and the only
way this knowledge will manifest itself may instead be as a combination of
attributes of other entities, perhaps STATISTICS and CUSTOMER_POLL.
BON has been designed to follow a different track. Rather
than trying to include concepts from traditional data modeling or the so-called
structured techniques with all their accompanying drawbacks, a more fruitful
alliance is sought: the combination of object-oriented flexibility with the clarity
and expressive power of strong typing and formal contracts between classes.
p. 17 BON has been designed to follow a different track. Rather
than trying to include concepts from traditional data modeling or the so-called
structured techniques with all their accompanying drawbacks, a more fruitful
alliance is sought: the combination of object-oriented flexibility with the clarity
and expressive power of strong typing and formal contracts between classes.
Formalisms from other fields, which are often adapted and used as part of
proposed object-oriented analysis and design methods, such as state transition
diagrams, process diagrams, Petri nets, entity−relationship diagrams, data flow
charts, etc., are therefore not addressed in BON.
