This FLAME user guide will take you through a set of steps necessary to try FLAME for a collaborative design environment that uses XTEAM. The XTEAM design environment used in this user guide estimates (1) memory usage, (2) energy consumption, and (3) message latency of a message-oriented system. Note that that design environment might not be the best fit for your project, and you will need to integrate FLAME into your design environment.
Deployment-wise, FLAME has three sides: (1) server-side, (2) detector-side, and (3) architect-side. In the following sections, this user guide, for each of those sides, will list the prerequisite software packages as well as the detailed steps you need to follow in order to install and launch FLAME.
The rest of this guide is organized as following:
FLAME adds high-order proactive conflict detection on top of a conventional copy-edit-merge collaborative software design environment. On the architect-side, FLAME attaches a modeling tool-specific adapter, FLAME Adapter, to the modeling tool to capture each modeling change as it is made via the modeling tool's APIs. A FLAME Client is installed at each architect's location to establish a channel between the architect-side and the server-side through which the captured modeling changes can be sent. For proactive conflict detection, each captured modeling change is immediately forwarded from the FLAME Adapter, through the FLAME Client, to the server-side.
[Analysis type], [Column index in the .csv file], {[Target value] [operator] [threshold], ... }
Energy, 1, Total<7000000
Memory, 1, Maximum<30
Latency, 2, Average<7, Success>95
The interpretation of the above example XTEAM_Info.dat file is as following. FLAME will monitor three types of analysis: (1) energy consumption, (2) memory use, and (3) message latency. Each analysis type, in their corresponding .csv XTEAM simulation output, stores the data at the column number 1, 1, and 2 respectively. For energy consumption, FLAME will compute the overall summation of the values (Total) and validate if that is less than the threshold 7,000,000. For memory use, FLAME will find the maximum memory use of any component/connector at any point and validate if that is less than 30. Lastly, for message latency, FLAME will compute the average request-response time of all messages at every monitored interface and validate if that is less than 7. FLAME will also compute the success rate (number of responses / number of requests) and validate if that is greater than 95 percent.
The server-side Client Manager, which manages the connections between the server-side and FLAME Clients, receives the modeling change and forwards it to Detector Manager, which subsequently replicates and broadcasts the modeling change to all connected Detection Engines.
[Analysis type], [Column index in the .csv file], {[Target value] [operator] [threshold], ... }
Energy, 1, Total<7000000
Memory, 1, Maximum<30
Latency, 2, Average<7, Success>95
The interpretation of the above example XTEAM_Info.dat file is as following. FLAME will monitor three types of analysis: (1) energy consumption, (2) memory use, and (3) message latency. Each analysis type, in their corresponding .csv XTEAM simulation output, stores the data at the column number 1, 1, and 2 respectively. For energy consumption, FLAME will compute the overall summation of the values (Total) and validate if that is less than the threshold 7,000,000. For memory use, FLAME will find the maximum memory use of any component/connector at any point and validate if that is less than 30. Lastly, for message latency, FLAME will compute the average request-response time of all messages at every monitored interface and validate if that is less than 7. FLAME will also compute the success rate (number of responses / number of requests) and validate if that is greater than 95 percent.
A Detection Engine is similar to a FLAME Client in the way that it is connected to an instance of the modeling tool with a local copy of the model internally, but a Detection Engine does not have an architect using the modeling tool initiating operations. Instead, it has an off-the-shelf conflict detection tool plugged into the modeling tool. An instantiation of FLAME may have multiple Detection Engines, each of which has a different conflict detection tool and may maintain a different version of the model. When a Detection Engine receives an operation that has been broadcast by the Detector Manager, the Detection Engine applies the operation to its local copy of the model, automatically invokes the conflict detection tool, and analyzes the outcome as an architect would do. The result of the analysis is then consolidated and delivered back to the architects via FLAME in the reverse order to that described above, i.e., from the Detection Engine, via the server-side components Detector Manager and Client Manager, and to the architect-side FLAME Clients.
FLAME's detector-side has a component called Slave Manager, which manages a pool of slave nodes. Slave nodes may join the pool on-the-fly by initiating a connection to the Slave Manager, and the Slave Manager can asynchronously and simultaneously process several conflict detection instances by deploying the instances on the slave nodes.
This user guide will use Google Compute Engine as the cloud platform on which slave nodes are initiated and deployed.
Exploiting its architecture, FLAME can proactively inform an architect whether she has any outstanding high-order conflict that she will find when she performs an update, even before she actually performs the update. In turn, the earlier finding of the conflicts may potentially lead to lowered cost and complexity in their resolution.
Should you have any questions, do not hesitate to contact me: Jae young Bang ()