Dec0908 Model Generator & XML:DB Adapter

1. Faculty Advisor – Dr. Suraj Kothari Client – Jon Mathews Team Members – Chaz Beck Marcus Rosenow Shaun Brockhoff Jason Lackore Dec0908Model Generator & XML:DB Adapter

2. Importance of Project • 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

3. Why OSATE? • Few development environments available • Low entry-cost (Open source software) • Eclipse based (Java) • Eclipse Modeling Framework (EMF) • Visual representation of models • Unified modeling method

4. Problem Statement • 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

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

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

7. Concept Sketch

8. Technology Environment AADL Model Generator AADL Language OSATE Eclipse Modeling Framework Eclipse AADL XML:DB Adapter BaseX XML Database

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

10. Snapshot of User Interface • Model Generator command line interface:

11. Project Plan Model Generator – • Develop a static model generator that produces AAXL output • Extend the static model generator to handle dynamic model generation • Create a console that allows parameters to be input from the user to control the dynamic model generation • Experiment with dynamically generating models larger than memory XML:DB Adapter – • Experiment with BaseX and understand its limitations in terms of performance and features • Build a wrapper for BaseX in Java to insert XML files into database and to perform XPath (1.0) queries • Generate EMF models for testing from java annotated code • Develop the XML:DB adapter using EMF’s persistence API and use BaseX for data storage

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

13. Overall System Diagram

14. Design – Model Generator • 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

15. Design – XML:DB Adapter • 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

16. Implementation – Model Generator • 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

17. Implementation – Model Generator • 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

18. Testing – Model Generator • 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

19. Implementation – XML:DB Adapter • 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

20. Implementation – XML:DB Adapter • 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

21. Testing – XML:DB Adapter • White Box Testing • JUnit 4 used in BaseXWrapperclass 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

22. Testing – XML:DB Adapter • Verification • Used BaseX’s visual interface to ensure data was correctly inserted and retrieved

23. Man Hours/Cost http://www.payscale.com/research/US/Job=Software_Engineer_/_Developer_/_Programmer/Salary

24. Effort Breakdown

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

26. Future Work • 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

27. Questions?