Faculty Advisor – Dr. Suraj Kothari Client – Jon Matthews Team Members – Chaz Beck Marcus Rosenow Shaun Brockhoff Jason Lackore Importance of SoftwareProject Plan Problem Statement Design Overview Test Results Conclusion White Box Testing -JUnit testing primarily on individual logic-based classes -OSATE API provides many restrictions on how components can be used – there were places that we needed to create our own restrictions to preserve model validity -Custom exceptions thrown to catch specific errors System Testing -Input from the client via command line used to generate model in memory -Output AAXL file is parsed by OSATE and converted to AADL text and EMF diagram -Use OSATE to run analyses on imported diagrams to confirm validity of the model -Use OSATE to create “instances” of the system – a flat model based on tiered implementations within the model Testing Results -Most bugs were identified in the system-level testing -Some boundary/fringe conditions and needed guards were identified during white box testing White Box Testing -JUnit testing primarily on individual logic-based classes -OSATE API provides many restrictions on how components can be used – there were places that we needed to create our own restrictions to preserve model validity -Custom exceptions thrown to catch specific errors System Testing -Input from the client via command line used to generate model in memory -Output AAXL file is parsed by OSATE and converted to AADL text and EMF diagram -Use OSATE to run analyses on imported diagrams to confirm validity of the model -Use OSATE to create “instances” of the system – a flat model based on tiered implementations within the model Testing Results -Most bugs were identified in the system-level testing -Some boundary/fringe conditions and needed guards were identified during white box testing White Box Testing -JUnit testing primarily on individual logic-based classes -OSATE API provides many restrictions on how components can be used – there were places that we needed to create our own restrictions to preserve model validity -Custom exceptions thrown to catch specific errors System Testing -Input from the client via command line used to generate model in memory -Output AAXL file is parsed by OSATE and converted to AADL text and EMF diagram -Use OSATE to run analyses on imported diagrams to confirm validity of the model -Use OSATE to create “instances” of the system – a flat model based on tiered implementations within the model Testing Results -Most bugs were identified in the system-level testing -Some boundary/fringe conditions and needed guards were identified during white box testing White Box Testing -JUnit testing primarily on individual logic-based classes -OSATE API provides many restrictions on how components can be used – there were places that we needed to create our own restrictions to preserve model validity -Custom exceptions thrown to catch specific errors System Testing -Input from the client via command line used to generate model in memory -Output AAXL file is parsed by OSATE and converted to AADL text and EMF diagram -Use OSATE to run analyses on imported diagrams to confirm validity of the model -Use OSATE to create “instances” of the system – a flat model based on tiered implementations within the model Testing Results -Most bugs were identified in the system-level testing -Some boundary/fringe conditions and needed guards were identified during white box testing 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 Testing Results Most bugs were identified in system testing Boundary/fringe conditions and necessary guards identified during white box testing White Box Testing -JUnit testing primarily on individual logic-based classes -OSATE API provides many restrictions on how components can be used – there were places that we needed to create our own restrictions to preserve model validity -Custom exceptions thrown to catch specific errors System Testing -Input from the client via command line used to generate model in memory -Output AAXL file is parsed by OSATE and converted to AADL text and EMF diagram -Use OSATE to run analyses on imported diagrams to confirm validity of the model -Use OSATE to create “instances” of the system – a flat model based on tiered implementations within the model Testing Results -Most bugs were identified in the system-level testing -Some boundary/fringe conditions and needed guards were identified during white box testing White Box Testing -JUnit testing primarily on individual logic-based classes -OSATE API provides many restrictions on how components can be used – there were places that we needed to create our own restrictions to preserve model validity -Custom exceptions thrown to catch specific errors System Testing -Input from the client via command line used to generate model in memory -Output AAXL file is parsed by OSATE and converted to AADL text and EMF diagram -Use OSATE to run analyses on imported diagrams to confirm validity of the model -Use OSATE to create “instances” of the system – a flat model based on tiered implementations within the model Testing Results -Most bugs were identified in the system-level testing -Some boundary/fringe conditions and needed guards were identified during white box testing White Box Testing -JUnit testing primarily on individual logic-based classes -OSATE API provides many restrictions on how components can be used – there were places that we needed to create our own restrictions to preserve model validity -Custom exceptions thrown to catch specific errors System Testing -Input from the client via command line used to generate model in memory -Output AAXL file is parsed by OSATE and converted to AADL text and EMF diagram -Use OSATE to run analyses on imported diagrams to confirm validity of the model -Use OSATE to create “instances” of the system – a flat model based on tiered implementations within the model Testing Results -Most bugs were identified in the system-level testing -Some boundary/fringe conditions and needed guards were identified during white box testing Model Generator – 1.Develop a static model generator that produced AADXL output. 2.Extend the static model generator to handle dynamic model generation. 3.Create a console that would allow parameters to be imputed from the user to control the dynamic model generation. 4.Experiment with dynamically generating models larger than memory. AADL-XML Adapter – 1. Experiment with BaseX and understand its limitations in terms of performance and features. 2.Build a wrapper for BaseX in Java to insert XML files into database and to perform queries. 3.Generate EMF models for testing. 4.Develop the AADL-XML adapter using EMF’s persistence API and use BaseX as custom storage for AADXL