From DaVinci

Contents 1 Project Overview: 1.1 Project objective 1.2 Target Market 1.3 Potential extensions 2 Project Context 2.1 Business Goals 2.2 Problem Definition 3 Architectural Drivers 3.1 Functional requirements 3.2 Prioritized Quality Attribute Utility Tree 3.3 Quality Attribute Scenarios 3.4 Constraints 4 High-Level Architecture 4.1 Overall Approach for Architecture Design 4.2 Component & Connector Viewtype

Project Overview:

Project objective

Currently, the Architecture Analysis and Design Language (AADL) is a standard of the Society for Automotive Engineers (SAE) that has little tool support and a fairly small user community. The SEI aims to enlarge the user community substantially. More users would allow the SEI to offer their consulting services to a larger audience. More broadly, this would also motivate venders to develop other tools for the language, thus eventually attaining the critical mass AADL needs to gain traction as an industry standard. The SEI intends to achieve this by developing a software tool suite that would allow AADL to grow fairly easily while providing a baseline that tool vendors can build on top of. Such requirements call for the tool suite to be easy to understand, extend, and maintain. The project will contribute to the ongoing tool suite development task by implementing and including the following plug-in tools:

• Refactoring tools
• Model optimization tools
• Model transformation tools
• Documentation and guidance for users who intend to extend the Open Source AADL Tool Environment (OSATE), and need help to determine whether they should use the Atlas Transformation Language (ATL) or programmatic techniques for their extensions.
  

Figure: Overall System Context Diagram

ContextDiagram.vsd

Target Market

The project\'s target markets are real-time and embedded system-engineering communities. Engineering communities within the aerospace, automobile and avionics industries currently use a broad variety of model-based software system-engineering practices to reduce system errors, avert dependability failures, and increase their systems\' performance. In 2004, the SAE approved the AADL as a standard notation for describing and reasoning about complex system architectures. Although AADL promises to address many of the needs of the target markets, engineers have been relatively slow to adopt it. One major limitation currently hampering wide-spread adoption is the fact that very few software tools support AADL at the moment.

Potential extensions

This project can be extended in the future to support more intelligent model-analysis tools. Such tool support would better enable engineers to identify architectural errors and predict the consequences of using different architectural patterns. This would build upon this project\'s goals of providing automated model transformation, refactoring, and optimization. Incorporating intelligent analysis tools will be the logical next step because this would automate the decision making needed to determine what transformations, refactorizations, and optimizations should be applied.

Project Context

Business Goals

• Foster the widespread use of AADL as the standard for model-based embedded systems engineering by:
  • Providing a cost-effective method for predicting how well suited an architecture model is for promoting the quality attributes required by a software-intensive system.
  • Helping detect architectural issues early in the software development process by analyzing how software-intensive systems will perform.
  • Reducing development, integration, and maintenance costs of software-intensive systems in the embedded domain.
  • Encouraging the use of a common architecture modeling notation in the aerospace, avionics, and automotive industries.
  • Promoting the cooperation between different parties by easing the interchange and integration of architecture models.

Problem Definition

Team DaVinci\'s role is to develop plug-ins to extend OSATE\'s capabilities. OSATE, which supports the AADL standard, is aimed at software architects in the embedded systems domain who need to measure and analyze quality attributes of software architectures. The tool allows users to model architectures via graphical and textual views.

Typically, organizations create architecture models to reason about software-intensive systems. This reasoning is often supported by the use of already existing analysis tools that require a model structured in a predefined way. Currently OSATE does not support the conversion of AADL models to or from these other third party formats. One of team DaVinci\'s responsibilities is to create conversion plug-ins to support a predefined set of analysis tools.

As a result of this reasoning, opportunities for fine-tuning these models can be identified. Another feature to be added to OSATE is the optimization of a particular model, this is, from a given AADL model OSATE will be capable of producing an equivalent AADL model but with some sort of optimization applied on it.

AADL models may be rather large. Working on these models may become a tedious task. Refactorings are a good source to minimize editing tedious details. Another capability to be added to OSATE is the support of refactorings which may alleviate simple but tedious tasks such as the renaming of components.

Architectural Drivers

Functional requirements

Transformations

• Transform an AADL model into an XML model that an existing analysis tool accepts as input. The analysis tool has not yet been selected.
• Transform an AADL model into a non-XML model that an existing analysis tool accepts as input. The analysis tool has not yet been selected.

Refactoring

• Change AADL system components to process components.
• Refactor AADL models using the ATL framework. The specific refactoring task remains to be identified.
• Refactor AADL models using hand-crafted code. The specific refactoring task remains to be identified.

Optimizations

• Reduce the number of connections in AADL models by introducing port groups that encompass those connections.

Prioritized Quality Attribute Utility Tree

Figure: Prioritized Quality Attribute Utility Tree

UtilityTree.vsd

Quality Attribute Scenarios

1. When DaVinci Transformation (DVT) reads a semantically correct AADL model and executes the transformation, the result cannot lose relevant information.

2. DVT reads a semantically incorrect AADL model. The model is processed without a crash, and no new errors are introduced. An error list is provided to easily navigate to them.

3. A non DaVinci team member that understands a transformation must be able to write that transformation using the DVT infrastructure and the ATL framework in less than 3 weeks.

4. When users start long-running transformations they must be able to cancel the transformation at any time and without causing any inconsistent data.

5. When users start long-running transformations the user interface must not be blocked.

6. Within a session, users must be able to re-run transformations using previously entered input data.

7. When users start transformations taking more than 1 second, they must get feedback of the progress.

8. The user wants to undo the transformation, refactoring or optimization that changed an AADL model. That must be possible within an existing session and without causing any inconsistency in the model.

Constraints

Technical

• The new features must be implemented as Eclipse plug-ins using the Java language.
• Some features must be implemented using the ATL framework. Others must be implemented by using the OSATE infrastructure to programmatically manipulate the AADL model.

Business

• OSATE is being developed as open-source software and is covered by the Common Public License.

High-Level Architecture

This section describes the high-level architecture of the project.

Overall Approach for Architecture Design

We followed the guidelines provided by the Architecture Centric Development Method (ACDM) for creating a high-level architecture for the system.

The brief summary of the approach:

1. Create a notional architecture of the system depending on the high-level functional requirements, quality attribute scenarios, and constraints.
2. Partition important elements and assign responsibilities to sub-elements until they satisfy the prioritized quality attribute scenarios.
3. Evaluate alternatives, tradeoffs between alternatives and provide rationale for a choice between alternatives.
4. Plan and conduct appropriate experiments to mitigate the risk due to unknown elements in the architecture.
5. Review architecture with clients, mentors, and experts.
6. Refine architecture based on review.
7. Document the architecture.

Component & Connector Viewtype

The following diagram shows the high-level architecture (C&C view) of our system.

Figure: High level C & C View

CandCView.vsd

In this high level C&C View, two main architecture styles are used to represent the system. One is event-based style (at the top of the figure) and the other is call-return style (at the bottom of the figure). The combination of these two architecture styles fulfilled the necessary quality attributes, functional requirements and constraints of our system.

The following element catalog explains the key architectural elements shown in the high-level architecture and provides a brief description. The description includes element type (component/connector), responsibilities of the component, and other important attributes of the architectural element.

Architectural Element	'Description and Responsibilities'
Function Component: - Transformation - Optimization - Refactoring	The three main high-level functional requirements of our system are Transformation, Optimization and Refactoring. As shown in the high-level architecture, our system is divided into three major Function Components. Each of the Function Component provides the corresponding high-level functionality of the system. Therefore, all of the Function Component accepts an input model and outputs a result model using a particular algorithm inside the component.
Control Component - UI Manager - Model Manager	There are two main Control Components in the system. They are used to handle the operation logic between the Function Components and the user operation (or data operation.) - UI Manager: The UI Manager mainly handles the inputs from the user and manages the instances of the Function Components. It has four major responsibilities. Manage the instance: It initiates each of the Function Component using different threads or processes without blocking the user interface and get the reference of each instance if necessary. Handle the user input: It handles the inputs and commands from the user. It verifies the input and the command from users and then calls the Function Component. Handle the events: It handles the events from the Function Components and the Model Manager and decides the next operation based on getting the different events. Show the visual effects: It is responsible for presenting the visual effect to users after the operation. - Model Manager: The Model Manager handles all of the model operation within the system. It has three major responsibilities. Keep the old models: It contains the data structure to track old and new versions of the models. Therefore, users can roll back to previous version models if they want to access the old model. (e.g. undo operation) Monitor each model: It monitors each of the models within the system. When there is a modification for any of the model, it will generate the event to let the UI Manager know the changes. Output the model to physical file: It also includes the functionality to handle the file I/O for models and generate the different format of the models if require.
File	The File here contains the physical models, such as AADL models and third-party data models. They are usually presented in an XML style format.
Eclipse/OSATE platform	Our system is based on the OSATE system that is an open source project using the Java technology provided by the Eclipse platform. The plug-in we are developing now is also using the technology provide by Java technology and eclipse platform. (e.g. EMF and ATL)
Event bus	It is a representation of the event based architecture style.
X calls Y	It is a connection presenting the relationship between the Component X and Y. Here, it is the call-return style, and X is the caller, and Y is the callee.
X outputs Y	It is a connection presenting the relationship between the Component X and Y. Here, X outputs the model to physical file as Y.
X generates events to Y	It is a connection presenting the relationship between the Component X and Y. Here, X generates the event to the Y and Y usually is an event bus.