- Email: [email protected]
The production of interactive engineering design software using Borland Delphi
Advances in Engineering Software 32 (2001) 789±796
www.elsevier.com/locate/advengsoft
The production of interactive engineering design software using Borland Delphi Paul F. McCombie a,*, Jim Penman b a
Department of Architecture and Civil Engineering, University of Bath, Bath BA2 7AY, UK b Tensar International, New Wellington Street, Blackburn BB2 4PJ, UK Received 27 October 1999; accepted 22 February 2001
Abstract Advances in PC programming systems allow the development of highly interactive engineering design software. Software can work in a way which is obvious to the user, and gives considerable feedback during and after the analysis. If an indication is given of the cost of a design, the user can concentrate on making design decisions, rather than on the mechanics of the analysis. Such programs can be developed to run themselves, making changes to the data and carrying out analysis until an optimum design has been reached. These possibilities are illustrated using a program for the design of reinforced soil structures. q 2001 Civil-Comp Ltd and Elsevier Science Ltd. All rights reserved. Keywords: Design; Programming; Delphi; Reinforced soil
1. Introduction Design tends to be an iterative process, in which different concepts are explored and assessed, before settling on a particular style of solution and re®ning it. If a computer program makes it easier to perform accurate analysis and reasonably reliable costing, the engineer can concentrate on the larger issues, such as type of construction, geometry, and choice of materials. Information given during and after the analysis will guide the engineer in understanding the nature of a problem or in determining an optimum solution. It might sometimes be desirable to make a program ®nd an optimum design itself. A new level of code must be provided which changes data, runs analysis, and checks and assesses results in a way that would normally be under the direct control of the user. The need for the controlling code to access all the other components of the program effectively prevents the common practice of providing separate programs for data entry, analysis, and display of results. The integrated user interface must allow control and monitoring of all these operations. The usefulness of the results will depend upon the program being able to assess a solution on a similar basis to that preferred by the user. As the number of variables and the complexity of their interaction increases, so providing a method to arrive at a * Corresponding author. Tel: 144-1225-826-629; Fax: 144-1225-826691. E-mail address: [email protected] (P.F. McCombie).
solution becomes more dif®cult. A study of the methods employed in manual use of the program is likely to be helpful, at least in providing a starting point; this will become part of an evolutionary approach to program design and veri®cation. This could also establish if there is a need for automation, for example if the preferred method would be tedious or uneconomical manually. 2. The modern programming environment Writing programs following this philosophy would be dif®cult using older programming methods. Modern operating systems provide many tools that would once have had to be written afresh for each new project, or at least copied manually. Because windows based operating systems have established conventions for the behaviour of user interface elements, most of the programming associated with these elements can be provided in standard units; the user interface of the programming environment is designed to manipulate these quickly and easily. Programming systems now provide another layer of standardisation and tools, so that the programmers need only to write the code for non-standard operations. Borland's Delphi, for example, allows the appearance of forms and controls to be designed by placing and moving elements with a mouse on the screen. Many aspects can be altered easily, both at design time and by the program itself while it is running Ð the colour of an element can be changed from black to red with a single line
0965-9978/01/$ - see front matter q 2001 Civil-Comp Ltd and Elsevier Science Ltd. All rights reserved. PII: S 0965-997 8(01)00030-8
790
P.F. McCombie, J. Penman / Advances in Engineering Software 32 (2001) 789±796
of code, or a box repositioned or hidden, or made bigger or smaller. Sets of radio buttons can have items added or removed, and the correct button set before they are shown. Delphi itself writes the main code for the user interface; the programmer writes code into procedures to respond to events occurring when the program is run. In older Windows programming systems many of these things could be done, but it took a greater amount of the programmer's time to produce the desired effect; with a modern system, this is quicker and easier. These event-response procedures can then be called from elsewhere in the program Ð the program can in effect press its own buttons. This ability to make part of the program operate the user interface makes automating the design process a matter of automating the running of the program, rather than writing completely separate code. Delphi also provides tools for inspecting a running program during its development. A program can be run from within Delphi line by line, or to any desired point in the code: values of variables can then be examined and even changed before continuing execution. This is particularly useful when programming the analytical part of a program, as it allows it to be checked and re®ned much more easily than with the older style of program. As with most other advances in computing, the new programming environments have made it much easier than it used to be to produce something really bad very quickly, and they are no panacea; however, by saving time spent in routine tasks, the programmer is able to put more thought into the overall design of the program, and into re®ning the way in which it operates. 2.1. Delphi compared with FORTRAN A possible perceived problem for engineering programmers might be the absence of modern environments using FORTRAN. In their original form, clear programming languages such as Pascal were not well suited to large engineering problems ([1] provided a good discussion of programming languages), as they could not provide dynamic memory allocation, but the Borland extensions to Pascal have done this for over 10 years now. This language, as well as being very easy to read (there is no practical restriction on length of variable names for example, so the shorthand of FORTRAN programming is unnecessary), allows great ¯exibility in user-de®ned data types. This helps organising data Ð a Cartesian-coordinate type could be de®ned to contain three variables x, y and z for example. Other types could then be de®ned which used that type Ð a line-type could have two variables, end1 and end2 of type Cartesian-coordinate. This organisation of data can be taken to whatever level is required. Compilers exist which allow FORTRAN programming for the Microsoft Windows operating system (e.g. Salford Software's FTN95), but the other limitations of the language remain. The ease with which Delphi code can be structured, the easy syntax of
Pascal, and the high level debugging tools within Delphi all make it much easier to produce code which is reliable, an obviously fundamental requirement of engineering software. 2.2. Delphi and object oriented programming A further advantage of Delphi compared with FORTRAN is that it is set up for object oriented programming. An object contains a group of data and methods that acts on the data; a line type might have a function, which is passed a point of type Cartesian-coordinate and returns the distance from the line. The resulting code is very highly organised and easy to read and adapt. Combined with the ability to create new object instances at run-time (dynamic allocation), object oriented programming allows routine use to be made of sophisticated programming techniques. The use of objects greatly facilitates work with the Windows interface; the functionality of Delphi is provided through objects. Delphi is not a strict object-oriented language, in that it is possible to have data, procedures and functions which exist outside objects, and it is possible to allow data within objects to be operated on directly. While this might be `impure' from a purely academic viewpoint, on a practical level it allows the programmer to use object oriented approaches when they are advantageous, and more traditional approaches when they are quicker and easier. Cardelli [2], for example, gives a discussion of the reasons this ¯exibility is advantageous. 2.3. Object oriented programming in other languages It is possible to use object oriented techniques in FORTRAN (e.g. Ref. [3]), but it is not easy. Cary et al. [4] concluded that FORTRAN was inadequate compared with C11. C11 may be the most widely used objectoriented language, being well suited to the needs of professional programmers. It is generally acknowledged, however, that it takes longer to code in C11 than it does in Delphi, and the language is nothing like as easy to read and so debug as Pascal. Given that much engineering design software is written by people who are engineers ®rst and software writers second, this is important. It is also true that software written at a higher level is much less likely to be tripped up by the regular changes that are made to operating systems, and one of the main advantages of C11 compared with Delphi is that it is easier to program at a lower level. Another advantage offered by Delphi, although not exploited in the example discussed below, is the ease with which databases can be used. It could be useful, for example, to make a link between a design program and a database of jobs, storing both general data and the data used in the design. Components available within Delphi allow the programmer to make such links with an absolute minimum of programming. Apart from Delphi and C11, the other most widely supported and used object oriented language is Java. Java is used primarily for writing small applications to
P.F. McCombie, J. Penman / Advances in Engineering Software 32 (2001) 789±796
791
Fig. 1. Winwall during the design of a reinforced soil wall undergoing seismic loading.
be loaded from the World Wide Web into a browser and run within an HTML document. The attraction of doing this is that the result code is device independent, and can be made widely available with a minimum of effort. However, Java is limited to operating through HTML, and for the purposes of engineering design, one of its strengths becomes a serious weakness. A big attraction of Java compared with ActiveX controls, is that it cannot get at the user's data storage; for use over the Internet, this is an important security feature, but for running design software it is a serious limitation. The size of program that can sensibly be downloaded over the Internet is also a serious limitation on the capability of such software, and its usefulness for engineering design is very limited. A much more powerful approach to making software available over the Internet is the application server model, in which the user only needs to download user interface information, and the program itself can be large and complex, and kept on the server. Furthermore, it is possible to make any Windows program available in this way, so there is no advantage to using Java for large applications. There are many other object oriented languages available, but none appear to offer the combination of ease of programming, wide support, and suitability for engineering design software, that is offered by Delphi. 3. Winwall Ð an example of interactive design programming The program `Winwall' was written by the ®rst author for Tensar International; it allows the design of reinforced soil retaining walls and steep slopes following any of eight
different methods [5±10]. Automatic design procedures are available for half of these methods. A screen-shot of the program during the design of a reinforced soil retaining wall to the Institut fuÈr Bautechnik method, with seismic loading, is shown in Fig. 1 (the cost of the design shown has been concealed). The program produces printed output in English, French, German, Spanish or Chinese. A cutdown version of the program modi®ed for overseas use has the added feature that all text in the user interface can be displayed in English, French, German, Spanish or Dutch. 3.1. Program organisation Although the program makes use of colour in conveying information to the user, most of the colour on the screen is set by the user in the Windows environment. In the interests of clarity of reproduction, a high contrast monochrome scheme has been set before producing the screen images used in this paper. The main features of the program can be seen in Fig. 1. The program uses the `Multiple Document Interface' (MDI) format; this is a standard format for programs which deal with data ®les (most commonly word processors and spreadsheets) which allows more than one ®le to be opened at any one time. At an early stage in its development, the program allowed multiple ®les to be opened, but it was found that the feature was little used and the complexity associated with this was causing more trouble than it was worth. The primary use of the MDI format now is that it allows a number of windows (`child' windows) to be opened at the same time within the main window, and ensures that their behaviour relative to each other is consistent.
792
P.F. McCombie, J. Penman / Advances in Engineering Software 32 (2001) 789±796
The user interface consists of a main menu and a set of buttons along the top of the screen (a `toolbar'), and a space below in which various child windows are opened and closed. The buttons all have `hints' Ð short prompts which appear when the cursor is held over them, indicating their purpose. A longer message may also appear at the bottom of the screen. These hints can give important assistance to the new user, and in Delphi require little more programming than typing out the message. The core data associated with each design are kept in a single record which can be written to or loaded from a data ®le. When a ®le is opened, or a new ®le created, this data is put into an object (the Wall Object), which is seen by the user as a child window (the Wall Window). This window can be seen at the top centre of Fig. 1; it shows a crosssection of the wall, and has the name of the open ®le as its caption. The Wall Object contains methods for initialising itself and all of the data, drawing the cross-section, and making changes in response to data entered by the user. The Wall Object also holds much of the data created during the running of the program, such as information about the status, and results. Every other window concerned with the design refers to it, and it responds directly to some menu commands. Most data entry is via child windows (forms) which contain a variety of controls, including edit boxes, pulldown lists, and radio buttons, with diagrams and text where appropriate to clarify what is required. These forms can be opened by clicking on buttons or menu items at the top of the screen; most can then be kept open while the effects of changes are being investigated, and they can be arranged on the screen by the user to suit the design being carried out. Some forms open modally Ð that is, they must be completed and closed before the program can do anything else. Modal forms are used for carrying out the automatic design processes. Apart from the Wall Window, the only form that must be open as long as a ®le is open is the Results Form. This allows the method of analysis to be selected, shows the overall results (whether or not the design is safe in various respects, and the cost), and contains buttons to start the analysis or automatic design. The use of the Wedges Form together with the Wall Window is shown in Fig. 1. Wedges of reinforced soil can be checked at any level in the structure. The results are shown in the table, and graphically in the Wall Window. Wedges that are unsatisfactory are drawn in red, giving the user a quick visual indication of the status. The program uses this feature in many instances when carrying out a design or checking stability. This paper will now concentrate on a selection of forms to illustrate the principles used.
Fig. 2. Facing selection form.
right appears for some classes to allow selection of a subclass. Further choices may be offered by sets of radiobuttons. The edit boxes show some relevant numbers, and when appropriate allow editing. When the user makes changes, these are passed instantly to the Wall Object and shown in the Wall Window; a method in the Wall Object renders any previous results out-of-date. If numbers are changed in the boxes at the bottom of the form, they are not acted upon until the `SET' button is pressed. In Delphi only a few lines of code are needed to select the controls to be seen, and their contents, to re¯ect the current design. In this way, only the information the user needs to be aware of is displayed at any one time. 3.3. Geometry Entry Form The Geometry Entry Form takes the main design parameters Ð the height of the wall, and so on. To make it clear what is required, the edit boxes are placed on a diagram. With Delphi, it is easy to create a form which can be shown or hidden at will, and made modal or non-modal; the ¯exibility is far greater than with simple dialogue boxes. Fig. 3 shows the form with the face angle disabled, as it cannot be changed for the facing type in use. The `De®ne Grid
3.2. Facing selection form This form allows the user to choose a facing system for the design (Fig. 2). The box at the top left of the form allows the user to choose the class of facing. The box at the top
Fig. 3. Geometry entry form.
P.F. McCombie, J. Penman / Advances in Engineering Software 32 (2001) 789±796
793
Fig. 4. Spacing curves and grid layout form.
Lengths' button brings up a dialogue box in which the reinforcement lengths can be set in other ways; it is not shown for all design methods. When the user has entered all the required values, pressing the SET button makes the program read all the data and checks it for consistency before passing it on to the Wall Object. Any problems are reported to the user in simple message boxes; in some cases a value will not be accepted, in other cases a warning is shown and the user is asked to con®rm they wish to use the values they have entered. 3.4. Spacing curves and grid layout forms These forms are shown together (Fig. 4) because they are used together in some design methods, in which the Spacing Curves Form provides the user with the information needed to decide on reinforcement placing. For each layer, the vertical spacing (Sv) is plotted against the height up the wall face. The curves show the maximum spacing that can be used to avoid rupture failure (the solid line) and serviceability failure (the dashed line). As the user speci®es the reinforcement layout, using the various buttons and edit boxes in the Grid Layout Form, both the Wall Object and the Spacing Curves Form are continuously updated, so an optimum layout can be arrived at quickly. Additionally, each individual grid is checked for rupture, anchorage, and if appropriate serviceability; if it should fail any of these, an arrow points to it and a message is shown indicating how it has failed. This saves the user having to judge whether or not a plotted grid crosses a curve. When more than one type of reinforcement is used, new curves are added to indicate the safe spacing for each type. These are shown in the same colour as the grid type is plotted, for clarity. Many calculations are required to display this form, but it still refreshes very quickly in a modern computer (normally a fraction of a second).
the program. The cost of the current design is shown at the top of the form, and is continually updated as the design is changed (note that the price has been concealed for this example). The design method is selected in the box below. When the design method is changed, all open forms are updated to meet the requirements of the new method, and any no longer required are closed. The main results of the analysis are shown in the panels below. In the example shown, a wall is being designed to resist seismic as well as static loads, and the set of radio buttons at the bottom left of the form allows the user to choose the conditions for which the results are to be displayed. This form also contains buttons that execute the code to analyse the external stability, the internal stability, and to do the design. This last button brings up the modal form described below.
3.5. Results Form The Results Form (Fig. 5) is the main `control centre' of
Fig. 5. Results form.
794
P.F. McCombie, J. Penman / Advances in Engineering Software 32 (2001) 789±796
Fig. 6. Bautechnik method design form.
3.6. Bautechnik method design form This form (Fig. 6) is an object which contains all the code for running the rest of the program to carry out automatic designs for this design method. The methodology followed is based upon an approach that would be taken by an engineer using the program in a very systematic way to arrive at a design, which is optimised both for cost and for ease of construction. It appears when the `Design' button is pressed in the Results Form. If the facing type permits it, the user will be able to change some or all of the numbers shown, which control the options available to the program for carrying out the design. Pressing `Proceed' launches the automatic design process. If the `Keep grid lengths equal' button has not been pressed, the program will carry out a design for a range of back-face angles (the angle of the back of the reinforced soil block), and then settle on the cheapest satisfactory design. The Design Form ®rst determines the length of reinforcement needed to satisfy external stability requirements. It does this by setting a base length, then executing the procedure which responds to a press of the `Check External Stability' button in the Results form Ð in effect, it presses the
button. It then increases the length if necessary until the results are satisfactory. It then does the equivalent of pressing the `Check Internal Stability' button to ®rst of all ®nd out the total reinforcement force required, and then to check successive reinforcement layout options, which it determines to support that strength. As there are a number of different reinforcement types and spacing that can be used, there are usually large numbers of designs that would be safe. The initial layouts are selected to be likely to work on the basis of simple rules of thumb, and are then re®ned for optimum economy while ensuring ease of construction. The most economical design arising from the initial options is then set before control is handed back to the user. While this process is carried out, some of the iterations are shown to the user so that progress can be monitored. For small structures requiring little reinforcement, the process can take just a few seconds, but for high structures the range of options increases considerably, and the time taken to reach an optimum solution can exceed one minute. This is considerably faster than can be achieved by using the program manually, and it is usually very dif®cult to arrive at a more economical design. 3.7. External Stability Form This form (Fig. 7) shows the economy in the use of code which is possible with the Delphi programming system. All graphical output within Delphi is handled by the same set of procedures, whether it is to the screen or to a paper output device. It is therefore possible to get the same code to write to screen or printer simply by passing it the address of the appropriate device. There are still issues of scaling which must be handled, and these are done by the program. All output is handled by a set of routines written by the
Fig. 7. External stability calculations form.
P.F. McCombie, J. Penman / Advances in Engineering Software 32 (2001) 789±796
programmer which take into account the capabilities of the device. As these procedures and the data they use are embedded in an object de®nition, it is possible to make separate instances of the object at run-time to deal with screen and paper output, allowing both screen and printer to be addressed at the same time on a different basis. The External Stability Form makes use of this capability by using the same code that produces the printed output to put that output into a window on the screen to be read by the user. This technique is used in other windows, especially in the print and plot preview windows which display on screen exactly what will be put onto paper. 4. Program development The development of Winwall was in¯uenced by the fact that the design methods used could not be fully explored until they were entered into the program. In the early stages of development of a design method, the program becomes an experimental tool, while still providing a working tool for established methods. This was controlled in Winwall by using dongles to restrict the methods available to different users. Small cores of users were selected for preliminary investigations of new methods. These groups would check the results of the program, offer feedback on the usability, and discuss principles for the use of the program. In some cases these groups identi®ed bene®ts of providing an automatic design process. They would then provide indications of possible approaches, and examine the results. Given that the design method is only worked out in full detail at the programming stage, it is essential that the programmer has a full understanding of the problem to be solved, and is able to make design decisions during the programming. For a large and complex program such as Winwall, signi®cant knowledge of programming is required. However, for more restricted problems, the simplicity of working in Delphi would enable programs to be written by engineers with only limited programming knowledge. Understanding of the problem is more important than knowledge and experience of programming; the latter becomes important only as the complexity of the problem increases. Once the programming of a design method has passed the initial development stage, it is inevitable that new features will be required, new con®gurations must be designed for, and preferences will emerge to have things work slightly differently. The approach taken for Winwall is to have a user of the program who is familiar with its development take responsibility for considering initial enquiries or reports of problems. This allows items requiring new work to be assigned an appropriate priority considering both their value and the amount of work involved; they can then be addressed in a planned manner alongside main development work.
795
5. Discussion The use of Delphi, including object-oriented features, allows the user to be presented with a modern interface, and plenty of information and feedback as a design is being carried out and checked. The resulting ease of use is such that the program can be picked up quickly by occasional users. The standard of interface that can be achieved is rather better than that given in modern wordprocessing software, which must cater for a very wide range of user requirements. Ef®ciency of programming, and economy in the use of code, allows the programmer to move beyond simply providing an analytical tool. It becomes necessary for the programmer to look at the design process in its entirety; in so doing, it will sometimes be possible to produce additional code to automate the design process. In some cases this can be a challenging task, and it certainly requires an understanding of the thought processes that could be followed by an engineer in arriving at a design. An important aspect is to ensure that the program will work satisfactorily for con®gurations of problem beyond those originally envisaged when the need for the program is identi®ed. In a highly iterative design process, it can become very dif®cult to ensure that the program does not become locked into an extended loop as it derives new solutions based upon what it has done before. In a problem which has many variables, automated design can be very dif®cult to program, and an assessment must be made of the potential savings in terms of design time and economy of solution compared with the programming cost. While many programmers might wish to have the facilities offered by Delphi, the fact that the programming language is not FORTRAN might be seen as a disadvantage. However, it is not excessively dif®cult to convert FORTRAN code to Delphi. The ability to de®ne data types, procedures and functions allows the programmer to write code to replicate FORTRAN subroutines, even using the same names in many cases. Automatic replacement functions in the programming environment can be used to facilitate the conversion. Delphi is supplied with a number of example programs, which can easily be adapted to meet the needs of a new task. While Delphi allows a simple program to be written extremely quickly (the traditional engineering program of data input, analysis, and output of results is very easy), a complex and sophisticated user interface still requires a signi®cant amount of programming. However, Delphi is probably the quickest way to achieve it (much faster than C11), and has an advantage of a powerful but compact programming language (unlike Basic). Furthermore, Pascal encourages good structured programming; while FORTRAN allows this to be achieved, it does not make it easy. Delphi produces 32 bit code, and allows dynamic allocation of simple variables, arrays, records and objects, so memory is unlikely to be an issue, and large problems can be handled and solved quickly.
796
P.F. McCombie, J. Penman / Advances in Engineering Software 32 (2001) 789±796
6. Conclusions
References
A modern object-oriented programming system can be used to present large, complex programs to the user in a simple way, providing good feedback and allowing rapid use. This is particularly valuable in engineering design, which is usually iterative. For a range of problems, this iteration can be handled entirely by a computer program; the ability to include partial costing is essential for this automation. When automation is too dif®cult to implement, or not worth implementing for the amount of use to which it will be put, clear numerical and visual presentation of information to the user is important in supporting the decision-making process. A quality of interface can be achieved which is at least up to the standard of a modern word-processor, and thus meets general expectations of ease of use.
[1] Smith IM, Grif®ths DV. Programming the ®nite element method. New York: Wiley, 1988. [2] Carddelli L. Bad Engineering Properties of Object-Oriented Languages http://www.research.compaq.com/SRC/articles/199702/ BadPropertiesOfOO.html 1997. [3] Decyk VK, Norton CD, Szymanski BK. Expressing object-oriented concepts in Fortran90, 16. New York: ACM Fortran Forum, 1997. p. 1. [4] Cary JR, Shasharina SG, Cummings JC, Reynders JVW, Hinker PJ. Comparison of C11 and Fortran 90 for object-oriented scienti®c programming. Los Alamos National Laboratory as Report No. LAUR-96-4064, 1996. [5] British Standards Organisation. BS8006: Code of practice for strengthened and reinforced soils and other ®lls: 1995. BSI, London 1995. [6] Department of Transport. Reinforced and anchored earth retaining walls and bridge abutments for embankments, Technical Memorandum (Bridges) BE 3/78 (revised 1987). London: HMSO, 1987. [7] Department of Transport. HA68/94 Design methods for the reinforcement of highway slopes by reinforced soil and soil nailing techniques. London: HMSO, 1994. [8] The Deutches Institut fuÈr Bautechnik. Approval Certi®cate Number Z 20.1-102 for reinforced soil structures. Berlin: DIBT, 1990. [9] CES/GCO Hong Kong. Endorsement Certi®cate RF1/90(4) for reinforced ®ll structures. Hong Kong: CES/GCO, 1990. [10] Tensar International. The design of reinforced soil structures using Tensar Geogrids. Blackburn: Tensar International, 1996.
Acknowledgements The authors wish to thank Tensar International for permission to make use of their computer program in illustrating this paper.
www.elsevier.com/locate/advengsoft
The production of interactive engineering design software using Borland Delphi Paul F. McCombie a,*, Jim Penman b a
Department of Architecture and Civil Engineering, University of Bath, Bath BA2 7AY, UK b Tensar International, New Wellington Street, Blackburn BB2 4PJ, UK Received 27 October 1999; accepted 22 February 2001
Abstract Advances in PC programming systems allow the development of highly interactive engineering design software. Software can work in a way which is obvious to the user, and gives considerable feedback during and after the analysis. If an indication is given of the cost of a design, the user can concentrate on making design decisions, rather than on the mechanics of the analysis. Such programs can be developed to run themselves, making changes to the data and carrying out analysis until an optimum design has been reached. These possibilities are illustrated using a program for the design of reinforced soil structures. q 2001 Civil-Comp Ltd and Elsevier Science Ltd. All rights reserved. Keywords: Design; Programming; Delphi; Reinforced soil
1. Introduction Design tends to be an iterative process, in which different concepts are explored and assessed, before settling on a particular style of solution and re®ning it. If a computer program makes it easier to perform accurate analysis and reasonably reliable costing, the engineer can concentrate on the larger issues, such as type of construction, geometry, and choice of materials. Information given during and after the analysis will guide the engineer in understanding the nature of a problem or in determining an optimum solution. It might sometimes be desirable to make a program ®nd an optimum design itself. A new level of code must be provided which changes data, runs analysis, and checks and assesses results in a way that would normally be under the direct control of the user. The need for the controlling code to access all the other components of the program effectively prevents the common practice of providing separate programs for data entry, analysis, and display of results. The integrated user interface must allow control and monitoring of all these operations. The usefulness of the results will depend upon the program being able to assess a solution on a similar basis to that preferred by the user. As the number of variables and the complexity of their interaction increases, so providing a method to arrive at a * Corresponding author. Tel: 144-1225-826-629; Fax: 144-1225-826691. E-mail address: [email protected] (P.F. McCombie).
solution becomes more dif®cult. A study of the methods employed in manual use of the program is likely to be helpful, at least in providing a starting point; this will become part of an evolutionary approach to program design and veri®cation. This could also establish if there is a need for automation, for example if the preferred method would be tedious or uneconomical manually. 2. The modern programming environment Writing programs following this philosophy would be dif®cult using older programming methods. Modern operating systems provide many tools that would once have had to be written afresh for each new project, or at least copied manually. Because windows based operating systems have established conventions for the behaviour of user interface elements, most of the programming associated with these elements can be provided in standard units; the user interface of the programming environment is designed to manipulate these quickly and easily. Programming systems now provide another layer of standardisation and tools, so that the programmers need only to write the code for non-standard operations. Borland's Delphi, for example, allows the appearance of forms and controls to be designed by placing and moving elements with a mouse on the screen. Many aspects can be altered easily, both at design time and by the program itself while it is running Ð the colour of an element can be changed from black to red with a single line
0965-9978/01/$ - see front matter q 2001 Civil-Comp Ltd and Elsevier Science Ltd. All rights reserved. PII: S 0965-997 8(01)00030-8
790
P.F. McCombie, J. Penman / Advances in Engineering Software 32 (2001) 789±796
of code, or a box repositioned or hidden, or made bigger or smaller. Sets of radio buttons can have items added or removed, and the correct button set before they are shown. Delphi itself writes the main code for the user interface; the programmer writes code into procedures to respond to events occurring when the program is run. In older Windows programming systems many of these things could be done, but it took a greater amount of the programmer's time to produce the desired effect; with a modern system, this is quicker and easier. These event-response procedures can then be called from elsewhere in the program Ð the program can in effect press its own buttons. This ability to make part of the program operate the user interface makes automating the design process a matter of automating the running of the program, rather than writing completely separate code. Delphi also provides tools for inspecting a running program during its development. A program can be run from within Delphi line by line, or to any desired point in the code: values of variables can then be examined and even changed before continuing execution. This is particularly useful when programming the analytical part of a program, as it allows it to be checked and re®ned much more easily than with the older style of program. As with most other advances in computing, the new programming environments have made it much easier than it used to be to produce something really bad very quickly, and they are no panacea; however, by saving time spent in routine tasks, the programmer is able to put more thought into the overall design of the program, and into re®ning the way in which it operates. 2.1. Delphi compared with FORTRAN A possible perceived problem for engineering programmers might be the absence of modern environments using FORTRAN. In their original form, clear programming languages such as Pascal were not well suited to large engineering problems ([1] provided a good discussion of programming languages), as they could not provide dynamic memory allocation, but the Borland extensions to Pascal have done this for over 10 years now. This language, as well as being very easy to read (there is no practical restriction on length of variable names for example, so the shorthand of FORTRAN programming is unnecessary), allows great ¯exibility in user-de®ned data types. This helps organising data Ð a Cartesian-coordinate type could be de®ned to contain three variables x, y and z for example. Other types could then be de®ned which used that type Ð a line-type could have two variables, end1 and end2 of type Cartesian-coordinate. This organisation of data can be taken to whatever level is required. Compilers exist which allow FORTRAN programming for the Microsoft Windows operating system (e.g. Salford Software's FTN95), but the other limitations of the language remain. The ease with which Delphi code can be structured, the easy syntax of
Pascal, and the high level debugging tools within Delphi all make it much easier to produce code which is reliable, an obviously fundamental requirement of engineering software. 2.2. Delphi and object oriented programming A further advantage of Delphi compared with FORTRAN is that it is set up for object oriented programming. An object contains a group of data and methods that acts on the data; a line type might have a function, which is passed a point of type Cartesian-coordinate and returns the distance from the line. The resulting code is very highly organised and easy to read and adapt. Combined with the ability to create new object instances at run-time (dynamic allocation), object oriented programming allows routine use to be made of sophisticated programming techniques. The use of objects greatly facilitates work with the Windows interface; the functionality of Delphi is provided through objects. Delphi is not a strict object-oriented language, in that it is possible to have data, procedures and functions which exist outside objects, and it is possible to allow data within objects to be operated on directly. While this might be `impure' from a purely academic viewpoint, on a practical level it allows the programmer to use object oriented approaches when they are advantageous, and more traditional approaches when they are quicker and easier. Cardelli [2], for example, gives a discussion of the reasons this ¯exibility is advantageous. 2.3. Object oriented programming in other languages It is possible to use object oriented techniques in FORTRAN (e.g. Ref. [3]), but it is not easy. Cary et al. [4] concluded that FORTRAN was inadequate compared with C11. C11 may be the most widely used objectoriented language, being well suited to the needs of professional programmers. It is generally acknowledged, however, that it takes longer to code in C11 than it does in Delphi, and the language is nothing like as easy to read and so debug as Pascal. Given that much engineering design software is written by people who are engineers ®rst and software writers second, this is important. It is also true that software written at a higher level is much less likely to be tripped up by the regular changes that are made to operating systems, and one of the main advantages of C11 compared with Delphi is that it is easier to program at a lower level. Another advantage offered by Delphi, although not exploited in the example discussed below, is the ease with which databases can be used. It could be useful, for example, to make a link between a design program and a database of jobs, storing both general data and the data used in the design. Components available within Delphi allow the programmer to make such links with an absolute minimum of programming. Apart from Delphi and C11, the other most widely supported and used object oriented language is Java. Java is used primarily for writing small applications to
P.F. McCombie, J. Penman / Advances in Engineering Software 32 (2001) 789±796
791
Fig. 1. Winwall during the design of a reinforced soil wall undergoing seismic loading.
be loaded from the World Wide Web into a browser and run within an HTML document. The attraction of doing this is that the result code is device independent, and can be made widely available with a minimum of effort. However, Java is limited to operating through HTML, and for the purposes of engineering design, one of its strengths becomes a serious weakness. A big attraction of Java compared with ActiveX controls, is that it cannot get at the user's data storage; for use over the Internet, this is an important security feature, but for running design software it is a serious limitation. The size of program that can sensibly be downloaded over the Internet is also a serious limitation on the capability of such software, and its usefulness for engineering design is very limited. A much more powerful approach to making software available over the Internet is the application server model, in which the user only needs to download user interface information, and the program itself can be large and complex, and kept on the server. Furthermore, it is possible to make any Windows program available in this way, so there is no advantage to using Java for large applications. There are many other object oriented languages available, but none appear to offer the combination of ease of programming, wide support, and suitability for engineering design software, that is offered by Delphi. 3. Winwall Ð an example of interactive design programming The program `Winwall' was written by the ®rst author for Tensar International; it allows the design of reinforced soil retaining walls and steep slopes following any of eight
different methods [5±10]. Automatic design procedures are available for half of these methods. A screen-shot of the program during the design of a reinforced soil retaining wall to the Institut fuÈr Bautechnik method, with seismic loading, is shown in Fig. 1 (the cost of the design shown has been concealed). The program produces printed output in English, French, German, Spanish or Chinese. A cutdown version of the program modi®ed for overseas use has the added feature that all text in the user interface can be displayed in English, French, German, Spanish or Dutch. 3.1. Program organisation Although the program makes use of colour in conveying information to the user, most of the colour on the screen is set by the user in the Windows environment. In the interests of clarity of reproduction, a high contrast monochrome scheme has been set before producing the screen images used in this paper. The main features of the program can be seen in Fig. 1. The program uses the `Multiple Document Interface' (MDI) format; this is a standard format for programs which deal with data ®les (most commonly word processors and spreadsheets) which allows more than one ®le to be opened at any one time. At an early stage in its development, the program allowed multiple ®les to be opened, but it was found that the feature was little used and the complexity associated with this was causing more trouble than it was worth. The primary use of the MDI format now is that it allows a number of windows (`child' windows) to be opened at the same time within the main window, and ensures that their behaviour relative to each other is consistent.
792
P.F. McCombie, J. Penman / Advances in Engineering Software 32 (2001) 789±796
The user interface consists of a main menu and a set of buttons along the top of the screen (a `toolbar'), and a space below in which various child windows are opened and closed. The buttons all have `hints' Ð short prompts which appear when the cursor is held over them, indicating their purpose. A longer message may also appear at the bottom of the screen. These hints can give important assistance to the new user, and in Delphi require little more programming than typing out the message. The core data associated with each design are kept in a single record which can be written to or loaded from a data ®le. When a ®le is opened, or a new ®le created, this data is put into an object (the Wall Object), which is seen by the user as a child window (the Wall Window). This window can be seen at the top centre of Fig. 1; it shows a crosssection of the wall, and has the name of the open ®le as its caption. The Wall Object contains methods for initialising itself and all of the data, drawing the cross-section, and making changes in response to data entered by the user. The Wall Object also holds much of the data created during the running of the program, such as information about the status, and results. Every other window concerned with the design refers to it, and it responds directly to some menu commands. Most data entry is via child windows (forms) which contain a variety of controls, including edit boxes, pulldown lists, and radio buttons, with diagrams and text where appropriate to clarify what is required. These forms can be opened by clicking on buttons or menu items at the top of the screen; most can then be kept open while the effects of changes are being investigated, and they can be arranged on the screen by the user to suit the design being carried out. Some forms open modally Ð that is, they must be completed and closed before the program can do anything else. Modal forms are used for carrying out the automatic design processes. Apart from the Wall Window, the only form that must be open as long as a ®le is open is the Results Form. This allows the method of analysis to be selected, shows the overall results (whether or not the design is safe in various respects, and the cost), and contains buttons to start the analysis or automatic design. The use of the Wedges Form together with the Wall Window is shown in Fig. 1. Wedges of reinforced soil can be checked at any level in the structure. The results are shown in the table, and graphically in the Wall Window. Wedges that are unsatisfactory are drawn in red, giving the user a quick visual indication of the status. The program uses this feature in many instances when carrying out a design or checking stability. This paper will now concentrate on a selection of forms to illustrate the principles used.
Fig. 2. Facing selection form.
right appears for some classes to allow selection of a subclass. Further choices may be offered by sets of radiobuttons. The edit boxes show some relevant numbers, and when appropriate allow editing. When the user makes changes, these are passed instantly to the Wall Object and shown in the Wall Window; a method in the Wall Object renders any previous results out-of-date. If numbers are changed in the boxes at the bottom of the form, they are not acted upon until the `SET' button is pressed. In Delphi only a few lines of code are needed to select the controls to be seen, and their contents, to re¯ect the current design. In this way, only the information the user needs to be aware of is displayed at any one time. 3.3. Geometry Entry Form The Geometry Entry Form takes the main design parameters Ð the height of the wall, and so on. To make it clear what is required, the edit boxes are placed on a diagram. With Delphi, it is easy to create a form which can be shown or hidden at will, and made modal or non-modal; the ¯exibility is far greater than with simple dialogue boxes. Fig. 3 shows the form with the face angle disabled, as it cannot be changed for the facing type in use. The `De®ne Grid
3.2. Facing selection form This form allows the user to choose a facing system for the design (Fig. 2). The box at the top left of the form allows the user to choose the class of facing. The box at the top
Fig. 3. Geometry entry form.
P.F. McCombie, J. Penman / Advances in Engineering Software 32 (2001) 789±796
793
Fig. 4. Spacing curves and grid layout form.
Lengths' button brings up a dialogue box in which the reinforcement lengths can be set in other ways; it is not shown for all design methods. When the user has entered all the required values, pressing the SET button makes the program read all the data and checks it for consistency before passing it on to the Wall Object. Any problems are reported to the user in simple message boxes; in some cases a value will not be accepted, in other cases a warning is shown and the user is asked to con®rm they wish to use the values they have entered. 3.4. Spacing curves and grid layout forms These forms are shown together (Fig. 4) because they are used together in some design methods, in which the Spacing Curves Form provides the user with the information needed to decide on reinforcement placing. For each layer, the vertical spacing (Sv) is plotted against the height up the wall face. The curves show the maximum spacing that can be used to avoid rupture failure (the solid line) and serviceability failure (the dashed line). As the user speci®es the reinforcement layout, using the various buttons and edit boxes in the Grid Layout Form, both the Wall Object and the Spacing Curves Form are continuously updated, so an optimum layout can be arrived at quickly. Additionally, each individual grid is checked for rupture, anchorage, and if appropriate serviceability; if it should fail any of these, an arrow points to it and a message is shown indicating how it has failed. This saves the user having to judge whether or not a plotted grid crosses a curve. When more than one type of reinforcement is used, new curves are added to indicate the safe spacing for each type. These are shown in the same colour as the grid type is plotted, for clarity. Many calculations are required to display this form, but it still refreshes very quickly in a modern computer (normally a fraction of a second).
the program. The cost of the current design is shown at the top of the form, and is continually updated as the design is changed (note that the price has been concealed for this example). The design method is selected in the box below. When the design method is changed, all open forms are updated to meet the requirements of the new method, and any no longer required are closed. The main results of the analysis are shown in the panels below. In the example shown, a wall is being designed to resist seismic as well as static loads, and the set of radio buttons at the bottom left of the form allows the user to choose the conditions for which the results are to be displayed. This form also contains buttons that execute the code to analyse the external stability, the internal stability, and to do the design. This last button brings up the modal form described below.
3.5. Results Form The Results Form (Fig. 5) is the main `control centre' of
Fig. 5. Results form.
794
P.F. McCombie, J. Penman / Advances in Engineering Software 32 (2001) 789±796
Fig. 6. Bautechnik method design form.
3.6. Bautechnik method design form This form (Fig. 6) is an object which contains all the code for running the rest of the program to carry out automatic designs for this design method. The methodology followed is based upon an approach that would be taken by an engineer using the program in a very systematic way to arrive at a design, which is optimised both for cost and for ease of construction. It appears when the `Design' button is pressed in the Results Form. If the facing type permits it, the user will be able to change some or all of the numbers shown, which control the options available to the program for carrying out the design. Pressing `Proceed' launches the automatic design process. If the `Keep grid lengths equal' button has not been pressed, the program will carry out a design for a range of back-face angles (the angle of the back of the reinforced soil block), and then settle on the cheapest satisfactory design. The Design Form ®rst determines the length of reinforcement needed to satisfy external stability requirements. It does this by setting a base length, then executing the procedure which responds to a press of the `Check External Stability' button in the Results form Ð in effect, it presses the
button. It then increases the length if necessary until the results are satisfactory. It then does the equivalent of pressing the `Check Internal Stability' button to ®rst of all ®nd out the total reinforcement force required, and then to check successive reinforcement layout options, which it determines to support that strength. As there are a number of different reinforcement types and spacing that can be used, there are usually large numbers of designs that would be safe. The initial layouts are selected to be likely to work on the basis of simple rules of thumb, and are then re®ned for optimum economy while ensuring ease of construction. The most economical design arising from the initial options is then set before control is handed back to the user. While this process is carried out, some of the iterations are shown to the user so that progress can be monitored. For small structures requiring little reinforcement, the process can take just a few seconds, but for high structures the range of options increases considerably, and the time taken to reach an optimum solution can exceed one minute. This is considerably faster than can be achieved by using the program manually, and it is usually very dif®cult to arrive at a more economical design. 3.7. External Stability Form This form (Fig. 7) shows the economy in the use of code which is possible with the Delphi programming system. All graphical output within Delphi is handled by the same set of procedures, whether it is to the screen or to a paper output device. It is therefore possible to get the same code to write to screen or printer simply by passing it the address of the appropriate device. There are still issues of scaling which must be handled, and these are done by the program. All output is handled by a set of routines written by the
Fig. 7. External stability calculations form.
P.F. McCombie, J. Penman / Advances in Engineering Software 32 (2001) 789±796
programmer which take into account the capabilities of the device. As these procedures and the data they use are embedded in an object de®nition, it is possible to make separate instances of the object at run-time to deal with screen and paper output, allowing both screen and printer to be addressed at the same time on a different basis. The External Stability Form makes use of this capability by using the same code that produces the printed output to put that output into a window on the screen to be read by the user. This technique is used in other windows, especially in the print and plot preview windows which display on screen exactly what will be put onto paper. 4. Program development The development of Winwall was in¯uenced by the fact that the design methods used could not be fully explored until they were entered into the program. In the early stages of development of a design method, the program becomes an experimental tool, while still providing a working tool for established methods. This was controlled in Winwall by using dongles to restrict the methods available to different users. Small cores of users were selected for preliminary investigations of new methods. These groups would check the results of the program, offer feedback on the usability, and discuss principles for the use of the program. In some cases these groups identi®ed bene®ts of providing an automatic design process. They would then provide indications of possible approaches, and examine the results. Given that the design method is only worked out in full detail at the programming stage, it is essential that the programmer has a full understanding of the problem to be solved, and is able to make design decisions during the programming. For a large and complex program such as Winwall, signi®cant knowledge of programming is required. However, for more restricted problems, the simplicity of working in Delphi would enable programs to be written by engineers with only limited programming knowledge. Understanding of the problem is more important than knowledge and experience of programming; the latter becomes important only as the complexity of the problem increases. Once the programming of a design method has passed the initial development stage, it is inevitable that new features will be required, new con®gurations must be designed for, and preferences will emerge to have things work slightly differently. The approach taken for Winwall is to have a user of the program who is familiar with its development take responsibility for considering initial enquiries or reports of problems. This allows items requiring new work to be assigned an appropriate priority considering both their value and the amount of work involved; they can then be addressed in a planned manner alongside main development work.
795
5. Discussion The use of Delphi, including object-oriented features, allows the user to be presented with a modern interface, and plenty of information and feedback as a design is being carried out and checked. The resulting ease of use is such that the program can be picked up quickly by occasional users. The standard of interface that can be achieved is rather better than that given in modern wordprocessing software, which must cater for a very wide range of user requirements. Ef®ciency of programming, and economy in the use of code, allows the programmer to move beyond simply providing an analytical tool. It becomes necessary for the programmer to look at the design process in its entirety; in so doing, it will sometimes be possible to produce additional code to automate the design process. In some cases this can be a challenging task, and it certainly requires an understanding of the thought processes that could be followed by an engineer in arriving at a design. An important aspect is to ensure that the program will work satisfactorily for con®gurations of problem beyond those originally envisaged when the need for the program is identi®ed. In a highly iterative design process, it can become very dif®cult to ensure that the program does not become locked into an extended loop as it derives new solutions based upon what it has done before. In a problem which has many variables, automated design can be very dif®cult to program, and an assessment must be made of the potential savings in terms of design time and economy of solution compared with the programming cost. While many programmers might wish to have the facilities offered by Delphi, the fact that the programming language is not FORTRAN might be seen as a disadvantage. However, it is not excessively dif®cult to convert FORTRAN code to Delphi. The ability to de®ne data types, procedures and functions allows the programmer to write code to replicate FORTRAN subroutines, even using the same names in many cases. Automatic replacement functions in the programming environment can be used to facilitate the conversion. Delphi is supplied with a number of example programs, which can easily be adapted to meet the needs of a new task. While Delphi allows a simple program to be written extremely quickly (the traditional engineering program of data input, analysis, and output of results is very easy), a complex and sophisticated user interface still requires a signi®cant amount of programming. However, Delphi is probably the quickest way to achieve it (much faster than C11), and has an advantage of a powerful but compact programming language (unlike Basic). Furthermore, Pascal encourages good structured programming; while FORTRAN allows this to be achieved, it does not make it easy. Delphi produces 32 bit code, and allows dynamic allocation of simple variables, arrays, records and objects, so memory is unlikely to be an issue, and large problems can be handled and solved quickly.
796
P.F. McCombie, J. Penman / Advances in Engineering Software 32 (2001) 789±796
6. Conclusions
References
A modern object-oriented programming system can be used to present large, complex programs to the user in a simple way, providing good feedback and allowing rapid use. This is particularly valuable in engineering design, which is usually iterative. For a range of problems, this iteration can be handled entirely by a computer program; the ability to include partial costing is essential for this automation. When automation is too dif®cult to implement, or not worth implementing for the amount of use to which it will be put, clear numerical and visual presentation of information to the user is important in supporting the decision-making process. A quality of interface can be achieved which is at least up to the standard of a modern word-processor, and thus meets general expectations of ease of use.
[1] Smith IM, Grif®ths DV. Programming the ®nite element method. New York: Wiley, 1988. [2] Carddelli L. Bad Engineering Properties of Object-Oriented Languages http://www.research.compaq.com/SRC/articles/199702/ BadPropertiesOfOO.html 1997. [3] Decyk VK, Norton CD, Szymanski BK. Expressing object-oriented concepts in Fortran90, 16. New York: ACM Fortran Forum, 1997. p. 1. [4] Cary JR, Shasharina SG, Cummings JC, Reynders JVW, Hinker PJ. Comparison of C11 and Fortran 90 for object-oriented scienti®c programming. Los Alamos National Laboratory as Report No. LAUR-96-4064, 1996. [5] British Standards Organisation. BS8006: Code of practice for strengthened and reinforced soils and other ®lls: 1995. BSI, London 1995. [6] Department of Transport. Reinforced and anchored earth retaining walls and bridge abutments for embankments, Technical Memorandum (Bridges) BE 3/78 (revised 1987). London: HMSO, 1987. [7] Department of Transport. HA68/94 Design methods for the reinforcement of highway slopes by reinforced soil and soil nailing techniques. London: HMSO, 1994. [8] The Deutches Institut fuÈr Bautechnik. Approval Certi®cate Number Z 20.1-102 for reinforced soil structures. Berlin: DIBT, 1990. [9] CES/GCO Hong Kong. Endorsement Certi®cate RF1/90(4) for reinforced ®ll structures. Hong Kong: CES/GCO, 1990. [10] Tensar International. The design of reinforced soil structures using Tensar Geogrids. Blackburn: Tensar International, 1996.
Acknowledgements The authors wish to thank Tensar International for permission to make use of their computer program in illustrating this paper.