2004 fall simulation interoperability workshop in search of the philosopher’s stone: simulation...

2004 Fall Simulation Interoperability Workshop

In Search of the Philosopher’s Stone: Simulation Composability

Versus Component-Based Software Design

Modeling and Simulation Technology Research Initiative

Robert G. Bartholet, LTC, US Army

David C. Brogan, Ph.D.

Paul F. Reynolds, Jr., Ph.D.

Joseph C. Carnahan


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.)



The Question

Are simulation composability and CBSD fundamentally different?


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


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)


Invoking a Component Service

LOCAL CLIENT

LOCAL PROXYREMOTE PROXY

COMPONENT

INVOKECOMPONENT

SERVICE

MARSHAL AND SHIP PARAMETERS

POSSIBLE PROCESS OR MACHINE

BOUNDARY

UNMARSHAL ANDPASS PARAMETERS

COMPUTERESULTS

RETURNRESULTS

RETURNRESULTS

RETURNRESULTS


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.


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


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).”


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.


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)


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.


The Path Ahead

RESEARCH PATH

LEVERAGE S/W ENG AND WEB

TECHNOLOGIES

LEVERAGE SIMULATION UNIQUE

CHARACTERISTICS

SUCCESS


Leveraging Other Research: PACC/PECT

COMPONENT OR

ASSEMBLY

REASONING FRAMEWORK

SPECIFICATION

+

+

COMPONENTTECHNOLOGY

PREDICTED BEHAVIOR


Leveraging Other Research: OWL

• Web-based formal data description• Provides meaning to XML structure

• OWL and semantic composabilityGiven:

• 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?


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


Leveraging Simulation Uniqueness

• What is unique about simulations?

• Stochastic sampling

• Time management

• Event generation

• Needs to be explored


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.


Acknowledgements

• Defense Modeling and Simulation Office• US Army• National Science Foundation• MaSTRI at the University of Virginia


2004 fall simulation interoperability workshop in search of the philosopher’s stone: simulation...

Documents