The ability of reusable components to be varied and appropriate to different designers and re-users requirements is a key property in reusable component development, especially in Business Component (BC) development. The primary objective of this work1 is BCs reuse in different Business Domains. In order to achieve this goal, we focus on the variability concept, which is defined as the ability of a software artefact to be changed or customized so as to be reused in multiple contexts. Thus, we introduce the concept of Functional Component (FC) that captures similarities and variations between BCs that share common behaviours in order to increase their reusability in different business domains. The FC is modelled by using a multiview variability.
Component reuse is defined as the process of implementing or updating information systems using existing assets, and the ability of reusable components to be varied and appropriate to different designers and re-users needs is a key property in reusable components development.
This process has been supported by research contributions from various fields,
including generic data models [
However, we presume that is also beneficial the reuse of variable development
artefacts. For this, we focus on the concept of variability, which is defined as “the
ability of a software artefact to be changed or customized to be used in multiple
contexts” [
According to [
Researchers have proposed different structures of BC (see [
ReserveBed() is a part of the interface of the Hotel BC). - The “Master” part describes what the BC is. It corresponds to the structural part (e.g. “Hotel” is a structural part). Yet, the class “Part” (“Room”) supplements the Master part to which it is connected by a composition relationship. It corresponds to a partial structuring of the attributes of the Master part, thereby highlighting a business aspect of the component. - The “Role” part describes what a BC uses. It highlights the collaboration played with BC suppliers (e.g. “RoomRes” formalizes the contract between the class “Room” and a supplier (other BC interface, for instance the Reservation BC), thus, “RoomRes” class is described as a role).
However, in this paper a special interest is given to the reuse activity in several business domains. Therefore, we propose to represent the BC at a generic level and to express all its variabilities. For this purpose, we introduce the concept of Functional Component (FC) that captures similarities and variations between BCs that share common behaviours in order to increase their reusability in different business domains. In this paper, our objective is to design an FC and express variability in order to support the development and the reuse of variable development artefacts. Variability can be applied and occurs at different views of development (functional, dynamic and static). However, locating where an FC varies and the way we can realize its variations are complex tasks. Thus, with FC development, the necessity to trace variability between solution and problem spaces is inevitable, and the approaches dealing with this complexity of variability need to be established clearly.
This work aims to define the main concepts of variability for reuse, namely the requirements for identifying variability, thus outlining the crucial factor for determining the overall benefit of variability for reuse, especially how it can enrich a reuse space and improve the reusability of the developed BC. In this paper, to illustrate how to get an FC from similar BCs, we use an example which shows variability between two BCs from the same functional domain (Reservation), but from two different business domains: Tourism (Hotel Reservation) and Health (Hospital Reservation).
The remainder of this paper is structured as follows: in Section 2, we define the relations between a BC and an FC. Variability finality and capture concepts are illustrated in Section 3. In Section 4, we introduce an approach to represent a multiview variability in an FC. Related works are presented in Section 5. Concluding remarks are given in Section 6.
BC 1 BC 2 BC n
In this paper, the purpose of our approach is the design of FCs that represent abstract recurrent behaviours (e.g. Resource Allocation, Recording…) among several business domains (e.g. Tourism, Health…), in order to reuse them in other business areas (e.g. Transport). The main idea here is to abstract BCs that share these behaviours related to their own business domains. This consists of the identification of what is common and what is variable between these BCs. Hence, using variability mechanism is needed.
To support the variability concept, we propose that the specification of an FC has to distinguish between a fixed part and variable parts (cf. Fig.2). The fixed part represents the component structures which are reusable in each business domain that requires these structures; they are directly integrated in the BC under construction. The variable parts represent the component structures for which reuse requires a selection process adapted to a particular business domain.
Variability in FC is then defined as a process which is used to control the common and variable parts of FC artefacts. Variability resolution (exploitation) produces a collection of particular FC reuse cases. Yet, the abstraction (design for reuse) is a process that identifies reusable artefacts from BCs that already exist in several business domains, and the reuse (design by reuse) is a process that produces reuse cases of FC artefacts in order to develop BCs. Both processes are based on the variability technique.
Yet, a BC can be also reused in several applications within the same business domain. Thus, BC reuse gives a set of Business Objects which are modular structures specific to a given information system [11]. Business objects can represent entities (customer, supplier…) or processes (order, invoice…) associated to an information system. This type of reuse is not undertaken in our paper.
Functional Domain
Functional Element 1..*
* Functional Domain Business Domain
Business Element 1..*
* Business Domain Functional Component
Business Component 0..1 Abstraction of > 1..* * < Reuse of
1..*
The metamodel depicted in Fig.3 highlights the relation between a BC and an FC. The FC represents the central concept of a functional domain. A functional domain is composed of functional elements that correspond to knowledge which is independent from any business area whereas a BC represents the central concept of a business domain which is composed of business elements that correspond to business knowledge. An FC is built from the abstraction of at least one BC, and a BC can be built by reusing at least one FC or by the abstraction of at least one business objet of the same business domain. The relation between BC and business object is not represented in our metamodel.
Figure 4 depicts an example of functional domains composed of FCs and business domains composed of BCs. The “Resource Allocation” can be made with or without reservation, thus, we represent it with the FC1 which can be specialised by both FC2 and FC3. To illustrate the relation between FCs and BCs, the example shows that FC3 can be reused in several business domains, so it can be reused to design BC1, BC2 or BC3. In addition BC1, BC2 and BC3 can be abstracted to design FC3.
FC3:
There are many concepts involved in variability management. In the present section, we introduce several concepts that we consider as the minimum necessary to specify an FC supporting variability. These concepts deal with tow points: variability finality and variability capture.
1. One BC implements a feature in several ways and offers the user a choice among them. 2. Several BCs from different business domains share the same feature but implement it in different ways and it is foreseeable that, in future BCs, the feature will be implemented in other ways.
In our case, in which we want to express variability for reuse, we focus on the second point. This case shows that variability can be identified in several BCs and can be predictable for future BCs.
In the initial phase of the FC development, we are confronted to requirements that allow us to identify where variability is needed. Thus, variability capture is the most important phase to discover where BC varies.
In our context, for variability capture, we propose to use a list of BCs within the same family of systems i.e. systems that share common characteristics. Then, we proceed to deal with the commonalities and differences between those BCs. Hence, we use in this paper two similar BCs of the “Reservation” system and we try to represent them with an abstract BC as an FC. The first BC is the “Bed Reservation” in a “Hospital” business domain and the second BC is the “Room Reservation” in the “Hotel” business domain. Commonalities are the fixed parts of the FC, and differences are the variable parts of the FC, which are the parts that make the BCs distinct from one another. Yet, for more details about variations, we propose that the specification of each BC must be at different views (i.e. functional, dynamic and static). Due to space limitations, we cannot present a full account of the variability capture phase.
The abstraction activity aims to generate an FC by comparing similar BCs according to the three views. In the “Room Reservation” and the “Bed Reservation” BCs, for instance, the comparison of their functional and dynamic views leads to the generation of abstract artefacts by a simple use of reservation taxonomy. All we have to do is to replace “Room” and “Bed” by “Stay Place”, “Secretary” and “Receptionist” by “Reservation Responsible”, “Hotel” and “Hospital” by “Stay Provider”, etc.
However, at the static view, the abstraction activity is more complex. This situation shows the presence of variation between both BCs. This variation is denoted by the way the “Stay provider” and the “Stay place” are related. In fact, in the “Hotel” BC, the “Room” class is directly related to the “Hotel” class. Nevertheless, in the “Hospital” BC, the “Bed” class is related to the “Hospital” class by an intermediate class, which is the “Room” class. This statement leads to the distinction of a structural variability, which occurs when there are classes related in several ways. Hence, we denote the differences identified between our two BCs by the degree of depth of related classes that vary from a BC to another. Once a variation is identified, it needs to be constrained. Thus, it is eventually designed as variable part; we have illustrated this point in the context of a precedent paper [13]. In the next section, we show how to represent this variability across the three views of the FC.
Proceedings of MoDISE-EUS 2008 4
As we mentioned in Section 3, the variation identified in our BCs is the degree of depth when a “Stay Place” is related to a “Stay Provider”.
Hence, to represent differences between BCs of the same family, we use the concepts of Variation Points (VP) [14] and / or Variants (V) [15]. According to our context, we define VP and V as follows:
Variation Point: represents a location on which a variation will occur. It is a conceptually common feature that can be implemented in different ways. Thus, it locates a specific place in an FC artefact to which a later decision is attached. Variant: represents a specific implementation of a variation point. It corresponds to design alternatives to resolve the variability.
Thus, in this example “Identify StayPlace” is considered as a Variation Point and “Identify StayPlace_0 degree” (i.e. a “Room Reservation”; the class “Room” is related directly to the “Hotel” class) and “Identify StayPlace_1 degree” (i.e. a “Bed Reservation”; the class “Bed” is related to the “Hospital” class by an intermediate class: “Room” class) are considered as Variants of this VP.
In this paper, to represent variability, we propose to use UML extension carried out by stereotypes. UML is a good candidate for variability representation, because there is wide range of tools supporting it, and the notation is extensible. Therefore, we will apply this approach on the functional, dynamic and static views of our FC. 4.1
At the functional view, our proposed stereotypes are supported by use cases in the use case diagram. Stereotypes that we use in our example are given as follows: - « Variation »: to specify if a use case is a VP. - « Variant »: to specify a variant related to a VP. - « Alternative »: to specify the relation between a VP and its alternative Variants.
Figure 5 depicts a variable specification of the functional view of the FC. “Identify StayPlace” is a VP while “Identify StayPlace_0 Degree” and “Identify StayPlace_1 Degree” are its alternatives variants. Expressing variability in the dynamic view is based on frames (fragments of interaction). Thus, we include sub-sequences corresponding to alternatives. This technique requires the application of the following rule: any Variation Point of the functional view must be represented by at least a frame of a sequence diagram in the dynamic view. Hence, we respectively use the stereotypes « Variation » and « Variant » on the fragments related to a VP and V.
Figure 6 depicts a variable specification of the dynamic view in the FC. It illustrates the frame for the use case “Reserve StayPlace”, including a reference to the “Identify StayPlace” fragment. Figure 7 shows how the dynamic parts of the variants are included in the variation point.
This phase consists of the specification of the static contributions of each functionality to finalize our FC. Indeed, for each specified use case, we give the static contributions in the solution model.
The structure is distributed in several fragments which will be assembled to form a traditional static view at the reuse activity. Each class impacted by a variation or by a functionality will be represented in the static fragment of this use case. Figure 8 depicts static fragments of the use cases: Reserve StayPlace (8.a), Identify StayPlace_1 Degree (8.b) and Identify StayPlace_0 Degree (8.c).
Identify StayPlace_1Degree <<Variant>> 8.b
Identify StayPlace_0 Degree <<Variant>> 8.a 8.c
Once variability is modelled across the three points of view, we obtain an FC supporting variability. According to our example, we also mention that it is worthwhile to note that having designed an FC allows many BCs to be derived in other business domains such as the “Transport” business domain. For example, we can reuse our FC for a “Train Place Reservation”. This FC reduces software development efforts. In this context, we make use of a horizontal reuse across a wide variety of business domains.
Yet, our approach can also be applied for vertical reuse. In this case, the basic idea is the reuse of a BC supporting variability that can be used by a family of information systems with similar requirements in the same business domain. In this case, variability can be used with the customization finality.
Variability was originally introduced in the FODA method by the feature model [
Therefore, several extended UML methods have been proposed (see [14], [15] and [16]) in order to represent the variability concept. The extension is realised by using standardised extension mechanisms of UML by using stereotypes, and can be expressed as a UML profile [17].
In our work, we based on this solution. In fact, extending UML for modelling variability in BC artefacts, throughout different phases of development (requirements, analysis, design and implementation) or different points of view (functional, static and dynamic), has the benefit to guarantee traceability among corresponding artefacts, and the particularity of our work consists of taking into account the business aspects in order to represent this variability.
Furthermore, variability, as a separate model was proposed, and was denoted by
Variability Orthogonal Model (VOM) in the product line context. The VOM, as it is
described in [
This paper described the potential of variability modelling through BC development. To design a generic BC, which supports variability, we have introduced the concept of FC which captures similarities and variations between BCs that share common behaviours. Subsequently, the FC can be reused in multiple business domains.
Our proposed approach needs further study; it means that after designing functional components supporting variability, it is essential to implement a resolution process of this variability, as well as the integration of these components in the development process of a components-based information system.
Therefore, we presume that only conceptual models of functional components, such as UML models, produced during the specification or design processes, are real reusable artefacts for the design of components based information systems; they are technologically neutral and evolve according of the changing needs for which they respond.