Reuse Methodology and Implementation Appnote

The Satellite Communication Payload application was associated with an internal project at Lockheed Martin Astrospace Company at East Windsor, New Jersey. Our goal was to build a design reuse repository from the legacy data sources at Astrospace, and maintain it over the course of the demonstration period. Two incremental prototype RRDMs demonstrated some of the basic features of the Information Broker in the Astrospace environment, including the object-oriented class hierarchy, attribute-based searches, and web-based access.

The CPC was in a position to provide objects in a wide variety of functional categories which could be used both to augment the RASSP RDOCH and upon which to implement the demonstrations. The metadata about these objects promised to be rich in terms of the variety of naming conventions, data values/enumerations, units, data types, data formats and such. This was considered to be very important from the interoperability perspective. The data also demonstrated the concept of representing multiple implementation levels (e.g., concepts, designs and implementations from components to systems). Use of this diverse data set showcased important ways of accessing information to solve design problems at multiple levels like satellite beam coverage analysis down to communications circuit design. In addition, the ability to access information on concepts, trade studies, rules of thumb and detailed design from distributed sources is extremely useful. This showed how an organization can enhance the engineering process by encouraging reuse.

The CPC problem was a real world case for an integration of interest to Lockheed Martin, the Government and aerospace in general. The CPC had developed potentially reusable components in the past and was about to embark on many more to support the new generation of digital communication satellites. CPC was developing a "configure-to-order" to replace the traditional "design-to-order" concept for satellites. "Configure-to-order" required CPC to maximize the use of reusable components, assemblies and even systems. It required the ability to catalog and easily access information residing in a wide variety of sources including databases, product data managers, component information systems and document management systems. The system would have a wide range of users (e.g., systems engineers, designers, procurement specialists) each requiring a different "view" of the multiple data sources. This demonstration showed the proof-of-concept for providing these views and highlighted the types of features that would be necessary to integrate distributed heterogeneous sources for a engineering reuse application.

The process of building the reuse repository consisted of the following steps:

1. Interview design engineers at Astrospace to identify sources of legacy reusable design data.
2. Source the information, which consisted primarily of presentations, drawings, and some documentation from legacy sources and on-going projects
3. Develop a class hierarchy for the data available in a bottom-up fashion, identifying leaf-level classes and their attributes first, and abstracting common facets to form abstract superclasses
4. Populate the data in a repository with a web-based front end

The first interim implementation of the RRDM was created with classes and instances stored as static HTML pages. The documents were obtained either in electronic format or were scanned into GIF and PDF formats from paper documents. HTML links were provided from the design object class instances to the data objects (documents) that described the design objects. Documents could be viewed or downloaded as either HTML files, Adobe PDF files, or in their original format -- typically Microsoft Word or Interleaf format. Security was provided using the Netscape Secure Socket Layer (SSL) features. Only people accessing the system from authorized machines (verified by IP addresses), with an authorized user name and password were allowed access to the system.

This interim implementation of the RRDM lacked scalability, as the only means for searching for data was by browsing or doing text searches on the HTML pages. Sophisticated searches using attributes of the classes were not possible. To overcome these limitations, an object-oriented approach was used for the second RRDM prototype engine. An object-oriented database system was selected over a relational database for the following reasons:

1. The object-oriented reuse classification hierarchy could be mapped directly to C++ classes for implementation purposes, rather than simulating each class as several tables in a relational or object-relational environment (cumbersome and costly).
2. An object-oriented database system uses pointers to represent relationships between objects rather than object-ids and multiple table joins as in an object-relational DBMS. The RRCH implements numerous relationships between classes and between instances of classes. An object model seemed to be most appropriate from a performance perspective.
3. The object-oriented model is more expressive than other modeling methodologies such as relational, network, or hierarchical. It allows natural modeling of complex data types such as sets, arrays, and collections, and facilitates the definition of the behavior of the objects using methods derived from the constraints specified in Ontolingua or defined in source applications and repositories.

The second prototype for the satellite communications RRDM was implemented using ObjectStore, an object-oriented database management system with a C++ -based API. The class hierarchy was implemented and maintained through a C++ -based programmatic interface. The database was populated manually through a graphical user interface and through scripts with load files once the schema became stable. Complex attribute-based querying was supported in this implementation. Inverse pointers between design objects and the related data objects were implemented to maintain database integrity. Thus when new design objects were added or when a design object was deleted from the repository, the back pointers from the related data objects were automatically updated by the ObjectStore system.

Key lessons learned in the course of this effort are:

• Guidance for engineers is needed to clarify the definition of a reuse item and improve the reuse library population process
  • A considerable amount of data generated during the course of a design that is not normally considered reuse data should be, either on its own merit, or becuase it enhances the usefulness of other reuse items. This includes such things as descriptions of design intent, trade-offs performed, and candidate design selection criteria. Rejected approaches and the reasons for rejection are almost as important to a document describing the selected approach as the selected approach itself. Giving designers access to the thought processes of the reuse item creators enhances their ability to make good decisions about using the item. Although this type of data exists, because it is not considered part of a traditional data package, it is often hidden in reports and presentations, or worse, in somebody's notebook. Designers must be constantly aware of the reuse process and what types of data objects are of interest from a reuse point-of-view so that appropriate data is collected, described and stored over the course of the design cycle.

• The process for collecting and documenting reuse data must occur in parallel with the design process
  • Collecting data at the end of a project is a time-consuming and slow task. Once a project is over and people are assigned to new tasks, it is very difficult to recreate quality reuse data. A significant amount of data will be lost if the engineers are not consciously and continuously collecting what is needed to create a robust reuse object. Each organization must define what documents are important to the reuse community, basing their decisions on both the type of information normally generated during the course of a design, and the type of additional information that must be collected to support a reuse library.

• Domain experts must spend some time learning the classification process in order to be effective in their role in defining the class hierarchy and class attributes
  • For example, hardware engineers tend to classify objects on the basis of a physical hierarchy, instead of a functional hierarchy. Thus, a typical hardware hierarchy might be: System => Box => Board => Chip. However, from a functional point of view, "System" , "Box", "Board", and "Chip" have similar attributes: function, throughput, latency, power, etc. From a structural point of view, they also have similar attributes: size, weight, number of I/O, etc. As such, they would not belong in separate classes. Rather, "System", "Board", etc. would be a value for an "Implemented-as" attribute of the Design Object class. Familiarity with the classification concepts, along with examples, will assist the domain expert in defining a quality class hierarchy.

The final reuse prototype demonstration featured the integration of two distributed VHDL model repositories. It demonstrated support for uniform user access to source repositories with diverse implementation schema via the information broker.

The focus of the final demonstration was two-fold:

• to highlight the productivity gains realizable with the Sandpiper information broker as compared to conventional approaches or current best practices for queries against multiple heterogeneous databases, and
• to show the generality of the solution and its relevance to other government and commercial applications.

Two databases on separate machines were used to represent a distributed database. Both databases were searched with a single query from the Sandpiper information broker. Corresponding searches were performed on the individual databases using native search methods to verify the correctness of the results.

The first database was developed from Lockheed Martin Advanced Technology Laboratories-developed VHDL models primarily associated with the RASSP benchmark program and other internal libraries. These model libraries include performance and detailed behavior models for the UYS - 2 and SAR benchmark programs, and register transfer level (RTL) models from the RASSP Model Year Architecture effort. Metadata about these models is accessible through a keyword search engine developed by ATL. (The vocabulary for the keyword search engine was significantly enhanced as a side benefit of this effort.)

The second database was developed using VHDL models associated with the RASSP legacy information project managed by SCRA. These models are available through an HTML-link-based search engine developed by SCRA.