1 Model Interface Implementation for Two-Way Obliviousness in Aspect- Oriented Modeling Presented by Wuliang Sun Department of Computer Science Baylor University
Dec 24, 2015
1
Model Interface Implementation for Two-Way Obliviousness in Aspect-Oriented Modeling
Presented by Wuliang SunDepartment of Computer ScienceBaylor University
2
Outline Aspect-Oriented Software Development (AOSD)
Why AOSD Quantification and Obliviousness in AOSD
Aspect-Oriented Modeling (AOM) Existing Approaches for AOM
Motivation One-Way Obliviousness vs Two-Way Obliviousness
Background Aspects in MATA
Our Two-Way Obliviousness Approach Model Interface and Badge
Conclusion and Future Work
3
Why AOSD? Decompose complex systems into different
concerns Affect modularization Manage interactions between concerns
AOSD: Aspect-Oriented Software Development
Scattering The concern is spread
over multiple modules Tangling
The concern is intermixed with other concerns
http://en.wikipedia.org/wiki/Aspect-oriented_software_development
4
Quantification and Obliviousness
Quantification Refer to and modify the
disparate elements of the system
Obliviousness Specify the system without
the effort to allow the quantification
Aspects
Base
quantify over
“Just program like you always do, and we’ll be able to add the aspects later” by Filman and Friedman (p.6, Aspect-oriented programming is quantification and obliviousness, 2000)
5
Obliviousness in AOSD One-Way Obliviousness
VS Two-Way
ObliviousnessAspects
Base
quantify over
Aspects
Base
quantify over
Interface
implements
6
Approaches to Realize Aspect-Orientation
Extensions to existing languages such as Java (e.g., Hyper/J, AspectJ)
Frameworks for introducing aspect orientation without changing existing languages (e.g., Spring, JBoss)
Modeling with UML (e.g., Weavr, MATA)
AOP
AOM
AOSD
7
Distribution
« Service Provider Manager »
Notification Alternate Manager
« Recovery Block Manager »
ComplaintRecovery Block
Manager
« Service Provider
Manager »
Notification Manager
« Service Provider Manager »
Complaint Alternate Manager
« Service Provider
Manager »
Complaint Manager
« Acceptance Test Manager »
Notification Acceptance Test
Manager
« Acceptance Test Manager »
Complaint Acceptance Test
Manager
« Recovery Block Manager »
NotificationRecovery Block
Manager
« Client »
User Citizen Manager
Fault tolerance
Roles
ActivitiesViews
Contexts
Security
Functional behavior
Bookstate : StringUser
borrow
return
deliver
setDamaged
reserve
Use case model
PlatformModel Design
Model
Product Code
Aspect-Oriented “Modeling”
8
Existing Approaches for AOM
Motorola’s WEAVR Support state machine Support two-way obliviousness
MATA: Modeling Aspects using a Transformation Approach Support class diagram, sequence
diagram and state machine Support one-way obliviousness
10
Aspect Composition and Analysis in MATA
UML2 Specification
RSMAGG System
Input
Output
AGG Type Graph
MATA Bridge
Input
OutputInput
Output
Input
Output
Rational Software Modeler (RSM)Attributed Graph Grammar (AGG)
11
MATA Approach Evaluation Advantage
Support class diagram, sequence diagram and state machine
Support structural and behavioral aspects Limitation
No interface for two-way obliviousness Limited supports on design-level model
elements Some model elements are not preserved
during the composition
12
Model Interfaces and Badges Model Interface: specify the structural features that
a concrete model may implement Badge: relate model interface elements to
concrete model elements
15
Conclusion and Future Work Two-way obliviousness supported Diagram type supported
Class, sequence and state machine diagram Tool support
Modeling Analysis Weaving
Enhancement Well supports on design-level model elements Preserve the important model elements during
the composition
16
Acknowledgements
Mentor: Dr. Eunjee Song Nathan V. Roberts, UT Austin Dr. Jon Whittle, Lancaster University