Design Review Client: Jon Mathews, EnSoft Advisor: Dr. Suraj - - PowerPoint PPT Presentation

Design Review

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

• Project Overview
• History of Project
• Problem/need statements
• System Diagram
• Intended users/uses
• Assumptions/Limitations
• Expected end products
• Approach
• Risks
• AADL Model Generator Design
• Design
• Testing
• Prototyping
• XML Adapter Design
• Same as above
• Cost and Resources
• Schedule

2

Original Project -

An open ended exploration project pertaining to performing error analysis on AADL models

Version 2 -

Redefined project scope to solve the storing of large AADL models in a database

Problems encountered with Version 2 -

• 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.

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

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

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,
• ur 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.

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

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

• The team will split into two smaller teams, one team

focusing on the model generator, and the other focusing

• n 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

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

11

• Complications arising from EStore interface implementation

(Low)

• Unforeseeable complications could creep up during the actual implementation of

the EStore interface. The team must try to minimize the damage caused by this and be quick on developing alternative solutions.

• Losing a team member (High)
• The actual chance of losing a team member is low, but the impact it would

create on the project would make the project unlikely to be finished if it were to

• ccur. Dividing the team into two separate groups would create specialization

among members which intensifies the damage caused by a team member loss.

• Finishing the project on time (Medium)
• This project has gone through multiple iterations. Which has been good ruling
• ut what has been feasible and what isn’t. But the delay caused by changing the

scope of the project has affected the amount of time allotted for the design phase.

12

13

14

• 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

15

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

16

• 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

17

• 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

18

• 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

19

• 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

20

• 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

21

22

• 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

23

• 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

24

• 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

25

• 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

26

27

• 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
• n a per-object basis

28

• OSATE suffers from limitations from using “standard”

EMF model

• Fix = Implement EStore interface to allow different

storage models

29

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

30

• 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

31

• 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

32

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

• 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

34

• 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) 35

• 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

36

• Materials
• Eclipse IDE, Free
• Java Development Kit, Free
• OSATE, Free
• BaseX, Free
• Testing plug-ins, Free
• SVN, Free (ECprE)
• Issue Tracking, Free (ECprE)
• E-mail, Free (Iowa State)
• Meeting Locations, Free (Iowa State)
• Possible Purchases
• Hardware for database, alternative use our own.
• E-books/Reference material
• Main cost of project?
• Time

37

• 8/24/09 – 9/04/09 (2 weeks)
• Fall Semester Presentation
• Develop General Structure of Model Generator
• Setup and Deploy BaseX Database
• 9/07/09 – 9/18/09 (2 weeks)
• First prototype for both components

Model Generator

• 9/21/09 – 10/16/09 (4 weeks)
• Second prototype
• 10/19/09 – 10/30/09 (2 weeks)
• Third prototype
• 11/02/09 – 11/13/09 (2 weeks)
• Fourth prototype
• 11/16/09-12/04/09 (3 weeks)
• Integration of prototypes into final code
• Acceptance Testing

38

XML Adapter

• 9/21/09 – 10/09/09 (3 weeks)
• Second prototype
• 10/12/09 – 11/06/09 (4 weeks)
• Third Prototype
• After 10/16, Model Generator is usable for testing purposes
• 11/09/09 – 12/04/09 (4 weeks)
• Integration of prototypes into final code
• Code clean-up
• Acceptance testing
• 11/23/09 - 12/04/09 (2 weeks)
• Create Poster and IRP presentation

39

40

AADL – Architecture Analysis and Design Language; Used to specify information about the hardware and software of a system and their connections CDO – Connected Data Objects; An enhancement of the EMF that allows EMF-based models to be stored in a central repository (database); Allows for pluggable storage adapters for connecting to different types of data sources Eclipse – A Java based IDE which is expandable by plug-ins EMF – Eclipse Modeling Framework; A framework for creating models in the Eclipse environment OSATE – Open Source AADL Tool Environment; Plug-in for Eclipse which allows for textual and XML editing of models; May be extended to edit models graphically. XPath – XML Path Language; It is a language used for selecting and accessing nodes in an XML document. URI – Uniform Resource Identifier; generic term used for specifying an address to an

• bject located on the Internet, computer file system, in a document, etc..

41

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

42

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

43

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

44