Applying Design Patterns for Enabling Simulation Interoperability

1
Applying Design Patternsfor Enabling Simulation
Interoperability
04S-SIW-111

• Paul Gustavson (SimVentions)
• Katherine L. Morse (SAIC)
• Bob Lutz (JHU/APL)
• Steve Reichenthal (Boeing)

2
Approaches for Defining a Model Representation
(1)
SYSTEMIMPLEMENATION
OBJECTIVES / REQUIREMENTS
MATCH SYSTEMCAPABILITIESTO NEEDS
Real World
MODELREPRESENTATION(FOM)
System DrivenRepresentation
3
Why This Happens

• A simulation or system already exists with the
  desire that it be a participant in a federation.
• capabilities of the system or simulation are
  often well understood
• Easier to reverse engineer its capability to form
  an interface assembly such as a FOM,
• Harder to transition the real needs and
  requirements into an interface assembly.
• Reusing the whole as opposed to the parts
• Grain-size level of reuse is at the federate
  level
• Prefer reuse at the pattern / component level
• Requirements are loosely identified.
• Its not understood how to take the requirements
  and objectives and lay out a truly functional
  conceptual design.
• frequent FOMoramas
• selection of an existing FOM with the attempt to
  tailor it to federation needs

4
Approaches for Defining a Model Representation
(2)
OBJECTIVES / REQUIREMENTS

• HURDLES
• Knowing what to look for within the problem
  domain space in which a conceptual model should
  be engineered
• Knowing how to capture the various conceptual
  models that represent the domain space

CONCEPTUALANALYSIS
Ideal World
MODELREPRESENTATION(FOM)
RequirementsDrivenRepresentation
5
Recommended Methodology

• Discover solutions to recurring design problems
• Reflects capability
• Drives Development
• Facilitates Reuse

• Identify common patterns of interplay
• Applied and reused to support common objectives
  and problems
• Not limited to just one federation

The Timeless Way of Building Christopher
Alexander
6
Why Patterns?

• Common (subconscious) representation of real
  world activities
• Often modeled and represented by federates and
  federations

• Examples
• DIS 1278
• Weapons Fire
• Logistics Support
• Simulation Management
• Emission Regeneration
• Radio Comms
• Danzig Approach for representing threats

7
Pattern Identification Approaches

• Conceptual Analysis Approach
• Examine design patterns associated with the
  domain space
• Capture activities to be represented within a
  federation
• Take into context aspects of the domain space in
  a federate independent manner.
• Result
• Leads to the production of UML interaction
  diagrams, e.g. sequence diagrams,
• conceptual-level UML class diagrams

• System Capabilities Approach
• Examine design patterns associated with the
  capabilities of pre-selected federates
• Capture internal representations of entities
• Result
• Can lead to the production of implementation-level
  UML class diagrams

Maybe More detail than necessary
Practical and useful toall stakeholders
8
Recognized Patterns

• Adapter
• Match an existing object/system to a particular
  interface.
• Examples
• DIS to HLA
• DoD 1.3 to IEEE 1516 adapters.
• Strategy
• choose different algorithms depending on the
  context in which they occur.
• separates the selection of algorithm from the
  implementation of the algorithm.
• Examples
• applied to select a DR algorithm based on the
  position representation being used in a
  particular federation.
• Interplay
• typically captured in the federation agreements
  rather than in the FOM.
• Examples
• Weapon Effect
• Automated Door

9
Interplay Pattern - Munitions Firing
10
Interplay Pattern - Automated Door
11
Guidance

• Follow the FEDEP
• Study objectives and capabilities to be modeled
  and represented
• Identify sequences of events that may occur with
  some repeatability.
• Recognize specific relationships and combinations
  among structural and behavioral elements

Its often said that patterns are discovered
rather than invented - Martin Fowler
Fowler, M., Analysis Patterns Reusable Object
Models, Addison Wesley, 1997.
The best way to discover a pattern is to perform
a conceptual analysis on the problem space.
The pattern represents an abstraction of the
occurrences of events that happen over time
amongst specific actors to support a common,
repeatable operation.
12
Extensions and Variations

• Patterns of interplay can also include
  extensions and variations
• Extension unexpected but potential behavior
• Variation different way that activity can be
  accomplished
• Real world examples (for grins)

Man Catching
Ship Anchoring
13
Role of XMSF
Extensible Modeling Simulation Framework (XMSF)

• Web-based Technologies
• Web services

• Standards
• Process
• Practices

• Web-based Technologies
• Web services

• Web-based Technologies
• Web services

MS tailored
Profiles
New Generation Internet-distributed applications
Next Generation Internet-distributed applications
Next Generation Internet-distributed applications
emerge
develop
interoperate
14
BOM Alignment with XMSF
Extensible Modeling Simulation Framework (XMSF)

• Pattern Profile Enabler
• IF BOM / Mega-BOM support XMSF Profile definition
  objectives
• Provide unambiguous specification of the
  functionality of components, and interfaces among
  components of the framework
• Provide the necessary metadata to facilitate
  composability and reuse of components across
  multiple MS application domains
• Component Profile Enabler
• ECAP BOM applied to support XMSF push for web
  enabled simulation
• Provides behavior modeling for a pattern within a
  distributable payload

• Web-based Technologies
• Web services

• Standards
• Process
• Practices

• Web-based Technologies
• Web services

• Web-based Technologies
• Web services

MS tailored
Profiles
New Generation Internet-distributed applications
Next Generation Internet-distributed applications
Next Generation Internet-distributed applications
emerge
develop
interoperate
15
Existing HLA Architecture
Federation Layer
Federate A
Federate B
Federate C
Federate D
Federate E
Federate Z
Interface Layer
FOM
HLAObjectModels
FOM based,meta-datachallenged
Communication Layer
RTI
Optional
Required
16
BOM Architecture
Federation Layer
Federate A
Federate B
Federate C
Federate D
Federate E
Federate Z
Encapsulation Layer
HLAObjectModels
Federate Code
ECAP BOM a
ECAP BOM b
ECAP BOM c
ECAP BOM d
ECAP BOM x
Interface Layer
IF BOMs
IF BOM 1
IF BOM 2
IF BOM 3
IF BOM n
Classa
Classb
Classx
Classa
Classc
Classx
Classb
Classc
Classx
Classa
Classb
Classd
ECAP BOMs
Mega BOM
Meta-dataRich
Communication Layer
RTI
Optional
Required
17
BOM Architecture
Federation Layer
Federate A
Federate B
Federate C
Federate D
Federate E
Federate Z
Encapsulation Layer
Federate Code
ECAP BOM a
ECAP BOM b
ECAP BOM c
ECAP BOM d
ECAP BOM x
Interface Layer
IF BOM 1
IF BOM 2
IF BOM 3
IF BOM n
Classa
Classb
Classx
Classa
Classc
Classx
Classb
Classc
Classx
Classa
Classb
Classd
Mega BOM
Meta-dataRich
Composability The capability to select and
assemble components in various combinations into
complete, validated simulation environments to
satisfy specific user requirements across a
variety of application domains, levels of
resolution, and time scales Dr. Mikel Petty
Communication Layer
RTI
Optional
Required
18
BOM Architecture
Federation Layer
Federate A
Federate B
Federate C
Federate D
Federate E
Federate Z
Encapsulation Layer
Federate Code
ECAP BOM a
ECAP BOM b
ECAP BOM c
ECAP BOM d
ECAP BOM x
ComponentRepository
ECAP BOM X
Interface Layer
ECAP BOM d
IF BOM 1
IF BOM 2
IF BOM 3
IF BOM n
ECAP BOM c
Classa
Classb
Classx
Classa
Classc
Classx
Classb
Classc
Classx
Classa
Classb
Classd
ECAP BOM c
ECAP BOM a
Mega BOM
Meta-dataRich
Composability The capability to select and
assemble components in various combinations into
complete, validated simulation environments to
satisfy specific user requirements across a
variety of application domains, levels of
resolution, and time scales Dr. Mikel Petty
Communication Layer
RTI
Optional
Required
19
BOM Architecture
Federation Layer
Federate A
Federate B
Federate C
Federate D
Federate E
Federate Z
Encapsulation Layer
HLAObjectModels
Federate Code
ECAP BOM a
ECAP BOM b
ECAP BOM c
ECAP BOM d
ECAP BOM x
Interface Layer
IF BOMs
IF BOM 1
IF BOM 2
IF BOM 3
IF BOM n
Classa
Classb
Classx
Classa
Classc
Classx
Classb
Classc
Classx
Classa
Classb
Classd
ECAP BOMs
Mega BOM
Meta-dataRich
Communication Layer
RTI
Optional
Required
20
Application ofInterface BOMs
Sim / System A
Federate
InterfaceBOM 1
Federate A
Federate B
- or -
InterfaceBOM 2
Federation
Mega-BOM
Representation
Composition
Federate X
InterfaceAssembly
- or -
InterfaceBOM n
Model1
Model2
Aggregation
Interface BOMs(Coupling)
Model3
Modeln
21
Pattern IF BOM Mapping
IF BOM / Mega-BOM Elements
Pattern Description
Model Definition
Model Identification
Object Models(1516.2)
Name
Description
Step
Type
Use Limitation
Events
Version
Use History
Mod Date
Keywords
Security Class
POCs
Rel Restriction
References
Purpose
Others
App Domain
Glyph
Not needed for Mega-BOM
Required
Optional
22
Pattern IF BOM Mapping
IF BOM / Mega-BOM Elements
Pattern Description
Model Definition
Model Identification
Object Models(1516.2)
Name
Description
Step
Type
Use Limitation
Events
Version
Use History
Mod Date
Keywords
Security Class
POCs
Rel Restriction
References
Purpose
Others
App Domain
Glyph
Not needed for Mega-BOM
23
(No Transcript)
24
Utilization of Component Models
InterfaceBOM 1
InterfaceBOM 2
Sim / System a
Tool
Run-timeSupport
Modeling
SimulationEnginePlug-in
Federate
InterfaceBOM n
BOMs
Implementations representing a pattern of
simulation interplay can be either contained
within a package of Encapsulated BOMs
(representing component models) or internal
within the federate.
25
ECAP BOM Elements
Behavior Model
other
Model Description
Visual Model
VV Markup
Digital Rights
Level of Fidelity

• ECAP BOM Implementations Types
• PIM
• XML-based (SRML)
• PSM
• Source Code (C, C, Java, Delphi, )
• Binary (DLL, DSO, .NET Assembly, Java Bean, COM,
  )

Required
Optional
26
Pattern Behavior In SRML

• An executable Platform Independent Model (PIM)
  may be embedded in an ECAP BOM
• A particular ECAP BOM pattern can be loaded
  directly into an SRML simulator, providing
  pattern behavior (i.e. class/actor) for the
  interface BOM

• lt! Race Pattern description in interface BOM --gt
• ltpatternDescriptiongt
• ltsteps action"GetReady" event"GetReady"
  bom"RaceManager"/gt
• ltsteps action"StartRace" event"Release"
  bom"Competitor"/gt
• ltsteps action"GetConditions" bom"Competitor"/gt
• ltsteps action"UpdatePosition"
  bom"Competitor"/gt
• ltsteps action"CrossedFinishLine" bom"Track"/gt
• ltsteps action"RaceComplete" event"RaceComplete"
  bom"RaceManager"/gt
• lt/patternDescriptiongt
• lt! SRML Encapsulated behavior for a pattern
  description --gt
• ltsrmlScript type"text/ECMAScript"gtlt!CDATA
• function GetNextStepNode (CurrentStep) // Return
  the next step node.
• return CurrentStep.node.nextSibling
• //...
• gt
• lt/srmlScriptgt

27
Web-Based Simulation Engine

• SRML promotes a standard for governing the
  operation of web-based simulation engines
• Like HTML, SRML provides for executable content
  using the same kinds of mechanisms found in Web
  Browsers
• Object models
• Scripting
• Plug-ins
• Downloaded and assembled content

• ltCompetitor ID"BOMBiscuit"gt
• lt!-- Custom behavior for this instance --gt
• ltsrmlScript type"text/ECMAScript"gtlt!CDATA
• function StartRace ()
• getReady ()
• updateLocation (Track1, "Start")
• // ...
• gt
• lt/srmlScriptgt
• lt/Competitorgt

28
Applying Patterns
29
Development Process
Activities
Pattern
Step 1
Objective / Desired Capability
Step 2
IF BOM
Step n
Classa
Classb
Classx
30
Race Pattern Example
31
Race Example
IF BOM Classes
ECAP BOM Classes
Relationshipof Actors
Models
32
Soap Box Derby Mega-BOM
Environment ECAP BOM
Car ECAP BOM
Track ECAP BOM
Race Manager ECAP BOM
Race IF BOM
33
Summary

• Patterns provide a practical mechanism for
  representing domain activities / interactions
• IF BOMs provide way to codify a pattern of
  interplay
• Minimizes over-use of inheritance
• Patterns of interplay can be transformed into a
  collection of reusable components models (ECAP
  BOMs)

• Recommendations
• Patterns should be a key part of MS Analysis and
  further explored within SISO
• A Pattern approach, (via XMSF, BOMs, SRML) can be
  used to support federation development
  composability.

34
Questions?

• Specific areas
• XMSF Katherine L. Morse
• BOMs Paul Gustavson
• FEDEP / OMT Bob Lutz
• SRML Steve Reichenthal
• Web sites
• www.boms.info
• www.xmsf.org

35
Addendum Slides
36
Common Terminology

• Pattern
• an abstraction of the occurrences of events that
  happen over time amongst specific actors to
  support a common, repeatable operation.
• Object Oriented Paradigm
• Association
• Physical or conceptual relationship between
  object classes
• Generalization
• is-a or inheritance
• Aggregation
• has-a, a object class and collection of objects
  that collectively represents the composite class
  assembly
• Composition
• part-whole, a container object class and the
  set of objects that it contains, and that
  collectively represents the composite class
  assembly
• Object model
• HLA Object-based Paradigm
• provide a means of representing an entity of
  interest (via objects and interactions)
• HLA object classes characterized by the attribute
  data
• defines the state of the object at any point
  during execution (state data)
• Static data defined within federate
• Object behavior (operations) modeled within
  federate.
• Composability

37
FEDEP
38
Design Pattern Tenets

• Encapsulate variation
• Expose that which is constant
• Hide that which varies
• Commonality/variability analysis can be applied
  to a systems design
• To identify potential future variations
• To decide which generalizations are worth
  reflecting / reusing in the future

39
Race IF BOM Example (1/2)
40
Race IF BOM Example (2/2)