Morale / ACME Tool Interchange Specification

GENERAL

ACME is an architectural interchange language which provides an almost unlimited extensibility through the property mechanism in the language. The following general descriptions map ACME keywords to their MORALE interpretation (ACME keywords are shown as boldItalics):


EXPORTATION:

All MORALE tools are responsible for conservation of information. This means that information imported from an ACME description which is not used by a particular MORALE tool must still be exported back to the ACME representation so information is not lost during manipulation by tools that operate at divergent levels of abstraction.

ISVIS

System

GENERAL

ISVis provides reverse engineering support for legacy source code. It builds one or more preliminary architectural views of a legacy system tied to a specific usage scenario for the software under analysis. Each usage scenario may have multiple "views" (or analyst estimates of the architectural representation). Each of these views may be defined as a separate ACME System or they may all use the same System, but with additional properties being added to each System. The continuing example used through this description is based upon the actual ISVis data available by viewing the ISVis tutorial and using dfsFinal1.session as the input file.

PROPERTIES OF SYSTEMS

Since a Family may have several System representations, it is useful to note the origin of this particular representation. The following property is used to note the MORALE tool which most recently modified the System representation. This property is common across all MORALE tools.

Property Type ArchSourceT = enum {

EXAMPLE:

The analyst is working on a trace file from the dfs legacy system using usage scenario 10_Node_DFS.

Family dfs = {

}

Component , Port

GENERAL

The ISVis analyst defines components during analysis. Each component generally maps directly to an ACME Component. The exception to this rule is if a component is contained in another component. In this case, it is treated as in the following description.

ISVis allows the definition of components to include files, classes and functions. For non-object-oriented legacy languages, all functions are considered to be in class GLOBAL. Likewise for OO legacy systems which allow some functions outside classes (like C++), all functions outside a class are grouped in the class GLOBAL. How these items are handled depends on whether the legacy language is OO or not:

PROPERTIES OF COMPONENTS

The principle property for ISVis-defined components is the source code information (file and line number). To store this information, ISVis uses a standard type that is defined for every Family.

Property Type SourceCodeT = Record

EXAMPLE:

The ISVis screen shows the following items:

Components Files  Classes Functions 
Polka Animator Polka/polkaobject.c 

Polka/polka.h

Action 

AnimObject

AnumObjImpl

Animator

View

Action 

Copy

DamageIt

Draw

Intercepts

MyView

SetWrapper

RegisterAlgoEvt

AddUpdateObject

Animate

ActualShapes Polka/polkaobject.c CircleImpl 

LineImpl

RectangleImpl

TextImpl

BoundBox 

Draw

Where

System 10_node_dfs = {

};

System polkaDetail = {

};

Connector , Role , Attachment

GENERAL

ISVis uses the concepts of a scenario and an interaction to describe the interaction between actors (Component and Port). During exportation, these descriptions are changed into Connector and Role definitions. In general, for architectural analysis, the ordering of events within a scenario is not important, however for some MORALE tools, the ordering of the events within a scenario must be preserved. ISVis doesn't support specification of connectors at a high level of abstraction except through the scenario mechanism. Scenarios are discussed in more detail in the following section. ISVis uses a standard set of connector/role definitions for both low and high levels of abstraction.

For low-level abstraction they are:

For high-level abstraction they are:

ISVis processes the list of scenarios and generates Attachment descriptions based upon the actual event traces.

PROPERTIES

The scenario property is generally a property of a System however it is included here because of its close ties to the concept of Connector. A scenario has a name which is the name the ISVis analyst gives the scenario when created. The description is the descriptive text provided by the analyst on creation of the scenario. The Attachment list is a sequence of integers each representing an attachement involved in this scenario. The integer is basically an (1-based) index into the attachment descriptions with 1=first pair in Attachment list. Ordering is significant and preserves the event ordering of the ISVIS trace.

Property Type ScenarioT = Record

;

Property Type ScenarioListT = Set of ScenarioT;

EXAMPLE

Assume the components involved in this example are a continuation of the previous example.

Scenario Name Scenario 

Description

Interaction
LineBox Draw bounding box around a line during screen redraw drawAll to Intercepts 

Intercepts to BoundBox

BoundBox return to Intercepts

Intercepts return to drawAll

Connector classMemberCall = {Role caller, callee;}

Connector message = {Role send, receive;}

//lowest level of abstraction

Attachments : {

//highest level of abstraction

Attachments : {

Property scenario_list:ScenarioListT = {

("Line Box", "Draw bounding box around a line during screen redraw", (1,2));

};

Note - resolution of the high level and low level attachment abstractions is done through the Bindings clause which is elaborated for representations (see consolidated example). The order that bindings are listed is significant and must "match up" across the components. Otherwise the single abstract message roles will lose the ability to bind multiple concrete ports to their single abstract port. It may be helpful to think of this an abstraction of a multiplexing message port.

Consolidated Example

Using the same ISVis data as before, the combined individual examples in their proper order would look like:

Family dfs = {

//This is a header for all system descriptions generated by MORALE tools. All

//common type definitions are automatically included here for use by other

//tool imports.

};

//The high-level system definitions are here. This is the top-level of abstraction

//that the MORALE tool has produced.

System 10_Node_DFS = {

};

//Now the detailed representations that represent the next level of abstraction in the system.

System polkaDetail = {

;

System shapeDetail = {

};

SAAM

This description assumes the reader has read and understood the general description of the export mechanism in ISVis. Since SAAM handles architectures at the level ACME was originally intended, there is a close correspondence between the ideas of System, Component, Connector, Port, Role and Attachment . Saam however provides refinements of these concepts which must be preserved via properties.

SAAM differentiates between types of components. Each component coming out of SAAM has a component type (the default is COMPUTATION):

Property Type ComponentTypeT = enum {COMPUTATION, DATA_STORE, FILTER};

Likewise, connectors also have different types (default is PROCEDURE_CALL):

Property Type ConnectorTypeT = enum {PROCEDURE_CALL, MESSAGE, EVENT, PROTOCOL, RPC};

Many times an architecture may have been designed using one of the standard architectural styles. If a style was used as the basis of the architecture, it is recorded as a property of the System.(default is NONE).

Property Type ArchStyleT = enum {BLACKBOARD, PIPE_FILTER, LAYERED, CLIENT_SERVER, NONE};

SAAM generates scenarios to perform impact analysis of a system. As in ISVis, a list of attachments forms the basis from which a scenario can be recreated. Unlike ISVis, when SAAM has mulitple views of a system, the scenarios are constant across the Family, but each System must account for whether the scenario was direct or indirect. When SAAM exports to ACME, the scenario list may be moved into the Family definition. Each individual system has a list that corresponds to the scenario classification.

Property Type ScenarioTypeT = enum {DIRECT, INDIRECT};

Property Type ScenarioTypeListT = Sequence of ScenarioTypeT;

EXAMPLE

SIRRINE

SCENIC

MORPH


IMPORTATION

ISVIS

SAAM

SAAM imports ACME descriptions and builds visual representations to which architectural information is attached. SAAM maintains two models of information based upon the imported data:

When SAAM imports an ACME file it does the following:

Using the example of ACME Exportation from ISVIS (not repeated here), the following graphs would be drawn:
First the context showing the family and all systems containing views of that family:

Next the System-level view is generated:

If desired, each container node (those with representations) can be shown:


Finally, SAAM supports isolation of individual scenarios.  A scenario view is generated using the information contained in the scenario property exported from ISVIS:

 

SIRRINE

SCENIC

MORPH