cessing and pipelining. therefore programming languages like fortran · 2014. 5. 16. · therefore...

Experiences building a pure object-oriented

modelling system architecture

O. David

Department of Geography /Geoinformatics, Friedrich-Schiller-

gna, loeWfrgrabeM 32, D-0774J Jena, Germany

Abstract

Modelling and simulation of complex environmental problems becomes moreinteresting by using modern software construction techniques for buildinglarge scale models. A closely problem-oriented and transparent softwaredesign and it's efficient implementation seems to be orthogonal in the past.The pure object-oriented approach in modern software construction leads toa very homogenous system view for developing software in general. In mod-elling and simulation object-oriented system view becomes more and moreinteresting because of problem-oriented representation of envirommental re-search topics. The paper presents the design of the Object Kernel as a part ofthe Object Modelling System developed at the Department as an integratedsystem for building modells on the top of existing library components using.Emphasis is given on the design of the modelling system architecture.

1 Introduction

Computer simulation and modelling becomes more and more interesting forproblems in environmental science since more computing power has migratefrom the computing centre to the desktop and comfortable software toolsare available for using this power most efficent.

In reality there is a lot of software code available for simulation in envi-ronmental science. But most of them are very closed applications written forspecial purposes with special data in- and output, graphical representation,etc. Because of handling complex environmental problems in simulationsthe software architecture was conveniently optimized for special operating

Transactions on Ecology and the Environment vol 10, © 1996 WIT Press, www.witpress.com, ISSN 1743-3541

606 Computer Techniques in Environmental Studies

systems and hardware features like for example multithreading, vector pro-cessing and pipelining. Therefore programming languages like FORTRANare prefered because they are suitable for intensive and efficient numericalcomputations with no main relevancy to software engineering and designaspects. There are two main separate groups in closed modelling systems,model developer are designing and implementing the whole modell and themodell user are applying the modells. A lot of functions and libraries basedon individual work of environmental scientists where written over the years.There are for example a lot of closed models in geohydrological solute trans-port modelling on PC and UNIX platforms. To control all informationabout models and simulation software like system requirements, interfaces,parameters, etc. meta information systems are used to manage the correctusage of models.

To avoid individual solution for modelling software, software (modell)development systems where developed like for example the Modular Mod-elling System MMS [13]. They are used as a tool set by a modeller to builda modell based on a set of modules implementing modelling algorithms,data import and export, graphical representation. With this knowledge themodelling process can now be subdivided into three main classes:

• Modell application A model user is applying an existing executablemodell for simulation. He is only varying parameters to observe thebehaviour of the modell in his work. That's the way how to apply anexecutable modell in environmental analysis. The user has to knowabout the parameter for fitting the modell. He knows mathematicalbasics but noting about programm implementation.

• Modul combination A model user/developer is building a new modellbased on a set of existing modules. He is replacing one module withanother implementing a different computing approach. This work canmerged into the modell application. Not only parameters has to bevaried but algorithms too. The developer/user knows about modellparameters and behaviour and interfaces of modules.

• Modul dcvelopjnent A developer is implementing modules which canbe used for Modul combination. Thats the way how to transferhuman knowledge representing in mathematical methods into algo-rithms. This work often is relatively independ from real applicationof modells. Than comprehensive the available module library thanmore powerful the the system benefit. A developer detailed knows aprogramming language (C,C++,FORTRAN,..)

Using a modelling tool supporting these three classes of module de-velopment, the modelling application is represented not only by a strictseparation of modell development and application. The modell application


Computer Techniques in Environmental Studies 607

is characterized by the variation of Parameters/Data and Algorithms. Themodelling application is now becoming a character as a kind of program-ming. Modell application and a following new modell combination can beperformed alternating. The development and application process is merg-ing. But this work is only possible by using a well supporting tool in thisprocess. It has to give a non programmer the power to combine existingmodules in a right order to fit the modelling scheme without any knowledgeabout programming paradigms, data structures and formats and so on.

This paper will point out how can a architecture for a modelling systembased on the pure object-oriented approach be constructed. This architec-ture is used within the Object Modelling System, the modelling engine ofthe Object Modelling System. Section 2 gives an overview about our systemrequirements and object definitions in modelling, section 3 will introducethe design and implementation of the Object Kernel and section 4 will showthe embedding of the kernel in a modelling system.

2 Some Modelling Development System De-

sign Aspects

The development of the Object Modelling System was derived from a projectcalled "Object-Shell" [5, 4]. The goal of this project was to provide anobject-oriented user interface on the top of the UNIX operating system toenable an object-oriented interaction with UNIX. Such a tool is very us-able for prototyping-oriented software development in general [2] whereasuser want testing only aspects or a particular behaviour of software proto-types. These requirements in general software develpment are identical tothe modelling process. Modeller sometimes wants to build an executablemodell only for some application cases. Thats a typical procedure in scien-tific computing.

There where defined some design requirements in building such a systemshell.

• The system should only satisfy the pure object-oriented approach insystem design. Operations allowed are the object creation and deletionand a type save interaction of object via messages.

• The prototyping (modelling) system should be work on the top ofC++ libraries. Because this language is becomming more and morepopular, a lot of code is available. C++ allows to integrate C andFORTRAN routines as well.

• To achieve best performance balance in program (model) generationand execution, pure interpretative or compiling working methods arerejected because of many disadvantages in prototyping/modelling [5].



An incremental compiling and linking method should be applied sav-ing both (i) short program preparation time for building an executableand (ii) a time efficient run time to handle complex simulation.

• Platform independence should be reached as far as possible to supporta range of different architectures. RISC architectures are preferedbecause of relatively simple machine code structure. This feature isimportant for the efficient mapping of object-oriented commands intoan executable without any system compiler or linker.

• Operating system support should be given to systems supporting acommon file format for executables. This is complied by using the Exe-cutable and Linkable Format (ELF) [9] of some SVR4 UNIX derivates.Solaris, Irix and newer versions of Linux are supporting this format.The ELF defines a common file structure for executables under differ-ent operatring systems and hardware architectures.

• All software for developing such a system should be based on publicdomain products. Therefore the GNU tools are used for softwaredeveloping exclusively.

Matching all these topics at the same time available prototyping ori-ented development platforms are not suitable enought for such a system.They only satifying particular aspects as noted above. A good orientationfor developing such a system is given by the operating system research.Object-oriented Microkernel Operating Systems seems to be qualified for aninteractive programming/modelling. They deal with some interesting ar-chitecture characteristics like for example a non complex kernel responsiblefor object management, migration and message passing and some additionalbut limited features like inter-process communication. In order to this archi-tecture paradigm a kernel for prototyping/modelling was designed to fulfita real application in modelling.

Next section will point out the design and implemantation of the ObjectKernel.

3 The

Kernel architectures in computing science reserach in general are character-izes by a basic and limited functionality to realize a well defined amountof tasks. This design is supporting the maintenace, flexibitity, and robust-ness of the sourounding software environments due to strong separated re-sposibilities. Kernels are dealing with features like ressource management,communication, strong hardware related operations. In operating system(research) such examples are for example the MAGE kernel [1] the archi-tecture of the iAPX 432 System [10] and the Spring Operating System [8]



Hence it is recommended to model the architecture of the Object ModelingSystem (QMS) closely to object-oriented (operating) systems. The messagecontroled interaction of object-oriented operating system components andthe direct support of object-oriented user processes are main properties ofsuch systems as well [12, 3].

Object A

Figure 1: Object Interaction

Kernels in terms of object-orientation are only responsible for objectcreation and communication. They are realizing a full object managementwhich consist of:

1. Ressource management for object spaces and

2. controlling the type save message interaction between objects withmessage identifiers and oarameters (Fierure IVL/WULi Wiling, L11C LJ^U DCIVU IJLlCdOClgC UlLUlCLUUlmessage identifiers and parameters (Figure

Kernel space

CREATE ObjectDELETE Object

Object "*— MESSAGE*

User space

Variables

AssignmentsControl statementsExpressionsFunctions

Libraries(System,environmental libs e.g.Geohyd)

Figure 2: kernel-approach

If such an approach wants to be applied for a prototyping/modellingsystem a C-h-h system library is required to implement programming basics



like assignments, control statements, expressions, etc. The implementedKernel System Library provides ca. 20 C++ classes in a Smalltalk likeorder for realizing basic programming features. Now an unique systemview of all nessesary elements of a programm/modell can be applied inobject-oriented terms. It doesn't matter how complex are algoritms inside amessage implementation of an object. The object kernel is only handling theinterface of the message to realize the C++ method call (C++ terminology).The principle is illustrated in Figure 2.

(Modelling)Graphical User Interface

IPC

C++ i Smalltalk] ] \- - -

Object Management

ELF Management

SPARC ] MIPS \ \ RS6000 \ \

Modelling front end

Object-oriented langu

Object Manipulation

Common Executable

Machine dependent c

age interfaces

Interface

ode

Figure 3: The Object Kernel Layered Architecture

The implemented Object Kernel structure is shown in Figure 3. This isa layered architecture whereas the different boxes are partial implementedas C++ classes. There are well defined interfaces for using features of thelayers but only the nearest underlaying class can be accessed. The directaccess from for instance the object management to the hardware relatedlayers on the bottom of the Figure is prohibited. The layer responsibilitiescan be notet as follows:

Language Interface Layer This Layer implements the language interfaceof the kernel. It defines the syntax of the accepted object-orientedlanguage. Currently there is a C++ style syntax available with someenhancements to manage instruction objects a la Smalltalk. The defi-nitions for lexical and syntax analyses are implemented using the GNUflex and bison tool. The Language Interface Layer is transfering state-ments of a concrete incomming (modelling) source script into generalcalls to the underlaying object management layer. This layer can onlyperform syntax checks of a source script.

Object Management Layer It is realizing the object management interms of storing meta information about all related (i) static infor-mation of C++ classes like inheritance relations, class size, message



(method) list, parameter lists of messages, etc. and (ii) di/normc m-formation like objects and their relations. The layer is storing allthese information into several hashtables. It can verify the semanticcorrectness of a command.

Elf Management Layer This layer/class is managing the analysis andmanipulation of an executable. There are routines for extractingheaders, sections (e.g. text, data, rodata) and additional informa-tions like symbol or string tables from an existing executable. Usingthis layer a fast access to particular region inside the executable forobject management is possible. These routines are applicable for allELF supporting operating systems.

OPCode Layer The OPCode Layer implements the processor relatedparts of an executable. This means real opcode instruction for somebasics like (i) pommefer pushing into stack or registers and (ii) m/k toa library function inside an executable. These instructions are usualyplaced inside the text-section of an executable to enable a processor-specific execution. The number of needed opcodes for object manage-ment is only about 14 on Spare architecture example.

The layers are direct corresponding to C++ classes in structure, andis reflected by the class and module dependencies. The OPCode Layer hasan additional so called abstract interface class, which deals with interfacemethods to all derived classes. The amount to port the software to otherprocessor architectures like MIPS or RS6000 is limited by adding a newC++ class which realizes the Opcode. If the operating system is not sup-porting the ELF Format, the ELF Layer has to be replaced by a COFF(Common Object File Format) for instance. Then the porting amount isincreasing.

The total size of source code nessesary to build the Object Kernel forthe SPARC/Solaris architecture with C++ interface is only about 4500lines of C++ Code, the executable Object Kernel takes only 70 KB. Thecomplexity of the system is minimal. Maintenance and error localizationbecomes easy. In comparison to known modell development environments,the programm (modell) preparation time using our incremental compilingand linking scheme takes up to 1000 times faster than conventional methods.

4 Embedding the Object Kernel into a Mod-

elling System Architecture

The Object Kernel is currently representing only one element in modellingsystem development. Beside the Object Kernel there are components like

DB, ZWsmn gwpporf %sfemg Dgg or Gmp/Mcaf [/ger



GUI (Figure 4). The GUI component in particular is separated from themodelling kernel. Graphical user interface and the Object Kernel are com-municating using an Inter Process Communication IPC facility (Figure 3).Currently we are using a TCP socket communication and we defined a pro-tocoll for information exchange.

Figure 4: Interacting Subcomponents in OMS Development

Using the GUI the modeller is constructing his software modell withicons, pictograms, etc. He is designing the interaction of objects using agraphical editor. All static informations are provided by the kernel.

The GUI is generating a script corresponding to the Object Kernel lan-guage syntax (e.g. C++). The information exchange protocol transmits thesource to the kernel, which is permanently running on a modelling server.The kernel is listening on defined ports and is expecting modelling com-mands. Inside the protocol there are commands for executable generation,execution, tracing, etc. The generation and execution of a model is locatedon the modelling server. Results are transmitted to the GUI.

This architecture of a pool of loosely coupled tools leads to more flexibil-ity in modelling. Both the GUI and the kernel can run on the same machinebut it is not nessesary. Also PC's can work as an modelling front end run-ning MS-Windows. They tcp network support is the only precondition tointegrate it. As GUI we are prefering public domain software products likethe Tk Toolkit [11], which is available on many platforms.

5 Conclusion and Outlook

Because of the very suitable application of object-oriented techniques forsoftware design and implementation also in environmental domains, thisapproach in software construction is used for building a modelling system.



A closely design of a modelling system related to microkernel based object-oriented operating systems was realized. Such a system is characterized bya maximum support of interactivity due to these simple object operationsand a low complex structure.

Building such development systems in object-oriented structure too, thewhole modelling system architecture becomes much easier because of theintegrative system architecture for modelling system, modelling librariesand models. Every simulation within the system is viewed as an interactionbetween objects. Objects can be all resources in problem description andsolution.

The previous work on the Object Kernel shows the suitability of the pureobject-oriented approach building a system for experimental software devel-opment in general and modelling software in special. Due to the homogenoussystem view in library design and modelling system development architec-ture the complexity of the modelling system decreases to a minimum. Main-tenace, realbility, robustness and type security are some feautures causedby the pure object-oriented approach and micro-kernel implementation.

The flexibility of the system application is determined by an direct sup-port of several Operating Systems using the SVR4 Executable and Link-able Format and RISC Architectures. These configurations seems to bethe most popular HW/SW architectures in scientific applications becausethey are scalable from desktop to supercomputers in one architecture, costefficient and universal usable. The usage of a distibuted modelling architec-ture based on the UNIX IPC facility and the separation into (i) a graphicalmodelling front end for interactive modell construction and (ii) a modellingenginge (Object Kernel) for the modell generation and execution gives moreinteraction power to the PC/windows and moves the modell execution ontothe computing-oriented RISC/UNIX world.

Our future work is mainly focused on the integration of more HW plat-tforms like the new Pentium Architecture and the additional Object Kernelsupport of Windows NT. On the same time we are also active in adopting ex-isting environmental software to the object modelling system. We startedwith different libraries in groundwater and solute transport modelling inconjunction with the approach of Hydrological Response Units (HRU) [7]in geohydrolocical river basin modelling.

References

[1] M. J. Accetta, R. V. Baron, W. Bolosky, and D. B. Golub. Mach: ANew Kernel Foundation for UNIX Development. In Summer Confer-ence Proceedings, pages 93-112. USENIX-Association, June 1986.

[2] W. R. Bischofberger and G. Pomberger. Prototyping-Oriented SoftwareDevelopment, Concepts and Tools. Springer-Verlag, 1992.



[3] R. H. Campbell. Principles of Object-Oriented Operating System De-sign. Technical Report UIUCDCS-R-89-1510, University of Illinois atUrbana-Champaign, April 1989.

[4] O. David. Entwurf und Implementation einer objektorientiertenSHELL. Internationales Wissenschaftliches Kolloquium, September1994.

[5] O. David. Entwurf und Implementation einer objektorientierten UNIX-Shell, ein prototyping-orientierter Ansatz. PhD thesis, Technische Uni-versity Ilmenau, February 1995.

[6] O. David. Interactive Environmental Modeling using an Object-Shell.In Proc. International Congress on Modelling and Simulation MODSIM95, volume 4, pages 185-190. MSSA, MSSA, November 1995.

[7] W.-A. Fluegel. Delineating Hydrological Response Units (HRU's) byCIS analysis for regional hydrological modelling using PRMS/MMS inthe drainage basin of the River Broel, Germany. Hydrological processes,9:423-436, 1995.

[8] G. Hamilton and P. Kougiouris. The Spring Nucleus: A Microkernel forObjects. In Proc. 1993 Summer USENIX Conference, pages 147 160,June 1993.

[9] Intel Corp. Excutable and Linkable Format (ELF), Portable FormatsSpec.

[10] Intel Corp. ĝ Zem J32/(%?0 %5̂ m #e/erence MonW, 1981.

[11] J. K. Ousterhout. An Introduction to Tel and Tk. Addison Wesley,1992.

[12] V. P. Russo. An Object-Oriented Operating System. PhD thesis, Uni-versity of Illinois at Urbana-Champaign, 1991.

[13] University Colorado at Boulder. Modular Modeling System Users'sManual, January 1993.


cessing and pipelining. therefore programming languages like fortran · 2014. 5. 16. · therefore...

Documents