Design Document Overview Client: Jon Mathews Advisor: Dr. Suraj - - PowerPoint PPT Presentation

Design Document Overview

Client: Jon Mathews Advisor: Dr. Suraj Kothari Team Members Chaz Beck Shaun Brockhoff Jason Lackore Marcus Rosenow

• State of the Project

 New problem/need statements  ‘How did we get here?’  Intended users/uses  Assumptions/Limitations  Expected end products  Approach

• AADL Model Generator Design

 Design  Testing  Prototyping  Schedule

• XML Adapter Design

 Same as above

9/13/2009 2

• There is a need for interesting test cases involving AADL

models, particularly very large models

• We need to be able to generate AADL models with the ability

to specify attributes that the model must have

i.e. percentage of objects that are a particular component type, depth

• f the tree, etc

AADL models do not need to represent any real world system, however they must be valid models.

• The Random AADL Model Generator will be independent of,

but related to the XML adapter

9/13/2009 3

• OSATE and other tools used to create and edit models for

large, complex systems

• Currently, the entire model is stored in main memory, which

is a problem as models reach several gigabytes in size

• Data can only be queried on a per resource basis
• For efficient model retrieval, we need to be able to store and

query individual objects as opposed to entire resources

9/13/2009 4

• Original project was an open ended exploration project

pertaining to performing error analysis on AADL models

• Redefined project involved storing large models in a database

 New requirements are keeping with this focus  Problems requiring us to change directions

• Attempting to understand and modify OSATE’s source code was proving

to be outside the scope of the class

• Further research into CDO determined that the software was not yet

mature enough to depend on later in the project

• New project direction is keeping with the same overall goal, without

getting tangled in CDO and OSATE.

9/13/2009 5

• The end product is expected to be useful mostly to other

developers.

 As the overarching goal is still to get OSATE to be database-enabled, our software will be primarily used to provide a framework that can be plugged into OSATE (without our team getting involved with that part)  The AADL model generator will be useful both for our team to use in testing the XML adapter, and also for general AADL model testing by

• ther developers.

9/13/2009 6

• Open Source XML Database

 Mature enough for use  Any limitations posed by selected database will in turn pose limitations on API’s for interaction

9/13/2009 7

• AADL/EMF model generation tool

 Used to create large models with specified parameters for use in testing

• XML database adapter

 Lessens the burden of larger AADL models by storing “unused” segments in secondary storage

9/13/2009 8

• The team will split into two smaller teams, one team focusing
• n the model generator, and the other focusing on the XML

adapter

• XML Adapter

 We will plan on investigating the EStore class of EMF for Resource Management

• CDO implements EStore, so our resource management needs can be

feasibly met with this interface

9/13/2009 9

• AADL Model Generator

 There are already model/graph generators in existence, but none yet for AADL  Will follow a similar approach to other model generators...but with additional constraints to ensure the model conforms to AADL  We plan to start with some static (but interesting) models to test specific access patterns  We will eventually work up to very granular controls to combine many different attributes and constraints in an adaptable way

9/13/2009 10

• System must take in parameters and output a model that

fulfills the parameters given

• System must be extendable, that is, allow a developer to easily

add new parameter types to the model generator

• System must generate large models incrementally, without

using large amounts of computer memory

9/13/2009 12

• Parameter Parser
• Model Constraint Builder
• Abstract Constraint
• Model Builder
• Component Factory
• AADL Output Generator
• Model

Validation

9/13/2009 13

• Parameter Parser

 Check the validity of each individual parameter and pass to the model constraint builder

• Model constraint builder

 Combine different constraints into one unified constraint, like a query  It is important that parameters cannot contradict one another, so check the validity of the combination parameters given

9/13/2009 14

• Abstract Constraint

 In order for the system to be extendable all constraints will need to fall under a similar structure  Constraints will modify the existing attributes of the system in some way,

• r create new ones

9/13/2009 15

• Model Builder

 Take individual components and combine them in meaningful ways  Must follow rules of AADL, particularly concerning component hierarchies

• Component Factory

 Generate individual components based on constraints on demand  Return the components to the model builder for use in the overall system

9/13/2009 16

• AADL Output Generator

 Take the model represented in memory and output it to AADL text  Use constraints to break up the model into resources as required

• Model

Validation

 Check the completed model to ensure it conforms to AADL standards  Use in testing stage of the project

9/13/2009 17

• Input

 Take in a set of parameters and their values(as seen in the next slide)  Not all parameters are required, some parameters have default values

• Output

 Valid AADL Model with attributes based on parameters given  Model will NOT represent an actual system

9/13/2009 18

9/13/2009 19

• Using a command line interface with switches to control

parameters for model generation.

 Will make it easier to extend and plug in new model constraints  With no GUI, new developer needs only to develop the logic for the new parameters and not worry about updating any graphical elements

9/13/2009 20

• Model Generator will be written in Java using the Eclipse

development environment

 Other AADL tools are already in Java so it makes sense that this will be in Java.

• While it is standalone it is possible that it could be integrated in the future

9/13/2009 21

• Black box testing methods for the interface

 Random input  Boundary testing  Equivalence classes

• Unit testing on internal methods
• Metrics for code coverage
• Output will be verified via OSATE or a contrived testing suite

for automation

9/13/2009 22

• Several prototypes

 Increasing complexity  Increasing size  For major features

• Example

 Prototype 1: Generating tree in memory  Prototype 2: Outputting tree to AADL  Prototype 3: Inserting more complex AADL constraints  Prototype 4: Implementing cross referencing

9/13/2009 23

• The system must take as input an AADL model in its XML

format and store it in an XML database

• The system must provide access to stored AADL models on a

per-object basis

9/13/2009 25

• OSATE suffers from limitations from using “standard” EMF

model

• Fix = Implement EStore interface to allow different storage

models

9/13/2009 26

EMF/Ecore XML Schema and XMI meta model Readers and Writers for XML Schema and XMI meta model Java Classes and Persistent Storage

• Storage of AADL models in XML database

 XML:DB adapter

• AADL importer
• Individual object retrieval

 URI validation/conversion

9/13/2009 27

• Initial storage of AADL handled by importer
• Subsequent requests from the database are handled on a per-
• bject basis

 URI indicates the specific object to retrieve  URI between XML database and EMF converted as needed

• An open source XML database such as BaseX that targets

“XML:DB API”

 Other Options [fallbacks]

• Target XQuery or DOM enabled open source XML databases

9/13/2009 28

• Input

 Initially, an AADL model in AADL XML format  URIs for individual objects within a model  Address\Path to XML database

• Authentication to database
• Output

 EMF objects corresponding to URI input  A valid URI in respect to URI validation/conversion

9/13/2009 29

• Integrated into OSATE workspace

 Database settings inside Window > Preferences > OSATE

 Inserting AADL model into database using OSATE menu

• Requires editing OSATE’s plugin.xml file

and a few snippets of code for action listeners

9/13/2009 30

• XML database adapter will be written in Java using the Eclipse

development environment

• EMF interfaces including the EStore will be used for the

persistent storage of AADL models

9/13/2009 31

• Setup XML database for integration testing

 Start with one database, switch out or add additional XML database depending

• n time constraints and encountering difficulties
• Unit testing [jUnit 4]

 Black box testing and acceptance testing

• T

esting database path

• T

esting various XML files

 White box testing

• Internal code methods
• Metrics for test coverage and code complexity
• Use AADL Model Generator for integration testing and handling

large AADL models (acceptance testing)

9/13/2009 32

• Storage of simple XML data with no relevance to OSATE

and/or AADL models

• Build simple EMF model, derive XML from model, and insert

into database for storage and retrieval

• Storage of complex AADL model and access more complex

sets of data within

9/13/2009 33

• Overall System Design
• Questions?

9/13/2009 34

9/13/2009 35

AnnexAAADLMetaModel-V0.999.pdf from www.aadl.info

9/13/2009 36

http://dev.eclipse.org/viewcvs/index.cgi/www/cdo/documentation/presentations/Webinar_2009_01/CDO_Webinar_2009_01. pdf?root=Eclipse_Website&view=co

9/13/2009 37

“The SAE AADL Standard: An Architecture Analysis & Design Language for Developing Embedded Real-Time Systems” available from Carnegie Mellon University