Chapter 2: LITERATURE REVIEW

Transcription

1 Chapter 2: LITERATURE REVIEW 2.1 Introduction Earlier the programs were developed using low level languages which used to consume lot of time in processing a single instruction set. Then the approach shifted towards high level languages such as procedural and object based. In this chapter such techniques have been reviewed. Basically the survey has been presented based upon two aspects i.e. UML for Aspect Oriented Systems and Testability. Research based upon fuzzy logic has also been studied and presented in this chapter UML for Aspect Oriented Systems (AOS) Unified Modeling Language (UML) profile is necessary to design Object Oriented applications and it is required to extend it to Aspect Oriented Systems. UML is capable of expressing core components and aspect components as well as the associations between them. In UML profile each notion is identified, clarified, presented and associated to a discipline. The following section discussed the surveys related to AOSD UML. Pawlak, R., Duchien, L. et al. (2002) have proposed various graphical notations for designing Aspect Oriented Systems (AOS). These notations can be used for distributed environment of aspect oriented application. Three concepts of UML has been explained i.e. groups, pointcut relations and aspect class notations which are useful for programming. Groups have two properties; they represent set of objects that are not instances of the same class or upper-class. Through these properties the aspect designer explained that the set of heterogeneous objects belong to the same system i.e. semantics. Secondly, a group may be composed of members that are localized on different hosts. An aspect class has been represented like a regular class, except that it can contain methods that have particular semantics. One of the methods for extending aspect semantics is by using any one of the stereotypes i.e. before, after, around, replace and role. As these methods are not invoked directly so the arguments passed to the aspect methods are contextual arguments. Pointcut relations allow the designer to link some aspect methods to some points of the base class. The association between aspect class and base class is stereotype with <<pointcut>>. The above notations are explained by taking example for modeling real life aspects, thus providing full aspect oriented model of the JAC framework for future software development. 11

2 Stein, D., Hanenberg, S., et al. (2002) proposed a UML extension to the existing UML for Aspect Oriented Programming. Aspect oriented design model (AODM) is transformed into an ordinary UML design model. AODM basically explained how to design crosscutting in AOSD. Until this paper no feasible modeling language has been available that supports the design of aspect oriented concepts. AODM is a design model that extends the UML. AODM further provided AspectJ s weaving mechanism in the UML. Various weaving instructions explained which model elements in a base design model are to be crosscut. In AODM, aspects are represented as UML classes of a special stereotype. These classes of stereotypes may link in association dependency and generalization relationships just like standard UML classes. Structural crosscutting is specified by means of collaboration templates where collaboration describes a projection of a design model. It specifies instances and relationships with their members and set of interactions that describe their behavior. Behavioral crosscutting is visualized by highlighting message in UML interaction diagrams. It takes place at the link that is used to send message. Weaving instruction explains which class in a base hierarchy is to be crosscut. Behavioral crosscutting weaving instructions specify which link in base class collaboration is to be crosscut. Weaving instructions define the pointcut in the dynamic execution of a program, where the operation of <<advice >> is to be run. AODM provides a special pointcut concept but does not provide weaving instruction for structured crosscutting. UML of AOSD complications could be resolved by executing the design of structural crosscutting form the model representing the aspect. UML profile for AOSD provides a complete set of model elements that represents the concept of the system based on aspect oriented system. The concerns having low coupling in different dimensions can be easily modeled. Aspect Oriented Technology tries to modularize these scattered implementations in order to avoid tangling of codes. Aldawud, O., Elrad, T., et al. (2003) provided a UML extension for AO system. UML provides the facility by which one can extend its make model to fulfill the needs of a modeling concern. The extension mechanism allows customized UML model elements. UML profile for AOSD will give guidelines for applying standard UML to the graphical notation for AOSD to represent ASPECT profile as shown in figure

3 Figure 2.1 An Aspect Profile Extension mechanism is based on the concept of stereotype. Aspect behavior is expressed through employing state charts artifacts. The UML behavioral package is composed of collaboration, use case, state machine and activity graphs package. The behavior of an aspect in AspectJ is determined by pointer s advice and the code. AOP based UML profile tries to reduce the gap between OO and AO design troop. Junior, J., Camargo, V., V., et al. (2009) explained the design tool i.e. Aspect Oriented UML (AO-UML). It used to capture and manage early aspect using the aspect oriented component engineering methodology. This tool can be used throughout the development life cycle. It integrates various AOCE techniques that are needed to provide an integrated development environment. AOCE supports the identification explanation about the component s functional and non functional requirements. By using AOCE components will be automatically indexed by their early aspects. AO-UML tool includes a component-based system s functional requirement designs and component specification. The architecture of AO-UML consists of three main parts i.e. graphical user interface, repository and implementation factory. It provides different visual symbols for different parts. Although various AO-UML notations were described and explained by taking example of banking system, but still there is a problem of navigation for aspects and classes. User has to manually search through the diagrams to find related components. One has to identify his own aspect and design components manually in the tool which is more time consuming. Suzuki, J. and Yamamoto, Y. (1999) described how the aspect supports in the design level. Extended UML has been proposed to support design of aspects properly. It is 13

4 an extension of existing UML specification and an XML-based aspect description language. It also provided the aspect model information to develop tools. It captured aspect in the design level and expressed them in the XML format. Once the module has been encoded with XML, the aspect information can be reused for a wide range of different development tools with different strengths. A UXF/a (UML exchange format), an interchanging an aspect design model was also introduced. It stated how the semantics should be described explicitly and transferred precisely. UXF/a, an extension of UXF, is the format to describe UML model to capture aspect information. UML metamodel has been used to support aspects by adding new elements for the aspect and woven class. Some existing elements were reused for aspect-class relationship i.e. (Association, Generalization and dependency). The stereotype <<woven class>> was also introduced to represent a woven class as shown in figure 2.2. Figure 2.2 A woven class Herrero, J. L., Sanchez, F., et al (2000) defined the basic function of objects and their implementation. Their functional and non functional properties have been designed independently using the basic modeling mechanism provided by UML Base class and stereotyped classes by relating an association relationship. This association relationship has again been represented by a special stereotype which provided an additional metaproperty that specified a mapping of base class to the stereotyped class. Each class of stereotype <<syn>> has been associated with one state chart diagram of stereotype <<synchronization state chart Diagram>> as shown in figure

5 Figure 2.3 Mapping The mapping expression could behave like point cut declaration which specifies the operations that are to be crosscut by the aspect and the points in dynamic execution of base class at which the aspect is to be attached. Especially the author focused on specification of crosscutting behavior in separate entities which may be related to other entities. It also specified the points in dynamic execution of base class at which the aspect is to be attached. But the approach of author was not satisfactory for the design of aspect oriented systems especially for AspectJ. Clarket, S., and Walker, R. J. (2001) proposed a new design concept, i.e. composition patterns to model requirements that have crosscutting impacts on multiple classes. It described how composition patterns can be mapped onto program of AspectJ. Composition patterns are UML templates for designing subjects that expect classes and operations as template parameters and encapsulated all model elements related to a crosscutting requirement in it. A composition pattern may consist of more than one classes and each pattern class may contain multiple template operations. Pattern classes have been used to model structural crosscutting such as attributes and operations that are to be merged to actual base classes and template operations have been used to design behavioral crosscutting. Template parameter has been represented by sharp brackets to avoid mixing of pattern classes with simple operations as shown in figure

6 Figure 2.4 A sample composition pattern Bind composition relationship is proposed by bind attachment which shows the actual elements that replace the composition patterns. Composition relationships are used to relate more than one element that needs to be combined. Figure 2.5 shows how bind attachment bound the composition pattern with actual design subject. Figure 2.5 Bind attachment Pattern merge is an integration strategy that is applied on composition relationship with bind attachment adopts most characteristics of the merger integration strategy. These 16

7 are the integration of non-template properties of pattern classes like there attributes, their association and their dependencies relationship. In the collaborations, UML designer may refer to crosscut input operations and woven output is generated after binding the composition pattern to the actual subject with the composition relationship shown in figure 2.5. Clarke explained that composition patterns constitute a design model that is independent from any particular model. Authors purposed a mapping mechanism which can be used to map composition pattern, concepts to concepts in Aspect J. Still there are some problems like composition patterns did not appropriately represent advice as distinct feature of aspect. Interaction diagrams are not properly delineating the scope in which the advice is executed. AspectJ may contain simple java attribute and operations composition patterns, being stereotyped. With the help of composition patterns only static crosscutting can be designed but dynamic crosscutting is not possible to design. A new design model has to be developed that is suitable for AspectJ. Stein, D., and Hanenberg, S., (2002) provided a notation for all language constructs in AspectJ and specified a UML implementation of AspectJ weaving mechanism. An extension to existing UML concept using UML s standard extension mechanisms was proposed. This approach also reproduced AspectJ s weaving process in the UML and extended UML mechanism to provide standard means to existing UML with new properties called tagged values. These new blocks were called stereotypes having the same structure as the basic block from which they are derived. Stereotypes might be used to indicate a difference in meaning with identical structure. Links could be used as one model element which represents joinpoints in UML diagram. Links represented main points in dynamic execution of a joinpoint in AspectJ. Joinpoints might be visualized by highlighting message in UML interaction diagrams. These interaction diagrams had generally been used to represent communication between instances. This denoted stereotype for pointcut as <<point cut>>. Advice was also represented as an operation of a stereotype named <<advice>> and was also semantically comparable to a standard UML operation as it had dynamic features that affect behavior. An aspect is a defined class of special stereotype i.e. <<aspect>>. The AODM implemented weaving mechanism for advice with the help of collaboration composition of collaborations that could be done by indentifying and matching instances. In a UML diagram, the weaving order could be represented by AODM which refine the use case describing the base class operations. Multiple collaborations might be needed for weaving introduction. Basically there are three instances i.e. before, around & after. The AODM introduced a new relationship to 17

8 the UML to signify the crosscutting effects of aspects on their base classes. In this paper authors provided a suitable notation for all components of an aspect and extended these notations from existing UML. In AODM, the relationship and weaving process provide the developer to assess the crosscutting effects of aspect at design level. A theoretical idea for extension of UML has been proposed but still there is a need to develop tool for AODM. Asteasuain, F., Contreras, B., et al. (2004) presented different approaches to include aspect during the design phase and proposed some extension to the existing UML for aspect. In this extension, the collaboration diagram might be used to model the dynamic structure of the system. UML diagram has been used to show the structure and interactions modeling of the aspect oriented system. The diagram of the system has been shown by an object that interchange message with other objects and classes. Two ways have been proposed to extend UML. One was general extension in UML with whom it would be possible to construct good and simple models with required abstraction. The main disadvantage of this model was to be very general and chances to lose some concepts of aspect during modeling. The second model provided a higher level of abstraction. The main disadvantage of this model was that it would not support reusability of product. In this paper the authors recommended to use model which was suitable for application requirement. These models were then compared on the basic of traceability, user friendly etc. On the basis of these comparisons, the author suggested that if the system is simple and has a controllable number of aspects, then Specific Extension to UML (SEU) is effective. In this paper authors concluded that it was easy to represent aspect semantics but the way to express them is not up to the satisfaction level. Again this is theoretical concept and there is a need to develop an automated tool. The unified Modeling language (UML) is a graphic language notation widely used as a standard to support the subject oriented and component based software development process as described by Aldawud, O., Elrad, T., et al. (2001). UML is a standard modeling language endorsed by Object Management Group (OMG) 1997 as UML. The use of UML as a standard implies communication without ambiguity. Benefits of modeling AOSD are that when aspects are identified at an early stage of the development life cycle, it makes their design components more reusable and automatic code generation possible for AOP systems. UML profile introduced basic AOSD terminology for UML to enable the visual representation of AOSD systems. The OMG defined UML modeling language in four layer architecture. The UML metamodel was defined and standardized. The metamodel layer defined the modeling language. The metamodel layer explained the model and the 18

9 user object layer explained instance of the model. UML provides the facilities to extend its metamodel to fulfill the requirement of a modeling concern. Extension model could be customized and extended. To allow the modeling a specific domain UML profile provided a predefined set of stereotype, tagged value and graphical icons. UML profile took for AOSD provided graphical notation for AOSD. It provided every aspect & support for AOSD in UML. UML profile provides different stereotype of AOSD like <<aspect>> << join point>> and << point cut>>. The researchers recognized the importance of applying aspect oriented technique to all phases of software development life cycle. The aspectual properties of the problem were initially decomposed and eased to the next life cycle phase. The authors discussed UML profile for modeling the orthogonal concerns in the aspect oriented software system. Identification of an aspect at an early stage of the development life cycle it makes design components more reusable. In this paper a simple extension to UML package has been proposed in a UML profile for AO. It provided guidelines for use of graphical notations for AOSD. This extension mechanism was based on the concept of stereotypes. The authors suggested list of stereotypes for AOSD and not defined any association notation in this paper. Behavior of aspect and classes could be described with collaboration diagrams. These were the views of authors for UML profile. Still a formal modeling of AOS development is required. Losavio, F., Matteo, A., et al (2009) presented an AOSD UML core for early aspect and focused on the AOSD ontology documents of common foundation for AOSD and various UML extensions. This was explained by taking a case study for initial architecture of a web application and provided establishment of standards for unified AOSD terminology. The authors explained AOSD Modeling and UML extension for AOSD. UML can be extended into two ways; metamodel and profiles. Their extensions were also explained in this paper. Stereotype was used in profile modality. Various notations for UML by different methods for AOSD such as UML notation for aspect, composition, weaving, standpoint, and advice for modeling element and their stereotypes were also discussed in detail. Authors tried to reduce the gap between the requirements, use case and component models. Basically the authors worked on requirement and analysis phase. But there was a need to improve on initial step that could be included in product line aspect oriented architecture design approaches and need of automated tools design architect. Fuentes, L. and Sánchez, P. (2006) proposed the UML 2.0 profiles for aspect oriented system and extended the aspect oriented concept means of profiles. Various 19

10 techniques to platform specific models were discussed. The main advantage of using UML profile is a notation and concepts which are familiar to many designers. MOF metamodel has been created for each AO proposal by reusing elements from previously elaborated MOF metamodel. The generic metamodel was proposed using MOF best by reusing the maximum elements of UML 2.0 metamodel. This metamodel consisted of four basic packages i.e. package structure, entities package, joint point package and AO behavior package. Extra package like method for adding classes, interfaces and aspect composition were also proposed. Aspect composition rules model were defined for composition between aspect and base classes. Inter type composition rule model has been used for addition of new structural and behavioral features to entities. UML profile used stereotype <<aspect>> for aspect when they did not have the same structure as common classes. Intertype stereotype feature was represented as <<intertype>> and non-intertype as <<aspectual>>. Intertype binding could be between related aspect and base classifier and aspectual binding could be done between behaviors of base class. And aspect association and dependencies has been used to show relationship between classes and components. UML 2.0 provided wearing mechanism by using some classifiers like hooks, aspect binding, point cuts and AO behaviors. Basically this paper defined new alternative and modeling approach that was not specified in the previous survey. Jackson, A., Sánchez, P., et al (2006) focused on traceability support from AO architecture to AO design. The system design elements have been derived from architectural elements and these elements have well defined mapping between DAOP- ADL and UML (AOD) for providing traceability support. Every use case behavior has been mapped to a set of required methods of the components interface. After developing the architectural design, each component has been implemented. Reuse component has been marked so that previously developed components could be recognized. Traceability support has been supplied at instance where elements in design have been developed based on architectural elements. These alternatives for selecting a specific alternative were recorded. The information has been recorded in two iterations. In both iterations anticipated and unanticipated changes have been identified. It was observed that analyzing the justification for selection of alternative in the first alternative could help the designer to change the design decision in second iteration. Zakaria, A. A., Hosny, et al (2002) proposed a UML extension for model aspectoriented systems. The extension was applied to Rational Rose, CASE tool as an add-in to facilitate the use of proposed extension. The add-in generates skeleton file of an AspectJ 20

11 for Rational Rose tool. The main aim of this extension was to tailor the UML for modeling system aspects. This extension tool was based on stereotypes, tagged values and constrains. Stereotypes were used to extend the UML vocabulary and introduced a new type of model elements. Tagged values were used to specify the characteristics or attributes of model elements and constraints were used to represent how a UML element is to be treated. It suggested notation for aspect as shown in figure 2.6 (a). Figure 2.6 (a) Aspect, (b) Pointcut Aspect class relationship depends upon model system. It proposed three aspect Boolean tagged values; abstract, active aspect and passive aspect. A pointcut described where an aspect advice gets attached to class functionality. A join point is a pointcut whose expression is a function name or an attribute. The proposed stereotype for pointcut is as shown in figure 2.6 (b) and association with class is <<Point cut>>. Pointcut acts like an interface with the aspect to determine the point in the execution at which the advice is executed. Figure 2.7 shows two pointcuts circle and triangle of an aspect. Figure 2.7 Pointcut circle and triangle attached with an aspect The Unified Modeling Language provides both static and dynamic views for software specification by using several diagrams, such as class diagrams provide a static view of the classes of the objects that are used in the system and their relationships. Due to the lack of UML in aspect oriented language constructs, cross cutting concerns of a 21

12 software system cannot model modularly in class diagrams. A simple extension of UML class diagram has been proposed by Zhang, G. (2005) which implements the concept of aspect-orientation in UML class diagrams. Aspects were introduced into class diagrams as first class elements that consist of a pointcut and an advice. The static structures of various software systems like Logging system, Airline system and Library System were modeled more modularly and redundancy in models has been reduced. An Aspect oriented domain specific language called Program Description Logic (PDL) is developed by Morgan, C., Volder, K., D. et al. (2007) for the specific purpose of checking the design rules. PDL has been based on a fully static and expression pointcut language. A PDL program consisted of a list of point cut advice pairs where each pointcut advice pair represented a design rule. The point cut matches violations of a design rule and the advice specified a corresponding error massage. The syntax of PDL point cut was similar to AspectJ but the PDL joint point model was static, such that the evaluation of PDL points cut has been done statically. The evaluation of PDL has been done by comparing it to Fxcop, an industrial strength tool for checking the design rules. The approach was comparable to Fxcop and could scale to large codebase. As aspect-oriented software development (AOSD) is gaining wide attention, it requires a new assessment framework to measure the reusability and maintainability. Sant Anna, C., Garcia, A., et al (2003) presented an assessment framework for AOSD, which was composed of two components: a suite of metrics and a quality model. The quality model defined precisely how to measure reusability and maintainability based on a set of proposed metrics. The proposed metrics captures information about the design and code in terms of coupling cohesion and size. The suite is composed of five design metrics and five code metrics. An assessment framework has been development to capture the understanding of coupling cohesion and size attributes to provide support for assessment of reusability and maintainability of aspect-oriented systems based on the proposed metrics suite. The basic components of the framework are the suite of metrics and the quality model. The quality model establishes a relationship between external, internal attributes and metrics. The metrics and model have been evaluated by using two different empirical studies with different characteristics. The first study was an experiment to compare the use of object-oriented approach and Aspect oriented approach to design and implement a multi agent system. Second study defined the implementation of proposed framework to evaluate Hahnemann s Java implementation and AspectJ implementation of the GOF design patterns. The proposed metrics of the framework satisfy the important requirements 22

13 in order to achieve successful measurements in AOSD context. The model also assists software engineers to interpret the data gathered from measurement process. The proposed framework show a justified result in the assessment of design decisions in AOSD and in comparison of both aspect oriented solutions and object-oriented solutions. A UML based design notation based on the limited time devotion on analysis and design is described by Bustos, A., and Eterovic, Y. (2007). It used to model the main concepts of aspect, its behavior and relationship with the base system. UML s class, software and state diagrams have been used in which the notation added a few new elements to model pointcut specification and pointcut activation. The notation considered two views of the relationships between an aspect and the base system: a static view and dynamic view. To show the dynamic nature of aspect both state and sequence diagrams are used. The state diagram is used to represent the internal behavior of the aspect and the sequence diagram is used to represent interaction between the aspect and the base system. To represent the static view of an aspect, a class diagram is used that shows the relationships between the aspect and the rest of the system. The proposed notation allowed giving reasons about the weaving process between the aspect and base system. A method has also been proposed to develop the static view in three stages. The methodology has been applied to design a bottle neck detection system for a real system i.e. major mobile communication service provider and systems seem to give good results. Zakaria, A. A., and Hosny, H. (2003) described the effect of CK metric of Aspect oriented system. In this paper most of the work has been done at the implementation level. Aspect oriented technology builds on the basic concepts of object oriented technology. So the metrics used for Object Oriented systems are applicable for Aspect Oriented systems. It defined the effect of aspect oriented on the following CK metrics i.e. WMC, depth of inheritance tree, number of children, lack of cohesion in methods, coupling between objects and response for a class. Still empirical validation is required. The attribute significant from design testability is called class interaction. The interaction points out of the design need to improve driving structural modifications or constraints specifications for reducing the final testing effort. Bandry, B., Traon, Y., L., et al. (2002) proposed a testability measurement approach that counts the number and the complexity of interactions that must be covered during testing. The authors were concerned with the issue of testability of object-oriented static design based on the UML class diagrams. It aimed at pinpointing the parts of the software architecture, where complex interactions may appear and lead to difficulties in testing. 23

14 By using the bottom-up methodology, various concrete applications are studied in order to indentify the attributes that impact the testability in a precise testing context. To do that, a testing task is defined and an effort is done to test a piece of software according to the criterion that is evaluated such that evaluation of all the interactions and their complexities was done. Defined global test cost is equal to the number of detected testability anti-patterns. A testability anti-pattern is a design solution that presents a configuration in the class diagram which increases the testing efforts. Testability antipatterns and class interaction or self-usage interaction were identified as two main configurations that make the code complex. These anti-patterns between classes might be implemented as interactions between objects due to which the final software may become difficult to test. The proposed test criterion covered all the interactions and a model has also been defined that could be derived from a class diagram from which it was possible to detect all the anti-patterns in an ambiguous way. By using the proposed model it was possible to compute the complexity of anti-patterns which is the maximum number of object interactions that could exist in further work Bandry, B., Traon, Y., L., et al. (2003) had shown an improvement by using UML extension mechanisms to better specify design information that could make implementation more testable. UML extension mechanisms such as tagged values and stereotypes were the main features used to specify the roles of the relationships in the class diagram. By using the ideas investigated in the previous work various solutions are proposed to improve the testability of the design. The idea was to add information on the design to make implementation more testable. The goal was to give the intuition of the testability issues that could be objected from class diagrams and to improve the proposed models for making the design more testable. An interesting technique has been proposed to identify the testability anti-patterns as particular part in the design on which a particular attention should be taken to limit testability problems in implementation. UML stereotypes were also proposed that add information on relationships in the class diagrams which helps to improve the testability of the design Testability Concepts Testability of a software system is defined as attributes of software that bear on the effort needed to validate a software product, i.e., it is indicative of the amount of effort required to test the system. Predicting the testability at the early stage of software development may lessen the time and cost of a software project. The following section presents a review of various testability concepts. 24

15 Jungmays, S. (2002) explained the testability usage related to dependence during design phase and also discussed new approach based on metric to handle critical usage for testing. The factor for testability facto complexity, separatism of concerns coupling, fault locality, controllability, observably, automaticity built in test capability and diagnostic capability were considered. But during design level some usage are considered for testability like hard-wired dependencies on class. It may be possible that a server class depends upon hard-wired dependencies to classes, cyclic dependencies between classes, cyclic links between objects, dense object network etc. Reduction matrices were proposed to evaluate the impact of a particular dependency on testability. Still there are many parameters to be discussed which make negative impact on system structure. These measures are also for Object Oriented Systems. Kassab, M., Ormandjieva, O., et al. (2005) identified and defined the occurrence of crosscutting during software requirement and design phase. Some quality measurement associated with initial phase of aspect-oriented software development was considered for functional requirements and non functional requirements. Authors took two use case diagrams to check the modularity. In use case model object-oriented software metrics, MOOD has been used to measure the coupling in the domain model interaction point to identify where other requirement may crosscut. Then relative size was defined i.e. at a particular interaction point how many crosscuts effect. The relative parameter like local conflict, inter dependency, interaction point has been evaluated. For design phase they define cohesion and coupling for separation of requirement. But still this frame work will assist in existing crosscut at the design level only. Gupta, V., Aggarwal, K.K., et al. (2005) proposed testability index for objectoriented software. This single value testability index can be used to calculate the testability of class. Fuzzy technique and concept was used to evaluate the testability index. Object oriented metrics were used with respect to their capabilities to evaluate the effort needed for testing. For this Chidember and Kemerer (CK) metric are used i.e. WMC, RFC, CBO and DIT. Testability index is a combination measure of renewal characteristics of Object Oriented Software like CK metrics, abstraction, polymorphism and inheritance. These characteristics and metrics are integrated with the help of fuzzy model to process their value in fuzzy domain, knowledge based index or information supplied by domain experts. Proposed fuzzy model consider four inputs where each input consists of three terms. It will create 81 rules for all these combinations of inputs. After applying these rules the testability index was evaluated. On the basis of testability index, testing effort could be 25

16 produced. This fuzzy model has been proposed for Object Oriented System. The testability index could be used to estimate the testability of software. Mouchawrab, S., Briand, L., C., et al. (2005) proposed a framework for objectoriented software testability. They defined design attributes that have affected testability, directly or indirectly. Design suggestion can be made to improve testability before implementation starts. Another objective of this paper was to identify a set of potential measures and model elements in UML design models which participate to evaluate the measures and change the design to improve testability. Firstly three levels of testing i.e. unit testing, integration testing and system testing were explained. Then an effort intensive testing sub-activities like specifying test cases, developing drivers, developing stubs and developing oracles were defined. A hypothesis is provided to describe the cues effect relationship between attributes and testability and was based on a thorough and systematic review of the literature. The authors supposed that measures must be defined from the information available in UML use case, class, state chart, and interaction diagrams. Proposed framework was generic and not limited to any specific development. The measures of a given testability attribute may vary according to the situation considered as unit coupling affects the integration testing. This paper provided hypotheses that how and why the attributes affect testability. The author provided 20 hypotheses on different attributes like inherited feature, inheritance design properties and discussed which may impact testability. This impact is not always controllable or avoidable. After that they defined OCL expression complexities i.e. many attributes depend on the complexity of constraint expression (OCL) which play important role is many UML diagrams. Use case model and system interface complexity has been defined. During evaluation they found that integration testing involved different attributes than unit testing. The authors defined a detailed table of attributes at each level of testing with their measure and remark. Measure could not be interpreted independently and bench marks on multiple dimensions helps decision making. This paper provided a framework for predicting the testability of designs by specifically focusing on the UML. Still empirical validation is required for these hypotheses. Phogat, M., and Kumar, D. (2011) proposed the factor of testability for object oriented system. Framework for software metrics has been defined to assess the testability of the class of an object-oriented system. The approach used to analyze a set of object-oriented metrics with respect to their contribution to evaluate a system s testability such as testing 26

17 criterion, documentation implementation, test suite, test tools and process capability. The author classified the already proposed measures into three groups. 1. Program-based measurement methods 2. Model-based measurement methods 3. Dependability assessment methods Program-based measurement was evaluated through Arithmetic Expression, Assignment Predicates and Boolean Predicates. Then they defined Model Based Testability by checking data flow model. Black box approach was used for Dependency Based Testability measurement. The authors focused on Program input and outputs. Simplicity of system was evaluated by complexity, and simplicity is inversely proportional to the complexity. Testability of a method into the class depends upon the visibility component, i.e. TM = Constant*(VC) Testability of class is Q = MIN(TM) VC = Visibility component-possible input/output Cyclomatic Complexity was computed by using control flow graph. They defined testability metrics for object-oriented system by using the R. Binder work for testability. Predicting class testability using object-oriented Metric; Bruntink, M., Deursen, A. (2004) defined factors of the testability of software system. Software testability was characterized using source code metrics and forced on object-oriented white box unit testing. An adapted version of fish bone diagram is used for identifying test case construction factors to evaluate testability. Metrics used were DIT, fan-out, LCOM, LOCC, number of children, number of Fields, number of methods, response for class and weighted method per class. The authors evaluated these metrics using the GQM/MEDEA frame work proposed by Basili et al. DLOCC and NOTC metrics were also defined to indicate the size of attest suite, where d is a dependent variable. Statistical analysis was used to investigate the hypotheses proposed in this paper. The main aim of this paper is to increase understanding of what makes code hard to test. Still this work is also related to object-oriented system and source code base testability. Aspect oriented Architectural framework has been focused on the problem developing software system that fulfill non functional of requirements such as performance, testability adaptability etc. Cooper, K., Dai, L., et al. (2003) defined the problem in Formal Design Analysis Framework (FDAF) using formal architectural 27

18 description language. FDAF was used to define aspect oriented design and analyze multiple non functional properties with the help of Non Functional Requirement (NFR), UML and a set of formal methods. The formal design analysis framework consisted of extended UML design model, NFR framework for design, existing formal methods, aspect oriented formal Models, Automate the design and analyze non-functional properties, which used semiformal and formal methods. It assisted the designer to choose an appropriate formal method, analyze and identify conflicting properties using on extended version of the NFR. It already defined the notations used an architecture design, including UML and formal methods to help the analysis of a design. Still it defined a single non functional properly and there is a need to work for other non functional property. Zhao, L., (2006) defined problems in existing research work. Beta distribution had been used to indicate software testability. There are some limitations of existing research. Many researchers have defined their own definitions to process analysis like controllability, prediction of the failures to be observed during random black box testing, potential conflict that may observe during test, estimate effort to test the software according to certain criterion etc. These definitions reflect the nature of testability and aim at different targets without any operational guidelines. It provides research hypothesis and proposed solution of research objectives. Basically three main steps were defined, testing criterion s effectiveness measure by using fault detection probability. Secondly it evaluates the express ability of beta distribution, which affected all factors that have negative impact on testability. Third is the experiment, which validates the usability of the model. It observes the effectiveness of several testing criterion on various program. Nazir, M., Khan, R. A., et al. (2010) defined a framework for testability estimation of an object oriented system. Author validated the acceptability and used the frame work for estimating testability in design phase which consisted of seven steps like testability factorization, software characterization metric selection, correlation establishment, testability quantification and qualitative assessment. It also consider design review quantitative estimate of testability help in defining design hierarchy. Testability quantification has been mentioned by execution steps it is observe that various factors play a significant role in predicting software testability. Two factors; understandability and complexity having great significance on quantifying object oriented software testability for that understandability estimation model and complexity estimation model have been developed to quantify the understand and complexity of software design. A statistical 28

19 analysis has been made to prove the correlation of testability with understandability and complexity in empirical validation of the model is also carried out. Bruntink, M., Deursen, A., (2006) defined a framework to predict testability of classes in an object-oriented system static analysis of source code. Object oriented metrics like depth of intendance tree, number of children line of code of a class has been used to evaluate testability. The size of test framework is considered as estimates of testing effort. Test framework is measured by metrics such as number of test cases is used. It defined the correlations between the object oriented properties and the test framework size by statistical analysis. Singh, Y., and Saha, A. (2010) have predicted testability at package level. Eclipse Plug-in has been developed to evaluate the value of source code metrics and test metrics from Eclipse project. These metrics were calculated at package level and obtain from Junit test classes. These package level metrics were defined from class level metrics to identify some test metrics based on Junit test classes. These metrics were calculated at package level and obtained from Junit test classes. These package level matrices were defined from class level metrics which identified some test metrics based on Junit test classes like TLOC, TM, TA and NT class etc. On the basic of these metrics several hypothesis have been proposed and evaluated. It also defined a relation between source code metrics and test metrics. This correlation was defined by using system related metrics (LOC, LOA, NOM, WMC), cohesion metrics (LOCM, ICH, TCC), coupling metrics (CBO, DAC, MPC & RFC) and inheritance related metrics. It has been observed that the source code metrics affect the testing efforts and testability at the package level. It was observed that as the size of the software increases and the testing efforts also increase. Massicotte, P., Badri, M., et al. (2005) relate testability with aspect-class integration testing sequences. A new technique has been proposed to generate test sequences based on the dynamic interactions between aspect and classes. Major part of this paper covered the unit testing of aspect oriented programs. The sequence diagrams generated from given collaboration diagrams have been verified by checking their working and errors. The errors not related with aspect have been eliminated and incremented to integrate the aspect. Gao, J., Wu. Y., et al. (2003) introduced three basic approaches to increase software component testability: framework based testing facility, Built-in tests, and Automatic component wrapping for testing. These three mechanisms constructed testable components. Framework based testing facility approach is a well-defined framework (such 29

20 as a class library) used to develop and allow engineers to add program testing code into software components. Built-in tests method required component developers to add test code and tests inside a software component to support self-checking and self-testing. Automatic component wrapping for testing method used a systematic way to convert a software component into a testable component by wrapping it with the program code, which facilitated software testing. Coelho, R., Staa, A. et al. (2009) proposed an exception handling mechanisms to make programs more reliable and robust. First the exploratory study was performed to assess the error proneness of AOP mechanisms on exception flow of programs. Second was the development of SAFE (static Analysis for the Flow of Exceptions) tool for exception flow analysis in AspectJ programs. A framework was defined that enables the developer to find faults on the exception handling code statically. The authors also introduced a set of bug patterns related to the exception handling code of AO programs that were characterized based on empirically data collected. Join point models were also specified to enable aspects to add new exception at specific point in the code, potentially causing the bug patterns found here Fuzzy models Fuzzy approach is a problem-solving control system methodology for implementing simple and small to very large multi-layered systems. It can be implemented in software characteristic evaluation through approximation by providing a simpler way to achieve definite results based upon ambiguous or imprecise crisp input variables. This section discusses the approaches to develop a fuzzy model. Kumar, R., Grover, P. S., Kumar, A. (2010) developed a framework for evaluating the complexity of an aspect-oriented system has been defined. It developed a tool using fuzzy logic to automate the measurement of complexity. It has proposed new complexity metrics for AO system. Design of metrics depends on internal characteristics like cohesion, coupling and complexity. The tool proposed by authors to automate complexity measurement using fuzzy logic has three different inputs related to complexity. For these inputs, 96 fuzzy rules have been defined to measure the complexity of generic AO systems. The complexity has been divided into two categories: 1. Code Complexity 2. Interaction complexity Complexity is CMP G = CM P +CMP I 30

21 All the complexity metrics can be added only if all metric values are in same unit. There may be hundreds of combination of complexity weight values of operational. It proposed solution of above said problem by using fuzzy logic approach. This fuzzy model integrates all the AO component complexity. It evaluated code complexity for generic AO Software. For large software projects testing is a major part of software life cycle to make the project acceptable and of good quality. Testability of object oriented software can be effectively measured from testability effort and time required to test the software. Testability effort can be calculated using object oriented metrics system. Fuzzy logic can be used to determine precise testability index. Two approaches have been used by Kaur, N., Singh, M. (2011). Mamdani and Sugeno models of fuzzy logic have been used to calculate the precise testability index of software project. Various metrics were used to find testability like Average Cyclomatic Complexity (ACC), CBO, RFC and DIT. These metrics were applied as a convex set of all geometric figures, Polygons, Triangles etc. The value of metric were calculated as ACC = 2, RFC = 8, CBO = 0, DIT = 2. For triangle the value of DIT = 1. These metrics have been measured manually or using tools like JHawk. Fuzzy logic model has also been used by Mamdani model logic to find out the Precise Testability Index (PTI) as shown in figure 2.8. The Mamdani Testability Index and Sugeno model of fuzzy logic has also been used to find out the Sugeno Testability Index. Figure 2.8 Fuzzy model 31

22 2.2 Conclusion In this chapter, two main topics have been reviewed in detail i.e. UML for Aspect Oriented Systems (AOS) and Testability of Software Systems. From this survey it has been found that many of the researchers have worked on UML design for Aspect Oriented Systems, and each one has suggested his own notation for designing AOS. Further it has been observed that there is no standardized tool which satisfies all the AOS design requirements. To satisfy the problem definition of the proposed work, Suzuki s notations for class diagrams are followed. In this chapter a detailed review has also been carried out on testability of Object Oriented Systems (OOS). Metric suites for testability such as cohesion, coupling, complexity, inheritance for AOS have also been reviewed. It has been found that the proposed metrics are applicable for AspectJ since they affect the external characteristics such as testability. It has been observed that some of the metrics can also be applied for AOS to evaluate the testability as AOS is an extension of OOS. In short, an up to date research has been studied which is very useful for carrying out the further work in this area. The next chapter describes our work related to testability framework for AOS and its validity. 32