mining the high-level organization in software is evidenced by the interest in architectural styles or idioms, and in the design and object-oriented communities in design patterns. We advocate that software understanding at a higher abstraction level is enhanced if you know these basic software architecture building blocks. These building blocks are considered here as formal architectural design patterns based on a reuse model.

Design patterns can be defined as a means to achieve large-scale reuse by capturing successful software development design practice within a particular context [5, 6, 7]. Patterns should not be limited in what they can describe and can be used to encapsulate good design practices at both the specification and implementation levels. Thus, design patterns can be applied at many different levels of abstraction in the software development life-cycle, and can focus on reuse within architectural design as well as detailed design and implementation. In fact, a system of patterns for software development should include patterns covering various ranges of scale, beginning with patterns for defining the basic architectural structure of an application and ending with patterns describing how to implement a particular design mechanism in a concrete programming language. Design patterns that represent the basic architectural structure of a distributed software application are the ones we are considering here. These patterns reflect typical programming (or programming-in-the-large) paradigms for distributed software system application development.

Most published research [5, 7] in design patterns has been described in a structured but informal notation, and has focused on implementation-oriented patterns rather than architectural ones. For example, one publication [5] contains descriptions of patterns using text and diagrams, and has grouped patterns into three major categories. These descriptions can be viewed as an informal recipe or process for producing instantiations of specific patterns in languages such as Smalltalk or C++. Even when architectural issues are considered [6], the software architectural design is expressed only through informal patterns. An architectural pattern is based on selected types of components and connectors, together with a control structure that governs their execution.

We use a formal approach to design patterns [1] which encompasses patterns at different levels of granularity, ranging from architectural to implementation descriptions. There are two aspects to design patterns that are considered in this formal presentation: the process of producing specific instantiations of a design

pattern, and the use of formally defined components or objects to substitute in these instantiations.

If the process is defined through a process programming language with formal syntax and semantics, then any ambiguities in the process of design pattern instantiation should be eliminated. Reducing or even eliminating ambiguity should make it easier to derive code consistently and perhaps even lead to some automation of the code production for the particular instantiation of a design pattern [2]. Substituting formally defined components into an instantiation could permit a formal reasoning process about the resulting system. We currently have established two different frameworks for reasoning about designs[8, 9] of this type.

Recent investigations[9] have shown how both a formal model and a prototype can be derived from a single component-based specification, thus providing a strong link between formalism and implementation.

The formally defined components are based on the Abstract Data View (ADV) approach[10, 11, 12] which uses a formal model [8, 13] to achieve separation by dividing designs into two types of components: objects and object views, and by strictly following a set of design rules. Specific instantiations of views as represented by Abstract Data Views (ADVs) and objects called Abstract Data Objects (ADOs) are substituted into the design pattern realization while maintaining a clear separation between view and object. Currently the ADV and ADO components are specified using temporal logic and the interconnection between components is described in terms of category theory. Each design pattern has an associated process program that describes how to substitute these components to create a specific instantiation. In fact, this framework can be seen as a formal approach for a system of design patterns.

The basic idea behind the proposed formal approach to distributed software understanding is to reverse engineer applications to extract the various levels of architectural design patterns that have been used and/or to produce a similar but better design based on an architectural pattern structure. In this sense, this paper presents an architectural design pattern-based approach to reverse engineering applied to the domain of distributed applications. This exercise would not only assist us in understanding the application, but also in evaluating and enhancing the design, proving formal properties, and through some form of simulation verifying the model against the existing application. We should point out that tools have been developed, implemented, and tested to facilitate the