In Search of the Philosophers Stone:

1
Modeling and Simulation Technology Research
Initiative
In Search of the Philosophers Stone Simulation
Composability Versus Component-Based Software
Design
Robert G. Bartholet, LTC, US Army David C.
Brogan, Ph.D. Paul F. Reynolds, Jr., Ph.D. Joseph
C. Carnahan
2
Modeling and Simulation Technology Research
Initiative

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

3
The Question
Are simulation composability and CBSD
fundamentally different?
4
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
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
Invoking a Component Service
POSSIBLE PROCESS OR MACHINE BOUNDARY
COMPUTE RESULTS
LOCAL CLIENT
COMPONENT
INVOKE COMPONENT SERVICE
UNMARSHAL AND PASS PARAMETERS
RETURN RESULTS
RETURN RESULTS
RETURN RESULTS
LOCAL PROXY
REMOTE PROXY
MARSHAL AND SHIP PARAMETERS
7
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
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
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 dont (at least not
  easily and cost
• effectively).

10
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
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 objectssuch as insurance coverage, and
  script complex business processes such as order
  fulfillment. (Krieger and Adler 1998)

12
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
The Path Ahead
LEVERAGE S/W ENG AND WEB TECHNOLOGIES
RESEARCH PATH
SUCCESS
LEVERAGE SIMULATION UNIQUE CHARACTERISTICS
14
Leveraging Other Research PACC/PECT
COMPONENT TECHNOLOGY
PREDICTED BEHAVIOR
15
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
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
Leveraging Simulation Uniqueness

• What is unique about simulations?
• Stochastic sampling
• Time management
• Event generation
• Needs to be explored

18
Conclusion

• There is no philosophers 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.
• Leverage s/w engineering and semantic web
  research.
• Leverage unique MS characteristics.

19
Acknowledgements

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

Modeling and Simulation Technology Research
Initiative