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

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

3. 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 - o Attempting to understand and modify OSATE’s source code was proving to be outside the scope of the class o Further research into CDO determined that the software was not yet mature enough to depend on later in the project o New project direction is keeping with the same overall goal, without getting tangled in CDO and OSATE. 3

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

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

7. The end product is expected to be useful mostly to other developers. o 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) o 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. 7

8. Open Source XML Database o Mature enough for use o Any limitations posed by selected database will in turn pose limitations on API’s for interaction 8

9. AADL/EMF model generation tool o Used to create large models with specified parameters for use in testing XML database adapter o Lessens the burden of larger AADL models by storing “unused” segments in secondary storage 9

10. 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 o 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

11. AADL Model Generator o There are already model/graph generators in existence, but none yet for AADL o Will follow a similar approach to other model generators...but with additional constraints to ensure the model conforms to AADL o We plan to start with some static (but interesting) models to test specific access patterns o We will eventually work up to very granular controls to combine many different attributes and constraints in an adaptable way 11

12. 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 occur. 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 out 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. 13

14. 14

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

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

17. Parameter Parser o Check the validity of each individual parameter and pass to the model constraint builder Model constraint builder o Combine different constraints into one unified constraint, like a query o It is important that parameters cannot contradict one another, so check the validity of the combination parameters given 17

18. Abstract Constraint o In order for the system to be extendable all constraints will need to fall under a similar structure o Constraints will modify the existing attributes of the system in some way, or create new ones 18

19. Model Builder o Take individual components and combine them in meaningful ways o Must follow rules of AADL, particularly concerning component hierarchies Component Factory o Generate individual components based on constraints on demand o Return the components to the model builder for use in the overall system 19

20. AADL Output Generator o Take the model represented in memory and output it to AADL text o Use constraints to break up the model into resources as required Model Validation o Check the completed model to ensure it conforms to AADL standards o Use in testing stage of the project 20

21. Input o Take in a set of parameters and their values(as seen in the next slide) o Not all parameters are required, some parameters have default values Output o Valid AADL Model with attributes based on parameters given o Model will NOT represent an actual system 21

22. 22

23. Using a command line interface with switches to control parameters for model generation. o Will make it easier to extend and plug in new model constraints o With no GUI, new developer needs only to develop the logic for the new parameters and not worry about updating any graphical elements 23

24. Model Generator will be written in Java using the Eclipse development environment o 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

25. Black box testing methods for the interface o Random input o Boundary testing o 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

26. Several prototypes o Increasing complexity o Increasing size o For major features Example o Prototype 1: Generating tree in memory o Prototype 2: Outputting tree to AADL o Prototype 3: Inserting more complex AADL constraints o Prototype 4: Implementing cross referencing 26

27. 27

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

29. OSATE suffers from limitations from using “standard” EMF model Fix = Implement EStore interface to allow different storage models 29

30. Storage of AADL models in XML database o XML:DB adapter  AADL importer  Individual object retrieval o URI validation/conversion 30

31. Initial storage of AADL handled by importer Subsequent requests from the database are handled on a per-object basis o URI indicates the specific object to retrieve o URI between XML database and EMF converted as needed An open source XML database such as BaseX that targets “XML:DB API” o Other Options [fallbacks]  Target XQuery or DOM enabled open source XML databases 31

32. Input o Initially, an AADL model in AADL XML format o URIs for individual objects within a model o Address\Path to XML database  Authentication to database Output o EMF objects corresponding to URI input o A valid URI in respect to URI validation/conversion 32

33. Integrated into OSATE workspace o 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

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

35. Setup XML database for integration testing o Start with one database, switch out or add additional XML database depending on time constraints and encountering difficulties Unit testing [jUnit 4] o Black box testing and acceptance testing  Testing database path  Testing various XML files o 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

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

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

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

39. 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. 40

41. 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 object located on the Internet, computer file system, in a document, etc.. 41

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

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

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