Dean Allemang

Synquiry Technologies, Ltd.

One Williston Road
Belmont MA 02475

Tel: (617)484-3383x13, fax: (617)484-3363

Email: dta@synquiry.com

Many methodologies for organizing reuse process include the analysis of exemplar systems; including legacy systems, well-known state-of-practice systems, or even proposed or prototype systems (for a comprehensive treatment of this topic, see ODM).  In order to make effective use of the study of these systems, however, a great deal of knowledge about them must be organized in a way that facilitates an analysis of the functional commonality and variability of the systems.

The information that we need from a legacy or exemplar system in order to inform the construction of a well-scoped understandable reusable asset base is the same information we would use for design rationale.  In particular, the necessary information includes a Functional Representation of the system, as well as a structure of recorded alternatives for the system design.

The approach I propose for representing the information about a system is embodied in a tool called FAMILIAR (Formal Alternatives Management Integrating Logical Inference and Rationale).  FAMILIAR can be best understood in two parts; the formal alternatives manager, and the functional representation system. The formal alternatives manager allows several alternative designs to be considered in relation to one another.  Consider the following example:

Already in this example, we have considered three different possible systems - the legacy system as it stands, a new system built on the Irix platform, and a hybrid system made up of some components of each. These three alternatives are represented as siblings beneath the main heading for the combined Optical Recon System.  FAMILIAR shows this relationship in outline form. The scenario continues

These alternatives are represented as refinements of the general Hybrid solution, as shown below.

Each of these alternatives represents a particular system architecture, i.e., its own requirements for the components of the system an how they work together.  This information is stored in a functional representation of the system, which records the expectations of the system, the components it uses to accomplish those expectations, and an explanation for how those components will work together to accomplish the expectations.  In the case of the hybrid Irix MPS system, this is expressed in a three-level diagram:

In this diagram, the overall functionality of the combined Irix and MPS hybrid system is shown to be made up of  a camera controller and an image processor, which are cascaded in that order as shown in the middle of the diagram - that is, after the camera controller has run, the image is available.  After the image processor has run, the image has been interpreted.  Finally, the particular camera controller runs on the MPS system, and the image processor runs on Irix.

Diagrams of this sort already provide more formal information about the meaning of the alternatives shown in the FAMILIAR outline above; in particular, they include architectural information that discriminates one alternative from another.  However, a functional representation can also provide certain analytic services to determine and record properties of the system that arise from the architecture.

Following the example, if we annotate the MPS system with information about the protocols it can use to publish its information, and the protocol that Irix can use to import information, it is possible to trace the diagram above to determine that the protocols do not match.  This is done by a component of FAMILIAR called ZD (Liver95), which analyzes functional representations.  In this case, ZD reports its findings as annotations on the archtecture diagram showing where and what the error is.  In this case, the error is recorded as an annotation on the overall service level, that a mistmatch has happened in the protocol property of the combined components.  In the diagram, this error is signalled with a change in color at the service level. In fact, FAMILIAR stores both versions of the digram, i.e., with and without the color annotations, as a before/after analysis comparison.

In FAMILIAR, these diagrams are displayed using the visualization tool AcmeStudio, which also allows the user to examine the details of the analysis made by ZD. Finally, the scenario continues:

This refinement is shown in FAMILIAR as a further entry in the outline:

The functional representation of this architecture is similar to the ones shown earlier, with the addition of the filter.

If we annotate the filter with the conditions that it changes the X protocol into TCP, then ZD can analyze this architecture as flawless. All of these functional representations, in the form of (annotated) architecture diagrams, are stored with the alternative structure of FAMILIAR, so that they are available from the outline as explications of the alternatives, why they satisfy certain requirements or why they do not.

The capabilities described in this paper are available in a prototype system written in Java and Lisp.  The graphical presentations (and all the architecture images in this paper) were done with AcmeStudio, which runs on Windows platforms.  The alternatives manager (which was used for the outine images) was produced by Knowledge Evolution, Inc.

The most similar approach to the ZD style of functional representation is the TMK modeling system of Murdock.  ZD differs from TMK in several ways, but one that is important for reuse is the fact that devices are defined modularly in ZD, with a distinction between the role played by a subcomponent, and the particular subcomponent that plays the role.  TMK makes no such distinction; this makes it difficult to use a TMK model as a basis for an analysis for commonality and variability of subsystems.

FAMILIAR in general is similar to issue-based rationale systems (e.g., WinWin, Lee96) in that it organizes information about design rationale in a persistent structure.  It differs from WinWin in that the structure of the information is based on the idea of analyzing and comparing multiple systems, again making it particularly useful for commonality and variability analysis. FAMILIAR is unique among architecture representation systems in that it manages multiple architecture diagrams and analyses in a systematic way.  While a single architecture representation language such as ACME (Garlan97) can represent several levels of architectural detail, it is not very effective at representing variation in architectures or their evolution.

Dean Allemang finished his PhD with Prof. B. Chandrasekaran in 1990 at The Ohio State University.  His dissertation topic addressed the issues of applying functional representation to the analysis of software.  Since that time, he has continued this research in a number of different contexts, including collaboration with Dr. Beat Liver at Swiss Telecom, applying these concepts to the management of telecommunications networks.  At present, Dr. Allemang is pursuing this research as part of DARPA's Evolutionary Design of Complex Systems programme, where he has integrated the functional representation capabilities of ZD with alternatives management and architecture description.