Biography Of Angeliki Cooney | Senior Vice President Life Sciences | Albany, ...
MexADL - HADAS Presentation
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
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 requirements
Chen, 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
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
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
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
28. CASE STUDY (1/9)
• Indvalid: Validate digital tax receipts according to mexican regulations
http://indvalid.com, 188 classes, 3 programmers, 1 architect
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
