Final Report. Dec09-08: SAE AADL Simulation and Modeling Tools. Chaz Beck Marcus Rosenow Shaun Brockhoff Jason Lackore

Transcription

1 Final Report Dec09-08: SAE AADL Simulation and Modeling Tools Chaz Beck Marcus Rosenow Shaun Brockhoff Jason Lackore 5/3/2009

2 Foreword This document is to display all the documentation generated over the course of this project, starting in January 2009 and ending December This project has gone through three major revisions involving the purpose of the project and two different clients. This report only documents the last project revision. Contained within this revision, several smaller revisions were made to change the scope of the project which is visible moving linearly through the report. Requirements remained mostly same but the deliverables and features of the project were tweaked to adjust to the smaller time frame allocated for the project and for technical difficulties faced. We, as a team, would like to thank our advisor, Dr. Suraj Kothari, for providing guidance during the life of the project. We are extremely thankful for your time and mentoring, especially the times you went out of your way helping us during critical moments in the planning and design phases. Without your guidance this project would had been a complete failure from the start. Also a special thanks is deserved by our client, Jon Matthews. A great appreciation is felt by each team member for becoming our client when we lacked one and for lending your technical knowledge to our disposal. This knowledge shared was indispensible for helping us achieve our goals and help all of us gain a deeper understanding of Eclipse, EMF, AADL, and OSATE. Hopefully this project will have some usefulness for you in the days ahead. 2

3 Table of Contents 1 Project Plan Introductory Material List of Definitions Acknowledgement Problem/Need Statement System Description Operating Environment Technology Environment User Interface Description System Block Diagram Intended Users and Uses Assumptions and Limitations Market and Literature Survey Intellectual Considerations Commercialization Considerations Security Considerations Expected End Product and other Deliverables Proposed Approach Functional Requirements (Model Generator) Functional Requirements (XML:DB Adapter) Nonfunctional Requirements (Model Generator)

4 1.21 Constraints Risks Testing Original Work Plan Work Breakdown & Schedule Resource Requirements Cost Estimation Design Model Generator Functional Decomposition System Analysis Model Generation Tool Detail Design User Interface Software Specification Testing Specification Prototyping XML:DB Adapter Functional Decomposition System Analysis XML:DB Detail Design Input and Output Specification User Interface Software Specification Testing Specification Prototyping Implementation

5 3.1 Model Generator XML:DB Adapter Testing Model Generator XML:DB Adapter Project Plan Model Generator XML:DB Adapter Effort and Resources Hours Spent By Each Team Member Hours per Semester Hours per Component Cost Time Allocation Material Resources Conclusion Appendix AADL Component Hierarchy (partial)

6 1 Project Plan 1.1 Introductory Material List of Figures Figure 1 : Technology Layers Figure 5: System Block Diagram Figure 6: Command-Line GUI Figure 7: Preference Window - Eclipse Figure 8: OSATE Menu Figure 9: Overall System Diagram List of Definitions 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 plugins EMF Eclipse Modeling Framework; A framework for creating models in the Eclipse environment OSATE Open Source AADL Tool Environment; Plugin 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 Acknowledgement Special acknowledgement must be given to the following individuals for their assistance in this project. Without their help and guidance, this project could not be possible. Thanks to their generous efforts, our team has the tools needed to achieve a successful project. 6

7 Jon Mathews Client, currently working at EnSoft. Jon is assisting Rockwell to correct performance problems with AADL to help incorporate larger models for aircraft systems. Dr. Suraj Kothari Faculty advisor, professor at Iowa State University. Dr. Kothari drafted the project statement with help of Jon Mathews for this project. Jason Boyd Senior design course/lab coordinator for 491. Dr. Ahmed Kamal Senior design instructor for 491. Barry Buelow Interested party in project. Dr. Daji Qiao Senior design instructor for 492. Dr. Manimaran Govindarasu Supervisor of senior design course. 1.4 Problem/Need Statement Model based development is becoming more prevalent every day. As more companies move to the model based design paradigm, it becomes necessary to allow for larger and more complex models to be supported. One of the tools used to create and edit models of complex systems is the Open Source AADL Tool Environment (OSATE). While OSATE works well with reasonably sized models, there are limitations that keep OSATE from running efficiently once the models grow too large. Models opened in OSATE are stored entirely in main memory. As models grow to several gigabytes in size, the computer is slowed to a standstill while main memory and the hard drive swap file are thrashing. The overarching goal for this project is to address the problem of scalability of models by developing methods for storing and accessing models in a database. In general, AADL models can be represented as large graphs. This project has been divided into two sub-projects. The first, the AADL model generator, will provide useful test cases for use in other projects. The other, an XML:DB adapter for AADL will be the first step towards creating a database-enabled OSATE. While this project will not become entangled in modifying OSATE s source code, it is intended to provide a framework for being integrated into OSATE. Integration with OSATE is outside of the project. 1.5 System Description Our system will involve a number of different components. The central components of the system are AADL and OSATE. AADL is the language used to describe and specify models. In the current system implementation, the entire model is stored in main 7

8 memory. In the finished system, the model will be stored in a database and only parts of the model will be brought into main memory at different times. The system will be divided into two sub-systems, an AADL model generator, and an XML:DB adapter. The sub-systems will not be integrated, however data from the model generator will be used in testing the XML:DB adapter. The AADL model generator will take parameters from the user that define variables of the system and will output AADL text. OSATE will then be able to convert the text to other formats, such as XML or TOPCASED graphical notation. The XML:DB adapter will take AADL represented in an XML file and place it in a database. The adapter will also be responsible for converting URIs and providing a way to query the model on a per-object basis. Some of the functionality will be similar to CDO, particularly the way resources are handled. For this purpose, CDO may still be used as a reference tool, but is no longer part of the system. 1.6 Operating Environment The end product will run on the Java Virtual Machine (JVM). With the use of the JVM, the product will be portable to platforms that are supported by the JVM, Eclipse, and OSATE which includes, but is not limited to, Microsoft Windows, Apple Mac OS, and various Linux distributions. 8

9 1.7 Technology Environment 1.8 User Interface Description Figure 1 : Technology Layers Since our tool will be built on top of a working distribution of OSATE, our product will use Eclipse s user interface. Elements may be added to the Eclipse user interface for our tool to operate, but the specific details for these additions are not known at this time. The model generator will run on the command line with several switches to input parameters. These parameters will be used to specify the attributes the model will be generated with. 9

10 1.9 System Block Diagram 1.10 Intended Users and Uses Figure 2: System Diagram The following describes the end users and the intended uses for this project End Users The end product is expected to be useful mostly to other developers and eventually OSATE users who are working with very large models. The users who are utilizing the XML adapter will not likely interact with it directly. The model generator will be used directly by developers Intended Uses This XML adapter is meant to store large AADL models in a database. This is to reduce the memory overhead. Therefore this would be used by any user interested in persistently containing these large models. The model generator is intended to be used by other developers to generate large test cases for use in their own development. The model generator will also be used to generate test cases for the XML adapter to use in its testing phase. 10

11 1.11 Assumptions and Limitations OSATE may not be designed to wait for a model to be fetched from a database and be brought into memory. Unexpected errors may be encountered because of this The purpose of the project is NOT to integrate our tools with OSATE. Rather it is to provide a framework which can be integrated into OSATE later Our project will depend on an open source XML database being mature enough for use, at least for basic functionality; that is, Select, Insert, Update, Delete. Any limitations in the database will limit the functionality of the adapter and its API Market and Literature Survey OSATE currently has no first or third party solution to the problem at hand, namely storing AADL models in database, and by extension, limits the size of the models handled by OSATE. However, solutions similar to ours proposed in this document, specifically through the use of a database, have been mentioned by other higher education institutions but no official documentation or implementation can be found. Dr. Kothari, this project s faculty advisor, has stated numerous times that parties such as The Boeing Company and Rockwell Collins, Inc. would be interested in possible solutions to the memory management problem currently found in OSATE. Specifically, any performance analysis would be beneficial to the previously mentioned parties Intellectual Considerations The adaptor will be built upon various open source intellectual properties including Eclipse and OSATE. It is worth noting that the end product s reliability is partially dependent upon the reliability of the previously mentioned open source software Commercialization Considerations Due to the open source nature of the underlying architecture and solution we are to create, commercialization of our system on any level, save the possibility of product support, is not possible. However, given the scope being restricted to our stay at Iowa State University not even product support will be commercialized Security Considerations The major security consideration for the project is collaboration between team members. A Subversion server is setup to be used in this project. Restriction has been 11

12 placed to allow only team members to edit and change the project s source code. Currently, this project s source code is open to the public for viewing but this can be turned off at the client s request. Also, because the source code will reside on each team member s computer for development when they checkout from the Subversion server, it is the responsibility of each member on the team to secure their computer against unauthorized access and malware infecting the project s source code. If these protection mechanisms are not put in place, a team member could unknowingly infect or cause unauthorized tampering to the project which could theoretically ruin the project if committed back to the Subversion server Expected End Product and other Deliverables At the end of this project these deliverables will be available to the client via download from this team s website, Note: At the client s request the material may be taken off the website and uploaded to another data source for the client to obtain completed work AADL Model Generator The AADL model generator will take in a set of parameters and output an AADL model with attributes that correspond to the parameters input by the user. Some of these parameters may include the total number of components, the makeup of these components, the max depth of the graph, and many others XML:DB Adapter The XML:DB adapter will take an AADL model in its XML form and store it in an XML database. The adapter must allow a user to query the model on a per object, rather than a per resource, basis. The adapter will be required to validate and convert the URIs used in the lookup process Large AADL Models For testing purposes, large AADL models will be created to validate the functionality of the XML adapter and acceptance of the system. These models won t model any real world system but will only act as large memory consumers. A large model will constitute as a model that causes thrashing on a computer with 2 GB of available memory. Smaller AADL models may also be created for testing and be available to the client for testing Design Report A text document much like the project plan composing of the system design, detailed design, and software design to aid in creation of other deliverables. 12

13 Poster The poster is a reflection of the work completed by this senior design team and will include snapshots of the team s code and product along with hours worked, money spent, and summary of project Presentations Various presentations will be given by the project team such as the draft plan, 2nd semester presentation, and the IRP presentation in front of the design committee Example Database A database will be created to hold AADL models. The database will be an open source XML database, tentatively BaseX Proposed Approach The following section contains information in regards to requirements, considerations, constraints and risks of the project Functional Requirements (Model Generator) The system must take in parameters and output an AADL model that conforms to the parameters provided The system must be extendable, that is, allow a developer to easily add new parameter types to the model generator Functional Requirements (XML:DB Adapter) 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 The system must provide object retrieval support for both OSATE and EMF uniform resource identifier syntax. The EMF URI syntax is XPath whereas OSATE uses an XPath-like specification. Regardless, the system will allow for both retrieval paths, OSATE s or EMF s, without extra effort for the user. 13

14 1.20 Nonfunctional Requirements (Model Generator) The system must be able to generate large models incrementally without using large amounts of computer memory 1.21 Constraints Time This project and all its deliverables must be completed by December 19 th and be uploaded to this project s website. This project will consist of two school semesters, the first dedicated mostly to documentation and the second dedicated to implementation. As this is the third iteration of the project, there was less time able to be spent on the design of the system. Also, the structure of the senior design course forces a waterfall process model constraint on the project where detailed design is created before implementation Database Due to limited budget, commercial databases will be sparingly used if at all and instead open-source databases will be used in its place Software Limitations and constraints may be created from OSATE or the database that we choose. We will be mindful of OSATE s system and the overall goal but also remember that the XML:DB adapter and model generation tool are standalone systems Risks 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. 14

15 Finishing the project on time (Medium) This project has gone through multiple iterations. This has been useful for ruling out what is feasible and what is not. However, the delay caused by changing the scope of the project has affected the amount of time allotted for the design phase Testing Due to the focus of the project, namely OSATE s handling of large models, testing will have to be with large test data making comparison testing more difficult. However, the models we create for testing do not need to be sophisticated or even meaningful. All that is required is a large enough model to simulate the problem and show that our solution works. Performance testing will also be conducted to measure our solution compared to the working version of OSATE. Our project s goal is to create another solution to the problem, not necessarily optimal. Therefore, weighing it against other implementations is a secondary if not tertiary objective Original Work Plan The following is the purposed work plan divided up into four components: work breakdown, resource requirements, project schedule, and cost estimation. Collectively as a team each of us will participate in every milestone and contribute to the project Work Breakdown & Schedule The following tasks represent various milestones in the project: 15

16 Model Generator M1. Develop a static model generator that produces AAXL output (4 weeks) M2. Extend the static model generator to handle dynamic model generation (4 weeks) M3. Create a console that allows parameters to be input from the user to control the dynamic model generation (2 weeks) M4. Experiment with dynamically generating models larger than memory (2 weeks) XML:DB Adapter M1. Experiment with BaseX and understand its limitations in terms of performance and features (2 weeks) M2. Build a wrapper for BaseX in Java to insert XML files into database and to perform XPath (1.0) queries (4 weeks) M3. Generate EMF models for testing from java annotated code (2 weeks) M4. Develop the XML:DB adapter using EMF s persistence API and use BaseX for data storage (4 weeks) 1.26 Resource Requirements Eclipse IDE The Eclipse IDE will be used to work with AADL models via OSATE, especially for testing database functionality Faculty Advisor and Client This team s faculty advisor and client are instrumental in providing an initial direction for the project. They will be a reliable source of getting clarification and defining certain aspects that will aid in the design and implementation AADL Documentation Documentation on AADL semantics is essential if the team seeks to fully understand the AADL language. Carnegie Mellon is the primary source of information about AADL. 16

17 Money A sum of one-hundred and twenty dollars is available to the team for use with this project. This amount may be used to purchase materials such as posters, software, hardware, or documentation Subversion Server Source control is needed for the team to allow collaboration between team members. It also provides a reliable backup mechanism for the team in case a member experiences software or hardware loss of their computer Room Locations This team has between one to two weekly meetings per week. A room is required for these meetings. Currently our team has available Coover 3132 on Thursdays at 4 p.m. and also the ALC South West corner on Tuesdays at 4 p.m. Meetings normally last an hour Testing Resources To satisfy the before mentioned testing requirements, the following software resources are available to our team: Bugzilla, junit, Abbott and Costello, FEST, djunit, dbunit, and Metrics plug-in. Our testing resources must be open-source and available for free Cost Estimation Tool COCOMO 2 will be used to help plan the costs of the project relating to the man hours required to complete the project Test/Database Computer Our project will require a moderately powerful computer with approximately 2GB memory for our test environment. 17

18 1.27 Cost Estimation Figure 3: Person Months and Staffing Figure 4: Work Breakdown for Project Stages Figure 2 and 3 above were both obtained using the COCOMO II model of early development. It gives a rough estimate on the amount of time needed to complete the project. According to the model, it would take 23.5 person months to complete this project with its current scope. 2 Design 2.1 Model Generator Functional Decomposition Parameter Parser The parameter parser will take the input from the command line and validate each individual constraint on the system. If any of the parameters are invalid, this is the 18

19 module that will either abort the program with an appropriate error or notify the user the parameter is invalid and proceed with a default value for the parameter. The action taken will vary on the type of parameter Model Constraint Builder The model constraint builder module of the system will take individual parameters from the parser and combine the individual constraints into one unified constraint. This unified constraint could be thought of as a query much as one would query a database; however, this query would be to another module of the system responsible for generating dynamic content based on the query. It is important in this module that all the parameters as a whole are checked for validity, especially in the case that some parameters may contradict each other. In this stage, the program may be aborted due to invalid combinations of parameters, or it may also be able to use the parameter with the highest priority (i.e. the constraint defined towards the end of the string of parameters) Abstract Constraint The abstract constraint will be an abstract Java class from which all constraints in the system will extend from. In order for the system to be extendable, all constraints must follow the same general structure and rules for modifying the attributes of the model. For new types of constraints, a new developer may choose to add new variables to the model and then use a more concrete constraint class to be able to specify the value of that variable upon launching the program Model Builder The model builder will receive the query from the model constraint builder component. This subsystem will arguable be the most complex and will be broken up into many classes (and possibly subsystems). It is in this module that the general algorithm for generating models (graphs) will be implemented. The model builder will use this algorithm to determine what types of components will need to be generated and where in the model they will be placed. The model builder will be required to conform to the rules of AADL, particularly concerning component hierarchies Component Factory The component factory will be able to generate individual components on demand based upon the need of the model builder subsystem. The component factory may be given some simple variables to assist in generating a component, 19

20 such as probability of certain components being generated, or a family of components to choose from (Data, Process, or other types of AADL components) AADL Output Generator The AADL output generator subsystem will take the model as represented in memory and output it to AADL text. This subsystem will be responsible for breaking up the model into different resources, or files/documents. This breakdown is important because of the way AADL objects are currently accessed (on a per resource basis). This subsystem will be used concurrently with the others. That is, the entire model will not be generated in memory, and then written to AADL text. To fulfill the non-functional requirement that the system generate this text incrementally, and thus have a reasonable memory footprint, this subsystem will be used incrementally Model Validation This subsystem will be responsible for checking the validity of the model once it is in text and other formats (OSATE will automatically convert the text to XML and graphical formats). The primary concern is making sure that the model conforms to AADL standards. Once this subsystem has been tested, it can be used to test the rest of the subsystems. 20

21 2.2 System Analysis Figure 2: System Block Diagram 21

22 2.3 Model Generation Tool Detail Design Input and Output Specification Input Take in a set of parameters and their values. Not all parameters are required. Some parameters may have default values Output Output a valid AADL model with attributes based on the parameters given. The model may not necessarily represent any real-world system. 2.4 User Interface The user interface will be a simple command line interface with switches or flags to control the parameters used in model generation. Using the command line instead of a GUI will make it easier for future developers to plug in their own parameters to the system without needing to modify any other components of the system like the GUI. Their plug-in will simply need to define the parameter type and possible values. Figure 3: Command-Line GUI 22

23 2.5 Software Specification Development Environment The AADL model generator will be written in Java using the Eclipse integrated development environment. Because of the other AADL tool in this project and other open-source AADL tools were written in Java, it only makes sense to write this tool in Java, especially if there is a chance it will be integrated into OSATE in the future Libraries At this time, we do not expect to depend on any specific libraries. 2.6 Testing Specification Testing methods Black Box Testing Black Box testing methods will be used on the console interface to test for different inputs. Random, boundary and acceptance tests will be used. White Box Testing As we have full access to the source code, the team will be able to utilize white box testing methods. The team will be able to perform more complete unit, integration and system level testing. See "Unit Testing" for more information. Metrics An available plug-in for Eclipse is called Metrics. This plug-in adds functionality that helps the tester to determine the best areas to test (i.e. high use of methods). This plugin combined with another plug-in called DjUnit will capture the testing coverage used by our unit testing. This will be used to help direct the team towards problem areas. Unit Testing Unit testing shall be used to test the specific portions of the model generator. As the team knows what the output should be when working with specific code segments, Unit testing would be the best means of making comparison tests. The testing framework being used is junit 4, this framework was chosen due to its integration with Eclipse and the familiarity the team has using it. Integration Testing 23

24 Several prototypes will be created to work through integration testing of the system. Read below for more details System Testing After integration testing, system testing will be implemented. The method used for this will likely be similar to a Big Bang method when both parts of the system are brought together, and output is measured from input. The model generator will be used as a tester for the XML:DB Adapter, which will be an excellent testing method for the generator. 2.7 Prototyping Generating tree in memory The first step in creating the model generation tool is to store the general structure of the language in memory. This will be a good test to see how large models get in memory also. The team working on the generator shall be able to utilize the debugging perspective in Eclipse to move through the tree, to check creation Outputting tree to AADL text The next step in creating the model generation tool is to generate the AADL text from the model in memory. At this point the complex constrain requirements should not be implemented, and only basic requirements should be used. The team can check the validity of this by examining the outputted file. The file could also be imported into OSATE to visually inspect the model Inserting more complex AADL constraints The next iteration would be to implement the remaining complex constraints and requirements into the system, so that the resulting models fully support the AADL standard. This, again, will be done by examining the output files, and by examining the model after loading the files into OSATE Implementing cross-referencing A fairly complex feature to implement into the model generator is the crossreferencing functionality of AADL. When the language is interpreted the calls are then traversed. Creating a model that accurately makes use of this functionality could be difficult, hence its separate step. 24

25 2.7.5 Model Validation Tool Finally the model validation tool should be implemented, for thorough testing of the abstract constraints of the system. This tool is to automatically test the validity of the system. 2.8 XML:DB Adapter Functional Decomposition The XML:DB adapter will break down into two parts: the adapter itself and a URI validation and conversion module XML:DB adapter The adapter itself provides two key functions. The first is the ability to import AADL models, or more specifically the AAXL version, into an XML database. From the initial import, all information retrieved from the AAXL model will be on a perobject basis. The object retrieval is completed via the URI associated with all the objects within the AAXL file itself. Given that the XML database choice allows for querying based on similar, if not identical, formats to that of the URI, the retrieval process is greatly simplified URI validation/conversion Mentioned above in section 7.3.1, all AADL model objects have a unique URI that will be influential in the efficient retrieval from the database. Currently, two possible URI options are within OSATE itself, namely, XPath and OSATE s own XPath based URI format. The specific URI format is for a given AADL model is based on a user option in the OSATE preference since version The BaseX database, has the option for querying based on an XPath query string. Based on the knowledge that OSATE can be implemented with XPath, but may not, and the XML database requires an XPath query, validation of all URI must be used to determine if conversion is required when not strict XPath or to find malformed URI. 2.9 System Analysis For the XML:DB adapter, the key to implementation is the use of EMF s EStore interface. Through EStore, changes to the persistence model allows for storage patterns different from that of the default functionality. Meaning, EObjects can be stored in an XML database and retrieved as objects as described in functional requirements. 25

26 2.9.1 AADL Import The actual AADL import is relatively straightforward. BaseX will be used to insert the elements, attributes, comments, etc. that will be present in the AAXL corresponding to the AADL model to store. Specifically, the keywords for inserting data using BaseX are described below. Insert database nodes. Insert a fragment or a specific node at the specified child [pos] of the specified [target] query: insert element [name] [pos] [target] Insert an element with specified tag [name] insert text [text] [pos] [target] Insert a text node with the specified [text] insert attribute [name] [value] [target] Insert an attribute with the specified [name] and [value] insert comment [text] [pos] [target] Insert a comment with the specified [text] insert pi [name[ [value] [pos] [target] Insert a processing instruction with the specified [name] and [value] insert fragment [frag] [pos] [target] Insert an XML [frag] Per-Object Retrieval Per-object retrieval is one of keys to solving some of the memory issues present in OSATE and is the basis for this project. Currently, OSATE loads whole resources at a time due to the design limitation present in EMF. These resources consist of the many objects that may or may not be accessed in local clusters. Meaning, objects from one resource may reference only one object from another. If this second resource is large then memory is wasted loading the entire set, thus loading by the object needed is the solution. For example, an XPath query to find the titles of all books with price attribute greater than 35 would be: /bookstore/book[price > 35]/title 26

27 2.9.3 URI Validation/Conversion The URI validation and conversion from OSATE URI and XPath URI used in the XML database will be implemented similar to EMF s URI converter interface, URIConverter. However, since URIConverter was implemented for use with known sets of URI to convert and we will be converting a much larger set of URI the use of the standard interface will not be ideal. For this project, the normalized, or converted, form will be that of an XPath URI used by the database. Ideally, no conversion would be necessary. However, since OSATE did not have the option for saving AADL models with XPath URI until recently the ability to convert non-standard URI from OSATE to one usable by the database XML Database: BaseX The XML database implementation used for this project will be the open source BaseX. BaseX, while being one of the few XML databases with recent updates, has all the of required traits for this project. First, it supports the XML:DB API. Meaning, its implementation goal is to be language agnostic so far as to not require an object oriented language. Second, it supports querying based on an XPath expression. This is vital to keeping the URI conversion as simple as possible. The risk involved in using this, or any open source XML database, is the question of whether it is mature enough for our use and it will be able to handle the large sets of data we will be storing with the end product. However, so long as the data can be stored and retrieved in a reasonable amount of time, the BaseX database will be used for this project XML:DB Detail Design 2.11 Input and Output Specification Input AADL Model For importation into the XML database, an AAXL version of the AADL model will be required. The path to the model will be provided by the user, and the path specified by the user must allow read access for retrieval. URIs of components in AADL model 27

28 To query the XML database for an AADL model a URI is required for lookup. The URI may be based on XPath's specification or OSATE's XPath-like specifications. URL to XML Database The address to the XML database must be provided to the adapter for use in importing the model to the database and performing queries of the database. The address must use the URL standard which is a subset of URI. The database may be located on a separate machine or the current machine used by the user and the URL must account for this, such as or file://. Connection String to Database Instead of specifying a URL to an XML database, an ODBC connection string may be entered by the user to specify the URL of the database plus additional attributes of the database such as login credentials and database table. Any other attributes required by BaseX can be entered as well Output EMF Objects An EMF object corresponding to the URI specified from the input. The structure of the object will be dependent on the initial AADL model. Notification Messages Notification messages may be sent to the user during certain times of execution such as a message stating, "successful AADL model import into the database". Also, the user will be notified of any errors that occur during execution such as a lost connection to the database. 28

29 2.12 User Interface Database URL entry Figure 4: Preference Window - Eclipse Inside Eclipse's menu bar, a preference window is present under Window > Preferences. Inside this window, a heading exists for OSATE on the left side of figure 4. Inside OSATE's panel a label and a textbox will be created to allow a the user to enter a URL to the XML database (label's purpose is to tell the user what the textbox's purpose is). When the user clicks "Apply" or "OK" the settings will be saved for the adapter to use. If time does not permit in the project for this type of integration, the same ability will be provided through a command line interface that will allow the user to enter the URL to the database and any other connection parameters. This information will be saved for the XML adapter to use. 29

30 Insertion of Model into Database Figure 5: OSATE Menu Inserting an AAXL version of an AADL model will available either through OSATE's menu inside Eclipse or by right-clicking the AAXL file and selecting "Import model into XML Database". If time does not permit this type of integration, then a command line interface will be available for the same purpose. Querying Model Querying the model with be available either through OSATE directly or by a command line based tool. If OSATE is used, the model can be viewed through Eclipse's EMF viewer. If the command line tool is used, the output from the query will be displayed in its XML format inside the command prompt Software Specification Adapter The XML:DB adapter will be written in Java using the Eclipse integrated development environment. Because the other component of this project and 30

31 other open-source AADL projects have been written in Java, it was a nature choice for this component as well User Interface The user interface will use OSATE's and Eclipse's environment for displaying to the user. Because of this, Eclipse's PDE (Plug-in Development Environment) will be used in developing this component. This API is written in Java and uses a plugin.xml file for hook in with Eclipse. Action listeners will be created to watch for user input and take proper action when fired. OSATE has its own plug-in environment which may be used as well, but at this time it is unknown if this environment will be used or the action listeners will be directly inserted into OSATE's source code to make use of its menus EMF and EStore interface The EMF framework and the EStore interface will be used in implementing the use of persistent storage of AADL models. A sample code stub for the EStore interface is provided in the appendix Testing Specification Testing methods Integration Testing A BaseX database will be setup on a local computer for use in integration testing. If time permits, additional XML databases that support XML:DB API will be deployed as well for testing purposes. Black Box Testing Various black box testing methods will be used in testing different URLs to the XML database. Also, various AADL models will be tested for importation into the database and querying. An automated GUI testing framework such as Abbot and Costello or FEST will be used for automating the black box testing by entering information into the GUI. White Box Testing For the adapter, white box testing methods will be deployed to perform unit testing on this component's code logic. The URI conversion/validation component will also be tested for handling different equivalence classes devised by the use cases generated by the team. Unit Testing 31

32 The unit testing is broken up into the black box and white box testing methods above. The framework used for testing is JUnit 4 for its integration into Eclipse and the team's experience using it. Use cases will be devised to develop the unit testing for the project. Results from the unit testing will be uploaded to the team's SVN server and any bugs created will be reported on the team's issue tracking software which has been integrated with the SVN server. Acceptance Testing This testing will be conducted by the team and by the client. The Model Generator tool (from this project) will provide AADL models for upload into the database. The perobject retrieval from the database will be tested by the client to ensure the required functional requirements have been met Prototyping The project will be using prototyping to ease into the complexity of the end product. Each step, described below, incrementally adds the functionality of the end product while providing a bed for simple testing of the program design during implementation Storage of Simple XML The simplest case to study/implement is to store mundane XML data in the database and retrieve info from stored data. This prototype specifically determines whether the XML database choice is mature enough for our needs. These needs include information retrieval using XPath and storing large amounts of data. The efficiency of retrieval, specifically the read speed, is not necessarily a factor that could make or break the database option but will be accessed during this prototype Storage of XML based on EMF model The next prototype will involve storing EML based models in XML form. Since OSATE models are EMF based, this evolution both tests that real world EMF examples can be stored with our tool and acts as a stepping stone from which the final product will be built. This prototype will also include the framework for the URL validation module Storage of complex AADL model This final prototype will be very close in functionality as the final product. It specifically targets the storage of AADL, potentially created by the generator, and retrieval thereof. With the storage of AADL models comes the URI branching 32

33 depending of the model type. Therefore, the conversion module will also be implemented during this iteration. 3 Implementation 3.1 Model Generator Integrated with OSATE by using their API and components to generate and output the model. Doing this allowed the team to more easily follow AADL syntax and make good reuse of code. Using the OSATE component implementation also provided some limitations about what could be done with the components. Some of the problems that were encountered during implementation were trying to make our framework more abstract and extendable. Because of AADLs rigid syntactical requirements, we were forced in many places in the code to provide specific details and class types rather than being able to generalize. In this regard, it would have been helpful to define our own component classes. To help overcome this problem, we created a number of factory and builder classes all of which were created from the same set of abstract classes and implemented it in such a way that future implementations of the components must adhere to providing certain services and functionality. In this way, future extensions to the framework will preserve its original integrity. 3.2 XML:DB Adapter The BaseXWrapper was created to wrap around the BaseX APIs. This allowed for all the database connection and querying logic to be removed from the main implementation code for retrieving and recreating the objects once queried. This also allowed the BaseX API to be simplified using the façade design pattern and gives more management capabilities to the developer. The URI converter implemented the URIConverter interface for normalizing the AADL URI to allow for XPath queries. The normalization was fairly straight forward as the format for referencing objects in an AADL file is similar, if not based on, the format of XPath. Therefore, the normalization required simple searches for common delimiters 33

34 within the OSATE formatting and replacing them, or inserting extra syntax, to make them conform to XPath URI standards. The XML:DB Adapter was required to be able to handle both dynamic (created at runtime) and generated (created by annotated Java, UML, XML) EMF models. This was accomplished by creating a factory, BaseXEFactory, and having dynamic models use this factory for EObject creation. For generated models the process is more complicated. In the.genmodel, a parameter must be set to use the BaseXEObjectImpl instead of EObjectImpl. Also the generated model s factories would need to be modified by renaming the create method to creategen and adding a new create method that directed object persistence to the BaseXEStoreImpl class. This new create would be very similar to BaseXEFactory s create() method. BaseXEObjectImpl and BaseXEStoreImpl required no modification to handle both cases of model creation. The two main methods in BaseXEStoreImpl are get() and create().basiceobjectimpl s eget() method is delegated to use BaseXEStoreImpl s get() method for retrieval of objects out of the BaseX database. The data must first be placed in the database before use. The set() method in BaseXEStoreImpl would be the method that would allow EMF objects to be placed into the database, but its implementation was outside the scope of this project. The other important method create(), is what allows the hook-up of the EStore interface, and is used by BaseXEFactory. BaseXEObjectImpl was set to extend EStoreEObjectImpl once it was discovered that CDO performed the same inheritance. This allows the amount of code in BaseXEObjectImpl to be significantly reduced because it was originally planned to implement all the methods required of EObjects. 34

35 Figure 6: Overall System Diagram 4 Testing 4.1 Model Generator White Box Testing JUnit testing 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 EMF models were used for testing the AADL-XML Adapter implementation 35

36 4.1.3 Testing Results Most bugs were identified in system testing Boundary/fringe conditions and necessary guards identified during white box testing Figure 10: AADL flow analysis 4.2 XML:DB Adapter 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 inmemory storage Used JUnit 4 for testing dynamic model creation Instrumented BaseXWrapper class with Java Logger to capture traces of EMF s execution 36

37 Figure 11: XML:DB Testing Interface 5 Project Plan This is the final draft of the project plan that was used during the implementation phase of the project. Some of this material may overlap with previous reports but for the most part, some changes were made to better accomplish the project s goals and to hopefully create a more mature implementation. The idea behind this project s plan was to create clear and concise deliverables that were both attainable but reflected true milestones within the project. Some comments and reflections were left for each phase. 5.1 Model Generator Develop a static model generator that produces AAXL output This is where most of the time was spent learning how to use the OSATE API for how components are created and connected to make sure the syntax is followed. Using the OSATE API rather than generating our own components was ultimately a good idea, as the syntax is rather strict and the API prevented us from using the syntax incorrectly. 37

38 5.1.2 Extended the static model generator to handle dynamic model generation Once the team learned how to interact with the OSATE API, changing the model generator to generate models dynamically because an easier task. We did run into some limitations with the OSATE API that did not allow us to abstract certain components out as much as we had planned Create a console that allows parameters to be input form the user to control the dynamic model generation The console input method turned out to be problematic, and error reports were not helpful. After much trial and error, the command line input for the model generator was created. Unfortunately a way to output help and other forms of output was not found at the time of this report. The command line input will have to be refined, but as it stands it will perform its function Experiment with dynamically generating models larger than memory We investigated generating the models larger than memory but ultimately were unable to do this, due to limitations in the OSATE program. Currently OSATE keeps a reference to everything in the model, and it is very difficult to reference only part of the model at one time in the current implementation. 5.2 XML:DB Adapter Experiment with BaseX and understand its limitations in terms of performance and features BaseX turned out to be a good choice for this project. XML databases are few and far in-between and lack widespread adaptation. Its support for XPath was the driving force for picking this database. During tests, it was found that BaseX didn t support XPath as well as we had originally hoped but a plan was developed to help escape the issues we discovered Build a wrapper for BaseX in Java to insert XML files into the BaseX database As seen in the implementation, BaseX required a lot of steps to perform a simple task. Having a wrapper around BaseX allowed traces to be collected on the use of the database which in turned provided debug information on EMF s usage. Developing the wrapper also helped gain an understanding of what BaseX provided and aided in making the code in the XML:DB adapter to be condensed. 38

39 5.2.3 Generate EMF models for testing final implementation Both dynamic and generated models were created. In the end, only the dynamic models were used. Creating the generated models helped us learn about the power EMF provides to developers, and taught us some model-driven development techniques that could be useful in our future careers Develop the XML:DB adapter using EMF s persistence API and use BaseX for data storage Even though this phase didn t fully complete as hoped. Its implementation proved to be very challenging and pushed our team into the unknown because very little information is available today about how to conduct the implementation. 6 Effort and Resources Every week throughout the life of the project, each team member were required to submit the amount of hours they spent and what deliverables of the project they worked on. This information was compiled every Monday morning into a weekly report that was sent to both our advisor and instructor in charge of the Senior Design class (CprE 491 & 492). The data shown below was aggregated from these weekly reports. 39

40 6.1 Hours Spent By Each Team Member This total reflects both Spring 2009 and Fall 2009 semester. 6.2 Hours per Semester Totals are from all four members of the project. 6.3 Hours per Component The data was compiled only from 2 nd semester. Model generator s hours were created from adding Shaun and Jason s hours together. The XML:DB Adapter was from adding Marcus and Chaz s hours. 40

41 6.4 Cost The value for AVG Salary (per year) was taken from: mmer/salary This value is the average salary of 1 st year software engineers in the United States of America. Work hours in year was calculated from taking 52 * 40, which is the number of weeks in a year multiplied by the average number of hours worked per week. AVG Salary was than divided by work hours in year to create pay per hour. Pay per hour was multiplied by the overall number of hours worked on this project, which created the final cost. 6.5 Time Allocation 6.6 Material Resources This project spent none of its budget during the course of the project. 41

42 The EMF Book ( Eclipse Modeling Framework 2 nd Edition by Dave Steinberg, Frank Budinsky, Marcelo, Paternostro, and Ed Merks), which was used extensively by the XML:DB team had already been purchased by team member Chaz Beck before the course of the project so this didn t subtract from the team s budget. Other materials for the project were freely available online for download and viewing. Please reference Resource Requirements, section 1.26, for more information on what materials were used. 7 Conclusion This senior design team started off working on an exploratory project aiming to understand AADL and model driven development using OSATE. Through three iterations of the project, the purpose has shifted to trying to extend current model-based development tools and overcome their current short comings. The focus still stayed on OSATE and AADL due to it being open-sourced and popular among the industry. Most of the team s time spent was trying to understand how to do system integration with OSATE, EMF, Eclipse, and BaseX. Many different components and APIs were involved and leveraged during the course of development. Unlike other senior design projects, where they build their project from scratch, great care was needed to ensure that new functionality added didn t break the existing code base and that the correct APIs were used to get the desired functionality. This increased the complexity of the project and involved considerable time researching. In all, this project was a great exercise in real-world software development. The team learned how to evolve a project s requirements, how to integrate existing software components which is a common practice in industry, and how to manage a large-scale project and develop an internal infrastructure to handle communication and delegation of tasks between members. As for deliverables, the team was able to successfully implement a dynamic model generator that could be used for creating AADL test models. The XML:DB adapter is near completion and will be an essential component in enabling OSATE to work with models stored in an XML database. 42

43 8 Appendix 8.1 AADL Component Hierarchy (partial) Figure 14: AADL Component Hierarchy 43