Published on

MexADL thesis presentation

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  1. 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. 2. OUTLINE• Introduction• Approach• MexADL• Case Study• Conclusions 2
  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% 3
  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. 4
  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 5
  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 7
  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 8
  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. 9
  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 10
  11. 11. SOFTWARE QUALITY (3/4) SQuaRE quality model 11
  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 12
  13. 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. 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. 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. 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. 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. 18. OUTLINE• Introduction• Approach• MexADL• Case Study• Conclusions 18
  19. 19. APPROACH (1/4) 19
  20. 20. APPROACH (2/4) 20
  21. 21. APPROACH (3/4)Use cases for the verification approach 21
  22. 22. APPROACH (4/4) Maintainability quality metrics 22
  23. 23. OUTLINE• Introduction• Approach• MexADL• Case Study• Conclusions 23
  24. 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. 25. MEXADL (2/8) External metrics tools 25
  26. 26. MEXADL (3/8)xADL 2.0 extension (Characteristic) 26
  27. 27. MEXADL (4/8)xADL 2.0 extension (Sub-characteristics) 27
  28. 28. MEXADL (5/8)xADL 2.0 extension (Component) 28
  29. 29. MEXADL (6/8)xADL 2.0 extension (Java implementation) 29
  30. 30. MEXADL (7/8) Definition 30
  31. 31. MEXADL (8/8) Verification 31
  32. 32. OUTLINE• Introduction• Approach• MexADL• Case Study• Conclusions 32
  33. 33. CASE STUDY (1/7)• SQL query optimizer designed for distributed databases xADL 2.0 description 33
  34. 34. CASE STUDY (2/7) Quality metrics values 34
  35. 35. CASE STUDY (3/7) Association of quality metrics 35
  36. 36. CASE STUDY (4/7) Layer Spring Annotation Layer Java package patternController 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. 37. CASE STUDY (5/7)Valid interactions aspect 37
  38. 38. CASE STUDY (6/7) Quality metrics aspect 38
  39. 39. CASE STUDY (7/7) Verification results 39
  40. 40. OUTLINE• Introduction• Approach• MexADL• Case Study• Conclusions 40
  41. 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. 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. 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. 44. FUTURE WORK• Implementationsfor other environments such as C++ or the .NET framework• Consideration for dynamic structures of software systems 44
  45. 45. Questions 45