SEE Integration to Support Megaprogramming - Semantic Scholar

SEE Integration to Support Megaprogramming Jim Hamilton Boeing

Abstract Megaprogramming is a system development approach based on building products from a reusable set of architecture-based assets by a product-line organization. A megaprogramming SEE is tuned to support development of products in a specific product-line instead of being geared toward general purpose automation to support development of any product. This paper discusses the development of a SEE which is based upon an object oriented repository and is specifically targeted to the product-line of air vehicle training systems.

To demonstrate the applicability of megaprogramming on United States Government projects, the United States Advanced Research Projects Agency Software Technology for Adaptable Reliable Systems (STARS) program is teaming with three United States Department of Defense development projects. As one of the STARS program prime contractors, Boeing is developing a SEE which will be used on a United States Navy project to develop a flight instrument trainer. We are using the Software Productivity Consortium’s Synthesis Process to analyze the air vehicle training system (AVTS) domain. A part of the Synthesis process is development of a SEE to support the building of products within a product-line. The key elements of our SEE automation approach are:

1. Introduction

•

automation and tooling to support process definition, modeling, and enactment,

Megaprogramming is an engineering approach to the development of large-scale, complex systems that underscores the ability to exploit commonness of system architectures, and system components, across products within a specific domain. Megaprogramming requires organizations to invest in product-line management strategies with an emphasis on reuse of system architectures and well defined and continuously improved upon organization infrastructures and development processes.

•

automation and tooling to support domain-specific reuse,

•

flexible framework services to support tool integration and interoperability, and

•

selection and adoption of a suite of standards, supporting tool interoperability across heterogeneous hardware platforms.

Central to exploiting this product-line management philosophy are the notions of: establishing, maintaining, and improving well defined, repeatable, and measurable processes that guide and support system development; defining and utilizing domain architectures and models that enable the identification and classification of system components that can be reused to populate those architectures; and maintaining and evolving software engineering environments that can be adapted and tailored to the domain and the development projects within that domain.

The notion of a process-driven environment [7] imposes requirements and constraints on a SEE to support process definitions that can be adapted to a specific application domain, and that can be dynamically tailored to the needs of the software project. Our SEE provides process infrastructure elements that support process definition and enactment mechanisms which are used to guide and support software development through activity enactment and work flow control. The SEE supports the ability to establish, and unobtrusively collect and analyze metrics used to improve the defined process.

STARS has emphasized domain-specific, reuse-based development, guided by a domain architecture, to support reuse in-the-large. Although a reuse warehouse of components may provide some measure of productivity gain, in order to achieve the expected levels of productivity envisaged within the megaprogramming approach, a reusable architecture within a domain is needed to support product-line development. The Boeing STARS SEE provides framework mechanisms supporting the definition, evolution, and maintenance of a domain architecture, together with a taxonomic scheme that supports classification, search, and rule based retrieval of domain assets supporting a specific project, consistent with that project’s defined, software development process.

2. SEE framework services The Boeing SEE provides a set of commercially available framework integration services based on industry standards. The STARS Standards Portfolio [1] (summarized in Table 1: STARS Standards Portfolio) lists the standards that the STARS program developed through cooperative meetings involving the STARS prime contractors; Boeing, IBM, and Paramax; and STARS program commercial counterparts; DEC, IBM, and Unisys (Paramax is now teamed with Hewlett Packard). Involvement of commercial companies served two purposes for the STARS program: (1) insurance that the standards selected would have commercial support, and (2) help in analyzing the vast number of standards related to SEEs.

Figure 1: Standards Available for SEE Integrators illustrates the dilemma facing a tool and/or SEE developer when selecting standards to base their product offerings upon. Figure 1 only shows a small subset of the available standards and yet the number of pages that a developer must analyze in this subset is in the thousands. Exacerbating the standards selection problem is the overlapping functionality provided by many standards. The STARS Standards Portfolio enabled us to focus our resources on a limited set of standards that cover the breadth of framework services needed for our STARS SEEs User Interface P H I G S

X Windows

O p e r a t i n g S y s t e m

Motif

T E R M

POSIX

FTAM V T P D O C NFS S E I X.400 X.500 T C P / PCTE I P

DCE Tools PCTE

A S I POSIX S

Post Script

P I C R T D E S

CDIF

G K S

A T I S

SGML

CGM

C o m m u n i c a t i o n S e r v i c e s

etc

Data Services

Table 1: STARS Standards Portfolio Framework Service

Selected

Considering

Object Management Services

IRDS ATIS, ECMA PCTE

Process Management Services

IRDS ATIS, ECMA PCTE

Communication Service

X.400/500, FTAM, Telnet, SMTP, FTP

User Interface Service

Motif, X, GKS, PHIGS

Policy Enforcement Service Framework Administration and Configuration Services

OSF/DCE, NFS

ECMA PCTE, POSIX POSIX, DCE, Motif IRDS ATIS, ECMA PCTE

Figure 1: Standards Available for SEE Integrators STARS identified two lists of standards which are shown in Table 1: STARS Standards Portfolio. Column 2 lists standards selected by STARS and column 3 lists standards under consideration. Column 1 of the table is organized according to major sections in the NIST/ECMA Reference Model for Frameworks of Software Engineering Environments [2]. One area that evoked many long discussions [3] is in the area of object management services or sometimes called repository interface standards. The STARS program concluded that there were two repository standards, IRDS ATIS and ECMA PCTE, that should be further investigated before any selection could be warranted. The immaturity of

these standards and the lack of available products for ECMA PCTE severally limited our ability to make a definitive choice. Boeing selected an ATIS based repository based on both strategic and technical reasons. Strategically, our commercial counterpart has made a significant investment in ATIS based repository technology and there are more ATIS based SEEs available from commercial companies. Technically, ATIS provides an object oriented interface with extensible object behavior [4], whereas ECMA PCTE only provides a core set of operations for an entity relationship model. ATIS, also provides support for critical process enactment services that are not available in ECMA PCTE. Another consideration is that ECMA PCTE not only provides data integration services, it attempts to provide a complete set of interfaces across several framework services in order to support tool portability. In our SEE, POSIX serves as the tool portability standard to the underlying computer hardware [5]. ATIS is defined in an manner that makes it independent of underlying portability platforms such as POSIX.

3. Framework integration capabilities

all user defined types (where types include methods, relationships, and attributes). Its capabilities are similar to forms based interfaces available from many relational database products. The user interface provides basic forms editing on objects defined in the database, and views for displaying objects by type and to display related objects via traversal of repository relationships. The capabilities available in the framework for providing views of repository data are fairly complete. The coupling available between the user interface customizer and the repository is extremely important. This is where the power of an object oriented repository really pays off. Since new methods are defined by extending the repositories types and since the types are self defining, then the user interface customizer can be easily tied in with the repository. An example is extending the type hierarchy to include an Ada source code type with a method to provide language sensitive editing via a message called edit. The extensions to the type hierarchy can be determined by the user interface customizer via standard calls to the repository and these new extensions are presented to the user via the customizer’s user interface. It is then a simple operation for the SEE integrator to define a menu item called ’edit’ and attach it to the message edit on the type Ada source code.

Figure 2, Framework Integration Capabilities, depicts framework integration services as three dimensions of increasing integration capabilities [6]. The three dimensions are control, data, and presentation. Along each axis of the graph, an industry standard and an associated COTS product are shown next to a level of integration capability. A central feature of our framework-based environment is an object-oriented repository, based on A Tool Integration Standard (ATIS) [7]. ATIS defines an extensible object-oriented type hierarchy that supports both control and data integration. Digital Equipment Corporation’s CDD/Repository product has an ATIS interface and a user interface tool, CDD/Administrator, which is integrated with the CDD/Repository meta-model.

The user interface customizer provides filters into repository data based upon object types and additionally by user defined roles. The user interface provides an object oriented view into the repository where available actions on objects are directly related to the available methods on object types. This filtering is not sufficient for some complex types due to the vast number of methods that may be defined for an object. Therefore, the user interface supports definition of user roles such as a configuration manager, a project manager, or a software developer which further filters available actions on objects. Using the edit example on the Ada source code type, a software developer would have visibility to the edit message and a project manager would not need such visibility.

3.1 Presentation Integration

3.2 Control Integration

Motif and the X Window System are the underlying presentation integration capabilities within the framework. One of the reasons Motif was selected, over other user interface toolkits, is its User Interface Language capability which was not available with other user interface systems. Another reason, was its availability on most workstation hardware platforms. Layered on top of Motif is a user interface customizer, CDD/Administrator, that is coupled to the repositories information model including

Central to our process enactment capabilities is the ability to extend the object oriented repository via addition of new methods and pre/postambles on the methods. A similar capability is being researched by IBM with a repository interface called OOTIS. This capability is not found in relational database products and is not available in the ECMA PCTE standard or in PCTE products. The ANSI X3H4 IRDS standard committee has prepared a

specification for an object oriented repository interface [7] which includes pre/postambles on methods.

within the product-line family is understood. To support both reuse and process integration a framework must provide an extensible entity relationship model. An ATIS based repository provides capabilities beyond relational databases by providing for storage and retrieval of complex objects such as drawings, images, and documents. Additionally, ATIS provides a self defining type hierarchy so that the meta model for objects, as well as the object instances, are available for use in integration efforts. The ATIS type hierarchy is a single inheritance model where attributes, relationships, and methods can be reused or refined. The ATIS model could be improved if it provided multiple inheritance instead of single inheritance.

In the control integration dimension, the framework provides services for supporting operating system process control via POSIX, distributed computing support via DCE and OMG/CORBA, message passing between tools via OMG/CORBA, process enactment via control points and policies, and process definition via a language called Agents, Activities, and Artifacts (AAA) [8]. The majority of our integration is provided via extensions to the ATIS model via a mechanism named control points and policies [9]. AAA provides a high level language for defining processes which are then translated into control point and policy enacment code.

3.4 Integration of Tools 3.3 Data Integration

In an ideal world, tools would publish interface specifications for their internal functions and for their data models. Then SEE integrators could integrate tools at whatever level of granularity that makes sense for the process being automated. However, only a handful of tool vendors are providing interface specifications. User interface customization of tool menu items is also rare but

Data integration is a crucial element for automation of process and reuse. Process definitions include relationships between activities, input and output artifacts, and the agents that perform the activities. In a leveraged reuse process, the product-line architecture is well defined and the variability of the assets used to build a product

Control Integration (high level) Process Definition Process Enactment Methods Event Triggers IPC/RPC Execution (low level) X

AAA Language Translator Control points and policies CDD/Repository (ATIS) ACAS (OMG CORBA) OSF/DCE POSIX POSIX

File Non-Graphical

MOTIF

Windowing Mechanisms CDD/Admin VUIT (high level)

CDD/ Repository (ATIS)

RDB (SQL)

Database

Entity Mgt System

Object Mgt System

"Look and Feel" Tool Kits UI Customiser

UI Generators

Presentation Integration

Figure 2: Framework Integration Capabilities

Scale is "capability"

ROAMS (ATIS Extension) Asset Library

Data Integration (high level)

highly useful for SEE integrators. The framework should provide services for defining new methods on objects that are directly related to tool interfaces. ATIS defines a model for tool registration and a set of method types that is sufficient for registration and invocation in most cases. An additional asynchronous method type would be beneficial for supporting process enactment. This asynchronous method type would support execution of the method’s postambles after a notification event was received from the external process running the asynchronous method.

to still provide effective process enactment via the repository methods and user interface. This integration relied on a programming interface to the project management tool’s database and the object oriented extensibility provided by the ATIS-based repository. Building the developer’s view of activities was very easy and required little coding on our part due to the user interface customization facilities provided by CDD/Administrator.

5. Conclusion 4. Integration of a Project Management Tool During the integration of any tool, a SEE developer must decide what level of integration they require in order to effectively support their defined process and their reuse needs. The primary driver for integration is data integration into the overall information model that is managed by the SEE. Fine grain integration is not necessarily the optimum approach for all tools. In our integration of a project management tool, some data was integrated into the repository from the project management tool and other data was left to the auspices of the project management tool. The SEE’s repository controls user access to and configuration management of artifacts associated with activities and the project management tool manages scheduling information associated with activities. To determine how to integrate a tool into a SEE, an operational concept should be developed that takes into account the strengths of the tool. The scenario we developed is based on the strength that the planning tool had for scheduling algorithms, user interface views of project management data, and project management reporting facilities. What the tool didn’t provide was a capability for defining relationships to development process work products such as source code, and documents. Our implementation also takes into account the different views of project management that users of a SEE require. In our SEE, developers of work products are presented individual activities to perform via the repository user interface, and project managers are presented global views of the project via precedence networks and work breakdown structures. As developers complete their activities, repository methods update the project management tool’s database with the appropriate status. The repository then queries the project management tool’s precedence network and updates the activities presented to developers. This integration enabled us to make use of the multiple views of project management data provided by the available tool and

Historically, there are many contributing factors in the poor performance of SEEs in their ability to improve productivity and quality: 1) General purpose instead of product-line specific SEEs and processes 2) Inadequate process definitions 3) Paucity of reusable assets 4) Overlapping and confusing SEE framework architectures and standards 5) Insufficient integration interfaces to tools 6) Inadequate computing hardware throughput (networks and CPUs) 7) Inadequate framework services The first three factors are organizational issues that can not be overlooked and the STARS program is addressing these within demonstration projects to prove the concept of megaprogramming. Overlapping SEE framework standards are difficult to resolve and our approach has been to attend and influence a limited number of standards efforts. The STARS program is participating in standards organizations with most of our efforts directed toward ANSI X3H6 CTIM. Current directions towards convergence and harmonization in standards organizations are encouraging, but there is still significant overlap in standards committee charters. Tools are beginning to provide ’open’ architectures by providing some published interfaces to their internal methods and data, and some user interface customization facilities. However, this will continue to be the most difficult integration issue for SEE developers in the foreseeable future. The last two factors are becoming less of an obstacle and will continue to improve dramatically in the next few years. Performance issues related to fine granularity of data integration are being overcome by recent advances in computing hardware. Functionality of framework products, from commercial

vendors, is finally at a level that effective integration can be achieved and organizations that take a product-line approach to SEE automation will begin to reap rewards. Effective process automation and reuse can be achieved by targeting a SEE to a specific product-line. An extensible set of SEE infrastructure services is essential to support tailoring of SEE capabilities to support specific needs of projects within a product-line organization. An extensible object oriented repository provides many of the key infrastructure services to support dynamic process tailoring, and to support definition and improvement of product-line assets. The emergence of object oriented repository products from commercial vendors is enabling SEE integrators to develop effective automation solutions. Our SEE integration efforts, using commercial-offthe-shelf products and AVTS product-line assets, are providing us with encouraging results in overcoming the limiting factors mentioned above.

References 1. STARS Standards Portfolio (SSP) for the STARS SEE, James Hamilton, et. al.; Boeing STARS CDRL 4032R, 6 April, 1992. 2. Reference Model for Frameworks of Software Engineering Environments, Version 2; NIST & ECMA/TC33/TGRM, 13 November 1991. 3. Report on the STARS Conference on Frameworks Convergence, David J. Carney, et. al.; IDA Document D972, June 1991. 4. Core Environment Services Required for Process Definition and Enactment, James King and John Anderson; Practitioners Guide to STARS Process Concepts; Boeing STARS CDRL 5105-1, 30 October 1992. 5. Ada Program Support Environments: A Good Idea Overcome by Changes, William M. Hodges; Proceeding for TRI-Ada 1992. 6. Future Direction for Evolution of IRDS Services Interface, X3H4/92-161, 16 September 1992. 7. Proceedings from STARS 92. 8. The EIS Execution Engine and the AAA Process Engine, John Kimball; Process Sensitive SEE Architectures Workshop, August 1991. 9. Process Enactment Mechanism in an ATIS Environment, Thomas Peterson; Compendium of Process Concepts for Practitioners, Boeing STARS CDRL 5105-1, 30 October 1992.