Bridging the gap between structured analysis and structured design for real-time systems - includes related article on principles of structured analysis and design - Technical

Hewlett-Packard Journal, August, 1993 by Joseph M. Luszcz, Daniel G. Maier

A real-time software design technique has been applied to the design of the software architecture for ultrasound imaging products.

Structured analysis (SA) and structured design (SD) are two widely used methodologies for software development.(1,2) Structured analysis specifies the functionality to be implemented by a software system, and structured design is used for partitioning a single task into a set of functional modules. See "Structured Analysis and Structured Design Refresher" on page 92 for a brief review of the structured analysis and structured design notation and terminology used in this paper.

When designing and implementing a software system represented by a structured analysis model, it is usually necessary to partition the functionality among a number of concurrent tasks to meet the timing constraints placed on the software system. In addition, to achieve a design with the characteristics of low coupling and high cohesion, it is desirable to partition the functionality into objects or packages for data hiding.

Although structured techniques provide designers with a methodology for partitioning a complex system into manageable pieces for analysis and design, there are some problems in making the transformation from SA to SD for real-time systems design. For example, the transformation from SA to SD does not easily support concurrency. Processes need to be grouped into concurrent tasks before detailed design. Another example is related to object-oriented design. SA and SD do not strongly support producing well-encapsulated objects.

Because of these problems a software developer, after specifying a real-time system using SA techniques, is often not sure how to proceed to a design and typically resorts to ad hoc design techniques. A methodology is needed to help the designer bridge the gap between SA and SD.

The ADARTS Solution

ADARTS (Ada-based Design Approach to Real-Time Systems)(*) is a high-level design methodology that effectively fills the gap between SA and SD by providing a systematic means (called process steps) for partitioning an SA specification model into a set of tasks, packages (objects), and communication links, which can then be designed using SD.

The deliverables from ADARTS include a set of high-level architectural diagrams and a set of specifications called component interface specifications for each task and package. These deliverables are described later in this article. Fig. 1 shows a simple overview of how ADARTS fits into the software development process with SA and SD. The notation and graphic symbols for the ADARTS diagram shown in Fig. 1 are described in more detail later in this paper.

We have been using ADARTS for embedded software development at Imaging Systems Division (ISY) since early 1990. ADARTS helped us deal with the complexity inherent in the design of the ISY shared software architecture, and we found it indispensable in turning SA models into realizable designs.

While the ADARTS technique supports the synchronizing constructs inherent to the Ada programming language, it is not necessary to program hi Ada to derive the majority of the benefits from ADARTS. We easily adapted the methodology and its diagramming terminology to a more conventional operating environment consisting of high-level language programs running under the control of a real-time operating system. At ISY, we develop software in the C language running under the pSOS-68K operating system. However, our approach to using ADARTS works with any language.

The diagramming notation used in ADARTS is based on the Buhr notation,(4) which is used to represent the tasks, packages, and communication paths resulting from the design decisions made in ADARTS (see Fig. 2). This diagramming notation is supported in commercially available CASE tools.

The rest of this paper gives a brief overview of the ADARTS methodology (defining the notation shown in Fig. 2 along the way) and then presents an example of our experience with using ADARTS for software architecture design.

ADARTS Process Steps

The ADARTS process involves following the steps listed below to create the ADARTS deliverables mentioned above and then using the deliverables to design and implement the system.

1. Develop a real-time structured analysis specification, and level the data flow diagrams to create a single (flat) diagram from the hierarchical set of data flow diagrams in the original model.

* Although ADARTS uses Ada constructs, its use is not limited to Ada. ADARTS was created by a group of companies called the Software Productivity Consortium iSPC). Two versions of the

ADARYS specification have been produced by the consortium. This paper is based on the first

version.3

2. Identify concurrent tasks by applying task structuring criteria, and determine the kind of communication and synchronization mechanisms for the data and events passed between tasks. Task structuring involves combining those processes that should be combined or keeping separate those processes that must be separate.