Joint Workshop for the Use of Models that Define the Data and Processes for Information Systems

Interoperability of Software Engineering Models: a PCTE perspective

Issue 2 - 4th September 1996

A position paper for the JTC1 workshop on standards for the use of models that define the data and processes of information systems, in Seattle USA from 9 to 13 September 1996

Abstract

1. Status of PCTE base standards

PCTE is defined in three standards:

• ISO/IEC 13719-1: Abstract specification
• ISO/IEC 13719-2: C binding
• ISO/IEC 13719-3: Ada binding

Changes in response to comments on these standards have been agreed by SC22/WG22 and are being prepared as technical corrigenda.

Extensions to PCTE (developed jointly with OMG) are in preparation as PDAMS to these standards:

• PDAM1: extensions for object-orientation
• PDAM2: extensions for fine-grain objects

A CORBA IDL binding to PCTE has been submitted by ECMA to JTC1 under the fast-track procedure.

2. Status of PCTE SDS standards

ECMA TC33 has a Memorandum of Understanding with EIA CDIF concerning the use of CDIF as a transfer format for PCTE. We chose to use CDIF in preference to defining a PCTE-specific standard in order to be able to interchange data with other CDIF-compliant repositories and CASE tools.

Use of the CDIF transfer format requires work in two areas:

• The definition of a standard mapping between PCTE and CDIF representations, and PCTE SDSs for subject areas of the CDIF meta-model derived from this mapping. This work is in ballot for CD registration (SC7 N1553) and is discussed in more detail in the next section. It allows the transfer of logical properties of information in software engineering models.
• Extension of the CDIF meta-model for other kinds of properties that can be represented by PCTE, e.g. fine-grain objects, link categories, versions and access control. This work has been widely discussed but there is no draft specification yet. It will allow the transfer of physical properties of information in software engineering models.

Note that the logical/physical (or static/dynamic) distinction is not clear-cut and that physical information may be treated as specific to PCTE or abstracted to apply to other storage methods.

3. PCTE SDSs for CDIF subject areas

SC7 N1553 differs little from a draft reviewed by SC22/WG22 (PCTE) and SC7/WG11 (SEDDI/CDIF). It consists of a definition of the PCTE-CDIF mapping and PCTE SDSs for the Foundation, Common, Data Modeling and Data Definition subject areas of the CDIF meta-model. In preparing the first draft it was envisaged that the mapping would be non-normative guidelines and that the SDSs would be normative. In WG11 there was consensus that the mapping could and should be fully-defined and applicable automatically. This implies that the mapping should be normative; the SDSs may remain normative (but essentially redundant), become informative, or be omitted altogether (particularly those to be derived from future CDIF subject areas!). (The author favours the inclusion of some SDSs as informative examples and SDSs derived for all CDIF subject areas available in electronic format - which is all that users want.)

The principles used to define the CDIF-PCTE mapping could be generalised to apply to mappings between other pairs of representations, most notably CDIF-IRDS for another part of WG11's SEDDI standards. They are therefore pertinent to the purpose of this workshop. In SC7 N1553 they are as follows, with some editorial modifications for ease of reference. (Principles 4 to 9 still reflect the starting assumption that it would not be possible to define a completely deterministic mapping.)

"1.3 General principles

[end of quotation from SC7 N1553]

This work has also been influenced by some commonly held attitudes of the PCTE community:

• The mapping was defined pragmatically, translating CDIF subject areas into PCTE SDSs by starting from natural correspondences (CDIF entity to PCTE object, CDIF relationship to PCTE link with reverse link, etc.), then prototyping and refining them. Earlier attempts starting from comparisons of the meta-meta-models had fizzled out whilst spiralling into the stratosphere, but they were useful in promoting common understanding of CDIF and PCTE.
• The mapping and SDSs were produced as part of a prototyping exercise, which consisted of implementing a PCTE import-export tool and interchanging models with a free-standing CASE tool. More extensive prototyping involving a range of CDIF-compliant CASE tools and repositories is to be preferred, but such an exercise, as with all prototyping of interoperability standards, is expensive and difficult to organise.
• PCTE standards have always been regarded as specific rather than generic, i.e. "the PCTE standard" not "the repository standard". Similarly the derived SDSs would be regarded as e.g. "the PCTE standard SDS for the CDIF Data Modeling subject area" not "the PCTE standard SDS for Data Modelling". If there were other viable standards for data modelling, there could be corresponding standard PCTE SDSs and these could be derived in the same manner. This could be done for example when the OMG adopts a meta-model for Object Analysis and Design.

4. Relevance of SEDDI

SC7/WG11's project 7.28 SEDDI (Software Engineering Data Description and Interchange) was started as the culmination of a series of workshops and standard coordination meetings, with similar objectives to those of this JTC1 workshop, under banners such as "Harmonization around IRDS" and "A Standard Description of Data for Software Engineering". SEDDI was promoted as solving these problems by defining an architecture and coordinating the activities of groups producing standards for components of the architecture.

The SEDDI architecture has turned out to be that of CDIF and the SEDDI standards (as currently under development) are CDIF (meta-meta-model, meta-model and transfer format) with PCTE, IRDS and potentially other representations of the meta-model.

Although progress in WG11 has felt frustratingly slow, it is now en route to a tolerable solution ot the basic problems posed by this workshop, including one of particular concern for PCTE, the need for a JTC1 strategy on repository standards. JTC1 N4029 Joint Position of SC21 and SC22 Chairmen on Repository Standards Work states:

"2. SC7/WG11 (SEDDI) is currently producing definitions of standard content modules (schema definition sets) expressed both in IRDS and PCTE terms, in liaison with SC21/WG3 and SC22/WG22. This work parallels the production of bindings for APIs in different programming languages such as Ada and C. In view of this, interoperability between repository standards can be achieved through developing common standards of data exchange between diverse repositories."

5. Proposals for the workshop

These proposals are the author's personal opinions, based on experience from the work described above.

1. SEDDI potentially solves most of the soluble problems posed for this workshop. We should spend a significant part of our time reviewing how well it does so and what beneficial actions (for SC7/WG11 or others) are needed to improve the solutions and to start tackling the outstanding problems.

2. A useful aid to this process and a basic part of the workshop would be a simple architecture (transfer format; repository; metamodel broken down slightly to data model, process model, etc.; a list of terms and synonyms, some with simple definitions) with a listing of standards work on the different components (3 or 4 pages). The architecture should only be decomposed to the extent needed to state problems raised in the workshop.

3. It is essential to recognise which problems are insoluble, the main one being the desire for a controlled set of unique, consistent, complete, separated and independent standards. Each group has its own imperatives and (lack of) resources; the best we can hope for is that they make informed choices. All we can do is to inform the relevant groups what others are doing and of inconsistencies and gaps. I am hopeful that the workshop will provide some significant benefits of this kind.

4. My paper may appear to be an attempt to give centralised control of these standards to SC7/WG11, but it is not. Such control cannot be achieved (as just indicated) and is probably undesirable. Anyway, SC7/WG11 has not been conspicuously successful in its coordination role. However, if the architecture and list of component standards is worthy of maintenance by JTC1 then SC7 Software Engineering, probably WG11, is the appropriate home (and already has such projects).

5. It is important to recognise which potentially soluble problems cannot be solved yet. An example of this is standards for semantic integration - we are still struggling to finish the simpler structural integration. The architecture should help the clear statement of such problems and of possible routes to solutions for the workshop results. This might be the most useful outcome of the workshop.

6. There should be no difficulty in completing whatever can be achieved within the duration of this workshop (possibly with some groups taking on consequential activities). I expect the results will be useful, but we should resist any temptation to propose further workshops. This workshop has failed to attract any groups outside JTC1 and therefore will have limited authority in the industry. In any case my experience (as participant or observer) from the precursors to SEDDI referred to above and the first and only Workshop on Application Integration Architecture (AIA) suggests that they are not viable or useful at intervals of less than 3-5 years.