Integration of new components into existing information systems (IS) is a challenging problem mainly because of the data sharing. In this paper we propose a situation-driven approach for IS components (IS-COTS) integration into existing IS. We claim that such an approach has to take into account a large number of situations and therefore has to be built by applying situational method engineering principals and defined as a collection of reusable method chunks. The main contribution of this work consists of the metamodel for ISCOTS definition, the specification of the requirements for the proposed approach and the illustration of our approach with three method chunks.
Enterprise-wide Information Systems (IS) are very often built of several more or less autonomous IS components. Besides, constant changes and evolution of enterprise organisation and business require for new IS components that have to be integrated with the legacy ones. This situation leads to fragmented IS and therefore to the redundancy between different IS components which introduces the need for a permanent data, process and rules consistency validation. The common part of different IS components represents the interoperability area of the enterprise IS. If no integration is done between these IS components, the interoperability challenge is left to the human using this IS, i.e. the human have to validate “by hand” the consistency between different IS components. Such a human intervention generates extra cost and leads to a poor data quality.
To reduce this interoperability cost and to support the extension of existing IS with
new components we aim to develop a new approach for IS components, that we call
IS-COTS, integration into legacy IS. It is evident that such an interoperability
challenge leads to a large range of situations to be considered and resolved. As
consequence, we build our approach following situational method engineering [
The remainder of this paper is in five sections. In section 2 we analyse the domain of component-based IS engineering and explore how COTS-based software engineering principles can be adapted to IS engineering. Section 3 provides the metamodel of IS-COTS while section 4 specifies requirements for an approach supporting IS-COTS integration in a situation-driven manner. To illustrate our approach we propose three examples of method chunks in section 5. The paper ends with a review of this work and its future perspectives. 2
IS engineering methods must continuously consider the new forms of technology to support business activities. Introduction of Enterprise Resource Planning (ERP) systems modify deeply IS engineering in the enterprises; even if not all IS domains are covered by ERPs. But, despite the increase of flexibility of such systems, often the organization of the enterprise and/or its business practices have to be considerably transformed to be adequate with the selected ERP. Sometimes this transformation fails. Nevertheless, the ERP approach has success and the main reason of that is the integrated approach for all the data that the ERP system manages.
Another approach of component-based IS engineering is based on the use of
generic components, generally called Component off-the-shelf (COTS). The slogan of
this approach is “not to reinvent the wheel”. The developers of software and/or
information systems are invited to go to the hyper market of COTS (of course it is a
virtual one as Capterra [
Therefore, we claim that COTS for information systems, that we call IS-COTS, should be white boxes. Due to the fact that IS-COTS share data previously stored in the IS when they are integrated and executed in this IS, the process of integration of IS-COTS into an IS is more sophisticated than the process of integrating traditional software COTS. It must take into account the fact that the IS-COTS and the IS have an overlap of data and this overlap must be overcome. Besides, it is not only a technical question but also a question of business rules, sharing of responsibilities and transformation of schemata at the static and the dynamic level. Insertion of IS-COTS into a legacy IS is in fact an extension of the IS application domain. Moreover, this extension is at the origin of a lot of new situations relative to the sharing of objects of classes, compatibility between constraints and coordination between transactions but also the emergence of new human roles, new human activities, new business rules and new levels of human coordination.
We claim that IS engineering based on IS-COTS integration can combine the real strength of the ERP approach relative to the integration of data and the real strength of the COTS approach relative to flexibility. Definition of an IS-COTS as a white box allow us to clearly identify the overlap between the IS-COTS and the IS under consideration. This overlap specification is necessary to evaluate the impact of the ISCOTS integration and to identify elements that serve as a basis in the integration process. In the next section we provide the definition and the metamodel of an ISCOTS. This metamodel is as a basis for the overlap specification and represents the product part of the methodology for IS-COTS integration. 3
Traditional object-oriented methods propose two categories of models, static and
dynamic, to specify software and information systems. Static models deal with data
structure and system architecture definition while dynamic models define system
functionalities, activities, states and behaviour. In our opinion, these two modelling
perspectives are not sufficient to completely specify an IS. We identify a third
perspective, which is specific to the IS engineering, the specification of rules
governing the IS and ensuring the integrity of its data. Therefore, from the conceptual
point of view the specification of an IS is a triplet <static space, dynamic space, rules
space> [
As defined in [
Static space (SS). We use an object-oriented approach to represents the structure of
the information. As shown in Fig. 1, the main concepts of this space are well known:
class, attribute, key, specialization/generalization relationship, and method.
Relationships between classes are limited to existential dependencies and are captured
in the attributes. To be able to better represent the domain of the IS and to support its
evolution, we extend the object-oriented approach with the notion of a Hyperclass. “A
Hyperclass is a large class, composed of a subset of conceptual classes of the IS
schema, forming a unit with a precise semantic” [
Rules Space (RS). The objective of this space is to preserve the coherence,
correctness and consistency of the IS during its exploitation. The main type of rules to
be considered here is the integrity rules [
To illustrate the notion of an IS-COTS and its integration into an existing IS, we use a simplified version of the IS of our University, the part which is in charge of courses and students management. This IS was designed to support courses and students related to the Bachelor diploma (in the terms of the Bologna declaration). The static space of this IS is shown in Fig. 2 (a). It provides support to describe and organize Bachelor courses. It allows to allocate students to the courses corresponding to the followed Bachelor and to store their examination results, to associate teachers to their courses, and to generate several documents like examination reports, Bachelor diplomas, etc. Each person (student or teacher) belongs to an institution that can be either a University or a department of a University or another kind of organisation (e.g. a teacher from an industrial company).
(a) (b)
In order to support the management of the Master diploma in the same manner as the Bachelor diploma, the initial IS has to be extended with a new IS-COTS. The static space of this IS-COTS is shown in Fig. 2 (b). We can already see from this figure that the overlap between these two static spaces is quite important and their integration requires a well guided methodological support. In the next section we specify requirements for a method supporting IS-COTS integration into an IS. 4
According to several authors [
In our case, the step of method design is based on the notion of reusable method
chunk while the step of method construction uses the assembly technique in order to
combine method chunks into a situation-driven and flexible process. Instead of
providing one universal methodology for IS-COTS integration we propose to define it
as a collection of inter-related and reusable method chunks each of them addressing
some specific activity in the IS-COTS integration process. Some chunks can be
extracted from existing methods [
The main contribution of this work is the specification of the requirements for a situational method supporting IS-COTS integration and illustration of a few method chunks to be included in this method. 4.1
Integration of an IS-COTS into an existing IS has to be considered in two levels: conceptual and system level. The former deals with the integration of conceptual models representing data schemas, integrity rules and transactions while the later aims to ensure compliance with existing data and applications. In this paper we present the part of our approach dealing with the integration at the conceptual level.
Supposing that the required IS-COTS have been selected, we consider that the process of its integration into the IS should be based on five main steps: 1. The adaptation of the selected IS-COTS, 2. The identification of the overlap between the IS-COTS and the IS, 3. The unification of overlap situations if necessary, 4. The construction of the integrated specifications by applying the appropriate integration operators on the identified overlap elements, and 5. The consolidation of the obtained specifications.
During the first step the selected IS-COTS have to be adapted to the system requirements. It can be reduced if its scope is too large, for example, it contains some inadequate classes, transactions or rules. Or in the contrary, it can be necessary to extend the component with some additional elements (classes, attributes, rules, etc.) in order to better prepare it for the integration into the IS. Besides, it can undergo different kind of modifications as renaming, restructuring or reattribution of roles.
The second step consists in identifying overlap situations in the specifications of the selected IS-COTS and the considered IS, analysing these situations, identifying elements for the integration (e.g. classes to be merged) and detecting elements that need to be unified before their integration.
During the third step the overlap situations requiring some unification have to be settled by applying the appropriate unification and transformation operators. We distinguish three types of unification: semantic, structural and functional. Semantic unification mainly concerns concepts naming. For example, if the same name is used for different things or, in the contrary, the same thing is named differently in the two schemas, one of the names have to be modified. Structural unifications deal with structural representation of the information. For example, a concept can be Reduce
Extend
Modify Validation
Adapt IS-COTS
Start
Semantic Structural Functional
Functional
Structural
Validation Semantic Identify Overlap represented by a class in one schema and by an attribute in the other. In this case, the attribute can be transformed into a class. Finally, functional unification mainly appears in the dynamic space of the specifications and concerns the modification of transactions. It is evident that modifications have to be avoided as much as possible in the IS specification and the most of the transformations have to be done on the ISCOTS specification in order to preserve the integrity of the already existing data and running processes.
The fourth step consists in selecting the appropriate integration operator for each overlap situation and to apply it.
Finally, the integrated specification has to be consolidated. The integration of an IS-COTS into an IS can create new situations which didn’t exist neither in the initial IS nor in the IS-COTS. The new integrated system is more than simple addition of two applications. It can provide additional information or functionalities and impose additional rules that have sense only in the new integrated system. Therefore, it can be necessary to add new integrity rules or new transactions in order to guarantee the completeness and the coherence of the integrated specification.
Based on this reasoning, we specify requirements for the approach supporting
ISCOTS integration as shown in Fig. 3. As advised in [
Based on the discussion above, the requirements map (Fig. 3) for IS-COTS integration contains five main intentions namely Adapt IS-COTS, Identify overlap,
Stop Completeness validation Validation
Conflict Consolidate Specifications
With appropriate integration operator By adding new elements
Integrate Specifications
Structural Functional
Semantic Unify Overlap
With appropriate
integration
operator
Unify overlap, Integrate specifications and Consolidate specifications and foresee
several strategies to achieve each intention. The process model for IS-COTS
integration should provide one or several method chunks for each section (a triplet
<source intention, target intention, strategy>) of this map. The method design step
consists in defining these method chunks, each of them being more or less complex,
atomic or compound, depending on the complexity of the guideline it have to provide.
The metamodel of method chunk was already presented in [
In this section we propose three examples of method chunks: the first is related to the overlap identification between the IS-COTS and the IS specifications, the second deals with the integration of specifications and the third one helps to consolidate integrated specifications.
Identify Overlap. The overlap between the IS and the IS-COTS specifications have to be considered in the three spaces: static, dynamic and rules. The method chunk presented in Table 1 helps to identify and describe the semantic overlap in the static space. This identification leads to an overlap report that describes all semantic relationships between the IS and the IS-COTS static space specifications. For each couple of classes having similar semantics in the IS and the IS-COTS specification a relationship descriptor is provided.
Integrate Specifications. Based on the overlap report several integration situations can be identified. We propose a method chunk (see Table 2) that aims to realize one of them: the integration of two classes where their objects are in the situation of intersection. The guideline of this chunk specifies operations that must be realized in order to fulfil the goal of this chunk. For some of them the notion of common attributes, methods, transactions, and integrity rules are used. The identification of such common elements is the role of method chunks supporting the Identify Overlap phase but which are not presented in this paper due to the lack of space. Another notion used in the guideline of this method chunk is the Product Requirements. This notion is used to specify some additional requirements on the product part. For example, in this chunk some evolution primitives must be enabled in order to realize the guideline operations. These requirements also play a role during method chunks selection process. Indeed, if the IS is not able to support these evolution primitives, this method chunk cannot be selected.
Consolidate Integrated Specifications. The method chunk presented in Table 3 helps to consolidate the integrated specifications. It is mainly helpful after the application of the method chunk presented in the previous section. Indeed, the integration of two classes via a common superclass generates a new situation: the integrated specifications have to support object transfer from one subclass to another and requires for new integrity rules and new transactions supporting such a transfer.
Chunk ID: MC01 Name: Semantic Overlap of Similar Classes Objective: To identify and specify the semantic overlap between similar classes Interface:
Situation: Static space specifications of the IS and the IS-COTS Intention: To produce an overlap report that specifies the semantic relationships between the classes of the IS specification and the similar classes of the IS-COTS specification Body:
Product Part: The IS-COTS metamodel (Fig. 1). The overlap report metamodel (figure below).
Guideline: For each classe from the IS specification that have a semantic relationship with a class of the IS-COTS, to create an overlap item in the overlap report and to define the relationship descriptor. There are five types of descriptor. Each of them is based on the set of objects (**Clis) of the IS class Clis and on the set of potential objects (**Clis-cots) (objects that will be stored after the integration) of the IS-COTS class
Clis-cots. 1. **Clis = **Clis-cots: all objects of the IS class are included in the IS-COTS class and vice versa. 2. **Clis **Clis-cots: all objects of the IS class are included in the IS-COTS class. 3. **Clis **Clis-cot : all objects of the IS-COTS class are included in the IS class. 4. : some objects are common to the IS and the IS-COTS class and some are **Clis **Clis-cots z not.
**Clis **Clis-cots = : the IS and the IS-COTS classes have no common objects.
Application Example: Let us take the example introduced in section 3.2. The overlap between the University IS and the ISCOTS for Master diploma can be analysed as follow: x **IS.Person = **IS-COTS.Person x **IS.Teacher = **IS-COTS.Teacher x **IS.Student **IS-COTS.Student z : Students of the IS are at the Bachelor level while those of the IS-COTS are at the Master level. Therefore, there are three categories of students: (1) those that are only known as Bachelor students, (2) those that have not done their Bachelor in this University and are only known as Master students and finally (3) those that have finished their Bachelor in this University and now are Master students. x **IS.Course **IS-COTS.Course = : Courses from the IS represent Bachelor courses while those from the IS-COTS represent Master courses. As a course can be only a Bachelor or a Master course, the intersection of the objects is empty. x **IS.Diploma **IS-COTS.Diploma = : Diplomas from the IS represent Bachelor diplomas, those from the IS-COTS represent Master diplomas. As a diploma can be only a Bachelor or a Master one, the intersection of the objects is empty. In our example, the integrated IS has to manage two kinds of student: Bachelor and Master. As defined in the overlap report, a student object can belong to both the BachelorStudent class and the MasterStudent class. Therefore, we need to add a new transaction allowing a Bachelor student to become a Master student. Besides, a new rule has to be added in order to ensure that a Bachelor student has finished his Bachelor degree before beginning Master studies. This rule is expressed as follows: ON ENTER in MasterStudent : obj exist in BachelorStudent AND obj.hasBachelor == True where obj represent a student. 5
While the use of IS is growing in all areas of our society, the diversity of their application domains increases as well. To address this diversity, ERP systems and Components of-the-shelf, also named COTS, are proposed as building blocks to compose new IS and to evolve the existing ones. In this paper we claim that, in the contrary to the software engineering, COTS for IS engineering cannot be proposed as black boxes and a simple plug-in process is not sufficient to integrate COTS into existing IS due to the data, processes and rules overlap. Therefore, in the domain of IS engineering we need a new kind of COTS provided as white boxes as well as we need a new kind of approaches to deal with the complexity of their integration. In this perspective we see the following contributions of this paper:
The notion of IS component that we call IS-COTS and its metamodel. The requirements specification for a situation-driven approach supporting ISCOTS integration into existing IS. The MAP formalism used for requirements representation as a strategic process model enables their evolution. Indeed, it is quite simple to add new strategies and intentions into the requirements map. The examples of method chunks to be integrated into our approach. We claim that such an approach should be based on situational method engineering principals, i.e. it has to be modular, reusable and flexible. Therefore, we aim to define this approach as a collection of inter-related method chunks dealing with a huge number of IS-COTS integration situations. This kind of flexibility and adaptability to a specific situation lead us to a new kind of approach for IS engineering.
Currently we focus our effort on identifying and evaluating different situations that can occur in the IS-COTS integration process and defining method chunks satisfying these situations. A tool support is also under development.