Sent From: [log in to unmask]


The same abstract text was entered for both paper 97F-SIW-162 and paper 97F-SIW-163. The correct abstract and relevance for paper 97F-SIW-162 has been entered in the database for the web site. Both abstracts are shown below for your review. Allison Griffin Institute for Simulation & Training (407) 658-5033 [log in to unmask] See the abstracts below! ___________________________ Paper 97-SIW-162 ****************************** Title: Introduction to Design Patterns Keywords: HLA, Distributed Systems, Design Patterns Abstract: A Design Pattern based architecture is proposed for the RTI. This is the first in a series of papers. This paper will introduce the concepts of design patterns and frameworks. The Design Patterns movement arose within the object-oriented analysis community in an effort to assist in designing reusable object-oriented software. In particular design patterns solve many of the problems in system engineering for the RTI: finding appropriate objects, determining object granularity, specifying object interfaces, specifying object implementations, differentiating class versus interface inheritance, and programming to an interface as opposed to an implementation. Design patterns address specifically common causes of redesign, i.e.: creating an object by specifying a class explicitly, or dependence on specific operations. Dependence on hardware and software platforms, dependence on object representations or implementations, algorithmic dependencies, tight coupling, extending functionality by subclassing, and the inability to alter classes conveniently. Design Patterns also provide a common vocabulary for application programmers to discuss alternatives. Frameworks are "sets of cooperating classes that make up a reusable design for a specific class of software". Frameworks can be looked upon as high-level design patterns. Examples of design patterns and frameworks applicable to the RTI will be presented. Finally, the business case for using design patterns and frameworks will be presented. Relevance of the proposed paper: In an effort to provide for communication and location transparency for distributed heterogeneous simulations, the AMG has mandated certain design principles that mesh very well with the objectives of the Design Patterns movement. This paper will define what is a design pattern and give the history of the Design Patterns movement focusing in particular on the works of Alexander, Gamma et al. (Gang of Four), PloP, and Doug Schmidt. Also, pertinent work within the DOD community will be cited especially Using the Gamma style of cataloging design patterns, the paper will discuss design pattern intent, motivation, applicability, structure, participants, collaborations, consequences, implementation, known uses and related patterns. While Design Patterns provide a rich catalog of solutions to address a wide variety of problems (especially Model-View-Controller for GUI development), this paper will focus on those patterns relating to distributed systems. In particular, the Proxy, Factory, Broker, ThreadMutex, Adapter, Bridge, and Reactor will be discussed. Paper 97-SIW-163 ************************************** Title: A Proposal for an RTI Core Framework Keywords: HLA, Distributed Systems, RTI, Design Patterns Abstract: Design Pattern based architecture is proposed for the RTI. This is the second in a series of papers that will promulgate the use of Design Patterns and Frameworks to resolve the problems of integrating distributed heterogeneous components. An RTI Core Framework encompassing three patterns is proposed: Proxy, Factory and Broker. The heart of the RTI Core Framework is the Broker, a pattern originally identified by Seimens that provides for communication and location transparency. It also provides a means for bridging a number of open federations managed by brokers. Bridges between federations are also supported. Proxies and Factories are described in Gamma, et.al. Design Patterns. A remote Proxy provides a local representative for an object in a different address space. It hides the fact that the object does not reside on the same machine. The actual socket level coding is encapsulated within the Proxy object. A Factory defines an interface for creating an object but lets subclasses decide which class to instantiate. It provides hooks for subclasses and connects parallel class hierarchies, i.e. FOM class hierarchies and remote Proxy class hierarchies. A Factory also makes it easy to replace the default proxy with one that uses client-side caching. Relevance of the proposed paper: In an effort to provide for communication and location transparency for distributed heterogeneous simulations, the AMG has mandated certain design principles that mesh very well with the objectives of the Design Patterns movement. In an effort to articulate the RTI in terms of this movement several frameworks can be identified. This paper will define the RTI Core Framework and will point the way to future frameworks to be developed. If a core framework that is easily extended can be identified, prototyping efforts can be come relatively cheap. The key to this framework is separating the interface from the implementation. Since the interface into the FOM and the underlying transport mechanisms are hidden, the user is free to focus on the data transfer between simulations. This architecture permits the use of complex data structures and avoids much of the overhead associated with translation systems. If a translation system starts to use artificial intelligence to decode messages, then it has become too complex and wastes clock cycles in computationally intensive activities trying to solve a system-engineering problem. Natural language processing techniques were developed in order to handle human languages (i.e. open-ended ambiguous systems). By definition, computer systems are closes and finite (i.e., ultimately everything does reduce to a 0 or 1). If natural language processing techniques have never been proposed to solve similar problems of managing interfaces on single-processor systems such as mainframes, there is no reason to result to this technique on distributed systems. If space permits, frameworks for multithreading, time management, object management and multicast will be included.



To unsubscribe from the Z-ARCHIVE-SIW-CFI list, click the following link:
https://discussions.sisostds.org/index.htm?SUBED1=Z-ARCHIVE-SIW-CFI