Cross Product Line Reuse in Component-based ...

2010 International Conference on Computer Application and System Modeling (ICCASM 2010)

Cross Product Line Reuse in Component-based Software Engineering Yang Liu, Kinh Nguyen, Mary Witten and Karl Reed Dept. of Computer Science and Computer Engineering La Trobe University, Melbourne, Australia [email protected]

Abstract —Over the last twenty years, our understanding of how software systems can be developed as product lines has improved significantly. However, there has been little progress towards a wider goal of product lines that are usable across disparate application domains. We present a new formalism, a Nature Diagram, to address this issue. This representation allows the characteristics (both data structures and operations) of entities identified during the design process to be represented and easily compared in a way that allows their usability in domains other than their original “home” to be identified. The approach is inspired by the natural ability of human designers to discover similarities between systems. We validate our method using two real world examples, and illustrate its advantages by comparison with existing methods. Keywords—Product line, Cross domain reuse, Component.

II. C ROSS DOMAIN ISSUES PLE comprises two major phases[1]: domain engineering (creating core assets) and application engineering (adding extra features according to the customer’s requirements). From Figure 1, domain analysis identifies the candidates for

I. I NTRODUCTION Product Line Engineering (PLE) has lead to increased reuse, to higher product quality and reduced time to market[1]. PLE research targets the construction of multiple variants of some application within a given application domain, or the construction of these from a core set of components. However, there have been few attempts to develop cross domain product line development methodologies[2]. The existence of large scale, underlying commonalities between applications from different domains has been suggested (theatre reservation/university course administration[3]; air traffic control/flexible manufacturing[3]; banking/stock control/lending library[4]; theatre booking/airline booking/lending library/warehouse system[5]). Demonstrating the similarity of a wide range of (apparently) different applications would constitute a significant step towards high-level reuse. A model description system, suitably structured from the cross-domain PLE viewpoint, would permit comparison of applications in one domain with descriptions of classes of applications in others. Design would then become the specialisation of those generalised application models which matched appropriately. There are currently no standardised approaches that allow PLE to be used across multiple domains even when similar requirements appear to exist. This paper introduces a new method based on capturing the nature of systems by employing a new type of diagram, a “Nature Diagram” and constructing formal descriptions for identified user tasks of a product line. Thus, commonalities in the pre-built product line and new requirements can be compared, insupport of the product line in different domains.

978-1-4244-7237-6/$26.00

C

2010 IEEE

Fig. 1: Domain engineering in Software PL[6] later reuse. Domain analysis may involve domain experts to provide technical assistance at the beginning of the project development[7]. Defining a product’s domain is considered difficult, and subsequent changes are considered counterproductive[8]. Too narrow a domain restricts reuse for future products; too large a domain leads to a high cost, less useful product line as product features will be vague when the domain covers too many possible products. Component-Based Software Engineering (CBSE) enables cross domain reuse as a result of the development of families of domain “agnostic” atomic components (which can be “small” or whole COTS applications e.g. applications from MS Office). Developers can integrate these to build systems for different requirements. This type of reuse can be applied

V9-427

2010 International Conference on Computer Application and System Modeling (ICCASM 2010)

across application domains. For example, examination of functionality shows an account matching component in a bank system can be reused as a member ID validating component in a theatre system. Nevertheless, in current PLE methods like Form and KobrA, the domain analysis is actually finalized before the system’s component level structure is determined. Consequently, developers tend to reuse components from the target application domain, or even application family. When using product line from one domain as the basis for a product line in a new domain, there may be a name-space mapping mismatch which conceals the correspondence between their individual abstract data types and operations[9]. This is exacerbated by designers interpreting “name-type” bindings using the semantics of their “names”. This obfuscates the identification of reusable elements in the source framework. Product line approaches such as KobrA[8] do not solve this problem despite their extendable dictionaries for namespace matching. The existence of the underlying similarity of systems from “widely” different domains clearly implies the need for a better approach. Consider library management, theatre booking, airport booking, and warehouse management systems at the domain level[5]. By listing objects from their enterprise models in Figure 2, cross domain similarities can be observed. Currently, experience is the only tool for finding

Fig. 2: Cross domain similar systems[5]

based on the KobrA PL methodology[8] as it is componentbased and has a well-defined structure. We use basic domain analysis models - enterprise models and use case analysis; to determine the commonalities between systems. KobrA’s enterprise model includes the enterprise concept and enterprise process diagrams. In the former, there are two types of nodes: role and entity (similar to control and entity classes respectively in class diagrams). The system is shown as a role node in the enterprise diagram. We focus on the relationships between the system actor and the leaf nodes in the concept diagram. For example, the Library System’s enterprise diagram in Figure 4, shows the library system as the main actor and the leaf entities: Item and LibraryAccessCard. Two experimental rules[5] are used to validate that leaf node entities qualify as main entities in the enterprise model. 1) Main entities are those that can exist independently in the enterprise model. 2) If the main entities cannot be identified then calculate the information content of each entity, according to the formula:  wi = F(ci ) + cj ∈ Rci C(ci , cj ). Here F(ci ) is the frequency of the entity ci , C(ci , cj ) is the value of coupling between ci and other entities, Rci is the asset of all the entities which directly relate to entity ci . Using these rules, the “Item” entity qualifies as a main entity. The “LibraryAccessCard” has high cohesion to another role entity “Account” so it should not be used as a main entity to profile the Library System. After the qualified leaf node entity has been identified in the enterprise model, our Nature Diagram(ND) is used, to describe the relationship between the leaf node entity and the system. The relationship between  role  and  entity  is profiled as an actor-object operation. Each leaf node entity is represented by an object with name and attributes and the system entity is represented by an actor. The role of actor in this diagram is to change the object’s status and attributes by its actions. These actions are represented by the links between the system actor and the end node entities. Figure 3 illustrates

these similarities[5]. Inexperienced developers may miss reuse opportunities available in an existing product-line. Converting skills currently held only by experienced developers into “methods” capable of being used reliably by less skilled and experienced people is essential. To this end, a method for building bridges between different domains is required. In our view, this must use the results of the domain analysis for the first application in the product line, and before the product’s domain model has been constructed. III. R EUSABLE COMMONALITY FROM FORMAL STRUCTURE

(a) Library

We use the fact that humans can identify the significant features of an object[10] to capture the most important features of the system above the domain level. Our approach is

(b) Theatre

Fig. 3: The Nature Diagrams the commonalities between the library and theatre systems.

V9-428

2010 International Conference on Computer Application and System Modeling (ICCASM 2010)

Although the Theatre System’s ND has an additional layer around the leaf node, considering Show as a separate entity we have the scenario of the Library System and Item. After the commonalties have been observed, we use the Bmethod[11] to describe each part of the system starting from the leaf nodes. We use the enterprise process diagram as a map of the system, to make sure there are no missed parts. Before we construct the B-description for each entity, we write the use case description for all the use cases that relate to that entity, based on the use case diagram which is provided in the domain model of the product line. After we have completed the use case description, we use this document as a reference for the details of the system operation for charting the B-description. When a new system is going to be constructed, by repeating the first two steps we can identify the end node entities and the Nature Diagrams of the new system. Developers can focus directly on the system operations on the leaf node entities because in the Nature Diagram, all entities are represented by the same symbol and their status and attributes are represented by outside, connected components. If two systems are similar in their Nature Diagram representations, then developers can use the B-description of the pre-built product line to assess the possibility of generating the B-description of the new system entities based on the existing description, and follow the route of the new system’s process diagram until a complete system B-description is generated. During this process, developers can find out how much commonality exists in these systems’ B descriptions. Our current thinking is that if more than 65% of a new system can be described by reusing the description of an old system, then the new system will be identified as similar and can be produced by the pre-built product line. In the next section, the whole process of our reuse model is illustrated using the Library System as the first built product line and the Theatre System as the required new system.

Fig. 4: Library enterprise concept diagram[8]

IV. B UILDING A R EUSE M ODEL Following KobrA’s development process, we first create the enterprise concept diagram and the enterprise process diagram for the two systems. The enterprise process diagram is used for decomposing and identifying system activities. As a starting point of system function analysis, those smallestgrained activities (the bottom nodes in the process diagrams) are called user tasks, which directly reflect the use cases of the system. From the enterprise concept diagram of the Library System, we can identify the end node entity - Item is the main entity that is operated in the process by the system actor. The entity Loan is the related entity of Item and entity Account is the container of the Loan. Next we group the user tasks in the enterprise process diagram, according to their aims. In the process diagram of the Library System, there are twelve user tasks related to Item, and six tasks related to changing the status of an Item; namely, Loan items, Return items, Reloan items, Reserve items, Register item and Remove item. The user task Overdue control can be considered as an optional task inside the Loan

Fig. 5: Theatre enterprise concept diagram

items. Search and Lost report are also related to Item. Later, these user tasks will be generated as use cases in the use case diagram. Based on Figure 7, we can identify that the end node entity - Item represents the total number of items in the library and each item has an ID attribute. As the central actor, Library System has the ability to change the Item amount or trace an Item according to its ID. Then we construct the Nature Diagram of the Library System based on our analysis results. First we draw the main actor - Library System and the end node entity - Item. At this stage, we simply describe the relationship between the entity and the actor as “the centre actor manages the end node entity”. Then we can use “Manage Item” as the name of those user tasks that related to Item. In order to clarify

V9-429

2010 International Conference on Computer Application and System Modeling (ICCASM 2010)

Fig. 8: The basic expression of the System Nature

Fig. 6: Theatre enterprise process diagram

Fig. 9: Library System use case diagram[8]

Fig. 7: End node related user tasks from the Library System enterprise process diagram[8]

the relationship between the system actor and the end node entity, we transfer those user tasks in the enterprise process diagram into the use case diagram. In the use case diagram, we can list the group of use cases which are included in the asset “Manage Item” and we can identify the order of these use cases: Add Item → Loan Item → Reloan Item → Reserve

Item → Report Loss. From domain analysis we can identify there are two states of the Item entity: Loanable and Unloanable. We describe these states by employing a state machine. Then based on the relationship with state changes of Item entity, we can group these system actions into three groups: 1) Search: does not change the state of the entity but needs entity to provide its ID. 2) System actions that change the entity’s state (Loan items, Return items). 3) System actions that change the total number of entities (Add items, Remove items). We modify our ND by following the state machine separating the Item entity into two object assets: Loanable and Unloanable, and these two assets union together as the asset of all the items in the library.

V9-430

2010 International Conference on Computer Application and System Modeling (ICCASM 2010)

Fig. 10: Library System state machine

We express connections between the system actor and end node entities by using “+” and “-”, to represent changes in the number of Items in these two assets. Finally we represent those details of the Item entity by using the attribute symbol and add it on the outside of the Item entity super class. The complete System - end node entity ND of the Library System is shown in Figure 11. Having developed the system’s ND,

Fig. 12: Item Machine of Library System

Fig. 11: Library System Nature Diagram we use traditional techniques to describe the system in detail. First, we write a complete use case description of the Library System based on the system’s use case diagram. Then, using this complete set of use case diagrams, we construct the B-description of the System, starting from the end node entities. Each part of the system is described as an abstract machine in the B-method, and each related user task should have a corresponding operation in the abstract machine. This machine, (Figure 12) describes the Item entity in the Library System. Each Item has its ID and attributes and Item has its Loanable status. Furthermore, from this abstract machine, we can identify three operations which are related to the Item entity: (1) Create item (2) Loan items and (3) Return items.

As there is more than one item managed by the Library System, there should be another machine which represents the asset of all of the items. Here we add a machine named “Item List”, which shows an abstract existence - a list, by adding in all the Items in the library. Part of the Item List machine is shown in Figure 13. We repeat this for the Theatre System. We identify the end node entity “Seat” and we can identify the relationship between this entity and the Theatre System as Bookable. Then we generate the ND of the relationship between the Theatre System and the end node entity. It can now be compared with the system-main entity relationship in the Library System. From this we see that these two relationships with their end node entities can be represented by the same ND. The possibility of reuse based upon the two systems’ commonalities must be verified by a detailed comparison of the candidate structures. So we construct the B-specifications of the Theatre System, starting from the end node entity, and compare them with the abstract machine “Item” in the Library System. In Figure 15, all the bordered parts in the Seat’s B-specification are those which are different from the Item’s parts in the Library System. All of these differences are just on the name space of the attributes and operations, but the logic of their operations, and the concrete details of the operations are common. According to the KobrA principle, when two system specifications have

V9-431

2010 International Conference on Computer Application and System Modeling (ICCASM 2010)

Fig. 13: Item List machine of Library System

Fig. 15: B-specification of Seat compared with Item

(a) Library

(b) Theatre

Fig. 14: Nature Diagrams of Library and Theatre Systems

differences just on namespaces, but the same structure of operations, then the semantic mapping between these specifications can be constructed, and the reuse of this part of these systems can be realized. We systematically compare the Bspecifications of these two systems, using the Nature Diagrams or other types of diagrams (e.g. UML class diagrams) to find the corresponding parts in the two systems, until we have compared the full B-specifications of these systems. Having identified common elements, reusable components suitable for cross domain products can be built. In our research, we have implemented these common parts as generic classes (the reuse components). V. M EASUREMENT OF R EUSE Our method was evaluated by developing the Library and Theatre Systems twice, first without employing reuse (reusable

classes). Then three metrics were applied to measure the reuse provided. From our observation of the B-specification of the two systems, we construct four classes as reuse components: (1) Basic Element, (2) List Generator, (3) Composite Element and (4) Company Model. Those B-operations which repeatedly occurred in the Bdescription and differing only in their namespaces are directly represented as methods in the generic classes for reuse. Those B-operations with small differences in details are represented as abstract methods in generic classes. These will be implemented by the system classes, which reuse (extend) the generic classes as required by the system’s domain requirements.

A. Whole application reuse measurement Consider the percentage of reuse in a system application by counting Lines Of Code (LOC)[6]. Let L1, T1 represent the Library and Theatre Systems without using the reuse model and L2, T2 represent the systems using the reuse model. V(L1), V(T1) represent the total lines of code of the systems without reuse. V(L2), V(T2) represent the total lines of code with

V9-432

2010 International Conference on Computer Application and System Modeling (ICCASM 2010)

Fig. 16: Class-based reuse representation

Average reuse in both systems:

reuse. Library System: V(L1) = 399; V(L2) = 229. 1−

V(L2) 229 = ≈ 43% V((L1)) 399

Theatre System: V(T1) = 510; V(T2) = 296. 1−

296 V(T2) = ≈ 42% V((T1)) 510

1−

(1)

(2)

V(L2) + V(T2) 229 + 296 =1− ≈ 42.6% V(L1) + V(T1) 399 + 510

(3)

The saving is 24.5% of LOC, and our preliminary study of similar systems, e.g. the Airline Booking System and a Storage Management System suggests that savings in the range 4243% may be typical. Taking a simplistic view of project costs, the return on investment would occur after the third such project. This meets the experimental law of domain related

V9-433

2010 International Conference on Computer Application and System Modeling (ICCASM 2010)

reuse. Traditionally, cross domain reuse (also called horizontal reuse)[6] is normally limited to about 20% of the system application. The domain specific reuse (also called vertical reuse) can reduce the total LOC up to 65%, but only within a single application domain (like a traditional Software PL). Our method increases the cross domain reuse achievable by more than twice that previously reported. Improvement is obvious. B. Generic classes reuse measurement The Generic Classes’ frequency of usage is an important standard for reuse assets[12]. The major elements measured are the percentage of LOC and the number of methods which are inherited from the Generic Classes in the final products’ classes. This measurement is halved, counting the volume of reused code and number of times the methods have been called in the products’ classes. Let G(loc) represent LOC of a Generic Class and G(m) represent the number of methods (excluding the abstract methods) in a Generic class. Let N represent the number of product classes which use this generic class, E(loc) represent the LOC of the product classes, and E(m) represent the unique methods in the product classes. (1) For LOC:  Frequency(loc) = G(loc) × N/(G(loc) × N + E(loc)) (4) (2) For methods: Frequency(m) = G(m) × N/(G(m) × N +



E(m))

(5)

For example, the Basic Element Class has 25 lines of code, includes 4 methods and has been inherited by 2 product classes (Item and Seat). So we can count the reuse of this class as 25*2 (two times the code reuse) divided by (the sum of the product classes’ LOC and the Basic Element’s LOC). The super-classes’ code is considered as existing in the sub-classes - it is just hidden. Here the Item class has 5 lines of extra code and two extra methods (the constructor, Item(String id, String name) and getName()) so its total LOC is 25+5=30, and Seat just extends Basic Elements without adding methods, so its total LOC is counted as 25 and no extra methods. Hence, we count the percentage of LOC reuse of the Basic Element class as 25*2/(25+30) = 90.1%, and the percentage of method reuse of the Basic Element class as 4 (number of methods)*2(times of reuse) / (4*2+2(extra methods that are introduced by subclasses)) = 80%. The results show that the Generic Classes have average 86.52% frequency of reuse based on LOC, and 82.73% frequency of reuse based on method counting. Thus the components have high reusability. C. Cost saving reuse measurement To compute the cost saving due to reusing components[6], let C(n), C(r) and C(a) respectively represent the percentage of new code, reusable code and adaptable code (the code needing to be modified before reuse) in a system application. Based on experience, we can consider the cost of developing a line of new code (Cdlnc) as standard cost. The cost of developing a line of code with verbatim reuse averages 0.20 X Cdlnc and

the cost of developing a line of adapted code is on average 0.67 x Cdlnc. Then the total cost of developing a system is calculated based on the reuse distribution (C(n), C(r), C(a)) subject to the constraint: C(n)+C(r)+C(a) = 1. TotalCostofDeveloping = C(n)+0.2×C(r)+0.67×C(a) (6) The results show that, for the Library System the reuse model reduces the total developing cost to 35.68% of developing from scratch. For the Theatre System, the total cost is decreased to 38.2% of development without using the reuse model. The average cost saving is 36.94%. The improvement in productivity is significant. VI. C ONCLUSION Cross domain reuse is a major challenge, as yet not met by current product line approaches. The most difficult issue is finding the essential commonalities between systems and recording these commonalities in a systematic way. Our approach uses the basic domain analysis results, the enterprise models and use cases, with B-method system specifications to make these commonalties visible for developers. The key issue in finding commonality at an appropriate functional level is addressed by the Nature Diagram proposed in this paper. We have shown it is possible to identify valuable commonalities by using role entity and leaf node entity objects. Interesting issues for further investigation include the relationship between the role elements (actor) and the entity elements in a system (which lead to the Nature Diagram) and the “characteristics” of the different nature relationships and their representations. R EFERENCES [1] S. Pavel, J. Noye, and J.-C. Royer, “Dynamic configuration of software product lines in archjava,” in Software Product Lines, 2004, pp. 90–109. [2] A. Helferich, K. Schmid, and G. Herzwurm, “Product management for software product lines: an unsolved problem?” Communications of the ACM Special Issue on Software Product Line Engineering, vol. 49, no. 12, pp. 66–67, 2006. [3] N. Maiden and A. Sutcliffe, “Exploiting resuable specifications through analogy,” Communications of the ACM, vol. 35, no. 4, pp. 55–64, 1992. [4] K. Reed, “Lecture notes: On the recognition of components, re-use and designs based on components: the problem of isomorphisms,” La Trobe University, 2002. [5] H. Zhao, W. Zhang, and Z. Ma, Reuse Oriented Requirements Modeling. Beijing, China: TsingHua University Press, 2008. [6] H. Mili, A. Mili, S. Yacoub, and E. Addy, Reuse-Based Software Engineering: Techniques, Organization, and Controls. New York, USA: John Wiley Sons, 2001. [7] E. Evans, Domain-Driven Design. Boston, USA: Addison-Wesley, 2004. [8] C. Atkinson, Component-Based Product Line Engineering with UML. Harlow, England: Pearson Education, 2002. [9] K. Schmid, “A comprehensive product line scoping approach and its validation.” in Proceedings of the 24th International Conference on Software Engineering. Florida, USA: ACM Press, 2002, pp. 593–603. [10] M. Minsky, The Society of Mind. New York, USA: Simon Schuster, 1988. [11] J.-R. Abrial, The B-book: Assigning Programs to Meanings. Cambridge, England: Cambridge University Press, 1996. [12] Z. C. Qi, Q. P. Tan, and H. Ning, Software Engineering. Beijing, China: Publishing House of High Level Education, 1997.

V9-434