harbaughs@eglin-vax (05/22/86)
This was sent to soft-eng BB so you may get a duplicate from there.
This book review is 289 lines long. I intend to submit it to Ada-Letters
by 01 July 86. Please send any comments by 15 June 86. Also please
send me any pointers on publications dealing with tying OOD and Ada
to Structured Analysis/Design. Thanks. harbaughs@eglin-vax
--
Structured Development for Real-Time Systems
Paul T. Ward & Stephen J. Mellor
Yourdon Press, New York, NY, 1985
3 Volumes, 503 pp. total, $28.95 each volume,
$56.45 for all 3 volumes, ISBN 0-917072-51-0
[Reviewed by Sam Harbaugh* from an Ada** point of view]
In the reviewer's opinion the 3 volume book is worthwhile reading for a
person skilled in Ada who has to perform system analysis and design or who
must work with system analysts and designers. The book brings together, in a
coherent manner, various techniques such as entity-relationship(ER) diagrams,
state diagrams and Petri net analysis with the system specification techniques
of DeMarco and Jackson.
The Ada reader will not find explicit reference to object-oriented
design[1] but the reviewer believes that it is can be easily extended from the
ER diagram. The Ada reader will find a few explicit references to Ada and
none to Ada/PDL. Techniques and tools for Ada/PDL should be adaptible to the
book's methodology by the reader.
The reviewer suggests that the book be used ONLY as a source for a
modeling language and techniques and NOT as a reference for designing
real-time systems. There are too many real-time system subjects which are
treated lightly or not at all. The lightly treated subjects may mislead the
reader into thinking that real-time system design is easy and the missing
topics may cause oversight of critical design requirements. For instance the
topic of stability is treated very lightly and non-linear systems and queuing
theory are not mentioned. Reliability, maintainability, power, size, weight
and cost are not mentioned as design factors.
Detailed Comments
The Ada readers will first discover that the books "tools" are a language
(graphical) and a methodology (techniques and heuristics) rather than tools in
the sense of something that performs some work for the analyst/designer.
There is often controversy about how much detail should be allowed in
high-level design expressed in Ada/PDL. The reviewer prefers the book's
approach in Volume I, section 4.4: "-details at all levels can relate either
to the problem or the solution".
Volume I, section 5.1 admonishes to include in the "essential model" (the
model of the required system behavior and it's environment) "those issues
associated with faults or errors". The Ada designer will recognize this as
admonishing that exception reporting and handling be designed along with the
desired functionality of a system.
* Sam Harbaugh is with Integrated Software Inc., Box 295, Palm Bay, Fl. 32906
** Ada is a registered trademark of the U.S. Dept. of Defense (AJPO)
Volume I, section 5.2 discusses the implementation model (the model of
the as-built software) partitions the software among processors, tasks within
each processor, and modules within tasks. There is true concurrency among
processors, simulated concurrency among tasks within a processor and no
concurrency between modules within a task. This coincides with the Ada
uniprocessor model, where there is a single Ada program within a processor and
simulated concurrency among tasks within the Ada program. If however the Ada
program is implemented on a multi-computer processor with true concurrency
possible among Ada tasks then the book's model will not map directly.
Volume I, section 7.3 defines state as: "A state represents an externally
observable mode of behavior". The readers should be cautioned that systems
can have states that are not observable and also can have states that are not
controllable and possibly states that are neither controllable nor observable.
The book implicitly treats only controllable and observable states. The
readers should be referred to books on State-Space Control Theory.
Volume I, section 8.2-8.3 discusses procedural specifications using a
high-level language, and states: "PDL's may be specifically designed for their
function, or a high-level language such as Ada or Pascal may be used as a
PDL". The book continues "When a PDL is used, the compilation features of a
high-level language are available and may be used to identify structural logic
errors-". "A PDL description may also be executed." At this point the
reviewer was elated however the elation was short-lived for the next sentence
states: "However, the execution must be done by a group of people in a
paper-and-pencil fashion." The readers should be referred to the work done by
Ada people in semantic modeling [2] and (you knew this was coming) XAda [3,4],
a technique of executing Ada/PDL as it is developed.
Volume I, section 8.3, shows an example transformation specification
written in pseudocode and structured English . Pseudocode is defined to be "-a
textual representation that has a somewhat formal syntax but for which no
machine compilation facilities are available (usually because the syntax is
chosen in an ad-hoc manner-)". In the reviewers opinion Ada would be just as
compact and readable as pseudocode; however, the structured English example
appears to be more compact and readable than if it were done in Ada.
Volume I, section 8.5, shows a specification for a closed loop speed
regulator performance as "|SPEED-SPEED SETPOINT|<2 mph for T>0". This is not
a very good way to specify control system performance since it admits limit
cycles (instability) of +-2 mph of setpoint. The readers should be admonished
to include in the software specification a time or transform domain control
system performance specification and be referred to books on control theory to
learn about closed-loop control system specification.
Volume I, chapter 9, is dedicated to executing the specification using a
paper-and-pencil Petri net token approach. This approach is very useful and
cries out for automation. One could imagine Pacman-like tokens eating their
way through the transformation network, with loud noises for detected errors.
Volume I, section 9.2, states "Enabling a currently enabled
transformation, or disabling a currently disabled transformation, is treated
as an error". It seems to the reviewer to be overly restrictive and whether
or not these are errors should be defined by the analyst.
Volume I, section 9.3, states "If a control transformation is in a state
in which no response to a particular event flow is defined, the arrival of
that event flow results in discarding of the token, with no action taken." It
seems to the reviewer that arrival of an undefined event flow should be
treated as a specification error.
Volume I, section 9.6 deals with prototype execution of the specification
by both pencil-and-paper and automated methods. The Ada readers will probably
associate the "automated prototype" with a "semantic model". Regarding
execution of the automated prototype the book says:"-a multitasking execution
environment is not necessary. Potentially concurrent transformations can be
serialized-executed one at a time in an arbitrary sequence." The reviewer is
concerned that the system specification will contain concurrency whose order
of execution is part of the specification and therefore cannot be accurately
represented by arbitrary serial execution in a semantic model.
Volume I, section 9.6 ends with "In other words, a transformation
specification for the controlled portion of the loop must be provided." At
this point the readers should be made to realize that time is an important
simulation variable. References to simulation languages should be given. If
the readers plan to write the automated prototype of the controlled system in
a computer language (e.g.:Ada) they will have to learn about numerical
integration of differential equations and be given references.
Volume I, section 9.7 begins with "In principle, the transformation
schema, together with it's data and transformation specifications, could be
compiled into executable code and implemented like any other program." The
section references Ada as such a language. This is a direct tie-in to XAda.
Volume I, chapter 10, presents data modeling using entity-relationship
diagrams. It seems to the reviewer that the ER specification presents the
designer with the identity of object types from the problem space(using
Booch's terminology) and operations required on those types. The designer can
then choose to represent some of these problem space object types with
solution space (software) objects and collocate those software types in an Ada
package with the required software operations(Booch's OOD).
Volume I, chapter 11 deals with specifying data as to it's meaning,
composition and type. Here type is defined as "- the set of values that the
data element can take on-." This contrasts to Ada's type definition which also
includes the set of allowed operations. Two paragraphs later however there is
reference to Ada permitting "-the definition of such extended data types.- Our
use of type should be thought of in this more general sense." The reviewer
believes that the book should have used the Ada type definition.
Volume II, chapter 1 deals with system modeling. One technique presented
is called "Subject-matter-centered modeling" and considers "-the components of
the total system grouped and listed as perception/action space objects,
sensors/actors, communication links and processors." This subject-centered
modeling seems to be very close to the analysis leading to OOD with the
perception/action space being Booch's "real-world".
Volume II, section 3.6, discusses passive modeling of the system
environment and states "-a passive modeling approach, which involves a search
for association between objects in the system's environment, can be used."
This also seems to be the analysis portion of Booch's OOD.
Volume II, section 4.10, describes constructing a data schema from an
event list. The book states "The idea is to translate sentences describing
the system into entity-relationship diagram components by changing nouns into
object types and verbs into relationships." It seems that this is exactly
Booch's analysis step prior to performing OOD and that therefore OOD can be
performed from the ER diagram specifications.
Volume III, preface says that automated support tools can reduce the
overhead of building the models but it does not give references to any.
Volume III deals with implementation and presents methods of taking the
specification model and transforming it into an implementation. Therefore
many real-world limitations are dealt with here. The book's task is very
close to the Ada task when implemented on a uniprocessor, as mentioned earlier
in this review. Section 1.4 defines the states of a task as started, stopped,
interrupted or resumed which doesn't match Ada task states.
Volume III, section 4.2 deals with priority task dispatching which is
compatible with Ada however it also admits time-slicing, contrary to Ada.
Volume III, section 4.4 deals with sampled data control of continuous
dynamic systems. The book references an encylopedia definition of Nyquist
rate when weakly describing the need to sample at a high enough frequency.
The reviewer believes that more explanation is needed on the subject and
references to control systems textbooks should be provided.
Volume III, section 4.4 presents time-line control of tasks which,
although not mentioned as such, seems to be the cyclic-executive used in
avionics systems and of course not found in Ada.
Volume III, section 4.5 deals with queue handling and states that burst
rates for inputs should be used to set the queue size. The reviewer believes
that this is an oversimplified design approach and that the reader should be
referred to textbooks on queuing theory for the methods of choosing queue
lengths based on probability of queue overflow.
Volume III, section 5.3 discusses synchronization of access to stored
data by tasks. One of the design methods is to depend on relative task
priority to control synchronism. The reviewer believes that this is bad
design practice because relative priority, in general, only arbitrates the cpu
usage. Therefore a high priority task waiting for I/O could lose the cpu to a
lower priority task which accessed the same data. Another design method
presented is to make the task uninterruptable which of course is not possible
in Ada tasking. The book presents two more methods, flags and data servers
(monitors), which can be implemented in Ada.
Volume III, section 5.6, defines data flows as being two ways, in or out.
It seems to the reviewer that Ada's "in out" should be incorporated in the
book's methodology.
Volume III, chapter 8 deals with module level design and structure
charts. Here the book refers to an Ada package as a place where a shared data
area can exist for the use of several modules. This is the book's only
reference to Ada packages therefore Ada designers must determine their own
mapping of modules to Ada packages. The reviewer has already mentioned the
possibilty of an OOD mapping from ER diagrams.
Volume III, section 8.3, deals with module specification. It states "
The amount of detail provided in the specification should depend on the
destination language: there is little use in writing pseudocode for a module
to be written in a high-level language such as Ada, -". However, there is no
mention of the existence of Ada/PDL's and processors for this purpose.
Volume III, section 8.4 dealing with data specification refers to Ada
twice. When dealing with data representation details the book states
"Higher-level languages such as Ada take away the need to define some of these
details." When discussing initialization of shared data the book states "If
Ada is used, this data specification will become the basis for the
initialization section for the package." The reviewer is not sure if the book
refers to an Ada package. The book should warn that Ada does not require
initialization and compilers are not required to flag uninitialized data.
Volume III, chapter 11, deals with sizing, efficiency and optimization.
The reviewer believes that several other considerations should be covered in
this chapter, namely:
The run-time demands for dynamic memory and the need to collect garbage
generated by such things as Ada access objects should be addressed.
Ada elaboration resource usage should be included in the book's model.
Hardware measurement techniques should be described which can be used in
lieu of, or in cooperation with, the software resource consumption
measurements mentioned in the chapter.
Power, size, weight and cost considerations in real-time system design
should be covered.
Reliability, maintainability, availabilty calculation techniques should
be presented along with their influence on the computer system design.
References:
[1] "Software Engineering with Ada" by Grady Booch
Benjamin/Cummings Publishing Co. ISBN 0-8053-0600-5 (1983)
[2] "A Specification Technique for the Common APSE Interface Set"
by T. Lindquist et al, Journal of Pascal, Ada & Modula-2 Sept/Oct 84
[3] "XAda: An Executable Ada Design Language Methodology"
by Sam Harbaugh, Ada Letters May,June 1985
[4] "First Use of XAda Methodology"
by Bonnie Burkhardt, Ada Letters July, August 1985
----
------