Overview

The current generation of tools with their open application interfaces, object models, and client-server capabilities enable a new approach to building engineering environments.

Modern engineering environments address many diverse objectives, for example:

  • Facilitate best practices
  • Support concurrent engineering processes
  • Enable distributed teams
  • Enhance productivity.

These objectives lead to large numbers of requirements for specific tool capabilities and interfaces among tools. To satisfy all the requirements, an environment must include many kinds of tools each providing one or more capabilities to support one or more tasks in the engineering process:

  • Engineering tools, supporting engineering disciplines at different levels in the system development process
  • Office automation tools
  • Process management tools
  • Project management tools

Because the engineering process is iterative, similar tasks (such as document production or requirements management) occur many times at different process levels. Tools designed for an engineering discipline (e.g., software or chip design) provide some support for these repeated, common tasks. There are also, however, task-specific specialty tools such as desk top publishing systems available to support a specific task no matter where it occurs in the process. Repeated, common tasks challenge environment builders to select the right enabling tool for each task occurrence. Most environments use both of the possible approaches:

Choose a task-specific tool and provide an interface between it and the engineering tool(s).
This approach allows users to employ the same tool each time the repeated task occurs in the engineering process.
Choose to perform the repeated task with the engineering tool being used at the time the task must be done.
This approach lets users stay within the engineering tool best suited to the engineering task at hand, but may require very different user operations to perform similar tasks.

In either approach, additional tool interfaces are needed to move information between the engineering tools used at different levels in the process. Interfaces based on file transfers between tools are at best satisfactory; it is difficult to make them mechanically seamless. But at a more fundamental level they require a mapping between not quite similar types of objects and, often, massive duplication of information. Information quality, ownership, and integrity present challenging problems.

The new generation of tools offers much better interface solutions. Most recently released tools are true multi-user, client-server tools. They share an object-oriented view of their user visible information. Intended to be members of a tool community, they provide open application programming interfaces (APIs), letting users build their own client applications and enabling interoperability.

Interoperability occurs when tools cooperate seamlessly in real time. Each tool maintains its own information; information is not duplicated, but pointers may be kept to data in other tools. When tools must share information, the tool that needs information may act as a client, invoking the services of the other tool to provide information and possibly to present it to the user. Many task-specific tools function very well as clients to engineering tools. When users need integrated information from several tools, a user-developed application may act as a client to several tools and allow the user to manipulate information in a tool-independent manner.

This paper explores three types of interoperability:

  • An Information Presentation Client: Microsoft Word as a client to an engineering tool.
  • An Interoperability Client: A client that integrates two engineering tools: RDD-2000(tm) and Rational Rose.
  • A Background Client: A client-server implementation of Integrated Design to Cost (IDTC) in which an engineering tool client calls upon a background PRICE client to compute costs.

The Information Presentation Client

The PC software marketplace is flooded with tools that allow users to format, manipulate, and present information. Such tools include desktop publishing tools, spreadsheets, presentation development tools, and programs that produce graphics ranging from simple bar charts to 3-D plots. All of these tools are useful for communicating the results of engineering work. Many are also useful for doing certain kinds of editing of engineering information. While many engineering tools provide some of the information presentation capabilities of some of these tools, no engineering tool will ever match the capabilities the user can assemble by choosing the “best of breed” for each type of presentation tool. It is far more sensible to use existing information presentation tools to view engineering information. Three recent technology advances have made this feasible:

  • Most new generation tools (those released in the last year or so) provide an API that allows tool capabilities to be invoked by programs. This lets application builders develop sequences of tool operations that users can access by clicking a button or selecting from a menu.
  • Most new generation tools support at least a subset of object semantics. They allow application developers to associate objects, attributes of objects, and relationships between objects with tool capabilities.
  • Client-server tools are designed to facilitate development of new clients through their APIs as well as by their own development teams.

These capabilities make it possible to build applications in which an information presentation tool is extended to act as a client to an engineering tool. Using a presentation client a user can:

  • Build or select queries to send to the server part of an engineering tool.
  • Control how the resulting information is mapped to the user-visible structures of the presentation tool.
  • Manipulate and reformat information using the familiar capabilities of the presentation tool.
  • Edit certain kinds of information and return it to the engineering tool server.

Types of Information Presentation Clients

It is possible to develop two types of information presentation clients:

  • Task specific information presentation clients.
  • General-purpose information presentation clients.

Task specific information presentation clients are designed to support a specified task. They are most useful when they support tasks such as requirements reviews that are performed many times by many persons who seldom interact directly with the engineering tools. The detailed requirements for a task specific client are driven by the engineering process and the allocation of tasks to tools. (See Malcolm 1995 for additional information on process driven integration.) Task specific clients are easy to build, and often require little or no user training. However, they may not be reusable in other process steps or by other programs. General-purpose information presentation clients can be used to perform a variety of tasks in many places in the engineering process. They allow the user to:

  • Select the engineering information to be presented.
  • Determine where the engineering information will be placed in the presentation tool.

Their flexibility makes them usable in many process steps in many programs, but they are relatively expensive to build and use. Developing an intuitive way to allow users to select and map information will require many iterations, and users generally require some training in the selection and mapping mechanisms. On the other hand, an experienced user can use the selection and mapping mechanism to build a task specific version of the client for a less experienced user.

Information Presentation Client Example

The RDD-Word Interface (RWI) client for Holagent’s RDD.COM is an example of a general purpose information presentation client:

  • The RWI client lets users populate sections of Microsoft Word documents and Word tables.
  • A menu added to Word provides a list of queries (Multi-Element Views) available in the RDD.COM server. Each query determines a collection of objects (RDD.COM Elements) that will be sent to the RWI client. A second menu provides a list of attributes for each type of object. The user picks a query and attributes to populate each section or subsection of the document, or each column of a table.
  • Users who do not wish to learn how to generate a document using the RWI client may view and edit information-using documents created by others.

Users can employ Word capabilities to:

  • Format the information provided by the server.
  • Add text, such as section headings, that did not come from the server.
  • Add illustrations.
  • Users can edit attributes in the Word document and return the new values to the server, creating new versions of the edited objects.
  • Because the RWI application is a client, it communicates efficiently and seamlessly with the server. It avoids clumsy file transfers and duplication of information, and lets users view up to date information via Word.

The Interoperability Client

The engineering community is served by a wide variety of tools addressing many different kinds of engineering work done at many different places in the engineering process. Most engineering environments employ one or more general tools as well as more specialized tools for individual engineering disciplines. Engineers using general tools must share information with those using specialized tools. In first generation tools, the information was printed from one tool and keyed into the next. In later tool generations the information was transferred by files and stored in both tools. File transfers were seldom seamless or convenient, and duplicated information was seldom consistent.

Like the current generation of information presentation tools, the current generation of engineering tools support open APIs, object semantics, and client-server interactions. These capabilities make it possible to build clients that inter-operate with two or more engineering tool servers.

Effective use of such interoperability clients requires some consistency of the object semantics among the tools in the engineering environment. To ensure this consistency, environment builders must:

  • Document the engineering process. (See Tronstad et. al. 1993.)
  • Allocate the process onto the engineering tools.
  • Identify the interfaces between tools and the information that forms logical connections across these interfaces. Typically these logical connections are either:
    • Relationships from an object in one tool to a relationship target in the other.
    • Or, an object in one tool that has some attributes that are only used in a second tool.
  • Allocate each object to one and only one tool for data management and configuration management. Sometimes an object will need to be restructured as a composition or collaboration of objects, so that appropriate parts may be allocated to different tools.
  • Add appropriate attributes to the objects to represent the logical connections.

Once the logical connections have been built, applications can easily navigate among objects managed by several tools.

Types of Interoperability Clients

The kinds of information that are currently shared via files suggest that two types of interoperability clients are needed:

  • Traceability editors allow engineers to focus on the information at tool boundaries. They are particularly useful when most work is done in one tool or the other, but traceability links must be maintained among the tools.
  • Context viewers allow engineers who are working in one tool to see and perhaps comment on (but probably not change) information from other tools.

Interoperability Client Example

While Holagent has not yet released an interoperability client, one has been developed and is being tested in cooperation with one of our customers. After it is released to that customer, Holagent will evaluate turning it into a product. It links RDD-100 with Rational Rose, and has been designed to be ported to RDD.COM in a later release. The current implementation uses RDD-100 as a server via the RDD-100 API that supports the RDD-100 RWI (Word) product. It provides both context viewing so that the Rose user can see system level requirements from RDD-100, and traceability editing so that artifacts of the software engineering process can be linked to RDD-100 elements. It supports the following logical connections in the first release:

RDD: Scenario Rose: Use Case
RDD: RealWorldObjectType Rose: Class
RDD: Requirement Rose: Class Specification Property
RDD: Component of type CSCI Rose: SubSystem

Additional connections are planned for subsequent releases.

The Background Client

A number of engineering tools provide computation services to engineers working at various levels of the engineering process. Tools are available to solve many kinds of mathematical equations, as well as to roll up budgets and compute costs. Just as many engineering tools duplicate some of the capabilities of information presentation tools, many include some of the capabilities of these computation tools. But, again, the “best of breed” for any specialized computation is usually a specialist tool.

Like the current generation of information presentation and engineering tools, computation tools support open APIs, object semantics, and client-server interactions, allowing computation tools to function effectively as clients.

Unlike presentation tools and engineering tools, computation tools usually have little to say to the user. A computation tool often acts as a background client that:

  • Is invoked by an engineering tool client that interacts with the user.
  • Requests certain values from the server.
  • Interacts with the user only in peripheral ways such as displaying a progress bar, allowing a choice of options, or handling errors.
  • Uses values from the server to perform calculations and return results to the server.
  • Returns control to the engineering tool.

Background Client Example

While Holagent has not yet implemented a background client, this approach is our current candidate for our port of Integrated Design to Cost (IDTC) to RDD.COM. IDTC is a collaboration between RDD-100 and PRICE, a parametric estimating tool from PRICESystems. In the current IDTC implementation:

  • Engineers use RDD-100 to build a Component hierarchy and populate attributes of Component elements that will be used to compute costs.
  • RDD-100 produces a file of the Component information that PRICE reads.
  • PRICE uses the information in the file, along with PRICE parameters that tailor its computations to needs of a particular program, to compute costs.
  • PRICE produces a file of cost information that RDD-100 reads.

This implementation requires the engineer to move files around and change tools each time he wants to compute a cost. The proposed background client implementation would make a seamless process and facilitate what-if analysis:

  • Engineers use an RDD.COM engineering client to build a Component hierarchy and populate attributes of Component elements that will be used to compute costs.
  • The engineering client invokes the RDD.COM PRICE client and hands off the user’s RDD.COM context to it. This ensures that the PRICE client “sees” only the subset of engineering information that the user is working on, and is constrained by the same read/version permissions and configuration management controls as the user.
  • The PRICE client uses the information in the context, along with PRICE parameters that tailor its computations to needs of a particular program, to compute costs. If appropriate, the PRICE client displays progress bars and may provide error messages to the user.
  • PRICE places cost information in the user’s context and returns control to the engineering client.

Summary

The current generation of tools with their open APIs, object models, and client-server capabilities enable a new approach to building engineering environments. “Best of breed” tools for information presentation and special computations can be effectively integrated as clients to engineering tools. Engineering tools that operate effectively at different levels of the engineering process can cooperate to provide users with context information from other engineering levels and make it easy to establish inter-tool traceability. Data integrity can be improved since there is no need to duplicate information and tools can cooperate in ways that are seamless to the user.