Jon Mathews Team Members Chaz Beck Marcus Rosenow Shaun Brockhoff - - PowerPoint PPT Presentation

Faculty Advisor –

• Dr. Suraj Kothari

Client – Jon Mathews Team Members – Chaz Beck Marcus Rosenow Shaun Brockhoff Jason Lackore

 AADL (Architecture Analysis and Design Language)

 Textual and graphic notation with precise semantics to model applications and execution platforms

 Example: airplane’s subsystems (sensors, processes, buses, etc)

 Models tested against predefined qualifiers  Language used as a unifier in transferring models in communication  Companies interested:

 Rockwell Collins  Boeing  Honeywell  Lockheed Martin  and others

 SEI Open Source AADL Tool Environment (OSATE)

 Major program used to develop AADL models  A few weaknesses

2

 Few development environments available  Low entry-cost (Open source software)  Eclipse based (Java)  Eclipse Modeling Framework (EMF)

 Visual representation of models  Unified modeling method

3

 Application of model persistence

 For alleviating modeling tool burdens  For creation of meaningfully sized models for simulation

 Storage of EMF models

 Import large models  Retrieve relevant, but smaller sections of data

 Dynamic model testing

 Arbitrarily large  Multiple layers of abstraction

4

 Model Generator

 Accept model parameters/constraints and output AADL model conforming to the parameters  System must be extendable so future developers can easily add new parameters to the system

 XML:DB Adapter

 Store XML representations of AADL models in an XML database  Allow user to query the model on a per-object basis

5

 Model Generator

 Console based user-interface with a focus on scripting for future use as a testing tool  Plug-in for OSATE

 XML Adapter

 BaseX wrapper for use with connecting to a BaseX XML database  Code based means for inserting and retrieving individual objects that have been stored externally

6

7

8

 Model Generator uses two interfaces

 Command line interface for scripting purposes  OSATE plugin

 XML:DB Adapter

 None

9

 Model Generator command line interface:

10

Model Generator –

1.

Develop a static model generator that produces AAXL output

2.

Extend the static model generator to handle dynamic model generation

3.

Create a console that allows parameters to be input from the user to control the dynamic model generation

4.

Experiment with dynamically generating models larger than memory XML:DB Adapter –

1.

Experiment with BaseX and understand its limitations in terms of performance and features

2.

Build a wrapper for BaseX in Java to insert XML files into database and to perform XPath (1.0) queries

3.

Generate EMF models for testing from java annotated code

4.

Develop the XML:DB adapter using EMF’s persistence API and use BaseX for data storage

11

 High risk of not finishing on time

 Project was redefined twice, leaving less time to focus

• n planning and design phases

 Making improvements to existing software, some of which is not mature  Two subgroups meant the loss of a team member would have more drastic effect due to more specialization between the two subgroups  Evolving requirements, unsure if new project is feasible

12

 Pass in constraints/properties of the model  Create tree representation of the model using

EMF/OSATE components in memory

 Output memory representation to AAXL text,

which can be converted by OSATE into AADL text and EMF diagram

 Extensible structure to allow new AADL

components and tree structures to be added later

14

 Implement EMF Estore and other interfaces to

allow per-object queries

 Validate user-provided URI and do conversion if

necessary between two supported standards (EMF or OSATE’s custom XPath implementation)

 Generalized for XML, but can store AAXL model

files as they conform to XML specifications

15

 Integrated with OSATE by using its

implementations of AADL component classes

 +Reuse of existing code  +Helped make sure we used correct AADL constructs  -Restricted what we were able to do with the components

16

 Extendibility

 Created factories for different component categories  “Builder” classes to combine components from different factories –e.g. connection builder, flow builder  Ability to add more model structures and constraints later

17

 White Box Testing

 JUnit was used on logic-oriented classes

 OSATE API provides many restrictions on how components can be used  We have put our own restrictions in place to preserve model validity  Custom exceptions thrown to capture specific errors

 System Testing

 Use OSATE to convert AAXL to AADL and EMF diagram  Use OSATE to run analyses on imported diagrams to confirm validity

• f model

 Use OSATE to create “instances” of the system – a flat model based on the original model layers

18

 Handling “Dynamic” and “Generated” EMF models

 Dynamic: Create a factory from scratch to point objects to use

• ur data storage (BaseXEFactory class)

 Generated: Modify the model’s auto-generated factory and point object creation through our BaseXEObject class

 Handling the entry and retrieval of data to and from the

database through the EStore interface

 Rely on EStore‘s get() and set() methods  Create a unique key based on EClass and EStructuralFeatures to be able to query database  Serialize the object to XML and insert into database  Convert data back into a EMF object once retrieved

19

 Knowing which EMF classes/interfaces to

extend/implement

 Study EMF book and look at CDO implementation  Trial and error

 Debugger nearly impossible to use due to EMF being packaged in JAR

 How to simplify BaseX’s API

 Create a façade and use singleton pattern to handle I/O

20

 White Box Testing

 JUnit 4 used in BaseXWrapper class to test BaseX database commands

 Black Box Testing

 Used generated EMF models from java annotated code  Rewrote the generated model’s factory classes to use BaseXEStore instead of in-memory storage  Used JUnit 4 for testing dynamic model creation  Instrumented BaseXWrapper class with Java Logger to capture traces of EMF’s execution

21

 Verification

 Used BaseX’s visual interface to ensure data was correctly inserted and retrieved

22

Chaz Beck 144.5 Jason Lackore 111 Marcus Rosenow 135 Shaun Brockhoff 141

23

Fall Spring Overall Total Hours 144.5 387 531.5 XML:DB Adapter Model Generator Hours Per Component 204 183

http://www.payscale.com/research/US/Job=Software_Engi neer_/_Developer_/_Programmer/Salary

AVG Salary (per year) 57420 Work hours in Year 2080 Pay per Hour 27.60576923 Cost $14,672.47

Documentation 5% Implementation 33% Research 17% Design 23% Requirements 20% Testing 2%

24

 Lessons Learned

 Model-driven development techniques  Evolving system requirements  Integration of third-party software components  Managing a large-scale project

 Summary

25

 Mode Generator

 Generating models larger than memory  Taking advantage of XML:DB Adapter

 XML:DB Adapter

 Integrating XML:DB adapter with OSATE  Package up implementation into “market” deliverable

26

27