Providing Quality Measurement for Aspect-Oriented Software ...

Providing Quality Measurement for Aspect-Oriented Software Development M. Kassab, O. Ormandjieva, C. Constantinides Department of Computer Science and Software Engineering Concordia University 1455 de Maisonneuve Blvd West Montreal, Quebec, H3G 1M8, CANADA {moh_kass, ormandj, cc}@cse.concordia.ca Abstract Adopting aspect-oriented technologies for software development requires revisiting the entire traditional software lifecycle in order to identify and represent occurrences of crosscutting during software requirements engineering and design, and to determine how concerns are composed. In this work, we propose sets of quality measurements to be associated with the activities of aspect-oriented software development (AOSD). The intended goal of the measurements is to assist stakeholders with quantitative evidences to better map or iterate system modules at different activities in the development process and to better set the design decisions for the analyzed requirements.

1. Introduction A conflict tends to rise when we map an ndimensional requirements space to a single dimensional design and implementation space while building development artifacts. This conflict constitutes the source of crosscutting which imposes two symptoms on implementation: (1) code tangling and (2) code scattering. In object-oriented development crosscutting does not allow the benefits of object-oriented programming (OOP) to be fully utilized. Developers are thus faced with a number of implications including poor traceability of requirements, strong coupling between functional components, low cohesion of modules, low degree of code reusability, and low productivity. As a consequence to the above, the quality of software is negatively affected.

Aspect-Oriented Programming (AOP) is a term that refers to a growing family of approaches and technologies that provide solutions to separate and implement crosscutting concerns by providing a second axis of decomposition that enables separation of core functionality from crosscutting requirements. In [3], we discussed an AOSD model that constitutes of a sequence of systematic activities towards an early consideration of identifying, specifying and separating crosscutting functional requirements (FRs) and nonfunctional requirements (NFRs) starting from the requirements elicitation. Throughout the development process, stakeholders are in need to verify that they managed capturing and specifying all related crosscutting requirements properly. To achieve this target, we choose to extend our AOSD model in this paper by proposing sets of quality measurements at different breakpoints during development. These measurements will assist stakeholders to better map or iterate the requirements of the system by providing them with quantitative evidences as a feedback on the following: 1. The existence of crosscutting requirements those are yet to be captured. 2. Decisions to be taken when setting the design strategies for the analyzed requirements. The rest of this paper is organized as follows: Section 2 presents an overview of the AOSD model proposed in [3] and its quality measurement extension. In Section 3 we present our sets of measurements for crosscutting requirements. The related work is reviewed in Section 4. Finally, we will conclude our work in Section 5.

1

2. AOSD framework An effective software development approach must harmonize the need to build the functional behavior of a system with the need to clearly model the associated NFRs that affects part of the system or the system as a whole. This work builds on the proposed aspectoriented framework in [3] while focusing and treating exclusively the subject matter of quality measurements. The extended aspect-oriented model is illustrated in Figure 1. The model categorizes the activities into five main sets (phases): requirements elicitation, analysis, composing requirements, design modeling and implementation. In spite of the modeled sequence of activities, we emphasize the iterative and incremental nature that should accompany the development process. The proposed sets of measurements are as follows: 1. Requirements analysis measurements: A set of measurements applied on the specified requirements to help realizing early crosscutting implications in the system. 2. Interaction Points measurements: A set of measurements inducted to optimize the activity of composing requirements and to help setting better design and project management strategies. 3. Design and Implementation measurements: A set of measurements inducted at the end of the design activity and/or the end of the implementation to obtain quantitative evidence on the degree at which the crosscutting requirements been separated and thus to determine whether a further iteration would be required to generate a better modularized version of the system.

3. Crosscutting measurements In this section we will present and discuss the sets of measurements that extend the AOSD model.

3.1. Requirements analysis measurements Analysis modeling is the formal presentation of the specification, through which the knowledge and information included in the textual description of the requirements are transmitted to the elements of the object-oriented analysis models. In the AOSD model, the analysis model consists of a use-case model, system sequence diagram (SSD) (dynamic view on the system under development) and a domain model (static view). We see the set of use-cases in the resulting use-case model as a set of abstractions of the usages in the do-

main model reflecting the properties of the domain object they are to represent. One way to determine the quality of the software usage partitioning into usecases is to look at how the activities between use-cases are related to one another. This is the criterion of lack of modularity in the use-case model.

Requirements Elicitation

Identifying Functional Requirements

Identifying and Specifying Nonfunctional

Specifying Functional Requirements

Requirements Analysis Measurements

Analysis and Crosscuttings Realization

Composing Requirements Identifying Interaction Points

Defining Conflicts

Interaction Points Measurements

Design

Resolving Conflicts

Integration

Implementation

Design and Implementation Measurements

Figure 1. Extended AOSD model. Another important way to evaluate the partitioning of the analysis model is by how the real-world concepts are related and depends on each other in the domain model. That is the criterion of coupling. Modularity in the use-case model and coupling in the domain model are both ways of measuring the quality of partitioning in the analysis model. Associating the analysis with these measurements leads to early feedback on the realization of the crosscuttings within the system and thus an early possible treatment. The requirements analysis measurements and their validation are described in [5] and briefly introduced below. 3.1.1. Modularity in Use Case Model (M_UCM). We consider a use-case to be a set of scenarios describing instances of the usage of the system. Each scenario shows the real-world concepts (including the system) and the events interchanged between them, ordered in time sequence. We map the scenarios to sequences of events. We define the grammar for a sequence of events as follows:

2

sequence_of_events::= [actor’s event , [sequence_of_events]*, system’s event] Let two different use-cases UA and UB are defined by the sets of scenarios A and B respectively where each scenario is a sequence of events. We say that A and B operate on a common sequence of events σ when σ∈(A ∩ B), where (A ∩ B)≠ ∅. Intuitively, the existence of similar events within scenarios of different use-cases indicates a low modularity, i.e., low level of partitioning quality. The modularity in the Use Case Model (M_UCM) measure is defined on the set of all scenarios belonging to all use-cases in the use-case model: M_UCM = 1-|QM|/|PM| where QM is the set of the pairs of scenarios sharing at least one common event. (The order is not important to avoid duplication), and PM is the set of all pairs of scenarios (same condition apply). The range of the values for the measure M_UCM is [0..1], where 1 indicates the highest level of modularity and 0 indicates the lowest level of modularity. Lower M_UCM values indicate that possible cross cuttings are to be identified. To increase the value of M_UCM we suggest factoring out the behavior corresponding to a common event into a new separate use-case Uc that will crosscut the other two use-cases. Uc is most likely to be mapped to an aspect in later stages of the development. 3.1.2. Coupling in the domain model. In the analysis activity, we target the coupling in the domain model. We have adopted the MOOD Object-Oriented Software Metrics [4] Coupling Factor to quantify the existing level of coupling in the domain model due to associations between the concepts. Coupling Factor (CF) is a measurement for the level of coupling in the domain model diagram excluding coupling due to inheritance, and it is defined as follows: CF = ∑TCi=1 [∑TCj=1 is_client(Ci, Cj)] (TC2 – TC) where TC is the total number of classes and is_client (Cc, Cs) =

1 iff Cc=> Cs 0 otherwise

^ Cc ≠ Cs

and Cc => Cs represents the relationship between a client class and a supplier class Cs . The range of the values for the CF is [0..1] where 0 indicates lack of coupling , and 1 is corresponding to the highest possible level of coupling. As a higher value of CF would indicate higher level of coupling between the concepts in the domain, this value may be considered as an implication of crosscutting requirement(s) to be realized.

3.2. Interaction Points measurements Interaction Points are the identified requirements in the system where other requirements may crosscut. In this section we propose set of measurements to obtain a quantitative analysis of the characteristics of Interaction Points such as size, cohesiveness, local conflict, interdependency, independency and complexity. These measurements intend to assist the effort required for the composition of the requirements, and to provide a solid ground for making decisions and setting priorities while mapping candidate elements into the next activities of the development. 3.2.1. Define Interaction Points. We start by defining the set of requirements R = {FR} ∪ {NFR}, and the set of crosscuttings C = {Crosscutting requirements (CCRs)} ⊆ R. We define a function A which maps R to sets of CCRs as A: R→Ρ(C), where P states for “Powerset”. A tracks those requirements that transverse several other requirements captured by this level of the development cycle. Let r ∈R, c ⊆ C. We define A as: A(r) = ∅, if there are no crosscutting requirements at r, and A(r) = c, otherwise. The set of Interaction Points I is defined as: I = R – {r | A (r) =∅}. We can illustrate the mapping of each element in I to a list of CCRs (Table 1), which is provided by function A. Table 1 is a template that is built based on the (RxR) set and we use it to show the mapping of each element in the set I through the function A. Table 1. Interaction Points in the system r2 … rn r1 r1 … √ r2 √ … … … rn √ … 3.2.2. Defining conflicts. Hardly any requirements manifest in isolation, and normally the provision of one

3

crosscutting requirement may affect the level of provision of another. We refer to this mutual dependency as non-orthogonality. The dependency can be collaborative (positive) or damage (negative). We define a function B for mapping of pairs of CCRs to values “+”, “-”, “ ” or “?”: B : C×C → {“+”,“-”,“ ”,“?”}. The rules for assigning the signs to the pairs of CCRs are as follows: 1.

2.

3.

4.

5.

The value “-” is assigned to a pair of CCRs originating from the set of NFRs that contribute negatively at the same Interaction Point. The assignment is based on the expert’s judgment of the developers. The value “+” is assigned to a pair of CCRs originating from the set of NFRs that contribute positively if they meet at the same Interaction Point. The assignment is based on the expert’s judgment of the developers. The value “ ” is assigned to a pair of CCRs originating from the set of NFRs that do not interact. The assignment is based on the expert’s judgment of the developers. The “?” value would indicate a lack of information on the contribution; this might be updated in later phase of the software development life-cycle, or a subsequent iteration. We assign “ ” to all pairs of CCRs where at least one CCR originates from the set of FRs. The rational is that NFRs are usually constraints on FRs, they do depend on each other, but the nature of this dependency cannot be positive or negative.

We use Table 2 as a matrix presentation of the function B. The matrix is symmetric. Table 2. Candidate aspects contribution matrix CCR 1 CCR 2 … CCR n CCR 1 CCR 2 + … CCR n + 3.2.3. Relative Size. The relative size of the Interaction Point is a measurement for how many crosscuttings affect a given Interaction Point Pi ∈ I in relative to other Interaction Points defined in the system (set I): Relative_Size (Pi) = A(Pi ) / ∑nk=1 A(Pk )

where n is the cardinality of the set I. The relative size is a non-negative value in the interval [0..1] interpreted as a relative weight of a given Interaction Point. 3.2.4. Local conflict. The effort required for the integration process would highly depend on the level of interdependency between the crosscutting requirements, and more specifically on the defined conflicts at Table 2. We propose to use the local conflict measure which reports the level of conflict LLC (Local Level of Conflict) for each Interaction Point Pi∈I based on the list of crosscutting requirements A(Pi). LLC(Pi)={(CCRk,CCRl)•CCRk,CCRl∈A(Pi)∧B(CCR, CCRl)=”-“}/ n Where n is the cardinality of the set of all pairs of CCRs in A(Pi ) (the order is ignored to avoid duplications). 3.2.5. Interdependency. Similar to LLC, we propose to track the level of interdependency LLI (Local Level of Interdependency) for each Interaction Point Pi∈I based on the list of cross cutting requirements A(Pi): LLI(Pi)={(CCRk,CCRl)•CCRk,CCRl∈A(Pi)∧B(CCRk, CCRl )=”+“}/ n Where n is the cardinality of the set of all pairs of CCRs in A(Pi ) (the order is ignored to avoid duplications). 3.2.6. Independency. We use this term to indicate to which level crosscutting requirements are independent from each other at a certain Interaction Point. So for each Interaction Point Pi ∈ I based on the list of crosscutting requirements A(Pi), we define Local Level of Independency LLInd (Pi) = 1-LLC-LLI 3.2.7. Complexity Profile of the Interaction Points. At this level of abstraction, we propose that source of complexity at an arbitrary Interaction Point rises up from negative contribution among requirements. We relate complexity of an arbitrary Interaction Point to other Interaction Points’ complexities in the system using the following formula: Complexity(Pi)= {(CCRk,CCRl)•CCRk,CCRl∈A(Pi) ∧ B(CCRk,CCRl)= ”-“} / ∑nj=1{ (CCRk,CCRl)•CCRq,CCRr∈A(Pj) ∧ B(CCRq,CCRr) = ”-“}

4

Table 3. Requirements tracing among components and operations

where n is the cardinality of the set I. The figures obtained at this level from the above proposed measurements are supposed to direct the effort towards a better design strategies and decisions. For example, an Interaction Point with a high complexity or a relative size value requires more effort to configure and design; consequently, a more brains, time, and money are to be dedicated.

r1

3.3.1. Separation of requirements. Separation of requirements metrics measure the degree to which a single requirement in the system maps to the design components (classes and aspects) and to the operations defined within the methods and the advices. We define the separation of requirements in terms of: 1. Requirement scattering over classes and aspects (RSCA): counts the number of classes and aspects from Table 3 whose main purpose is to contribute to the implementation of the requirement. 2. Requirements scattering over methods and advices (RSMA): counts the number of class methods and aspect advices and methods from Table 3 whose main purpose is to contribute to the implementation of the requirement. High RSCA and/or RSMA values for a specific requirement signals a low modularity and thus a high probability of an existence of crosscuttings to be captured. 3.3.2. Component Lack of cohesion. We use an inverse measure of cohesion, lack of cohesion, to measure how much the responsibilities are tangled within a certain component (class/aspect) or operation (method / advice).

…

r n

..

..

..

Classes …..

…..

Class i

Method1

…

√

…

Method(Number

of methods

√

in class i )

3.3. Design and Implementation Measurements Within object-oriented software development, the design phase takes place when the functionality of the set of entities defined in the domain model is modeled as a set of interacting software classes with a clearly defined properties and behavior. In AOSD, the design phase extends this transformation to map candidate aspects defined in earlier stages to a 1) design decision, 2) defined function or 3) a real aspect. In this section, we define set of measurements for separation of requirements, cohesion and coupling for the system. These measurements are applicable to both phases: design and implementation. We use a template (See Table 3) to clarify the relations.

r2

…..

…..

…

..

..

..

……

……

…

…

…

…

Aspect k

Advice1

Aspects √

…… Advice(Number of advices in

√

aspect k)

Method1

√

….. Method(Number of methods in

√

aspect k)

…..

…..

…

..

..

..

1.

Lack of cohesion in component (LOCC): counts the number of requirements from table 3 that are implemented within certain class or aspect. 2. Lack of cohesion in operation (LOCO): counts the number of requirements from table 3 that are implemented within certain operation. Higher LOCC and/or LOCO values indicate low of cohesion for a certain component or operation due to the low level of modularity. A further iteration is required to achieve a better separation of requirements. 3.3.3. Coupling. We propose to apply the same coupling measurement we used in the analysis level on both classes and aspects separately. According to this, we define CFclasses, CFaspects. As in the analysis phase, high values for CF could be an implication of a bad design separating the contributed requirements.

4. Related work Current AOSD models aim at drawing an abstract pathway that concentrates on a general purpose modeling procedure within a certain domain, or to support particular NFRs in the system (e.g., performance or security [1, 2]). In addition, these approaches do not fully support a smooth transition among the requirements, analysis and the design phases.

5

In [12], the composition of the concerns is defined as the last step of a proposed model for separation of concerns at requirements engineering using the formal method LOTOS. Resolving conflicts among concerns is recommended through negotiation with stakeholders. Having an empirical values inducted out of using our proposed Interaction Points measurements will definitely lead to a better negotiation process. In [6], the authors suggested a framework to specify and separate concerns from requirements to design. There was no discussion on how to identify aspects in activities other than requirements elicitation. Using our proposed design measurements will assist in realizing the existence of crosscuttings at the design level. There is little work discussed in the literature on measurement in AOSD or AOP. The first set of objectoriented measures have been introduced in [11]; their AOP counterparts are reported in [10]. Both are applicable at a class level from the design phase. In [7, 8, 9] the authors introduce a set of measures for aspectoriented code complexity based on program dependency analysis. Our work differs considerably from the existing ones. Our main goal is to target the quality of AOSD artifacts and to assist the process of identifying and modeling crosscutting concerns right from the requirements analysis phase. To our best knowledge, aspect-oriented measurements applicable in the early phases of the AOSD developement did not exist prior to our work.

5. Conclusion Tangling and scattering are symptoms that do not exclusively affect implementation, but they also propagate up to early stages of the development process. Identifying and modeling crosscuttings earlier has a great impact on improving the general quality of the system and reducing complexity by (1) prompting understandability and reusability, (2) enhancing defects detection and their removal and (3) reducing development time. In this paper, we built on [3] by introducing different sets of measurements based on the notion of crosscutting concerns to assist the identification and modeling of the early crosscutting implications in the system. This paper aims at laying the foundation for further work in reasoning about formalizing the composition in the AOSD model. The main goals of these rules are: 1. To eliminate the gap created out of using different specifications while modeling FRs and NFRs.

2.

To establish formal way to identify conflicts among aspects at certain join point. The main target will not be limited to direct conflicts only but will include the indirect conflicts as well. 3. To establish formal methodology to resolve the conflict with minimal contribution from stakeholders. 4. To help establish formal one-to-one mapping with the matching components at later stages of the development. Applying our sets of measurements in a general context of AOSD is a subject for a future research as well.

References [1] E. Franz and C. Pohl, ”Towards a unified treatment of security and other non-functional properties”, Proc. Workshop on AOSD Technology for Application-Level Security (AOSDSEC'04), Lancaster, UK, 2004. [2] V. Shah and F. Hill, ”An aspect-oriented security framework: Lessons learned”, Proc. Workshop on AOSD Technology for Application-Level Security (AOSDSEC'04), Lancaster, UK, 2004. [3] M. Kassab, C. Constantinides, and O. Ormandjieva, “Specifying and separating concerns from requirements to design: a case study”, Proc. the IASTED International Conference on Software Engineering (ACIT-SE 2005), Novosibirsk, Russia, 2005. [4] F. Brito e Abreu, “The MOOD Metrics Set”, Proc. ECOOP’95 Workshop on Metrics, 1995. [5] O. Ormandjieva, M. Kassab, and C. Constantinides, “Measurement of Cohesion and Coupling in the Analysis Model Based on Crosscutting Concerns”, Proc. the 15th International Workshop on Software Measurement (IWSM 2005), Montreal, 2005. [6] A. Rashid, A. Moreira, and J. Araujo, “Modularization and composition of aspectual requirements”, Proc. 2nd International Conference on Aspect-Oriented Software Development, Boston, MA, 2003, pp. 11-20. [7] J. Zhao, “Towards A Metrics Suite for Aspect-Oriented Software”, Technical Report SE-136-25, Information Processing Society of Japan (IPSJ), March 2002. [8] J. Zhao, and B. Xu, “Measuring Aspect Cohesion”, In Proc. Of Fundamental Approaches to Software Engineering: 7th International Conference (FASE 2004), pp.54-68.

6

[9] J. Zhao, “Coupling Measurement in Aspect-Oriented Systems”, Technical Report SE-142-6, Information Processing Society of Japan (IPSJ), June 2003. [10] C. Sant’Anna, A. Garcia, A. Fabricio, C. Chavez, V.F. Garcia, C. Lucena, and V. Staa, “On the Reuse and Maintenance of Aspect-Oriented Software: An Assessment Framework”, Simposio Brasilieiro de Engenharia de Software, 2003, pp. 19-34, Manaus. [11] S. Chidamber, and C. Kemerer, “A Metrics Suite for Object-Oriented Design”, In IEEE Transactions on Software Engineering, 20(6), pp. 476-493, 1994. [12] I. Brito, and A. Moreira, “Integrating the NFR framework in a RE model”, Proc. Workshop on Early Aspects in conjunction with 3rd International Conference on AspectOriented Software Development, Lancaster, UK, 2004.

7