1 / 24

ACS Generic Software Interface Simulator

A simulator for the ACS software infrastructure, allowing developers to configure and test behavior of simulated components.

mariabrooks
Download Presentation

ACS Generic Software Interface Simulator

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. A Generic Software Interface Simulator for ACS D. Fugate, G. Chiozzi, A. Caproni, B. Jeram, H. Sommer, S. Harrington

  2. Background • ACS is a software infrastructure for the development of distributed systems based on the component/container model • A component is a piece of software that “lives” within a container yet is decoupled • The container manages the lifecycle of components and provides them with a set of common container services • Examples of the component/container design pattern are: • Enterprise Java Beans (EJB) • CORBA Component Model • Microsoft .Net • The ACS group has implemented this model entirely in CORBA using IDL and provides a complete implementation of the container and base component classes

  3. ACS Component/Container Model The specification of the Scheduler IDL interface and the implementation of the functionality are all that ALMA developers are required to do. ACS provides the rest of the infrastructure.

  4. Problem In September 2003 we came to the conclusion that it was necessary to make available to the subsystems a simulation framework. ? X

  5. Solution Due to the fact that only IDL interfaces can be seen by clients of components and not the actual implementations, we concluded that the most effective means of simulation for ALMA is at the component level: • component implementations are hot-swappable • it should be possible to specify to the container that the implementation for a given component is a simulated component factory

  6. Requirements • Must be able to generate implementations of all interfaces without user input • Enumerations will be fully supported • If an interface defines a CORBA Object attribute or a method that returns a reference to another CORBA Object, the simulator should create it • A simulated component should behave in the same manner as a real component • The simulator should take advantage of real object implementations • Users will have the option to specify a timeout value • Read/write attributes should have some form of “memory”

  7. Requirements • It may be necessary to simulate the crashing of a component • A GUI shall be implemented • Users should be able to define simulated component behaviour using the ACS CDB • An API to change the behaviour of the simulation will be provided

  8. Design - Overview The accepted design allows developers to configure the behaviour of simulated components in four different ways: • Completely self-implementing components • Configuration files found in the ACS CDB • A GUI • An API

  9. Design - The Big Picture API??? GUI??? ??? CDB???

  10. Design - CDB • Defining simulated component behaviour usefulness • Characteristics of a simulated component retrieved from the ACS CDB • CDB entries are placed in a specific area of the CDB • Allows setting method timeouts

  11. Design - API and GUI • Useful to change the behaviour of a simulated method at run-time • Possible by running the container within an interactive Python session • A few configurable items are: • A standard global timeout • The maximum sequence size • Associating new timeouts, functions to be executed, etc • API used by a GUI spawned by the first simulated component • Purpose of the GUI is to make the API much simpler to use

  12. Design - Self-implementing Objects Simulated component will implement its own methods and attributes completely autonomously

  13. Design - UML Diagram

  14. Example - Self-implementing Objects Wait a second…there’s absolutely nothing the end-user needs to do here. The infrastructure handles everything!

  15. Example - IDL

  16. Example - Deployment

  17. Example - Behavior from GUI

  18. Example - Behavior from GUI

  19. Example - Behavior from CDB

  20. Example - Behavior from API

  21. Results • Executive team and operator GUI • A few other groups have begun using the simulator to decouple their modular tests from components provided by other subsystems

  22. Conclusions - Overview From an end-user’s point of view all that needs to be done is: • modify a configuration file describing the component Additionally, the user can provide their own simulated behaviour via: • an XML configuration file • a GUI • an API This framework is quite easy to use but…

  23. Conclusions - Future Improvements • the CDB XMLs need to support complex Python constructs • sophisticated support for receiving/sending events • area in the CDB in which users can add XMLs defining the behaviour of all IDL interfaces of a given type

  24. Time for Questions???

More Related