Reliability and Robustness of Engineering Software II: Proceedings of the Second International Conference held in Milan, Italy, during 22–24 April 1991
Upload
others
View
0
Download
0
Embed Size (px)
344 x 292
429 x 357
514 x 422
599 x 487
Citation preview
ELSEVIER
CMP
Acknowledgement is made to J.S. Medes and M. Jeffries for the use
of Figure 2 on page 65, which appears on the front cover of this
book.
Reliability and Robustness of Engineering Software II
Proceedings of the Second International Conference held in Milan,
Italy, during 22-24 April 1991.
Editors: C.A. Brebbia A.J. Ferrante
Computational Mechanics Publications Southampton Boston
Co-published with
C.A.Brebbia Computational Mechanics Institute Wessex Institute of
Technology Ashurst Lodge Ashurst Southampton S04 2AA U.K.
A.J. Ferrante COPPE/UFRJ Federal University of Rio de Janeiro CXP
68506 Rio de Janeiro RJ 21945 Brazil
Published by Computational Mechanics Publications, Ashurst Lodge,
Ashurst, Southampton, UK
Distribution of this book is being handled by:
ELSEVIER SCIENCE PUBLISHERS LTD, Crown House, Linton Road, Barking,
Essex IG 11 8JU, England
Sole Distributor in the USA and Canada:
ELSEVIER SCIENCE PUBLISHING COMPANY INC. 655 Avenue of the
Americas, New York, N.Y. tOOtO, USA
British Library Cataloguing in Publication Data Reliability and
robustness of engineering software.
1. Engineering. Use of software. I. Brebbia, C.A. (Carlos Alberto)
1938- II. Ferrante, A.J. (Augustine J.) 620.0028553 ISBN
1-85312-132-0
ISBN 1-85166-625-7 Elsevier Applied Science, London, New York ISBN
1-85312-132-0 Computational Mechanics Publications, Southampton
ISBN 1-56252-064-4 Computational Mechanics Publications, Boston,
USA
Library of Congress Catalog Card Number 91-70441
No responsibility is assumed by the Publisher for any injury and/or
damage to persons or property as a matter of products liability,
negligence or otherwise, or from any use or operation of any
methods, products, instructions or ideas contained in the material
herein.
©Computational Mechanics Publications 1991 See also p72.
All rights reserved. No part of this publication may be reproduced,
stored in a retrieval system, or transmitted in any form or by any
means, electronic, mechanical, photocopy ing, recording, or
otherwise, without the prior written permission of the
publisher.
PREFACE
Software for engineering applications has become, during the last
few years, a multi-billion pound industry as applications of
computer programs are now an essential part of any engineering
project. In spite of this, engineer ing software is not always
reliable and many fail to produce good solutions. The extent of
this problem, which is very costly to the engineering industry, and
its consequences, are somewhat hidden because the software industry
has not reached the necessary maturity.
An engineer needs a long training before being able to design a
body for instance. However, to do that, he may use a computer
program which has undergone no validation whatsoever and is written
by someone without any engineering knowledge. It is imperative to
address this problem to ensure that computer codes are properly
prepared to provide good solutions, and that they are robust and
reliable.
This 2nd International Conference on Reliability and Robustness of
En gineering Software (RRES 91) was called to address this
problem. The meeting was held in Milan, Italy, in April 1991 and
was of importance to engineers working in industry who are actively
involved with the develop ment of computer codes.
This book contains the edited version of the papers presented at
the Con ference and is divided into the following sections:
1. Software Development and Tools 2. Evaluation, Validation and
Maintenance 3. System Reliability 4. Model and Data Reliability 5.
Expert Systems 6. Data Bases and Networks 7. Engineering Systems 8.
Model Generation and Computer Graphics
The organizers are grateful to the participants and authors for
their support and in particular to the International Society for
Computational Methods in Engineering (ISCME) and the Latin-Ibero
American Society for Compu tational Methods in Engineering (AMC)
for having sponsored the meeting. The Conference was organized by
the Wessex Institute of Technology, U.K. to whom the editors are
also indebted.
The Editors Milan, April 1991
CONTENTS SECTION 1: SOFTWARE DEVELOPMENT AND TOOLS
A Design for Reliable CFD Software M. Petridis, B. Knight, D.
Edwards
Ensuring Robustness and Reliability of Object Oriented Software
using MASCOT 3 J. Moses, K. Jackson
Finite Element Program Generator and Finite Element Language G-P
Liang
DDLMU, Degrees of Freedom Management Module for Numerical
Modelization F. Delince, A. Genon, W. Legros, A. Nicolet, M.
Ume
The Contribution of Organisational Analysis to Engineering Software
Dependability J.S. Medes, M. Jeffries
A Structural Engineering Software Development Using CASE Tools M.M.
Mourelle, B.P. Jacob, N.F.F. Ebecken
Is Software Engineering Really Engineering? P. Smith, S. Ali
SECTION 2: EVALUATION, VALIDATION AND MAINTENANCE
Specification and Verification of Distributed Real-Time Systems
M.J. Wieczorek, J. Vytopil
A Software Reliability Monitoring and Prediction System D. Ambrose,
M.A. Rahman
Some Experience in the Development of Commercial FEM Software in
U.F.R.G.S. A.G. Groehs
Quality Assurance and Test Validation for CA.ST.OR M. AJzali, M.
Herve, A. Turbat
3
19
35
47
59
73
85
99
115
125
133
Quality Assurance of a Boundary Element Software System R.A. Adey,
R. Harfield, G.A. Brebbia
SECTION 3: SYSTEM RELIABILITY
New Evaluation Framework for Assessing the Reliability of
Engineering Software Systems Design Paradigms P. Kokol, V. turner,
B. Stiglic
SECTION 4: MODEL AND DATA RELIABILITY
Error Analysis and Adaptive Refinement of Boundary Elements N.
Karniya, I<. Kawaguchi
Reliability and Applicability of Nonlinear Optimization Software B.
Novak
Robustness and Accuracy of Groundwater Flux Computations in
Large-Scale Shallow Sedimentary Basins W. Zijl, M. Nawalany
SECTION 5: EXPERT SYSTEMS
An Expert System for Flexible Risers Design and Applications J.A.B.
Geyrnayr, N.F.F. Ebecken
Solute Transport Modeling Assisted by a Knowledge-Based System J.
Feher, M. Th. van Genuchten, W.J. Alves, D. W. Joyce
Treatment of Standard Design Requirements with Artificial
Intelligence Technology G. Bravo, A.F. Martin
SECTION 6: DATA BASES AND NETWORKS
S02: A Flexible Object Oriented Data Base Management System A.
Attoui, M. Schneider
Software Environment for Queueing Network Modelling M. Ghabrol, M.
Gourgand
143
159
173
187
203
217
231
243
253
271
285
SECTION 7: ENGINEERING SYSTEMS
FLYSIM - A Program for a Basic Flight Simulator G.D. Alford
Reliability Computer Analysis of Offshore Platforms L. V.S.
Sagrilo, E.P. de Lima, A.J. Ferrante, S. G. Rodriguez
Hormazabal
SECTION 8: MODEL GENERATION AND COMPUTER GRAPHICS
A Multiregion Finite Element Mesh Generator Based on Deformable
Grid Templates C. Stan Wei
Better Criteria for the Development of Solid Modeling Software B.
Feij6, R. Fischer, M. Dreux
An Auto-Adaptive Meshing Process in a Finite Element Software M.
Dubois, J. Magny, A. Turbat
Retrofitting and Integration of Engineering Software P. Gambirasi,
P. Salvaneschi
Authors'Index
297
313
327
341
353
363
375
387
SCIENTIFIC COMMITTEE
C.A. Brebbia A.J. Ferrante M. Afzali G.D. Alford G. Carosso M.S.
Deutsch M. Gattass N. Kamiya G. Keramidas B. Knight
A. Martin J.S. Medes J. Oliveira Pedro G. Pardoen A. Samuelsson R.
Spagnuolo P. Strona B.A. Szabo J.T. Webb W. Zijl
SECTION 1: SOFTWARE DEVELOPMENT AND TOOLS
A Design for Reliable CFD Software M. Petridis, B. Knight, D.
Edwards Centre for Numerical Modelling and Process Analysis, School
of Mathematics, Statistics (3
Computing, Thames Polytechnic, London, UK.
Abstract
The viewpoint of this paper is that the special needs of
computational software in terms of reliability must be considered
at the initial stages of a software development. The paper
describes an experimental implementation of a design which has been
developed in order to address some key features of software
reliability in computational fluid dynamics. The areas considered
important for reliability are the software engineering, problem
set-up results validation and the integration of an IKBS.
Particular characteristics and essential external software
qualities needed in CFD software are discussed, focusing at the
corresponding vital internal design decisions and overall
strategies deemed essential for large-scale CFD software
packages.
A data oriented design methodology based on Entity Analysis has
been adopted, and applied to a class of CFD problems. It is shown
that a useful partition of the model exists into problem and
solution spaces. This assists a view of the design as an
object-oriented structure, and allows a modularisation according to
information hiding principles. The resulting design allows the
integration of an IKBS and takes the form of a blackboard
architecture, which is particularly suited to the requirements of
results validation and problem set up validation.
The current experimental implementation is described. This is a
working prototype application implemented in "C". It is built
around a core comprising the blackboard architecture and the
working database. It includes a built-in data dictionary of
information entries and concepts meaningful to the user. This is
used by a rule-based component which allows automatic validation.
The rules are formulated as Prolog clauses, which are compiled into
"C" code for efficiency and portability. The results of initial
testing are discussed, and conclusions drawn about the robustness
of the system, particularly in respect of flexibility and extension
to parallel processing.
4 Reliability and Robustness
Introduction
During recent years there has been a sharp increase in the demand
for Engineering-Scientific software, especially in the
Computational Fluid Dynamics (CFD) area. This can be mainly
attributed to the availability of relatively cheap "raw" computer
power and to the development of a better mathematical understanding
of numerical analysis techniques due to considerable break-throughs
in this area. This has made computer modelling a credible
supplement or even alternative to expensive and usually
non-conclusive experimental prototyping.
For a considerable time there has been a need for complex software
systems that could deal with all aspects of CFD modelling, from
problem set-up to results validation and interpretation. In the
past a similar demand for software application systems in other
disciplines such as business software, general data processing or
real time applications has led to a rapid proliferation of a series
of formal software design strategies, methodologies, methods and
tools, some of them turning into industry standards ( e.g. SSADM
[1]). That has certainly not been the case in the area of CFD
software where the mathematical-physical correctness and
number-crunching efficiency aspect of CFD software are considered
as the main and in some cases only criteria for the final software
product. This has led to the treatment of the overall software
design as an afterthought, usually at a stage when most of the
basic design decisions have already been irretrievably embedded in
the software in an opportunist fashion.
Enthusiastic scientists, numerical analysts and engineers with
understandably little appreciation for software engineering methods
often create tailor-made pieces of software, good enough to cope
with a certain short term modelling target. The software eventually
passes through many programming hands, environments and consecutive
new requirements, so that extensions and mending patches tend to
pile up, most of them being performed in the best pioneering
traditions of computer programming. Despite these heroic efforts,
by the time the software is eventually a part of a commercially
exploitable CFD package it has turned into a structure with little
resemblance to the original design that spawned it and with a whole
number of design deficiencies that show up expensively during the
maintenance phase when considerable effort may be needed for
further extension of the software. Sometimes even a single simple
change in the software can involve a painstaking operation of
changes over the whole software body. Another problem created by
this evolutionary process is evident in the complexity and
obscurity of the user interface which reflects the corresponding
internal complexity and obscurity of the code.
The essential question remains whether a carefully designed and
engineered CFD software product can cope better with the special
requirements and needs of CFD in terms mainly of reliability
maintainability and user friendliness. To answer this question we
first discuss what is really involved in CFD modelling and what are
the main particular qualities required for CFD
Reliability and Robustness 5
CFD Modelling
Computational Fluid Dynamics modelling can be described as the
effort to produce a realistic mathematical representation of a
physical structure, process or device involving matter in a fluid
form as the main or dominant component acting in a dynamic and
usually time-dependent way. This representation would normally be
in the form of a set of mathematical equations describing the main
features and properties of the modelled situation in an unambiguous
but also uncomplicated form. These usually include the
Navier-Stokes equations in any simplified form deemed appropriate
for the given application, plus a set of thermodynamic and
empirical equations. There is also a geometrical representation of
the modelled domain and a set of usually simpler equations giving
the initial and boundary conditions for the model.
As there are no analytical solutions to the Navier-Stokes equations
or even to most of their simplified variants used in CFD modelling,
an approximate numerical solution must be found. This numerical
solution yields results which are compared to "reality" in the form
of measured data in real or simulated situations and experimental
prototypes, or even observed patterns which are put to test by
human physical intuition and/or expertise and experience. The
results of this comparison are then fed back to the original model
until the final result is deemed satisfactory for the given
application ( the well known "modelling cycle" ).
CFD software, then, has usually to deal not only with producing an
accurate and efficient solution of the mathematical statement of
the model but with all the life cycle of modelling. describing and
formulating the model. deciding the solution scheme. solving to a
satisfactory accuracy and outputting the results in an appropriate
form to the user to be evaluated and if necessary fed back to the
original model.
Particular qualities needed for CFD software
The particularities of CFD software derive from the fact that it
has to deal with the whole life cycle of modelling of a CFD problem
in a consistent way and from the CPU-intensive, number-crunching
nature of CFD software. It is obvious that some of the qualities
needed for CFD software are also a part of the quality requirements
for software in other disciplines of numerical modelling and
engineering software, and in almost every other software
applications field. There are two interrelated viewpoints for
looking at software quality, namely the external factors, which
comprise the viewpoint of the end user and the internal factors
such as modularity or readability only perceptible to computer
professionals. It is clear that in the end only external factors
really matter despite the indisputable fact that in order to enjoy
the visible software qualities it is imperative that internal
design techniques must have been applied
6 Reliability and Robustness
to ensure the hidden ones. The main external quality factors are
briefly presented here, as follows:
Efficiency: This is the most easily identifiable quality and the
one most frequently sought after, taking into consideration the
number-crunching nature that lies at the core of CFD software. It
essentially has to do with the good use of the available hardware
resources. This low level efficiency, though of considerable
importance, is frequently over-emphasised at the expense of the
overall efficient performance of the software. It underlines though
the quest for special techniques and hardware architectures for
parallel and vector processing.
Correctness: It is vital that CFD software products perform exactly
the required tasks according to specifications.
Robustness: This is needed so that CFD software functions in a
"smooth" way and can cope even with abnormal or extreme conditions.
CFD software has to be robust, especially as it may be used in real
time or safety critical applications with no margin for failures,
corrections or restarting (a time consuming operation after a
crash).
Extendibility: CFD software almost never stays the same and must be
capable of adaptation to frequent changes of specifications. It
should be a dynamic tool, able to incorporate any new state of the
art algorithm and able to deal (with or without modifications) to a
range of CFD applications and problems.
To this end, it has to incorporate two vitally essential
principles: > Design simplicity > Modularity (basically
information hiding)
Reusability: Much human effort and resources are usually invested
in CFD software, so that an essential quality of CFD software
products is their ability for reuse in whole or in part for new
applications.
Compatibility: A CFD software package should ideally be compatible
with other packages in terms of interfaces, basic data structures
and formats. (Such as text or binary output,graphical interfaces ..
)
Portability: CFD software users make use of a wide and diverse
range of software and hardware environments. The ease of
transferring CFD software between different environments ranging
from a laptop personal computer on the shop floor to a
sophisticated supercomputer via a remote link, is an essential
quality.
Verifiability: As the output of a CFD software package can be huge
and very complex, it is usually difficult to verify its performance
for lack, in most cases, of experimental data orland physical
insight and intuition. Verifiability is the
Reliability and Robustness 7
ease of preparing acceptance procedures, test data, benchmark test
cases and procedures for detecting failures and tracing them to
errors during the validation and operation phases.
Integrity: CFD software is used by people with a wide variety of
skills and expertise in different fields. It is up to the software
system itself to protect its various components (programs, data,
documents) against unauthorised access and modification. The last
but probably the most important aspect of software quality for CFD
is:
Ease and Efficiency of use: As mentioned above, people who use or
maintain CFD software have a wide range of possible skills and
originate from a number of different disciplines. There is the
numerical analyst, the modeller, the engineer and the
physicist.
CFD software needs a user interface with the following features: 1)
It should give a consistent view of the different parts of the
system to
fit the overall view and concepts of the user in the way that is
naturally perceived by him.
In particular CFD software must communicate physically meaningful
concepts to the engineer user instead of, for example, software
components, flags and switches which lie outside his natural
intuition.
2) As a superficial contradiction to the latter, CFD software must
give control, support and insight to the experienced user over most
of its functions and structure. This is essential, especially when
stretching the existing software to applications outside its
original scope and its normal area of use, which is something very
common to CFD software. CFD code will normally be used during its
life-cycle for many more uses than it has originally been built
for.
3) CFD software must be able to communicate results to the user in
a flexible range of ways and formats to suit the particular needs
and level of detail-abstraction appropriate for each
occasion.
4) CFD software must communicate with the user only when it is
really needed, in a simple form that can be easily understood and
with terms naturally perceived by the user. It should also be able
to take some basic and obvious decisions or even some more complex
ones but also communicate both the decisions and the inference
procedure to the user who is to make the final choices that could
override the system decisions.
After a careful examination of the external factors named above it
is clear that two key ways of improving software quality are on one
hand the careful internal design of software components and the
overall software structure, and on the other hand the bridging of
the conceptual gap between the user perception and the internal
characteristics and functionality of the software through an
intelligent user interface. These two tasks are closely
interconnected as they essentially need each other to work towards
achieving a quality end software product. These two aspects will be
considered through a look into
8 Reliability and Robustness
formal software design strategies that would be appropriate for CFD
software and through a discussion of the possibility of the
integration of an Intelligent Knowledge Based System (IKBS) into
CFD software.
The prototype An experimental prototype CFD application has been
implemented to
demonstrate the feasibility of incorporating the two key elements
referred to in the previous paragraph to yield "good quality" CFD
software. This prototype is a CFD application dealing with a family
of common CFD problems. The resulting software structure has been
implemented using the "c" programming language to work under
various hardware and operating environments.
The design and implementation of the prototype will be discussed
briefly to demonstrate the approach deemed appropriate to be taken
during the various stages of the development life-cycle of a CFD
software product as well as the main features needed for a reliable
and flexible CFD software package.
Formal software design The logical design of software is the first
important stage in the life cycle
of a software application. It is here that decisions are taken
which will detennine to a large extent the internal and external
qualities of the final product.
Over the years several formal design methodologies have evolved in
an effort to find a structured approach to the logical design of
software. We can distinguish three major approaches, on which
formal methodologies together with methods and tools have been
built. These are the . Data Flow (Yourdon [2], Peters [3]), the
Data Structure (Jackson [4], Warnier [5]) and the Object Oriented
(Cox [6], Meyer [7]) approaches to software design. The main
difference between these approaches lies in the importance they
give to the design of functions and data. In areas such as finance
and administration, software designers naturally tend to consider
database design as the basis of software design and development as
a whole, whereas in fields such as numerical modelling software the
functions on data (usually complex number crunching algorithms)
usually come first while database design is treated as an
afterthought. Knight et al [8] have demonstrated the implications
of these approaches to numerical software.
The introduction of parallel processing, where data communications
and coupling between software modules play an important role,
together with the increasing demand and use of AI elements in
numerical software increases the need for a "cleaner" and more
thorough database design in the field of numerical software
design.
A CFD problem is usually naturally defined as a set of data
describing the geometry and the properties of the modelled
properties and a general discretisation of the problem domain into
domain elements such as FEs,or CVs (Figure 1). On them, algorithms
and solving techniques are subsequently built to tackle the
problem. This makes the careful and structured design of a
flexible
Reliability and Robustness 9
database the important natural first step in CFD software design,
since, the things which are most likely to change during the
life-cycle of a CFD product are exactly the algorithms and
processing techniques rather than the topology of the data which at
the end represent the original statement of the modelling
problem.
A data-structure methodology would therefore seem to be the natural
vehicle for a formal approach to CFD software design. This view is
re-enforced by the need for IKBS integration, which fits easily
into the overall architecture by means of a global data structure,
or "blackboard". The design of the software architecture is
discussed in the following sections with reference to the
particular example illustrated in Figure 1.
Mathematical statement / V
N
Figure 1 A simple 2-D CFD modelling problem
Data structure design The data structure approach to software
design revolves around the
structured design of the database and the functions and processes
which can be defined to work on it. The purpose is to create a
highly modular software, which is exactly the result of building
the functions on a well designed database, as it creates software
modules with high cohesion and low coupling.
In order to design a well structured database for the heat transfer
problem presented previously, we have to use a specific collection
of concepts that can represent reality. This is called a data
model. The Entity-Relationship model (Chen [9],Shave [10]) will be
applied to yield the conceptual database schema. This is a
representation of the specific portion of reality (mini-world)
which is of interest for viewing the problem. It will be
constructed with the E R model and will give the static,
time-invariant view of the problem An instance of this schema, that
is a collection of data which conforms the structure of the schema,
will be the dynamic, time variant aspect of the problem. This could
be manipulated through update operations.
The Entity-Relationship model has a set of abstractions, namely
aggregation (entities,attributes), association (relationships) and
identification (primary keys-identifiers). The first step using the
E-R model is to identify the entities (objects) and their
relationships in the problem. This yields a time independent
representation of the portion of reality which covers the
specific
10 Reliability and Robustness
problem(see ego Knight [11]). The E-R diagram for the heat transfer
problem can be seen in Figure 2.
This is the conceptual schema of the problem. An entity is
represented by a box and a relationship by a straight line.
However, for different types of relationships different notations
exist which are also demonstrated in Figure 2
1:1
~ I:n
> < m:n
mandatory
--- --- contingent
- - - -- optional
Domain
around
Boundary
has
Reliability and Robustness II
As we can see in Figure 2, we can define two logical regions, the
problem domain and the solution domain which are not completely
independent of each other.
Logical formulation of the entity-relationship model The next step
is the logical formulation of the entity-relationship model.
This consists of identifying the entity sets and writing down the
attributes of the entities and the relationships between the
entities. (An attribute indicates a property of an entity). 1)
Entities
Grid_points(gp ) Elemencedges(ed) Plane_eIements(pe) Boundary
_points(bp) Grid_line_modules(gIm) Grid_lines(gl)
Sets GP={gp:GP(gp)}
Boundary _line_modules(bIm) Boundary _line_sections(bIs)
Boundaries(br)
ED={ ed:ED(ed)} PE={pe:PE(pe) } BP={bp:BP(bp) } GLM={glm:GLM(gIm) }
GL={gI:GL(gI) } BLM={blm:BLM(blm) } BLS={bIs:BLS(bIs) } BR={
br:BR(br)}
Domains(dm)
Plane elements:
3) Relationships around (br,dm) has (pe,ed) is (bp,gp) next (gI,gl)
ends (bp,bIm)
DM={ dm:DM(dm)}
Residual (gI,r) Geometry (gI,gm)
Temperature (bp,t) Coordinates (bp,co)
Boundary_condition (bIs,c) Geometry (bls,gm)
has (br,bIs) is (bIm,gIm) on (bp,glm) starts (bp,bIm) ends
(gp,ed)
has(bIs,blm) is (gIm,ed) on (gIm,gl) starts (gp,ed)
12 Reliability and Robustness
Note that an attribute relates an entity occurrence to a unique
value taken from a specific value set, while a relationship relates
entities to other entities. The notation used here to formulate the
model is that of predicate calculus. The logical model may be
viewed as the database section of a logic programming language such
as PROLOG.
The entity-relationship model shown above is in fact the conceptual
logical schema of the problem discussed. It represents a logical
system design and identifies all the time independent basic
properties of the problem.
The entity-relationship approach to systems analysis requires some
skill and may not in the first instance be ideal. However, models
can be substantially improved with the help of the formal process
of normalization as shown by Robinson [12].
The next step in software design is the identification of
particular functions with reference to their restricted visibility
and access to specified parts of the database as shown in Figure 3.
This allows us to make explicit the natural bond between functions
in a generic form and the data they act on,tbrough an integrated
view of objects encapsulating data and functions. Objects can be in
a generic form such as a "solver" or a "grid generator" whose
different instances are needed for the specific circumstances of a
particular application.
They would all come in a hierarchy under four basic classes: a)
Database Browsers-Pattern Recognisers with a restricted
read-only
access to attributes corresponding to the solution space part of
the logical database schema.
b) Database Constructors-Modifiers (such as grid generators) having
restricted access to the topology and instantiation of the
database.
c) Database Updates (such as solvers) having restricted access only
to attributes of the solution space part of the database.
d) Output functions (such as visualization functions, contouring
functions) having read-only access to attributes across the
database.
Processes
Reliability and Robustness 13
That leaves the problem of the overall architecture of the software
especially in reference to the overall control and the UI.
One promising architecture is the Blackboard (B-B) architecture
shown below in Figure 4.
Figure 4 The Blackboard software architecture
M.-> Main Program C.-> Control U.-> User Interface 0.->
Database Browser-Pattern recognition 1.-> Database
Construction-Modification 2.-> Database Update (attributes)
3.-> Output (Files-User)
A Blackboard architecture is a carefully designed database module
to which a number of processes and the controlling module have
restricted access and allows a flexible passing of information
needed for the modelling process (Morgan [13]).
14 Reliability and Robustness
The Blackboard architecture The design strategy described above
together with the resulting software
architecture built around the B-B model has been implemented in the
experimental prototype CFD application program using the "c"
programming language and under various hardware and operating
environments.
The design of the database according to the E-R model has been
implemented using dynamic memory allocation at Run-time with the
introduction of the type "entity" defmed as a recursive structure
and using pointers to represent the relationships between the
entities as defined in the logical formulation of the E-R
model.
Using the "entity" type definition a series of entities and their
attributes and relationships are defined dynamically and
instantiated optimally for a particular application.
Various functions such as solvers and grid generators are built
around the database with reference to their special visibility and
access to parts of the database.
The B-B architecture has been implemented as a hierarchical
structure containing dynamic information about the problem, the
solution state of the modelling process and a series of tasks to be
performed implemented as data structures encapsulating the software
functions and the data needed for performing them. The entries it
contains are in fact abstractions of the entities defined in the
database. The tasks are queued on the B-B by the reasoning process
taking place in the control module in conjunction with User needs
communicated through the VI module. Each task waits in the B-B
queue to be fired according to the instantiation of software
function and data parameters it contains, as soon as a process is
ready to start, which in tum informs the B-B about when the task
has started and when and how it has finished.
55 TB
, , ,
, , , '-
'-', )
Discretisation Technique Solver Characteristics
Reliability and Robustness 15
The control module looks at the B-B, detennining the state of the
modelling process, consults the user if deemed necessary through
the UI and the set of rules in the rulebase finally deciding on one
or more tasks that have to be performed which it then puts on the
B-B buffer.
Integration of an Intelligent Knowledge Based System The main task
of the knowledge based module in this architecture is to
bridge the conceptual gap between the multiplicity of the users of
the CFD software product and the internal structure and system of
concepts of the software. A main component of this gap has to do
with the different kind of vocabulary used by the two sides. On the
one side there is the strictly defined numerical precision of the
solvers, with a huge amount of multiple raw data and from the other
side there is the perception of situations and patterns in terms of
qualitative data. A user would prefer to refer to and communicate
meanings and concepts according to his own naturally perceived
qualitative view of the modelled reality. Concepts such as "Fine
grid" or "slow convergence" are easier to understand than looking
at files with thousands of raw high precision numbers. Conditions
for firing certain actions during the whole modelling process from
input data validation, deciding grid generation methods, algorithms
and solvers as well as the visualisation method to be used, are all
naturally formulated in a qualitative way.An expert user could
state for example something like "if the domain is irregular use
Body Fitted Coordinates" to decide on the discretisation technique
rather than looking in detail at the actual measurements of the
given domain.
This need for a qualitative representation of data and rules
dealing in a natural form with the qualitative data entries is
integrated into the CFD software prototype mentioned before as
shown in Figure 4. A Data-Dictionary of a series of qualitative
data entries for CFD was compiled and integrated into the
package.
A tool editor was implemented so that a user can pick and edit -to
his requirements a set of rules and data entries describing his own
interests and abstract view of the modelling process. Different
users in terms of experience and/or background can use alternative
RuIebaseslData-Dictionaries to fit their requirements creating a
flexibly controllable package giving a familiar "feel" to every
user through a polymorphic response to the outside world.
The rules are formulated as Prolog clauses and using inference
procedures similar to Prologs'. A particular predicate is the
predicate Is(symbol,"string") that consults the D-D for any given
assertion involving qualitative data. The set of Data-entries and
Rules are then compiled into "c" data structures and pointers for
efficiency and portability of use. The control part of the package
has restricted read-only access to the rulebase and the D-D to
determine what task has to be done according also to the users
wishes and the modelling process state shown on the B-B. The whole
inferencing process is communicated to the user through the UI in
order to give justification of a given decision or advice and to
give the user the opportunity to override any
16 Reliability and Robustness
such decision at will. An example of data-entry and a rule as seen
by the user in the data editor
is given below:
units: residual_change over 1 iteration(% )/average residual Bandl:
0-0.0001 Name: "slow" Band.2: -0.001 Name: "nonnal" Band3: ->
Name: "fast" Definition: The speed of convergence ie slow, steady,
fast .. , locally or globally
Is(Model, "Laplace "):- Is(Time_dependency,"steady-state"),
Is(Phases,I), Solver(lrectangularl,lline_SOR").
Meaning: H we have a steady-state, single-phase Laplace problem,
then the solver to be used should be a line by line SOR (successive
over-relaxation) on a rectangular grid.
Conclusions
The application of the data structure design approach built around
the Blackboard software architecture and the embedding of an IKBS
in the experimental CFD software prototype has shown to be
successful in dealing with a family of common 2-D CFD modelling
problems.
It has shown a resilience in coping with changes in requirements
and dealing efficiently and flexibly with the tasks required.
However further work is needed for further proving the design
in:
- Implementing more complex real life modelling extensions around
the existing kernel, mainly 3-D modelling, automatic mesh
generation,complex flows.
- Extending the Data-Dictionary and Rulebase to incorporate more
complex expertise and creating alternative more area specific ones
for different applications fields.
- Improving the UI aspect, mainly problem and results set-up and
visualisation.
- Investigating the use of the software architecture for
alternative hardware environments such as parallel processing (a
very promising direction given the CPU intensive nature of CFD
software) where the Blackboard architecture could potentially prove
to be an appropriate choice.
Reliability and Robustness 17
References
1. Downs, E., Clare, P., Coe, I., Structured Systems Analysis and
Design Method, Prentice-Hall, 1988.
2. Yourdon, E., Constantine, L., Structured design, Prentice-Hall,
1979.
3. Peters, L., Software design, methods and techniques, Yourdon,
New York, 1981.
4. Jackson, M.A., Principles of Program Design, Academic Press,
1975.
5. Warnier, J.D., Logical Construction of Systems, Yan Nostrand
Reinhold, 1981.
6. Cox, B., Object-oriented programming, Addison-Wesley,
1986.
7. Meyer, B., Object-oriented Software Construction, Prentice-Hall
International, 1988.
8. Knight, B.,Cross, M. and Edwards, D. Software Design Strategies
for Numerical Software, in Reliability and Robustness of
Engineering Software,(Ed. Brebbia, C.A.,Keramidas, G.A.),
pp.121-136, Edited papers presented at the 1st International
Conference, Como, Italy, September 1987. Elsevier, 1987.
9. Chen P., The entity-relationship model - towards a unified view
of Data, ACM Transactions on database systems, YoU, Nol, pp.9-36,
1976.
10. Shave, M.J., Entities functions and binary relations:steps
towards a conceptual schema, The Computer Journal, Yol.24, No.1,
pp. 42-47,1981
11. Knight, B., A Mathematical Basis for Entity Analysis,in
Entity-Relationship Approach to Software Engineering (Ed.
Davis,C.G., Jajodia,S., Ng, P.A. and Yeh, R.T.), pp. 81-90,
Proceedings of the Third International Conference on
Entity-Relationship Approach, Anaheim, California, U.S.A., 1983.
North Holland, 1983.
12. Robinson, H., Database Analysis and Design, Chartwell-Bratt,
England, 1981.
13. Morgan, T., Engelmore, R.(ed.), Blackboard Systems,
Addison-Wesley, 1988.
Key words
Computational Fluid Dynamics, Entity Analysis, Intelligent
Knowledge Based Systems.
Ensuring Robustness and Reliability of Object Oriented Software
using MASCOT 3 J. Moses(*), K. Jackson(**) (*)School of Computer
Studies and Mathematics, Sunderland Polytechnic, Sunderland, SRi
3SD, UK. (**)SD-Scicon UK Ltd., Fleet, Hampshire
ABSTRACT
This paper presents the use of MASCOT 3 as a design tool for the
production of robust and reliable Object Oriented software.
Object-Oriented design for software systems is a fast growing area
of research and development, although currently there is no
methodology to ensure the robustness and reliability of the
software produced.
The MASCOT 3 design methodology, designed for use in the
development of real-time systems by Ken Jackson et al., may prove
to be an ideal way of developing 00 software.
The paper describes the use of MASCOT 3 for the design of an
Object-Oriented software system and discusses the resulting
strengths of the design provided by the MASCOT 3 methodology.
MASCOT 3 provides: a formalism, which is machine and language
independent, for the expression of the system in terms of
system/sub-system network diagrams and text; a methodology for the
design, implementation, testing, documentation and maintenance of
the software; and a kernel which provides run-time executive
control for synchronisation and scheduling of real-time processing,
and which can be utilised to control the parallel processing of
operations on Objects.
Further, the formalism supports the design of Objects using MASCOT
3 1 s basic design entities; it
20 Reliability and Robustness
provides a natural way of expressing classes and hierarchical
relationships between objects; the MASCOT 3 design template
automatically aids the reuse of software objects; MASCOT 3's Access
Interface can be used to represent and ensure legal messages
between objects; and the formalism supports the information hiding
and abstract data typing associated with 00 design.
INTRODUCTION
Object-Orientation has become a fast growing area for research and
development into software production. Its advantages and main
concepts have been widely documented: e.g. Rentsch [1], Bloor [2],
Kim [3] and many more.
The following synopsis of the major concepts involved in 00
programs has been culled from Bloor [2] and Tello [4] and forms a
basis for the examination of MASCOT 3 and its ability to produce
robust and reliable 00 software.
OBJECT-ORIENTED SOFTWARE
Object-Oriented Programming Concepts 00 software embodies the
following concepts: objects, messages, methods, hierarchies and
classes. No definitive statement on what constitutes 00 design or
software has been generally accepted, Tello [4]. Simply, software
can be considered as object oriented if it contains most of the
concepts mentioned, including the basic 'object' concept. For
example, software which embodies all the above concepts and
excludes hierarchies may still be considered as object-oriented,
Sommerville [5].
An object is usually described as an 'entity', of importance to a
system, and is an instance of a class or type of object. Thus, a
class acts as a template for an object, Tello [4]; the template or
class describes an object instance completely; and classes are
often considered as abstract data types.
An object contains one or more methods which process data, or
perform some other action such as display data or graphic
characters. A method is invoked by a message sent to the object
either by another object, or by an external source e.g. a sensing
device in the case of real-time systems. Further, methods are only
invoked by the correct message; and all messages which do not
correspond to a method in an object are ignored by that
object.
Reliability and Robustness 21
Each object class may possess a super class (excluding the upper
most class) and a subclass. In other words, a class may inherit
properties, methods and messages, from a superclassi and can bestow
its properties upon a subclass. A subclass is, generally, only of
use when it has additional properties to those inherited. Hence, 00
software exhibits inheritance and hierarchy.
Inheritance, taken to its logical conclusion, should therefore
imply the existence of a class possessing properties which include
methods to create and delete the object class: the metaclass used
to create other classes. The language Small talk actually provides
this, Bloor [2], Rentsch [1].
Advantages of 00 software Object-orientation claims for its
advantages:
data abstraction, which may often more adequately model a system.
re-usable software, since an object is a distinct self-contained
module it can easily be re-used. data encapsulation, which within
an object reduces the maintenance costs, because changes to the
software will be in terms of the addition and removal of objects,
and changes to individual objects and their classes. error
detection can be more straightforward, leading to fewer unexpected
error conditions, since such conditions can be defined by class.
information hiding through data encapsulation, allows data peculiar
to an object and its methods to remain inaccessible to other
objects in the system. easier implementation of parallel processing
is enabled using the object design concept.
OBJECT ORIENTED DESIGN METHODS
Some object-or iented software design methods have been developed,
see Pressman [6], Booch [7], Booch [8]. To date there appears to be
no firmly accepted method. However HOOD, which resulted from
Booch's original work and the merging of two organisations
development methods i.e. Matra Espace's Abstract Machines and
CISI-INGENIERIE's 00 design, features as a main contender.
It is proposed that, with exceptionally few additions, MASCOT 3
provides a natural method for the production of robust and reliable
object-oriented
22 Reliability and Robustness
software. A rigorous comparison of HOOD and MASCOT 3 is not
attempted within this paper, however MASCOT 3 will be described and
its advantages will be contrasted with those of HOOD.
MASCOT 3
MASCOT 3 provides a Modular Approach to ,S.oftware konstruction
Qperation and Test. This approach was developed originally for
real-time embedded application areas, including concurrent parallel
processing systems. It provides a pictorial representation of a
real-time system which can be utilised to describe the complexities
within the system in a clear and unambiguous way.
The representation uses system and subsystem network diagrams which
are used to discuss a system's design with users and members of the
development team, so facilitating the process of system design,
implementation, test and maintenance. MASCOT 3 also provides a
means of representing activities and processes, and the
interactions which take place between them in a real-time
system.
Problems associated with unauthorised interactions, allowed by most
programming languages, can be controlled by MASCOT 3.
One of the major reasons for the development of MASCOT 3 was to
provide a means of enforcing the design of a real-time system on
the implementation of the system. The template feature of MASCOT 3
enforces the system structure from design through to implementation
and provides a mechanism which enables re-use of a design.
The design of most systems, appearance of methodologies like
undertaken using complex network which resulted in the design being
the final software.
prior to the MASCOT 3, was representations
indiscernible in
Amongst the other features of MASCOT 3 are: prov~s~on for the
comprehensive testing of the software system; and, synchronisation
and scheduling facilities which enable co-operating and parallel
processes to be executed reliably.
Facilities Provided by MASCOT 3 The facilities provided by MASCOT 3
include:
a formalism for the expression of the structure
Reliability and Robustness 23
of a system, the structure is represented as a system/subsystem
network diagram and a corresponding textual form, the formalism is
machine and language independent. a methodology based on the
formalism and used during all stages of the system development life
cycle i.e. design, implementation, testing, documentation and
maintenance. a small kernel which provides run-time executive
control and supports the formalism providing synchronisation and
scheduling for processes. (The MASCOT 3 kernel can be implemented
in three main ways: directly onto a machine's hardware~ on top of
an existing operating system~ or, integrated into an operating
system. MASCOT's software construction facilities and its kernel
are collectively known as the MASCOT machine.) a modular design
strategy, which is utilised in the construction and testing of the
system, and is identifiable in the executing software.
The MASCOT 3 Diagram Representation This representation is based on
hierarchies of network diagrams which are composed of distinct
symbols representing different basic components of a real-time
system. The top level diagram is the system diagram which usually
contains subsystems. Each subsystem will be decomposable into other
smaller subsystems or basic components. At the lowest level of
decomposition a subsystem will comprise basic components
only.
System and subsystem diagrams show the connections made to external
devices and other subsystems.
The basic component types of a subsystem are activities, channels
and pools.
Activities An activity is an independent, identifiable algorithmic
data processing action, and is able to execute as an independent
unit. Activities can be considered as threads of control which can
execute in parallel with other activities.
Channels and Pools MASCOT 3 requires that data which flows in the
system must pass from one activity to another via an
Intercommunications Data Area (IDA). The two basic IDA component
types are channels and pools. IDAs ensure the independence of
activities.
A channel allows data to flow from a producer of data to its
consumer, and exhibits destructive
24 Reliability and Robustness
reading. After a producer has written data to a channel a consumer
may read the data, the data will then be destroyed i.e.
consumed.
The MASCOT pool is used to show the accumulation of data which may
be referenced by more than one activity. Activities which read from
a pool do not affect the data, however data written to a pool by an
activity will overwrite data previously held in the pool.
The MASCOT 3 Methodology The MASCOT 3 methodology provides a means
for developing a logical design for a system. The design forms the
basis for subsequent stages of the methodology and is identifiable
at each stage of the software development life cycle. The stages of
the methodology are:
Identification of Requirements and Constraints Production of a
Design Proposal Network Decomposition Element Decomposition Program
Definition and Coding System Integration and Testing
Requirements and Constraints MASCOT 3 does not provide a specific
representation for the requirements stage. However, the following
are to be identified: the set of data processing functions and
interactions~ and the set of constraints that the system should
incorporate. Further, the methodology is compatible with major
design methodologies which possess a requirements analysis stage
e.g. SSADM, CORE.
Design Proposal The design proposal is developed as a network
diagram which shows the data flow through the system. The diagram
contains three types of component: active, passive and
server.
Network Decomposition The overall design is represented in terms of
a hierarchy. The decomposition continues down to a level of detail
at which the network components are shown, that is activities,
pools and channels that comprise each subsystem. At this level of
decomposition the individual functions of activities, servers for
external devices and access procedures which define the way data is
to be transferred across access interfaces are defined.
Reliability and Robustness 25
Access interfaces are associated with IDAs and activities and form
part of the mechanism which enables parallel processing and defines
the connectivity of each subsystem or component instance.
(Connectivity is considered under the paragraph on modular
design.)
Element Decomposition This stage enables further decomposition of
the activities in a subsystem, when necessary. The decomposition is
in the form of a Root and its Subroots. Each Sub root which belongs
to an activity has allocated to it a subset of the activity's
functions. For a fuller discussion, reference should be made to
Jackson [9], [10] and to the MASCOT manual [11].
Program Definition and Coding At this point in the methodology each
non-composite component is coded. MASCOT 3 ensures that coding is
constrained to be within the network design and any change
contemplated at this stage must first be agreed with the design
team before incorporation in the code.
Here, MASCOT 3's textual representation, which can be derived
directly from the diagram representation and to which it
corresponds, can be transformed into the implementation
language.
Test Stage The test stage requires each template designed for the
system to be tested individually and in the groups of subsystems to
which it is connected. MASCOT 3, also enables the use of specially
constructed networks to test individual components.
The MASCOT Kernel The kernel provides the synchronisation
facilities necessary for access procedures to execute successfully
i.e. to execute in a real-time parallel processing environment. It
provides the processes of Mutual Exclusion and Cross-stimulation in
order to achieve synchronisation. Mutual Exclusion is essentially
the standard process of excluding an activity from using a facility
i.e. an IDA or server, whilst the facility is in use; and
cross-stimulation allows an activity to be suspended until it is
signalled that it may use a facility from which it has been
excluded. MASCOT 3 uses the concept of a control queue to enable
mutual exclusion and cross stimulation to service activities. For
a more complete description of the MASCOT kernel reference should
be made to the Official MASCOT Handbook and to Jackson [12].
26 Reliability and Robustness
Modular Design Every subsystem wi thin the overall design of the
system is defined in terms of a template, and individual components
of a template are derived in order to construct the system. A
component may be an IDA, an activity or a subsystem. Each component
is defined as an instance of a template, and components with
identical characteristics can be constructed from the same
template. A template defines the function of the components which
can be derived from it, and also how these components are to be
connected into a network.
Component connectivity is defined in terms of access interfaces. An
interface possesses a set of procedures which define the way data
is to be manipulated by the interface e.g. an access procedure may
add an item of data to a buffer in an IDA. In addition, an access
procedure may contain coding to prevent deadlock and inconsistent
updating of data stores. This may be achieved, when using the
MASCOT kernel, by the processes mentioned earlier, along with some
basic control queue operations.
The connectivity constraints for each template are imposed using
two more MASCOT 3 features,the port and the window. A port, on a
template, is one end of a path between two templates, the other end
of which is a window on the other template. The path is a data flow
connection, and the interactions which take place between two
components connected by a path are defined by the access interface
of a particular type, and two templates may only be connected
together when one possess the port and the other the window
associated with that access interface. A port is the active end of
the path and initiates interactions along the path, and the window
is the passive end of the path. A window, although passive, may
transmit or receive data. A port indicates the interactions a
template requires and a window indicates those interactions which a
template may provide.
Access interfaces are actually sets of procedures and functions
which can be expressed in MASCOT 3's textual representation as
operations on data objects. Translation of this text into a high
level language, like Ada, is then straightforward e.g. Jackson
[10], [9].
The MASCOT 3 Symbol Set Figure 1 shows some of the symbols used by
MASCOT 3 to produce the hierarchical system and subsystem
diagrams.
Reliability and Robustness 27
AN OBJECT ORIENTED DESIGN USING MASCOT 3
It is contended that MASCOT 3, apart from providing robust and
reliable software as a matter of course, is ideally suited to the
design of reliable 00 software. The following MASCOT 3 design
features correspond to the 00 concepts listed:
class object
(including
template instance of a template i.e. subsystem or component
instance activity or subsystem access procedure
: system/subsystem relationship multiple inheritance)
It is clear that abstract objects are automatically produced with
MASCOT 3. A simple data processing example serves to illustrate how
identifiable objects can be easily accommodated within a MASCOT 3
design. Figures 2 and 3 contain some of the MASCOT 3 diagrams and
text for a system comprising the four objects: customer, order,
invoice and part. The overall system design would enable basic d.p.
functions e.g. adding or deleting a customer, recording customer
orders and invoices, and maintaining details about parts.
Messages pass between the objects. For example, when a customer
requests an order a message is sent to the customer object, a
message is then passed to order indicating that the order is for a
valid customer e.g. the customer exists and does not have an
outstanding debt. Each message corresponds to an access procedure,
specified in a MASCOT access interface, and implemented in an IDA
e.g. a pool or channel.
MASCOT 3 I S template concept ensures re-use of software where
applicable e.g. the activity template act-comp is used three times
within the customer template. Multiple inheritance is also shown:
the customer object or subsystem inherits the properties
28 Reliability and Robustness
of act_comp, subsys_del and subsys_add; and the dp system inherits
from the customer, invoice, part and order subsystems. Further, any
of the subsystems e.g. customer, part, or basic activities and IDAs
can be used in other systems, provided that the correct connections
exist within the new system. The customer subsystem template text
shows how the template is established by connecting the var ious
ports and windows of the constituent subsystems, pool and
activity.
Access Interfaces:
end.
money) ; end.
record) ; boolean, cust_rec
record) ; boolean, cust_rec
ww : write; access procedure find_cust details (cust_rec
record) ;
end. access procedure update_bal (cust_rec
amount money); record,
ow : accept; accept procedure affirm (answer
cust rec record);
pv : valid~ pr : read;
end.
bw write; requires pcc check c;
pdc check-c; pnc check-c;
Pool dpo : data-pool;
Activity acl : act_comp (pc = pcc, pv = pvv, pr = dpo. rw);
Subsystem ssde subsys_del (pdcl = pdc, prdl = dpo.rw, podl =
dpo.ww);
Subsystem ssad subsys_add (pncl = pnc, pvnl = dpo.rw, poal =
dpo.ww);
30 Reliability and Robustness
Reliability and Robustness 31
prdl : read; podl : write;
uses act_comp, chan, act_del; Channel cl : chan; Activity ac2
act_comp (pc
pv pr
(poid pod
Activity adl
Figure 3 Some of the MASCOT 3 Text
MASCOT 3 AND ITS SUITABILITY FOR 00 DESIGN AND DEVELOPMENT
Using Ladden's [13] seven factors for a 'Complete Life Cycle
Object-Oriented Development Methodology', it can be seen that when
a requirements analysis technique e.g. CORE [14] and an automated
product like the IPSYS tool builders kit are used, then MASCOT 3
encompasses all these factors.
The seven factors (which were originally intended for 00 Ada
software, but are arguably applicable to any programming language
capable of enabling 00 development) can be summarised as:
support for the software development life cycle. facilitation of
software development and maintenance subsequent to coding.
automatic production of the methodology's products. compatibility
of techniques throughout the life cycle. practicality and
usefulness of the method for those involved in designing and
developing a system. ease of learning and implementation.
minimisation of implementation risk.
Further, recommendations for the software development process for
000, also enunciated by Ladden [13], are fulfilled by MASCOT 3.
That is, MASCOT 3 provides: preliminary and detailed design
development processes for the selection and definition of both
problem and solution space
32 Reliability and Robustness
objects, functional primitives, and operations (problem space
objects correspond to objects which are identifiable at inception
by a user e.g. a sensing device, a customer~ and, solution space
objects are objects devised to implement the users "real-world
object requirements on a computer"): and, MASCOT 3 provides for
code and test processes. The inclusion of CORE at the requirements
stage fulfils the recommendations.
MASCOT 3, through its template construction and access interfaces,
provides a static representation of the system~ a dynamic
representation is provided by the network of activities and IDAs~
and, the root and sub root provides a hierarchical structure for
each thread of control. These features provide a representation of
the static and dynamic structure of a system required by Ladden
[13].
CONCLUSION - A CONTRAST OF MASCOT 3's ADVANTAGES
MASCOT 3's advantages are now contrasted against some features of
HOOD.
MASCOT 3 is neither machine nor language dependent, whilst HOOD has
been primarily developed for use with Ada, so much so that HOOD's
data description language is defined on the Ada language.
HOOD is essentially an architectural design method leading into
detailed design, see HOOD manual [15], whereas MASCOT 3 follows the
complete software life cycle.
A major weakness of the HOOD method is that it relies heavily on a
natural language description of the system under development. This
description is used to detect the objects and messages present in
the system, in fact, this approach has been reported as being
disregarded by its originator, Ladden [13].
MASCOT 3 provides an easily understood and natural method for
producing hierarchical diagrams, these do not require the explicit
use of relationships between objects, or constraints to be placed
on objects, as with HOOD. The only constraints in MASCOT 3 are
those imposed by the connectivity of each component through access
interfaces, and this is consistent with the 00 philosophy.
Also, MASCOT 3 enables the definition of templates, essentially
equivalent to classes, and
Reliability and Robustness 33
abstract objects as a natural part of the development process.
Hence, objects do not need to be explicitly identified before
design can commence, they can be discovered during design. As shown
in the example, they can equally well be incorporated into a design
from inception.
The MASCOT 3 methodology automatically produces hierarchies of
modules, where they exist, during the network decomposition phase;
hierarchies need not be considered separately, as with HOOD which
requires the identification of parent and child objects. A
subsystem in MASCOT 3 will always be a distinct object, and it may
well be an object instance of a class exhibiting multiple
inheritance derived from other subsystems i.e. super-classes.
Arguably, MASCOT 3 possesses a strong and meaningful diagramming
method, the results of which can be used in both design team and
user consultations; HOOD's representation is more conceptual in
nature. A HOOD design is in terms of a program structure diagrams,
messages are shown passing between objects as data flows, and no
facility for displaying templates appears to exist, see HOOD manual
[15]. Whilst, MASCOT 3's diagramming clearly identifies all data
flows, all object classes whether derived or present in the
real-world, and describes the dynamic behaviour of the system.
HOOD's representation is simpler but less meaningful, and its data
description language constrains it to Ada implementations. These
two factors denigrate HOOD as a widely applicable method for the
construction of robust and reliable 00 software.
Apart from the complexity of the design representation, when
compared to HOOD, the only voiced cr i ticism of MASCOT 3 has been
that it is relatively unknown in the United States, Ladden
[13].
REFERENCES
1. Rentsch, T., Object-Oriented Programming, ACM Sigplan Notices,
17(a) pp. 51-57, September 1982.
2. Bloor, R., Object-Orientation has the edge over leading
languages, DECUSER pp. 55-56 October 1989.
3. Kim, W., Architectural Issues in Object-Oriented Databases,
Journal of Object-Oriented Programming, Vol. 2, No.6, March/April
1990.
34 Reliability and Robustness
4. Object-Oriented Programming for Artificial Intelligence - A
Guide to Tools and System Design, Chapter 1, Object Oriented
Programming Defined pp. 3-13, Addison-Wesley 1989.
5. Sommerville,!., Software Engineering 3rd Edition, Chapter 11,
Object-Oriented Design pp. 203-231, Addison-Wesley, 1989.
6. Pressman, R.S., Software Engineering A Practi tioners Approach,
Chapter 9 McGraw-Hill Int., 1988.
7. Booch, G., Object Oriented Development, IEEE Transactions on
Software Engineering, February 1986.
8. Booch, G., Software Components with Ada Structures, Tools and
Subsystems, Chapter 2, pp. 10-32, Benjamin Cummins, 1987.
9. Jackson, K., MASCOT 3 and Ada, Software Engineering Journal,
Vol. 1, No.3, pp. 121-135, May 1986.
10. Jackson, K., MASCOT 3 and its relationship to other Methods and
Ada.
11. The Official Handbook of MASCOT Version 3.1, Issue 1, issued by
the Joint IECCA and MUF Committee, Crown Copyright, June
1987.
12. Jackson, K., MASCOT.
13. Ladden, R., Survey of Issues to be Considered in the
Development of an Object-Oriented Development Methodology for Ada,
ACM SIGSOFT Software Engineering Notes, Vol. 13, No.3, pp. 24-30,
July 1988.
14. Controlled Requirements Specification (CORE), Seminar Manual,
Mullery, G.
15. HOOD Manual Issue 2.2 Revised by Robinson, P.J., Software
Engineer ing Section, European Space Agency.
Finite Element Program Generator and Finite Element Language G-P
Liang Institute of Mathematics, Academia Sinica, Beijing, 100080,
China
l.INTRODUCTION
Until now, although there are many finite element program systems
running on various computers, the scientists and engineers who are
fa miliar with finite element methods feel strongly that the
finite element program system so far provided is very difficult to
use. Since they created their finite element programs tney can
modify them arbitrarily and en sure they operate well. Therefore
people are eager to have a finite element program system built to
their own specification. However to develop the simplest finite
element program system takes a lot of time, energy and money. Thus
people often give up any attempt to develop one. The aim of
developing this finite element program (FEPG) and finite element
lan guage is to help people build a system to their own
specifications.
With the aid of FEPG, the user pays only a small price, he can
rapidly create and arbitrarily modify the finite element program or
pro gramming system according to his own specifications.
This generator supplies users with a new programming method of
finite elements - automated generating technique and its relevant
tools. It can rapidly produce various finite element programs
according to the requirements of users. For the users who do not
have any finite element programs, they can rapidly create their own
finite element programs with the aid of FEPG. For the users who
already have a finite element program system, they can manage,
maintain, and develop their own system even better with the aid of
this generator.
36 Reliability and Robustness
2.1 Automatically generating element subroutines This system can
generate stiffness, mass and dumping matrix as well
as load vector for any element, including linear and nonlinear, in
which the element subroutine can be dependent either on unknown
functions of the equations or on others (this is necessary for a
couple of problems). The number of displacement functions (unknown
functions), the number of other functions, the number of nodes, the
number of generalized dis placements, the dimention of space
coordinates, the orders of equations (do not exceed four), and the
expression of shape functions (only polyno mials) are arbitrary
without limitation in general. The user needs only to input the
expressions of shape function, coordinate transformation, weak
equations (including symmetric and non-symmetric), load and so on
to obtain the FORTRAN subroutine needed. Furthermore all the
symbols in the expressions (such as coordinate variables,
displacement functions, generalized displacements etc.) are
specified by the user so that he does not need to change his own
familiar ones.
2.2 Automatically generating preprocessor programs The preprocessor
program for inputting data can be generated with
arbitrary tableau format. The number of tables, the relations
between various tables (i.e., the tree structure), the names of
various tables, the array variable names of each column in the
table and the form for storing them into files are all specified by
the user. Therefore it is not neces sary to limit the degrees of
freedom of each node at a fixed number (In conventional finite
element programs for computing structural mechanical analysis, this
number is fixed at 6, and that has brought a lot of inconve nience
to users). Users can select any number for their own applications
and select different numbers for different problems.
Moreover in order to reduce the amount of users' input data and
increase their readability and generality, the system allows users
to refer to variables and adopt any expressions which are permitted
by FORTRAN in the data file. In addition the system supplies three
automatic modes of data which are very convenient and easily
remembered and its function exceeds preprocessors of conventional
finite element programs.
2.3 Automatically generating the main program for finite element
computation
The main program can be automatically generated according to
the
Reliability and Robustness 37
formulae given by the user to tell the generator how to form the
stiffness matrix and the load vector.
2.4 Automatically generating programs to allocate dynamically core
memory for all arrays. FEPG can help the user implement the dynamic
allocation of memory according to the FORTRAN program which defines
arrays statically.
2.5 Up to now, this system can automatically generate finite
element programs to solve various linear static and dynamic
(including eigenvalue) problems and to solve any linear, non-linear
and couple equations (includ ing non-symmetric case). No matter
which field the partial differential equations come from, as long
as they can be solved by the finite element method, the finite
element program can be generated automatically by this
generator.
2.6 FEPG provides users with conventioinal expressions of shape
functions (including 1D, 2D and 3D) and weak equations (including
polar coordinates, cylindrical coordinates, spherical coordinates,
including both symmetric and non-symmetric cases, and so on) for
linear elastic me chanic problems, so that users can get these
element subroutines without inputting these expressions (instead,
writing down their names).
3. INPUT FILES AND AN EXAMPLE
When the system is employed to generate a finite element program,
an element information file is needed to be written for each type
of element subroutine and two files (tree structure file and data
file) are to be written for generating preprocessor programs. In
the following three sections, a Poission equation with fixed
boundary condition on· a rectangle in x-y plane will be solved by
bilinear elements and this is taken as an example to show how to
write the three files.
3.1 Element information file A file for solving the Poission
equation by using bilinear elements is
given as follows.
ELEM \equation u/xx+u/yy = -2*(2-x* x-y* y) \solution u = (l-x* x)*
(l-y* y) \boundary condition u = (l-x* x)* (l-y* y) defi disp
u
38 Reliability and Robustness
var ul, u2, u3, u4 refc p, q coor x, y dord 1 node 4
shap u=[(l-p)* (1-q)/4jul+[(1+p)* (1-q)/4ju2 +[(l+p)*
(1+q)/4ju3+[(1-p)* (1+q)/4ju4
tran x=[(l-p)* (1-q)/4jx(1)+[(1+p)* (1-q)/4jx(2) +[(l+p)*
(1+q)/4jx(3)+[(1-p)* (1+q)/4jx(4)
y=[(l-p)* (1-q)/4jy(1)+[(1+p)* (1-q)/4jY(2) +[(l+p)*
(1+q)/4]y(3)+[(1-p)* (1+q)/4jy(4)
gaus=4 -1.,-1.,1.; 1.,-1.,1.; 1.,1.,1.; -1.,1.,1.;
stif dist=[u/x; u/x]+[u/y; u/yj
load=[uj* 2.* (2.-x* x-y* y)
end
Where the element subroutine name is filled in on the first line.
From the 2nd to the 4th lines ("\" is the first symbol at each
line) are comment lines. From the 5th line to the blank line with
the keyword "defi" at the first line, fill in the displacement (the
unknown function of the equations) names, generalized displacement
variable names, reference coordinate and global coordinate variable
names, differential orders of unknown functions in weak equations
and the number of element nodes as the first segment
information.
The second segment information is labelled with the keyword "shap"
at the first line, and following that are the expressions of
element shape functions of unknown functions, where the basic
function is filled in be tween matching square brackets "[" and
"j" in front of the generalized displacement variable.
With the keyword "tran" at the first line, the third segment infor
mation is analogous to the previous shap information segment.
Reliability and Robustness 39
The fourth segment information is labelled with the keyword "gaus"
, then the number of integral points and coordinate values and
weighting coefficient of each integral point are given.
In the fifth segment with the keyword "stiff" at the first line,
the weak form of the Poission equation is filled in after the
keyword "dist". Where [.;.1 denotes the inner product of the two
functions, the function before the semicolon is the unknown
function while the function after the semicolon is considered as
the variational variable, so any weak form of partial differential
equations (including non-symmetric) can be written in this
form.
The sixth segment information is about the right side of the
equation led by the keyword "load".
3.2 Tree structure file for tables It is simple and convenient for
users to input data with tableau
format in a finite element program. In this system the information
spec ifications of tables are specified by users according to
their applications. The example in the previous section will also
be used to explain how to fill in this file.
. •
And this tree structrue information can be written as
follows.
BILl COORj ELEMj IDj DISP
ELEMF ENOD
TABLE
ENOD N; NODI; NOD2; NOD3; NOD4; IS; IS; IS; IS; IS;
IDF N;IDU; IS; 13;
DECLAR
COMMON\NXY\NX, NY, XMAX, YMAX
Where BILl is the root directory and the next line is filled with
all its subdirectories (there are four subdirectories in this
example). ELEM in the fourth line is a subdirectory name with a
letter "F" on its right side, which means that all data in this
subdirectory are stored in a file. On the next line all its
subdirectories (only one subdirectory ENOD in this example) are
filled in.
The word "table" after a blank line is a keyword below which all
tables will be specified. The table specification occupies three
lines. The first line is the table name. If a letter "F" appears on
the right side of this name, the data of this table will be stored
alone in a file.
The names of subscript and all column variables are filled in on
the second line. Then the last line specifies the format for
displaying this table data.
After the specification of all tables specify common variables for
all tables at the last two lines with the keyword "declar" at the
first line.
3.3 Data file The structure of the input data in the finite element
program is
specified by the tree structure file in the previous section. This
section will tell users how to fill in a data file in which all the
subdirectory (including the table) names and all the column
variable (including subscript) names
Reliability and Robustness 41
are the same as those of the tree structure file. In the example
this data file is as follows.
BILl 4
COOR $c6 COMMON/XY/X, Y $r &NXj &NYj &XMAXj &YMAXj
&DX=XMAX/NXj &DY=YMAX/NYj [[(1-1)* (NX+1)+Jj DX* (J-l)j DY*
(I-l)j J=I, NX+1]j 1=1, NY+1]
ID [Ij Ij 1=1, (NX+1)* (NY+1)] [Ij -lj 1=I,NX+1] [Ij -lj 1=(NX+1)*
(NY+1)-NX, (NX+1)* (NY+1)] [(NX+l)* (l-l)+1j -lj 1=1, NY+1]
[(NX+1)* Ij -lj 1=1, NY+1]
ELEM 1 ENOD [[NX* (l-l)+Jj (1-1)* (NX+1)+Jj (1-1)* (NX+1)+J+lj \ h
(NX+1)+J+1j 1* (NX+1)+Jj J=I, NX]j 1=1, NY]
DISP $c6 DIMENSION R(2) $c6 COMMON /XY/X(I000), Y(I000) [Ij O.Oj
1=1, (NX+1)* (NY+1)] [Ij &R(I)=X(I)j &R(2)=Y(I)j
BOUND(R,I)j 1=1, NX+1] [Ij &R(I)=X(I)j &R(2)=Y(I)j
BOUND(R,I)j 1=(NX+1)* (NY+l)-NX, \ (NX+1)* (NY+l)] [N=(NX+1)*
(l-l)+1j &R(I)=X(N)j &R(2)=Y(N)j U=BOUND(R,I)j 1=1,
NY+1]
[N=(NX+1)* Ij &R(I)=X(N)j &R(2)=Y(N)j U=BOUND(R,I)j 1=1,
NY+1]
Where the first line specifies the root directory name of the input
data, the number 4 on the right side denotes that 4 subdirectories
will follow, which are all tables except the third one. Data in
each table begin with the table name and end with a blank line and
all data are followed by a semicolon.
The first table is for inputting the coordinate data. Following the
table name COOR a common block is specified for storing the
coordinate X and Y values, ready for the fourth table to use. The
second line is for reading four paramaters, which are the numbers
of subdivision along X and Y directions and the sizes of these
directions of the rectangle respec tively. The sizes along X and Y
directions in each element are calculated in the third line. The
fourth line is to compute all nodal coordinate values. The form of
the data generation is specified as implied-DO list in FOR-
42 Reliability and Robustness
TRAN, but by matching square brackets "[" and "J"instead of
matching parentheses "(" and ")".
The inputting of data of the following three tables is analogous.
The function BOUND(R,l) occurring in the fourth table for
calculating the boundary condition is a FORTRAN function as
follows.
FUNCTION BOUND(R,J) DIMENSION R(2) GOTO (1,2,3), J 1 BOUND=(1.-R(1)
.. 2). (1.-R(2) .. 2) GOT04 2 BOUND=2 .• R(1). (R(2) .. 2 -1.)
GOT04 3 BOUND=2 .• R(2). (R(1) .. 2 -1.) 4 CONTINUE RETURN
END
4.NON-LINEAR AND COUPLE PROBLEM
Most of the differential equation problems in practice are
nonlinear and couple ones. The linear uncouple problems are only
the simplification and approximation of those kinds of differential
equation problems. In many situations, the simplification or
approximation is far from meeting the requirement, so it is
unavoidable and of more general significance to solve the nonlinear
differential equations.
FEPG can be used to solve any non-linear and couple equations. It
can automatically generate different finite element programs for
solving any different non-linear and couple equations according to
the algorithms given by the users. An additional file (besides the
three files above for linear problem, see section 3), which gives
the formulae to form the stiff ness matrix and the load vector
corresponding to the linearized equations, is required for
generating the non-linear program. As an example the following file
is for solving a non-linear elliptic equation.
defi stif S
equation vectv read (s, unod) v matrix = lSI fort = [F]
SOLUTION U vect U, v read (s, unod) v [v]=[U]+[v] write(s, unod) v
$06 ERR = 0.0 $C6 DO 1111 1=1, KNODE $C6 DO 1111 J=l, KDGOF $C6 ERR
= ERR+EU(J, I) •• 2 $CO 1111 CONTINUE $C6 IF (ERR .LT. loOE-6) $CO
• OPEN(ll, FILE=' " STATUS='NEW')
$06 WRITE(.,. ) 'ERR =', ERR
Reliability and Robustness 43
And the corresponding element information file for generating a bi
linear element subroutine is
ELEM
\equation -u/xx-u/yy+u** 3 = (x* x+y* y)** 3 - 4 \solution u = x* x
+ y* y \ boundary condition u = x* x + y* Y defi disp u var ul, u2,
u3, u4 refc p, q coor x, y coefun dord 1 node 4
shap u=[(l-p)* (1-q)/4]ul+[(1+p)* (1-q)/4]u2
44 Reliability and Robustness
tran x=[(l-p)* (1-q)/4]x(1)+[(1+p)* (1-q)/4]x(2)
+[(l+p)* (1+q)/4]x(3)+[(1-p)* (1+q)/4]x(4)
y=[(l-p)* (1-q)/4]y(1)+[(1+p)* (1-q)/4]Y(2) +[(l+p)*
(1+q)/4]y(3)+[(1-p)* (1+q)/4]Y(4)
coef un=[(l-p)* (1-q)/4]un(1)+[(1+p)* (1-q)/4]un(2) +[(l+p)*
(1+Q)/4]un(3)+[(1-p)* (1+q)/4]un(4)
gaus=4 -1.,-1.,1.; 1.,-1.,1.; 1.,1.,1.; -1.,1.,1.;
stif dist=[u/x; u/x]+[u/y; u/y]+[u; u]* DG(un)
mass dist=[u/x; u/x]+[u/y; u/y]
load=[u]* (F(x,y)-G(un))-[u/x]* un/x-[u/y]* un/y
end
FORT
RETURN
RETURN
RETURN
END
Another two files for generating the preprocessor program are the
same as those in previous sections (see section 3.2 and 3.3).
5. CONCLUSION
Reliability and Robustness 45
FEPG is a powerful tool for solving PDE problems. Scientists and
engineers can solve any PDE problems by FEPG without coding while
using FEM. So a big amount of coding time will be saved and they
can concentrate on the formulae and algorithms, but not program
design and coding.
DDLMU, Degrees of Freedom Management Module for Numerical
Modelization F. Delince(*), A. Genon, W. Legros, A. Nicolet, M. Dme
Department of Electrical Engineering, University of Liege, Institut
Montefiore, Sart Tilman Bat.B28, B-4000 Liege, Belgique (*)This
author is Research Assistant with the Belgian National Fund for
Scientific Research
ABSTRACT
A software tool is presented which is aimed to facilitate the
development of large numerical programs such as the ones using the
finite element method (see Silvester [1]) and the boundary element
method (see Brebbia [2]). DDLMU is a module written in FORmAN 77
and is aimed at performing tasks such as the degrees of freedom and
equations numbering and the system assembling and resolution.
INTRODUCTION
One of the major problems in the practical implementation of
numerical methods, such as the finite elements and the boundary
elements is the assembling process. This problem is related to the
problem of degrees of freedom (DOF) and equations numbering. This
is particularly true when the problem is divided into subdomains
where different methods are applied (Boundary elements-finite
elements coupling, for instance).
We isolated a set of characteristic tasks to be accomplished by a
module called the degrees of freedom management module
(DDLMU).
We introduced the notion of relation, that is a very simple
equation between degrees of freedom such as the equality of two DOF
or a DOF equals a constant.
The problem of DOF numbering is solved by introducing a DENT code
(Domain, Element, Node, and Type) able to describe any DOF.
Equation numbering is solved similarly by introducing a Domain,
Node, and Type code.
Practically DDLMU appears to the programmer as a set of subroutines
forming a kind of language. DOF and equations are referred to only
by their codes. The programmer of an application does not worry
about internal numbering of DOF and equations, matrix storage and
system resolution.
48 Reliability and Robustness
DDLMU provides a natural slicing of programs in preprocessing,
processing and postprocessing.
PRELIMINARY NOTIONS
Continuous media are generally modelized by partial derivative
equations and most numerical methods to solve such equations need a
discretization of the media (i.e. a meshing in small pieces called
elements).
So, rather than considering continuously varying unknowns (which
implies an infinite number of numerical values), we are led to
consider a finite number of unknowns such as the values of a
physical quantity at a certain number of distinguished points
called the nodes of the problem. Those unknowns are called the
degrees of freedom (OOF) of the problem.
Consider, for instance, a magnetostatic twodimensional problem. As
unknown quantity, we have the vector potential (which has here only
one component) varying at each point of the considered domain. To
solve the problem with [mite elements, we can divide the domain
into triangles which will be our elements. We suppose, for
instance, a linear variation of the potential on the elements. The
nodes of the problem will be the vertices of the triangles and the
numerical resolution will consist in finding the nodal values of
the vector potential.
If a problem involves parts where material properties and/or
equations are different, those parts are called subdomains or
simply domains. This distinction is particularly important for the
boundary element method.
EQUATIONS AND RELATIONS
The numerical values of the degrees of freedom are obtained by
solving a system of algebraic equations (linear or linearized). To
have a well posed problem, the number of linearly independent
equations must be equal to the number of degrees of freedom. In
some cases, an equation may have a particularly simple structure,
such as the equality between two degrees of freedom. It leads to a
very sparse row in the system matrix (Only two elements non equal
to zero). In this case, the equation will be called a "relation"
rather than an "equation". The distinction between those two
categories is, of course, quite subjective. One advantage of
relations is that they can be removed a priori from the system
during the preprocessing.
To show this, take a system of size NS (fig. 1). It is always
possible with a correct numbering of the equations and of the
unkowns to express it under the form shown on fig. 1 (i.e., to make
appear sets of relations as rectangular blocks).
The block i is constituted of ~ relations between Ni unknowns.
Using matrix form, we have an underdeterrnined system:
(1)
hj given right hand member vector.
A non singular square submatrix lB j (1) of dimension Ni x Ni can
be extracted from lB j and we have:
(2)
It allows us to express a part of the unknowns (£.P ~ as linear
functions of
the others (£.12' by :
p(l) = _ (lB \lrl lB \2)\ p(2) + lB \lrl h. -1 l' 1 J -1 l.1l1
(3)
Posing £.12) = Jlj, the initial Nj unknowns £'j can be expressed as
linear
functions of N j - M j new unknowns Jlj.
(4)
Unknowns £. will be called physical degrees of freedom because they
can be interpreted in physical terms. Unknowns U , used during the
computation, will be called numerical degrees of freedom. Applying
this procedure to all the blocks of relations, linear relations are
obtained between physical DOF and numerical DOF.
(5)
Ni~ Mi» NS
The remaining (rectangular) system consists of the genuine
equations (i.e. not the relations) :
A.~=Q (6)
Remark The right hand member of an equation is always considered
equal to zero. IT it is not the case, the equation with a right
hand member
Equation=b
may be transformed into an e
LOAD MORE