Your SlideShare is downloading. ×
MexADL - HADAS Presentation
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

MexADL - HADAS Presentation

288

Published on

MexADL presentation for the HADAS group

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
288
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
19
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
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

    • 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 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. 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 invocationhas been made Execution Execution Compile-time warning
    • 33. CASE STUDY (6/9) Quality metrics aspect
    • 34. CASE STUDY (7/9) Associatecomponents 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

    ×