MexADL
-
Upload
jccastrejon -
Category
Technology
-
view
299 -
download
0
description
Transcript of MexADL
![Page 1: MexADL](https://reader033.fdocuments.in/reader033/viewer/2022052907/558fce1d1a28ab6d7f8b45dc/html5/thumbnails/1.jpg)
Juan Carlos CastrejónITESM-CCM
An Approach for the Maintainability Verification of Software Systems based on Aspect Oriented Programming and
Architecture Description Languages
1
![Page 2: MexADL](https://reader033.fdocuments.in/reader033/viewer/2022052907/558fce1d1a28ab6d7f8b45dc/html5/thumbnails/2.jpg)
OUTLINE
• Introduction
• Approach
•MexADL
• Case Study
• Conclusions
2
![Page 3: MexADL](https://reader033.fdocuments.in/reader033/viewer/2022052907/558fce1d1a28ab6d7f8b45dc/html5/thumbnails/3.jpg)
PROBLEM (1/3)
• As a 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
![Page 4: MexADL](https://reader033.fdocuments.in/reader033/viewer/2022052907/558fce1d1a28ab6d7f8b45dc/html5/thumbnails/4.jpg)
PROBLEM (2/3)
Maintainability software development problem factorsLack of traceability
Changes are not adequately documentedDocumentation is obscure or untrustworthy
Lack of adherence to programming standardsLack 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.
4
![Page 5: MexADL](https://reader033.fdocuments.in/reader033/viewer/2022052907/558fce1d1a28ab6d7f8b45dc/html5/thumbnails/5.jpg)
PROBLEM (3/3)
• In regard 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
![Page 6: MexADL](https://reader033.fdocuments.in/reader033/viewer/2022052907/558fce1d1a28ab6d7f8b45dc/html5/thumbnails/6.jpg)
AREAS AND TOPICS
6
![Page 7: MexADL](https://reader033.fdocuments.in/reader033/viewer/2022052907/558fce1d1a28ab6d7f8b45dc/html5/thumbnails/7.jpg)
• This discipline 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 (1/2)
7
![Page 8: MexADL](https://reader033.fdocuments.in/reader033/viewer/2022052907/558fce1d1a28ab6d7f8b45dc/html5/thumbnails/8.jpg)
• 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 ARCHITECTURE (2/2)
8
![Page 9: MexADL](https://reader033.fdocuments.in/reader033/viewer/2022052907/558fce1d1a28ab6d7f8b45dc/html5/thumbnails/9.jpg)
• 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(1/4)
9
![Page 10: MexADL](https://reader033.fdocuments.in/reader033/viewer/2022052907/558fce1d1a28ab6d7f8b45dc/html5/thumbnails/10.jpg)
•New generation 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(2/4)
10
![Page 11: MexADL](https://reader033.fdocuments.in/reader033/viewer/2022052907/558fce1d1a28ab6d7f8b45dc/html5/thumbnails/11.jpg)
SOFTWARE QUALITY(3/4)
SQuaRE quality model
11
![Page 12: MexADL](https://reader033.fdocuments.in/reader033/viewer/2022052907/558fce1d1a28ab6d7f8b45dc/html5/thumbnails/12.jpg)
SOFTWARE QUALITY(4/4)
•Maintainability is 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
![Page 13: MexADL](https://reader033.fdocuments.in/reader033/viewer/2022052907/558fce1d1a28ab6d7f8b45dc/html5/thumbnails/13.jpg)
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
![Page 14: MexADL](https://reader033.fdocuments.in/reader033/viewer/2022052907/558fce1d1a28ab6d7f8b45dc/html5/thumbnails/14.jpg)
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
![Page 15: MexADL](https://reader033.fdocuments.in/reader033/viewer/2022052907/558fce1d1a28ab6d7f8b45dc/html5/thumbnails/15.jpg)
• 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
ASPECT ORIENTED PROGRAMMING (3/3)
15
![Page 16: MexADL](https://reader033.fdocuments.in/reader033/viewer/2022052907/558fce1d1a28ab6d7f8b45dc/html5/thumbnails/16.jpg)
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
![Page 17: MexADL](https://reader033.fdocuments.in/reader033/viewer/2022052907/558fce1d1a28ab6d7f8b45dc/html5/thumbnails/17.jpg)
HYPOTHESIS
• The maintainability 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
![Page 18: MexADL](https://reader033.fdocuments.in/reader033/viewer/2022052907/558fce1d1a28ab6d7f8b45dc/html5/thumbnails/18.jpg)
OUTLINE
• Introduction
• Approach
•MexADL
• Case Study
• Conclusions
18
![Page 19: MexADL](https://reader033.fdocuments.in/reader033/viewer/2022052907/558fce1d1a28ab6d7f8b45dc/html5/thumbnails/19.jpg)
APPROACH (1/4)
19
![Page 20: MexADL](https://reader033.fdocuments.in/reader033/viewer/2022052907/558fce1d1a28ab6d7f8b45dc/html5/thumbnails/20.jpg)
APPROACH (2/4)
20
![Page 21: MexADL](https://reader033.fdocuments.in/reader033/viewer/2022052907/558fce1d1a28ab6d7f8b45dc/html5/thumbnails/21.jpg)
APPROACH (3/4)
Use cases for the verification approach
21
![Page 22: MexADL](https://reader033.fdocuments.in/reader033/viewer/2022052907/558fce1d1a28ab6d7f8b45dc/html5/thumbnails/22.jpg)
APPROACH (4/4)
Maintainability quality metrics
22
![Page 23: MexADL](https://reader033.fdocuments.in/reader033/viewer/2022052907/558fce1d1a28ab6d7f8b45dc/html5/thumbnails/23.jpg)
OUTLINE
• Introduction
• Approach
•MexADL
• Case Study
• Conclusions
23
![Page 24: MexADL](https://reader033.fdocuments.in/reader033/viewer/2022052907/558fce1d1a28ab6d7f8b45dc/html5/thumbnails/24.jpg)
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
![Page 25: MexADL](https://reader033.fdocuments.in/reader033/viewer/2022052907/558fce1d1a28ab6d7f8b45dc/html5/thumbnails/25.jpg)
MEXADL (2/8)
External metrics tools
25
![Page 26: MexADL](https://reader033.fdocuments.in/reader033/viewer/2022052907/558fce1d1a28ab6d7f8b45dc/html5/thumbnails/26.jpg)
MEXADL (3/8)
xADL 2.0 extension (Characteristic)
26
![Page 27: MexADL](https://reader033.fdocuments.in/reader033/viewer/2022052907/558fce1d1a28ab6d7f8b45dc/html5/thumbnails/27.jpg)
MEXADL (4/8)
xADL 2.0 extension (Sub-characteristics)
27
![Page 28: MexADL](https://reader033.fdocuments.in/reader033/viewer/2022052907/558fce1d1a28ab6d7f8b45dc/html5/thumbnails/28.jpg)
MEXADL (5/8)
xADL 2.0 extension (Component)
28
![Page 29: MexADL](https://reader033.fdocuments.in/reader033/viewer/2022052907/558fce1d1a28ab6d7f8b45dc/html5/thumbnails/29.jpg)
MEXADL (6/8)
xADL 2.0 extension (Java implementation)
29
![Page 30: MexADL](https://reader033.fdocuments.in/reader033/viewer/2022052907/558fce1d1a28ab6d7f8b45dc/html5/thumbnails/30.jpg)
MEXADL (7/8)
Definition
30
![Page 31: MexADL](https://reader033.fdocuments.in/reader033/viewer/2022052907/558fce1d1a28ab6d7f8b45dc/html5/thumbnails/31.jpg)
MEXADL (8/8)
Verification
31
![Page 32: MexADL](https://reader033.fdocuments.in/reader033/viewer/2022052907/558fce1d1a28ab6d7f8b45dc/html5/thumbnails/32.jpg)
OUTLINE
• Introduction
• Approach
•MexADL
• Case Study
• Conclusions
32
![Page 33: MexADL](https://reader033.fdocuments.in/reader033/viewer/2022052907/558fce1d1a28ab6d7f8b45dc/html5/thumbnails/33.jpg)
CASE STUDY (1/7)
• SQL query optimizer designed for distributed databases
xADL 2.0 description
33
![Page 34: MexADL](https://reader033.fdocuments.in/reader033/viewer/2022052907/558fce1d1a28ab6d7f8b45dc/html5/thumbnails/34.jpg)
CASE STUDY (2/7)
Quality metrics values
34
![Page 35: MexADL](https://reader033.fdocuments.in/reader033/viewer/2022052907/558fce1d1a28ab6d7f8b45dc/html5/thumbnails/35.jpg)
CASE STUDY (3/7)
Association of quality metrics35
![Page 36: MexADL](https://reader033.fdocuments.in/reader033/viewer/2022052907/558fce1d1a28ab6d7f8b45dc/html5/thumbnails/36.jpg)
CASE STUDY (4/7)Layer Spring Annotation
Controller org.springframework.stereotype.Controller
Service org.springframework.stereotype.Service
Repository org.springframework.stereotype.Repository
Layer Java package pattern
Model mx.itesm.ddb.model..*
Util mx.itesm.ddb.util..*
Association of user-generated types36
![Page 37: MexADL](https://reader033.fdocuments.in/reader033/viewer/2022052907/558fce1d1a28ab6d7f8b45dc/html5/thumbnails/37.jpg)
CASE STUDY (5/7)
Valid interactions aspect
37
![Page 38: MexADL](https://reader033.fdocuments.in/reader033/viewer/2022052907/558fce1d1a28ab6d7f8b45dc/html5/thumbnails/38.jpg)
CASE STUDY (6/7)
Quality metrics aspect
38
![Page 39: MexADL](https://reader033.fdocuments.in/reader033/viewer/2022052907/558fce1d1a28ab6d7f8b45dc/html5/thumbnails/39.jpg)
CASE STUDY (7/7)
Verification results
39
![Page 40: MexADL](https://reader033.fdocuments.in/reader033/viewer/2022052907/558fce1d1a28ab6d7f8b45dc/html5/thumbnails/40.jpg)
OUTLINE
• Introduction
• Approach
•MexADL
• Case Study
• Conclusions
40
![Page 41: MexADL](https://reader033.fdocuments.in/reader033/viewer/2022052907/558fce1d1a28ab6d7f8b45dc/html5/thumbnails/41.jpg)
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
• The set of source code quality metrics is not fixed, and could be changed according to the needs of particular projects
• This flexibility would also come in handy in the event of changes to the definition of the ISO/IEC SQuaRE quality model.
41
![Page 42: MexADL](https://reader033.fdocuments.in/reader033/viewer/2022052907/558fce1d1a28ab6d7f8b45dc/html5/thumbnails/42.jpg)
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
![Page 43: MexADL](https://reader033.fdocuments.in/reader033/viewer/2022052907/558fce1d1a28ab6d7f8b45dc/html5/thumbnails/43.jpg)
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
![Page 44: MexADL](https://reader033.fdocuments.in/reader033/viewer/2022052907/558fce1d1a28ab6d7f8b45dc/html5/thumbnails/44.jpg)
FUTURE WORK
• Implementations for other environments such as C++ or the .NET framework
• Consideration for dynamic structures of software systems
44
![Page 45: MexADL](https://reader033.fdocuments.in/reader033/viewer/2022052907/558fce1d1a28ab6d7f8b45dc/html5/thumbnails/45.jpg)
Questions
45