Applying Design Patterns for Enabling Simulation Interoperability
Article by: Paul Gustavson  (pgustavson@simventions.com) Paul Gustavson (SimVentions) Dr. Katherine L. Morse (SAIC) Robert Lutz (JHU APL) Steve Reichenthal (Boeing) 1 Introduction Characteristically the approach for defining a model representation for a federation, which is often referred to as a Federation Object Model (FOM) in HLA, is to focus on matching system capabilities of federates that come closest to supporting the perceived needs (i.e. the requirements) of the federation, or choosing an existing and well-adopted FOM whether or not it maps and fully supports the perceived needs of the federation. However, a more effective and efficient way for creating a model representation for a federation and facilitating reuse begins with the identification of the conceptual models. The approach recommended is illustrated in Figure 1: Figure 1. Requirements Driven Representation Essentially, the conceptual model produced from the conceptual analysis describes “what the [simulation or federation] will represent, the assumptions limiting those representations, and other capabilities needed to satisfy the user’s requirements. [1]” The hurdles in reaching a model-specific representation are typically in knowing how to capture the various conceptual models that represent the domain space, and, more importantly, knowing what to look for within the problem domain space in which a conceptual model should be engineered. While it’s important to understand the attributes of a conceptual model during the capture process (associated with FEDEP Steps 1 and 2), the more elusive activity is in seeking and discovering common themes (or problems) within the domain space that are to be modeled by the federation. Solutions for these themes and common problems can be represented (described) as reusable design patterns. A pattern identifies a set of activities used to accomplish a common need, capability or purpose. In other words, a defined pattern reflects what activities take place and with what resources (often identified as actors) are needed to carry out an identified objective. The concept of patterns actually grew out of the architectural community [2] some years ago, and found application within the Software Development community with the research and ideas put forth in the book, Design Patterns - Elements of Reusable Object-Oriented Software [3]. In the same manner, the concept of patterns is seen as a key enabler in supporting the M&S community in regards to federation development, composability and reuse. The vision is that systems, simulations, and the interchanges among them can be effectively described by one or more patterns. One of the enabling technologies being developed to support this concept is Base Object Models (BOMs). A BOM is used to codify a pattern and provide a mechanism to include the identification of behaviors (e.g. events) needed to satisfy a pattern’s activities, and the specific actors (e.g. object models including object classes/interaction classes) used to support those events. The heart of our desire in even bringing up the idea of design patterns is to find ways to better support simulation composability. Petty defines composability as: “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. [4]” 2 Types of Patterns We can choose from a number of different types of patterns that can support structural elements of our design, creational elements needed for the execution of our federate, or behavioral elements needed for the conceptual entities being represented within the problem space. Ultimately this leads us to the ability and desire to create flexible and reusable classes that can translate into validated components. Following the FEDEP process, we can discover patterns in a manner that reflects capability, drives development and facilitates reuse. Of specific interest is how common “structural patterns” and “patterns of interplay” among conceptual entities within a simulation space can be applied and reused to support common objectives among multiple federations. Note that we are examining design patterns associated with the domain space and activities to be represented within a federation. These activities that are cataloged as design patterns can potentially be common to other federations. The types of design patterns examined in this paper, which take into account aspects of the domain space in a federate independent manner, can lead to the production of comprehensible UML interaction diagrams, e.g. sequence diagrams, and conceptual-level UML class diagrams, which, from a visual perspective, can be practical and useful to all stakeholders. 2.1 Structure-Oriented Design Patterns Let us explore some of the recognizable design patterns that are applicable to simulation. The most common applications of design patterns to software systems are to the structure of the software itself. “Structure-oriented” design patterns can be applied to simulations and simulation frameworks. The following are several well-known “structure-oriented” design patterns that we might expect to see in a simulation system. The Adapter pattern matches “an existing object beyond your control to a particular interface. A system has the right data and behavior but the wrong interface. … The Adapter provides a wrapper with the desired interface [5].” The most obvious applications of this to simulation systems are DIS to HLA RPR FOM or DoD HLA 1.3 to IEEE 1516 adapters. The Bridge pattern is designed to separate a class’s interface from its implementation allowing you to vary or replace the implementation without changing the client code. In the case of Base Object Models (BOMs), which we will discuss in detail later, the Interface BOM [6] provides the abstraction serving as the class interface, whereas the Encapsulated BOM provides the implementation. The Composite pattern is used to form a collection of objects. In the case of BOMs, the Mega-BOM is used to represent a composite of IF BOMs. This composite is used to formulate the model representation for a federation (akin to a FOM), a federate (akin to a SOM), or an aggregation of elements or HLA object classes. The Façade pattern is used to wrap a set of complex classes into a simpler enclosing interface. One example of this in HLA, is the ongoing Dynamic Link Compatibility (DLC) API effort, which is focusing on creating a common interface to support the various RTI implementations that are currently in existence. This will allow a federate to plug into virtually any RTI implementation using the DLC API calls rather than having to recode to support various RTI implementations as is often the case now. The Flyweight pattern can be used to help manage large numbers of class instances (i.e. entities) within a simulation. By identifying the common attributes of the classes representing the entities within a simulation, a common class can be defined and, where there are any differences in attributes among the various classes, these can be maintained as extrinsic data passed in as arguments (using mechanisms such as HLA Interactions). This approach is currently being investigated to support instance aggregation within the simulation community. 2.2 Behavioral-Oriented Design Patterns Many of the examples related to “creational-oriented” patterns and “behavioral-oriented” patterns that are found in the design pattern literature may not seem as applicable for distributed simulation, but they certainly can be applied. Capabilities within the federates themselves can be represented using these patterns. The Strategy pattern, for instance, “allows you to use different algorithms depending on the context in which they occur. The selection of an algorithm that needs to be applied depends upon the client making the request or the data being acted upon. … [It] separates the selection of algorithm from the implementation of the algorithm. [It] allows for the selection to be made based upon context [5].” In a simulation system, this pattern might be applied to select a dead-reckoning algorithm based on the position representation being used in a particular federation. For simulation interoperability we extend the concept of “behavioral-oriented” design patterns for representing patterns of “interplay”. In the context of the object-based HLA, this aspect of simulation is typically contained in the federation agreements rather than in the FOM. However, it is this aspect that can be codified formally through the application of Base Object Models (BOMs), specifically Interface (IF) BOMs. The IF BOM, which is currently a trial-use standard developed within SISO, is used to represent such patterns of interplay. To understand our simulation interplay pattern, let us start with a simple example from DIS that has been carried forward to HLA via the GRIM document that essentially provides the baseline federation agreements for federations employing the RPR FOM. An entity in Federate A is engaging an entity in Federate B and fires a small munition (as opposed to a missile or torpedo). As illustrated in Figure 2, Federate A issues a WeaponFire interaction (Fire PDU). The GRIM indicates that Federate B should respond with a MunitionDetonation interaction (Detonate PDU). If the engaged entity in Federate B is damaged as a result of the detonation, this would be reflected in a subsequent update of the Damage-State attribute of the PhysicalEntity class instance (Entity State PDU) from Federate B. In this example, we see a common pattern fulfilled by several activities necessary to support a full munitions firing engagement. This is a common simulation interplay pattern used unknowingly in many federations. The opportunity is to capture and document this pattern so that it can be reused for a wide range of federations. Figure 2. Munitions Firing 3 Supporting Simulation Interplay Patterns with Base Object Models There are two essential BOM building blocks that can be produced from the conceptual analysis of FEDEP Step 2: pattern components, that are codified as Interface (IF) BOMs, and behavior components, that are codified as Encapsulated (ECAP) BOMs. As shown in Figure 3, IF BOMs represent the relationship of activities among conceptual entities enabling support at the FOM level, whereas ECAP BOMs represent the needed behavior required of a conceptual entity to support one or more patterns of interplay thereby enabling a Federate to participate in the Federation. Again, you can see the importance of the conceptual model. Figure 3. BOM Representations The IF BOM provides the essential abstraction necessary in allowing us to separate the interface (IF BOM) from its implementations (ECAP BOM), thereby supporting a Bridge pattern. Each ECAP BOM represents a behavior description needed for supporting the pattern that is codified by an IF BOM. One of the favorable consequences of this approach is that it also allows for an ECAP BOM to support more than one pattern. 4 Impact The result of applying BOMs in support of this pattern approach is that it can be used to facilitate composability and support web-enabled simulation initiatives such as the eXtensible Modeling and Simulation Framework (XMSF). Furthermore, XML-based specifications such as the Simulation Reference Markup Language (SRML) can be used to help bring patterns to life [7]. Specifically, SRML can provide the underlying code used to model the behavior of an ECAP BOM in a manner that can provide a distributable payload within a web-enabled simulation environment, thereby supporting the needs of XMSF. 5 Summary It’s often said that “patterns are discovered rather than invented” [8]. The best way to discover a pattern is to perform a conceptual analysis on the problem space. We identified earlier a high level process for supporting federation development and composability that prescribes some practical activities supportive of pattern discovery. We have also described the benefit of categorizing repeating themes (or problems) within a design, and we have shown how patterns and IF BOMs can help expedite the composability of simulations and simulation spaces without requiring an over-use of inheritance (as often is the case). Furthermore, we have explored how these patterns of interplay can be transformed into a collection of reusable behavior components, represented by ECAP BOMs. References [1] IEEE 1516.3, High Level Architecture (HLA) Federation Development and Execution Process (FEDEP), April 2003. [2] Alexander, C., et al, The Timeless Way of Building, Oxford University Press, 1979. [3] Gamma, Helm, Johnson, Vlissides, Design Patterns – Elements of Reusable Object-Oriented Software, Addison Wesley, 1995. [4] M. D. Petty and E. W. Weisel, “A Composability Lexicon”, Proceedings of the Spring 2003 Simulation Interoperability Workshop, Orlando FL, March 30-April 4 2003, 03S-SIW-023. [5] Shalloway, Trott, Design Patterns Explained – A New Perspective on Object-Oriented Design, Addison Wesley, 2002 [6] SISO-STD-003.1-DRAFT, Base Object Model (BOM) Template Specification Volume I - Interface BOM, v0.8, February 2004 [7] “SRML - Simulation Reference Markup Language”. W3C Note, Dec. 18, 2002. <http://www.w3.org/TR/SRML/> [8] Fowler, M., Analysis Patterns – Reusable Object Models, Addison Wesley, 1997.
Close