Position Paper for the OMG/DARPA Workshop on Compositional Software Architectures

Component Specification and Conformance:
What Components must Expose to Compose

Bob Hodges
Senior Member Technical Staff, Texas Instruments
Currently Assigned to SEMATECH
bob.hodges@sematech.org

Background

Since 1991 SEMATECH has coordinated the efforts of its member companies and their Manufacturing Execution System (MES) suppliers to define an object oriented application framework for semiconductor manufacturing. Through an iterative series of specification releases and feedback cycles, the SEMATECH CIM (Computer Integrated Manufacturing) Framework is now nearing its final revision under the SEMATECH banner. These semiconductor manufacturers and MES suppliers, along with counterparts from around the globe, are now working to leverage the CIM Framework Specification into a healthy marketplace of components that can compose to meet the software needs of the next generation wafer fabrication factories. This process involves efforts to ballot and adopt the CIM Framework specification within the Semiconductor Equipment and Material International (SEMI) Standards Organization and to collaborate with other industries to adopt MES specifications within the Object Management Group through upcoming Request for Proposals.

This position paper outlines technical issues with the specification of standard manufacturing components and describes some of the approaches the SEMI CIM Framework Task Force is considering to help address those issues.  It also links the manufacturing domain efforts to specify the CIM Framework with the broader activities of the OMG to adopt a Business Object Facility to solve many of these same problems for many business domains.

The CIM Framework Approach to Component Specification and Composition

The CIM Framework consists of a collection of components defined as part of an object oriented application framework.  These component specifications are intended to serve as contracts for independently developed, but interdependent software implementations that compose and work together. To achieve this result, we must: In the final analysis, the measure of our success will be the multi-supplier availability of successful, conformant products that can actually compose and work together in production factory installations.

Partitioning

The SEMI CIM Framework Task Force partitioned the CIM Framework into nine "sub-frameworks" containing a total of thirty components. Together with a set of abstract interfaces for base types, a technical architecture document, and an overarching structure and functional architecture we will manage the CIM Framework as twelve separate specification documents.  The twelve parts are listed here. In arriving at this structure, we considered a range of partitions from a single document for the entire framework (which is what SEMATECH has done) to a separate document for each component. The key issue we encountered in defining our partitioning was one of granularity. Some of the contributors wished to interpret the sub-frameworks as larger course-grained components. This allowed the possibility of unspecified interactions between the contained implementations and seemed to map more closely to product boundaries of current solutions. While this interpretation is pragmatic when  considering current product implementations, it limits the potential for more flexible composition of future solutions. It could also tend to lock in current product packaging boundaries.

Another Task Force consideration was the need to keep components grouped in framework structures that emphasized the patterns of interactions.  Collecting cohesive sets of components together was deemed necessary to aid  human understanding of the individual components.

The final granularity interpretation adopted by the Task Force was that each component within a sub-framework be considered an independently composable unit. Further, we assume that components are  not coupled to one another except through the specified dependencies of the framework. This interpretation then leads to the next issue:  how do we adequately specify the components so that hidden interactions or dependencies are not needed to implement working solutions?

Rigorous Specifications

The SEMATECH CIM Framework project adopted a specification structure based on the OMG Object Management Architecture. We continue to supplement OMG IDL with Rumbaugh OMT models (intended to be migrated to UML) to address additional exposed semantics.

IDL gives us the foundation for specifications:

Supplemented with extensions for: We still have a long way to go to achieve the level of rigor required to specify independent, but composable components.  Our specifications do an adequate job of representing the server-side of the specifications.  We define the operations offered, and the meaning of the information exchanged through those operations.  We also show the events that the components are expected to generate.  Where we encounter difficulty is in specifying the client side of the dependency.  What are the assumptions about the operations a component requires, the events it consumes, and the collective behavior that it exhibits through the interactions with the other components?  While we have captured some of these dependencies with models, we have not achieved the rigor needed to drive conformance testing of collaborative behaviors.  Without additional rigor in the specifications, there is inadequate foundation for independently developed and composable components.

As a co-submitter to the OMG Business Object Facility RFP, SEMATECH is helping OMG move toward a Business Object Facility and Component Definition Language to further strengthen our specification toolset. The adoption of a meta-model and specification language that supplements IDL with the required concepts, that is expressible with an unambiguous syntax, that is directly mappable to the existing IDL interfaces, and that supports conformance measurements will be a needed first step.  Then we will be better prepared to tackle the challenging task of filling in the meaning of the behaviors and dependencies that must be exposed to enable composition.  While object modeling, especially with the recent adoption of a standard Unified Modeling Language from OMG, forms the conceptual basis for the semantic specifications, we still need a still more narrowly targeted mechanism for capturing the contracts for framework components.

Conformance Points and Levels

The CIM Framework Task Force is still working to define the specific conformance points for the CIM Framework. While we agree that our goal is conformance at the component level, current products are still evolving toward component structuring and may be packaged to conform at a courser granularity for some time to come. This would mean that products may support all of the required interfaces and behaviors for a set of components, but may not be fully decomposed and substitutable at the individual component level. In order to chart a path from the present reality toward the target of independent, composable components, we will need to define incremental ways to define and measure conformance.

We have proposed the following types of conformance for further consideration and definition. Each of these levels may require different measurement approaches to validate products against the specification.

Each of these conformance levels are progressive, in that they build upon prior levels and are necessary for the subsequent levels.  Without architectural conformance, there is no sound basis for a common syntax.  Without the syntactic specification of exposed interfaces, there is nothing to hang the semantics on.  Without exposed semantics, there is no chance for true substitutability.

The Component Specification Challenge: Expose and Minimize Necessary Coupling

Our collective experience with the CIM Framework has revealed some tension between exposing semantics and hiding implementation details. The use of IDL already couples clients to servers through exposed interfaces and couples components to one another through inheritance. Richer semantic specification exposes still more coupling through delegation and dependencies across components. While we aspire to minimize coupling, we recognize that suppressing semantic content doesn't necessarily reduce coupling, it often just pushes it into an underground system of hidden dependencies.  The coupling will still be there in implementations and may impede progress toward independence and composability of components.

By strengthening specification content and rigor we can expose the necessary areas of coupling between components. Then we can work from that known base to encapsulate and hide as much as possible to minimize the coupling, enable implementation choices, foster innovation and increase healthy competition. Our challenge is to specify and agree on what must be visible to meet our objectives of partitioned and composable components for MES.

Links:

SEMATECH

SEMATECH CIM Framework

SEMI Standards

SEMI CIM Framework Task Force - Europe