MexADL - HADAS Presentation
Upcoming SlideShare
Loading in...5
×
 

MexADL - HADAS Presentation

on

  • 381 views

MexADL presentation for the HADAS group

MexADL presentation for the HADAS group

Statistics

Views

Total Views
381
Views on SlideShare
381
Embed Views
0

Actions

Likes
0
Downloads
18
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Apple Keynote

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • \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

MexADL - HADAS Presentation MexADL - HADAS Presentation Presentation Transcript

  • 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
  • OUTLINE• Introduction• Approach• MexADL• Case Study• Conclusions
  • 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 View slide
  • 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. View slide
  • 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
  • AREAS AND TOPICS
  • 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
  • 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
  • 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.
  • 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
  • SOFTWARE QUALITY (3/4) SQuaRE quality model
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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 implementation ADL xADL 2.0 ADL environment ArchEdit, Archipelago AOP implementation AspectJ Build tool Apache Ant Implementation tools
  • 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.com, 188 classes, 3 programmers, 1 architect
  • 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 Association aspect
  • 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 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.
  • 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.
  • 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
  • Questions