1 Modularity Analysis of Use Case Implementations Fernanda d’Amorim Advisor: Paulo Borba

2 Component-based decomposition Use cases are system concerns Use case Actor Requirements are assigned to components Requirements can be specified as use cases

3 Ideally, we want to isolate different concerns into separate components… but, in practice…

4 Typical Use Case Implementation

5 Use Cases are crosscutting concerns with respect to implementation!

6 Crosscutting Concerns impact on Modularity Changeability –Invasive changes Traceability –Loss of 1:1 Mapping between use case code and assets Understandability –Tangling and scattering makes code difficult to understand Increase on maintenance and evolution cost !

7 Goal: modularize use case implementations

8 Why? Hypothesis: Modularity of use case implementations improve the overall system’s modularity RQ1. Does modularity of use case implementations reduce modularity of non use case concerns? RQ2. Does modularity of use case implementations improve overall maintenance and evolution? RQ3. Which modularity dimensions benefit from modularized use case implementations?

9 Traditional Modularity Techniques –Abstract Data Types –Structured Programming –Object Oriented Programming New Modularity Techniques –Composition Filters –Adaptive Methods –Aspect Oriented Programming How?

10 Modularity improvement? overall evolution? better traceability? better pluggability? X

11 Let’s analyze! Use cases on the target system Changes Concerns Metrics

12 Techniques Use Case as Aspect - with AspectJ –Intertype declaration, advices and aspects. Use Case as Pluggable Collaboration - with CaesarJ –Virtual classes, collaborations and mixins composition.

13 Toy Example – Library System Add Book CheckInBook CheckOutBook StaffMember

14 Use Case as Aspects System composed by core components and use case modules One module per use case implementation

15 Use Case Module Groups code related to a single use case Contains –Specific Classes –Specific Extensions

16 Use Case as Pluggable Collaboration System composed by core collaborations and use case collaborations One collaboration per use case

17 Use Case Collaboration Groups code related to a single use case Contains –Specific Classes and Classes Refinements

18 Key Points to Evaluation Metrics Selection –GQM model linking software quality attributes to meaningful metrics –Most metrics previously defined and used in others AOP studies Change Requests –Changes commonly applied to a system under maintenance. –Different types (perfective, adaptive and corrective) –Different natures (use case scoped and system scoped)

19 Metrics CDC DOSC DOT ADOSC ADOT CDC NSFC NCC NAC NALOC CI NAC CBO, LCO VS, DIT LOC NCC NBDLOC NDLOC

20 Case Studies Library System –Toy application –Used to consolidate techniques and the evaluation process Health Watcher –Real System –Benchmark for AOP studies - Solid Evaluation

21 Health Watcher (HW) Setup

22 Health Watcher Original Design

23 Change Requests CR1- Addition of 6 new use cases CR2 - Modifications on 2 use cases CR3 - Removal of 1 use case CR4 - New persistence mechanism

24 HW - Separation of Concerns

25 HW – DOSC and CDC

26 Chosen Concerns (and assignment) impact results! Less tangling when concerns do not cover most of the code More tangling and scattering when there is more concern intersection Modularity depends on chosen concerns!

27 Ok with GUI, Business and Data concerns but tangling and scattering when we also consider a use case concern… Ok with use case concerns but tangling and scattering when we also consider GUI, Business and Data…

28 HW – Complexity UC_AO implementation –Better result for Cohesion (LCO) UC_OO implementation –Better result for Coupling (CBC) and Vocabulary Size (VS) Similar results for Lines of Code (LOC) and Depth of Inheritance Tree (DIT)

29 HW – Changeability Propagation of change effects depends on the type of change. –Use case scoped changes present better result when use cases code are modularized –System scoped changes present better result in the use case OO implementation Modularity depends on the type of change!

30 HW – Pluggability, Traceability and Parallel Development Modularizing use case implementations leads to a system where it is easier: –To plugg or unplugg a use case –To maintain traceability links between use case code and others assets –To manage parallel development related tasks

31 Threats to Validity Target System Techniques/Languages Concerns selection and assignment Metrics Change requests

32 Modularity Analysis is Relative! Concluding Remarks Language constructs are unable to provide a decomposition that is superior in all situations

33 Related work Use case implementations modularity techniques –Jacobson, Herman et al., and Bhole et al. AOP empirical studies –Garcia et al., Kulesza et al., Greenwood et al., Valente et al.

34 Future Work Execute others case studies considering different and real target systems –Collect more evidence of our findings Analyze and repeat one of our case studies using a tool-based solution –Virtual Separation of Concerns/Features –Program Navigation Analysis

35 Modularity Analysis of Use Case Implementations Fernanda d’Amorim Advisor: Paulo Borba

36 Use Case as Aspect - Constructs Intertypes, advices and aspects.

37 Components and Modularity Encapsulate requirements that change together Essential to design, implement, and test the system Key to Reuse!