Detail C&C View

From DaVinci

Contents

Abstraction

The diagrams below show the overall architecture as well as how each of the quality attribute scenarios maps to the part of the architecture that promotes it. C&C views are used throughout.

Informational Notation

Image:Legend.jpg

Rules

  • commands: the basic unit of one functional operation
  • operation: one operation could be consist of several commands
  • There is only one operation could be performed at a time
  • Data Component has only one instance at the run-time

Element Catalog

Relations and Responsibilities for each element are described as below:

  • UI Manager:
    • It is the intermediary between the user and the functionality provided by the system. That is, the user is enabled to execute all transformations through this element.
    • It contains the user interface elements to interact with the user. These elements are used for entering transformation parameters, providing a mechanism to trigger the cancellation of an operation, and showing progress information for an operation.
    • It provides the Command Manager the data that this element needs for executing the desired transformation. These data include the name of the transformation and any default parameters with which this transformation has previously been executed.
    • It uses the Information Repository element for storing and retrieving previously used transformation parameters.
    • Although not relevant from the architecture point of view, it is worth mentioning that all user interface elements will be implemented under the Eclipse’s plug-in paradigm. This means that the UI Manager will interact with the Eclipse framework in order to provide all the user interface elements.
  • Command Manager
    • The Command Manager is responsible for triggering the Invoker thread to do the actual operation. It will input a Command Set with Commands inside as a parameter to the Invoker.
    • When it receives from the UI Manager the request to execute a transformation, it selects and assembles, in the right order, the required Commands to execute the transformation. These Commands are added into a Command Set element.
    • The Command Manager has the knowledge to determine which Commands are required to execute a particular type of transformation.
    • The Command Manager read from a XML file to know the mapping between each operation and the commands it should execute through.
    • Once the Command Set is ready, the transformation can be executed. The Command Manager then creates and runs in a separate thread the Invoker element. The Command Set is made accessible to the Invoker.
    • The Command Manager elements consists of three different kinds of elements
  • Command History:
    • It stores the mapping between the executed command name and the model after each command executed.
    • It stores the mapping between the executed operation and the commands that inside this operation.
    • It is responsible for keeping track of a limited number of operational commands. It may be used when users require a series of undo operations
    • It holds intermediate state for a given transformation so Commands are enabled to undo their operation.
  • Invoker
    • It knows how to construct the Command Set for an undo operation of a previously executed transformation.
    • Its main responsibility is to coordinate the execution of Commands that make up a transformation.
    • It is also in charge of coordinating the execution of the Commands required to cancel and to undo a transformation. In the case of cancelling a transformation, the Invoker waits for the current Command to complete. Then it executes in reverse order the undo operation of those Commands that had already been executed.
    • Once it receives progress information from Commands, it notifies the progress of the transformation to the UI Manager.
    • As a mechanism to avoid the user interface to be blocked, the Invoker runs in a separate thread than the UI Manager.
  • Model Manager
    • It interacts with OSATE to gain access to the AADL models that have been loaded.
  • Information Repository
    • It is a volatile repository that contains the parameters used to execute a particular type of transformation. For each type of transformation, this element stores the last parameters used to execute that type of transformation.
    • This repository only holds data generated during the current execution of the system.
  • Command Set
    • It holds a group of Commands which altogether implement a transformation.
  • Commands
    • Each Command in a Command Set is in charge of executing a fraction of a transformation. This provides a good level of granularity required for informing the user on the progress of an operation. Also this same granularity may be useful for an undo operation with several steps.
    • Each Command is responsible for notifying the Invoker the progress of the transformation.
    • Commands must know how to undo the operation they provide.
    • They keep track of the errors found in the AADL model. This list of errors must be made available to the user through the UI Manager.
    • They must run in the background so during the execution of a transformation the user may be able to continue using the system.
    • A Command is the only element that alters the model to be transformed. For this purpose, it uses the Model Manager for storing and retrieving data that allows it to undo its operation. It may also use the Model Manager to get access to the AADL model on which it needs to operate.
    • Commands in the same Command Set are not aware of each other and are executed sequentially.
    • It represents all of the functionalities (transformation, refactoring, optimization etc.) by having different kinds of Commands. Each Command has to implement the interface ICommand in order to provide the necessary functionality.
  • OSATE
    • Although OSATE is not shown as part of the architecture, it is worth mentioning that all the transformations that the described architecture accommodates work on models that are only accessible through OSATE.
    • The interaction with OSATE is centralized in the Model Manager.
  • Interface
    • The purpose of all the interfaces is to separate the implementation from the responsibility each element has.

Risks, Sensitivity Points, and Tradeoffs

There are concerns about performance issues. This is due to the fact that transformations are executed by a number of commands. The introduction of the Command Manager element for assembling these commands, then the coordination of their execution by the Invoker, and the independency among each Command make us think that this may be too much overhead on the system. Here we are facing a tradeoff between performance, and usability along with modularity. An alternate approach would be to have an entire transformation executed in one chunk, that is, in one command. However, we would need to introduce a mechanism to keep track of the progress in the transformation. That could be done by introducing an implicit-invocation pattern in which at certain points in time the command would be reporting its progress to whoever is interested in being informed.

Another issue with the current architecture is that in order to execute an undo operation, each command needs to store the state of the transformed model before it starts its operation. That may pose a scaleability problem if the Model Manager would handle requests from multiple commands. A tactic to solve this problem would be the implementation of an incremental undo, that is, a mechanism to only store the part of the model that has changed.

Before proceeding with the implementation, experiments for these and some other risks need to be done in order to mitigate these risks.

Retrieved from "http://seiproject.homeip.net:8088/wiki/index.php/Detail_C%26C_View"