- Email: [email protected]
Successes and Failures using EPOS as a Software Production Tool
Copyright © IFAC Expe rie nce with lhe !\[anagcment of Softwa:'e Projects. Heidelberg, FRG, 19S6
SUCCESSES AND FAILURES USING EPOS AS A SOFTWARE PRODUCTION TOOL T. Schuler, R.
J.
Frank and W. Kratschmer
DOlllier-S)'.Ilelll GlllbH, P.O. Box 136 0, D- 7990 Fril'drirh.l/wji'lI, FRG
Abstract . The system development tool EPOS is discussed describing conceptual strong pOlnts, conceptual shortcomings, and handling characteristics based on experiences we have made during the long-term application of EPOS in different projects using the software specification utilities provided by the tool. In spite of shortcomings shown up EPOS is a living tool of high quality, developed and improved further on. Well suited as a tool for project management, system design and development support. Recommendations for the use of a system development tool in general are given as well as for the use of the tool EPOS in particular. Keywords. Analyzing and Testing Tool; Development Environment; Formal System Specification; Project Management System; Requirement Specification; Software Production Tool; Software engineering. BACKGROUND OF EXPERIENCES
EPOS-R: Requirement Specification Language Text system with an adjustable degree of formality to describe customer needs and system requirements documents as well as the conceptual design
The Informatics Department at Dornier-System was one of the first intensive users of the EPOS tool for development of large software systems. The engagement started in the year 1981 and covered projects in the field of Public Transit, Nuclear Reactor Remote Supervision, Human X-Ray Dosimetry in Nuclear Reactor~ Operation Control Centers for Rescue Services, Vehicle Data Aquisition Systems, Artillery Fire Control System, Satellite Checkout Systems, Software Development Tools.
EPOS-S: Specification Language with formal syntax and defined semant i cs for describing the operat i ona 1 design . EPOS-A: Program System for analyzing and testing the information described by EPOS-R, EPOS-S and EPOS-P.
Typical data of the projects were 3 to 15 team members, and several years of project development. The classes of target computers utilized vary from micro-processor systems, used in aircraft and sate llite onboard systems and portable data processing units, and VAX computers, used for large software systems in operation control centers. The program languages used to implement the software are Assembler, FORTRAN, PEARL, PASCAL and C. Table 1 gives an overview to a collection of projec~s, their size and implementation, realized using the EPOS tool.
EPOS-O: Program System for generating documents according to the information described in EPOS-R, EPOS-S and EPOS-P. EPOS-C: Human interface for communication with EPOS. The use of the component s EPOS-P: Specification Language for describing information related to project management and configuration management.
The EPOS tool is implemented at Dornier-System on several VAX 11/750 machines under VMS operating system and an IBM 4381-3 under VM/CMS operating system.
and
The experiences with EPOS at Dornier-System are based on the use of the EPOS components (Lauber, 1984)
EPOS-M: Program System for computer support (graphical representations) of activities related to project and co nfigur ation management.
125
T. Schuler, R. J. Frank and W. Kratschmer
126
TABLE 1 Project
Projects at Dornier System realized with EPOS Number of Teammembers
Size (Man-Years)
TargetComputer
Program Language
Rufbus (Public Transit )
5
15
VAX 11 /750
PASCAL
ROSAT (Satellite Checkout)
3
6
VAX 11/750 PDP 11/24
PASCAL C
10
25
AEG 80/30 DEA-SEL (Intel 8086)
PEARL + Assembler
ABACUS (Artillery Fire Control System)
5
10
AEG 80/30 DEA-SEL (Intel 8086)
PEARL + Assembler
KFUE (Nucklear Reactor Remote Supervision)
7
10
VAX 11/730
FORTRAN
PERSEUS (Human X-Ray Dosimetry)
8
15
2 * VAX 11/750 2 * PDP 11 /44
PEARL + Assembler
ILSE (Rescue Services Control Center Esslingen)
5
5
VAX 11/750
PASCAL
LARS (Rescue Services Control Cent er Berlin)
5
5
VAX 11 /730
PASCA L
DASU (Vehicle Data Aquisition System)
2
2
Dataprocessor MUDAS-426 (Intel 8086)
PEARL + Assembler
SPRAM (Software System Performance Report and Maintenance Tool)
2
2
VAX 11 /750
PASCAL
ARES (Rocket-Artillery Fire Control System)
has just started and therefore experiences concerning to the use of this EPOS components could not be included into this paper. Two reasons may be mentioned resulting in this situation. The first reason i s, only the latest EPOS release, delivered in january 1986, provides important features of EPOS-P/-M such as generation of bar-chart diagram6 network-plan diagrams, project-structureplan diagrams, and project planning analysis. So efficient use of the components EPOS-P and EPOS-M could not be performed before january 1986 . The second reason i s, you have to use the EPOS tool from the beginning of a project to gain most benefit. Th is condition has to be taken into account for the use of the components EPOS-P and EPOS-M, particularly. CONCEPTUAL STRONG POINTS AND SHORTCOMINGS During the long-term application of EPOS in different projects the conceptual strong points and shortcomings of the tool EPOS showed up. The product EPOS was developed further in these years and even completely new components like process-management support (EPOS-P/-M) were added. Our assessment is therefore mainly a look back. Conceptual Strong Points - The application of EPOS tool for system develop' ment guides the system engineer to produce structured design and concurrent computer supported documentation throughout the complete system's live-cycle. - The EPOS tool uses a rather transparent set of description objects. The requirement specifi-
cation language (EPOS-R) uses only four elementary objects (SECTION, REQUIREMENT, CONSTRAINT, DECISION-PROCESS), the design specification language (EPOS-S) only seven (MODULE, ACTION, DATA, EVENT, INTERFACE, CONDITION, DEVICE) and the project-management description language only five (ACTIVITY, TEAMMEMBER, CHANGE-PROPOSAL, PROGRESS-REPORT, ERROR-REPORT) . The use of only 16 basic elements for description of a system development project allows for the user in prinicipal a relatively simple start with the formal syntax of this tool. But there are serious problems which will become clear later on. - The whole tool ~uppo rts consistently all phases of a project. There are means to formalize the transfer between project phases, e.g for the transfer·fromrequi~emer;t to design ·s pecification the formal inserts (REQUIREMENTS) can be related to the corresponding fulfillments and checks concerning completeness of the design can be made. There are also partly automat i c mechanisms for the step from design to coding. - Nearly all development phases from requirement specification up to maintenance are covered by one single tool. One must remark, however, that a gapless coverage is not yet reached, particularly for code generation and support, planning, and management of tests. - The tool is suited to support both software and hardware development. The hardware development description is however in a rather preliminary stage and supports only design at the level of assembly groups .. An interface to
127
Successes and Failures using EPOS
CAD-systems is in discussion and is a medium term aim. - During the design specification phase the choise among several design methods is free for the user (function-oriented, event-oriented, module-oriented, dataflow-oriented, data structure-oriented, device-oriented). All methods are based on the same basic objects of EPOS-S. The choice of one method results in a corresponding guidance at the user interface. The EPOS analyzing system (EPOS-A) performs consistency checks which depend on the design method. - The development of real-time software systems is heavily supported by the description elements for parallelity and synchronization. Together with the appropriate visual description with PETRI-nets the errorless specification of real-time requirements at high-order language level becomes fea sible. - The analytical possibilities for the check of all definitions in terms of the EPOS tool go beyond pure syntactical correct ness. By this means the design can be checked with respect to completeness, name conflicts, not referenced objects, and unneces sary design objects. The completeness check between requirements spec ification and design specification is in our opinion one of the most i mpor tant and useful features of EPOS.
ACTION example-l . DESCRIPTION: PURPOSE: "text ... " DESCRIPTIONEND. DECOMPOSITION: If count-condition THEN count-up ELSE Count-down FI. ACTIONEND ACTION count-up. DESCRIPTION. PURPOSE: "text ... " DESCRIPTIONEND. CODE:"counter := counter ACTIONEND
+
1,"
ACTION count-down. DESCRIPTION: PURPOSE: "text ... " DESCRIPTIONEND. CODE: "counter : = counter - 1;" ACTIONEND CONDITION count- condition . DESCRIPTION: PURPOSE: "text ... " DESCRIPTIONEND. DECOMPOSITION: a GT b. CONDITIONEND
Conceptual Shortcoming - The structure of the data base utilized in EPOS is not transparent for the user. Practical problems in the use like overfilling of the data base or partial retrivial of information can be solved only with the help of the EPOS distributor. Particularly adaptions to the EPOS tool by the use, him sel f are inhibited. The creation of interfaces to other system development tools are nearly impossible. This is a disadvantage which i s not acceptable on the long-term. It seems as if a trend towards in corporation of this possibility can be recognized from current activities. A user interface to the data base with query language is desirable. The following problems are related to the design specification language (EPOS-S): - The strict use of pseudo code for the decomposition of ACTIONS lead s to an "atomization" of the system design in the sense that a great number of very short ACTIONS has to be created and described. It would be very helpful to give up the strict distinction between DECOMPOSITION-part and CODE-part. We propose the possibility to mix pseudo code and code together with comments in the sense of a natural code structure. Thi s impli cates in addition that a seperate definition of branching via CONDITION elements is only necessary for very complex logical conditions or to define logical procedures. Figure 1 shows an example of the present way to compose an EPOS-S specification using terminal actions to specify the code and Fig. 2 demonstrates a reduced description proposed. - The possibilities and particularly the practical use of data structuring and type definition are not compareable with the standard given for example by PASCAL or ADA. The definition of data types and variables is very uncomfortable and way-off from usual modern high-order languages. The description amount is enormous. Practical experiences show that the description of the same data structure as a RECORD in PASCAL needs about 20 lines, where the code is already grouped in lines for better visual presentation, compared to about 20 pages
Fig. 1. EPOS-S spec ifi cat ion present implementation ACTION example-l. DESCRIPTION: PURPOSE : "~ext ... " DESCRIPTIONEND. DECOMPOS I TI ON: If % a> b % {comment, text ~ THEN % counter := counter +1; % {comment, te xt} ELSE % counter : = counter +1; % {comment, te xt} FI. ACTIONEND where % will be used as code delimiters and {} wi 11 be used as comment del imiters Fig. 2. Reduced EPOS-S spec ification proposed. in EPOS-S te xt documentation. This data definition is virtually unreadable. This will be domonstrated by a simp le example specifying an "address" in Fig. 3 as a PASCAL RECORD and in Fig. 4 as the basic EPOS-S DATA spec ification - Definition of data str uctu re s and data types is not sufficiently differentiated. This results from the additional implementation of data types to satisfy requirements to EPOS-S to support de s ign specifications to modern high-order languages implementations. - A top-down dataflow design is not properly supported by EPOS-S. This is true even for the dataflow-oriented design method. This contradicts the natural design process. The user is forced to define the dataflow immediately on basis of the isolated data definition.
T. Schuler, R. J. Frank and W. Kratschmer
128
The INTERFACE-concept in EPOS is not suited to describe software interfaces between modules or independent processes, therefore the frequently used method of software design from the viewpoint of interface description is not supported. This comes about because the object INTERFACE is mainly used to describe the data exchange between the technical system and its environment (e.g. the technical process, the user, etc.). In software projects exists, however, the necessity to define logical interfaces between subsystems in an early stage before the final specification is finished. This is true for interfaces between hardware and / or software modules. {comment, text ... } address: RECORD ARRAY [1 .. 32] of CHAR; name: {comment, text ... } firstname: ARRAY {1 .. 32] of CHAR; {comment, text ... } ARRAY [1..32] of CHAR; . street: {comment, text ... } ARRAY ~ .. 32] of CHAR; . town: {comment, text . . . ] END; Fig. 3. Data Record "address" in PASCAL DATA address. DESCRIPTION: PURPOSE : "text ... " DESCRIPTIONEND. DECOMPOSITION: name; firstname; street; town . DATAEND DATA ARRAY name. DESCRIPTION: PURPOSE:"text . . . " DESCiHPTIONEND TYPE: CHAR . BOUNDS: (1: 32) . DATAEND DATA ARRAY firstname. DESCRIPTION: PURPOSE: "text ... " DESCRIPTIONEND. TYPE: CHAR. BOUNDS: (1 :32) DATAEND DATA ARRAY street. DESCRIPTION: PURPOSE: "text ... " DESCRIPTIONEND. TYPE: CHAR. BOUNDS: (1: 32) . DATAEND DATA ARRAY town. DESCRIPTION PURPOSE: "text ... " DESCRIPTIONEND. TYPE: CHAR: BOUNDS: (1: 32). DATAEND Fig.4. Data Record "address" in EPOS-S HANDLING CHARACTERISTICS The acceptance of a tool by engineers depends on simple and comfortable handling in the first place. The following points will show up constraints and handling characteristics supporting and preventing fast acceptance by the user. The introduction of the EPOS tool for development
of software system is associated with modifications in the project cycle resulting in the constraint of systematic and structured approach by concurrent computer supported documentation. So the correct and efficient use of the EPOS tool requires intensive education and training of the design engineers as well as the project managers to understand the EPOS design philosophy and to know all the features provided by the EPOS tool. Handling of EPOS is easy to learn and communication with EPOS is very simple, but the user interface is very clumsy caused by a communication system who's realization is very simple and who's implementation is portable to all computers and terminals . The communication sy stem EPOS-C is composed by a question and answer dialogue tree . So the user is requested to answer a lot of questions to come to the desired point within the EPOS tool. Some helps are implemented to accelerate the dialogue, such as "Reduced Input" and "User-defined Dialogue Macros" . But all help cannot remove the clumsiness of the communication. The "Reduced Input" does not relieve the user to input all the answers required and the "User-defined Dialogue Macros", which specify a defined way th r ough the communication tree to reach a defined point, can be used only, if the EPOS system file "WRSYS" is held as a copy by each EPOS user. This is very diskspace consuming because each copy of the EPOS system file needs more than 600 kbyte. A solution supposed is to separate a "Project Information and User-defined Dialogue Macro" file from the EPOS system file to allow all EPOS users to use the macro definition utility without restrictions and to hold the EPOS system file shareab1e only once. EPOS-R is based on a file-oriented text system which requires to know only a few control commands to formate a design document and the syntax of formal specifications such as "Requirements" and "Constraints" described by a natura1language text or by a decision table is rather simple and easy to learn. In EPOS-R the possibility of graphical input is missed for direct, computer supported insertion of illustrations into a requirement specification. Using the actual EPOS system space has to be left free for illustrations, directed by formatting control commands, and the figures have to be pasted into the final documentation by hand. The composition of EPOS-S objects is well described by the syntax graph diagrams defined in the EPOS user manuals but the purpose of a syntax element is not always explained in the handbooks transparer.tly . The form processor to edit EPOS-S and EPOS-P formal language specifications is rather primitive. At the present VAX implementation the VMS-Editor is called creating a subprocess from EPOS and templates can be inserted and edited. The templates provided by object mask files are incomplete. A syntax oriented editor who offers comfortable form processing is announced by the EPOS distributor. The layout of documents generated by the component EPOS-D is very inflexible and paper consuming. The standard header page and the header of each page of a document are not uniform for all text documents generated by EPOS-D and its contents cannot be changed by the user. Text documents created from EPOS-S specifications are not very clear arranged and are very hard to read. This is the result of presenting specification elements logically grouped together in a distributed way
Successes and Failures using EPOS
using hierarchical or alphabetical organization, and a very column consuming formatting for the decomposition controlflow structures (complete keywords are shifted right for each structure level). Therefore an EPOS-S specification text document comes into risk never to be read. Handling of the EPOS data base is very uncomfortable for managing projects with more than one team member, because access to the data base is not shareable in the actual EPOS system. At present EPOS is a single user tool, only. Implementation of multi user operation is requested by the EPOS users to be implemented by the tool developer. For managing projects with more than one team member an EPOS data base has to be generated for every team member to perform the individual work packages, and an EPOS project data base has to be generated to integrate all work packages isolated developed. This leads to additional work because interface inconsistencies between work packages can be detected by the EPOS analyzing system only after integration of the work packages into the project data base and not during work package development phase. The EPOS system management requires an operator familiar with the computer system and the operating system used to link and install a new release of the EPOS tool. If major changes are contained in a new release such as new features added, the EPOS data base is not compatible to the data base of the previous release in general. This leads to additional work for all projects using EPOS. New EPOS data bases have to be generated and the source specifications have to be put into the new data base. GUIDELINES FOR THE USE OF EPOS For a successful work with EPOS it is absolutely necessary to define guidelines for the use of specific features of the design system and to arrange for a comfortable and efficient environment. These guidelines will normally have a general part which is valid for all software and sY,stem deve 1opment proj ects in a department or division of a company. In addition each project will modify and complement these general rules according to the specific needs of the project. This will be true at least for larger projects with a great number of team members and a long duration. First some general remarks: - Because of the rather high complexity of the underlying development method a very thorough education of the EPOS users is essential for a successful use of this tool. We had projects where the team members only learned the handling of the EPOS system but not the underlying "philosophy". This ended with cost additions and frustrated team members. It is obviously more difficult to use EPOS not only formally correct but according to the design model than to use a high order programming language. - It is very wise to use EPOS from the beginning of the project starting with EPOS-R. Otherwise not the full advantage of this tool is achieved. The general part of the guidelines deals mainly with organizational and administrative items, whereas the project specific part should define working rules for the use of the EPOS design language similarly to rules for coding which are in use in nearly every software department. The guidelines which we present here as an overview do not claim to be complete nor even consistent. But the experience shows that they are EMSF'-J
129
of great help for the practical work and to reduce the risk of failure using EPOS. General Guidelines The general guidelines organize the following: - What kind of projects should be developed using EPOS? This depends partly on external restrictions and and instructions. From our experience comes the opinion that other criteria like - project size, - project duration, - number of team members, - used development host and/or target computer, - used programming language play an additional role. Roughly speaking we recommend to use EPOS as development tool for projects if several of the following criteria are true - project duration more than one year, - more than 2-3 team members, - that means a project size of more than 3 manyears. We particularly recommend to use EPOS for development in lower level languages and with host computers with poor utilities for software development support. If on the host computer EPOS is not available we will prefer to make the complete design phases with EPOS on even another computer where EPOS is available. For small, short projects the overhead by using EPOS is too large in our opinion. This is true even for expe r ienced EPOS-users because of the already mer:t i oned unhandyness of the user interface. Project Specific Guidelines The project specific part of the guidelines must at least make statements about the following items: - Which optional parts of the object description should be used in what sense? One can, for example, use the NOTE- and IDENTIFICATION-parts of the description to give specific informations like references to other documents (NOTE) or internal characterization of the design object (IDENTIFICATION). We also define project-specificly down to which level the REALIZATION-part and the PROCESSED-part must be defined or in what particular circumstances these parts are obligatory. For example only for those ACTIONS the programming language will be explicitly given where it differs from the lot. Similarly one has to fix which informations about test strategy, test methods, test institutions etc. should written down at which object type. We recommend to insert general statements about test strategies and methods once and for all at the highest level possible. - Definition of allowed "style variants". It is, for example, extremely dangerous to allow unlimited use of "extended identifiers". Otherwise a great part of the significant formal information (e.g. controlflow in ACTIONS or data structures in DATA) could be incorporated in these "extended identifiers" and therefore could not be interpreted and analyzed by EPOS. On the other hand the use of "extended i dent ifi ers" is the on ly way to avoid the creation of a tremendous number of very small ACTIONS. Because the name of these alone is normally not sufficiently significant they need a full description.
130
T. Schuler, R. J. Frank and W. Kratschmer
This can be avoided by a proper use of "extended identifiers". We made a proposal to overcome thi s problem in another post of thi s paper. - The use of the object ACTION MODULE must be guided by the functional structure of the object. In simply structured and weak interconnected projects it might be sensible to avoid the use of ACTION MODULE completely. - It is necessary to define (of course extendable) thesaurus and - using the new feature of twostep categories - a structure of the CATEGORIES which should be used. Otherwise they will be of rather limited benefit for selection purposes. - Concerning the relation of formal and actual parameters (alt-param-list) we strongly recommend to use instead the data transfer mechanism at the reference of the ACTION with the keyword USING. - One must avoid the "atomization" of the system design by a great number of very small rather trivial object descriptions. To achieve this aim we have first to limit the pseudo code decomposition to a certain depth. Below of this level one should use the CODE-part or else describe further details in the PURPOSEpart. Secondly one can employ a short-hand notation for certain constructs where the meaning is hidden in the (possibly extended) identifier and not directly written down in EPOS syntax. - One has to define pragmatic rules for the use of the INTERFACE-object and the dataflow-part for the description of software interfaces (either procedure-calls or process/taskcommunication). The INTERFACE-object as it is defined in EPOS is directed towards the description of hardware interfaces. It is not possible to refer in the INTERFACE-description directly to DATA or ACTIONS and to the flow of data between ACTIONS. For pure software interfaces we recorr.mend to write down the usual descriptive informations in the description part and to define rules for formatting these informations. - One has to decide at which level of the data descriptions dataflow-parts should be used. It is absolutely necessary to have a uniform manner among the project team. Otherwise dataflow diagrams would show to be very non-uniform. We recommend to use the dataflow-part mainly at the higher levels of the data structures and in particular not to leave gaps. The last statement means that one should not use dataflow-parts only at the high and low data levels and not between. Another point of view would be to restrict dataflowdescriptions to such data which correspond to hardware and/or software interfaces. - Concerning the practical use of EPOS in dayly software life, rules and guidelines for the following activittes are necessary: - How to produce uniform EPOS documents (prints and plots)? To achieve this aim easier and more reliably it is necessary to give every software engineer utilities (macros, command procedures) at hand. There must be defined procedure to distribute the knowledge about them in the project team. - Similarly it is absolutely necessary to have methods and command procedures for comfortable utilization of EPOS in the system environment of a specific project. Very important is, for example, to produce fast and easy unified EPOS source files or data bases from separate ones . - As far as EPOS-R is concerned the following hint is valuable. Especially EPOS-R is sometimes used simply as a text system, a task to which it is not well suited. Therefore it is of high importance to educate the software
engineers to use the formal description methods in EPOS-R (formal requirement inserts, decisions tables etc.) as far as possible. CONCLUSION The use of EPOS in the system design phases will not result automatically in cost reduction compared with projects performed USing conventional design methods. The computer supported documentation generated and updated concurrently to the design phases leads to additional work in the early project phases. No active test support is provided by the present EPOS tool. But the quality of the software developed using the tool EPOS is improved considerabl y . The software design is buildt up consistently and logically and transparence is increased using formal inserts in the requirement specifications and the corresponding fulfillment s and checks in the design specifications . The system test and integration is accelerated and relieved by the complete and actual documentation which is available in this project phase. The maintainability of systems developed with EPOS will be better, system bugs found during operation can be solved faster and modifications can be implemented and documented without complicati ons. Caused by its diversity and clear pI anned concept the EPOS tool sugge sts to constructive critique, extension and improvement propositions. This is supported by an intensive cooperation of the EPOS users on one side and the EPOS developer and the EPOS di stributor on the other side. Significant extension s and improvements in EPOS were initiated by active EPOS user s in the past and other s will follow. This demonstrates that EPOS is a living tool of high quality who's shortcomings will be eliminated in future. The use of a syst em development tool such as EPOS will not eliminate the design engineer s job. The daily work of the de sign engineer is supported and relieved by the development tool, which is the slave of the engineer, to leave more time for creative engineering. The tool will never be the master who relieves the engineer of thinking . The experienced design and development engineer, creative and familiar with the use of his slaves will be a demanded expert today as well as in future. REFERENCES Lauber, R. July 1984 EPOS Primer - A short introduction to the EPOS system Institute for Control Engineering and Process Automation University of Stuttgart
SUCCESSES AND FAILURES USING EPOS AS A SOFTWARE PRODUCTION TOOL T. Schuler, R.
J.
Frank and W. Kratschmer
DOlllier-S)'.Ilelll GlllbH, P.O. Box 136 0, D- 7990 Fril'drirh.l/wji'lI, FRG
Abstract . The system development tool EPOS is discussed describing conceptual strong pOlnts, conceptual shortcomings, and handling characteristics based on experiences we have made during the long-term application of EPOS in different projects using the software specification utilities provided by the tool. In spite of shortcomings shown up EPOS is a living tool of high quality, developed and improved further on. Well suited as a tool for project management, system design and development support. Recommendations for the use of a system development tool in general are given as well as for the use of the tool EPOS in particular. Keywords. Analyzing and Testing Tool; Development Environment; Formal System Specification; Project Management System; Requirement Specification; Software Production Tool; Software engineering. BACKGROUND OF EXPERIENCES
EPOS-R: Requirement Specification Language Text system with an adjustable degree of formality to describe customer needs and system requirements documents as well as the conceptual design
The Informatics Department at Dornier-System was one of the first intensive users of the EPOS tool for development of large software systems. The engagement started in the year 1981 and covered projects in the field of Public Transit, Nuclear Reactor Remote Supervision, Human X-Ray Dosimetry in Nuclear Reactor~ Operation Control Centers for Rescue Services, Vehicle Data Aquisition Systems, Artillery Fire Control System, Satellite Checkout Systems, Software Development Tools.
EPOS-S: Specification Language with formal syntax and defined semant i cs for describing the operat i ona 1 design . EPOS-A: Program System for analyzing and testing the information described by EPOS-R, EPOS-S and EPOS-P.
Typical data of the projects were 3 to 15 team members, and several years of project development. The classes of target computers utilized vary from micro-processor systems, used in aircraft and sate llite onboard systems and portable data processing units, and VAX computers, used for large software systems in operation control centers. The program languages used to implement the software are Assembler, FORTRAN, PEARL, PASCAL and C. Table 1 gives an overview to a collection of projec~s, their size and implementation, realized using the EPOS tool.
EPOS-O: Program System for generating documents according to the information described in EPOS-R, EPOS-S and EPOS-P. EPOS-C: Human interface for communication with EPOS. The use of the component s EPOS-P: Specification Language for describing information related to project management and configuration management.
The EPOS tool is implemented at Dornier-System on several VAX 11/750 machines under VMS operating system and an IBM 4381-3 under VM/CMS operating system.
and
The experiences with EPOS at Dornier-System are based on the use of the EPOS components (Lauber, 1984)
EPOS-M: Program System for computer support (graphical representations) of activities related to project and co nfigur ation management.
125
T. Schuler, R. J. Frank and W. Kratschmer
126
TABLE 1 Project
Projects at Dornier System realized with EPOS Number of Teammembers
Size (Man-Years)
TargetComputer
Program Language
Rufbus (Public Transit )
5
15
VAX 11 /750
PASCAL
ROSAT (Satellite Checkout)
3
6
VAX 11/750 PDP 11/24
PASCAL C
10
25
AEG 80/30 DEA-SEL (Intel 8086)
PEARL + Assembler
ABACUS (Artillery Fire Control System)
5
10
AEG 80/30 DEA-SEL (Intel 8086)
PEARL + Assembler
KFUE (Nucklear Reactor Remote Supervision)
7
10
VAX 11/730
FORTRAN
PERSEUS (Human X-Ray Dosimetry)
8
15
2 * VAX 11/750 2 * PDP 11 /44
PEARL + Assembler
ILSE (Rescue Services Control Center Esslingen)
5
5
VAX 11/750
PASCAL
LARS (Rescue Services Control Cent er Berlin)
5
5
VAX 11 /730
PASCA L
DASU (Vehicle Data Aquisition System)
2
2
Dataprocessor MUDAS-426 (Intel 8086)
PEARL + Assembler
SPRAM (Software System Performance Report and Maintenance Tool)
2
2
VAX 11 /750
PASCAL
ARES (Rocket-Artillery Fire Control System)
has just started and therefore experiences concerning to the use of this EPOS components could not be included into this paper. Two reasons may be mentioned resulting in this situation. The first reason i s, only the latest EPOS release, delivered in january 1986, provides important features of EPOS-P/-M such as generation of bar-chart diagram6 network-plan diagrams, project-structureplan diagrams, and project planning analysis. So efficient use of the components EPOS-P and EPOS-M could not be performed before january 1986 . The second reason i s, you have to use the EPOS tool from the beginning of a project to gain most benefit. Th is condition has to be taken into account for the use of the components EPOS-P and EPOS-M, particularly. CONCEPTUAL STRONG POINTS AND SHORTCOMINGS During the long-term application of EPOS in different projects the conceptual strong points and shortcomings of the tool EPOS showed up. The product EPOS was developed further in these years and even completely new components like process-management support (EPOS-P/-M) were added. Our assessment is therefore mainly a look back. Conceptual Strong Points - The application of EPOS tool for system develop' ment guides the system engineer to produce structured design and concurrent computer supported documentation throughout the complete system's live-cycle. - The EPOS tool uses a rather transparent set of description objects. The requirement specifi-
cation language (EPOS-R) uses only four elementary objects (SECTION, REQUIREMENT, CONSTRAINT, DECISION-PROCESS), the design specification language (EPOS-S) only seven (MODULE, ACTION, DATA, EVENT, INTERFACE, CONDITION, DEVICE) and the project-management description language only five (ACTIVITY, TEAMMEMBER, CHANGE-PROPOSAL, PROGRESS-REPORT, ERROR-REPORT) . The use of only 16 basic elements for description of a system development project allows for the user in prinicipal a relatively simple start with the formal syntax of this tool. But there are serious problems which will become clear later on. - The whole tool ~uppo rts consistently all phases of a project. There are means to formalize the transfer between project phases, e.g for the transfer·fromrequi~emer;t to design ·s pecification the formal inserts (REQUIREMENTS) can be related to the corresponding fulfillments and checks concerning completeness of the design can be made. There are also partly automat i c mechanisms for the step from design to coding. - Nearly all development phases from requirement specification up to maintenance are covered by one single tool. One must remark, however, that a gapless coverage is not yet reached, particularly for code generation and support, planning, and management of tests. - The tool is suited to support both software and hardware development. The hardware development description is however in a rather preliminary stage and supports only design at the level of assembly groups .. An interface to
127
Successes and Failures using EPOS
CAD-systems is in discussion and is a medium term aim. - During the design specification phase the choise among several design methods is free for the user (function-oriented, event-oriented, module-oriented, dataflow-oriented, data structure-oriented, device-oriented). All methods are based on the same basic objects of EPOS-S. The choice of one method results in a corresponding guidance at the user interface. The EPOS analyzing system (EPOS-A) performs consistency checks which depend on the design method. - The development of real-time software systems is heavily supported by the description elements for parallelity and synchronization. Together with the appropriate visual description with PETRI-nets the errorless specification of real-time requirements at high-order language level becomes fea sible. - The analytical possibilities for the check of all definitions in terms of the EPOS tool go beyond pure syntactical correct ness. By this means the design can be checked with respect to completeness, name conflicts, not referenced objects, and unneces sary design objects. The completeness check between requirements spec ification and design specification is in our opinion one of the most i mpor tant and useful features of EPOS.
ACTION example-l . DESCRIPTION: PURPOSE: "text ... " DESCRIPTIONEND. DECOMPOSITION: If count-condition THEN count-up ELSE Count-down FI. ACTIONEND ACTION count-up. DESCRIPTION. PURPOSE: "text ... " DESCRIPTIONEND. CODE:"counter := counter ACTIONEND
+
1,"
ACTION count-down. DESCRIPTION: PURPOSE: "text ... " DESCRIPTIONEND. CODE: "counter : = counter - 1;" ACTIONEND CONDITION count- condition . DESCRIPTION: PURPOSE: "text ... " DESCRIPTIONEND. DECOMPOSITION: a GT b. CONDITIONEND
Conceptual Shortcoming - The structure of the data base utilized in EPOS is not transparent for the user. Practical problems in the use like overfilling of the data base or partial retrivial of information can be solved only with the help of the EPOS distributor. Particularly adaptions to the EPOS tool by the use, him sel f are inhibited. The creation of interfaces to other system development tools are nearly impossible. This is a disadvantage which i s not acceptable on the long-term. It seems as if a trend towards in corporation of this possibility can be recognized from current activities. A user interface to the data base with query language is desirable. The following problems are related to the design specification language (EPOS-S): - The strict use of pseudo code for the decomposition of ACTIONS lead s to an "atomization" of the system design in the sense that a great number of very short ACTIONS has to be created and described. It would be very helpful to give up the strict distinction between DECOMPOSITION-part and CODE-part. We propose the possibility to mix pseudo code and code together with comments in the sense of a natural code structure. Thi s impli cates in addition that a seperate definition of branching via CONDITION elements is only necessary for very complex logical conditions or to define logical procedures. Figure 1 shows an example of the present way to compose an EPOS-S specification using terminal actions to specify the code and Fig. 2 demonstrates a reduced description proposed. - The possibilities and particularly the practical use of data structuring and type definition are not compareable with the standard given for example by PASCAL or ADA. The definition of data types and variables is very uncomfortable and way-off from usual modern high-order languages. The description amount is enormous. Practical experiences show that the description of the same data structure as a RECORD in PASCAL needs about 20 lines, where the code is already grouped in lines for better visual presentation, compared to about 20 pages
Fig. 1. EPOS-S spec ifi cat ion present implementation ACTION example-l. DESCRIPTION: PURPOSE : "~ext ... " DESCRIPTIONEND. DECOMPOS I TI ON: If % a> b % {comment, text ~ THEN % counter := counter +1; % {comment, te xt} ELSE % counter : = counter +1; % {comment, te xt} FI. ACTIONEND where % will be used as code delimiters and {} wi 11 be used as comment del imiters Fig. 2. Reduced EPOS-S spec ification proposed. in EPOS-S te xt documentation. This data definition is virtually unreadable. This will be domonstrated by a simp le example specifying an "address" in Fig. 3 as a PASCAL RECORD and in Fig. 4 as the basic EPOS-S DATA spec ification - Definition of data str uctu re s and data types is not sufficiently differentiated. This results from the additional implementation of data types to satisfy requirements to EPOS-S to support de s ign specifications to modern high-order languages implementations. - A top-down dataflow design is not properly supported by EPOS-S. This is true even for the dataflow-oriented design method. This contradicts the natural design process. The user is forced to define the dataflow immediately on basis of the isolated data definition.
T. Schuler, R. J. Frank and W. Kratschmer
128
The INTERFACE-concept in EPOS is not suited to describe software interfaces between modules or independent processes, therefore the frequently used method of software design from the viewpoint of interface description is not supported. This comes about because the object INTERFACE is mainly used to describe the data exchange between the technical system and its environment (e.g. the technical process, the user, etc.). In software projects exists, however, the necessity to define logical interfaces between subsystems in an early stage before the final specification is finished. This is true for interfaces between hardware and / or software modules. {comment, text ... } address: RECORD ARRAY [1 .. 32] of CHAR; name: {comment, text ... } firstname: ARRAY {1 .. 32] of CHAR; {comment, text ... } ARRAY [1..32] of CHAR; . street: {comment, text ... } ARRAY ~ .. 32] of CHAR; . town: {comment, text . . . ] END; Fig. 3. Data Record "address" in PASCAL DATA address. DESCRIPTION: PURPOSE : "text ... " DESCRIPTIONEND. DECOMPOSITION: name; firstname; street; town . DATAEND DATA ARRAY name. DESCRIPTION: PURPOSE:"text . . . " DESCiHPTIONEND TYPE: CHAR . BOUNDS: (1: 32) . DATAEND DATA ARRAY firstname. DESCRIPTION: PURPOSE: "text ... " DESCRIPTIONEND. TYPE: CHAR. BOUNDS: (1 :32) DATAEND DATA ARRAY street. DESCRIPTION: PURPOSE: "text ... " DESCRIPTIONEND. TYPE: CHAR. BOUNDS: (1: 32) . DATAEND DATA ARRAY town. DESCRIPTION PURPOSE: "text ... " DESCRIPTIONEND. TYPE: CHAR: BOUNDS: (1: 32). DATAEND Fig.4. Data Record "address" in EPOS-S HANDLING CHARACTERISTICS The acceptance of a tool by engineers depends on simple and comfortable handling in the first place. The following points will show up constraints and handling characteristics supporting and preventing fast acceptance by the user. The introduction of the EPOS tool for development
of software system is associated with modifications in the project cycle resulting in the constraint of systematic and structured approach by concurrent computer supported documentation. So the correct and efficient use of the EPOS tool requires intensive education and training of the design engineers as well as the project managers to understand the EPOS design philosophy and to know all the features provided by the EPOS tool. Handling of EPOS is easy to learn and communication with EPOS is very simple, but the user interface is very clumsy caused by a communication system who's realization is very simple and who's implementation is portable to all computers and terminals . The communication sy stem EPOS-C is composed by a question and answer dialogue tree . So the user is requested to answer a lot of questions to come to the desired point within the EPOS tool. Some helps are implemented to accelerate the dialogue, such as "Reduced Input" and "User-defined Dialogue Macros" . But all help cannot remove the clumsiness of the communication. The "Reduced Input" does not relieve the user to input all the answers required and the "User-defined Dialogue Macros", which specify a defined way th r ough the communication tree to reach a defined point, can be used only, if the EPOS system file "WRSYS" is held as a copy by each EPOS user. This is very diskspace consuming because each copy of the EPOS system file needs more than 600 kbyte. A solution supposed is to separate a "Project Information and User-defined Dialogue Macro" file from the EPOS system file to allow all EPOS users to use the macro definition utility without restrictions and to hold the EPOS system file shareab1e only once. EPOS-R is based on a file-oriented text system which requires to know only a few control commands to formate a design document and the syntax of formal specifications such as "Requirements" and "Constraints" described by a natura1language text or by a decision table is rather simple and easy to learn. In EPOS-R the possibility of graphical input is missed for direct, computer supported insertion of illustrations into a requirement specification. Using the actual EPOS system space has to be left free for illustrations, directed by formatting control commands, and the figures have to be pasted into the final documentation by hand. The composition of EPOS-S objects is well described by the syntax graph diagrams defined in the EPOS user manuals but the purpose of a syntax element is not always explained in the handbooks transparer.tly . The form processor to edit EPOS-S and EPOS-P formal language specifications is rather primitive. At the present VAX implementation the VMS-Editor is called creating a subprocess from EPOS and templates can be inserted and edited. The templates provided by object mask files are incomplete. A syntax oriented editor who offers comfortable form processing is announced by the EPOS distributor. The layout of documents generated by the component EPOS-D is very inflexible and paper consuming. The standard header page and the header of each page of a document are not uniform for all text documents generated by EPOS-D and its contents cannot be changed by the user. Text documents created from EPOS-S specifications are not very clear arranged and are very hard to read. This is the result of presenting specification elements logically grouped together in a distributed way
Successes and Failures using EPOS
using hierarchical or alphabetical organization, and a very column consuming formatting for the decomposition controlflow structures (complete keywords are shifted right for each structure level). Therefore an EPOS-S specification text document comes into risk never to be read. Handling of the EPOS data base is very uncomfortable for managing projects with more than one team member, because access to the data base is not shareable in the actual EPOS system. At present EPOS is a single user tool, only. Implementation of multi user operation is requested by the EPOS users to be implemented by the tool developer. For managing projects with more than one team member an EPOS data base has to be generated for every team member to perform the individual work packages, and an EPOS project data base has to be generated to integrate all work packages isolated developed. This leads to additional work because interface inconsistencies between work packages can be detected by the EPOS analyzing system only after integration of the work packages into the project data base and not during work package development phase. The EPOS system management requires an operator familiar with the computer system and the operating system used to link and install a new release of the EPOS tool. If major changes are contained in a new release such as new features added, the EPOS data base is not compatible to the data base of the previous release in general. This leads to additional work for all projects using EPOS. New EPOS data bases have to be generated and the source specifications have to be put into the new data base. GUIDELINES FOR THE USE OF EPOS For a successful work with EPOS it is absolutely necessary to define guidelines for the use of specific features of the design system and to arrange for a comfortable and efficient environment. These guidelines will normally have a general part which is valid for all software and sY,stem deve 1opment proj ects in a department or division of a company. In addition each project will modify and complement these general rules according to the specific needs of the project. This will be true at least for larger projects with a great number of team members and a long duration. First some general remarks: - Because of the rather high complexity of the underlying development method a very thorough education of the EPOS users is essential for a successful use of this tool. We had projects where the team members only learned the handling of the EPOS system but not the underlying "philosophy". This ended with cost additions and frustrated team members. It is obviously more difficult to use EPOS not only formally correct but according to the design model than to use a high order programming language. - It is very wise to use EPOS from the beginning of the project starting with EPOS-R. Otherwise not the full advantage of this tool is achieved. The general part of the guidelines deals mainly with organizational and administrative items, whereas the project specific part should define working rules for the use of the EPOS design language similarly to rules for coding which are in use in nearly every software department. The guidelines which we present here as an overview do not claim to be complete nor even consistent. But the experience shows that they are EMSF'-J
129
of great help for the practical work and to reduce the risk of failure using EPOS. General Guidelines The general guidelines organize the following: - What kind of projects should be developed using EPOS? This depends partly on external restrictions and and instructions. From our experience comes the opinion that other criteria like - project size, - project duration, - number of team members, - used development host and/or target computer, - used programming language play an additional role. Roughly speaking we recommend to use EPOS as development tool for projects if several of the following criteria are true - project duration more than one year, - more than 2-3 team members, - that means a project size of more than 3 manyears. We particularly recommend to use EPOS for development in lower level languages and with host computers with poor utilities for software development support. If on the host computer EPOS is not available we will prefer to make the complete design phases with EPOS on even another computer where EPOS is available. For small, short projects the overhead by using EPOS is too large in our opinion. This is true even for expe r ienced EPOS-users because of the already mer:t i oned unhandyness of the user interface. Project Specific Guidelines The project specific part of the guidelines must at least make statements about the following items: - Which optional parts of the object description should be used in what sense? One can, for example, use the NOTE- and IDENTIFICATION-parts of the description to give specific informations like references to other documents (NOTE) or internal characterization of the design object (IDENTIFICATION). We also define project-specificly down to which level the REALIZATION-part and the PROCESSED-part must be defined or in what particular circumstances these parts are obligatory. For example only for those ACTIONS the programming language will be explicitly given where it differs from the lot. Similarly one has to fix which informations about test strategy, test methods, test institutions etc. should written down at which object type. We recommend to insert general statements about test strategies and methods once and for all at the highest level possible. - Definition of allowed "style variants". It is, for example, extremely dangerous to allow unlimited use of "extended identifiers". Otherwise a great part of the significant formal information (e.g. controlflow in ACTIONS or data structures in DATA) could be incorporated in these "extended identifiers" and therefore could not be interpreted and analyzed by EPOS. On the other hand the use of "extended i dent ifi ers" is the on ly way to avoid the creation of a tremendous number of very small ACTIONS. Because the name of these alone is normally not sufficiently significant they need a full description.
130
T. Schuler, R. J. Frank and W. Kratschmer
This can be avoided by a proper use of "extended identifiers". We made a proposal to overcome thi s problem in another post of thi s paper. - The use of the object ACTION MODULE must be guided by the functional structure of the object. In simply structured and weak interconnected projects it might be sensible to avoid the use of ACTION MODULE completely. - It is necessary to define (of course extendable) thesaurus and - using the new feature of twostep categories - a structure of the CATEGORIES which should be used. Otherwise they will be of rather limited benefit for selection purposes. - Concerning the relation of formal and actual parameters (alt-param-list) we strongly recommend to use instead the data transfer mechanism at the reference of the ACTION with the keyword USING. - One must avoid the "atomization" of the system design by a great number of very small rather trivial object descriptions. To achieve this aim we have first to limit the pseudo code decomposition to a certain depth. Below of this level one should use the CODE-part or else describe further details in the PURPOSEpart. Secondly one can employ a short-hand notation for certain constructs where the meaning is hidden in the (possibly extended) identifier and not directly written down in EPOS syntax. - One has to define pragmatic rules for the use of the INTERFACE-object and the dataflow-part for the description of software interfaces (either procedure-calls or process/taskcommunication). The INTERFACE-object as it is defined in EPOS is directed towards the description of hardware interfaces. It is not possible to refer in the INTERFACE-description directly to DATA or ACTIONS and to the flow of data between ACTIONS. For pure software interfaces we recorr.mend to write down the usual descriptive informations in the description part and to define rules for formatting these informations. - One has to decide at which level of the data descriptions dataflow-parts should be used. It is absolutely necessary to have a uniform manner among the project team. Otherwise dataflow diagrams would show to be very non-uniform. We recommend to use the dataflow-part mainly at the higher levels of the data structures and in particular not to leave gaps. The last statement means that one should not use dataflow-parts only at the high and low data levels and not between. Another point of view would be to restrict dataflowdescriptions to such data which correspond to hardware and/or software interfaces. - Concerning the practical use of EPOS in dayly software life, rules and guidelines for the following activittes are necessary: - How to produce uniform EPOS documents (prints and plots)? To achieve this aim easier and more reliably it is necessary to give every software engineer utilities (macros, command procedures) at hand. There must be defined procedure to distribute the knowledge about them in the project team. - Similarly it is absolutely necessary to have methods and command procedures for comfortable utilization of EPOS in the system environment of a specific project. Very important is, for example, to produce fast and easy unified EPOS source files or data bases from separate ones . - As far as EPOS-R is concerned the following hint is valuable. Especially EPOS-R is sometimes used simply as a text system, a task to which it is not well suited. Therefore it is of high importance to educate the software
engineers to use the formal description methods in EPOS-R (formal requirement inserts, decisions tables etc.) as far as possible. CONCLUSION The use of EPOS in the system design phases will not result automatically in cost reduction compared with projects performed USing conventional design methods. The computer supported documentation generated and updated concurrently to the design phases leads to additional work in the early project phases. No active test support is provided by the present EPOS tool. But the quality of the software developed using the tool EPOS is improved considerabl y . The software design is buildt up consistently and logically and transparence is increased using formal inserts in the requirement specifications and the corresponding fulfillment s and checks in the design specifications . The system test and integration is accelerated and relieved by the complete and actual documentation which is available in this project phase. The maintainability of systems developed with EPOS will be better, system bugs found during operation can be solved faster and modifications can be implemented and documented without complicati ons. Caused by its diversity and clear pI anned concept the EPOS tool sugge sts to constructive critique, extension and improvement propositions. This is supported by an intensive cooperation of the EPOS users on one side and the EPOS developer and the EPOS di stributor on the other side. Significant extension s and improvements in EPOS were initiated by active EPOS user s in the past and other s will follow. This demonstrates that EPOS is a living tool of high quality who's shortcomings will be eliminated in future. The use of a syst em development tool such as EPOS will not eliminate the design engineer s job. The daily work of the de sign engineer is supported and relieved by the development tool, which is the slave of the engineer, to leave more time for creative engineering. The tool will never be the master who relieves the engineer of thinking . The experienced design and development engineer, creative and familiar with the use of his slaves will be a demanded expert today as well as in future. REFERENCES Lauber, R. July 1984 EPOS Primer - A short introduction to the EPOS system Institute for Control Engineering and Process Automation University of Stuttgart