Design Document Overview

Transcription

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

2 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

3 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

4 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

5 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

6 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

7 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

8 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

9 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

10 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/

11

12 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/

13 Parameter Parser Model Constraint Builder Abstract Constraint Model Builder Component Factory AADL Output Generator Model Validation 9/13/

14 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/

15 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/

16 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/

17 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/

18 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/

19 9/13/

20 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/

21 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/

22 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/

23 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/

24

25 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/

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

27 Storage of AADL models in XML database XML:DB adapter AADL importer Individual object retrieval URI validation/conversion 9/13/

28 Initial storage of AADL handled by importer Subsequent requests from the database are handled on a perobject 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/

29 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/

30 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/

31 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/

32 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 Testing database path Testing 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/

33 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/

34 Overall System Design Questions? 9/13/

35 AnnexAAADLMetaModel-V0.999.pdf from 9/13/

36 pdf?root=eclipse_website&view=co 9/13/

37 The SAE AADL Standard: An Architecture Analysis & Design Language for Developing Embedded Real-Time Systems available from Carnegie Mellon University 9/13/