Reliability and Robustness of Engineering Software II: Proceedings of the Second International...

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
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
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
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
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
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)
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
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]).
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
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
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.
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
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.
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
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
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
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.
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].
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.
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
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);
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
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
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.
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.
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
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
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.
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
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-
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
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
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
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.
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

Reliability and Robustness of Engineering Software II: Proceedings of the Second International...

Documents

Transcript of Reliability and Robustness of Engineering Software II: Proceedings of the Second International...