Cameron and Tracey Hughes

Dr. Dobb's Bloggers

It's All In the Strategy, It's All About the Design

March 12, 2010

We have been blogging about designing applications for massive parallelism. In my last blog I introduced PADL, short for "Parallel Application Design Layers", a five-layer analysis model that we use at Ctest Labs during the requirements analysis, software design and decomposition activities of the SDLC. We use PADL to place concurrency and parallelism considerations in the proper context. We use PADL during the initial problem and solution decomposition.

We have been blogging about designing applications for massive parallelism. In my last blog I introduced PADL, short for "Parallel Application Design Layers", a five-layer analysis model that we use at Ctest Labs during the requirements analysis, software design and decomposition activities of the SDLC. We use PADL to place concurrency and parallelism considerations in the proper context. We use PADL during the initial problem and solution decomposition.

We also use the PADL model to circumvent much of the complexity that results from bottom-up approaches to parallel programming. This is an architectural approach to parallelism rather than a task-oriented procedural approach. Although concurrently executing tasks represent the basic unit of work in applications that take advantage of CMPs, we place those tasks within declarative architectures and predicate-based software models. Cameron and I approach application design with the fundamentals of the Software Development Life Cycle (SDLC) front and center along with the PBS (Predicate Breakdown Structure) used for decomposition. The PBS of a software design presents a view of the software as a collection of assertions, propositions and logical predicates. The PBS gives the declarative or predicate-based view of a software design. PADL and PBS are our fundamental tools for application design where multithreading, multiprocessing, or parallel programming will be used. PADL and PBS are departures from procedural and bottom up task-oriented methods.

PADL is used to help organize the software decomposition effort. It is a refinement model. Starting with the top layer each lower layer contains more detail and is one step closer to operating system and compiler primitives. PADL is meant to be used during the requirements analysis and software design activities of the SDLC. The industry standard description for a SDLC is contained in the IEEE Std 1074, Guide for Developing Software Life Cycle Processes. IEEE Std 1074 helps clarify what the minimum set of activities are. Table 1 shows some of the common activities found in the SDLC but it is not exhaustive. The PADL model is used to help design or decompose patterns of work before the software is written. That's why we place an emphasis on its use during design and analysis activities of the SDLC. Figure 1 shows the five layers of PADL.

Here are brief descriptions of each layer:

LAYER 5 deals with application architecture selection. Selection of the application architecture is one of the most critical decisions because everything else follows the architecture and once it is in place it is expensive to change. The architecture allows certain functionality and features while preventing others. The architecture provides the basic infrastructure of the application. The pattern of work is initially expressed within the context of the architecture chosen in this layer.

LAYER 4identifies concurrency models that will be used for the application. The architecture should be flexible enough to use the concurrency models (such as boss-worker, peer-to-peer, etc.) that are needed and the concurrency models should be flexible enough to support the architecture selected. The architecture is fleshed out by one or more concurrency models.

LAYER 3 starts to identify application frameworks, pattern class hierarchies, component/predicate libraries, and algorithm templates that will be used to implement the concurrency models identified at Layer 4 of the analysis. Layer 3 introduces tangible software into the PADL model. Software libraries such at the Thread Building Blocks (TBB) library or STAPL would be identified in Layer 3.

LAYER 2 represents the application's program interface to operating system. The components in Layer 3 will ultimately talk to and cooperate with the OS API. In our case the POSIX API is used for the greatest cross platform compatibility. Many of the components in Layer 3 are interface classes or wrappers for functionality found in Layer 2.

LAYER 1 is the lowest level of detail that our software application can be decomposed into. At Layer 1 we are dealing with kernel execution units, signals, device drivers, etc. The software at Layer 1 perform the actual work of the application interfaces presented in Layer 2. Layer 1 decomposition also considers compiler and linker switches.

Layers 4 and 5 are considered design layers. Layers 1-3 are the implementation layers. Layer 3 is usually reserved for application level software development. Layer 1 and 2 is usually reserved for system level software development. Obviously the barrier between Layer 2 and 3 can be (and often is) easily crossed. Once a PADL model analysis has been performed, the picture of the concurrency structure of an application is clear to all of those involved in the software development effort. The PADL analysis of an application provides the framework for the testing activities of the SDLC. The PADL analysis provides the necessary implementation and deployment targets of the SDLC for the application. At the top layers of the PADL are design concepts and models.

At the lowest level of the PADL are operating system primitives. So we have a complete picture of the concurrency of an application through the PADL model. The PADL model is meant to drive a declarative decomposition of the application because we proceed from architectures to operating system primitives not from the primitives to the architectures! But for PADL to insure a declarative decomposition it must restrict the architectures to software blueprints that have declarative, goal-oriented or predicate-based semantics.

The material in this blog including table and figure was based on material from our book "Professional Multicore Programming: Design and Implemetation for C++ Developers".

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task.
However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Video

This month's Dr. Dobb's Journal

This month,
Dr. Dobb's Journal is devoted to mobile programming. We introduce you to Apple's new Swift programming language, discuss the perils of being the third-most-popular mobile platform, revisit SQLite on Android
, and much more!