Model integration is becoming ever more important in practice as a result of several industry trends. Some of these were identified in Geoffrion and Powers [1995] in the special context of logistics, but hold more generally in other functional contexts as well: trends toward consolidating previously separate management functions, toward multi-company cooperative arrangements up and down the supply chain, and toward finding new uses for expensive assets. These trends lead to models that are more comprehensive in scope than before, often combining more than one operational, tactical, or strategic purpose.
Deep integration produces a single new model that combines two or more given models, subject to the important qualification that the new model must be represented in the same definitional formalism as the given models (or in one of the definitional formalisms used by the given models, if they happen to use more than one). Of course, the new model must be well formed if the given models are: the expression of the new model must be formally correct within the definitional formalism used. More than that, the new model should also be as semantically faithful a rendering as possible of the modeler's intentions.
Functional integration, in distinction, does not yield a new model in the same definitional formalism. It leaves the given models as they were and superimposes a computational agenda for coordinating calculations over them, typically directing certain models' outputs to other models' inputs while specifying the order of computations (portions of which may be left to automatic resolution at run-time). That agenda, which of course must be defined formally, serves as the (only) definition of the functional integration. Usually it is expressed in a model interconnection language. (Dolk and Kottemann [1993] use the term "model integration control language", and Muhanna and Pick [1988] propose a subsequently implemented "model description language" of this sort for composite models.)
Four detailed examples of deep integration can be found in Geoffrion [1992c], namely a four-submodel corporate model originally due to Blanning, demand forecasting plus transportation, EOQ plus transportation, and two simple transportation models that unite to form a two-echelon transshipment model. In all cases, the given and final integrated models are defined in SML. Examples of functional integration are given by Dolk and Kottemann [1993], Kottemann and Dolk [1992], and Muhanna [1993]; they address some of the above models, and a collection of models that together form a product mix model.
Not only is it important to make the deep vs. functional integration distinction, but there are also important distinctions to be made depending on just what is being integrated. As explained at length in Geoffrion [1989b], there is a natural four-level hierarchy of model abstraction: model instance, model class, modeling paradigm, and modeling tradition. For instance, a numerical example of the classical transportation model can be viewed as a model instance within the model class "Hitchcock-Koopmans transportation model" within the "network flow" modeling paradigm within the MS/OR modeling tradition. As explained in the paper, other modeling traditions containing pertinent modeling paradigms include database management and artificial intelligence.
This hierarchy suggests 10 possible types of integration, most of which have been studied in the literature (here "two" really means "two or more"):
Many examples are given in Geoffrion [1989b]. Some comments concerning these different kinds of integration are in order:
- Join two modeling traditions
- Join two modeling paradigms from a single modeling tradition
- Join two modeling paradigms from different modeling traditions
- Join two model classes from a single modeling paradigm (from a single modeling tradition)
- Join two model classes from different modeling paradigms from a single modeling tradition
- Join two model classes from different modeling paradigms from different modeling traditions
- Join two model instances from the same model class (from a single modeling paradigm and tradition)
- Join two model instances from different model classes from a single modeling paradigm (and tradition)
- Join two model instances from different model classes from different modeling paradigms from a single modeling tradition
- Join two model instances from different model classes from different modeling paradigms from different modeling traditions.
It follows that model integration, in its present immature stage, ought to focus on types 4, 5, and 6 in that order, and also type 7. All four of these types are discussed in Geoffrion [1989b]. Moreover, type 6 may be hopeless to tackle until there is sufficient progress on types 4 and 5. And type 7, which corresponds to what is sometimes called "consolidation" or "aggregation", seems a good deal easier to cope with than any other type. Consequently, in what follows, attention is confined to types 4 and 5. We remark that the corporate and two-echelon transshipment examples of Geoffrion [1992c] are of type 4, while the other two examples are of type 5.Types 1-3, which involve hybrids of modeling traditions and paradigms, are poorly defined and ought not to be considered until the other types of integration are better understood. Evidently 4 < 5 < 6 and 7 < 8 < 9 < 10, where "<" means "is easier to study". It seems prudent to let this partial order guide the allocation of research effort. Because functional integration does not need to reconcile different model classes or model instances as deep integration does, functional integration is better able to cope with the relatively greater difficulty of the integration types that come late in the partial orders just mentioned. Consequently, functional integration is likely to be more practical than deep integration in situations that call for the more difficult types of integration (Dolk and Kottemann [1993]). Types 8, 9, and 10 may not be very meaningful because the resulting model instance may not have an obvious model class, a deprivation that would rob it of much of its usefulness because model classes, rather than model instances, are the essential objects of interest in most model-based work (see pp. 63-64 of Geoffrion [1992a]). So it is prudent to replace the study of types 8, 9, and 10 with the study of types 4, 5, and 6 respectively.
Now that we have a better idea of the meaning of model integration -- deep and functional integration of types 4 and 5, correct semantically as well as syntactically -- we can survey what has been done within the structured modeling context.
Geoffrion [1992c] proposes a procedure for manual deep integration of types 4-6 when the given model classes are expressed in SML. That paper illustrates the procedure in complete detail for the four examples mentioned earlier, and discusses prospects for automation. The conclusion is reached that, while portions of the procedure can be automated or assisted, deep integration in general is too challenging to automate completely any time soon. Even formal correctness seems difficult to automate, given the intricate nature of SML (a consequence of SML's semantic richness). Since semantic fidelity is the most challenging aspect of deep integration, automating deep integration for SML is correspondingly challenging, and the paper expands on this point in some detail.
Further comments are in order on the difficulty of preserving formal correctness when editing SML in the course of deep integration. Here formal correctness refers not only to SML's context-free syntax, but also to its context-sensitive semantics as expressed in its so-called schema properties.
Tsai [1988, 1998] obtains partial results on the precise ways in which certain important kinds of schema edits can disrupt the formal correctness of an SML schema. Considering the amount of effort needed to produce those partial results, the prospect of extending them to the point of completeness is daunting. Yet, surely it is necessary to understand precisely the potential vulnerabilities of a schema to the kinds of edits needed for deep integration. Or is it?
A partial way out may be to rely on a language-directed editor that knows all of SML's rules -- context-sensitive schema properties as well as context-free syntax. Then when a schema edit is made, possible damage would be checked automatically and the modeler would be prompted to make any necessary repairs. It turns out that such an editor has already been built by Vicuña [1990]. His dissertation uses attribute grammar equations to completely formalize all the rules of SML, and demonstrates the feasibility of its approach by implementing a complete language-directed editor for SML.
Another possible way out is to study the effect of schema edits without assuming SML or any other particular language in support of structured modeling's semantic framework. Then there are no language rules at all to worry about, although there is still the integrity of the schema to worry about according to the formal definitions of Geoffrion [1989a]. This is the approach of Gagliardi and Spera [1995b, 1995c]. They formalize some of the mechanics of type 4-6 deep integration in terms of the formal structured modeling framework, using their own object-oriented language BLOOMS rather than SML when necessary to present examples taken from Geoffrion [1992c].
Preserving the modeler's semantic intent during deep integration beyond what is defined formally for the given models is more difficult because this intent cannot be characterized by any application-independent set of rules. This is where the most severe difficulties lie for all definitional formalisms.
One aspect of semantic intent is captured by typing and units of measurement. If the definitional formalism does not incorporate these, editing a model can easily produce all sorts of dimensional inconsistencies. But if they are incorporated, then consistency can be enforced as explained by Bradley and Clemence [1988]. SML does not incorporate typing and units of measurement, but clearly it could be modified to do so. This would enable one aspect of semantic intent to be formalized and therefore to become supportable by software.
If explicit typing and units of measurement can render one aspect of semantic intent software-supportable, can the same be done for other aspects? Identifying such opportunities and finding ways to exploit them is an important research topic.
Bradley and Clemence [1988] sketch a simple, formal language useful for functional integration of types 4-6, although it can be viewed also as a kind of macro language for deep integration. Of course, it provides for the use of typing and units of measurement to check the consistency of the integrated model. The key "library unit" concept is quite close to the concept of a "module" in structured modeling.
Kottemann and Dolk [1992] focus on the situation where multiple given models are to be used computationally in a coordinated way while preserving their identity. They sketch a model interconnection language for such situations based on the idea of communicating sequential processes. The approach has a strongly procedural, rather than declarative, character and can be viewed as naturally from the viewpoint of model manipulation as from the model integration viewpoint.
Dolk and Kottemann [1993] discuss functional integration, including a tantalizing glimpse of a model interconnection language based on SML. They also discuss deep integration and the virtues of the object-oriented paradigm for implementing model integration, including a brief description of "Communicating Structured Models" based on communicating sequential processes.
The final point of that paper may offer the most profound research challenge associated with functional integration. The authors point out that extant model interconnection languages all have been engineered without the benefit of an explicit, rigorous semantic framework, just as nearly all modeling languages have been. (SML and other languages for structured modeling are exceptional in this regard; see pp. 67-68 of Geoffrion [1992a].) Can such a framework be devised for model interconnection languages? If so, it should permit designing languages for functional integration that are superior to present ones.
Structured modeling's semantic framework (Geoffrion [1989a]) provides a plausible point of departure.