Selection of Architectural Patterns for Parallel Programming

The selection of an architectural pattern for parallel programming is guided mainly by the properties used for classifying them. However, it is important to notice that a particular architectural pattern, or its combination with others, is not a complete parallel software application. Its objective is just to provide a stable structure for a software system, as a first step on the design and implementation of parallel software.

Based on the classification schema and the pattern descriptions [POSA96, GHJV95], a procedure for selecting architectural pattern for parallel programming can be specified as follows:

1. Analyse the design problem and obtain its specification. Analyse and specify, as precisely as possible, the problem in terms of its characteristics of order of data and computations, the nature of its processing components, and performance requirements. It is important to also consider the context conditions about the chosen parallel platform and language (see section 5) that may influence the design. This stage is crucial to set up most of the basic forces to deal with during the design.

2. Select the category of parallelism. In accordance with the problem specification, select the category of parallelism - functional, domain or activity parallelism - that better describes it.

3. Select the category of nature of processing components. Select the nature of the process distribution -homogeneous or heterogeneous - among components that better describes the problem specification. The nature of process distribution indirectly reflects characteristics about the number of processing components and the amount and kind of communications between them in the solution.

4. Compare the problem specification with the Problem section. The categories of parallelism and nature of processing components can be simply used to guide the selection of an architectural pattern. In order to verify that the selected pattern copes with the problem at hand, compare the problem specification with the Problem section of the selected pattern. More specific information and knowledge about the problem to be solved is required. Unless troubles were encountered up to here, the architectural pattern selection can be considered as completed. The design of the parallel software system continues using the selected architectural pattern Solution section as a starting point. On the contrary, if the architectural pattern selected does not satisfactorily match aspects of the problem specification, it is possible to try to select an alternative pattern, as follows.

5. Select an alternative architectural pattern. If the selected pattern does not match the problem specification at hand, try to select another pattern that alternatively may provide a better approach when it is modified, specialised or combined with others. Checking the Examples, Known Uses and Related Patterns sections of the other pattern description may be helpful for this. If an alternative pattern is selected, return to the previous step to verify it copes with the problem specification.

If the previous steps do not provide a result, even after trying some alternative patterns, stop searching. The architectural patterns here do not provide a pattern that can help to solve this particular problem. It is possible to look at other more general pattern languages or systems [GHJV95, PLoP94, POSA96] to see if they contain a pattern that can be used. Or the alternative is trying to solve the design problem without using patterns.


Contact Information

Jorge Luis Ortega Arjona.

E-mail jortega-arjona@acm.org