Table of Contents

An Object Base Design Mechanism for Interactions Between an Ada 83 applications and X Windows

by Frank Hollenbach

Abstract: An Object Based Design (OBD) mechanism has been created as a variation of the Model-View-Controller (MVC) paradigm used by the Smalltalk programming language. The OBD mechanism encompasses the developmental application and three Commercial Off-the-Shelf (COTS) software packages: the UNIX operating system, the X Window System, and an Ada Run Time Environment (RTE). Although examples are provided that deal specifically with the Joint Service application, the Joint Tactical Information Distribution System (JTIDS) Network Design Aid (NDA), the mechanism can be abstracted to a general framework.

1. Overview

With the advent of the X Windows system, the need exists for a coherent framework to effectively handle interactions between Ada and X windows. This paper will discuss an Object Based Design (OBD) mechanism for interactions between an Ada83 application and X Windows. The specific application is a Joint Service support software tool that has been under development since April of 1991. Although examples are provided that deal specifically with the application, the Joint Tactical Information Distribution System (JTIDS) Network Design Aid (NDA), the mechanism can be abstracted to a generic framework. The NDA is being developed in an evolutionary manner through multiple builds that make use of cluster development along with the wave front integration technique [1]. This approach required development of the OBD mechanism in the initial build to provide the working architecture that the remaining builds could utilize.

The OBD mechanism encompasses the developmental application and three Commercial Off-the-Shelf (COTS) software packages: the UNIX operating system, the X Window System, and an Ada Run Time Environment (RTE). The operating system provides the necessary operating system support (e.g., process scheduling, memory management, low-level peripheral device support) required to execute the application software. The Ada RTE provides the specialized run-time support required to execute Ada software. The X Window System is used to construct and implement the user interface for the application. In this case, the Ada/X Windows bindings are conceptually placed within the application. Figure 1 depicts the relationship amongst the software elements.

2. The OBD Mechanism

The mechanism has been designed as a variation of the Model-View-Controller (MVC) paradigm used by the Smalltalk programming language. A brief synopsis of the MVC is provided herein with more detail available in a Smalltalk text[2]. The MVC paradigm provides a mechanism to allow interaction between abstract objects and the visual display presented to the user. Figure 2 indicates the relationships between the MVC triad. Within this scheme, a model represents a design abstraction which a user will examine and/or modify. The view is an object that dictates how the model is to be displayed on the physical monitor. The actual display on the monitor is referred to as a viewport. The controller is an object that handles the I/O interactions (i.e. mouse and keyboard) for the viewports.


For the NDA application, the model is the combination of a network object which contains specific elements that are elaborated by the network designer for a network design and a view manager which tracks the various views that may be created, modified or destroyed for specific elements. The Network object is the highest level design abstraction for the NDA application. A view is a perspective of a specific element of the network object. In this instance, the X Window system suffices as the controller.

The Ada package was utilized as the class construct for this approach. Therefore, there is a one to one mapping of classes to Ada packages. The vast majority of classes identified within the design solution space have been "derived" from specific abstractions within the problem space dictated by the application requirement specification (e.g., Connectivity Matrix, Time-Line, etc.). Each of these classes shall provide for the reation/destruction/manipulation of instances of the class (objects) represented by the class. For example, the Connectivity Matrix class shall provide, through Ada type/object declarations and exported operations all of the software conventions necessary for the implementation/manipulation of the connectivity matrix design abstraction. Some limited use of inheritance was made through variant record class implementation.

In addition to these "derived" classes, other classes have been introduced into the design solution space in order to make the design complete. These classes are:

  • the Graphical User Interface (GUI), the VIEW_MANAGER and the numerous classes designated as VIEWs which provide for the implementation of the NDA's User Interface;
  • the MODEL_MANAGER which is utilized to manage all of the active models; and,
  • sublevel classes (e.g., COMSEC_XREF_TABLE_ROW_PKG) which are not directly derived from the application specification but are useful within an OOD methodology in helping to ensure that objects are coupled loosely. These components include rows of tables, columns of tables, and lists of objects.
    •

    For this framework, the model may be defined as the highest level abstract object that encompasses the abstract problem space. The model manager was introduced in order to provide a central, single entrancy mechanism to control re-occurrence of a model within a multiple model environment. As such, each object must be registered within one specific model at the point in time at which it is created. The design allows for extensibility by not excluding the possibility that in the future multiple models could be used concurrently. An NDA specific example of this paradigm is shown in Figure 3. A network object acts as a container of all of the abstractions applicable to a network selected by a network designer (e.g., connectivity matrix object, time-line object, etc.). Such abstractions are referred to hereinafter as "true objects".


    Figure 3 also suggests the use of clusters for the development approach. Initially, the underlying mechanism (MODEL_MANAGER, VIEW_MANAGER, and GUI) was established to create, modify and delete an object as well as a view. For this application, the clusters usually contained the true object, any component objects, the VIEW(s) of the object, and a REPORT object for Figure 3: NDA Specific Example of the MVC Paradigm Variation generation of a printed report. Typically, several clusters were developed concurrently and combined in a wave front integration.

    The GUI object exists to initiate the application and to control access to the various subsystems (or clusters) of the application. The network designer will be presented with selectable menu items from which a choice may be made. The act of making a choice (i.e., pressing a mouse button, hitting a carriage return, etc.) registers an event. X Windows acknowledges the event and handles it by passing execution to an application defined callback routine. The purpose of the callback routine is to provide the software necessary to process the network designer's choice. Therefore, the flow of execution of the application can be generally summarized as initiate the GUI (i.e. make selectable choices available to the network designer), wait for an event, handle the event, wait for an event, handle the event and so on. Note that the act of handling an event may generate other selectable choices. This process would continue until the user selects the event which terminates the application. Many of the selectable choices presented to the network designer correspond to software subcapabilities stated in the requirement specification (e.g., Delete Network, Create Network Repository, etc.). Within this design, all of the callback routines which will be used to handle these specific software subcapability choices are located within the GUI object. Consequently, each subcapability interaction begins with a routine within the GUI_PKG. Since the design uses the convention that only the GUI_PKG and view packages may interface with X Windows (in order to keep all other abstractions free of display considerations), these routines were placed within the GUI_PKG to allow for the generation of any required displays. For instance, the creation of a network repository requires that the network designer answer certain prompts. Since the DIRECTORY object is not permitted to interface with X Windows in order to generate the prompts, the CREATE_NETWORK_REPOSITORY callback routine within the GUI_PKG handles the prompting problem.

    Views are provided for a true object when the network designer requires to display and/or manipulate a true object on the screen. The views have been defined on roughly the requirements specification subcapability level. Within this design, a true object may be implemented without any regard to its physical display. A view of a true object (e.g. Connectivity Matrix View, Time-Line View, etc.) is an object which is dependent upon its true object for its content and whose implementation is based primarily upon the consideration of a physical display . The advantage of this dual object approach to displaying the contents of an object is that coupling of a true object to the GUI has been offset to its view object. Consequently, true objects may be designed and implemented with regards to interacting with other true objects without carrying the extra baggage of display considerations. In addition, different perspectives or views may be defined independently of one another.

    3. Typical View Creation

    The interaction between a view object and its associated true object is implemented in a traditional object oriented black box format. As such, a view acquires the content of its true object via exported operations applicable to its true object. Since many true objects are instances of "dumb" container classes (i.e. the container knows what it contains but not the format of what it contains), a view is typically generated in the following manner:

    Certain characteristics of a view object are noteworthy. First, a view object is generated in such a way as to correlate the value of each widget with the specific component(s) of the true object from which that value was obtained. This correlation allows for efficient updating of true objects via views. When the content of one displayed widget is modified by the network designer, the view may now update its associated true object on an individual component basis as opposed to requiring a complete regeneration of the true object. Granted, modifications to a subset of the true object components may still require a complete regeneration of a true object. Second, the implementation of a view object incorporates that view object's true object. In other words, each view object contains within itself its corresponding true object. Such an implementation is useful within the design in order to simplify the client data which is passed via X Windows to callback routines. Due to the definition of callback routines as defined under X Windows, only one parameter, the client data parameter, can be used to pass application specific information to a callback routine. If multiple objects would need to be passed as client data, as is often the case with views and their true objects, then a composite object containing the necessary objects would need to be created and passed as the client data. By allowing the view object to "contain" its true object, composite objects created solely for use as client data parameters are not necessary.

    4. Modifications to Objects

    Alterations to views and their associated true objects must be kept synchronized. This process is somewhat complicated since the relationship between a true object and the views of that true object is one-to-many (i.e. an arbitrary number of views can be created for a single true object). In order to handle this situation, the view manager is used. The purpose of the view manager is to track views on a true object basis in order to ensure dynamic view updating. The view manager is utilized in the following manner.

    This convention of using the callback routine within the GUI_PKG to provide displays is also employed to handle error messages. If an error is encountered during an operation on a true object, a package specific exception is raised. If no view package subprogram is available on the execution path to handle the exception, the exception is propagated back to the GUI_PKG which handles it. The exception handler within the GUI_PKG invokes the QUERY_ERROR routine within the package where the exception was raised. The QUERY_ERROR routine returns information regarding why the exception was raised. The GUI_PKG may then use this information to display a meaningful error message. Such a mechanism is used because it is not possible to pass parameters via Ada exceptions.

    5. Summary

    The Object Based Design MVC mechanism provides the capability for interactions between an Ada83 application and X windows in a structured fashion. Once the mechanism is implemented, the interactions amongst the related clusters of objects can be fairly easily replicated for different subcapabilities. In addition, a mechanism for true objects to update other related or dependent true objects has been defined. Of course, these relationships are dependent on the actual application, however, one-to-one and one-to-many dependencies have been implemented by the NDA application. The Object Based Design MVC mechanism is a viable framework that provides for expansion of the domain application.

    6. Future Directions

    The development group is pursuing a study of the applicability of Ada95 and how the new technology could be inserted into the application development project. The effort entitled "Ada 95 Architecture for the JTIDS NDA Software System" is co-sponsored by the Ada Joint Program Office (AJPO) and the Navy Advanced Tactical Data Link Systems (ATDLS) office (PMW-159) through the Ada Technology Insertion Program (ATIP). Initially, the two areas of thrust appear to be to make use of the new Ada95 language features in a limited fashion to better align the design with an object oriented nature by formally defining the objects as such and secondly, to make more in-depth use of inheritance to redesign the application. Additionally, recent publication [3] has provided a suggestion on an Ada95 MVC that should be considered.

    7. Acknowledgments

    The JTIDS Program Office (JPO), Hansom AFB has sponsored the development of the JTIDS Joint Service NDA. Additional support has been provided by the Navy ATDLS Program Office (PMW-159). The author would like to acknowledge the efforts of the NDA development team for their contributions to and refinement of the OBD mechanism. In addition, Ron Roadarmel, Keith Kreider, and Linda Malloy provided numerous suggestions that contributed to this paper.

    8. References

    [1] McGregor, J.D. and Korson, T.D., "Integrated Object-Oriented Testing and Development Processes", Communications of the ACM 37, No. 9, pp. 59-77, September 1994.

    [2]. LaLonde, W.R. and Pugh, J.R., "Inside Smalltalk Volume 2", Prentice-Hall, Inc., Englewood Cliffs, NJ 1991.

    [3] Sasine, J.M. and Toal, R.J., "Implementing the Model-View-Controller Paradigm in Ada 95", TRI-Ada '95 Proceedings, The Association of Computing Machinery, Inc., pp. 202-211, 1995.