Theory and Practice in User-Composable Simulation Systems

1. Theory and Practice in User-Composable Simulation Systems Ernie Page Jeff Opper 30 October 1998 Organization: W15D Project: 0799A56A-1A

2. Agenda • Problem statement • Proposed approach and deliverables • Discussion

3. Problem: The Usability of Simulations • The ultimate in simulation usability … the Holodeck … how do we get there from here? • Clearly modern simulations are far more difficult to use than Roddenberry’s imagined simulation environment • Are the complexities associated with modern simulation systems essential or accidental? • Since Enterprise crew members are rarely seen generating code, the imagined future seems to exploit reuse and user control significantly better than we do today • Reuse and user control seem to be critical elements of simulation usability

4. Problem: The Usability of Simulations • Notable DoD M&S initiatives confronting the reuse problem • HLA • JSIMS • JWARS • OneSAF Domain-independent reuse Domain-dependent reuse In addition to reuse, JSIMS/JWARS/OneSAF purport high degrees of user control through the concept of composability.

5. Logical extension of modern OO software rhetoric Objects… Frameworks… Patterns… Substantive differences between concept of composability and structured (modular) programming concepts from the 1970s is unclear High levels of vendor spin Sun Java, JavaSpaces, JavaBeans, Jini … Microsoft ActiveX CORBA What Do People Who Use the Term “Composable” Really Mean? Composable = structured programming Composable = miracle cure for system development • Components with sympathetic interfaces make the program construction task as simple as building with Legos • Users can exercise very high degrees of influence on the nature of the system appearance and functionality at runtime • Composability is Universally good and does not negatively impact any other system objective • But … • Legos don’t have semantic differences • Current approaches to VV&A do not accommodate composability • Composability does impact other system objectives

6. What Do People Who Use the Term “Composable” Really Mean? (The Role of HLA) • Randy Saunders observes: • Networking is NOT the problem • Standardization efforts for network-based RTIs are misguided • There aren’t that many big (i.e. network demanding) simulation projects • Internal component integration not external simulator networking should be the focus of HLA • SISO starting SIG to address component technologies Considering HLA as an internal component integration technology demands understanding and supporting the (proper) relationship between simulation-support language and simulation-support architecture … a relationship that is currently ill-defined.

7. What Do People Who Use the Term “Composable” Really Mean? (Agile FOM Frameworks) SOM FOM AFF The alternative to this approach is unclear... Providing automated support for the SOM-FOM mapping process for a simulation that participates in multiple federations is a rather obvious solution (several ALSP translators within the JTC have similar functionality). It is unclear that AFF provides any insights on the composability problem.

8. What Do People Who Use the Term “Composable” Really Mean? (Composability in the JSIMS Domain) Source: JSIMS Composability Task Force Final Report • Composability -- the ability to rapidly configure, initialize, and test an exercise by logically assembling a simulation from a pool of reusable elements • Three levels of composability: • Component - the simulation must be composed from fine-grained elements which represent individual models or algorithms, and single host machine or processors • Package - the simulation is composed by selecting pre-assembled packages which carry numerous models designed to form a consistent subset of the battlespace • Simulation - a complete simulation has been pre-assembled which can be modified by parameterization, or by substitution of alternative packages drawn from a limited pool

9. Observations Good definitions are hard to construct by committee JSIMS as a program generally suffers from a terminology overload problem However, definition for composability is reasonable, although need for the term “logical” in definition is unclear Taxonomy seems reasonable Use case for composability consistent with our view What Do People Who Use the Term “Composable” Really Mean? (Composability in the JSIMS Domain) Source: JSIMS Composability Task Force Final Report Example Composable packages: SRA = SORTA -- simulates units in the Training Audience GCG = Ground Combat -- Ground Combat Training GCO = Ground Combat -- Other Training CSSC = Combat Service Support -- Other Training NCBO = Noncombatants -- Other Training EGRC = Ground Environmental Model -- Ground Combat Training EGRO = Ground Environmental Model -- Other Training EATO = Air and Space Model -- Other Training EATA = Air and Space Model -- Air Training EOCO = Oceanic Model -- Other Training EOCN = Oceanic Model -- Naval Training ELTL = Littoral region -- Littoral Training ELTC = Littoral Region -- Coastal Training ELTO = Littoral Region -- Other Training AF1 = Air & Space -- Land Training NV1 = Maritime -- Land Training WM1 = Intel -- Unclassified Training WM2 = Intel -- Classified Training ASP = Army Training Support JCI = JSIMS Core Infrastructure Example Army composition = {(SRA), {(CGC) | (CGO)}, {(CSSC) | (CSSO)} … {(JCI)}

10. Proposal • Investigate the concept of composability and its relationship to usability and other system objectives; develop mechanisms to describe and reason about composable systems • Deliverables and Schedule: Briefing on the definition of composability to be used in the study and a discussion of the technical problems 30 Oct 98 Briefing on the fundamental limits of the specification, analysis, and construction of composable systems 1 Jan 99 Briefing on the notation and methods for composable system specification and analysis 1 Mar 99 Briefing on the implications of composability on software system objectives such as usability, maintainability, reliability, and correctness 1 May 99 Briefing on the theory of composable systems 1 Jul 99 Briefing on the utility of the theory based on experience with OneSAF architectural products 1 Sept 99 30 Sept 99 Composite of previous briefings in annotated format

11. Arbitrary levels of composability potentially introduces decidability problems Supporting the user-based composition of artifacts is not significantly challenging, however… Is the developer-built engine expected to determine, e.g. Validity? Performance characteristics? Depending on the nature of the composition these questions may not be answerable Fundamental Limitations of Composability • Proposal: • Describe a general-purpose framework for user-based system composition • Evaluate the framework in terms of computability theory • Where undecidability issues exist, attempt to describe restrictions on composition that alleviate them User-generated “program” (e.g. objects and behaviors) Developer-built computation engine

12. Notation and Methods for Composable Systems Specification and Analysis • Proposal: • Investigate specification and analysis techniques for composable systems using, e.g. • Set theory • Automata theory • Predicate logics • Software specification languages • Architecture description languages • Category theory • Petri nets • Markov processes

13. Relationship of Composability to Other System Objectives • Proposal: • Investigate extensions of the Objectives - Principles -Attributes (OPA) methodology • Suggest indicators for composability • Integrate within Evaluation Environment prototype (ORCA Computing) Reusability Information Hiding Functional Decomposition Hierarchical Decomposition Documentation Coupling Cohesion Complexity Well-Defined Interfaces Ease of change Use of global variables Parameterless calls Excessive # of parameters

14. A Theory of Composable Systems • Proposal: • Using results from composable systems specification and analysis effort and the OPA extensions, describe a (first-order) theory for composable systems • Axioms • Design heuristics • Inference rules for analysis

15. Evaluation of the Theory of Composable Systems • Proposal: • Use the architectural products derived from the OneSAF architecture specification activity to evaluate the utility/accuracy of our composable systems theory • Use additional architectural products from other systems as deemed appropriate and made available

16. DISCUSSION