MexADL thesis presentation

1. An Approach for the Maintainability Verification of Software
Systems based on Aspect Oriented Programming and
Architecture Description Languages
Juan Carlos Castrejón
ITESM-CCM
1

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

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%
3

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.
4

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
5

6. AREAS AND TOPICS
6

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
7

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
8

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.
9

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
10

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

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
12

13. 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

14. 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

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

16. 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

17. 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

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

19. APPROACH (1/4)
19

20. APPROACH (2/4)
20

21. APPROACH (3/4)
Use cases for the verification approach
21

22. APPROACH (4/4)
Maintainability quality metrics
22

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

24. 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

25. MEXADL (2/8)
External metrics tools
25

26. MEXADL (3/8)
xADL 2.0 extension (Characteristic)
26

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

28. MEXADL (5/8)
xADL 2.0 extension (Component)
28

29. MEXADL (6/8)
xADL 2.0 extension (Java implementation)
29

30. MEXADL (7/8)
Definition
30

31. MEXADL (8/8)
Verification
31

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

33. CASE STUDY (1/7)
• SQL query optimizer designed for distributed databases
xADL 2.0 description
33

34. CASE STUDY (2/7)
Quality metrics values
34

35. CASE STUDY (3/7)
Association of quality metrics
35

36. CASE STUDY (4/7)
Layer Spring Annotation Layer Java package pattern
Controller org.springframework.stereotype.Controller
Model mx.itesm.ddb.model..*
Service org.springframework.stereotype.Service
Util mx.itesm.ddb.util..*
Repository org.springframework.stereotype.Repository
Association of user-generated types
36

37. CASE STUDY (5/7)
Valid interactions aspect
37

38. CASE STUDY (6/7)
Quality metrics aspect
38

39. CASE STUDY (7/7)
Verification results
39

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

41. 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
• 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.
41

42. 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

43. 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

44. FUTURE WORK
• Implementationsfor other environments such as C++ or
the .NET framework
• Consideration for dynamic structures of software systems
44

45. Questions
45