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

2.  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

3.  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

4.  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

5.  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

6.  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. 7

8. 8

9.  Model Generator uses two interfaces  Command line interface for scripting purposes  OSATE plugin  XML:DB Adapter  None 9

10.  Model Generator command line interface: 10

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

12.  High risk of not finishing on time  Project was redefined twice, leaving less time to focus on 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

14.  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

15.  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

16.  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

17.  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

18.  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 of model  Use OSATE to create “instances” of the system – a flat model based on the original model layers 18

19.  Handling “Dynamic” and “Generated” EMF models  Dynamic: Create a factory from scratch to point objects to use our 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

20.  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

21.  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

22.  Verification  Used BaseX’s visual interface to ensure data was correctly inserted and retrieved 22

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

24. 24

25.  Lessons Learned  Model-driven development techniques  Evolving system requirements  Integration of third-party software components  Managing a large-scale project  Summary 25

26.  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. 27