A proposal to support the extreme programming development methodology from the quality assurance...

Post on 18-Jan-2018

219 views 0 download

description

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

Transcript of A proposal to support the extreme programming development methodology from the quality assurance...

A proposal to support the extreme programming

development methodology from the quality assurance point of

view

Authors:Calin Jebelean – calin.jebelean@ac.upt.roVladimir Cretu – vladimir.cretu@ac.upt.ro

Introduction

QualityNewRequirements

V1 V2 Vn-1 Vn...System evolution

Detectionof design

flaws

Systemrefactoring

Softwareengineer

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

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 S System S’

Inspired from [MT04]

A Visitor Recommendation

An Abstract Factory Recommendation

System S System 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