MexADL presentation for the HADAS group

1. MexADL: An Aspect-Oriented Approach for Verifying the
Maintainability of Software Systems
Juan Castrejón, Rafael Lozano, Genoveva Vargas-Solar
ITESM-CCM, LIG-LAFMIA
http://code.google.com/p/mexadl

2. OUTLINE
• Introduction
• Approach
• MexADL
• Case Study
• Conclusions

3. PROBLEM (1/3)
• Asa 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%
http://users.jyu.fi/~koskinen/smcosts.htm

4. PROBLEM (2/3)
Maintainability software development problem factors
Lack of traceability
Changes are not adequately documented
Documentation is obscure or untrustworthy
Lack of adherence to programming standards
Lack 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.

5. PROBLEM (3/3)
• Inregard 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

6. AREAS AND TOPICS

7. SOFTWARE ARCHITECTURE
(1/2)
• Thisdiscipline 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

8. SOFTWARE ARCHITECTURE
(2/2)
• 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

9. SOFTWARE QUALITY
(1/4)
• 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.

10. SOFTWARE QUALITY
(2/4)
• Newgeneration 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

11. SOFTWARE QUALITY
(3/4)
SQuaRE quality model

12. SOFTWARE QUALITY
(4/4)
• Maintainabilityis 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

13. ASPECT ORIENTED
PROGRAMMING (1/2)
•A way to cope with software complexity is to follow the
separation of concerns principle
• The principle states that a program can be divided into
different features, or concerns, to allow independent analysis,
striving to maintain a minimum overlap of functionality among
them

14. ASPECT ORIENTED
PROGRAMMING (2/2)
• 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

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
• Themaintainability 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/4)
• An implementation of this approach for Java based systems
Requirement Tool implementation
ADL xADL 2.0
ADL environment ArchEdit, Archipelago
AOP implementation AspectJ
Build tool Apache Ant
Implementation tools

24. MEXADL (2/4)
External metrics tools

25. MEXADL (3/4)
xADL 2.0 extension (Characteristic)

26. MEXADL (4/4)
xADL 2.0 extension (Sub-characteristics)

27. OUTLINE
• Introduction
• Approach
• MexADL
• Case Study
• Conclusions

28. CASE STUDY (1/9)
• Indvalid: Validate digital tax receipts according to mexican regulations
http://indvalid.com, 188 classes, 3 programmers, 1 architect

29. CASE STUDY (2/9)
Quality metrics values

30. CASE STUDY (3/9)
Association of quality metrics

31. CASE STUDY (4/9)
Association of user-generated types

32. CASE STUDY (5/9)
An invocation
has been made
Execution
Execution
Compile-time warning

33. CASE STUDY (6/9)
Quality metrics aspect

34. CASE STUDY (7/9)
Associate
components to
Component
types
Marker
interface for
ServiceType
Association aspect

35. CASE STUDY (8/9)
Verification results

36. CASE STUDY (9/9)
Verification results

37. OUTLINE
• Introduction
• Approach
• MexADL
• Case Study
• Conclusions

38. CONCLUSIONS (1/2)
• 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
• Theset of source code quality metrics is not fixed, and could
be changed according to the needs of particular projects
• Thisflexibility would also come in handy in the event of
changes to the definition of the ISO/IEC SQuaRE quality
model.

39. CONCLUSIONS (2/2)
• 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.

40. FUTURE WORK
• Furtherevaluate the validity of our approach, by applying it to
a wider set of software projects
• Improvement of current verification controls during the
generation of AOP inter-type declarations.
• Implementationsfor other environments such as C++ or
the .NET framework
• Consideration for dynamic structures of software systems

41. Questions