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):
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.
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 {
SAAM, ISVIS, SIRRINE, SCENIC, MORPH };
EXAMPLE:
The analyst is working on a trace file from the dfs legacy system using usage scenario 10_Node_DFS.
Family dfs = {
… System 10_Node_DFS = { …
Property source:ArchSourceT = ISVIS; }
}
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
SourceFile : String;
SourceLineNo: int;
;
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 = {
Component PolkaAnimator= { Port fCallIn, fCallOut; Representation polkaDetail; }
Component ActualShapes= { Port fCallIn, fCallOut; Representation shapeDetail; }
};
System polkaDetail = {
Component Action= { Port Action, copy; Property code:SourceCodeT = ("Polka/polka.h", 34);}
Component AnimObject= { Port DamageIt, Draw, Intercepts; Property code:SourceCodeT = ("Polka/polka.h", 200);}
};
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
ScenarioName : string;
ScenarioDesc : string;
AttachementList: Sequence of string;
;
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 : {
View.drawAll to classMemberCall.caller;
AnimObj.Intercepts to classMemberCall.callee;
AnimObj.Intercepts to classMemberCall.caller;
LineImpl.BoundBox to classMemberCall.callee;
}
//highest level of abstraction
Attachments : {
PolkaAnimator.fCallOut to message.send;
ActualShapes.fCallIn to message.receive;
}
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.
Property Type ArchSourceT = enum {
SAAM, ISVIS, SIRRINE, SCENIC, MORPH };
Property Type SourceCodeT = Record
SourceFile : String;
SourceLineNo: int;
;
Property Type ScenarioT = Record
ScenarioName : string;
ScenarioDesc : string;
AttachementList: Sequence of string;
;
};
//The high-level system definitions are here. This is the top-level of abstraction
//that the MORALE tool has produced.
System 10_Node_DFS = {
Component PolkaAnimator= {
Port fCallIn, fCallOut;
extended with Representation {
polkaDetail;
Bindings :
PolkaAnimator.fCallOut to AnimObj.Intercepts;
}
}
Component ActualShapes= {
Port fCallIn, fCallOut;
extended with Representation {
shapeDetail;
Bindings :
ActualShapes.fCallIn to LineImpl.BoundBox;
}
}
Connector message = {Role send, receive;}
Attachments : {
PolkaAnimator.fCallOut to message.send;
ActualShapes.fCallIn to message.receive;
}
Property source:ArchSourceT = ISVIS;
Property scenario_list:ScenarioListT = {
("Line Box", "Draw bounding box around a line during screen redraw", (1));
};
};
//Now the detailed representations that represent the next level of abstraction in the system.
System polkaDetail = {
Component View= { Port drawAll; Property code:SourceCodeT = ("Polka/polka.h", 34);}
Component AnimObject= { Port Intercepts; Property code:SourceCodeT = ("Polka/polka.h", 200);}
Connector classMemberCall = {Role caller, callee;}
Attachments : {
View.drawAll to classMemberCall.caller;
AnimObj.Intercepts to classMemberCall.callee;
};
;
System shapeDetail = {
Component LineImpl = {Port BoundBox; Property code:SourceCodeT = ("Polka/polkaobject.c",133);
Connector classMemberCall = {Role caller, callee;}
};
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
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: