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

Transcription

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

2 Table of Contents 1 Introductory Material List of Tables List of Figures List of Definitions Acknowledgement Problem/Need Statement System Description Operating Environment User Interface Description System Block Diagram Intended Users and Uses Assumptions and Limitations Market and Literature Survey 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) Constraints Risks

3 5.6 Testing Work Plan Work Breakdown Resource Requirements Project Schedule Cost Estimation

4 1 Introductory Material 1.1 List of Tables Table Name Table 1 : Group Tasks 13 Table 2 : Model Generator Tasks 13 Table 3 : XML Adapter Tasks 14 Table 4 : Project Schedule 16 Page 1.2 List of Figures Figure Name Figure 1 : System Diagram 7 Figure 2 : Project Schedule View 16 Figure 3 : Person Months and Staffing 17 Figure 4 : Work Breakdown for Project Stages 17 Page 1.3 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. 4

5 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.. ECprE Abbreviation used by Electrical and Computer Engineering College at Iowa State University. 2 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. 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. Dr. Ahmed Kamal Senior design instructor. Barry Buelow Interested party in project. 3 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 5

6 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. 4 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 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. 4.1 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. 4.2 User Interface Description 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. 6

7 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. 4.3 System Block Diagram 4.4 Intended Users and Uses Figure 1 : 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. 7

8 4.5 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. 4.6 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. 4.7 Commercialization Considerations The end product for this system will not be a fully functioning system. Meaning, the tools created will only apply to a sub-set of OSATE s functionality nor will it even fully integrate with OSATE. The tools will either be independent or only minimally integrated with OSATE. Therefore, the commercialization of the product would not be applicable. 4.8 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 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 8

9 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. 4.9 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 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. 9

10 4.9.6 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. 5 Proposed Approach The following section contains information in regards to requirements, considerations, constraints and risks of the project. 5.1 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. 5.2 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 perobject 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. 10

11 5.3 Nonfunctional Requirements (Model Generator) The system must be able to generate large models incrementally without using large amounts of computer memory (e.g. generate a model larger than system RAM but not use all system RAM in the process) 5.4 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. 5.5 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. 11

12 5.5.3 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. 5.6 Testing 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 plug-in 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 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. 12

13 6 Work Plan The following is the purposed work plan divided up into four components: work breakdown, resource requirements, project schedule, and cost estimation. The purposed approach is to divide the team input two groups with two people. One group's task is to work on the AADL model generator. The other group's task is working on the XML adapter. Both groups will participate in the group tasks as outlined below. 6.1 Work Breakdown Group Task Name Description Presentation A presentation will be given at the start of the fall semester Poster Poster shows deliverable work of project IRP Presentation Presentation given in front of Senior Design Committee Table 1 : Group Tasks Model Generator Task Name General Class Structure First Prototype Second Prototype Third Prototype Fourth Prototype Integration/ Acceptance Testing Description From the functional decomposition, the class structure will be generated Generating tree in memory Outputting tree to AADL Inserting more complex AADL constraints Implementing cross referencing Integrate prototypes into final code and perform acceptance testing Table 2 : Model Generator Tasks XML Adapter Task Name BaseX Database First Prototype Second Prototype Description A BaseX database will be setup and deployed for testing purposes for use throughout deployment Storage of simple XML data, no relevance with AADL Build simple EMF model, derive XML from model, and 13

14 Third Prototype Integration/Acceptance Testing 6.2 Resource Requirements store into database Storage of AADL model in XML database and before retrieval Integrate prototypes into final code and perform acceptance testing Table 3 : XML Adapter Tasks Eclipse IDE The Eclipse IDE will be used to work with AADL models via OSATE, especially for testing database functionality Java Development Kit The Java Development Kit (JDK) will be required for use in developing and testing this project. The kit is a free download from Database An XML database will be required for testing the XML adapter. Currently the choice for this database is BaseX which is an open-source database that is free to use and obtain An system is needed to be used for communication between the members of the team. ECprE College has provided a free address dec0908@iastate.edu for use 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 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. 14

15 6.2.8 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. ECprE College has provided a server running GForge, software that can manage and deploy subversion repositories. A repository has been setup for the team Issue Tracking Issue tracking software is needed to track bugs that pop up in the software. GForge offers a tracker tool for capturing bugs. This service has been integrated with the subversion server Room Locations This team has between one to two weekly meetings per week. A room is required for these meetings Testing Resources To satisfy the before mentioned testing requirements, the following software resources are available to our team: junit, Abbott and Costello, FEST, djunit, and Metrics plug-in. Our testing resources must be open-source and available for free Test/Database Computer [optional] Our project may require a moderately powerful computer with approximately 2GB memory for our test environment for the BaseX database. The database can be run from the tester's computer as well. This option won't be explored until complications arise from running the database from the tester's computer E-books [optional] Some material about AADL or EMF is only readable after paying a certain fee and then downloading an E-book (in PDF form) for reading. 6.3 Project Schedule The schedule for the fall semester is below. The question mark by the date shows that the date is tentative and can be adjusted. Please refer to section 6.1 for more details about each task. Group Tasks Beginning Fall Semester Presentation 10 days Mon 8/24/09 Fri 9/4/09 Poster and IRP Presentation 10 days Mon 11/23/09 Fri 12/4/09 XML Adapter 15

16 Setup and Deploy BaseX Database 10 days? Mon 8/24/09 Fri 9/4/09 First Prototype 10 days? Mon 9/7/09 Fri 9/18/09 Second Prototype 15 days? Mon 9/21/09 Fri 10/9/09 Third Prototype 20 days? Mon 10/12/09 Fri 11/6/09 Integration/Acceptance Testing 20 days Mon 11/9/09 Fri 12/4/09 Model Generator Develop General Structure 10 days? Mon 8/24/09 Fri 9/4/09 First Prototype 10 days? Mon 9/7/09 Fri 9/18/09 Second Prototype 20 days? Mon 9/21/09 Fri 10/16/09 Third Prototype 10 days? Mon 10/19/09 Fri 10/30/09 Fourth Prototype 10 days? Mon 11/2/09 Fri 11/13/09 Integration/Acceptance Testing 15 days Mon 11/16/09 Fri 12/4/09 Table 4 : Project Schedule Note: the graph was generated from Microsoft Project 2007 Figure 2 : Project Schedule View 16

17 6.4 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 Material Costs Material Name Cost Provider Eclipse IDE $0 Java $0 Development Environment OSATE $0 BaseX $0 17

18 Testing Plug-ins $0 junit: Metrics: djunit: Subversion $0 ECprE: Issue Tracking $0 ECprE: $0 ECprE: Meeting Locations Computer (no monitor) $0 ECprE E-books $15-$30 Varies Optional $100 ISU Surplus: 18