A proposal to support the extreme programming development methodology from the quality assurance point of view Authors: Calin Jebelean – Vladimir Cretu –

Introduction Quality New Requirements V1V2Vn-1Vn... System evolution Detection of design flaws System refactoring Software engineer

Detection of design flaws? “There is no perfect software design …” [Fowler,O’Cinneide] … but each software design can be improved Design flaw detection lies at the bottom of improving the quality of a software design Keywords

Refactoring? Altering the code of a software system towards improving its design, without affecting its observable behavior Design modification required by: the software development method (agile methods) the maintenance phase of system’s lifecycle the detection of design flaws Keywords

Modeling? Code analysis: difficult and less practical Solution: performing analysis on a simplified model of the software system Advantages: Simple analyses Language independence Drawbacks: Loss of information – can lead to lack of relevance Keywords

Adaptive development methodology Change should be embraced, not denied Some principles: Interpersonal communication between developers (pair programming) between developers and clients (on-site customer) Acceptance of changing requirements simple design refactoring Frequent release of functional software short releases Extreme programming

Simple design Iterative system evolution Adapting the design to accept a new feature vs. adapting the feature to the existing design Prediction is unnecessary

Extreme programming enhanced Using models of the system between consecutive releases Capturing the refactoring intention (Expert E) Evolving the system as recommended “by the expert”

A Visitor Recommendation System SSystem S’ Inspired from [MT04]

A Visitor Recommendation

An Abstract Factory Recommendation System SSystem S’ Inspired from [GHJV95]

An Abstract Factory Recommendation

Conclusions Automatic support provided to the extreme programming development methodology during the refactoring step is feasible More analyses can be thought of and implemented as part of the expert module E Future work Implement the expert module containing the two analyses at first Define a suitable language to describe such analyses and allow other software engineers to freely add other analyses to the expert module Conclusions and Future Work

[Bec99] K. Beck – Extreme programming explained: Embrace change, Addison-Wesley, 1999 [Fow00] M. Fowler – Refactoring: Improving the design of existing code, Addison-Wesley, 2000 [MT04] T. Mens, T. Tourwe – A survey of software refactoring, IEEE Transactions on Software Engineering, February 2004 [GHJV95] E. Gamma, R. Helm, R. Johnson, J. Vlissides – Design patterns: Elements of reusable object-oriented software, Addison-Wesley, 1995 Bibliography