Juan Carlos CastrejónITESM-CCM

An Approach for the Maintainability Verification of Software Systems based on Aspect Oriented Programming and

Architecture Description Languages

1

OUTLINE

• Introduction

• Approach

•MexADL

• Case Study

• Conclusions

2

PROBLEM (1/3)

• As a software system evolves, the lack of compliance between design documents and implementation artifacts may cause a detriment in its overall quality

• Software maintenance costs between 50-75%

3

PROBLEM (2/3)

Maintainability software development problem factorsLack of traceability

Changes are not adequately documentedDocumentation is obscure or untrustworthy

Lack of adherence to programming standardsLack of consideration for software quality requirements

Chen, J., & Huang, S. (2009). An empirical analysis of the impact of software development problem factors on software maintainability. Journal of Systems and Software, 82(6), 981-992.

4

PROBLEM (3/3)

• In regard to the maintainability of software systems, we can identify two main sources for this detachment

• An ambiguous documentation of the system’s architectural intent and its desired quality attributes

• An absence of adequate mechanisms to enforce that both architectural and quality intents are maintained through system evolution

5

AREAS AND TOPICS

6

• This discipline strives to capture, document, analyze and reuse the highest level of abstraction of a system, by representing it with one or more structures, the components they are composed of, and the externally visible properties of such components

SOFTWARE ARCHITECTURE (1/2)

7

• System elements are usually depicted using informal diagrams and idioms (Ex: box-and-line)

• Architecture Description Languages (ADL) emerged as an effort to overcome this situation, by providing formalized constructs that strive to effectively represent a system’s architectural intent

SOFTWARE ARCHITECTURE (2/2)

8

• The quality of a system is the degree to which the system satisfies the stated and implied needs of its various stakeholders, and thus provides value.

•Quality Models: McCall, Boehm, ISO 9003, ISO 9126, etc.

SOFTWARE QUALITY(1/4)

9

•New generation of quality standards referred to as ISO/IEC SQuaRE (Software Product Quality Requirements and Evaluation)

• A logically organised, enriched and unified series covering three complementary processes: requirements specification, measurement and evaluation

SOFTWARE QUALITY(2/4)

10

SOFTWARE QUALITY(3/4)

SQuaRE quality model

11

SOFTWARE QUALITY(4/4)

•Maintainability is defined as as the degree of effectiveness and efficiency with which the product can be modified

•Divided into five sub- characteristics: modularity, reusability, analyzability, modifiability and testability

12

ASPECT ORIENTED PROGRAMMING (1/3)

• A way to cope with software complexity is to follow the separation of concerns principle

• The principle states that a program can be split into different features or concerns to allow independent analysis, striving to maintain a minimum overlap of functionality among them

13

ASPECT ORIENTED PROGRAMMING (2/3)

• It is not always simple to define what a concern is

• There may be concerns spanning more than one concept or functionality (crosscutting concerns)

• Classic examples: Security, Logging

14

• The Aspect Oriented Programming (AOP) methodology, introduces a new unit of modularization, the aspect

• An aspect is responsible for the abstraction of a crosscutting functionality

• An implementation of AOP may also include mechanisms to alter the static structure and dynamic behavior of the system

ASPECT ORIENTED PROGRAMMING (3/3)

15

PURPOSE

• To enforce the maintainability quality characteristic of software systems, as defined by the ISO/IEC SQuaRE quality model

• By describing its sub-characteristics within the constructs available in an ADL

• By using AOP techniques to help verify those sub-characteristics through the use of internal quality metrics

16

HYPOTHESIS

• The maintainability quality characteristic of a software system can be effectively defined and characterized using the constructs available in an architecture description language

• The maintainability quality characteristic of a software system can be verified using static crosscutting techniques of aspect oriented programming

17

OUTLINE

• Introduction

• Approach

•MexADL

• Case Study

• Conclusions

18

APPROACH (1/4)

19

APPROACH (2/4)

20

APPROACH (3/4)

Use cases for the verification approach

21

APPROACH (4/4)

Maintainability quality metrics

22

OUTLINE

• Introduction

• Approach

•MexADL

• Case Study

• Conclusions

23

MEXADL (1/8)

• An implementation of this approach for Java based systems

Requirement Tool implementation

ADL xADL 2.0 [31]

AOP implementation AspectJ [10]

ADL environment ArchEdit, Archipelago [31]

Build tool Apache Ant [60]

Implementation tools

24

MEXADL (2/8)

External metrics tools

25

MEXADL (3/8)

xADL 2.0 extension (Characteristic)

26

MEXADL (4/8)

xADL 2.0 extension (Sub-characteristics)

27

MEXADL (5/8)

xADL 2.0 extension (Component)

28

MEXADL (6/8)

xADL 2.0 extension (Java implementation)

29

MEXADL (7/8)

Definition

30

MEXADL (8/8)

Verification

31

OUTLINE

• Introduction

• Approach

•MexADL

• Case Study

• Conclusions

32

CASE STUDY (1/7)

• SQL query optimizer designed for distributed databases

xADL 2.0 description

33

CASE STUDY (2/7)

Quality metrics values

34

CASE STUDY (3/7)

Association of quality metrics35

CASE STUDY (4/7)Layer Spring Annotation

Controller org.springframework.stereotype.Controller

Service org.springframework.stereotype.Service

Repository org.springframework.stereotype.Repository

Layer Java package pattern

Model mx.itesm.ddb.model..*

Util mx.itesm.ddb.util..*

Association of user-generated types36

CASE STUDY (5/7)

Valid interactions aspect

37

CASE STUDY (6/7)

Quality metrics aspect

38

CASE STUDY (7/7)

Verification results

39

OUTLINE

• Introduction

• Approach

•MexADL

• Case Study

• Conclusions

40

CONCLUSIONS (1/3)

• Considering that the quality model of this study is based on the emerging set of ISO/IEC SQuaRE standards, it is expected to remain valid for a reasonable time

• The set of source code quality metrics is not fixed, and could be changed according to the needs of particular projects

• This flexibility would also come in handy in the event of changes to the definition of the ISO/IEC SQuaRE quality model.

41

CONCLUSIONS (2/3)

• The facilities provided by the xADL 2.0 language and its integrated environment, ArchStudio, proved to be very useful to effectively implement the extensions of the proposed approach

• AspectJ’s maturity and particular support for inter-type declarations was of great aid in order to implement the association between ADL descriptions and implementation code in an effective manner

42

CONCLUSIONS (3/3)

•Development teams can detect architectural violations in a more effective way, compared to a manual verification process.

• The approach can help avoid the lack of compliance between design documents and implementation artifacts.

43

FUTURE WORK

• Implementations for other environments such as C++ or the .NET framework

• Consideration for dynamic structures of software systems

44

Questions

45