Model-typed component interfaces

Available online at www.sciencedirect.com

Journal of Systems Architecture 54 (2008) 551–561 www.elsevier.com/locate/sysarc

Model-typed component interfaces Gernot Schmo¨lzer *, Egon Teiniker 1, Christian Kreiner Institute for Technical Informatics, Graz University of Technology, Inffeldgasse 16, A-8010 Graz, Austria Salomon Automation GmbH, A-8114 Friesach bei Graz, Austria Received 16 February 2007; received in revised form 20 January 2008; accepted 28 January 2008 Available online 6 February 2008

Abstract Component based software engineering (CBSE) allows to design and develop reusable software components that can be assembled to construct software systems via well defined interfaces. However, designing such reusable components for data intensive business logic often requires heavy data transfer between components over interfaces. Static interface definitions using basic data types or structures of such lead to large interfaces susceptible to modifications. The goal of this paper is to present model-typed interfaces based on generic interface parameters, which allows to transfer complex structured data between components. Providing such generic, model-defined types (MDT) with data models specifying the parameter structure supports compatibility checks of model-typed interfaces at platform independent system design time. The methodology is described platform independently and the coherency with our system development process is discussed. Moreover, a technology mapping to IDL and the CORBA component model (CCM) is illustrated. Ó 2008 Elsevier B.V. All rights reserved. Keywords: Interfaces definition; Software engineering; Data modeling

1. Introduction Component based software engineering (CBSE) promises enhancements in software development due to separation of concern, component reuse, and other component oriented methodologies [4,16]. Individual reusable components are plugged together via interfaces, which are used for component interaction. Several industrial grade server component architectures have been defined, such as Sun’s Enterprise JavaBeans (EJB), Microsoft’s COM+ and the CORBA Component Model (CCM). Nevertheless, designing such reusable and independent components often leads to bloated interfaces used to transfer data between different components. Basic data types and combinations of such (e.g. structures) are used for this *

Corresponding author. Address: Institute for Technical Informatics, Graz University of Technology, Inffeldgasse 16, A-8010 Graz, Austria. E-mail addresses: [email protected] (G. Schmo¨lzer), egon. [email protected] (E. Teiniker), [email protected] (C. Kreiner). 1 Present address: FH Joanneum, University of Applied Sciences, A-8605 Kapfenberg, Austria 1383-7621/$ - see front matter Ó 2008 Elsevier B.V. All rights reserved. doi:10.1016/j.sysarc.2008.01.006

purpose to ensure type-safety between different interface implementations. Besides large interfaces CBSE has several other practical limitations compared to standard object oriented programming: Complex structured data already available in one component cannot be transferred easily to another component, as it is simply possible to pass an object reference to another object. Moreover, refactoring an interface – e.g. due to additional parameters required by one component – may affect other components that rely on this interface. To overcome these drawbacks, we introduce generic, model-typed interface parameters. These can be used to pack an entire data object graph into a single parameter and to transfer it between components. Every model-typed parameter definition is annotated with a model that governs structure and relations of data objects passed via such generic parameters. 2. Motivation When designing interfaces and components for particular functionalities it is very difficult to find the optimal

552

G. Schmo¨lzer et al. / Journal of Systems Architecture 54 (2008) 551–561

granularity of individual components. In order to enhance reusability of components, business functionality is often split into general, atomized business functions. Thus, providing smaller and more general components, and creating more complex and specialized components by adding additional behavior through component composition [15,21] is an important design concept. In practice however, this approach has a major drawback for data-intensive business components. Separating business functionality often requires heavy data transfer between individual components over interfaces. Due to data transfer restrictions of component technologies as well as to ensure type-safety, interfaces are generally defined in a static way. This means, long interface parameter lists of either primitive data types or statically defined, serializable structures composed of primitive types are defined to transfer data from one component to another. This has two main disadvantages: First, because user defined data objects cannot be simply passed between components, interfaces are often large, and due to static parameter definition, very specific and thus difficult to reuse. Second, it is difficult to preserve relations between data objects when splitting them into primitive data structures. Another problem often occurs later in component evolution and maintenance phases when additional parameters are needed and interfaces need to be refactored. In case several components are daisy chained, multiple interfaces and components may be affected from such a change. This is especially difficult if components are distributed in binary form (e.g. COTS components).

3. Related work 3.1. Component and interface definition Clemens Szyperski defines a component as: ‘‘A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only” [16]. That means to be able to compose components into applications, each component must provide one or more interfaces. These interfaces form a contract between the component and its environment. The component interfaces clearly define which services a component provides. Also, software usually depends on a specific context, such as particular database schemas or other system resources. To support the composability of components, such dependencies must be explicitly specified. While current component technologies like Enterprise JavaBeans (EJB) [6], Microsoft’s COM+/DCOM and the CORBA component model (CCM) [12] describe their interfaces on a syntactical level, the concept of Trusted Components [2,10] implies a form of behavioral component specification too. We have explored the impacts of both test-driven component development [19] and contract aware component interfaces [18] to define a component’s behavior in practical

environments. As one result of our work, we have identified passing dynamic structures with large amounts of data as a serious weakness in context of component interface design. 3.2. Pragmatic solutions for data transfer Several solutions other than splitting data objects into primitive structures and thus bloating interfaces are common in practice. Assuming data objects being processed by a business component are retrieved from a database, data transfer is often solved by passing only primary key identifiers via interface parameters, which are used by the other component to identify and reload the entire object. Although this may pragmatically solve the problem of propagating entire entities, it leads to implicit dependencies on databases and their structure. Furthermore, reloading entire data objects separately in each component results in bad performance and uncommitted data in one component is not visible to other components. Another approach to overcome these disadvantages is to design dynamic, untyped interfaces, such as comma separated values (CSV), XML strings, or dynamic data types, such as CORBA’s Any type. This allows to define slim interfaces capable of transferring any serializable object, as proposed by the Data Transfer Object pattern [7]. Such dynamic parameters are much less affected by internal structural modifications. However, the price is loss of compiler type checks as well as the need of complex and error prone serialization functions. Therefore, generic types must be restricted to its particular interpretation and use. This is similar to concepts of contract aware interfaces [2,18], where parameters can be restricted to a particular value range. In the context of generic types, meta information (e.g. XML schema definition) is specified for each generic parameter. This can be used for compatibility checking of interface implementations at assembling time to prevent runtime errors. As well, type conversion between generic interface parameters and data objects, as seen from inside a component’s implementation, can be formalized and automated. 3.3. Data-transfer object One approach for transferring entire objects between remote interfaces in order to avoid large numbers of primitive parameters has been published as Data Transfer Object (DTO) pattern [7]. A motivation for DTOs are high latency costs of remote calls, i.e. making rather less calls with large amounts of data instead of many calls with less data. DTOs may occur in different forms: Generic collection data structure (e.g. dictionary) as DTO is a very simple method, but does not provide an explicit interface and loses the ability of compile-time typechecks.

G. Schmo¨lzer et al. / Journal of Systems Architecture 54 (2008) 551–561

Record Set pattern [7], a common form of DTO for business logic based on SQL databases, is a set of tabular records, such as it is returned from a SQL query. Although there are implementations that provide explicit interfaces and type checks (e.g. Microsoft’s Typed Data Sets), this approach is very specific for relational databases. Object graphs are serialized and transferred as DTO between interfaces. This has the advantage of typed data objects providing getter/setter methods for data access. However, such objects must be manually implemented or fully defined as part of interface definition (e.g. in IDL or WSDL). Moreover, separate DTO Assembler objects, which are responsible for creating DTOs from domain models and vice versa, need to be implemented. No matter which form of DTO is used, the following characteristics are common to all of them: – DTOs must be serializable, either in binary or human readable form. – Synchronization between sender and receiver is very important to ensure compatible serialization, which is a heavy restriction in practice. Changes on one side always require changes on the other side. – DTOs are created by an Assembler object from a domain model. Thus, the DTO is independent of the domain model. Since DTOs are mostly required in case of remote communication, serialization and deserialization for each call may result in performance overhead for communication within the same address space.

3.4. Managed entities In popular object-relational mapping frameworks like Hibernate [9] or implementations of the current Java Persistence API (JPA) [5], persistent data entities are realized as lightweight domain objects which are managed in a persistence context using an entity manager interface. An object-relational mapper maps entities to a relational database schema. During its life cycle, an entity instance can be in one of the following states: – A new entity instance has no persistent identity, and is not yet associated with a persistence context. – A managed entity instance is an instance with a persistent identity that is currently associated with a persistence context. – A detached entity instance is an instance with persistent identity that is no longer associated with a persistence context. – A removed entity instance is an instance with a persistent identity, associated with a persistence context, that is scheduled for removal from the database. Used in component implementations, entities can be detached from their entity manager, passed as typed

553

remote interface parameters, using some kind of serialization mechanism, and merged back into another component’s persistence context. By these means, parts of a domain model can be used as typed parameters without additional coding. This approach implies that both sender and receiver components share the identical domain model. As with typed DTOs, changing entities leads to modified interfaces, thus, component reuse becomes difficult. Also, domain models can have extensive relationships between entities which leads to large object graphs passed as interface parameters. In that case, explicit DTO’s are preferable. 3.5. Data modeling From the object-oriented perspective, data modeling is conceptually similar to class modeling. Data entities are identified, attributes are assigned to entities and associations are defined between entities – relationships, inheritance and composition are all applicable concepts in data modeling [1]. Nonetheless, data modeling is different from class modeling because it focuses solely on data. Class models allow to explore behavior and data aspects of a domain whereas data models only explore data issues. Data models can be used at different levels of abstraction. In the context of model-typed interface definition presented in this article we use data modeling to explicitly define the structure of generic interface parameters. 4. Model-typed component interfaces This article presents a methodology of model-typed interfaces based on generic interface parameter types, which allow to transfer complex structured data via component interfaces as well as to check compatibility of such interface implementations during the system design process. In our proposed approach, interface definitions include generic, model-defined parameters used to transfer complex object structures. Each component implementation providing or using such interfaces needs to specify meta information of data transferred via generic parameters. Depending on the complexity of data transferred via generic parameters, different ways exist for meta information specification. For instance, assuming an object hierarchy is transferred in XML format, the XML structure can be specified with an XML schema definition. Although XML is a common standard for data exchange, it is best suitable for object trees, whereas general data models that we aim at allow a definition of entire object graphs. Thus, we consider meta information of generic parameters to be specified in terms of such general data models [1]. Fig. 1 illustrates the concept of model-typed interfaces. In the interface specification model-typed interface parameters are defined as Model-defined Types (MDTs). Interface I1 defines a function foo with a generic in parameter x as MDT. Component CB provides an implementation of I1 and specifies a data model MB describing the structure of data

554

G. Schmo¨lzer et al. / Journal of Systems Architecture 54 (2008) 551–561

Interface Definition interface I1 { void foo(in MDT x); };

MA

MB

compatible

Data Model

Data Model

CA

CB

component CA {

component CB { provides I1 i1;

uses I1 i1;

};

};

Fig. 1. Concept of model-typed component interfaces: providing transfer of data objects over generic types at syntactical level and supporting type compatibility checks at the meta level.

expected from model-typed parameter x. On the other hand, component’s implementation CA uses interface I1 passing data for parameter x to its connected component. Therefore, MA specifies the structure of x passed to component CB during runtime. 4.1. A combined metamodel for model-typed component interfaces Considering the development process of components with respect to model-typed component interfaces, the following descriptions are required for producing a ready-touse component: interface definitions, component definitions, component implementation specifications, and data definition. How these descriptions depend on each other is shown in Fig. 2. From the perspective of a system designer it can be distinguished between definition and realization descriptions. Interfaces need to be defined first, which may contain operations with model-defined parameters. Components are then specified by providing or using these interfaces. For each component definition several component implementations may exist. In order to allow checking between different component realizations containing MDTs it is

Component

Interface

Definition Realization

Component Implementation

Data

Fig. 2. Component descriptions and their dependencies with respect to model-defined interfaces.

necessary to annotate each MDT with a data model. Thus, a component implementation depends on its definition as well as data specifications for individual MDTs. Finally, a data model depends on the interface definition in such a way that it realizes a particular MDT. The relationships of these four descriptions can be concretized by combining their metamodels, as illustrated in Fig. 3. Important to note is that all presented metamodels are in general platform and technology independent, and simplified to contain elements only from interest for the proposed methodology. In particular, the metamodel for component implementation is inspired by the OMG’s deployment and configuration specification [11], and the metamodel for data is a specialization of the UML class diagram metamodel [1,13]. The interface metamodel is extended with ModelDefinedType (MDT) as a specialization of GenericType. Because each component implementation needs to specify a data model for the corresponding model-defined parameter, ComponentImplementation is associated to DataModel, which therefore realizes one definition of MDT. In case of a monolithic implementation all MDTs require a data model, whereas data definitions of MDTs for component assembly implementations [15] can be automatically obtained from the components to be assembled. 4.2. Model-defined type checking In our model-driven system development process [21] a system is designed from interconnected and reusable components at an abstract level in terms of a Platform Independent Model (PIM). Such a PIM is obtained from the tasks illustrated in Fig. 4: interface, component, component assembly, and data modeling. Towards a specific platform and particular implementation, the PIM can be verified for consistency before any platform or technology mapping is required. If the PIM is verified successfully, it is transformed into Platform Specific Models (PSMs), which are then used for code generation. The entire system development process starting from abstract system modeling to generating, implementing and deploying components consists of three phases: system development, component development, and deployment phase. Enhancing this process, the methodology of model-typed interfaces contributes the following activities to these phases: System development phase: In case a system is completely modeled at the level of a PIM, consistency checks between data models specifying connected, model-typed parameters can be applied already at this level. Thus, interconnecting component instances via the same generic interface, but with incompatible parameter models can be detected in the verify model step (Fig. 4). Important to note is that this compatibility check does not require a particular implementation. Nevertheless, even if a platform independent system model does not exist,

G. Schmo¨lzer et al. / Journal of Systems Architecture 54 (2008) 551–561

Component

Interface Port +Identifier

+elements InterfaceElements 0..* +Identifier

Interface +Identifier

Component +Identifier

555

+uses 0..*

+interface

UsedPort

Type ProvidedPort

+provides 0..*

+type 1

+interface

+type 1

Attribute

+type 1 +type 1

0..* +bases

Operation

Parameter +direction +Identifier

GenericType ComplexType PrimitiveType

+params 0..* +throws 0..*

Component Implementation

Exception

ComponentInstantiation +instance +Identifier

PortEndpoint

1

+Identifier

1

+instance 1..* 1..* +implementation

+endpoint 0..*

ComponentImplementation

Data DataModel +definition +Identifier

+Identifier

+artifact

ComponentImplementation

+ownedElements 1

*

MonolithicImplementation ComponentAssembly

1..*

ModelDefinedType

ModelElement +name

*

Relation

0..* +connection

Class

Association

AssociationEnd +multiplicity 1 2 +assocKind

AssemblyConnection

+Identifier

+derived

Generalization 0..* Constraint for model−typed interfaces:

0..* +base

Entity Attribute

Entity 0..* +isAbstract 1

1

0..*

+child 1 1 +parent

AttributeType 1 For each parameter of ModelDefinedType in the component and interface specification respectively, a corresponding ComponentImplementation needs to specify a DataModel that is used for model−defined type checking.

1

Primitive

Structural Attribute

Structure 1 0..*

Fig. 3. A combined metamodel for interface and component definition, component implementation, and data definition.

such consistency checks can be applied at the PSM level, e.g. based on component and assembly descriptors of a particular component technology. Component development phase: For accessing modeltyped parameters a type-safe access layer, as described in Section 4.3 and Fig. 5, can automatically be generated from specified data models. Thus, consistency between business logic accessing generic parameters according to parameter definition (model) is ensured by the compiler. Deployment phase: Depending on the deployment setup, whether components are located in the same address space or on different hosts, interface adapters can be transparently generated for each particular setup [14].

4.3. Model-based parameter typing As shown in Fig. 1, parameters of MDT are provided with a data model specifying the structure of data trans-

ferred over this generic parameter. This has two major benefits: First, each implementation explicitly specifies, which parameter structure is expected and transferred, respectively. Second, as a consequence of explicit structure definition, compatibility between data models and thus compatibility of different implementations can be checked at a platform independent level. As defined by the Model-Driven Architecture (MDA) [8], the model-based parameter specification can be used to generate a type-safe access layer to parameter data for use inside the component. Such automatically generated access code may contain a transparent conversion between generic parameters and objects or object graphs. Moreover, consistency between the model and data access of the component’s business logic can be ensured by compiler checks. Fig. 5 shows this model-typed parameter access structure. For compatibility checks it is very important to take into account the direction of data flow. In case of in parameters, data flow occurs from used to provided interfaces (CA to CB , as illustrated in Fig. 6). Because CA invokes

556

G. Schmo¨lzer et al. / Journal of Systems Architecture 54 (2008) 551–561

example

example

Model Interfaces

Model Assemblies

Model Data

A

B

B

+a1: A1 +a2: A2

+b1: B1 +b2: B2

+b1: B1 +b2: B2

1

*

PIM

Model Components

Verify Model

Fig. 7. Example of two compatible models where MB is a submodel of MA : (a) Model MA and (b) Submodel MB .

[Error]

Implementation

Platform Transformation

Generate Component and Assembly Descriptions

Fig. 4. Model-driven system development process.

4.4. Closer analysis of model compatibility



CB

Interf. Def.

Business logic

MB

Type−safe access layer

Data Model

sidering the example models in Fig. 7, MB can be defined as subset of MA (MB  MA ), if for each model element in MB an equivalent element exists in MA . This hypothesis is also essential for out parameters, but in opposite direction implicating that MA  MB . Since inout parameters can simply be seen as a combination of both directions, MA  MB and MB  MA must hold for the parameter view models, and thus MA ¼ MB .



Dynamic parameter data

Fig. 5. Model-typed parameter access.

interface function foo passing parameter x to CB , data passed over x needs to be conform to (instance of) data model MA . From the target component’s perspective, data obtained from parameter x is viewed as instance of MB . Therefore, MB must be compatible to MA in order to interconnect CA and CB successfully, but how can such model compatibility be defined? The trivial case is MA ¼ MB . However, in case of a particular data flow direction, models do not need to be equivalent in order to be compatible. In the scenario from Fig. 1 it is sufficient if MB is a submodel of MA (MB  MA ). Con-

In the previous section we have defined the notion of submodel for data models used to specify model-typed interface parameters. Compatibility of a model and a submodel is rather obvious, and it has been used to elaborate our concept. Nevertheless, to ensure reusability of software components, compatibility between data models needs to be analyzed in more detail. Consider the example illustrated in Fig. 8, where a component’s business logic CIII is used in two different scenarios (by CI and CII ) with two different data models MI and MII . According to our previous definition successful assembling of components CI with CIII and CII with CIII would require MIII  MI and MIII  MII . However, in practice this assumption is very difficult to meet. Modifications to MI could possibly affect MIII , which in turn would require changes to MII , although component CI and CII are independent. Therefore, the question arises whether parameter models may be compatible, but they do not have to be entire

CI void foo(in M A x)

MI MIII

void foo(in M B x)

Interface Definition

PSM

[else]

void foo(in MDT x) Business logic

CA

MA

Business logic C B M B compatible to M A

MB

C II

C III

Data transformation Dynamic parameter data

Dynamic parameter data

Fig. 6. Business logic view of model-typed parameter.

MII Fig. 8. Model-typed interface compatibility.

G. Schmo¨lzer et al. / Journal of Systems Architecture 54 (2008) 551–561

example

example

A

B

A

B

+a1: A1 +a2: A2

+b1: B1 0..1 +b2: B2

+a1: A1

+b1: B1

1

...

1

*

...

Fig. 9. Example of two different models where MB is not a submodel of MA , but still compatible: (a) Model MA and (b) Compatible model MB .

submodels. In case of unidirectional data flow, such a compatibility is possible. Considering both models shown in Fig. 9, parameter data as an instance of MA can be viewed via model MB successfully. Each expected attribute (defined in MB ) is available at data instance, and each function processing a cardinality of * is also correct for instances with cardinality 0–1. Variability analysis of compatible data models allows to define a set of rules for object-oriented model constructs, based on the metamodel presented in Fig. 3 that must be ensured for compatibility. The terms MB as compatible model to MA are used to describe these rules: Ri Classes are optional in compatible models, but each class in MB must be available in MA , and the package structure (namespace) of classes must be equivalent. Based on our metamodel this means for each Entity class in MB an equivalent class in MA must exist. Rii Attributes may vary between compatible models, but each attribute that occurs in MB must also occur in MA . Types of both attributes must be equivalent. However, type constraints, such as for instance maximum length of strings, can be different. In such a case constraints of the compatible model MB need to be stronger. Regarding the metamodel a corresponding Attribute must exist in MA for each Attribute of an Entity class in MB . Riii Associations between classes are also optional for compatible models. As for attributes, all associations contained in MB must be also contained in MA . Associated classes and association types (association, composition, etc.) need to be equivalent, whereas cardinalities may differ. According to the metamodel this rule requires an Association in MA for each Association in MB , where types of AssociationEnds must be equivalent and cardinalities can vary according to rule Riv . Riv Cardinalities of corresponding Associations, defined as multiplicity attribute of class AssocationEnd in the metamodel, can vary as long as the cardinality in MB is more general than in MA . For instance, cardinality of * is compatible to 1 because any operation applied on a list of entities can also be applied on a single entity.

557

Rv Subclasses modeled in MB need to occur also in MA . However, MA may contain subclasses that are not included in MB . In the metamodel, class inheritance is defined by Generalization objects between Entity elements. Rvi A one-to-many composition in MA is compatible to an association in MB . The association’s cardinality at the end of the diamond in MA may be either 1 or 0–1. In the metamodel this means that the association kind attribute of class AssociationEnd may change between compatible models. We note that the variability analysis emerged from our domain specific use cases. As we would like to establish our logistics system in terms of a software product line in order to support efficient product customization, domain variabilities were analyzed and modeled accordingly. These domain variabilities require modularization of data structure as well as software components, which leads to the described problem of data exchange between components via interfaces. Moreover, several component implementations with different data models are required to realize domain variability, but other components may be general enough to be reused in different cases. This results in data model variability between component interfaces and was the basis for our variability analysis and, in turn, for the compatibility rules defined above. A more formal analysis of model compatibility and model subtyping, as already published for simpler data types [3], is still to be done. Nevertheless, designing an explicit metamodel and defining compatibility rules based on this metamodel, as presented in this article, is sufficient to implement a rule-based model validator hence demonstrating proof of concept of this methodology. 5. Implementation In order to automatically check compatibility between models at assembling time, a rule-based model validator can be implemented, as shown in Fig. 10. Input for such a validator are the two data models to be checked as well as the metamodel, such as defined in Fig. 3, and the rules to be validated. Because both data models MA and MB are instances of the metamodel, rules based on that metamodel can be validated and compatibility of these data models can be determined at assembling time. To demonstrate the concept of model-typed component interfaces, we have implemented model-based parameter typing for the CORBA Component Model (CCM) based on the open source project CCM Tools [17], as published in [14]. The methodology has been adopted to the local component adapter concept [20] and can be seen as addition to contract aware component interfaces [18] for generic data types. Data modeling of generic parameters is done in UML, using a particular UML profile for data modeling. Generic processing of data is performed with the Entity Con-

558

G. Schmo¨lzer et al. / Journal of Systems Architecture 54 (2008) 551–561

Metamodel





Rule−based validator

MA

MB

Rules

Fig. 10. Rule-based model compatibility validator.

MDT Metamodel 2 Compare MA

MA

MB 3

1 Entities

Component Impl. A

Entities

T

apply T 4

Entities

Component Impl. B

Fig. 11. Implementation steps of model-defined type transformation during runtime.

tainer (EC) [13], a model-based, object-oriented data cache. The EC allows to store and manipulate data

according to a data model, and based on the metamodel shown in Fig. 3. Data access with the EC is possible in two different ways: generically via a dynamic, untyped interface or statically via a type-safe access layer generated from the data model. The detailed implementation steps during runtime are illustrated in Fig. 11. In general both participating components share the same metamodel, which is defined in Fig. 3. Each data model associated to a MDT is an instance of the common metamodel, and data entities to be transferred are instances of the defined data model. In order to transfer data from component implementation A (CA ) based on MA to component implementation B (CB ) based on MB , in step 1 data entities as well as the corresponding data model (MA ) are transferred to CB . In case of a local component concept this simply requires passing references between components, whereas remote component interaction needs some kind of serialization/deserialization mechanism. In step 2, both data models are compared based on the common metamodel and model compatibility is validated in the same way as during assembling time. Assuming both models are compatible, the rule-based model validator creates in step 3 a transformation T and entities are converted from source model MA to destination model MB according to T in step 4. 6. Results To assess the applicability of the presented concept, a large real-world software product has been investigated with that focus. That logistics domain software accounts to approximately 2 million LOCs of C/C++ (legacy) code

Fig. 12. Case study: distribution of parameters over parameter count.

G. Schmo¨lzer et al. / Journal of Systems Architecture 54 (2008) 551–561

559

Fig. 13. Case study: distribution of attributes over parameter count.

and is currently structured into 46 coarse components. At the time of writing, model-typed interfaces are used in parts of that code. Not surprisingly, in such a data-centric application, many of the component methods’ parameters resemble persistent database structures. In that software, these persistent structures/classes are all generated and defined from UML class models [1,13]. Starting off this setting, we believe that it is permissible to make an extrapolation over the entire software product from the experience already gained. We have analyzed the methods and their parameters of all component interfaces. As common traces, we found that in most cases, there is a number of simple parameters and some of the mentioned, model-defined persistent classes, which tend to contain tenths of attributes. In a software product line setting, as encountered here, these modeldefined interfaces are primary candidates to accommodate variabilities originating from the data definition view. That is how we discriminated between potential model-typed and not model-typed interface parameters in the application’s component interfaces. In the statistics given here, the common x-axis are the number of parameters in a certain interface method. Each column shows the sum of all parameters over all component methods with a specific number of parameters P. The columns are divided in model-typed and not model-typed partial sums, as illustrated in Fig. 12. The second Fig. 13 has a similar structure, yet it counts attributes inside complex parameters. We believe this is a more fair comparison as simple parameters are contrasted with simple attributes inside model-defined

classes. All occurrences are counted, even when a class is used in more than one method, because variabilities would cause code modifications with every occurrence. Another finding is, that in many cases where two or more model-defined classes are used as interface method parameters, these are related and can collapse to a single model-typed parameter consisting of an entire object graph. This covers the programmers intent much better than separate, seemingly and formally independent structured parameters. In our analysis, we found, this is the case with approximately 8:4% of all methods (144 out of 1722). In these cases, model-typed interfaces can give software architects and developers a more concise way to express their ideas. 7. Conclusion As outlined in the motivating discussion, the functionality of compatible, but not necessarily identical parameters is essential for reusability of components and maintainability of component based systems. Practical experience has shown that separating business functionality into small, reusable parts often requires heavy data transfer between components. This leads to large, rigid interfaces in order to transfer necessary information. Furthermore, because many implementations of a particular interface may exist, interface modifications due to changes of a particular implementation affect all other implementations. In order to keep interfaces within a reasonable scope as well as making them robust against modifications, the con-

560

G. Schmo¨lzer et al. / Journal of Systems Architecture 54 (2008) 551–561

cept of model-typed parameters can be used for data transfer between different components. For each model-defined type (MDT), which is used in interface definitions to indicate such model-typed parameters, a component implementation needs to define a data model describing the parameter’s structure. This allows to determine compatibility of component assemblies by applying compatibility checks on specified data models. A list of rules for model compatibility were defined based on the metamodel. The verification step can be either performed at an abstract, platform independent system development process or at the level of a particular component platform. A technology mapping to IDL and CCM was described to demonstrate the concept of model-typed interfaces based on a practical example. The EC with its data object graph serialization was fully implemented and is available for C++ and JAVA. Finally, an analysis of a real world logistics application was done with respect to model-defined types in component interfaces. It has been shown that the amount of data attributes, which are defined in the data model and thus could be exchanged between components via model-defined interfaces, is significant. Thus, we believe that our approach can simplify component interfaces, in particular when data structures change due to product line variabilities. Our vision is an integrated framework that supports variabilities of information system software product lines, at least in the logistics domain that we have investigated. Model-typed component interfaces are a cornerstone in this effort, as they mean substantial progress towards seamless integration of component model and persistence framework – within a software product line environment. Open tasks still exist, like the improvement and a (more) formal notation of the model compatibility rule set, and the question about its completeness. We feel, that a deeper insight about the transforming role of model-typed interfaces for a component assembly is still necessary. Also, generalizations to models other than data structuring and persistence models like models of behavior in component interfaces call for investigation. References [1] Scott W. Ambler, Agile Database Techniques, Wiley Publishing, Inc., 2003. [2] A. Beugnard, J.-M. Jezequel, N. Plouzeau, D. Watkins, Making components contract aware, in: IEEE Computer, 1999, pp. 38–45. [3] Francßois Bry, Wlodzimierz Drabent, Jan Maluszynski, On subtyping of tree-structured data: a polynomial approach, in: Hans Ju¨rgen Ohlbach, Sebastian Schaffert (Eds.), PPSWR, Lecture Notes in Computer Science, vol. 3208, Springer, 2004, pp. 1–18. [4] Ivica Crnkovic, Magnus Larsson, Building Reliable Componentbased Software Systems, Artech House Publishers, 2002. [5] Linda DeMichiel, Michael Keith, Enterprise JavaBeans – Java Persistence API, Version 3.0, Final Release, Technical Report JSR 220, Sun Microsystems, 2006. [6] Linda DeMichiel, Michael Keith, Enterprise JavaBeans, Version 3.0, Final Release, Technical Report JSR 220, Sun Microsystems, 2006.

[7] Martin Fowler, Patterns of Enterprise Application Architecture, Addison Wesley, Reading, Massachusetts, 2002, November. [8] David S. Frankel, Model Driven Architecture, Applying MDA to Enterprise Computing, John Wiley & Sons, 2003. [9] Hibernate. , 2007. [10] Bertrand Meyer, The grand challenge of trusted components, in: Proceedings of 25th International Conference on Software Engineering ICSE, 2003, pp. 660–667. [11] OMG, Deployment and Configuration of Component-based Distributed Applications, Technical Report 04-05-15, Object Management Group, 2004. [12] OMG, CORBA Components, Technical Report 02-06-65, Object Management Group, June, 2002. [13] Gernot Schmoelzer, Stefan Mitterdorfer, Christian Kreiner, Joerg Faschingbauer, Zsolt Kova´cs, Egon Teiniker, Reinhold Weiss, The entity container – an object-oriented and model-driven persistency cache, in: HICSS, IEEE, 2005. [14] Gernot Schmoelzer, Egon Teiniker, Christian Kreiner, Michael Thonhauser, Model-typed component interfaces, in: EUROMICRO-SEAA, IEEE, 2006, pp. 54–63. [15] Gernot Schmoelzer, Egon Teiniker, Stefan Mitterdorfer, Christian Kreiner, Zsolt Kova´cs, Reinhold Weiss, Model-driven development of recursive CORBA component assemblies, in: EUROMICRO, 2004, pp. 170–175. [16] Clemens Szyperski, Dominik Gruntz, Stephan Murer, Component Software: Beyond Object-Oriented Programming, Component Software Series, Addison Wesley, 2002. [17] Egon Teiniker, Leif M. Johnson, Robert Lechner, CCM Tools Project. , 2002–2006. [18] Egon Teiniker, Robert Lechner, Gernot Schmoelzer, Christian Kreiner, Zsolt Kova´cs, Reinhold Weiss, Towards a contract aware CORBA component container, in: COMPSAC, 2005, pp. 545–550. [19] Egon Teiniker, Stefan Mitterdorfer, Leif Morgan Johnson, Christian Kreiner, Zsolt Kova´cs, Reinhold Weiss, A test-driven component development framework based on the CORBA component model, in: COMPSAC, 2003, pp. 400–405. [20] Egon Teiniker, Stefan Mitterdorfer, Christian Kreiner, Zsolt Kova´cs, Reinhold Weiss, Local components and reuse of legacy code in the CORBA component model, in: EUROMICRO, 2002, pp. 4–9. [21] Egon Teiniker, Gernot Schmoelzer, Joerg Faschingbauer, Christian Kreiner, Reinhold Weiss, A hybrid component-based system development process, in: EUROMICRO-SEAA, 2005, pp. 152–159. Gernot Schmo¨lzer received his Ph.D. degree in Informatics and Electrical Engineering from Graz University of Technology in 2007. Currently he is working as software architect at Salomon Automation GmbH, Austria. He is also a research associate at the Department of Computer and System Sciences, Royal Institute of Technology (KTH) in Sweden, participating in several computer security research projects. His research interests include computer security, software technology, model-driven development and software product line engineering. Egon Teiniker received his Ph.D. in Informatics and Electrical Engineering from Graz University of Technology in 2005. Currently he is working at the FH JOANNEUM University of Applied Sciences and as a technical consultant in the area of enterprise application integration. His research interests include model-driven development, component-based software engineering and service-oriented architectures.

G. Schmo¨lzer et al. / Journal of Systems Architecture 54 (2008) 551–561 Christian Kreiner graduated and received a Ph.D. degree in Electrical Engineering from Graz University of Technology in 1991 and 1999, respectively. Starting 2000, he served as head of the R&D department at Salomon Automation, Austria, focusing on software product line development for logistics software systems. He was in charge to establish a company-wide software product line development process and also headed the newly launched software product development department (from 2005).

561

During that time, he led and coordinated a long-term research cooperation with the Institute for Technical Informatics of Graz University of Technology. Since 2008 he is staff scientist at the same place and industry consultant. His research interests include software technology, software engineering and software process improvement.