The purpose of this paper is to build the foundation for software architecture. We first develop an intuition for software architecture by appealing to several well-established architectural disciplines. On the basis of this intuition, we present a model of software architec-ture that consists of three components: elements, form, and rationale. Elements are either processing, data, or connecting elements. Form is defined in terms of the properties of, and the relationships among, the elements-- that is, the constraints on the elements. The ratio-nale provides the underlying basis for the architecture in terms of the system constraints, which most often derive from the system:requirements. We discuss the compo-nents of the model in the context of both architectures and architectural styles and present an extended exam-ple to illustrate some important architecture and style considerations. We conclude by presenting some of the benefits of our approach to software architecture, sum-marizing our contributions, and relating our approach to other current work.

Parallel and distributed programming languages often include explicit synchronization primitives, such as rendezvous and semaphores. Such programs are subject to synchronization anomalies; the program behaves incorrectly because it has a faulty synchronization structure. A deadlock is an anomaly in which some subset of the active tasks of the program mutually wait on each other to advance; thus, the program cannot complete execution. In static anomaly detection, the source code of a program is automatically analyzed to determine if the program can ever exhibit a specific anomaly. Static anomaly detection has the unique advantage that it can certify programs to be free of the tested anomaly; dynamic testing cannot generally do this. Though exact static detection of deadlocks is NP-hard [Tay83a], many researchers have tried to detect deadlock by ...

The conventional classification of software fault detection techniques as static or dynamic analysis is inadequate as a basis for identifying useful relationships between techniques. A more useful distinction is between techniques that sample the space of possible executions, and techniques that fold the space. The new distinction provides better insight into the ways different techniques can interact, and is a basis for considering hybrid fault detection techniques including combinations of testing and formal verification.

The inherent difficulties of analyzing concurrent software make reliance on a single technique or a single monolithic tool unsatisfactory. A better approach is to apply multiple analysis and verification techniques by coordinating the activities of a variety of small tool components. We describe how this approach has shaped the design of a set of tool components to support concurrency analysis in the Arcadia-1 software development environment. Implementation and experience with key components is described.

. Infinite wait anomalies associated with a barrier rendezvous model (e.g., Ada) can be divided into two classes: stalls and deadlocks. Although precise static deadlock detection is NP-hard, we present two polynomial time algorithms which operate on a statically derivable program representation, the sync graph, to certify a useful class of programs free of deadlocks. We identify three conditions local to any deadlocked tasks, and a fourth global condition on all tasks, which must occur in the sync graph of any program which can deadlock. Again, exact checking of the local conditions is NP-hard; the algorithms check them using conservative approximations. Certifying stall freedom is intractable for programs with conditional branching, including loops. We give program transforms which may help alleviate this difficulty. Keywords: synchronization anomalies, Ada, deadlocks, static analysis, parallel programming 1 Introduction. Infinite wait synchronization anomalies associated with a b...

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : x 1. INTRODUCTION : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 1 2. BACKGROUND : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 4 2.1 Dynamic Analysis of Concurrent Systems : : : : : : : : : : : : : : : : 5 2.2 Static Analysis. : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 5 2.2.1 Theorem Proving : : : : : : : : : : : : : : : : : : : : : : : : : 6 2.2.2 Reachability Analysis : : : : : : : : : : : : : : : : : : : : : : : 7 2.2.3 Model Checking : : : : : : : : : : : : : : : : : : : : : : : : : : 9 2.3 Process Algebra : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 11 3. COMPOSITIONAL ANALYSIS USING PROCESS ALGEBRA : : : : : : 18 3.1 Background : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 18 3.1.1 Reachability Analysis : : : : : : : : : : : : : : : : : : : : : : : 18 3.1.2 Process Algebra : : : : : : : : : : : : : : : : : : : : : : : : : : 19...

The significance of software systems has rapidly increased. The assurance of software systems has become a critical requirement of the information age. Formal verification on the design of a system and testing on a system implementation with a variety of inputs has been used for this purpose. However, verifying a design can not guarantee the correctness of an implementation. Although testing is performed on implementation, it does not give formal guarantees because it is not possible to test exhaustively. Run-time formal analysis is proposed to combat the weaknesses of formal verification and testing. Run-time formal analysis aims to assure the correctness of the current execution at run-time. Run-time formal analysis is performed based on a formal specification of system requirements. This dissertation proposes a framework for run-time formal analysis. We investigate general issues for the framework. We show that a set of the properties run-time formal analysis can detect is a subset...

The purpose of this paper is to build the foundation for software architecture. We first develop an intuition for software architecture by appealing to several well-established architectural disciplines. On the basis of this intuition, we present a model of software architecture that consists of three components: elements, form, and rationale. Elements are either processing, data, or connecting elements. Form is defined in terms of the properties of, and the relationships among, the elements --- that is, the constraints on the elements. The rationale provides the underlying basis for the architecture in terms of the system constraints, which most often derive from the system requirements. We discuss the components of the model in the context of both architectures and architectural styles and present an extended example to illustrate some important architecture and style considerations. We conclude by presenting some of the benefits of our approach to software architecture, summarizing ...

. We describe an approach to the specification of concurrent systems which enables a Petri net model of a system to be built up in a systematic way starting from a trace-based CSP specification. This method enables the separate specification of the behaviour of each component (process) and their interactions in terms of the feasible sequences of events in which they can be involved. A set of rules is then applied to transform the trace-based specifications into a complete Petri net that is analysed and/or executed to validate system behaviour. The domain transformation procedure is fully automatable. The specification of a safety-critical railway control system is used as a case study. Keywords: Concurrent software engineering, Formal Specification and Verification, CSP, Petri Nets, Safety analysis 1. Introduction In the last decade the development of concurrent software has become a common practice in the high-performance computing community, where it is considered a means of fully e...

The behavior of a concurrent program often depends on the arbitrary interleaving of computations performed by asynchronous processes. The resulting non-determinism can lead to such phenomena as deadlock and starvation, making program development extremely difficult, and consequently making the development of tools for formal analysis highly desirable. A specification-based approach to concurrency analysis is a particularly promising way of addressing some of the difficulties inherent in concurrent program development. According to this approach, a programmer first writes a specification describing the interprocess communication behavior of a concurrent program. A set of formal analysis techniques are then applied in an effort to determine whether the specification can be fully satisfied. If the analysis is successful, target code is generated automatically that conforms to the specification. This approach has a variety of benefits. While such properties as safety and liveness are rathe...