- Email: [email protected]
Problems of Very High Level Languages for Process Control Programming
Problems of Very HilIh 'Level Languages fOr iProt~~SClmtTol Programming
fiuenter MusstepT G SCS Scientific Control Systems GmbH Ueberseerin g 8 0-2000 Hamburg 60 . Germany
A BST RAC T The reliability of present large and/or sophistieated software systems is not sufficient. On the other hand a g reat pro gress had been made in the area of hardware reliability in the last few years. The causes of such a behaviour of software systems are shown by analyzin g the usual requirements critically. Furthermore there is a contradiction in g enerai between the necessity of standardizing a g eneral purpose process-control langua ge and the requirements of the non computer-experienced user on special purpose langua g es. As a proposal for the solution of this problem a software production system is briefly described. The basic components of this system are already in use in different areas and are independent of one another. 1. History and Present Situation In the 1950's and in the early sixties most tasks performed by electronic computers had been of numeric nature. The necessary programs usually could be produced by a single individual without particular problems. At that time, the work of a programmer was very similar to that of an artist. Even today, high importance is sometimes attributed to the elegance of a program. On the other hand, the non computer-experienced user was unable to break into this secret science. Consequently, the programmer had to introduce himself to the respective application. However, hardware or programming errors were not considered critical, as a program run could easily be repeated without any damage if an error occurred. Since the mid-sixties both the number of non-numeric and the number of on-line applications have rapidly increased; In the same period decisive improvements were
achieved in the field of hardware reliability. Additionally, the introduction of low-cost, hi g hly efficient "mini-computers" durin g recent years has opened technical possibilities for the construction of interestin g hierarchically structured computer networks. However, when applying these technical possibilities numerous new problems arise. The volume of pro g rams and the necessity to realize such an EOP-system within 1 or 2 years result in a si gnificant enlargement of the development team. The so-called steels law: "An EOP-team either consists of less than 10 or more than 100 pro g rammers" reflects the resulting difficulties ("The inability to do much" (6) ). The real reason for this situation is not primarily found in the required amount of work but rat~er in the de g ree of interaction between the individual elements of the system. This is especially true when time becomes an additional, critical factor for real-time applications, and/or parallel processes are existent. Thl'l nrim09I'\I aims +OI' f urther improvements of program production tools should be: • reliable software, • maintainability (preservation of reliability), • possibilities for pro g ram modifications and extensions, and • portability of know-how. These aims are centered by the question: Is there a possibility to produce programs nearly free of errors and what is the behaviour of a program system after its acceptance? Usually an accepted system still contains errors. Assumin g the optimal case, the number of errors will slowly decrease durin g the maintenance of the system (fi g ure 1). However, the correction of errors often leads to new errors (15).
193
At this point, the so-called qual~ty of errors should be subje~t to ~ more detailed consideration. The quality of errors is measured in the man-hours required for the analysis and correction of the respective error and includes expenditures for treatment of subsequent errors as a result of primary corrective actions. Another aspect is the decreasin z know-how on the prqcram~in 2 system in the course of time. Primary ie~~cin~~re both the lack of reliability of the human memory and the decreasin g availability of former project team members. Fi g ure 1 clearly indicates that the pro g ram system contains less errors after a lon g er utilization perio d . The steepness of curves is mainly influeno~d by the system's size and by its de g ree of interactive nettin g . It is g reatl y influenced by the volume of modification and/or extension necessary. In unfortunate cases the described behaviour may result in an escalati o n of errors and even in the death of the system (repeated breakdown). The requirements of pro g ram maintenance and servicin g need to be taken much more into account when developing pro g rammin g tools. This is not only justified by the requirement for a fail-safe system. Likewise, economic reasons lead to the same conclusion. When comparin g the costs of system realization with those of system maintenance after a longer system utilization period, it is often found that the expenditure for system maintenance exceeds that for system realization (4). The difficulties mentioned above are to be found very often in • technical real-time applications on small and medium-scale computers and • medium and large-scale software systems. Therefore this paper mainly deals with these areas. Not discussed in detail are desi g n and maintenance problems of program systems. 2. Influence and Limitations of Programming Languages For a long time the provision of suitable hi g h level programming lan g ua g es seemed to be the crucial problem. Meanwhile a real inflation of pro g rammin g langua g es can be observed. More than 170 languages were operational in the USA alone in 1972 (16). A similar trend can also be noticed for process control pro g ramming languages.
In order to reco g nize the li mitations of hi g h level pro ~ ra-mm in fi lan g ua ges (HPLl with respect to the development of program systems, O~J"Tent re q uirements on HPL' s are analyzed at first. Some of the most important are: R1 - S.Y.l1t1l)CRo..d _.s..emantics of an HPL must be hardware-independent. R2 - Pro g rams written in an HPL must be hardware-indeoendent. R3 '-"-' L'A"'j'Jf6Wr'l!irrl tJJ!'i'tte~ in an HPL should be self-documentin p (influence to test and maintenance). R4 - An HPL should be easy to learn for the non-specialist user (reduction of expenditure for training and of 1 difficulties during programmin g and testing). HPL hardware independence (R1) and subsequently resultin g problems are very effectively demonstrated by implementation lan g ua g es like PASCAL (21), or the socalled problem lan gu age of the pro g rammin g system POLYP(10). Their primary applications area is the pro gr ammin g of system software. Besides hi g h level elements implementation lan g ua g es also contain so-called lower level lan g ua g e elements. Of remarka b le si g nificance in good implementation lan g ua g es are also syntax and semantics of the lower lan g ua ge elements, which are also hardware-independent. As simple examples, the definition of address variables, the utilization of indirect addressing for the representation of operands and address arithmetic may be mentioned here. However, the practical operation of implementation lan g ua g es reveals that the semantics of statements written with hardware-independent lan g ua g e elements are, nevertheless, often hardware dependent. For implementati o n langua g es this effect is not surprisin g . On the other hand, similar phenomena can also be observed in HPL's. Symptomatic in this respect is the dispute on the GOTOstatement (17,8). The deeper source for difficulties connected with the transfer of programs is based on the fact that a distinction is made between • the hardware independence of the description manner (lan g ua g e) and • the hardware independence of al gorithms, methods, and strate gi es. Requirement R1 can only be contiguous to the description manner (meanin g , the lan g ua g e itself). However, it does not provide protection, for example, against algorithms bein g dependent on the applied hardware structure.
194
Often, one is speakin g then of a misuse of the language. The simplest example is the "packing" of inte g er numbers (A and B) into a variable X by multiplication with povJers of 2: X
=
A + 65 536
~
B
Another example may be r, iven by the effects of various kinds of memory addressing: • addressing by actual (absolute) address, • addressin~ by means of a baSe register, or • virtual addressin g . 07ten, at least the memory structure of data must be determined, dependin g on the hardware structure applied in an actual project. In contrast to th~des~ription format the hardware independe~ce~F algorithms as components of pro g ram systems is often onl y difficult to reco g nize, a fact which has proved to be responsible for many problems with regard to the portability which means hardware-independence of programs (requirement R2). This is especially true for real time applications where the accomplishment of specified reaction times is part of the functional capability of a pro g ram. For example the handling of measured data in a fli8ht control computer. The difficulties related to the notion ·portability· have for example, also been reco g nized by Poole and Waite. In (12) they therefore made a distinction between ·portability· and ·adaptability": • ·Portability is a measure of the ease with which a program can be transferred from one environment to another." • "Adaptability is a measure of the ease with which a pro g ram can be altered to fit differing user images and system constraints." Lan g uage subsets pose another threat to requirement R2, especially when considerin g very efficient programmin g ianguages. The requirement for an upward compatibility of subsets formulated at the be g inning of each language or compiler development is mostly not kept throu g h to the end (figure 2). Often enough no attention is given to the fact that there are two different reasons for the reduction of the lan g ua ge extent. On the one hand, the subset is influenced by the capability of the target machine and the available operatin g system. On the other hand, there exists an influence of the performance of the computer on which the compiler is running. And if the latter is a mini-computer the resulting (unnecessary) restrictions in themselves are highly critical. However, this restriction can be largely prevented by the utilization of cross compilers. By the use of cross compilers the transfer of software production
tasks from small process control computers i:o l-l"I' ~ !lcele machines is eased at a decisive point. Testing, maintenance and modi7ication of pro g rams is only possible when the orograms are understood by the author not only dur1ITt wl"1t!rTP, (pa !? 8S 5-14 of (20)). The respective functional element or module and its relation and influence to its 6!I'I\I'it?llnJl!)9l1t Itltffl~ also be comprehensible to others at any later date. The difficulties in readin g , or better "understandin g ", a program have their ori g in in the fact that the available resources are of sequential nature (e.g. lan g ua g e, writing, thinking, etc.). This is also true with re~ard to the processin g method of a computer. Consequently, the form of a FORTRAN pro g ram, and of an object pro g ram, are also sequential. However, in contrast hereto the behaviour of process control applications to be described by such sequential lang ua g es is not sequential. To overcome these problems Dijkstra, for example, introduced the semaphore variables (7) thus facilitatin g the description of nonsequential processes. Of course, this method does not automatically g uarantee an understandin g of the respective program. Apparently the operation of suitable HPL's does not automatically satisfy the requirement R3. On the contrary both the pro g ram structure and the respective author's individual "si g nature" must be attributed a key role. In the early sixties requirements were directed primarily towards universal HPL's. But an additional necessity for special lan g ua g es was soon recognized. As examples APT (2) for numeric control of machine-tools, and ATLAS (1) for automatic equipment check out systems may be mentioned here. When analyzin g the practical experience gained with such langua ges it becomes apparent that: • an initial contact with such systems usually is very successful (first "small" or simple programs)! • with increasing performance requirements and "comfort" of the respective HPL (R4), and with the degree of program system complexity its operational application is exposed to more and more complication. The principal cause for this must be attributed to the limited stora g e capability of the human memory, combined with its relative unreliability. A suitable criterion for describin g this problem is the amount of training/ learning expenditure (R4) required for the mastering of tools like programmin g
195
languages, job contrQllang4~ge, test aids, or related means. On one hand, the amount of trainin g expenqiture depends on the de g ree of complexity, on the other on the tool's extent. Three examples are g iven to clarify this assertion: • To introduce oneself in FORTRA N less trainin g effort is required than for an assembler langua g e. • Training efforts for PL/1 are hi g her than for FORTR AN (reason: s y ntax). • The finally required trainin g efforts for ATLA S are hi g her than FORTRA N (reason: large number of fun c t ion s J s em ant i c! ) • This interdependence is depicted in fig ure 3. Entered accordin g to performance caoabilities are machine oriented lang ua g es (left), lan p; ua !': es 1 i ke FO RTRA N (middle), and very hi g h level lan g ua g es, including those very advanced special lanp;ua g es (ri g ht). Of course, the curve's de g ree of steepness is dependent on the trainee's previous knowled g e. Trainin g expenditure does not only affect costs and time for the trainin g of programmers. If a critical threshold in trainin g expenditure is pas s ed new error sources appear, e. g . because of the larg e variety of possible lan g ua g e element applications. At this point attention must be directed to the importance of standards. The aim of standards is primarily to save money . The savin g achieved through the application of standardized tools must be put into rel a tion with the investments of time and money for their development and realization, and with inconveniences such a s reduced fle x ibility. Likewise the lon g period of time required for determination of standards must be taken into account. For the sector "automation of industrial processes' it follOl-JS that, as a consequence of very rapid developments, standards are determined onl y at a time when different variants are already operational. To shorten these waitin g times is one aim of the INTERNATIO NAL PUROUE WORKSHOP ON INDUSTRIAL COMPUTER SYSTEMS (14). Without an y doubt the strivin g for standards, for example in the area of general purpose languages like FORTRAN or BASIC, is fully justified from an economical point of view. Regarding the standardization of special languages like ATLAS this question apparently cannot be answered so easily. In this field the definition of additional (private) company standards often appears useful. Indications are the large numbers of dialects of such languages which show remarkable vari-
ations . among ~ othsr however, resultin g in a de g radation of re q uire ment R2. An alternative to this situation is offar~~ ' ~~ O ~tandardizin ~ a relatively small lan g ua g e e x tent (l a n ? ua ~ e nucleus). In addition hereto another instrument, permitti~ ''6 !~tl~ flucleus extension, must be standardiz e d. This tool is also available to the user. Of cours e such extef1sio,~ ~'A~%,.b,\7lu Mt'5,i b h \"ithout an y modificatiori of th e compiler. S uch lan g ua g es are defined as "extensible lan g ua g es". The discussion on requirements R1 to R4 re v eals that these are neither co mplete nor without controversial aspects. Furthermore, the provision of suita b le HPL's is not sufficient. Many modern process control aoplications require extensi ve knowled g e and lon f, -time experience of application areas as well as of computer sciences. Today it is nearly impossible that a sin g le individual can sufficiently cope with these requirements. The onl y solution to this problem is seen in the development of hi gh-qualit y tools permittin g the final user to implement the system, and keep it aliv e , solel y by h ims el f. The key criterion for this aim is apparentl y not to transf e r voluminous pro g ram systems from one computer s y stem to a very similar one. Inst e ad of this the user must be able to describe the individual software s ys t e m in a mann e r which allows him to produce error-free pro grams. At the same time system reliability (breakdown prevention) is influenced to a decisive point, as well as its implemen ta tion within g iven time and cost con s traints. Initial considerations in this direction can be found in some pUblications on structured pro g rammin g , pro g ram !,: enerators, and on interactive pro ~ rammin g . How fast an improvement of the actual and rather unsatisfactory situation is possible does not only depend on the development and realisation of new tools. Not to be underestimated is also the influence of the user's re a diness (or the lack of it) to adapt his working methods and behaviour to new workin g tools. 3. Programmin g The notion "pro grammin g " is subject to various definitions and usages. In the present paper programmin g is understood to be the production of a detailed conceptual desi gn, and of the source pro gram. As mentioned initially the production of reliable program systems is one of the most important aims. This aim cannot be achieved solely by the provision of test
196
systems but rather by "In -9x'-IrTiinatitln of individual error cate gories with re ~ ard to their possible suppressio.n throu g h the ap p lication of bett e r todls,b~ ~of ad e quate workin g methods. The in f luence 0; working methods applied by the pro g rammer ma y be demonstrat e d by a sim p le example. Definition and op eration of macro 5ystems are _ wel~ suited for both assembler pro g rammln g an d for HPL pro g rammin g in order to reduce the number of potential errors. The practical use of ex tensive macro s y stems, however, indicates that at the same time new error sources can arise e. g . number and sequence of the parameters, or the restrictions connected with parameters may be violated. Hence, one ma y inf er from the fi g ure 4a that a critical number of macros should not b e exceeded. If durin g pro g rammin g a simple hardware svstem is available, which consists of a display, a ke y board, a micro-processor and an ex ternal memory, this statement holds no lon g er true. On reco g nition of a macro name by the micro-processor-resident pro g ram the required parameters are then called from the pro g rammer by the system. S uch a system represents the most simple lev e l of interactive pro g rammin g . By transition from the human to the more reliable machine memory these interactions result in a decisive reduction of new error sources (Fi g . 4b). Due to the development of costs and prices for hardware systems in recent years the application of such workin g metho ds is justified also from an economic point of view. Accordin g to this e x ample the problems occurring durin g pro gramming are outlined as follows. A source pro g ram includes the description of the information (data) to be processed, and of the prog ram flow. As the history of pro grammin g lan g uages reveals the program flow had initially been assi g ned far more importance (e. g . FO RTRA N). Languages like ALGOL 60 have been accused, among others, of havin g an excessivel y voluminuous organisation for data declarations. The great importance and the enormous influence of data on the pro g ram as a whole remained to be recognized much later. The structure (format and arrangement) of data in the computer is stron g ly influenced by a pro g ram's efficiency, which in turn is caused by the time/ memory alternative (access optimal or memory optimal arran g ement), and by the data structure's hardware dependency. A hardware independent k ind of pro g ramming, combined with compiler optimization methods obviously ~ n~ ~rooide ~
adequate. an~"'Oj~-this -problem. The reason for this can be found in the fact that the possible paths (static) are ' de1l1' n~ by the source pro gr a m. The actual, dynamic s eq uence of events, and consequentl y , the pro g ram's behaviour cannClt " ~--1"'eet! ~ lii::!:ed b y the compiler. He nce, crucial information required for cod e opti miz a tion is not avail a ble to the comp~~~ I1'~ Data decl a rations define their static structure ina prog ram. Howe v er, the data flow can onl y be read " indirectl y · in connection with pro g ram statements. These very unpleasant error sources can e ffectivel y be reduced by adequate tools for pro g ram desi ?, n and pro g rammin f, . The description of the p r og ram flow bears more problems. When usin g s equential lang ua ge s like FORTRAN or BA S IC the pro g ram'~ conceptual "translation" into a source pro g ram largel y consists of the task of arran g in g the usuall y nonsequential events into s eo uential ord er. The difficulties related hereto become quite obvio us on comparison of the verbal pro g ram description with the s ource pro g ram, or of the flow ch a rt with the s o urce p ro gram. On the one ha nd pro gram branches are for gotten or wron g l y coded, on the other hand the p roblem to b e solved cannot be clearly reco g nized in the source codin g . A solution to the first ~roblem can be found in the a p plication of decision tables. An approach towards the solution of the second problem is offered by the often discussed idea of structured programmin g . As mentioned before the job of pro g ramming is eased by HPL's. A reduction in problems can be achieved by raisin ~ the level of pro g rammin g lan g ua g es. Raisin g the level me ans in this case to st a nd for the f a ct that for the utilization of such lan g ua g es less and less computer and pro g rammin g knowled g e is re q uired. The application oriented pro g rammer therefore obtains a remarka b le de gre e of comf o rt. Examples of such hi g her general purpose lan g ua g es as PL/1 and ALCQL 68. On the other hand the operation of these lan g ua g es reveals that the required learnin g effort must be stepped up si g nificantly (see also fi g ure 3). The objection that the complete extent of a lan g ua ge need not to be ma stered turns out to be wron g . Furthermore, at the be g inning of a project the prog rammer is often unable to assess what lan g uage elements he will really require for an efficient operation. For some specific application areas an alternative approach is offered by the development and operation of special langua g es.
197
• Quite obviously no satisfyinr, solutIon -tor many actual technical real-time apolications is ~~e§@~ted by g eneral purpose lan g ua g es. On the other hand special lan gua g es need too much inves tment of mOD.BY to permi t their implementation with a sufficient de g ree of comfort. This is especially true for small ilW(Jrl me@ful\ltJ g:d~!J.l9 process control computers. The onl y alternative is offered by extensible langua g es in connection with cross compilers. • Trainin g expenditures must be reduced. An important contribution can be furnished throu g h standardization of job control lan g ua g es, test aids, compiler controls. and similar tools. • A further automation of software production is necessary. vJith the help of computer usa f, e durin g pro g rammin g a reduction in the size of manuals (small information systems) and the renunciation of pa per, pencil and rubber becomes possible. This may be called the first step in interactive progr a mming. The sam e holds true for the execution and evaluation of tests. • The portability of know-how in form of readab le, that is, adaptable routines and strategies is more important as an immediate aim than the (unreal) demand for portability of whole pro g rams, and/or systems.
The relatively long experien~e . gained in th e area of numerical m~6~i~~-tool control (e. g . APT (2)), or also in the field of equipment cr.i3ck out systems (e.g. ATLAS (1)) makes possible an analysis. To-day the necessity of havin g such tools has been proved beyond an y doubt. Nevertheless an effective control over such tools also requires remarkable trainin g effort to be invested. There is nO troOble in masterin g the syntax of a lan g ua g e. However, to effectivel y learn the semantics of langua g e elements - especi a ll y in very comfortable systems - requires si g nificant effort. This situation is a gg ravated by the fact that, unrelated to the above, the pro g rammer must ~Qsseqq information about the corresponairi~ tompiler features (error analysis, optimizations, test aids, etc.), utilities and job control lanf,uag es. The knowled g e considered essential is well demonstrated when all papers and manuals required for the pra ctical use of the lan g ua g e are piled up. Unfortunatel y an increasin f, comfort does not only r ·e sult in more trainin [; expenditure but also in the possibility of producin g more errors. The dilemma has already been discussed in previous chapters in connection with explanations of fi g ure 3. Within each individual project the continuously increasing so p histication of application systems usin r, computers also leads to increasin g know-how and experience demands of more and more branches of science. From the point of view of a user prog rammer it often appe a rs no lon g er possible to-day to survey the hardware and software problems bein g operated on, and the consequences resultin g therefrom. Vice versa, computer scientists often lack a sufficient understandin g of the respective applications. In other words: the essential know-how "application and computerscience" is too voluminous to be handled by a sin g le programmer. 4. Automatic software production systems 4.1 The structure of a software production system The above mentioned problems clearly outline the difficulties for medium and large scale technically oriented real-time applications. Apparently these problems even cannot be overcome by the known very high level lan g uages (18) in the sense of g eneral purpose languages at extreme level. What requirements must be accomplished now in order to allow a g reater independence of the user?
To facilitate a better understandin ~ of these requirements the followin g para g raph contains the description of a system structure suitable to be applied for an automated software production. The final part of such a system consists of a cross compiler (central compiler and code g enerator) for an implementation langua g e (10, 21). The next level comprises a macro processor. Lan g ua g es like STAGE2 (19) or the control lan f uage of POLYP (10) are suitable as macro langua g es. By means of macros the implementation langua g e becomes extensible with respect to the application and enables the portability of such programs (5). The semantics of macros meaning their function should be hardware independent. From the point of view of their realization (macro definition) hardware dependent macros are distinguished from hardware independent macros. This means that for the transition to another target machine the source pro gram needs not to be modified but only the hardware dependent macros (fi g ure 6, part A). The intermediate lan g ua g e at the macro processor's entry should contain only
198
number of programming errors
average quality of programming errors available know-how
.. .
number of possible errors
,/
,/
./
./
./
""
--- -- --
...
---,,I
time
I maintenance
system tinstallat.
..
---number of macros
Fig . ~a Possible errors in using macro systems manually
test
additional "possible errors" due 10 the usage of macros
accep1ance number of possible
Fig. 1 Main1enance of software systems
errors
------------number of macros
Fig.
~b
Possible errors in using macro systems interactively
reat i stic subsets
.".,..-- .......... ,
I
.\:. ~.: J
/ • :' ( (
_ '-'--
: .
\
I
/../,/
~.../'. / / .'-..'.....'-. ...... ........ /./
I
\
'-' .........
.~ ';:--._" ~' \
"..-
,.//.....: .;
, ' ....... ----- .....
,.-
display and keyboard
",
Fig . 5 Hardware for simple interac1 ive programming
ideal subsets
Fig . 2 Subsets of programming languages
manpower for tralnng
language extent Fig . 3 Training effort depending on language extent
199
microprocessor
external storage
higher level language elements of the implementation languag's aRe- ,tfl.6 ffie{)f'O' lang ua g e (mostly macro calls). The system is supplemented by a table controlled program generator (fi g ure 6, part B). This program generator is capable of process1nz sour'ce- pr
implementation are de fined. Tile plo g I'ammermu s t have a very goo d knowl e dge of the .c.orres pon d in g hardware , structure. Laye r Ill: Specific funct i ons are defined as extensions to the implementatlon IariiLia g e. The prog rammer should have g eneral pro g rammin g e xperience and 53 f Ifa :irrD It. flD"'l!!~ &! 0 f the respecti ve application sector. Layer I V: Alternative procedures and sequences are defined by means o f a tabl e definition lan g ua g e. The pro g rammer must primarily be famili a r with the fundamentals of the respective application. Layer V: Interactive user pro g rammin g at the terminal permittin ~ him to construct his s ystem larg ely without specific computer and pro g ra mmin g knov!led g e. These 5 l e vels or la y ers are also reflected by t he composition of a p ro gra mmin g team. >
In accordance with their in d iv i dual e xp erience the team membe rs are assi ? ned to a certain level. Within a level furth e r subdivisions are made de pendin g on professional aspects. It should be pointed out here that each team member only operates within his level. If he needs more resources from another level these must be requ ested by him. However, satisfyin g results can only be ex pected from this method if appropriate procedures for testin g an d error tracin g are available. The above described arran g ement of levels also provides for a sufficient de g ree of freedom from e rro rs (11). There is a correspondence hetween fi ~ ure 6 and the 5 layers: layer 1: part 0, link libra ry layer 2: part A, hardwat'e dependent lib rary layer 3: part A hardware independent 1 ibrary layer 4: part B la y er 5: part C This inherentl y requires that by suitable definitions of individual components testing is possible independent of the respective level's environment! When summarizin g the above mentioned considerations some conclusions can be drawn. The method described not only allows the user to "pro g ram" under his own responsibility, but also ensures that the system produced by him is larg ely free of software errors. From the practical point of view, importance should be directed further to the fact that after a basic i mplementation
200
certain adaptation~ and extensions may well be oerformed, if so requfr~. 4.2 Introduction of a new tool The development of a tool for prof,ram pro duction is often accomplished in isolation from its environment. Necessary for a langua g e are for example efficient compilers, test aids, operatin g systems adaptations, ~nd ttainin~ ~Jteri~l. Extent and importance of these "extra services" are often underestimated. This indicates one reason for the many problems connected with the introduction of new tools. Ir. the following it is assumed that the respective tool is not subject to such deficiencies. An evaluation of initial experience ga ined with a new tool is not without problems. Doubtlessly it is easy to decide whether a project has been a success or a failure (dead-lines, costs, system reliability, etc.). To reveal the real reasons, however, is much more difficult. A critical analysis of corresponding experience re po rts often indicates that formal command of a new tool alone is not sufficient. Even the best tool can be more easily misused than be used in a reasonable manner. When lookin g more closely for the reason it becomes apparent that demands are not satisfied by simply exchangin g an old tool for a new one. What is necessary is to simultaneously investi g ate whether the applied working methods are suitable or not.
5. Conclusions The reliability of software systems for proce6~ cQ~trol is not sufficient to-day. This is especially true for larg e and/or sophisticated systems. Raising the level of a lan guage and enlarging the capacity performance of a langua ge does not solve the problem, if we are only concentrating on lan g ua ges of sequential type. One real reason for this insufficient situation is the necessit y for soecial (individual) lan gua ge s and software svstems. This is true because these tools are used and these products are constructed and used not by machines but by humans. Therefore the only possibility or better the onl y chance is to standardize tools with the help of which the final, non computer-experienced user is able to define his own (individual) system without producin g software errors. To-day such an aim looks phantastic or unreal. Obviously it is not possible to develop and implement the methods and tools necessary in one step. But this paper demonstrates that it is possible to find a way in which parts of the final tools are already very useful. R E FER E N C E S (1)
Abbreviated Test Lan gua ge for Avionics System (ATLAS), ARINC Specification 4168, Aeronatical Radio Inc., Annapolis, Maryland, (1973)
Pilot projects need careful and critical attention. The aims of such attention are on one side • to reco g nize weak points of the new tool and on the other • to give org anisational support to the respective users. Until now very little attention has been directed to human psychological aspects. An exceptionally valuable contribution to close this g ap was provided by Weinberg (20).
(2)
APT Part Pro g rammin g , Mc Graw-Hill Book Co., I~e w York, (1967), (Illinois Institute of Techn.)
(3)
ARSI 80, AEG brochure A 512 06.01 8 0774, (1974)
(4)
Barry W. Boehm: Some Information Pro l cessing Implications of Air Force Space ~issions in the 1970s, Astronautics & Aeronautics, January 1971, pp. 42-50.
The primary task of new tools is to have those pro g rammin g components suitable for mechanization executed by the much more reliable machine. What remains for the pro grammer is that portion which requires his creative capabilities. This evaluation of work sharing between man and machine is considered to be very important since many large and sophisticated process control problems with high requirements on system reliability cannot be solved with those resources which are available at present!
(5)
P.J. Brown: Macro Processors, John Wiley & Sons, London (1974)
(6)
O.-J. Dahl, E.W. Oijkstra, C.A.R. Hoare: Structured Programming, Academic Press, London, pp. 1-82, (1972 )
(7)
E.W. Oijkstra: The Structure of "THE"Multiprogramming System, Communications of the ACM, Vol. 11, No. 5, pp. 341-346, (1968)
(8)
Oonald E. Knuth: Structured Programming with go to Statements, ACM Computin g Surveys, Vol. 6, No. 4, pp. 261-301, (19.14)
201
(9 ,
Programmsystem f1ADAM. Siemens brochure E 312/1107-1115. {'971)
>
?;
:;; >E
E
:;;,...
-:;;,... E
= ~
E
Q;
B
( 10) Guenter Musstopf: Des P rDg rammi 8 rs ystem POLYP, Angewanote IntormatiK, Vol. 10, pp. 441-448, (1972)
..
E
u; E ~~
.e~ uE
( 11) Guenter Musstopf: TO~Jards Software Reliability for Process Control - A status Reoort, 1974 IFAC/IFIP vlorkshop on Real Time Jl'rog Nlllilrd n g , 'Budapest, f1arch 74
.g :;;
~'"
~
,...
"E c: "c:
£J
'"c:
E
( 12) P.C. Poole, W."1. Waite: Portability and Adaptability, Advanced Course on Software Engineering, Springer Verlag, 81 , pp. 183-27 8 , (1973) ( 13) Process Svstems Proe:ram (PROSPRO IBM b ro ch urt. GH 20-4000, (1970)
"6. 0
..
"0
i;. :>
"B
~
.!
.~
II) ,
.~
'"
"0 0 .£;
0; E
E
.. .8. ., . .,<;
"0
E
'"
~
0
~
C
"0
c:
~
"0
~
"0
"0
.£;
.£;
<;
<;
E
o " o.g, ~ Cl.
'"
.!" .!::'"
::J
.!! u
-o "0 c:
::J
c: E
'" "
U;
i;;'
"-'"; c:
Q; 0. 0
.
0 0.
., '" ::
.,
~
.
'" 0 .:: v
.,
"'.£;
<;
:;;,... "0
"0
" c: ,...--' "
~
<;
.£;
,;,
u::
( 14 ) r1inutes of the 1973 Meetin g of the International Purdue Workshop on Industrial Computer Systems, Purdue Laboratory for Applied Industrial Cant ro l, Purdue Un i ve rs it Y, West Lafayette, Indiana, (1973) ( 1 5) C.V. Ramamoorthy, R.C. Cheung, K.H. Kim: Reliability and Integrity of Large Computer Programs, Lecture Notes in Computer Sciences 12, Sprinr,erVerlap;, pp. 86-161, (1974)
0 0 0.
(16 ) Jean E. Sammet: Programming Languages: History and Future, Communications of the ACM, Vol. 15, No. 7, pp. 601-610, (1972) ( 17) O.V. Schorre: Improved Organization fo I' P rocedu ra 1 Lan g uages, Tech. Memo TM 3086/002/00, Systems Development Corp. , (1966)
i
c .~
~~ ~ "gt. 0
( 18) Proceed i ngs of a Symposium on Very High Level Languages, ACM SIGPLAN Notices, Vol. 9, No. 4, (1974)
f@
"c
( 19) W.M. Waite: The mobile P rogrammi nr; System: STAGE2, Communications of the ACM, Vol. 13, pp. 415-421, (1970)
0.
~ OD
(20) Gerald M. Weinberg: The Psychology of Computer Programming, Computer Science Series, van Nostrand Reinhold Company, New York, (1971)
0 0.
!tj e2 00
j
~
c 0
C
0
.2
! j . c
(21 ) N. Wirth: The P rogrammi ng Language PASCAL Acta Informatica 1 , pp. 35-63, (1971 )
u
i
[
~
~
'"
'"
;;:
202
fiuenter MusstepT G SCS Scientific Control Systems GmbH Ueberseerin g 8 0-2000 Hamburg 60 . Germany
A BST RAC T The reliability of present large and/or sophistieated software systems is not sufficient. On the other hand a g reat pro gress had been made in the area of hardware reliability in the last few years. The causes of such a behaviour of software systems are shown by analyzin g the usual requirements critically. Furthermore there is a contradiction in g enerai between the necessity of standardizing a g eneral purpose process-control langua ge and the requirements of the non computer-experienced user on special purpose langua g es. As a proposal for the solution of this problem a software production system is briefly described. The basic components of this system are already in use in different areas and are independent of one another. 1. History and Present Situation In the 1950's and in the early sixties most tasks performed by electronic computers had been of numeric nature. The necessary programs usually could be produced by a single individual without particular problems. At that time, the work of a programmer was very similar to that of an artist. Even today, high importance is sometimes attributed to the elegance of a program. On the other hand, the non computer-experienced user was unable to break into this secret science. Consequently, the programmer had to introduce himself to the respective application. However, hardware or programming errors were not considered critical, as a program run could easily be repeated without any damage if an error occurred. Since the mid-sixties both the number of non-numeric and the number of on-line applications have rapidly increased; In the same period decisive improvements were
achieved in the field of hardware reliability. Additionally, the introduction of low-cost, hi g hly efficient "mini-computers" durin g recent years has opened technical possibilities for the construction of interestin g hierarchically structured computer networks. However, when applying these technical possibilities numerous new problems arise. The volume of pro g rams and the necessity to realize such an EOP-system within 1 or 2 years result in a si gnificant enlargement of the development team. The so-called steels law: "An EOP-team either consists of less than 10 or more than 100 pro g rammers" reflects the resulting difficulties ("The inability to do much" (6) ). The real reason for this situation is not primarily found in the required amount of work but rat~er in the de g ree of interaction between the individual elements of the system. This is especially true when time becomes an additional, critical factor for real-time applications, and/or parallel processes are existent. Thl'l nrim09I'\I aims +OI' f urther improvements of program production tools should be: • reliable software, • maintainability (preservation of reliability), • possibilities for pro g ram modifications and extensions, and • portability of know-how. These aims are centered by the question: Is there a possibility to produce programs nearly free of errors and what is the behaviour of a program system after its acceptance? Usually an accepted system still contains errors. Assumin g the optimal case, the number of errors will slowly decrease durin g the maintenance of the system (fi g ure 1). However, the correction of errors often leads to new errors (15).
193
At this point, the so-called qual~ty of errors should be subje~t to ~ more detailed consideration. The quality of errors is measured in the man-hours required for the analysis and correction of the respective error and includes expenditures for treatment of subsequent errors as a result of primary corrective actions. Another aspect is the decreasin z know-how on the prqcram~in 2 system in the course of time. Primary ie~~cin~~re both the lack of reliability of the human memory and the decreasin g availability of former project team members. Fi g ure 1 clearly indicates that the pro g ram system contains less errors after a lon g er utilization perio d . The steepness of curves is mainly influeno~d by the system's size and by its de g ree of interactive nettin g . It is g reatl y influenced by the volume of modification and/or extension necessary. In unfortunate cases the described behaviour may result in an escalati o n of errors and even in the death of the system (repeated breakdown). The requirements of pro g ram maintenance and servicin g need to be taken much more into account when developing pro g rammin g tools. This is not only justified by the requirement for a fail-safe system. Likewise, economic reasons lead to the same conclusion. When comparin g the costs of system realization with those of system maintenance after a longer system utilization period, it is often found that the expenditure for system maintenance exceeds that for system realization (4). The difficulties mentioned above are to be found very often in • technical real-time applications on small and medium-scale computers and • medium and large-scale software systems. Therefore this paper mainly deals with these areas. Not discussed in detail are desi g n and maintenance problems of program systems. 2. Influence and Limitations of Programming Languages For a long time the provision of suitable hi g h level programming lan g ua g es seemed to be the crucial problem. Meanwhile a real inflation of pro g rammin g langua g es can be observed. More than 170 languages were operational in the USA alone in 1972 (16). A similar trend can also be noticed for process control pro g ramming languages.
In order to reco g nize the li mitations of hi g h level pro ~ ra-mm in fi lan g ua ges (HPLl with respect to the development of program systems, O~J"Tent re q uirements on HPL' s are analyzed at first. Some of the most important are: R1 - S.Y.l1t1l)CRo..d _.s..emantics of an HPL must be hardware-independent. R2 - Pro g rams written in an HPL must be hardware-indeoendent. R3 '-"-' L'A"'j'Jf6Wr'l!irrl tJJ!'i'tte~ in an HPL should be self-documentin p (influence to test and maintenance). R4 - An HPL should be easy to learn for the non-specialist user (reduction of expenditure for training and of 1 difficulties during programmin g and testing). HPL hardware independence (R1) and subsequently resultin g problems are very effectively demonstrated by implementation lan g ua g es like PASCAL (21), or the socalled problem lan gu age of the pro g rammin g system POLYP(10). Their primary applications area is the pro gr ammin g of system software. Besides hi g h level elements implementation lan g ua g es also contain so-called lower level lan g ua g e elements. Of remarka b le si g nificance in good implementation lan g ua g es are also syntax and semantics of the lower lan g ua ge elements, which are also hardware-independent. As simple examples, the definition of address variables, the utilization of indirect addressing for the representation of operands and address arithmetic may be mentioned here. However, the practical operation of implementation lan g ua g es reveals that the semantics of statements written with hardware-independent lan g ua g e elements are, nevertheless, often hardware dependent. For implementati o n langua g es this effect is not surprisin g . On the other hand, similar phenomena can also be observed in HPL's. Symptomatic in this respect is the dispute on the GOTOstatement (17,8). The deeper source for difficulties connected with the transfer of programs is based on the fact that a distinction is made between • the hardware independence of the description manner (lan g ua g e) and • the hardware independence of al gorithms, methods, and strate gi es. Requirement R1 can only be contiguous to the description manner (meanin g , the lan g ua g e itself). However, it does not provide protection, for example, against algorithms bein g dependent on the applied hardware structure.
194
Often, one is speakin g then of a misuse of the language. The simplest example is the "packing" of inte g er numbers (A and B) into a variable X by multiplication with povJers of 2: X
=
A + 65 536
~
B
Another example may be r, iven by the effects of various kinds of memory addressing: • addressing by actual (absolute) address, • addressin~ by means of a baSe register, or • virtual addressin g . 07ten, at least the memory structure of data must be determined, dependin g on the hardware structure applied in an actual project. In contrast to th~des~ription format the hardware independe~ce~F algorithms as components of pro g ram systems is often onl y difficult to reco g nize, a fact which has proved to be responsible for many problems with regard to the portability which means hardware-independence of programs (requirement R2). This is especially true for real time applications where the accomplishment of specified reaction times is part of the functional capability of a pro g ram. For example the handling of measured data in a fli8ht control computer. The difficulties related to the notion ·portability· have for example, also been reco g nized by Poole and Waite. In (12) they therefore made a distinction between ·portability· and ·adaptability": • ·Portability is a measure of the ease with which a program can be transferred from one environment to another." • "Adaptability is a measure of the ease with which a pro g ram can be altered to fit differing user images and system constraints." Lan g uage subsets pose another threat to requirement R2, especially when considerin g very efficient programmin g ianguages. The requirement for an upward compatibility of subsets formulated at the be g inning of each language or compiler development is mostly not kept throu g h to the end (figure 2). Often enough no attention is given to the fact that there are two different reasons for the reduction of the lan g ua ge extent. On the one hand, the subset is influenced by the capability of the target machine and the available operatin g system. On the other hand, there exists an influence of the performance of the computer on which the compiler is running. And if the latter is a mini-computer the resulting (unnecessary) restrictions in themselves are highly critical. However, this restriction can be largely prevented by the utilization of cross compilers. By the use of cross compilers the transfer of software production
tasks from small process control computers i:o l-l"I' ~ !lcele machines is eased at a decisive point. Testing, maintenance and modi7ication of pro g rams is only possible when the orograms are understood by the author not only dur1ITt wl"1t!rTP, (pa !? 8S 5-14 of (20)). The respective functional element or module and its relation and influence to its 6!I'I\I'it?llnJl!)9l1t Itltffl~ also be comprehensible to others at any later date. The difficulties in readin g , or better "understandin g ", a program have their ori g in in the fact that the available resources are of sequential nature (e.g. lan g ua g e, writing, thinking, etc.). This is also true with re~ard to the processin g method of a computer. Consequently, the form of a FORTRAN pro g ram, and of an object pro g ram, are also sequential. However, in contrast hereto the behaviour of process control applications to be described by such sequential lang ua g es is not sequential. To overcome these problems Dijkstra, for example, introduced the semaphore variables (7) thus facilitatin g the description of nonsequential processes. Of course, this method does not automatically g uarantee an understandin g of the respective program. Apparently the operation of suitable HPL's does not automatically satisfy the requirement R3. On the contrary both the pro g ram structure and the respective author's individual "si g nature" must be attributed a key role. In the early sixties requirements were directed primarily towards universal HPL's. But an additional necessity for special lan g ua g es was soon recognized. As examples APT (2) for numeric control of machine-tools, and ATLAS (1) for automatic equipment check out systems may be mentioned here. When analyzin g the practical experience gained with such langua ges it becomes apparent that: • an initial contact with such systems usually is very successful (first "small" or simple programs)! • with increasing performance requirements and "comfort" of the respective HPL (R4), and with the degree of program system complexity its operational application is exposed to more and more complication. The principal cause for this must be attributed to the limited stora g e capability of the human memory, combined with its relative unreliability. A suitable criterion for describin g this problem is the amount of training/ learning expenditure (R4) required for the mastering of tools like programmin g
195
languages, job contrQllang4~ge, test aids, or related means. On one hand, the amount of trainin g expenqiture depends on the de g ree of complexity, on the other on the tool's extent. Three examples are g iven to clarify this assertion: • To introduce oneself in FORTRA N less trainin g effort is required than for an assembler langua g e. • Training efforts for PL/1 are hi g her than for FORTR AN (reason: s y ntax). • The finally required trainin g efforts for ATLA S are hi g her than FORTRA N (reason: large number of fun c t ion s J s em ant i c! ) • This interdependence is depicted in fig ure 3. Entered accordin g to performance caoabilities are machine oriented lang ua g es (left), lan p; ua !': es 1 i ke FO RTRA N (middle), and very hi g h level lan g ua g es, including those very advanced special lanp;ua g es (ri g ht). Of course, the curve's de g ree of steepness is dependent on the trainee's previous knowled g e. Trainin g expenditure does not only affect costs and time for the trainin g of programmers. If a critical threshold in trainin g expenditure is pas s ed new error sources appear, e. g . because of the larg e variety of possible lan g ua g e element applications. At this point attention must be directed to the importance of standards. The aim of standards is primarily to save money . The savin g achieved through the application of standardized tools must be put into rel a tion with the investments of time and money for their development and realization, and with inconveniences such a s reduced fle x ibility. Likewise the lon g period of time required for determination of standards must be taken into account. For the sector "automation of industrial processes' it follOl-JS that, as a consequence of very rapid developments, standards are determined onl y at a time when different variants are already operational. To shorten these waitin g times is one aim of the INTERNATIO NAL PUROUE WORKSHOP ON INDUSTRIAL COMPUTER SYSTEMS (14). Without an y doubt the strivin g for standards, for example in the area of general purpose languages like FORTRAN or BASIC, is fully justified from an economical point of view. Regarding the standardization of special languages like ATLAS this question apparently cannot be answered so easily. In this field the definition of additional (private) company standards often appears useful. Indications are the large numbers of dialects of such languages which show remarkable vari-
ations . among ~ othsr however, resultin g in a de g radation of re q uire ment R2. An alternative to this situation is offar~~ ' ~~ O ~tandardizin ~ a relatively small lan g ua g e e x tent (l a n ? ua ~ e nucleus). In addition hereto another instrument, permitti~ ''6 !~tl~ flucleus extension, must be standardiz e d. This tool is also available to the user. Of cours e such extef1sio,~ ~'A~%,.b,\7lu Mt'5,i b h \"ithout an y modificatiori of th e compiler. S uch lan g ua g es are defined as "extensible lan g ua g es". The discussion on requirements R1 to R4 re v eals that these are neither co mplete nor without controversial aspects. Furthermore, the provision of suita b le HPL's is not sufficient. Many modern process control aoplications require extensi ve knowled g e and lon f, -time experience of application areas as well as of computer sciences. Today it is nearly impossible that a sin g le individual can sufficiently cope with these requirements. The onl y solution to this problem is seen in the development of hi gh-qualit y tools permittin g the final user to implement the system, and keep it aliv e , solel y by h ims el f. The key criterion for this aim is apparentl y not to transf e r voluminous pro g ram systems from one computer s y stem to a very similar one. Inst e ad of this the user must be able to describe the individual software s ys t e m in a mann e r which allows him to produce error-free pro grams. At the same time system reliability (breakdown prevention) is influenced to a decisive point, as well as its implemen ta tion within g iven time and cost con s traints. Initial considerations in this direction can be found in some pUblications on structured pro g rammin g , pro g ram !,: enerators, and on interactive pro ~ rammin g . How fast an improvement of the actual and rather unsatisfactory situation is possible does not only depend on the development and realisation of new tools. Not to be underestimated is also the influence of the user's re a diness (or the lack of it) to adapt his working methods and behaviour to new workin g tools. 3. Programmin g The notion "pro grammin g " is subject to various definitions and usages. In the present paper programmin g is understood to be the production of a detailed conceptual desi gn, and of the source pro gram. As mentioned initially the production of reliable program systems is one of the most important aims. This aim cannot be achieved solely by the provision of test
196
systems but rather by "In -9x'-IrTiinatitln of individual error cate gories with re ~ ard to their possible suppressio.n throu g h the ap p lication of bett e r todls,b~ ~of ad e quate workin g methods. The in f luence 0; working methods applied by the pro g rammer ma y be demonstrat e d by a sim p le example. Definition and op eration of macro 5ystems are _ wel~ suited for both assembler pro g rammln g an d for HPL pro g rammin g in order to reduce the number of potential errors. The practical use of ex tensive macro s y stems, however, indicates that at the same time new error sources can arise e. g . number and sequence of the parameters, or the restrictions connected with parameters may be violated. Hence, one ma y inf er from the fi g ure 4a that a critical number of macros should not b e exceeded. If durin g pro g rammin g a simple hardware svstem is available, which consists of a display, a ke y board, a micro-processor and an ex ternal memory, this statement holds no lon g er true. On reco g nition of a macro name by the micro-processor-resident pro g ram the required parameters are then called from the pro g rammer by the system. S uch a system represents the most simple lev e l of interactive pro g rammin g . By transition from the human to the more reliable machine memory these interactions result in a decisive reduction of new error sources (Fi g . 4b). Due to the development of costs and prices for hardware systems in recent years the application of such workin g metho ds is justified also from an economic point of view. Accordin g to this e x ample the problems occurring durin g pro gramming are outlined as follows. A source pro g ram includes the description of the information (data) to be processed, and of the prog ram flow. As the history of pro grammin g lan g uages reveals the program flow had initially been assi g ned far more importance (e. g . FO RTRA N). Languages like ALGOL 60 have been accused, among others, of havin g an excessivel y voluminuous organisation for data declarations. The great importance and the enormous influence of data on the pro g ram as a whole remained to be recognized much later. The structure (format and arrangement) of data in the computer is stron g ly influenced by a pro g ram's efficiency, which in turn is caused by the time/ memory alternative (access optimal or memory optimal arran g ement), and by the data structure's hardware dependency. A hardware independent k ind of pro g ramming, combined with compiler optimization methods obviously ~ n~ ~rooide ~
adequate. an~"'Oj~-this -problem. The reason for this can be found in the fact that the possible paths (static) are ' de1l1' n~ by the source pro gr a m. The actual, dynamic s eq uence of events, and consequentl y , the pro g ram's behaviour cannClt " ~--1"'eet! ~ lii::!:ed b y the compiler. He nce, crucial information required for cod e opti miz a tion is not avail a ble to the comp~~~ I1'~ Data decl a rations define their static structure ina prog ram. Howe v er, the data flow can onl y be read " indirectl y · in connection with pro g ram statements. These very unpleasant error sources can e ffectivel y be reduced by adequate tools for pro g ram desi ?, n and pro g rammin f, . The description of the p r og ram flow bears more problems. When usin g s equential lang ua ge s like FORTRAN or BA S IC the pro g ram'~ conceptual "translation" into a source pro g ram largel y consists of the task of arran g in g the usuall y nonsequential events into s eo uential ord er. The difficulties related hereto become quite obvio us on comparison of the verbal pro g ram description with the s ource pro g ram, or of the flow ch a rt with the s o urce p ro gram. On the one ha nd pro gram branches are for gotten or wron g l y coded, on the other hand the p roblem to b e solved cannot be clearly reco g nized in the source codin g . A solution to the first ~roblem can be found in the a p plication of decision tables. An approach towards the solution of the second problem is offered by the often discussed idea of structured programmin g . As mentioned before the job of pro g ramming is eased by HPL's. A reduction in problems can be achieved by raisin ~ the level of pro g rammin g lan g ua g es. Raisin g the level me ans in this case to st a nd for the f a ct that for the utilization of such lan g ua g es less and less computer and pro g rammin g knowled g e is re q uired. The application oriented pro g rammer therefore obtains a remarka b le de gre e of comf o rt. Examples of such hi g her general purpose lan g ua g es as PL/1 and ALCQL 68. On the other hand the operation of these lan g ua g es reveals that the required learnin g effort must be stepped up si g nificantly (see also fi g ure 3). The objection that the complete extent of a lan g ua ge need not to be ma stered turns out to be wron g . Furthermore, at the be g inning of a project the prog rammer is often unable to assess what lan g uage elements he will really require for an efficient operation. For some specific application areas an alternative approach is offered by the development and operation of special langua g es.
197
• Quite obviously no satisfyinr, solutIon -tor many actual technical real-time apolications is ~~e§@~ted by g eneral purpose lan g ua g es. On the other hand special lan gua g es need too much inves tment of mOD.BY to permi t their implementation with a sufficient de g ree of comfort. This is especially true for small ilW(Jrl me@ful\ltJ g:d~!J.l9 process control computers. The onl y alternative is offered by extensible langua g es in connection with cross compilers. • Trainin g expenditures must be reduced. An important contribution can be furnished throu g h standardization of job control lan g ua g es, test aids, compiler controls. and similar tools. • A further automation of software production is necessary. vJith the help of computer usa f, e durin g pro g rammin g a reduction in the size of manuals (small information systems) and the renunciation of pa per, pencil and rubber becomes possible. This may be called the first step in interactive progr a mming. The sam e holds true for the execution and evaluation of tests. • The portability of know-how in form of readab le, that is, adaptable routines and strategies is more important as an immediate aim than the (unreal) demand for portability of whole pro g rams, and/or systems.
The relatively long experien~e . gained in th e area of numerical m~6~i~~-tool control (e. g . APT (2)), or also in the field of equipment cr.i3ck out systems (e.g. ATLAS (1)) makes possible an analysis. To-day the necessity of havin g such tools has been proved beyond an y doubt. Nevertheless an effective control over such tools also requires remarkable trainin g effort to be invested. There is nO troOble in masterin g the syntax of a lan g ua g e. However, to effectivel y learn the semantics of langua g e elements - especi a ll y in very comfortable systems - requires si g nificant effort. This situation is a gg ravated by the fact that, unrelated to the above, the pro g rammer must ~Qsseqq information about the corresponairi~ tompiler features (error analysis, optimizations, test aids, etc.), utilities and job control lanf,uag es. The knowled g e considered essential is well demonstrated when all papers and manuals required for the pra ctical use of the lan g ua g e are piled up. Unfortunatel y an increasin f, comfort does not only r ·e sult in more trainin [; expenditure but also in the possibility of producin g more errors. The dilemma has already been discussed in previous chapters in connection with explanations of fi g ure 3. Within each individual project the continuously increasing so p histication of application systems usin r, computers also leads to increasin g know-how and experience demands of more and more branches of science. From the point of view of a user prog rammer it often appe a rs no lon g er possible to-day to survey the hardware and software problems bein g operated on, and the consequences resultin g therefrom. Vice versa, computer scientists often lack a sufficient understandin g of the respective applications. In other words: the essential know-how "application and computerscience" is too voluminous to be handled by a sin g le programmer. 4. Automatic software production systems 4.1 The structure of a software production system The above mentioned problems clearly outline the difficulties for medium and large scale technically oriented real-time applications. Apparently these problems even cannot be overcome by the known very high level lan g uages (18) in the sense of g eneral purpose languages at extreme level. What requirements must be accomplished now in order to allow a g reater independence of the user?
To facilitate a better understandin ~ of these requirements the followin g para g raph contains the description of a system structure suitable to be applied for an automated software production. The final part of such a system consists of a cross compiler (central compiler and code g enerator) for an implementation langua g e (10, 21). The next level comprises a macro processor. Lan g ua g es like STAGE2 (19) or the control lan f uage of POLYP (10) are suitable as macro langua g es. By means of macros the implementation langua g e becomes extensible with respect to the application and enables the portability of such programs (5). The semantics of macros meaning their function should be hardware independent. From the point of view of their realization (macro definition) hardware dependent macros are distinguished from hardware independent macros. This means that for the transition to another target machine the source pro gram needs not to be modified but only the hardware dependent macros (fi g ure 6, part A). The intermediate lan g ua g e at the macro processor's entry should contain only
198
number of programming errors
average quality of programming errors available know-how
.. .
number of possible errors
,/
,/
./
./
./
""
--- -- --
...
---,,I
time
I maintenance
system tinstallat.
..
---number of macros
Fig . ~a Possible errors in using macro systems manually
test
additional "possible errors" due 10 the usage of macros
accep1ance number of possible
Fig. 1 Main1enance of software systems
errors
------------number of macros
Fig.
~b
Possible errors in using macro systems interactively
reat i stic subsets
.".,..-- .......... ,
I
.\:. ~.: J
/ • :' ( (
_ '-'--
: .
\
I
/../,/
~.../'. / / .'-..'.....'-. ...... ........ /./
I
\
'-' .........
.~ ';:--._" ~' \
"..-
,.//.....: .;
, ' ....... ----- .....
,.-
display and keyboard
",
Fig . 5 Hardware for simple interac1 ive programming
ideal subsets
Fig . 2 Subsets of programming languages
manpower for tralnng
language extent Fig . 3 Training effort depending on language extent
199
microprocessor
external storage
higher level language elements of the implementation languag's aRe- ,tfl.6 ffie{)f'O' lang ua g e (mostly macro calls). The system is supplemented by a table controlled program generator (fi g ure 6, part B). This program generator is capable of process1nz sour'ce- pr
implementation are de fined. Tile plo g I'ammermu s t have a very goo d knowl e dge of the .c.orres pon d in g hardware , structure. Laye r Ill: Specific funct i ons are defined as extensions to the implementatlon IariiLia g e. The prog rammer should have g eneral pro g rammin g e xperience and 53 f Ifa :irrD It. flD"'l!!~ &! 0 f the respecti ve application sector. Layer I V: Alternative procedures and sequences are defined by means o f a tabl e definition lan g ua g e. The pro g rammer must primarily be famili a r with the fundamentals of the respective application. Layer V: Interactive user pro g rammin g at the terminal permittin ~ him to construct his s ystem larg ely without specific computer and pro g ra mmin g knov!led g e. These 5 l e vels or la y ers are also reflected by t he composition of a p ro gra mmin g team. >
In accordance with their in d iv i dual e xp erience the team membe rs are assi ? ned to a certain level. Within a level furth e r subdivisions are made de pendin g on professional aspects. It should be pointed out here that each team member only operates within his level. If he needs more resources from another level these must be requ ested by him. However, satisfyin g results can only be ex pected from this method if appropriate procedures for testin g an d error tracin g are available. The above described arran g ement of levels also provides for a sufficient de g ree of freedom from e rro rs (11). There is a correspondence hetween fi ~ ure 6 and the 5 layers: layer 1: part 0, link libra ry layer 2: part A, hardwat'e dependent lib rary layer 3: part A hardware independent 1 ibrary layer 4: part B la y er 5: part C This inherentl y requires that by suitable definitions of individual components testing is possible independent of the respective level's environment! When summarizin g the above mentioned considerations some conclusions can be drawn. The method described not only allows the user to "pro g ram" under his own responsibility, but also ensures that the system produced by him is larg ely free of software errors. From the practical point of view, importance should be directed further to the fact that after a basic i mplementation
200
certain adaptation~ and extensions may well be oerformed, if so requfr~. 4.2 Introduction of a new tool The development of a tool for prof,ram pro duction is often accomplished in isolation from its environment. Necessary for a langua g e are for example efficient compilers, test aids, operatin g systems adaptations, ~nd ttainin~ ~Jteri~l. Extent and importance of these "extra services" are often underestimated. This indicates one reason for the many problems connected with the introduction of new tools. Ir. the following it is assumed that the respective tool is not subject to such deficiencies. An evaluation of initial experience ga ined with a new tool is not without problems. Doubtlessly it is easy to decide whether a project has been a success or a failure (dead-lines, costs, system reliability, etc.). To reveal the real reasons, however, is much more difficult. A critical analysis of corresponding experience re po rts often indicates that formal command of a new tool alone is not sufficient. Even the best tool can be more easily misused than be used in a reasonable manner. When lookin g more closely for the reason it becomes apparent that demands are not satisfied by simply exchangin g an old tool for a new one. What is necessary is to simultaneously investi g ate whether the applied working methods are suitable or not.
5. Conclusions The reliability of software systems for proce6~ cQ~trol is not sufficient to-day. This is especially true for larg e and/or sophisticated systems. Raising the level of a lan guage and enlarging the capacity performance of a langua ge does not solve the problem, if we are only concentrating on lan g ua ges of sequential type. One real reason for this insufficient situation is the necessit y for soecial (individual) lan gua ge s and software svstems. This is true because these tools are used and these products are constructed and used not by machines but by humans. Therefore the only possibility or better the onl y chance is to standardize tools with the help of which the final, non computer-experienced user is able to define his own (individual) system without producin g software errors. To-day such an aim looks phantastic or unreal. Obviously it is not possible to develop and implement the methods and tools necessary in one step. But this paper demonstrates that it is possible to find a way in which parts of the final tools are already very useful. R E FER E N C E S (1)
Abbreviated Test Lan gua ge for Avionics System (ATLAS), ARINC Specification 4168, Aeronatical Radio Inc., Annapolis, Maryland, (1973)
Pilot projects need careful and critical attention. The aims of such attention are on one side • to reco g nize weak points of the new tool and on the other • to give org anisational support to the respective users. Until now very little attention has been directed to human psychological aspects. An exceptionally valuable contribution to close this g ap was provided by Weinberg (20).
(2)
APT Part Pro g rammin g , Mc Graw-Hill Book Co., I~e w York, (1967), (Illinois Institute of Techn.)
(3)
ARSI 80, AEG brochure A 512 06.01 8 0774, (1974)
(4)
Barry W. Boehm: Some Information Pro l cessing Implications of Air Force Space ~issions in the 1970s, Astronautics & Aeronautics, January 1971, pp. 42-50.
The primary task of new tools is to have those pro g rammin g components suitable for mechanization executed by the much more reliable machine. What remains for the pro grammer is that portion which requires his creative capabilities. This evaluation of work sharing between man and machine is considered to be very important since many large and sophisticated process control problems with high requirements on system reliability cannot be solved with those resources which are available at present!
(5)
P.J. Brown: Macro Processors, John Wiley & Sons, London (1974)
(6)
O.-J. Dahl, E.W. Oijkstra, C.A.R. Hoare: Structured Programming, Academic Press, London, pp. 1-82, (1972 )
(7)
E.W. Oijkstra: The Structure of "THE"Multiprogramming System, Communications of the ACM, Vol. 11, No. 5, pp. 341-346, (1968)
(8)
Oonald E. Knuth: Structured Programming with go to Statements, ACM Computin g Surveys, Vol. 6, No. 4, pp. 261-301, (19.14)
201
(9 ,
Programmsystem f1ADAM. Siemens brochure E 312/1107-1115. {'971)
>
?;
:;; >E
E
:;;,...
-:;;,... E
= ~
E
Q;
B
( 10) Guenter Musstopf: Des P rDg rammi 8 rs ystem POLYP, Angewanote IntormatiK, Vol. 10, pp. 441-448, (1972)
..
E
u; E ~~
.e~ uE
( 11) Guenter Musstopf: TO~Jards Software Reliability for Process Control - A status Reoort, 1974 IFAC/IFIP vlorkshop on Real Time Jl'rog Nlllilrd n g , 'Budapest, f1arch 74
.g :;;
~'"
~
,...
"E c: "c:
£J
'"c:
E
( 12) P.C. Poole, W."1. Waite: Portability and Adaptability, Advanced Course on Software Engineering, Springer Verlag, 81 , pp. 183-27 8 , (1973) ( 13) Process Svstems Proe:ram (PROSPRO IBM b ro ch urt. GH 20-4000, (1970)
"6. 0
..
"0
i;. :>
"B
~
.!
.~
II) ,
.~
'"
"0 0 .£;
0; E
E
.. .8. ., . .,<;
"0
E
'"
~
0
~
C
"0
c:
~
"0
~
"0
"0
.£;
.£;
<;
<;
E
o " o.g, ~ Cl.
'"
.!" .!::'"
::J
.!! u
-o "0 c:
::J
c: E
'" "
U;
i;;'
"-'"; c:
Q; 0. 0
.
0 0.
., '" ::
.,
~
.
'" 0 .:: v
.,
"'.£;
<;
:;;,... "0
"0
" c: ,...--' "
~
<;
.£;
,;,
u::
( 14 ) r1inutes of the 1973 Meetin g of the International Purdue Workshop on Industrial Computer Systems, Purdue Laboratory for Applied Industrial Cant ro l, Purdue Un i ve rs it Y, West Lafayette, Indiana, (1973) ( 1 5) C.V. Ramamoorthy, R.C. Cheung, K.H. Kim: Reliability and Integrity of Large Computer Programs, Lecture Notes in Computer Sciences 12, Sprinr,erVerlap;, pp. 86-161, (1974)
0 0 0.
(16 ) Jean E. Sammet: Programming Languages: History and Future, Communications of the ACM, Vol. 15, No. 7, pp. 601-610, (1972) ( 17) O.V. Schorre: Improved Organization fo I' P rocedu ra 1 Lan g uages, Tech. Memo TM 3086/002/00, Systems Development Corp. , (1966)
i
c .~
~~ ~ "gt. 0
( 18) Proceed i ngs of a Symposium on Very High Level Languages, ACM SIGPLAN Notices, Vol. 9, No. 4, (1974)
f@
"c
( 19) W.M. Waite: The mobile P rogrammi nr; System: STAGE2, Communications of the ACM, Vol. 13, pp. 415-421, (1970)
0.
~ OD
(20) Gerald M. Weinberg: The Psychology of Computer Programming, Computer Science Series, van Nostrand Reinhold Company, New York, (1971)
0 0.
!tj e2 00
j
~
c 0
C
0
.2
! j . c
(21 ) N. Wirth: The P rogrammi ng Language PASCAL Acta Informatica 1 , pp. 35-63, (1971 )
u
i
[
~
~
'"
'"
;;:
202