Design Review Client: Jon Mathews, EnSoft Advisor: Dr. Suraj Kothari, ECprE Team Members Chaz Beck Shaun Brockhoff Jason Lackore Marcus Rosenow
• 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
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
• 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. 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
• 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
• 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
• 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
• 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
• 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
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 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
• 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
• 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
• 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
• 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
• 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
• 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
• 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
• 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
• 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
• 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 o XML:DB adapter AADL importer Individual object retrieval o URI validation/conversion 30
• 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
• 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
• 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
• 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
Recommend
More recommend
