Feature Modeling Based Multi-Paradigm Design for AspectJ Valentino Vrani ´ c www.fiit.stuba.sk/˜vranic, [email protected]Institute of Informatics and Software Engineering Faculty of Informatics and Information Techologies Slovak University of Technology L 3 S Info-Lunch Presentation — October 1, 2004
48
Embed
Feature Modeling Based Multi-Paradigm Design for AspectJvranic/pub/L3S.pdf · T. S. Kuhn. The Structure of Scientific Revolutions. University of Chicago Press, Chicago, 1970. b R.
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Feature Modeling BasedMulti-Paradigm Design for AspectJ
aT. S. Kuhn. The Structure of Scientific Revolutions. University of Chicago Press, Chicago, 1970.
bR. W. Floyd. The paradigms of programming. Communications of the ACM, 22(8), 1979.
cJ. O. Coplien. Multi-Paradigm Design for C++. Addison-Wesley, 1999.
Feature Modeling Based Multi-Paradigm Design for AspectJ – p.3/30
Small-Scale Paradigms
Programming language perspective
Configurations of commonality and variability
Scope, commonality, variability, and relationship(SCVR) analysisa
An example: the procedure paradigmScope: a collection of similar code fragments, each
to be replaced by a call to some new procedureCommonality: the code common to all fragmentsVariability: the “uncommon” code; variabilities are
handled by procedure parameters or custom code
aJ. O. Coplien et al. Commonality and variability in software engineering. IEEE Software, 15(6), Nov. 1998.
Feature Modeling Based Multi-Paradigm Design for AspectJ – p.4/30
Multi-Paradigm Software Development
Two issues:Making multiple paradigms available:multi-paradigm languages (e.g., Ledaa)Choosing an appropriate paradigm for theproblem being solved: multi-paradigm design
Multi-paradigm design methodsMulti-paradigm design method for Ledab
Multi-paradigm design (for C++)c
aT. A. Budd. Multiparadigm Programming in Leda. Addison-Wesley, 1995.
bC. D. Knutson et al. Multiparadigm design of a simple relational database. ACM SIGPLAN Notices,
35(12), Dec. 2000.c
J. O. Coplien. Multi-Paradigm Design for C++. Addison-Wesley, 1999.
Feature Modeling Based Multi-Paradigm Design for AspectJ – p.5/30
Multi-Paradigm Design (MPD)
MPD (for C++)a treats the solution domain in thesame manner as the application domain (SCVRanalysis)
Both application and solution domain models areexpressed mainly by tables
Transformational analysis is preformed as a mappingbetween the tables
Code design yields a code skeleton
aJ. O. Coplien. Multi-Paradigm Design for C++. Addison-Wesley, 1999.
Feature Modeling Based Multi-Paradigm Design for AspectJ – p.6/30
application to solution domain mapping(paradigm instances)
code skeleton
application domain related information solution domain related information
Feature Modeling Based Multi-Paradigm Design for AspectJ – p.15/30
Paradigm Modeling in MPDFM
Identification of paradigmsDirectly and indirectly usable paradigmsHierarchy of paradigms
Identification of binding timesA sequence of binding times provided by thesolution domainUsual binding times: source, compile, link, load,and run timeAn AspectJ example: the method body—run timebinding
First-level paradigm model
Modeling individual paradigms
Feature Modeling Based Multi-Paradigm Design for AspectJ – p.16/30
First-Level Paradigm Model
The solution concept
Consists of directly usable paradigmsSubconcepts of the solution conceptIntroduced as concept references (usually inplural)Their variability and binding time should bedetermined
Feature Modeling Based Multi-Paradigm Design for AspectJ – p.17/30
Modeling Individual Paradigms
Each paradigm is introduced in a separate featurediagram
Solution domain conceptsMay reference each other
Auxiliary conceptsConcepts referenced by paradigmsBut not considered to be paradigms themselves
Binding time (variable features)
Instantiation is modeled by features
Feature Modeling Based Multi-Paradigm Design for AspectJ – p.18/30
Structures and Relationships
Structural paradigms correspond to main constructs(structures) of the programing language
Relationship paradigms are about the relationshipsbetween programing language structures
An application domain concept node intransformational analysis
Can match with the root of a structural paradigmCannot match with the root of a relationshipparadigm
Feature Modeling Based Multi-Paradigm Design for AspectJ – p.19/30
AspectJ Aspect-Oriented Paradigms
Aspect-oriented programmingModularization of crosscutting concernsUseful for debugging, tracing, and synchronizationin generalApplication-specific aspects
The aspect paradigm:A structural paradigm (modularization)A container of advices, pointcuts, and inter-typedeclarations; relationship paradigms (crosscuttingconcerns)
Feature Modeling Based Multi-Paradigm Design for AspectJ – p.20/30
AspectAspect
Inter-type Declarations(R)
Advices(R)
FieldsMethods(R)
privileged
Instantiation policy
singletonper object
per control flow
Classes(R)
Aspects(R)
Interfaces(R)
Name
Inheritances(R)
Pointcuts(R)
finalScope
Access(R)
abstract
Pointcut(R)
Pointcut(R)
static
whole
below
Access
private protected public package
Constraint:
abstract ∨ final
Feature Modeling Based Multi-Paradigm Design for AspectJ – p.21/30
Advice and PointcutAdvice
aroundafter
throwingreturning
before
Body
Pointcut(R)
context
Return value type
Type(R)Type(R) Type(R)
Pointcut
context
BodyName
Static join points Dynamic join points
abstractfinal
Access(R)
Join points Join points
compile time run time
Constraints:
1. abstract ∨ Body
2. Access ⇒Name
Type
Class(R)Interface(R) Aspect(R)
Feature Modeling Based Multi-Paradigm Design for AspectJ – p.22/30
Transformational Analysis in MPDFM
Based on paradigm instantiation over applicationdomain concepts at source time
One application domain concept considered at a time1. Determine the structural paradigm of the
application domain concept2. Determine the corresponding relationship
paradigm for each unmapped relationship in it
A creative process
Feature Modeling Based Multi-Paradigm Design for AspectJ – p.23/30
Paradigm Instantiation in MPDFM
Concept instantiation in MPDFM
Viewed as concept specializationConcept instances represented by featurediagramsTakes into account binding time
A bottom-up instantiation
Inclusion of paradigm nodes stipulated by themapping of the application domain concept nodes
Conceptual correspondenceBinding correspondence
Feature Modeling Based Multi-Paradigm Design for AspectJ – p.24/30
OFeature Modeling Based Multi-Paradigm Design for AspectJ – p.25/30
Transformational Analysis ExampleAspect
Advices
Instantiation policy
single
NameScope
Access
Debugging Code.File.reading
FileDebug
Debugging Code.File.writing
Advice
after
returning
Body
Advice 1Advice 2
Advice
before
Body
Pointcut
calls to File.read
context
Body
Dynamic join points
final File object
package
Pointcut
calls to File.write
context
Bodyfinal
Debugging Code.File
Join points
Dynamic join points
Join points
contextcontext
File object File object
File object
Feature Modeling Based Multi-Paradigm Design for AspectJ – p.25/30
Code Skeleton Design
Performed by traversing paradigm instances
Structural paradigm instances first
An example: the file debugging code aspectaspect FileDC {
before(File f):
target(f) && call(* File.read(..)) {
. . .
}
after(File f):
target(f) && call(* File.write(..)) {
. . .
}
}
Feature Modeling Based Multi-Paradigm Design for AspectJ – p.26/30
Aspect-Oriented Modeling and MPDFM
Aspect-oriented languages differ in essentialaspect-oriented mechanisms
Hard to generalize them for modeling purposes
MPDFM application domain feature modelsAbstract from any implementation mechanismsIndependent of a solution domain feature model
AspectJ paradigm model enables to identify aspectsearly in the design
Feature Modeling Based Multi-Paradigm Design for AspectJ – p.27/30
Summary (1)
Multi-paradigm design with feature modeling(MPDFM):
Both application and solution domain representedas feature modelsTransformational analysis based fully on featuremodeling
MPDFM for AspectJAspectJ paradigm modelDemonstrated in the text editing buffertransformational analysisSuccessfully applied to the domain of featuremodeling
Feature Modeling Based Multi-Paradigm Design for AspectJ – p.28/30
Summary (2)
Reuse of application and solution domain featuremodels
Improvements of feature modeling:Concept instantiation with respect to instantiationtimeParameterization in feature modelsConstraints and default dependency rules aslogical expressionsConcept referencesA dot convention to enable referring to conceptsand features unambiguouslyA parameterized concept for representingcardinality in feature modeling
Feature Modeling Based Multi-Paradigm Design for AspectJ – p.29/30
Further Work
Partial feature model reuseOverlapping domainsGeneralization of similar concepts from differentdomains
MPDFM specialization to solution domains other thanprogramming languages
Feature Modeling Based Multi-Paradigm Design for AspectJ – p.30/30