Measuring the Coherence of Software Product Line Architectures

Measuring the Coherence of Software Product Line Architectures Vojislav B. Mišić 1 technical report TR 06/03 Department of Computer Science, University of Manitoba Winnipeg, Manitoba, Canada R3T 2N2 June 2006 1 University of Manitoba, Winnipeg, Manitoba, Canada

Measuring the Coherence of Software Product Line Architectures Vojislav B. Mišić Abstract: One of the promising approaches to software development is the concept of Product Line Architectures, or PLAs: architectural frameworks for developing software applications for a series of related products. Assessment of software PLAs and their measurement is still a largely undeveloped territory, where main emphasis is put on the experience and insight of individual designers, rather than on some more objective measure. We propose the coherence measure as a vehicle to increase the designers understanding of the quality of PLAs, and to give valuable insight into the possible modifications of the PLA in order to increase its conceptual quality. Keywords: software measurement, coherence, software product line architectures Contents 1 Reuse in software development 1 2 Product Line Architectures 2 3 Coherence? Wasn t it called cohesion before? 3 3.1 A formal definition......................................... 4 3.2 Properties of the coherence measure................................ 5 4 Using the coherence measure: a catalog of coherence-based refactorings 6 5 Concluding remarks 9 A Proof of the fourth property of the coherence measure 9

TR 06/03 Measuring the Coherence 1 1 Reuse in software development In the process of software development, the development team must interact intensively with the domain experts, and thus gradually develops an in-depth knowledge and understanding of the problems and issues related to that particular domain. Traditionally, the goal of achieving the required functionality in order to deliver the (functional) product to a known or unknown customer, has always been given first priority. The problems encountered in achieving this goal manifest themselves in several ways: products are not delivered on time, within budget, and with the functionality required. Overcoming these problems has become a primary task for the software development community, both in academia and in industry, and many advances have been made over the years. Unfortunately, the focus on functionality and timeliness of delivery, however necessary and useful it is (or may have been), did not leave much time for taking care of many other product- and process-related requirements. In particular, issues like design evolution and design for reuse did not receive much attention; they were considered only if there was time left never, in most cases. As a consequence, symptoms of software crisis tend to appear every time a software product is developed, despite the apparent domain expertise attained by the software development team. Over the years, a general consensus has materialized, that substantial savings can only be obtained through reuse: using already developed software applications, or parts thereof, when developing new ones. The concept of reuse is certainly not new: after all, most engineering disciplines imply reuse of various artifacts. In software development, artifact reuse should both increase productivity and improve quality of the final product thus bringing benefits from both technical and business perspective. One might even be tempted to say that reuse of software artifacts is an essential prerequisite for software development to become an engineering discipline. Now, software reuse may be, and indeed has been, attempted and implemented at different levels. For example, we may reuse individual subroutines and modules of our own making, as mentioned above, whenever we notice some repetitive task or calculation. We may also reuse subroutines and modules from a loose collection, e.g., module libraries such as SSP, Linpack, and the like. Sometimes we must reuse subroutines and modules from an organized collection, without which the project could not be implemented, such as the Windows API. All of these, however, do not result in any significant savings in time and effort. The only type of reuse that may generate benefits, both technical and economical, is through software components software applications, or building blocks, purposefully built with reuse in mind [13], either in-house or by a third party (COTS). However, this is just one half of the story component-based development cannot be successful if reuse is not planned, designed, and implemented top-down [4, 7]. In fact, effective use of software components requires a software architecture, which may be defined as structure (or structures) of a system, which comprise software components, their externally visible properties, and the relationships and interconnections between them [1]. Architecture is important because it constrains the quality attributes of a system, both development- and operational quality-related ones, it allows for communication between stakeholders, and it may be utilized to define a common reference for a collection of related software products a product family or product line [8]. Such a collection is commonly referred to as a product line architecture, or PLA.

TR 06/03 Measuring the Coherence 2 2 Product Line Architectures Product line architectures are, in fact, frameworks for developing customer-specific applications in a particular domain [8]. For example, all mobile phones or TV sets share some basic set of capabilities, yet each model may have unique features of its own. Note that this approach focuses on developing component-based application families, rather than individual applications. Technically, a product line architecture consists of a number of components. A component may be primitive, or it may contain other components; some components may have variants, while others can be optional. Each component provides some to other components, or to the external world (users and/or other components). Most components also access some from other components and/or external world. What kind of benefits we may expect from such an approach? As before, we do expect better quality and lower development costs. It is generally accepted that the excess effort needed to build software components (which will eventually be reused) makes them about three times as expensive as the components with about the same functionality that were built for a specific system. As for the Product Line Architecture approach, extra cost will not be less than for the individual components (some analyses show that the PLA investment pays off after as few as 4 to 6 systems [14]), but the savings that may be achieved in the long run are more than worth the price. This is why the PLA approach is used by companies like Nokia, Motorola, and HP, among others [1]. Among various technical and managerial challenges related to the design, development, and use of PLA, the issue of PLA assessment is not the least important. It includes the following simple questions: given two alternative PLAs, which one is better and why? and, given a PLA, how we can improve its quality? As always, assessment can be qualitative (description-based), or quantitative (measurement-based) assessment. As always, the latter approach is preferred, whenever possible. Software metrics is what comes to mind first, because software components and architectures are software too, and there exist quite a few software measure that provide concise information facilitate direct comparisons and/or ranking may provide clues on possible improvements. However, traditional software metrics usually focus on things like classes and objects; then, of course, the objects internal structure; and, ultimately, the program code that implements these objects. This orientation makes them mostly inappropriate for measuring software architectures (although, in fact, most of them are inappropriate for measuring software artifacts as well [5]). The assessment of software architectures, and PLAs in particular, should focus on features specific to those architectures and PLAs, such as structure and component interaction, partitioning of functionality, and the way this functionality is ensured. One possible way to do so is based on the measures of service utilization, PSU and RSU, proposed in [4]. The Provided Service Utilization (PSU) of a given component is the number of provided by that component that are actually used by other components in the achitecture, divided by the total number of provided by the component. PSU, in fact, measures how much of the functionality provided by the of a component, is used within the container or PLA. Ideally, a component which has all of its used by other components in the same container component or PLA, will have a value of PSU = 1. The closer PSU is to this maximum value, the more functionality of a component is used within the PLA.

TR 06/03 Measuring the Coherence 3 In an analogous manner, the Required Service Utilization (RSU) of the given component is the number of required by that component that are actually provided by other components in the architecture, divided by the total number of required by the component. In fact, the RSU measures the self-sufficiency of a container component or an entire PLA. In other words, just how much of the given component s needs for is satisfied within the same container component or PLA. Ideally, a component which does not require any service outside those provided by other in the same container component or PLA, will have RSU = 1. Most often, primitive components will have high values of RSU. It should be noted that the concepts underlying the measures of Required Service Utilization and Provided Service Utilization are not altogether new. Measures based on similar concepts have been known for a long time, for example: Fan-in measures number of incoming connections in this case, it would be the number of components that use one or more of the provided by the given component. Fan-out measures the number of outgoing connections in this case, it would be the number of components that provide one of more of the required by the given component. Note, however, that both fan-in and fan-out are structural measures, as they simply count incoming and outgoing (i.e., caller and callee) connections for a given component. On the other hand, RSU and PSU define rate of satisfaction and utilization, i.e., they are functional. Moreover, they take into account the context of use: the same component may have different values of RSU and PSU when used in the context of different PLAs. Both these properties make the measures of RSU and PSU remarkably similar to the concept of coherence [10]. 3 Coherence? Wasn t it called cohesion before? Since the publication of the seminal paper of Stevens et al. [12], the concepts of cohesion and coupling have been consistently taken to be valid indicators of the quality of the system design [11]. A system with lower coupling and higher cohesion is, or should be, of better quality than the one with higher coupling and lower cohesion. Consequently, the design goal is to minimize coupling and maximize cohesion and this goal holds for both traditional structured design paradigm and modern object-oriented approaches. Two contrasting views of cohesion have emerged over time. The majority of researchers have considered cohesion to be just a special case of intramodule coupling. In this approach, cohesion is measured as an internal property, a characteristic and a quantitative description of the structure of a software module. An exhaustive overview of these efforts is given in [2]. Another approach attempts to measure cohesion against the yardstick of the objective, purpose, or function of a software module [15]. As this purpose is to be found outside the module and not within it, cohesion is an external property, rather than an internal one. This approach results in a rather different measure, which has been called coherence, in order to emphasize its external and functional, rather than structural, orientation [10]. The distinction between structural and functional properties, after all, complies well with the principle of separation of concerns, which is one of the cornerstones of the object-oriented paradigm. The new approach examines the usage of an artifact its functionality, instead of its internal structure. Therefore, the new measure could be qualified as teleological, or even customer-centric, rather than the traditional, developer-oriented measures.

TR 06/03 Measuring the Coherence 4 w 1 w 2 w n w i are client components that use (require) some of the provided by c c provides,... s n c Figure 1: PLAs consist of client and server components. level. Coherence can be applied to software designs at different levels [10], including the Product Line Architecture 3.1 A formal definition Before we define coherence in a formal manner, let us define a few concepts first. Let C denote the set of components in a particular PLA. Let c C be one of those components, and let P (c) = {,... } denote the set of provided by the component c. Let W (c) = {w 1, w 2,... } denote the set of components w i C which use/require provided by the component c. In other words, W (c) is the set of clients of c. Finally, let S(c, w) denote the set of provided by c that is actually used by the client w. This is schematically shown in Fig. 1. Then, the coherence of the component c may be defined as: (#S(c, w) 1) ψ(c) = w W (c) (1) (#P (c) 1) w W (c) where #X stands for the number of elements in the sets X. In fact, each of the summands in the denominator is the same, therefore the denominator sum may be simplified, and the coherence is (#S(c, w) 1) w W (c) ψ(c) = (2) #W (c) (#P (c) 1) Note that coherence is the ratio of two positive numbers. A more formal definition applied to generic objects may be found in [10]. The following boundary values can be shown to hold: Coherence attains its lowest value of zero when each client uses/requires only one of the provided by c.

TR 06/03 Measuring the Coherence 5 Coherence attains its maximum value of one when each client uses/requires all of the provided by c. Coherence is undefined when the component c provides a single service only. (In fact, in such cases it would not make much sense to calculate coherence at all.) Thus, the coherence measure is defined on a ratio scale, which renders it fit for algebraic manipulations. (This feature is desirable for any measure [3, 15].) Moreover, the range from zero to one makes a measure quite convenient from a cognitive point of view. In words: number of available that a client uses, averaged over all clients. 3.2 Properties of the coherence measure The coherence measure obviously has two among the most desirable properties for a measure [2]: it is independent of the description language or development paradigm used; and it is easy to automate, since the measure is obtained by simple token counts. More formally, the coherence measure ψ can be shown to satisfy all four properties for a cohesion measure [3], as will be shown in the following. Note that the statements of the properties have been slightly rephrased from their original form, in order to conform to the terminology of architecture-based development. 1. (Nonnegativity and normalization) The value of coherence belongs to the range [0, 1]. This property was informally proven in the previous Subsection. 2. (Null value) The coherence of a component is null if the rest of the system is empty. The rest of the system is empty means that no service of the given components is used by other components; there may be more than one such component in an architecture. In such cases, the sum in the numerator of (2) will have no elements, which results in zero coherence. (Of course, a given component may provide to the user, or to some component outside the PLA itself; but such components should be fairly easy to identify.) 3. (Monotonicity) Adding new uses relationships does not decrease coherence. Adding a new relationship means that one of the clients of c say, w i (c) is altered to use/require a service from the given set, z S(c), which it did not use previously. In that case, one of the elements in the numerator sum the one corresponding to the client w i (c) will increase by 1, while the denominator will stay the same. Consequently, the new value of coherence will be greater than the old one which is exactly the desired property. 4. (Merging of components) The coherence of the component obtained by merging two unrelated components is not greater than the maximum coherence of the original components. Traditionally, unrelated means that the components to be merged are not clients of each other, but with coherence being an external and functional measure, we take it to mean that the components to be merged have no common clients. The proof is somewhat involved, and it is shown in the Appendix. The main consequence of this property is that coherence of unrelated components cannot be improved by simply merging them; however, if we split a component into two others, at least one of them will have higher coherence than the original one. The question, of course, is how to perform the split so that both resulting components have higher coherence. Some situations in which this might be the case will be shown in the next Section.

TR 06/03 Measuring the Coherence 6 C2 C2 uses C2 uses s 4, s 5 uses C2 uses s 4, s 5 Cy (a) If the coherence of a component is low because two clients use two (nearly) distinct sets of its... (b)... perhaps that component can be split into two, each of which will be more coherent than the original one. Figure 2: Use of coherence: example 1. As mentioned before, the coherence of a given component depends on its context of use: a single component could be fully coherent when used in one PLA, and less than fully coherent when used in another one. But such behavior is to be expected from a functional measure anyway [15]: a spoon may be a perfect tool to eat soup, but is not quite appropriate for cutting meat. 4 Using the coherence measure: a catalog of coherence-based refactorings After all the definitions and properties, one might still ask the question: what is it that we really measure? To put it in words: the coherence measures how well the provided by a component help it achieve the common objective of that component. Ideally, each client of a component will use all of the provided by that component. In less than ideal cases, there will be clients that do not use all, or different clients may use disjoint subsets of, or the like. The coherence measure helps pinpoint such cases, so that the architect may examine the client-server relationships in more detail and take appropriate actions. The range of available actions includes the following: modifying the component, be it the server or (in some cases) even the client; re-arranging the of the components into different components the practice commonly referred to as refactoring [6]; finally, doing nothing, because it may be too expensive, or other design objectives dictate such behavior. Either way, the additional scrutiny will most certainly result in better understanding of the architecture, and ultimately lead to quality improvement. A few examples of coherence-based refactoring are given in Figs. 2 to 7. The common thread of all these cases is that an increase in coherence might be obtained by (a) splitting the server components, and/or (b) merging or rearranging the client components. (This is the consequence of Property 4 above.) But the most important point is the fact that coherence may give us an additional insight

TR 06/03 Measuring the Coherence 7 a b b a uses b uses, s 2, s 4 a uses b uses, s 2, s 4 a b (a) If the coherence of a component is low because one variant of a client uses some of the of that component, while the other does not... (b)... perhaps the component itself should be split into two variants, each of which will be more coherent than the original one. Figure 3: Use of coherence: example 2. a b b a uses b uses, s 2, s 4 a, b use b uses service s 4 Cy (a) If the coherence of a component is low because a variant of a client uses some of the component, while the other does not... (b)... perhaps the component should be split into a common and an optional part and each of the two will be more coherent than the original component. Figure 4: Use of coherence: example 3.

TR 06/03 Measuring the Coherence 8 uses from uses s 5, s 6 from Cy also uses s 3, s 4 from Cy uses, s 4 from y Cy s 5, s 6 become internal in y y (a) If a client component uses from two other components, and one of them also uses the of the other... (b)... perhaps the two server components can be merged into a single, more coherent component. Figure 5: Use of coherence: example 4. C2 C3, C2 use C3 uses service s 3 Figure 6: Use of coherence: example 5. If a client uses fewer of a components than its other clients, examine it closely maybe it should be merged with another client. C2 uses C2 uses s 4, s 5 provides, s 2, s 4, s 5, s 6, s 7 Figure 7: Use of coherence: example 6. If the coherence is very low because some are never used, maybe those should not have been provided in the first place therefore, hide them or perhaps even remove them.

TR 06/03 Measuring the Coherence 9 into the structural quality of the PLA. In particular, it can highlight weaknesses in the PLAS structure, and thus facilitate restructuring that will improve this quality and bring benefits in the long term. 5 Concluding remarks Traditionally, measurement and overall assessment of software products focuses on their internal structure, but Product Line Architecture approach requires a different viewpoint. This approach is based on the concept of coherence. The concept is generic enough to enable the coherence measure to be used at various abstraction levels, and in different phases of the development life cycle. In this work we have shown that coherence can be used to improve the structural quality of product line software architectures, or PLAs. Work is under way to integrate the coherence measure with one of the well known Architecture Description Languages (ADLs) [9], and to integrate it into an architecture design tool. Further work is under way to validate the coherence measure in practice, and devise the best way to use the insight it offers to improve the quality of software designs. A Proof of the fourth property of the coherence measure As mentioned above, the fourth property from [3] states that the coherence of the component obtained by merging two unrelated components is not greater than the maximum coherence of the original components. If we denote the components to be merged as c 1 and c 2, their coherence values will be, respectively, (#S(c 1, w) 1) ψ(c 1 ) = ψ(c 2 ) = w W (c 1 ) #W (c 1 ) (#P (c 1 ) 1) (#S(c 2, w) 1) w W (c 2 ) #W (c 2 ) (#P (c 2 ) 1) where, as before, #X stands for the number of elements in the set X. In general, unrelated means that the components to be merged are not clients of each other, which can be written as c 1 W (c 2 ) and c 2 W (c 1 ), respectively. But since coherence is a functional measure, unrelated should be extended to the individual components clients as well, in which case W (c 1 ) W (c 2 ) =. Then, the coherence of the merged component x may be written as (#S(x, w) 1) w W (x) ψ(x) = (5) #W (x) (#P (x) 1) Now, the set of provided by the merged component x and the set of its clients may be obtained as unions of the corresponding sets of and clients of c 1 and c 2, respectively: (3) (4) P (x) = P (c 1 ) P (c 2 ) W (x) = W (c 1 ) W (c 2 ) (6)

TR 06/03 Measuring the Coherence 10 However, the two sets of, as well as the two sets of clients, are disjoint: #P (x) = #P (c 1 ) + #P (c 2 ) #W (x) = #W (c 1 ) + #W (c 2 ) (7) The sum in the numerator of (5) may be split into two sums, each of this corresponds to the clients of one of the original components: N (ψ(x)) = (#S(x, w) 1) + (#S(x, w) 1) (8) w W 1 w W 2 For simplicity, we use the notation N (F ) and D(F ) for the numerator and denominator of the fraction F, respectively. Now, the summands of the numerator sums may be simplified to: N (ψ(x)) = (#S(c 1, w) 1) + (#S(c 2, w) 1) (9) w W 1 w W 2 The denominator may be simplified as well, using equalities from (7): D(ψ(x)) = #W (x) (#P (x) 1) = (#W (c 1 ) + #W (c 2 )) (#P (c 1 ) + #P (c 2 ) 1) (10) After some simple algebraic manipulation, the coherence of the merged component may be written as ψ(x) = N (ψ(c 2)) D(ψ(c 2 )) 1 + N (ψ(c 1)) N (ψ(c 2 )) 1 + D(ψ(c 1)) D(ψ(c 2 )) + (#W 1)(#P (c 2 )) + (#W 2 )(#P (c 1 )) D(ψ(c 2 )) (11) We may arbitrarily assume that the component c 2 has higher coherence, ψ(c 1 ) ψ(c 2 ), which means that N (ψ(c 1 )) D(ψ(c 1 )) N (ψ(c 2)) D(ψ(c 2 )) (12) Since coherence is a ratio of two positive numbers, the last expression may be written as N (ψ(c 1 )) N (ψ(c 2 )) D(ψ(c 1)) D(ψ(c 2 )) (13)

TR 06/03 Measuring the Coherence 11 Now, the coherence becomes ψ(x) = N (ψ(c 2)) D(ψ(c 2 )) 1 + N (ψ(c 1)) N (ψ(c 2 )) 1 + D(ψ(c 1)) D(ψ(c 2 )) + (#W 1)(#P (c 2 )) + (#W 2 )(#P (c 1 )) D(ψ(c 2 )) (14) Since the member counts of sets W (c 1 ), W (c 2 ), P (c 1 ), and P (c 2 ) are non-zero, the second fraction may be simplified, so that the overall expression becomes ψ(x) N (ψ(c 1 + N (ψ(c 1)) 2)) D(ψ(c 2 )) N (ψ(c 2 )) 1 + D(ψ(c 1)) D(ψ(c 2 )) (15) Using (13), it follows that ψ(x) N (ψ(c 1 + D(ψ(c 1)) 2)) D(ψ(c 2 )) D(ψ(c 2 )) 1 + D(ψ(c 1)) D(ψ(c 2 )) N (ψ(c 2)) D(ψ(c 2 )) (16) which concludes the proof.

TR 06/03 Measuring the Coherence 12 References [1] L. Bass, P. Clements, and R. Kazman. Software Architecture in Practice. The SEI Series in Software Engineering. Addison-Wesley, Reading, MA, 1998. [2] L. C. Briand, J. W. Daly, and J. Wüst. A unified framework for cohesion measurement in object-oriented systems. Empirical Software Engineering, 3:65 117, 1998. [3] L. C. Briand, S. Morasca, and V. R. Basili. Property-based software engineering measurement. IEEE Transactions on Software Engineering, 22(1):68 86, Jan. 1996. [4] E. Dincel, N. Medvidovic, and A. van der Hoek. Measuring product line architectures. In 4th International Workshop on Software Product-Family Engineering PFE 2001, volume 2290 of LNCS, pages 346 352. Berlin, Germany: Springer-Verlag, 2001. [5] N. E. Fenton and S. L. Pfleeger. Software Metrics: a Rigorous and Practical Approach. PWS Publishing Company, London, 2nd edition, 1996. [6] M. Fowler. Refactoring: improving the design of existing code. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 1999. [7] D. Garlan, R. Allen, and J. Ockerbloom. Architectural mismatch: why reuse is so hard. IEEE Software, 12(6):17 26, Nov. 1995. [8] M. Jazayeri, A. Ran, and F. van der Linden. Software Architecture for Product Families. Addison-Wesley, Boston, MA, 2000. [9] N. Medvidovic and R. N. Taylor. A classification and comparison framework for software architecture description languages. IEEE Transactions on Software Engineering, 26(1):70 93, Jan. 2000. [10] V. B. Mišić. Cohesion is structural, coherence is functional: Different views, different measures. In 7th International Software Metrics Symposium, page35 144, London, England, Apr. 2001. [11] M. Page-Jones. The Practical Guide to Structured Systems Design. Yourdon Press, Englewood Cliffs, NJ, second edition, 1988. [12] W. P. Stevens, G. J. Myers, and L. L. Constantine. Structured design. IBM Systems Journal, 13(2):115 139, 1974. [13] C. Szyperski. Component Software: Beyond Object-Oriented Programming. Addison-Wesley, Harlow, UK, 1998. [14] D. M. Weiss and C. T. R. Lai. Software Product-Line Engineering A Family-Based Software Development Process. Addison-Wesley, Reading, MA, 1999. [15] S. A. Whitmire. Object-Oriented Design Measurement. John Wiley and Sons, New York, NY, 1997.