A Design and Specification Environment for Distributed Memory Multiprocessors* Thomas Bemmerl, Thomas Ludwig, Bernhard Ries Institut für Informatik der TU München Lehrstuhl für Rechnertechnik und Rechnerorganisation Arcisstr. 21, D-8000 München 2 Tel.: +49-89-2105-8247 or -2382 e-mail:
[email protected]
In order to facilitate the development of large and well-structured parallel applications, a multiprocessor programming environment must comprise tools which support the specification phase. The following paper gives an overview of the design and implementation of the SAMTOP environment, which has been implemented as a part of the TOPSYS programming environment for distributed memory multiprocessors. The specification method is based on SA/SD, a design method widely used for the development of conventional systems. It has been adapted to meet the requirements of the designer of parallel applications. Key features include a graphical editor for the design of process graphs and code generation facilities, which allow for a smooth transition from the specification to the implementation phase.
1. Introduction Complex and computation-intensive problems, such as real-time image processing, fluid dynamics and VLSI-layout require computers with computational powers far beyond that of modern single-processor systems. A lot of research has therefore been directed towards the development of multiprocessor-systems. By now some of these systems are readily available on the market. The development of faster hardware does however not automatically imply the solution to the problems mentioned above, since it is significantly harder to develop efficient programs for multiprocessors, than for conventional single-processor machines. The overwhelming majority of development environments for multiprocessors are still very rudimentary. In most cases, the programmer has to keep in mind the details of the architecture and operating system. This makes it extremely difficult to develop portable and efficient programs. Up to now, there is a special lack of specification-environments, which allow the user to design a parallel application at a high level of abstraction, and arrive at the implementation through a number of well-defined and structured steps. The goal of the project TOPSYS (TOols for Parallel SYStems) [Bemm90a] at the Technical University of Munich, is to develop a portable environment which integrates tools that help programmers cope with every step of the software development-cycle for parallel applications. It is therefore necessary to implement tools which support specification and design, coding *
Partly funded by the German Science Foundation under contract number SFB 0342, project A1
1
and debugging as well as optimizing multiprocessor programs. Consequently, the TOPSYSenvironment comprises: – a CASE-environment for the design and specification of applications, – a multiprocessor operating system, – a high-level debugger, – a visualizer and – a performance-analyzer. The tools are based on the MMK operating system [Bemm90b], which has been implemented for Intel’s iPSC/2 hypercube. MMK programs consist of a set of tasks which communicate via mailboxes and use semaphores for the purpose of synchronization. These objects form a global object space in which any task can easily access every other object, without having to know on which node the object resides. This paper gives an overview of the rationale and design choices for the specification and mapping tool SAMTOP (Specification and Mapping Tool for Parallel Systems).
2. Criteria for a Design Method for Multiprocessor-Software When developing an environment for the design and specification of software, the first important step is to postulate requirements which should be met by the tools and to find criteria which can be used to evaluate different approaches. The next paragraph concentrates on the formulation of such a set of requirements. To a certain extent these requirements are similar to those used to evaluate conventional design methods while others are specific to the field of multiprocessor software-design. Ease of use The most important consideration is, that a design method should be easy to learn, understand and use. In most cases, specification systems are used for the design of large applications, therefore a lot of time is spent working with the specification system. If the design tools are too difficult to use or the resulting specifications are too difficult to understand, the designenvironment will most likely not be accepted by the user community. A lot of research has been invested into the development of specification-methods which are based on complex mathematical formalisms, such as temporal logic [Lamp83], CSP [Chen89] or petri-nets [Krau88, Miel88]. These methods have the advantage, that the mathematical formalism can be used to prove the correctness of a specification, and in some cases even to derive implementation parts from the specification. At the actual state of research however, most of these methods can not be used for the design of large applications, because the formalisms are just too difficult to manage. It is our belief, that a design method which is to be widely accepted has to reduce mathe-
2
matical formalisms to a minimum in order to be easy to understand and use. A certain degree of formality is however necessary in order to make consistency checks possible. These requirements point to the use of a graphical design method, since standardized graphics provide a certain degree of rigidity in a specification, without making mathematical formalisms necessary. Computer-support Modern workstations make a considerable amount of computational power readily available to almost every programmer. It is therefore straightforward to use software-tools for the design and specification of parallel programs. In order to facilitate the communication between project members, it is very important to have a powerful database as the central part of the design-environment. This makes it possible to efficiently inspect and modify parts of the specification. Since large software projects normally require a considerable number of project members, a design-environment should run in a network environment and integrate mechanisms for version-control. Consistency Checks One advantage of a computer-based specification method, is that it facilitates automatic consistency checks. The extent to which such checks are possible, depends on the amount of formalism inherent in the specification. In the field of parallel processing, there are a number of important questions which have to be considered when designing an application, e.g. proving that a system is deadlock-free or checking the soundness of the flow of data through the system. A specification system should incorporate as many consistency-checks as possible. Code-Generation Computer-based design-environments make it possible, to automatically generate parts of the implementation directly from the specification. These code-generators also help to ensure the portability of the application programs. The design and specification can take place at a high level of abstraction, without taking into account implementation details, such as the target-architecture or the operating system used. The use of different code-generators for different target-systems greatly simplifies the task of porting a parallel application to a new environment. Compatibility with the Tool-Environment An environment for the development of multiprocessor-software should comprise tools which support all the phases of the software development cycle, such as debuggers, visualizers and performance analyzers. User-friendly design- and specification-tools should be compatible with the rest of the tool-environment, in order to facilitate the transition from the specification to the implementation. Once again, this is a strong argument for the use of a graphics-based specification method, since graphics provide a good basis for all of the tools mentioned above.
3
For example, a parallel program can be modeled by a process graph, in which nodes represent the tasks, and edges represent communication links between tasks. Such a representation is also well-suited for the visualization of the dynamic program behavior, and can be used as a user-interface for a debugger or performance-analyzer. General Availability A design method for parallel applications, on concepts which have been widely tested in practice and found to be useful is certain to be more easily accepted by the users, than a method based on a completely new approach. At the moment however, there is no design methodology for multiprocessor software, which is widely used. In the field of specification and design of conventional software the situation is somewhat different. A number of so called CASE-methods such as Structured Analysis/Structured Design (SA/SD) [DeMa79,Your78], SADT [Ross77] or JSP [Jack75] are being used more and more for the design and specification of large software systems. It is therefore straightforward to use one of these methodologies as a basis for a new design method for parallel applications. There are however a number of points in which the design process for multiprocessor applications differs considerably from the steps used for the design and specification of conventional software systems. Thus, the new method must contain a certain amount of changes and innovations. Design considerations for parallel applications A specification method for parallel applications should enable the user to model systems without taking into account the specific details of the architecture and the operating system used. However, if the specification is to be transformed into the implementation of a system by a series of well-defined steps, these details can not be totally omitted - as the design gets closer to the implementation, the properties of the target environment have to be considered. It is not plausible to search for a methodology which is suited for the design of applications for both tightly coupled and loosely coupled multiprocessors, since the programming models and architectural concepts used in these two classes of machines are very different. In most programming models for loosely coupled multiprocessors, a parallel program consists of a set of active components (tasks, processes etc.) which exchange data through message passing. Design methods which emphasize the flow of data through the components of a software system are particularly well-suited for the design of applications for this class of machines. The most common CASE-methods are based on the principle of dataflow through active components. It is therefore plausible to use one of these methods as a starting point for a design method for applications which are to run on message-based multiprocessors. Conclusions As we have seen, a computer based design method for parallel applications should not be overly formal but specifications should contain enough information to allow consistency
4
checks and code generation. It is possible to meet these requirements with graphical methods. In addition to relying strongly on graphics, CASE methods such as SA/SD have the advantage, that they have already been widely employed for the design of large conventional software systems. Thus a CASE method centered around a powerful database offers a good platform for the design of multiprocessor applications. For the design of SAMTOP, we therefore chose a set of CASE-tools and tried to enhance them by adding concepts which address issues specific to multiprocessor applications.
3. Overview of Existing Approaches A number of researchers have tried to tackle the problem of structured specification and design of multiprocessor applications. The following paragraph gives an overview of the most successful design environments for message-based multiprocessors. One of the first programming-environments for non-shared memory applications was the Poker system developed at the University of Washington [Gate87, Notk88]. A Poker program is represented by a process graph, with vertices representing processes and edges representing communication paths between processes. A very similar approach is taken in the Muppet system [Mueh88a], which is part of the german Suprenum project. The concepts used in the CODE system [Sobe88], which is being developed at the University of Texas, are of a more formal nature. Here, a parallel program is viewed as a set of units of computation, and a number of dependency relations which specify the order of execution of the units of computation. All three systems make extensive use of graphics - graphical editors are used to construct a process graph. Some systems try to make automatic transitions from the specification to the implementation possible. For example, a CODE-specification can be translated into an Ada program frame, that calls the computation units as Ada subprograms while taking into account the specified dependency relations. The representation of parallel programs as process graphs is very appealing, since such graphs are a good basis for the visualization of the topology and communication scheme of the parallel algorithm. A graphical editor which is to be used for the structured design of applications should however enable the designer to partition the process graph into logical subgraphs or subsystems. This feature is of special importance for the design of large applications. As we shall see in the following paragraph, the graphical design of parallel applications can get very cumbersome in some cases. It is therefore helpful, if the design environment offers the possibility of describing parts of the specification in a textual form. Examples for such an approach can be found in Polylith [Purt87], Pisces [Prat87] and the Design project [Mueh88b]. In our view, a design environment for parallel applications should combine both approaches. A graphical editor should be used to construct a well-structured program graph, but at the same time the user should be able to resort to a textual representation, whenever a
5
graphical representation is not adequate. In addition, the design environment should support a structured and - as far as possible - automated transition from the specification to the implementation through a series of code-generation steps.
4. Design of Multiprocessor-Applications using SA/SD The previous paragraphs have shown, that conventional CASE-tools offer a good platform for the specification and design of multiprocessor applications. However, the methods used for the design of conventional software systems have to be adapted in a number of ways, in order to meet the requirements of the designer of parallel systems. The following paragraph analyzes the strengths and weaknesses of the CASE-method Structured Analysis/Structured Design, which was chosen as a starting point in the design of SAMTOP. SA/SD and Extensions The SA/SD-method developed by Yourdon and DeMarco is one of the most successful methodologies for the design of conventional software systems. According to this approach, a software system is modeled as a set of active components, which transform input data into output data. This dataflow-oriented approach is particularly well-suited for the design of applications for message-based multiprocessors. Since the tasks of a multiprocessor program usually need to synchronize from time to time, it is necessary to add constructs which can be used to reflect synchronization statements, as for example operations on semaphores. This can be done by using Ward’s extensions to the conventional SA/SD method [Ward85], which make it possible to model the flow of control in a system. A parallel program can thus be represented by a dataflow graph, in which vertices represent the tasks or processes of the system, dataflow symbols represent communication links, and control-flow symbols are used to model synchronization operations. In the SA/SD-approach, the dataflow graph can be designed in a well-structured way, since it is possible to partition it into subsystems which reflect the modular structure of an application. The design is usually done by stepwise refinement of system components using a top-down approach. Design of task-partitioned applications The representation of a parallel computation structure by a dataflow graph is particularly useful for the design of applications, whose parallelism is based on the principle of task-partitioning. In this approach, a problem is solved by dividing into a set of distinct sub-problems. Each problem is then solved by a different type of task. This type of application can obviously be easily modeled by a dataflow graph, which shows the different tasks and their communication and synchronization links. Design of data-partitioned applications For many important problems the principle of task partitioning is not sufficient, since in
6
many cases it is more natural to partition the data set rather than partition the flow of control of the program [Hill86]. This means that a certain type of task appears in more than one instantiation - many data-parallel algorithms consist of only one task type with every available processor node running a copy of the task which works on a part of the data set. The principle of data-partitioning is of special importance for massively parallel systems, since it is not feasible to program a machine which consists of thousands of processors by creating an equal number of different task types. In many cases both task-partitioning and data-partitioning are used in the design of parallel algorithms. The design of data-parallel algorithms using dataflow-graphs is somewhat awkward. The reason for this is, that the fact that a task is replicated, that is, occurs more than once, cannot be easily expressed. It is of course possible, to express replication by simply copying parts of the dataflow graph. This is however not satisfactory, because typical data-parallel algorithms have a characteristic interconnection structure, such as for example a ring- or torus-configuration. The size of the configuration is variable, typically it is a function of the number of available processor-nodes. It follows, that the conventional design principle used for SA/SD is not suitable for the design of data-partitioned applications. A design method for multiprocessor software has to contain mechanisms which can be used to express replications of parts of the dataflow graph and to model interconnection structures between replicated components. Specification of dynamic program behavior One of the drawbacks of using SA/SD as a design method for multiprocessor applications, is that this method makes it difficult to model a system’s dynamic behavior. Even though State-Transition Diagrams can be used to specify the dynamic aspects of tasks, the structure of the dataflow graph remains static, since there is no way to model the dynamic creation or destruction of objects. The dataflow graph can therefore only reflect the initial structure or a stable end-configuration of a parallel application. Consistency checks Conventional CASE-Tools centered around the principles of SA/SD typically allow a number of consistency checks, such as checking the soundness of the flow of data through the dataflow graph. Even though these tests are useful in the design of multiprocessor applications, there are often other requirements which must be met by a multiprocessor application. As an example, it would be very useful if it were possible to check, whether the modeled system is free from deadlocks. As a prerequisite for this kind of tests, methods that allow a detailed specification of dynamic program behavior are necessary. Changes and Extensions The previous paragraphs have shown, that the conventional SA/SD method needs some
7
changes and extensions, if it is to be used for the design of multiprocessor software. The strength of the SA/SD design principle is, that it is possible to design a system in a structured way through stepwise refinement. However, extensions are necessary, to support the design of data-partitioned applications and consistency checks for typical requirements multiprocessor applications must meet. Many CASE-environments offer code generators, which can be used to derive parts of the implementation from the specification. At this point, a design method for multiprocessor applications should offer support for problems typically found in multiprocessor programming, such as the mapping of computational structures to processor nodes.
5. The Samtop CASE-Environment The Samtop CASE-Environment is based on the CARDtools (Computer Aided Real Time Design Tools) [Read89], developed and distributed by Ready Systems. The CARDtools offer software design facilities according to Ward’s extensions to SA/SD for the design of real-time systems. This CASE-environment includes the following features: – structured top-down design of applications using structure charts and dataflow diagrams, – specification of data types, – specification of algorithms using pseudocode, – detailed design of process graphs containing operating system primitives. In the design of SAMTOP, we tried to adapt and extend the functionality offered by the CARDtools, in order to meet the requirements of the designer of multiprocessor software. The following paragraph describes the structure and functionality of the resulting CASE-environment for multiprocessor applications. Structured Design of Data-Flow Graphs In the SA/SD approach, a software system is designed using a top-down approach. This is done using so-called structure charts, which show the modular structure of a system, i.e. its decomposition into different subsystems. In our approach, structure charts can be designed using the CARDtools Control Maps Builder. A structure chart can however also be seen as a dataflow diagram, which emphasizes the flow of data through the system rather than the system’s hierarchical structure. Dataflow diagrams can be derived from structure charts or designed from scratch using a graphical editor, the so called Data-Flow Diagram Builder. In a final design step, operating system primitives can be used to specify, how the functionality of a design is to be implemented. For example, active components can be replaced by symbols representing tasks or interrupt-severs, dataflows can be replaced by mailbox-icons and semaphores can be used as a substitute for control-flow symbols. Thus, the design yields a detailed process-graph, which shows the operating system components and their interconnection. Such a process graph is shown in Fig. 1. The structure of the data items exchanged by
8
Figure 1: Detailed example process graph.
9
tasks can be specified using a data-definition facility. It is also possible to use a pseudocodelanguage to specify the exact algorithms used. Specification of Replication and Interconnection Structures As we have seen in the previous paragraph, the graphical design of dataflow diagrams and process graphs is not very helpful for the design of data-partitioned applications. The conventional method has to be enhanced, in order to offer a way of expressing the replication of parts of the process graph and the interconnection structure between replicated parts. One possible approach is the use of graph-grammars as described by Bailey and Cuny [Bail87]. But this is once again a very formal concept which requires special skills on part of the designer. In the design of SAMTOP we therefore developed a simple programming language, which offers a natural way to express the structures mentioned above. This language contains conventional C-statements and three special operations: replicate, connect and map. The replicate-operation can be used to create multiple instantiations of parts of the process graph. In the initial design of the process graph, parts that are to be replicated are not connected with the rest of the graph, since they are only templates for the different instantiations. The interconnection structure is created using the connect-operation. Finally, the map-operation can be used to specify the mapping of system objects to processor nodes. Parameters can be used freely in all operations. This makes it easy to express, that the exact structure of an application is a function of certain system parameters, e.g. the number of available processor nodes. Consequently, a complete system model in the SAMTOP-environment consists of a graphically designed specification of the different program objects and a usually small file which describes the replication and interconnection structure using the language described above. Example The statements shown in Fig. 2 can be used to model the structure of a producer-consumer system, in which n producers communicate with m consumers via a single mailbox. Transition from Specification to Implementation In order to facilitate the transition from the specification to the implementation, the SAMTOP-environment incorporates code-generators, document-generators and a mapping-facility. Code Generation At the moment, the code-generation facilities offered are rudimentary, it is only possible to derive templates for the task types of a system model. These templates contain task declarations and are used to supply the tasks with parameters. These parameters typically include the identifiers of communication objects, e.g. the mailboxes and semaphores with which a task is connected.
10
#define N 10 #define M 20 REPSTART int i,j; /* ** producer and consumer are objects, whose exact structure was ** previously defined in the design of the dataflow graph; ** replication yields N consumers and M producers indexed as a vector */ replicate(producer,VECTOR[N]); replicate(consumer,VECTOR[M]); /* ** Interconnection structure: The output-mailbox of every producer ** is connected with the input mailbox of every consumer */ for (i=0; i; i++) for (j=0; j; j++) connect(producer[i].out,consumer[j].in); REPEND
Figure 2: Replication and interconnection in a producer-consumer system.
Document Generation A number of documents can be generated directly from the specification. These include a data types dictionary, data- and procedure cross-reference listings, invocation tree and pseudocode analyzer reports. In addition, it is possible to create print-ready versions of structurecharts, dataflow-diagrams and process graphs. Fig. 3 shows a configuration file generated from a specification. Mapping Support The mapping of program objects to processor nodes is a crucial step in the design of multiprocessor applications, since a good mapping is essential in order to balance system load and avoid communication bottlenecks. In many cases, this mapping can be thought of as part of the specification. As an example, consider a ring-structured application which is to be mapped onto a hypercube multiprocessor. In a good mapping, neighboring objects in the ring should be mapped onto processor nodes which share a communication link. Such a mapping can be achieved by using a gray-code. However, it is very often not sufficient to consider only the topology of the computational structure and the target architecture when determining a mapping function. Other important factors are the computation load and amount of communication generated by program objects as well as the degree to which different objects interfere with each other through synchronization operations. In most cases, these factors can only be determined by executing the program and analyzing its performance.
11
GLOBAL_BEGIN IO( 10000 NODE 0) MBOX( bottom INIT 0 NODE 7 ) MBOX( down_0 INIT 0 NODE 0 ) MBOX( down_1 INIT 0 NODE 1 ) MBOX( down_2 INIT 0 NODE 2 ) MBOX( down_3 INIT 0 NODE 3 ) MBOX( down_4 INIT 0 NODE 4 ) MBOX( down_5 INIT 0 NODE 5 ) MBOX( down_6 INIT 0 NODE 6 ) MBOX( top INIT 0 NODE 0 ) TASK( BOTTOM INIT bottom_code,32000, 150 ,bottom NODE 7 ) TASK( TOP INIT top_code,32000, 150 ,top ,input NODE 0 ) TASK( DOIT_0 INIT do_it_code,32000, 100 ,top ,down_0 ,output NODE 0 ) TASK( DOIT_1 INIT do_it_code,32000, 100 ,down_0 ,down_1 ,output NODE 1 TASK( DOIT_2 INIT do_it_code,32000, 100 ,down_1 ,down_2 ,output NODE 2 TASK( DOIT_3 INIT do_it_code,32000, 100 ,down_2 ,down_3 ,output NODE 3 TASK( DOIT_4 INIT do_it_code,32000, 100 ,down_3 ,down_4 ,output NODE 4 TASK( DOIT_5 INIT do_it_code,32000, 100 ,down_4 ,down_5 ,output NODE 5 TASK( DOIT_6 INIT do_it_code,32000, 100 ,down_5 ,down_6 ,output NODE 6 TASK( DOIT_7 INIT do_it_code,32000, 100 ,down_6 ,bottom ,output NODE 7 GLOBAL_END
) ) ) ) ) ) )
Figure 3: Generated configuration file.
The SAMTOP-environment attempts to support all these aspects of the mapping problem. The specification can be used to generate a configuration file, which describes the program objects and their mapping to processor nodes. Fixed topological mappings can be generated using the map-operation described above. On the other hand, it is also possible to generate random-mappings and to change the mapping of program objects manually. We are currently exploring the possibility of using the TOPSYS performance-analyzer to measure the performance of applications after such an initial mapping and to use the measurement data to compute an improved mapping function. The idea behind this approach is to use performance data, such as the CPU-time used by a task and the amounts of data transferred between tasks and mailboxes as input for heuristic algorithms which try to balance CPU- and communication loads by calculating an appropriate mapping of objects to processor nodes.
6. The TOPSYS Development Cycle After having described the SAMTOP design method in detail, let us now take a look at the steps and phases involved in developing a parallel application when using the TOPSYS environment. In our model the development cycle for multiprocessor applications consists of a series of well defined steps, which are illustrated in Fig. 4. The tool environment offers sup-
12
Requirements Specification
High Level Design
SAMTOP
Detailed Design
Coding & Debugging
DETOP PATOP VISTOP
Testing & Optimization
Figure 4: Development cycle in the TOPSYS environment.
port for each of the phases. The first step consists of modelling the hardware and software environment of an application and creating a high-level specification of the intended functionality. The high-level design is then transformed into a detailed design through a series of stepwise refinement steps using the SAMTOP CASE-environment. The facilities for code- and document generation ease the transition to the coding and debugging phase. The other tools (debugger, visualizer and performance-analyzer) offer support for debugging and optimizing existing applications.
7. Conclusions and Further Work The SAMTOP CASE-environment offers a new approach to the problem of design and specification of multiprocessor software, in that a standardized and widely used CASE methodology is used as a basis. This method has been adapted and enhanced in order to meet
13
the requirements of the designer of multiprocessor software. By integrating the design method into our tool-environment we have created a programming environment which offers support for all the steps involved in developing a multiprocessor application. However, the first version of the SAMTOP-environment is only a prototype. The main problem is the lack of a powerful project-database and of version control mechanisms. This makes it very difficult, to adapt the design method to our needs in a well-structured way. Current projects include the development of an automatic remapping facility based on performance data acquired by the TOPSYS performance-analyzer.
8. References [Bail87]
D.A. Bailey, J.E. Cuny: Graph Grammar Based Specification of Interconnection Structures for Massively Parallel Computation, in Graph Grammars and Their Applications to Computer Science, Lecture Notes in Computer Science 291, Springer Verlag 1987. [Bemm90a] T. Bemmerl: The TOPSYS Architecture, Proceedings of the CONPAR90-VAPP IV Conference in Zurich, Switzerland, September 1990, Lecture Notes in Computer Science, Nr. 457, H. Burkhart (ed.), Springer, Berlin, p. 732-743. [Bemm90b] T. Bemmerl, T. Ludwig: MMK - A Distributed Operating System Kernel with Integrated Dynamic Loadbalancing, Proceedings of the CONPAR90-VAPP IV Conference in Zurich, Switzerland, September 1990, Lecture Notes in Computer Science, Nr. 457, H. Burkhart (ed.), Springer, Berlin, p. 744-755. [Chen89] K. Chen, S. Yan: An Approach to Verification of Communication in Distributed Computing Systems, Proceedings of the 9th International Conference on Distributed Computing Systems, June 89, p. 603-610. [DeMa79] T. DeMarco: Structured Analysis and Systems Specification, Yourdon Press, 1979. [Eise89] S. Eisenbach, L. McLoughlin, C. Sadler: Data Flow Design as a Visual Programming Language, ACM Sigsoft Fifth International Workshop on Software Specification and Design, May 1989, p. 281-283. [Gate87] K. Gates, D. Socha: Programming NCUBES with a Graphical Parallel Programming Environment versus an Extended Sequential Language, Proceedings of the Second Conference on Hypercube Multiprocessors, 1987, p. 17-27. [Hill86] W.D. Hillis, G.L. Steele: Data Parallel Algorithms, Communications of the ACM, December 1986, p. 1170-1183. [Jack75] M.A. Jackson: Principles of Program Design, Academic Press, London New York San Francisco, 1975. [Krau88] K. Krauss, S. Golden: A petri-net method for the formal verification of parallel processes, Proceedings of the IEEE International Conference on Parallel Processing, 1988, p. 157-160. [Lamp83] L. Lamport: Specifying concurrent program modules, ACM Transactions on Programming Languages and Systems, 5, 1983, p. 190-122. [Miel88] R. Mielke, S. Stoughton, S. Som: Modeling and performance bounds for concurrent processing, Proceedings of the 8th International Conference on Distributed Computing Systems, June 88, p. 538544. [Mueh88a] H. Muehlenbein, O. Kraemer, F. Limburger, M. Mevenkamp, S. Streitz: MUPPET - A Programming Environment for Message-Based Multiprocessors, Parallel Computing 8, 1988, p. 201-221. [Mueh88b] M. Muehlhaeuser: Software Engineering for Distributed Applications - The Design Project, Proceedings of the 10th International Conference on Software Engineering, April 1988, p. 93-101. [Ni87] L.M. Ni, C. King, P. Prins: Parallel Algorithm Design Considerations for Hypercube Multiprocessors, Proceedings of the IEEE International Conference on Parallel Processing, 1986, p. 717-720. [Notk88] D. Notkin, L.Snyder, D. Socha et al.: Experiences with Poker, Proceedings of the ACM/SIGPLAN PPEALS, 1988, p. 10-20. [Prat87] T. Pratt: The Pisces-2 Parallel Programming Environment, Proceedings of the IEEE International Conference on Parallel Processing, 1987, p. 439-445. [Purt87] J. Purtilo, D.A. Reed, D.C. Grunwald: Environments for Prototyping Parallel Algorithms, Proceedings of the IEEE International Conference on Parallel Processing, 1986, p. 431-438.
14
[Read89] [Ross77] [Sobe88]
[Your78] [Ward85]
Ready Systems Corp.: CARDtools for Sun 3.3 User’s Guide, Sunnyvale, 1989. D.T. Ross, K.E. Schomann: Structured Analysis for Requirements Definition, IEEE Transactions on Software Engineering 3, no.1, 1977, p. 6-15. S. Sobek, J.C. Browne, M. Azam: Architecture and Language Independent Parallel Programming A Feasability Demonstration, Proceedings of the IEEE International Conference on Parallel Processing, 1988, p. 80-83. E. Yourdon, L.L. Constantine: Structured Design, Prentice Hall, Englewood Cliffs, N.J. 1976. P. Ward, S. Mellor: Structured Development for Real Time Systems, vol. I-III, Yourdon Press 1985.
15
