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 of 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 other 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 on 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, or 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

Readers and Writers XML Schema and Java Classes and EMF/Ecore for XML Schema and XMI meta model Persistent Storage XMI meta model • OSATE suffers from limitations from using “standard” EMF model • Fix = Implement EStore interface to allow different storage models 9/13/2009 26

• 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- object 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 on 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