0
MexADL: An Aspect-Oriented Approach for Verifying the         Maintainability of Software Systems           Juan Castrejón...
OUTLINE• Introduction• Approach• MexADL• Case   Study• Conclusions
PROBLEM (1/3)• Asa software system evolves, the lack of compliance between design documents and implementation artifacts m...
PROBLEM (2/3)                 Maintainability software development problem factors                                   Lack ...
PROBLEM (3/3)• Inregard to the maintainability of software systems, we can identify two main sources for this detachment  ...
AREAS AND TOPICS
SOFTWARE ARCHITECTURE           (1/2)• Thisdiscipline strives to capture, document, analyze and reuse the highest level of...
SOFTWARE ARCHITECTURE          (2/2)• System elements are usually depicted using informal diagrams and idioms (Ex: box-and...
SOFTWARE QUALITY                  (1/4)• The  quality of a system is the degree to which the system satisfies the stated an...
SOFTWARE QUALITY              (2/4)• Newgeneration of quality standards referred to as ISO/IEC SQuaRE (Software Product Qu...
SOFTWARE QUALITY      (3/4)    SQuaRE quality model
SOFTWARE QUALITY                  (4/4)• Maintainabilityis defined as as the degree of effectiveness and efficiency with whi...
ASPECT ORIENTED         PROGRAMMING (1/2)•A  way to cope with software complexity is to follow the separation of concerns ...
ASPECT ORIENTED         PROGRAMMING (2/2)• The  Aspect Oriented Programming (AOP) methodology, introduces a new unit of mo...
PURPOSE• To enforce the maintainability quality characteristic of software systems, as defined by the ISO/IEC SQuaRE qualit...
HYPOTHESIS• Themaintainability quality characteristic of a software system can be effectively defined and characterized usi...
OUTLINE• Introduction• Approach• MexADL• Case   Study• Conclusions
APPROACH (1/4)
APPROACH (2/4)
APPROACH (3/4)Use cases for the verification approach
APPROACH (4/4) Maintainability quality metrics
OUTLINE• Introduction• Approach• MexADL• Case   Study• Conclusions
MEXADL (1/4)• An   implementation of this approach for Java based systems                      Requirement      Tool imple...
MEXADL (2/4) External metrics tools
MEXADL (3/4)xADL 2.0 extension (Characteristic)
MEXADL (4/4)xADL 2.0 extension (Sub-characteristics)
OUTLINE• Introduction• Approach• MexADL• Case   Study• Conclusions
CASE STUDY (1/9)• Indvalid: Validate digital tax receipts according to mexican regulations               http://indvalid.c...
CASE STUDY (2/9)   Quality metrics values
CASE STUDY (3/9)  Association of quality metrics
CASE STUDY (4/9)Association of user-generated types
CASE STUDY (5/9) An invocationhas been made  Execution  Execution                 Compile-time warning
CASE STUDY (6/9)   Quality metrics aspect
CASE STUDY (7/9)  Associatecomponents to Component   types    Marker interface for ServiceType                     Associa...
CASE STUDY (8/9)    Verification results
CASE STUDY (9/9)    Verification results
OUTLINE• Introduction• Approach• MexADL• Case   Study• Conclusions
CONCLUSIONS (1/2)• Considering that the quality model of this study is based on the emerging set of ISO/IEC SQuaRE standar...
CONCLUSIONS (2/2)• Development   teams can detect architectural violations in a more effective way, compared to a manual v...
FUTURE WORK• Furtherevaluate the validity of our approach, by applying it to a wider set of software projects• Improvement...
Questions
Upcoming SlideShare
Loading in...5
×

MexADL - HADAS Presentation

300

Published on

MexADL presentation for the HADAS group

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
300
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
20
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Transcript of "MexADL - HADAS Presentation"

    1. 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. 2. OUTLINE• Introduction• Approach• MexADL• Case Study• Conclusions
    3. 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. 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 requirementsChen, 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. 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. 6. AREAS AND TOPICS
    7. 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. 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. 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. 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. 11. SOFTWARE QUALITY (3/4) SQuaRE quality model
    12. 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. 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. 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. 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. 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. 17. OUTLINE• Introduction• Approach• MexADL• Case Study• Conclusions
    18. 18. APPROACH (1/4)
    19. 19. APPROACH (2/4)
    20. 20. APPROACH (3/4)Use cases for the verification approach
    21. 21. APPROACH (4/4) Maintainability quality metrics
    22. 22. OUTLINE• Introduction• Approach• MexADL• Case Study• Conclusions
    23. 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. 24. MEXADL (2/4) External metrics tools
    25. 25. MEXADL (3/4)xADL 2.0 extension (Characteristic)
    26. 26. MEXADL (4/4)xADL 2.0 extension (Sub-characteristics)
    27. 27. OUTLINE• Introduction• Approach• MexADL• Case Study• Conclusions
    28. 28. CASE STUDY (1/9)• Indvalid: Validate digital tax receipts according to mexican regulations http://indvalid.com, 188 classes, 3 programmers, 1 architect
    29. 29. CASE STUDY (2/9) Quality metrics values
    30. 30. CASE STUDY (3/9) Association of quality metrics
    31. 31. CASE STUDY (4/9)Association of user-generated types
    32. 32. CASE STUDY (5/9) An invocationhas been made Execution Execution Compile-time warning
    33. 33. CASE STUDY (6/9) Quality metrics aspect
    34. 34. CASE STUDY (7/9) Associatecomponents to Component types Marker interface for ServiceType Association aspect
    35. 35. CASE STUDY (8/9) Verification results
    36. 36. CASE STUDY (9/9) Verification results
    37. 37. OUTLINE• Introduction• Approach• MexADL• Case Study• Conclusions
    38. 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. 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. 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. 41. Questions
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×