1. 2004 Fall Simulation Interoperability Workshop In Search of the Philosopher’s Stone: Simulation Composability Versus Component-Based Software Design M odeling a nd S imulation T echnology R esearch I nitiative Robert G. Bartholet, LTC, US Army David C. Brogan, Ph.D. Paul F. Reynolds, Jr., Ph.D. Joseph C. Carnahan

2. 2004 Fall Simulation Interoperability Workshop Simulation Design and Transformation for Reuse COERCE Coercibility: the practices and methods for capturing designer knowledge in software (Carnahan et al.) Coercion: a user-guided, semi-automated software transformation process (Waziruddin et al.) Composability Reusing components, possibly with acceptable amounts of revision, to meet new requirements (Bartholet et al.) M odeling a nd S imulation T echnology R esearch I nitiative

3. 2004 Fall Simulation Interoperability Workshop The Question Are simulation composability and CBSD fundamentally different?

4. 2004 Fall Simulation Interoperability Workshop Simulation Composability “The capability to select and assemble simulation components in various combinations into valid simulation systems to satisfy specific user requirements.” (Petty and Weisel 2003) Interoperability: meaningful combination of components for a single instance (Petty and Weisel 2003) Interoperability DIS ALSP HLA Composability Theoretical results, few practical

5. 2004 Fall Simulation Interoperability Workshop Component-Based Software Design Major players: Microsoft, Sun, OMG Software component characteristic properties (Szyperski 2002) Independent deployment Third party composition No externally observable state In addition to services, components typically provide Reflection Dynamic invocation Metadata Framework unique services (security, transactions, events, serialization)

6. 2004 Fall Simulation Interoperability Workshop Invoking a Component Service LOCAL CLIENT LOCAL PROXY REMOTE PROXY COMPONENT INVOKE COMPONENT SERVICE MARSHAL AND SHIP PARAMETERS POSSIBLE PROCESS OR MACHINE BOUNDARY UNMARSHAL AND PASS PARAMETERS COMPUTE RESULTS RETURN RESULTS RETURN RESULTS RETURN RESULTS

7. 2004 Fall Simulation Interoperability Workshop The Question Are simulation composability and CBSD fundamentally different? Published opinion: Composing models is different than composing general software components. Complexity Purpose Context-sensitive assumptions White-box Our opinion: They are more similar than different.

8. 2004 Fall Simulation Interoperability Workshop Closing the Gap: The Business Case Large up-front investment Forces against componentizing Mathematics as an exemplar High reconstruction cost Rich and standard nomenclature Composability will work if it: Reduces development effort Provides a formal means to describe component functionality

9. 2004 Fall Simulation Interoperability Workshop Closing the Gap: Architectural Mismatch Garlan, et al. 1995: CBSD with large-scale components is HARD! Recommendations: Explicit announcement of assumptions Orthogonal components Techniques for bridging mismatches Cookbook for software composition rules and principles Sullivan and Knight 1996 : CBSD with large-scale components is possible. “A key lesson is that, if components are to be composable, they have to be designed for it.” Kasputis and Ng 2000 “We have discovered that unless models are designed to work together, they don’t (at least not easily and cost effectively).”

10. 2004 Fall Simulation Interoperability Workshop Closing the Gap: Scale Attacking from different directions Software engineers often start small and simple. Simulationists often start large. Software engineering success Start small. Keep the composition within a tightly defined domain. Engineer to a common framework. Once success is achieved, scale up.

11. 2004 Fall Simulation Interoperability Workshop Closing the Gap: Semantics All software components are models. All software has semantics. Historically simulationists monolithic models semantics problematic s/w engineers small, simple models semantics intuitive But… “The goal is to replace...GUI controls with …business objects…such as insurance coverage, and script complex business processes such as order fulfillment.” (Krieger and Adler 1998)

12. 2004 Fall Simulation Interoperability Workshop Composability and CBSD Convergence The goals and business case are the same. Architectural mismatch occurs in both. Small scale is the key to success. Semantics are a challenge in CBSD and composability.

13. 2004 Fall Simulation Interoperability Workshop The Path Ahead RESEARCH PATH LEVERAGE S/W ENG AND WEB TECHNOLOGIES LEVERAGE SIMULATION UNIQUE CHARACTERISTICS SUCCESS

14. 2004 Fall Simulation Interoperability Workshop Leveraging Other Research: PACC/PECT COMPONENT OR ASSEMBLY REASONING FRAMEWORK SPECIFICATION + + COMPONENT TECHNOLOGY PREDICTED BEHAVIOR

15. 2004 Fall Simulation Interoperability Workshop Leveraging Other Research: OWL Web-based formal data description Provides meaning to XML structure OWL and semantic composability Given: Ontology supporting a domain, Models described using the above ontology Tools to reason about the ontology Can we reason about whether simulation components are semantically compatible?

16. 2004 Fall Simulation Interoperability Workshop Leveraging Other Research: UML/MDA UML Useful for modeling software Good documentation tool MDA Separates application from platform Facilitates reuse Does not address semantics Couple UML with DEVS? (Davis and Anderson 2003) Not clear where to go

17. 2004 Fall Simulation Interoperability Workshop Leveraging Simulation Uniqueness What is unique about simulations? Stochastic sampling Time management Event generation Needs to be explored

18. 2004 Fall Simulation Interoperability Workshop Conclusion There is no philosopher’s stone! Composability and CBSD are more similar than different. Same goal Same business case challenge Contain on syntax and semantics Syntax-dominated research results We advocate a two-pronged research agenda. 1. Leverage s/w engineering and semantic web research. 2. Leverage unique M&S characteristics.

19. 2004 Fall Simulation Interoperability Workshop Acknowledgements Defense Modeling and Simulation Office US Army National Science Foundation MaSTRI at the University of Virginia M odeling a nd S imulation T echnology R esearch I nitiative