Uploaded on

MexADL thesis presentation

MexADL thesis presentation

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
273
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
2
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

Transcript

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