Aspect-oriented and

Component Adaptation for

Software Product Lines

Anand Shah.
CWID # 10433548
This topic is made up of three different Terms or Techniques.

2) Aspect Oriented Programming.

3) Component Adaptation.

4) Software Production Line.

 Aspect-oriented Programming

• Aspect-oriented programming is a programming

approach based on the concept of separation of
concerns. An aspect or concern is a concept, goal or
area of interest.
• Concerns or Aspect can be categorized into two types:
core-level and system level concerns.
• Core-level concerns include the business logic, and
system-level concerns include aspects that affect the
entire system such as logging, Authentication,
persistency and performance.
 Aspect-oriented Programming

• Main use of AOP is to get rid of Crosscutting problem

persists in even OOP which affects many modules.
• For example, code handling concerns such as logging,
tracing, or persistence tends to be scattered and tangled
all across the objects of the system.
• Example AspectJ.
 Component Adaptation

• In a component-based software development,

components are considered as black boxes.
They are only described by their interfaces
expressing their visible behaviors. They must be
connected in an appropriate way, through
required and provided interfaces.
• To guarantee interoperability of components, we
must consider each connection of a required
interface with another provided interface.
 Component Adaptation

• In the general cases, to construct a

working system out of components,
Adapters have to be defined. They
connect the required operations and
attributes to the required ones.
• And that is where component adaptation
techniques comes in use.
 Software Production Line

• A software product line (SPL) is a set of

software-intensive systems that share a
common, managed set of features
satisfying the specific needs of a particular
market segment or mission and that are
developed from a common set of core
assets in a prescribed way.
 Software Production Line

• Importance:
• Software product lines are rapidly emerging as a
viable and important software development
paradigm allowing companies to realize order-of-
magnitude improvements in time to market, cost,
productivity, quality, and other business drivers.
Software product line engineering can also
enable rapid market entry and flexible response,
and provide a capability for mass customization.
 Software Production Line

• Success stories:
• Cummins Inc. was able to field more than 1000 separate
products based on just 20 software builds. They can
build and integrate the software for a new diesel engine
in about a week, whereas before, it took a year. Their
production capability allowed them to quickly enter and
dominate the industrial diesel engine market.
• Nokia was able to increase their production of mobile
phones from 5-10 new models per year to over 30 new
models per year.
• HP reported a 400% productivity improvement and a
2-7x time-to-market improvement for a product line of
printers.
 Software Production Line

• The activities involved in the software

product line development process can be
grouped into two stages:
– development of a reusable domain framework
also known as Domain Analysis and
Engineering (DA&E).
– Development of individual applications from
the framework. (Application Engineering)
Software Production Line
 Domain Analysis and Engineering
• DA&E involves activities such as eliciting requirements
and other domain-related information, identification of
common and variable requirements, defining potential
family members and their characteristics, design and
implementation of a domain architecture.
• One of the approaches for DA&E is Requirement
Engineering approach which is highly aspect oriented.
• The RE activities which are Aspect-Oriented are carried
out in the DA&E where requirements and other domain
details are gathered, common and variable requirements
are identified and analyzed, potential member products
are identified and characterized.
Domain Analysis and Engineering
• Standard RE process is
composed of five
activities:
– Requirements capture.
– Requirements analysis.
– Requirements specification
– Requirements validation
– Requirements
management.
• Figure shows the
structural representation
of this approach.
 Domain Analysis and Engineering
• Main use of AOP concepts are used in
Requirement Analysis.
• During this phase with the use of AOP we
have to define.
– Join point: A well-defined point in the
execution of a component. It can be a method
call or execution, an access to an attribute, or
the execution of a constructor.
– Pointcut: A mechanism that encapsulate join
points. It can be compose of one or more join
point.
 Domain Analysis and Engineering
– Advice: is a specifies the action (i.e., code)
that must take place at a certain pointcut (i.e.,
a group of join points). With both abstractions
mentioned above, advice give developer the
ability to implement crosscutting concerns.
There are three types of advice:
• before: The code declared is executed before the
join point.
• after: The code declared is executed after the join
point.
• around: The code declared is executed instead of
the one in the join point.
 Domain Analysis and Engineering
– Inter-type declaration: mechanism allows developer to
crosscut concerns in a static way. It permits
alterations to classes and inheritance hierarchies from
outside the original class definition. We enumerate
below the types of possible changes through Inter-
type declaration:
• Add members (methods, constructors, fields) to types
(including other aspects).
• Add concrete implementation to interfaces.
• Declare that types extend new types or implement new
interfaces.
• Declare aspect precedence.
• Declare custom compilation errors or warnings.
• Convert checked exceptions to unchecked.
 Domain Analysis and Engineering
– Aspect: is the container for the encapsulation
of pointcuts, advice code, and inter-type
declaration. Acting like a Java classes, it can
contain its own attributes and methods.
 Application Engineering
• In the application development stage,
member products are developed from the
reusable domain framework.
• This is where we have to use Component
adaptation techniques to make interface
(Adapters) Between framework and
application.
• Main problems and complexity we have to
face in this are shown in fig.
 Application Engineering

A hierarchy of interface models, which orders interface properties according to their

specification complexity, supports the identification and elimination of different types
of component mismatches
 Application Engineering
• We have to generate different patterns of
adaptors according to the interface we want.
Many patterns are available as per
requirements. Like.
– Adaptor
– Decorator
– Interceptor
– Wrapper Façade
– Bridge
– Microkernel
– Mediator
 Application Engineering
• Some Extra-Functional Adaptation Patterns are.
– Proxy
– Component Replication
– Process Pair
– Retransmission
– Caching
– Pessimistic Offline Lock
– Unit of Work
• Details:
 Conclusion
• Aspect-oriented Programming and
Component Adaptation techniques can be
very useful to improve quality and usability
of Software Production Line.
 References
• http://www.voelter.de/data/pub/VoelterGroher_SPLEwithAOan
• http://www.iro.umontreal.ca/~sahraouh/qaoose2005/paper4.pdf
• www.volantec.biz/Untangle_AOP.ppt
• http://ieeexplore.ieee.org/iel5/8501/26873/01194788.pdf
• http://research.microsoft.com/~cszypers/events/WCOP2006/w
• http://
www.wsmo.org/papers/presentations/preprintonline.pdf
• http://www.sei.cmu.edu/str/descriptions/deda.html