Type Associations Identified to Support Information Resource

Type associations supporting reuse decisions in course of the interoperable information systems design are identified. Type reducts (projections of object interfaces defined by types) are considered as patterns of reuse. The required federated composite objects are assumed to be created by integration of such fragments using views above their type definitions. Type associations introduced are based on an assumption of type specification completeness. The type refinement association is introduced as the fundamental concept for the others, such as subtyping, type reduct, type conformances and type inferencing associations. These associations are established to support the information system design with reuse .


Introduction
Megaprogramming metaphor [13] reflecting the need for programming-in-the-large in an open distributed computing / telecommunication environment becomes now a strong motive force.The components used in megaprogramming, called megamodules, encapsulate the functionality of services, provided by various pre-existing information resources.Technically megaprogramming is based on interoperability providing for representation of megamodules as objects in the global object space interoperating through brokers [10].
In the SYNTHESIS project [3] considering the megapogramming based on the pre-existing information resources we concentrate on semantic interoperability as a specific technique providing for meaningful and correct components composition to reach the required functionality.The semantic interoperation reasoning (SIR) method proposed [3] should lead to the concretization of specifications of requirements by views over the pre-existing information resources.These steps include: integration of an application domain and of an information resource ontological contexts, concretization view definitions supporting mediation of resource types to satisfy the requirements of specific application types, usage of declarative description style and predicative specifications for application and resource for generation and justification of concretization conditions capturing structural, extensional and behavioral properties.
The core interoperation technology [10] (addressing the system, technical level of interoperation) is based on the idea of total encapsulation of the underlying resources.No semantics of resources could be seen on the generalized level of description.In SYNTHESIS we are looking for methodological framework and architecture that should be SIR complete.
By completeness we mean that the specifications should be sufficient to reason that a resource is applicable to a given problem (perhaps, after some coneptual, functional, extensional, etc. reconciliation).Specifically it means that we are able to decompose the application specification and locate its fragments for which the resource could be considered a concretization.Or it means that the specifications should be sufficient to reason that a collection of resources is composable into a consistent, coherent entity reusable for a given problem (or its fragment) as a whole.Therefore, our solutions constitute complementary features to the core interoperation frameworks [10] and to existing

Type Associations Identified to Support Information Resource Reuse in Megaprogramming
Object Analysis and Design methods.The process of concretization of an application specification by the pre-existing resources is critical issue to reach the semantic interoperation.The proposed procedure [4] of searching for resources with application relevant capabilities is based on the ontological context coherence and semantical similarity of resource / application specifications, on strict, justifiable conditions of structural, value and behavioral concretization of an application by the heterogeneous resources.
We assume that pre-existing information resource specifications (IRS) and information system requirements specifications (ISRS) are known.We assume that these specifications are complete and given in the uniform notation [5].The basic constituents of the specifications are definitions of types representing ontological, state and behavioral semantics of pre-existing components and of the requirements to be developed.We consider specifications to be completely separated from the implementation definitions.We are focused here on reuse of specifications.The implementations that are behind them can be invoked through the specifications (one or multiple implementations can be associated with a type specification of a pre-existing resource).
We assume that type specifications are based on an object model with well-defined semantics containing an object calculus as its basic part (such as, e.g., [11,5]).We assume that in a type definition state and behavioral attributes are distinguished, invariant (constraints) definitions are provided and definitions of functions are given in a form of mixed pre-and postconditions expressed in an object calculus.
The intention of this paper is to identify basic associations between type specifications that are required to support reuse decisions in course of design.These associations can be provided directly by a specification repositoty or they can be inferred by analysis of type specifications and justified.The application domain semantic associations between type specifiations (provided partially by ontological information) are beyond this paper: everywhere we assume that types considered for reuse are semantically coherent.
For reuse we apply a model of composite object integrating data and behavior from various sources.The data and/or behavior residing at each source is regarding as a fragment of a composite object.We consider reducts (projections of object interfaces defined by types) as patterns of reuse.So, we decompose type specifications into a collection of reducts that can serve as units of reuse and composition.Thus we specify types of the object fragments as reducts of the required type and provide their loose integration in a bottom up fashion.Federated composite objects are created by integration of such fragments using views above their type definitions.Basic techniques supporting such objects include delegation, substitutability, inheritance providing for composition and sharing of behavior and state of objects.Concentrating on reuse, object-centered programming should be combined with class-based programming to form a continuum between prototype-or delegation-based languages [8] and class-based ones.Applying such models, we can properly define autonomous information resources (software servers) whose functional capabilities can be shared by delegation.
We address type refinement [9,1] as the fundamental property that is required to justify a correctness of substitution of instances of one type for another and of reuse of pre-existing objects state and behavior.We should discover suitable reducts of IRS types refining reducts of ISRS types so that we could apply the basic techniques above to form a refinement of the required type.Necessary functionality of objects of the required type can be provided by constructing of required behavior from scratch or reusing pre-existing behaviors relying on inheritance or delegation.The resulting type should be consistent (that is, the type should have a model and operations should preserve the type invariants).The resulting type should be a refinement of the required type.Thus we construct a type that is a subtype of the ISRS type.This construct provides for reuse by means of object substitutability.
In the paper we define basic type associations that should be established to make reuse decisions efficient.The paper is structured as follows.We start with the definition of type refinement as of the basic required association.Other associations introduced are based on the type refinement concept.Subtyping and reduct associations are defined further.Introducing type conformances, we deviate from conventional definitions of such associations basing their meaning on the type refinement associations.Finally we discuss type inference associations providing for necessary type calculations during the design.The type associations introduced are based on an assumption of completeness of the type specifications.

Type Refinement
The objective of the design is to have type specifications implemented eventually as software modules by means of some programming notation.So, we have to transform specifications so that they could eventually be implemented by means of a program.This will be done by a step by step restriction of the constructs that could be used further.This activity is called a refinement.
Algorithmic refinement is an approach of being more and more precise about the way our operations should be eventually made concrete.
Data refinement consists in removing completely all variables whose types are too complicated to be implemented as such and in replacing them by simpler variables whose types correspond to those found in programming notations.
The refinement of a type is defined as follows: a type t j is said to refine a type t i if a user can use values of t j instead of values of t i without noticing it.
Both types must have the same operation names (each with same input and output parameters respectively).Both types are said to have the same operational signature.But of course, they will not have the same variables.To define more precisely what a refinement is, we introduce the following definition of a type model.
For a type model M the set of all type specifications expressible in M is denoted by T: Type state.The type state corresponding to a type specification t i 2 T is a function s ti : Id ti !V i ;defining for each state variable (attribute) of the type specification denoted by identifier I 2 Id ti its value v i taken from the set of admissible values V i of the variable type.It is essential that v i in its turn can also be an analogous function.A set of admissible states corresponding to some type specification t i 2 T is a set of functions S ti : [ Id ti !V i ]: Aspace of type states expressible in M is a set of functions S : [ Id i !V i ];which may be considered as union of sets s ti 2 S ti for all t i 2 T:We consider only admissible states that satisfy the invariants related to types.-mapping is an algorithmic refinement.

Reduct Associations
To characterize fragments of objects to be reused we introduce a notion of a type reduct or simply a reduct.Roughly a reduct is a subset of an interface of a type instance.A reduct can be formed taking a projection of a type specification on certain state and functional attributes.
On another hand, a reduct should be a proper type specification that is always a supertype (immediate or transitive) with respect to an original type.A reduct should be properly placed in a type lattice.
Concerning reusability, we consider two reduct extremes: a functional reduct containing only behavioral attributes of the original type and a state reduct containing only state attribute of the origina type.These different kinds of reducts can be formed to be focused on pragmatically different primary intention of reuse: to reuse a data source or a functional source.
Actually in course of a design the reducts can dynamically be included into the type lattice to support searching for reusable components.After the search completion the reducts are removed from the type lattice.
Generally, we consider reducts as the basic reuse patterns.Different constructs for reduct aggregation and composition providing for reuse (such as paths, compositions of functions) are applicable for the views definition.

Subtyping Associations
The basic meaning of a subtyping is based on the following assumptions [2]: subtyping is a partial order on types; if then all values (objects) of a type can be used in any context in which values (objects) of a type can be used; if then instances of type have at least all properties that instances of type have.In another words, a theory of the supertype is contained in a theory of the subtype, i.e. , T h ( )Th ( ) .Therefore, subtyping implies a subset relationship between instances.
A subtype can be obtained from the supertype by: adding of new functions to an interface of ; refining the states; refining the assertions; refining the functions.
We denote a type specification t = < I d t ; S t ; O f t ; O p t >where Id t denotes for a type t a set of state variables, S t -a state space, O ft -a set of operations, O pt -a set of invariants.
A subtyping association for a supertype t sup = < I d sup ; S sup ; O f sup ; O p sup > and a subtype t sub =< Id sub ; S sub ; O f sub ; O p sub > holds iff there exists an abstraction function Abs mapping the subtype state space (S sub ) into the supertype state space (S sup ) such that the following conditions are satisfied: Advances in Databases and Information Systems, 1996 1.For a subtype invariants to be a refinement of a supertype invariants the following condition should be proved (P sup (P sub ) is a conjunction of all predicates in O psup (O psub )): 8 S sub ; S sup P sub ^Abs ) P sup 2. To preserve supertype operations behavior, subtype operations should be a refinement of the corresponding supertype operations [7].To show that an operation of a subtype O sub 2 O fsub is a refinement of the corresponding operation O sup 2 O fsup of the supertype when a subtype and supertype state spaces S sub and S sup are related by an Abs mapping, proof obligations should be generated according to the following templates [12]: The first template should state that a subtype operation should terminate whenever a supertype operation is guaranteed to terminate (X and Y denote input and output spaces of the operation):

S sub ; S sup preO sup ^Abs ) preO sub
This is known as the law of weakening of precondition.The second template ensures that the state after the subtype operation (marked by 0 ) represents one of those abstract states in which an operation of a supertype could terminate (here spc(O) denotes a predicative specification of O expressed in a mixed pre-and postconditions): The second condition is the law of strengthening of postcondition.If these conditions are satisfied then a subtype operation is suitable for all purposes for which a supertype operation is suitable.If we model a type and subtype by an abstract machine and its refinement then the subtyping conditions above will be correctly established.
Actually what we said above means that type t j is a subtype of a type t i iff a reduct of t j to state attributes and functions corresponding to t i is a refinement of t i :

Conformance Associations
Here we introduce a notion of type conformance associations that deviates from given sometimes in the literature [11].The reason for the new notion is that we look here not only for the object substitutability, but mostly for reusability of object fragments.For a given type we would like to associate a collection of other type definitions partially conforming to our type and forming a reusability perspective for the type.Therefore, we redefine conformance as follows.
A conformance association between types t 1 ; t 2 holds (we say "t 2 conforms to t 1 ") iff there exists a common reduct of t 1 and t 2 : A common reduct t = CR(t 1 ; t 2 )is such type (other than the null type) that t is a reduct r t (t 1 ) of t 1 and there exists a reduct r t (t 2 ) that refines r t (t 1 )2 .
A conformance relation on a set of types is reflexive and transitive.The conformance relation is not antisymmetric.
It means that from the facts that t 1 conforms to t 2 and t 2 conforms to t 1 it does not follow that t 1 = t 2 : On the contrary, for subtyping relation that is reflexive, transitive and antisymmetric (a partial order relation), if t 1 is a subtype of t 2 and t 2 is a subtype of t 1 then t 1 = t 2 : A particular conformance t 2 for a particular type t 1 gives a reuse possibilities for t 1 : The reducts defined for t 1 through conformance association define states and behaviors of t 2 that can be reused to implement the type t 1 : A type t 1 can have many conformances with a type t 2 : However, we are interested in a conformances in which any extension of a common reduct will not lead to new conformances.Such conformances are called the most common conformances.

Type Associations Identified to Support Information Resource Reuse in Megaprogramming
A most common reduct t = MCR ( t 1 ; t 2 )is a reduct r t (t 1 ) of t 1 such that there exists a reduct r t (t 2 ) that refines r t (t 1 ) and there can be no other reduct t i of t 1 (r ti (t 1 )) such that t is a reduct of t i ; t i is not equal to t and there exists a reduct r ti (t 2 ) that refines r ti (t 1 ): A conformance between pairs of types t 1 ; t 2 is most common iff these types are related through the most common reduct.It is clear that for a pair of types t 1 ; t 2 there exists at most one MCR :If most common reduct of t 1 and t 2 is equal to t 1 then we say that t 2 is a subtype of t 1 : Now we can extend the definition of a conformance association of a type t 1 to a collection of types T: We define a conformance of a type t as a collection of types S = ft 1 ; t 2 ; :::; t n g such that any type t i in S conforms to t: It is possible that some of the states and behaviors may be shared among the types in the conformance because of subtyping and conformance associations that may exist among them.A type can have many conformnces.However, for any type there exists a conformance such that adding a type to the conformance does not add any additional conformance information to the original type and removing a type from the conformance would lose such information.This conformance is called the most common conformance for the type.
We define a conformance S = ft 1 ; t 2 ; :::; t n g of a type t to be the most common conformance of t iff we take the most common conformance of each type in S to t and there does not exist a type t v not belonging to S such that MCR ( t; t i ) is a reduct of MCR ( t; t v ) where t i is a type belonging to S: A most common conformance of a type t is denoted by MC( t ) : The MC( t )characterizes a reuse perspective for a type t:

Type Inferencing Associations
These associations usually focus on issues of a type inferencing during object calculus formulae evaluation under assumption of the type specification completeness.Two kinds of formulae are distinguished: object-preserving and object-creating ones.The object-preserving formulae are limited to returning existing objects from an object base while object-creating formulae may create new objects during their evaluation [11].The object-creating formulae can form new types that were not integrated with the types from which they were formed.Based on the notion of a well-defined type lattice we should have a systematic possibility to integrate these new types into the existing lattice.
The type operations and expressions usually are intended as a technique for target-creating formulae evaluation, view and schema evolution support.Here we mostly emphasize these associations for the process of design with reuse -to form reducts introducing them properly into the type lattice, to produce composition of reducts and to express formulae leading to views serving as refinements of the required types.
Here following [11], we introduce type operations that are suitable for incomplete type specifications containing only signatures of functions.Let T i (1 i n) denotes types.
An operation T 1 & T 2 produces a type T as a meet of the operand types.T includes functions that are common for T 1 and T 2 : ) is a result of a type meet.Type T is placed in the type lattice as a supertype of types being operands of the operation.
An operation T 1 j T 2 produces as a result a type T that is a join of the operand types.T includes a union of functions of T 1 and T 2 : If T 2 (T 1 ) is a subtype of T 1 (T 2 ) then T 2 (T 1 ) is s result of a join operation.A type T is placed in the type lattice as a subtype of the operand types.
An operation T 1 T 2 produces as a result a type T that is a product of the operand types.A type T is placed in the type lattice as a subtype of other product types (but not of the operand types) in accordance with the interfaces defined for the product types.
A product type T 1 T 2 : : : T n is placed in the type lattice as a subtype of a product type T 0 1 T 0 2 : : : T 0 m if m n and T i is a subtype of T 0 i for 1 i m: It is placed in the type lattice as a supertype of T 00 1 T 00 2 : : : T 00 k type if n k and T i is a supertype of T 00 i for 1 i n: If a product type cannot Type Associations Identified to Support Information Resource Reuse in Megaprogramming be placed into a type lattice as a subtype of another product type it is placed there as a subtype of the root type of the lattice.
Complete type specifications include specifications of assertions (predicates constraining admissible type values) and specifications of functions serving as type operations.In this case type inferencing operations should produce correct types placed into type lattice in accordance with the definition of subtyping association given above that is clarified as follows.
Using the operations above, type expressions are introduced taking into account that meet and join operations are commutative and associative and a product operation is neither commutative nor associative.A product operation has a higher priority comparing to the operations of type meet and join.The type inferencing operations defined above should be extended with the following transformations (justifications) [6]: Type meet operation: Assertions created in the resulting type (obtained from operand type assertions) should be formed by a maximal subset of assertions common for the operand types and relevant to a reduced set of functions of a resulting type.

Type join operation:
A set of assertions inherited from operand types should be consistent (the resulting type should have a model).

Any type operation:
A specification of any interfacing function of a resulting type can be chosen among corresponding interfacing functions of operand types if the functions are in a refinement order (for a supertype (subtype) more abstract (more refined) function should be chosen).If the functions are not in a refinement order they are considered to be different interface functions.
In case of a specification completeness type inference operations should produce correct supertype (subtype) of the operand types.To do that the operations should perform nontrivial transformations of specifications and justification of their correctness.

Conclusion
The paper identifies basic associations between types that are required to support reasoning of semantic interoperability and reuse in course of a megaprogram design.The pre-existing information resource specifications (IRS) and information system requirements specifications (ISRS) are assumed to be complete.By completeness we mean that the specifications should be sufficient to reason that a resource is applicable to a given problem.For reuse we apply a model of federated composite object integrating data and behavior from various sources.To identify reusable fragments we consider reducts (projections of object interfaces defined by types) as patterns of reuse.Basic techniques supporting creation of such objects include delegation, substitutability, inheritance providing for composition and sharing of behavior and state of objects.
For the basic associations between types required to reason about the object fragments reusability we identified reducts, refinement, subtyping, various conformances and type inferencing associations.
We treat type refinement to be the fundamental type association that is required to justify correctness of reuse of pre-existing object fragments (object state and behavior) as well as to establish other type associations (such as subtyping, conformances and type inferencing).
The type associations defined support the semantically interoperable design in the SYNTHESIS project.
8 S sub ; S sup ; S 0 sub preO sup ^Abs ^spc(O sub ) ) 9 S 0 sup Abs ^spc(O sup ) Type behavior.The type behavior corresponding to a type specification t i 2 T is a function b ti : O ti ![S ti S tk : : : S t n !S t i ]defining for each operation in the type specification the related state transformation for this type.tk ; : : : ; t n are type specifications known in a context of the type specification t i : A set of admissible behaviors corresponding to some type specification t i 2 T is a set of functions B ti : [ O t i ![ S t i S t k : : : S t n !S t i ]]: which may be considered as union of sets b ti 2 B ti for all t i 2 T: Type model M is a triple < T; Ms; Mb > where Ms:T!Sis a semantic state function of M; Mb:T!Bis a semantic behavior function of M:Now, considering type t j being a refinement of type t i in M;we assume that the following conditions hold: A space of type behaviors expressible in M is a set of functions B : [ O ! [ S : : : S!S ]];