Kein Folientitel

1
Product Line Implementation
Variability in Code and Models
Markus Voeltervoelter_at_acm.orghttp//www.voelter.
de
This work is supported by
2
About me

• Markus Völter
• voelter_at_acm.org
• www.voelter.de

• Independent Consultant
• Based out of Göppingen, Germany
• Focus on
• Model-Driven SoftwareDevelopment
• Software Architecture
• Product Lines

3
C O N T E N T S

• PLE Concepts
• Software System Families
• Process and Terminology
• Variability
• Feature Modeling
• Binding Times
• Classical PLE Implementation
• Source time
• Compile time
• Deployment/Configuration time
• Link time
• Run time
• MDD-AO-PLE
• What is MDD
• What is AO
• What is MDD-AO-PLE
• More Terms and Concepts

• MDD-AO Implementation
• Intro to Case Study
• The Various (Meta-)Models
• Meta Model Modularization
• Terminology M2M Transformations
• Terminology Model Extension
• Libraries
• An Example House
• Tracing
• Orthogonal Variability
• Transformation and Template AO
• AO Modeling
• Code Level Aspects
• Negative Variability
• Testing
• Enforcing Conventions
• Product Line Evolution
• Summary

4
C O N T E N T S

• PLE Concepts
• Software System Families
• Process and Terminology
• Variability
• Feature Modeling
• Binding Times
• Classical PLE Implementation
• Source time
• Compile time
• Deployment/Configuration time
• Link time
• Run time
• MDD-AO-PLE
• What is MDD
• What is AO
• What is MDD-AO-PLE
• More Terms and Concepts

• MDD-AO Implementation
• Intro to Case Study
• The Various (Meta-)Models
• Meta Model Modularization
• Terminology M2M Transformations
• Terminology Model Extension
• Libraries
• An Example House
• Tracing
• Orthogonal Variability
• Transformation and Template AO
• AO Modeling
• Code Level Aspects
• Negative Variability
• Testing
• Enforcing Conventions
• Product Line Evolution
• Summary

5
Software System Families

• Typically, MDD makes most sense in the context of
  software system families because developing
  modeling environments, generators, translators,
  etc. can be a lot of work and it pays only if
  reused.
• What is a software system familiy?We consider a
  set of programs to constitute a family whenever
  it is worthwhile to study programs from the set
  by first studying the common properties of the
  set and then determining the special properties
  of the individual family members.
  Definition by Parnas

6
Examples for Software System Families

• A set of projects in the same domain (banking,
  telecom switching, automotive diagnosis).
• You might be able to generate recurring business
  logic from models.
• A set of artifacts based on the same
  infrastucture (such as EJB) in one project.
• Here, you might be able to to generate all the
  infrastructure-specific code around manually
  implemented business logic.
• you have some specific business logic that you
  want to run on different platforms.
• You might be able to generate platform-specific
  implementation code from the models (this is the
  focus of MDA)
• a set of artifacts based on the same modelling
  paradigm, such as state chart.
• You might be able to generate the complete
  implementation based on the model and its
  predefined mapping to lower-level implementations.

7
C O N T E N T S

• PLE Concepts
• Software System Families
• Process and Terminology
• Variability
• Feature Modeling
• Binding Times
• Classical PLE Implementation
• Source time
• Compile time
• Deployment/Configuration time
• Link time
• Run time
• MDD-AO-PLE
• What is MDD
• What is AO
• What is MDD-AO-PLE
• More Terms and Concepts

• MDD-AO Implementation
• Intro to Case Study
• The Various (Meta-)Models
• Meta Model Modularization
• Terminology M2M Transformations
• Terminology Model Extension
• Libraries
• An Example House
• Tracing
• Orthogonal Variability
• Transformation and Template AO
• AO Modeling
• Code Level Aspects
• Negative Variability
• Testing
• Enforcing Conventions
• Product Line Evolution
• Summary

8
Product Line Engineering

• Domain Scoping
• Variability Analysis
• Domain Structuring
• Define common architecture
• Define Production Plan
• Define Building Blocks
• Components
• DSLs Generators
• Production Process

9
Domain Analysis

• Goal A domain model (aka metamodel)
• Scoping defines, what is part of the domain, and
  what is not (defines the range of possible
  products of the family)
• A common vocabulary defines the terms in which
  the domain can be described
• A result of this process is also the knowledge of
  whether the domain is mature, or not (are there
  more commonalities than differences?)
• The commonalities and the differences between
  different products in the domain have to be
  defined ? Variability Analysis

10
Problem/Solution Space Application/Software
Domain

• Problem space and solution space are always
  relative to a transformation/generation step and
  are therefore relative.
• Ones solution space can be somebody elses
  problem space.
• For example, transformation/generation steps can
  be cascaded.
• The application domain contains concepts that are
  relevant to the customer/business expert
• The software domain deals with software
  development issues.
• Those two are absolute.

11
Core Assets Platform

• Core assets are everything that should be reused
  within the products of the product line or for
  producing products.
• Models
• Generators and transformations
• Software components
• Domain specification
• Requirements documents for the domain
• test plans
• project plans
• documentation.
• Not all of the core assets are used in every
  product.
• The platform consists of all core assets that are
  used as part of the built product(s). Typically,
  these are runtime artifacts.

12
Various Architectures

• Domain Architecture is a synonym to Core Assets.
• Target Architecture is the architecture of the
  products built with the help of the domain
  architecture.
• The platform is part of the target architecture.
• Product Line Architecture is very vaguely
  defined. We define it to be the sum of domain
  architecture and target architecture.

13
C O N T E N T S

• PLE Concepts
• Software System Families
• Process and Terminology
• Variability
• Feature Modeling
• Binding Times
• Classical PLE Implementation
• Source time
• Compile time
• Deployment/Configuration time
• Link time
• Run time
• MDD-AO-PLE
• What is MDD
• What is AO
• What is MDD-AO-PLE
• More Terms and Concepts

• MDD-AO Implementation
• Intro to Case Study
• The Various (Meta-)Models
• Meta Model Modularization
• Terminology M2M Transformations
• Terminology Model Extension
• Libraries
• An Example House
• Tracing
• Orthogonal Variability
• Transformation and Template AO
• AO Modeling
• Code Level Aspects
• Negative Variability
• Testing
• Enforcing Conventions
• Product Line Evolution
• Summary

14
Application Engineering vs. Domain Engineering

• Domain engineering is the sub process that is
  concerned with developing core assets
• Application engineering instantiates one product
  of the product line using the reusable assets
  developed in domain engineering.

15
Variability Analysis

• Variability analysis discovers the variable and
  fixed parts of a product in a domain. Parts can
  be
• Structural or behavioral
• Functional or non-functional (technical)
• Modularized or aspectual
• To define variable parts, we need to have a
  commonality base a base platform, a common
  architecture
• There are two kinds of variability
• positive variability add something (optional)
• negative variability removes something
  (essential)
• Another classification structural vs.
  non-structural var.

16
Structural vs. Non-Structural Variability

• Structural VariationsExample Metamodel
• Non-Structural VariationsExample Feature
  ModelsDynamic Size, ElementType int, Counter,
  ThreadsafeStatic Size (20), ElementType
  StringDynamic Size, Speed-Optimized, Bounds
  Check

• Based on this sample metamodel, you can build a
  wide variety of models

17
Rountine Configuration vs. Creative Contruction

• This slide (adopted from K. Czarnecki) is
  important for the selection of DSLs in the
  context of MDSD in general
• The more you can move your DSL form to the
  configuration side, the simpler it typically
  gets.
• We will see why this is especially important for
  behavior modelling.

18
Negative vs. Positive Variability

• Negative Variability (a) takes optional parts
  away from an overall whole
• Challenge the overall whole can become really
  big an unmanageable
• Positive Variability (b) adds optional parts to a
  minimal core.
• Challenge How to specify where and how to join
  the optional parts to the minimal core

19
C O N T E N T S

• PLE Concepts
• Software System Families
• Process and Terminology
• Variability
• Feature Modeling
• Binding Times
• Classical PLE Implementation
• Source time
• Compile time
• Deployment/Configuration time
• Link time
• Run time
• MDD-AO-PLE
• What is MDD
• What is AO
• What is MDD-AO-PLE
• More Terms and Concepts

• MDD-AO Implementation
• Intro to Case Study
• The Various (Meta-)Models
• Meta Model Modularization
• Terminology M2M Transformations
• Terminology Model Extension
• Libraries
• An Example House
• Tracing
• Orthogonal Variability
• Transformation and Template AO
• AO Modeling
• Code Level Aspects
• Negative Variability
• Testing
• Enforcing Conventions
• Product Line Evolution
• Summary

20
Feature Modeling

• As a consequence of the domain analysis and
  before defining a concrete metamodel, usually, a
  feature modelling phase makes sense to
  systematically define optional and mandatory
  features.
• A feature model describes the (sub-)features of a
  concept, subfeatures can be
• Mandatory
• Optional
• Alternative
• N of M
• A feature can represent some kind of component or
  an aspect.
• A feature model can be multi-dimensional
• A graphical notation exists feature diagrams

21
Example Feature Diagram

• Example products
• An aircraft with a low wing, piston engine and
  made of metal, wood and cloth Robin DR-400
• An aircraft with shoulder wing, no engine and
  made of plastic ASW-27
• An aircraft with low wing, jet engine(s) and
  made of metal Airbus A320

22
More Feature Models Communication
23
Feature Diagrams contd

• They can contain constraints on the combinations
  of features
• They can define names for specific combinations
  of features feature groups
• Features can be open additional subfeatures can
  be added
• Features can be incomplete the subfeatures are
  not yet defined
• Multiplicity of subfeatures can be added
• And more...

24
Variation Points

• A variation point is a location in the product
  line, where a customization for a specific
  product can occur.
• Variation points can be classified in various
  ways, such as
• The mechanism for configuring the variation point
  with a specific alternative (feature model-based
  configuration, creative construction DSL, etc.)
• The binding time, i.e. when in the development
  process a decision regarding the variation point
  has to be made
• The implementation technology used to implement
  the variation point in the resulting system

25
Variation Points II

• We distinguish between features and variation
  points.
• Every non-leaf feature (i.e. a feature that has
  sub-features) has one or more variation points.
• A variation point thus is the point regarding a
  feature, where a decision about a sub-feature has
  to be made.

• The connection between Feature1 and Feature2 is
  not a variation point, since Feature2 is
  mandatory and theres nothing to vary.
• In case of VP1/Feature3 it is equivalent whether
  you talk about a decision with respect to
  Feature3 or VP1. This is because Feature3 is a
  (single) optional feature.
• In case of VP2/Feature4/Feature5 it is not
  equivalent, because theres on VP that decides
  about two features.
• You also cannot equate Feature3 with VP2/VP3,
  because there are two Variation Points owned by
  Feature3

26
C O N T E N T S

• PLE Concepts
• Software System Families
• Process and Terminology
• Variability
• Feature Modeling
• Binding Times
• Classical PLE Implementation
• Source time
• Compile time
• Deployment/Configuration time
• Link time
• Run time
• MDD-AO-PLE
• What is MDD
• What is AO
• What is MDD-AO-PLE
• More Terms and Concepts

• MDD-AO Implementation
• Intro to Case Study
• The Various (Meta-)Models
• Meta Model Modularization
• Terminology M2M Transformations
• Terminology Model Extension
• Libraries
• An Example House
• Tracing
• Orthogonal Variability
• Transformation and Template AO
• AO Modeling
• Code Level Aspects
• Negative Variability
• Testing
• Enforcing Conventions
• Product Line Evolution
• Summary

27
Binding Time Analysis

• A feature diagram defines the common and variable
  parts of a system. It has to be determined when
  it needs to be decided if a specific (sub-)
  feature will be present in a specific product in
  the family. This is called binding time.
• Binding time has consequences on
• flexibility
• performance
• code size
• type safety
• and on the technique used to implement the
  variable aspect

28
Typical Binding Times Techniques

• source time manual programming, generators
• Compile time function overloading, precompiler,
  template evaluation, static aspect weaving
• deployment/configuration time component
  deployment (impl. for an interface), environment
  variables
• link time DLLs, class loading
• run time virtual functions, inheritance
  polymorphism, factory-based instance creation,
  delegation, meta programming, data driven
  (tables, interpreters)

29
Binding Time Consequences
30
C O N T E N T S

• PLE Concepts
• Software System Families
• Process and Terminology
• Variability
• Feature Modeling
• Binding Times
• Classical PLE Implementation
• Source time
• Compile time
• Deployment/Configuration time
• Link time
• Run time
• MDD-AO-PLE
• What is MDD
• What is AO
• What is MDD-AO-PLE
• More Terms and Concepts

• MDD-AO Implementation
• Intro to Case Study
• The Various (Meta-)Models
• Meta Model Modularization
• Terminology M2M Transformations
• Terminology Model Extension
• Libraries
• An Example House
• Tracing
• Orthogonal Variability
• Transformation and Template AO
• AO Modeling
• Code Level Aspects
• Negative Variability
• Testing
• Enforcing Conventions
• Product Line Evolution
• Summary

31
Manual Programming

• Handling variabilities by manually programming is
  the simplest way of handling variabilities.
• However, it is obviously very inflexible, since,
  whenever something changes you have to go back to
  the code and change it manually.
• Actually, theres no variability in the code.
• We wont elaborate this any further.

32
Generators

• With generators, you can also create
  modifications on source level ... Simply by
  generating different code based on models
• Can be very efficient, since it happens at source
  time...
• ... And is nevertheless very flexible.
• See later

33
C O N T E N T S

• PLE Concepts
• Software System Families
• Process and Terminology
• Variability
• Feature Modeling
• Binding Times
• Classical PLE Implementation
• Source time
• Compile time
• Deployment/Configuration time
• Link time
• Run time
• MDD-AO-PLE
• What is MDD
• What is AO
• What is MDD-AO-PLE
• More Terms and Concepts

• MDD-AO Implementation
• Intro to Case Study
• The Various (Meta-)Models
• Meta Model Modularization
• Terminology M2M Transformations
• Terminology Model Extension
• Libraries
• An Example House
• Tracing
• Orthogonal Variability
• Transformation and Template AO
• AO Modeling
• Code Level Aspects
• Negative Variability
• Testing
• Enforcing Conventions
• Product Line Evolution
• Summary

34
Function/Method Overloading

• Assume the following piece of code
• Here we use compile-time overloading, not
  polymorphism!

public class Calculator public int add( int x,
int y ) return xy public double
add( double x, double y ) return xy
// somewhere else.. Calculator c new
Calculator() int res c.add(3,5) // calls
the first one double res2 c.add(3.1415, 1.142)
// calls the second one
35
Preprocessors C/C Examples

• The following statement replaces the statement
  itself with the content of the file specified as
  part of the statement
• The next statement is a conditional statement
  that includes the part between the if and the
  endif.
• The ACE_HAS_TLI can be considered a boolean
  variable that can be defined or undefined.

include iostream.h
if defined (ACE_HAS_TLI)static ssize_t t_snd_n
(ACE_HANDLE handle, const void buf,
size_t len, int flags, const
ACE_Time_Value timeout 0, size_t
bytes_transferred 0) endif / ACE_HAS_TLI /
define ACE_HAS_TLI // defines ACE_HAS_TLI, sets
it true
36
Simple Macros C/C Examples (II)

• A typical case is to make sure include files are
  only included once per compilation unit.

if !defined(ComponentHelloWorldIncluded)define
ComponentHelloWorldIncluded include
"components\HelloWorld\HelloWorldSI.hinclude
"components\HelloWorld\HelloWorldRI.hinclude
"container\Diagnosable.h" class HelloWorld
public LifecycleInterface, public ComponentBase,
public HelloWorldSI,public
HelloWorldRI,public Diagnosable
private public HelloWorld()
HelloWorld() static int PARAMETER_NOT_DEFINE
D static int DP_inputvoltage static int
DP_clientcount int getDiagnosticParameter(
int name ) endif
37
Simple Macros C/C Examples (III)

• Macros can also be used to define constants
  (although specifically C provides better (and
  typesafe) means to achieve this)
• Processing is done via strict text pattern
  matching. Wherever the preprocessor finds the
  pattern, it replaces it. It has no clue about
  language semantics.
• Some more complex expressions involving
  parameters can also by preprocessed

define MAX_ARRAY_SIZE 200 define AUTHORNAME
MarkusVoelter
define MAX(x,y) (xlty ? y x) define square(x)
xx
38
Simple Macros Summary

• Macros are a useful means to achieve simple text
  replacement.
• In the context of programming languages, the
  problem is that macros are not syntax- or
  semantic-aware (and not type safe).
• As with almost anything, it can be abused by
  being used too heavily or by constructing
  formally legal, but nearly incomprehensible macro
  definitions.
• However, it is a proven tool and has been used
  successfully in many systems.

39
Template Parameters (in C)

• Unlike the generics implementation in Java, the
  templates in C are completely static this is
  why this is a source time mechanism.
• For every instantiated template (i.e. Template
  parameter) a completely new variant of the
  respective generic class is created.
• Consequently, this approach is quite efficient
  but potentially produces large images.

40
Template Metaprogramming (in C)

• Also called compile-time metaprogramming, because
  metaprograms run while the program is compiled
• Uses the features of C template instantiation
• Programming style is functional and operates on
  types
• Note that some awkward constructs are required,
• because C templates were not originally
  intended for this purpose
• and many generally unknown and non-trivial
  features of the standard are used.
• Error reporting is usually clumsy

41
Template Metaprogramming (in C) II

• A static IF can be used to check boolean
  conditions on types at compile time.

include ltiostreamgt using namespace
std templateltbool condition, class Then, class
Elsegt struct IF typedef Then
RET //specialization for conditionfalse tem
plateltclass Then, class Elsegt struct IFltfalse,
Then, Elsegt typedef Else RET void
main() cout ltlt "sizeof(short) " ltlt
sizeof(short) ltlt endl ltlt "sizeof(int) "
ltlt sizeof(int) ltlt endl ltlt
"sizeof(IFlt(12gt4), short, intgtRET) "
ltlt sizeof(IFlt(12gt4), short, intgtRET) ltlt endl
IFlt(12gt4), short, intgtRET i //the type of i
is int!
42
Static Aspect Weaving

• AOP can be used for various reasons
• fixing broken code
• Separate cross-cutting (often technical) concerns
• Handling variants
• Depending on the features we want in our system,
  we add additional pieces of (AspectJ) source
  code.
• In our example, we can optionally add error
  handling
• done by adapting/extending the build path of the
  respective project
• It happens statically, its woven on byte code
  level
• Can also be done at deployment time
• Using advices, you can attach additional
  behaviour to existing code.

43
Static Aspect Weaving Example

• We use a small service framework to illustrate
  the technique. Here is an introductory test case

public void testSimpleAdding() ServiceEngine
engine new ServiceEngine() engine.registerServ
ice( new CalculationService(),
CalculationServiceContext.class )
CalculationServiceContext ctx1 new
CalculationServiceContext(1,2) engine.addTask(
ctx1 ) CalculationServiceContext ctx2 new
CalculationServiceContext(3,4) engine.addTask(
ctx2 ) engine.run() assertEquals( 3,
ctx1.getResult() ) assertEquals( 7,
ctx2.getResult() )
44
Static Aspect Weaving Example II

• One variant adds error logging to the service
  engine framework. Here is a test case adding
  negative numbers is illegal, we expect an error
  in the log.
• The logFor() operation is new, as is the
  functionality to create a log in case the result
  is negative.

public void testSimpleAdding() ServiceEngine
engine new ServiceEngine() engine.registerServi
ce( new CalculationService(), CalculationServiceCo
ntext.class ) CalculationServiceContext ctx
new CalculationServiceContext(1,-2) engine.addTa
sk( ctx ) engine.run() assertEquals( -1,
ctx.getResult() ) assertNotNull( engine.logFor(
ctx ) )
45
Static Aspect Weaving Example III

• Heres the aspect that implements that variant

public aspect ErrorLogging private
MapltIServiceContext, Errorgt ServiceEngine.log
public Error ServiceEngine.logFor(IServiceCo
ntext ctx) return log.get(ctx)
public void ServiceEngine.log( IServiceContext
ctx, Error err ) log.put( ctx, err )
pointcut serviceExec( ServiceEngine e,
IServiceContext c, IService s ) execution(
ServiceEngine.executeService(IServiceContext,
IService)) args(c,s) target(e)
Status around( ServiceEngine e, IServiceContext
c, IService s ) serviceExecution(
ServiceEngine, IServiceContext, IService )
args(c,s) target(e) Status s
proceed(engine,ctx,srv) if ( s ! Status.ok )
engine.log( ctx, new Error(s, "no further
information") ) return s
46
C O N T E N T S

• PLE Concepts
• Software System Families
• Process and Terminology
• Variability
• Feature Modeling
• Binding Times
• Classical PLE Implementation
• Source time
• Compile time
• Deployment/Configuration time
• Link time
• Run time
• MDD-AO-PLE
• What is MDD
• What is AO
• What is MDD-AO-PLE
• More Terms and Concepts

• MDD-AO Implementation
• Intro to Case Study
• The Various (Meta-)Models
• Meta Model Modularization
• Terminology M2M Transformations
• Terminology Model Extension
• Libraries
• An Example House
• Tracing
• Orthogonal Variability
• Transformation and Template AO
• AO Modeling
• Code Level Aspects
• Negative Variability
• Testing
• Enforcing Conventions
• Product Line Evolution
• Summary

47
Component Deployment

• Consider a J2EE application server. When deplying
  EJBs you can
• Pass in configuration parameters
• wire the dependencies to other components
• Configure security and transactions,
• and generally address QoS issues by deploying
  on different hardware

48
Component Deployment Interceptors

• In general, whenever you can add interceptors to
  a system, this allows you to add/configure
  certain cross-cutting concerns
• Typically, this consists of generating proxies
  GoF for application components
• that can hook-in interceptors POSA2.
• Use a factory to instantiate the proxies if
  necessary.
• Consider you face the following situation

49
Component Deployment Interceptors II

• You can replace this setup by the following
• From a clients perspective, nothing has changed,
  the client still uses the interface I1. However,
  the client actually talks to a proxy that handles
  CCC, and then forwards to the real object.

50
Component Deployment Interceptors III

• Make sure that the join points are method calls
  then the following interceptor interface can be
  used
• The factory determines which interceptors will be
  used for a given object based on some kind of
  configuration (file).

public interface Interceptor public void
beforeInvoke( Object target,
String methodName,
Object params ) public void
afterInvoke( Object target,
String methodName,
Object params,
Object retValue )
51
Component Deployment Interceptors IV

• The following is the basic structure of the
  proxy

public class SomeComponentProxy implements I1
private SomeComponent delegate private
Interceptor interceptor // can also be a list
// of
interceptors public String someOperation(
String p1, int p2 ) Object target
delegate String opName someOperation
Object params p1, p2
Interceptor.beforeInvoke( target, opName, params
) String res delegate.someOperation( p1,
p2 ) Interceptor.afterInvoke( target,
opName, params, ret ) return res //
more operations of I1
52
Component Deployment Interceptors V

• Example. In the EJB scenario introduced above,
  the generated proxy would be the bean
  implementation class from the perspective of the
  application server, the real bean implementation
  would be an implementation detail of this
  class.

53
C O N T E N T S

• PLE Concepts
• Software System Families
• Process and Terminology
• Variability
• Feature Modeling
• Binding Times
• Classical PLE Implementation
• Source time
• Compile time
• Deployment/Configuration time
• Link time
• Run time
• MDD-AO-PLE
• What is MDD
• What is AO
• What is MDD-AO-PLE
• More Terms and Concepts

• MDD-AO Implementation
• Intro to Case Study
• The Various (Meta-)Models
• Meta Model Modularization
• Terminology M2M Transformations
• Terminology Model Extension
• Libraries
• An Example House
• Tracing
• Orthogonal Variability
• Transformation and Template AO
• AO Modeling
• Code Level Aspects
• Negative Variability
• Testing
• Enforcing Conventions
• Product Line Evolution
• Summary

54
DLL loading and Classloading

• In static languages such as C/C, you can load
  different DLLs that define the same entry points.
  
• In Java you can use class loading ... Although
  the variability mechanism in fact will be a
  runtime solution using polymorphism

55
C O N T E N T S

• PLE Concepts
• Software System Families
• Process and Terminology
• Variability
• Feature Modeling
• Binding Times
• Classical PLE Implementation
• Source time
• Compile time
• Deployment/Configuration time
• Link time
• Run time
• MDD-AO-PLE
• What is MDD
• What is AO
• What is MDD-AO-PLE
• More Terms and Concepts

• MDD-AO Implementation
• Intro to Case Study
• The Various (Meta-)Models
• Meta Model Modularization
• Terminology M2M Transformations
• Terminology Model Extension
• Libraries
• An Example House
• Tracing
• Orthogonal Variability
• Transformation and Template AO
• AO Modeling
• Code Level Aspects
• Negative Variability
• Testing
• Enforcing Conventions
• Product Line Evolution
• Summary

56
Polymorhpism

• This is well known. The method that is invoked
  depends on the runtime (dynamic) type of the
  object on which you invoke the operation.
• A factory is often used in conjuction
• Related to the strategy bridge patterns

57
Polymorhpism II

• A simple test case

public class PricingTest extends TestCase
private ListltProductgt products protected void
setUp() throws Exception products new
ArrayListltProductgt() products.add( new
Product() ) products.add( new Product() )
products.add( new Product() ) products.add( new
Product() ) products.add( new Product() )
public void testLinearPricing()
Customer normalCustomer new Customer(false)
int totalPrice Factory.getPricingStrategy(norma
lCustomer). calculatePrice(
products ) assertEquals( 500, totalPrice )
public void testRebatePricing()
Customer valuedCustomer new Customer(true)
int totalPrice Factory.getPricingStrategy(valued
Customer). calculatePrice(
products ) assertEquals( 300, totalPrice )

58
Polymorhpism III

• Strategy Implementation and the Factory

public abstract class PricingStrategy public
abstract int calculatePrice( List products
) public class LinearPricing extends
PricingStrategy public int calculatePrice(List
products) return products.size() 100
public class RebatePricing extends
PricingStrategy public int calculatePrice(List
products) int count products.size()
if ( count gt 3 ) count 3 return count
100
public class Factory public static
PricingStrategy getPricingStrategy( Customer c )
if ( c.isValued() ) return new
RebatePricing() else return new
LinearPricing()
59
Metaprogramming

• In as much as a computational process can be
  constructed to reason about an external world in
  virtue of comprising an ingredient process
  (interpreter) formally manipulating
  representations of that world, so, too, a
  computational process could be made to reason
  about itself in virtue of comprising an
  ingredient process (interpreter) formally
  manipulating representations of ist own
  operations and structures.
• Smith, The Reflection Hypothesis

60
Metaprogramming in OO Languages

• There are several terms in use
• Introspection/Reflection read/modify the program
• Reification change the semantics of existing
  code
• Often, the term Meta Object Protocol is used
• Example Languages
• CLOS Reification, Reflection, Introspection,
  MOP, Lisp in Lisp
• Smalltalk Reflection, Dictionary, (Smalltalk
  nil)...
• Java Introspection, teilweise Reflection,
  java.lang.Class, java.reflect
• Self Reification, Reflection, Introspection
• Ruby Reflection, Introspection

61
Metaprogramming in OO Languages II

• I assume you all know Java Reflection and its
  also not very interesting (since its not very
  powerful).
• Considering the current hype about dynamic
  languages such as Ruby, and the fact, that these
  languages
• integrate with Java nicely (JRuby)
• And that Java (at least, the VM) may even get
  native support for more dynamic languages
  (invokedynamic keyword)
• I will show an Example in Ruby
• It shows how to handle structural variability
  using metaprogramming

62
Metaprogramming in OO Languages III

• Here is an entity class definition
• And here is a test case
• Where do the native Ruby properties name and
  firstname come from, and how come they can be
  intialized via the gt syntax?

class Person lt Entity properties name,
firstname has_one adr gt Address has_many
addresses gt Address end
class SimpleTests lt TestUnitTestCase def
test_people p Person.new( name gt
"Voelter", firstname gt "Markus")
assert_equal p.name, "Voelter" assert_equal
p.firstname, "Markus
63
Metaprogramming in OO Languages IV

class WithProperties def self.properties(
attrNames ) define_method( initialize ) do
values attrNames.each do attrName
instance_variable_set(
("_at_"attrName.to_s).to_sym,
valuesattrName.to_sym ) end end
attrNames.each do attrName getter Q
def attrName.to_s
_at_attrName.to_s end
self.module_eval(getter) setter Q
def attrName.to_s (value)
_at_attrName.to_s value end
self.module_eval(setter) end
end end

• Here is the class definition of Entity
• and the WithProperties class ?
• The properties key-word in really staticmethod
  that is exe-cuted during classdefinition.
• It in turn creates the initializer and the
  setters and getters

class Entity lt WithProperties end
64
Dynamic Aspects, Virtual Classes Collaboration
Interfaces

• Example Stock Broker
• Challengeadd pricing feature
• Optionally, people canbe charged
• Different strategies should be usable
• and of course without touching existing classes
• Implementation with CaesarJ and its
  composite/virtual classes
• CasearJ is developed by the Software Technology
  Group at TU Darmstadt, see www.caesarj.org
• The example given here is based on an article
  byIris Groher, Vaidas Gasiunas, Christa
  Schwanninger, Klaus Ostermann. Thanks for letting
  me use it!

65
Dynamic Aspects, Virtual Classes Collaboration
Interfaces II
abstract cclass PricingCI abstract public
cclass Customer / provided / abstract
public double getBalance() abstract public
void charge(Item it) abstract public Bill
createBill() / expected / abstract
public String getCustInfo() abstract
public cclass Item / provided /
public double getPrice() public double
getTax() public BillLine createBillLine()
/ expected / public double
getBasePrice() public String
getItemDescr()

• cclasses encapsulateseveral inner
  classeswhich can be overriddenin subclasses of
  the cclass.
• provided methods areprovided by the
  cclassexpected methods areexpected by the
  cclassfrom its environment
• Note how this pricing feature is still
  completely independent of our stock broker
  application!

66
Dynamic Aspects, Virtual Classes Collaboration
Interfaces III

• The following code shows a possible
  implementation of the PricingCI, implementing a
  simple pricing strategy.
• Note how the inner classes are still abstract,
  since their expected methods are still not
  implemented.

abstract cclass SimplePricing extends PricingCI
abstract public cclass Customer
private double balance private List
billLines public double getBalance()
return balance public void charge(Item
item) balance - item.getPrice()
billlLines.add(item.createBillLine())
public Bill createBill() String header "Bill
for "
getCustInfo() ... abstract public
cclass Item public double getPrice()
return getBasePrice() getTax() public
BillLine createBillLine() return new
BillLine(getItemDescr(), getPrice(), getTax())
public double getTax() ...

67
Dynamic Aspects, Virtual Classes Collaboration
Interfaces IV

• We now need to bind the pricing feature with the
  stock broker app. The binding code is a separate
  entity.
• Note how the binding extends only the abstract
  CI, not the specific pricing strategy! Here the
  expected methods are implemented.

abstract public cclass PerStockRequestBinding
extends PricingCI public cclass
ClientCustomer extends Customer wraps Client
public String getCustInfo() return
wrappee.getClientName() " "
wrappee.getClientId() public
cclass StockItem extends Item wraps
StockInfoRequest public double
getBasePrice() return 5
wrappee.getStocks().length 0.2 public
String getItemDescr() return "Stock req. "
wrappee.getStocks().length
after(Client client, StockInfoRequest request)
(call(StockInfo StockInfoBroker.collectInfo(..
)) this(c) args(request))
ClientCustomer(client).charge(StockItem(request)
)
68
Dynamic Aspects, Virtual Classes Collaboration
Interfaces V

• You now need to combine the pricing strategy with
  the application binding
• The illustration on theright shows the result
  ofthis combination.

cclass SimplePricingPerStockRequest extends
SimplePricing PerStockRequestBinding
69
Dynamic Aspects, Virtual Classes Collaboration
Interfaces VI

• You can now, at any place in your application
  code, deploy the feature dynamically and use it

final PerStockRequest pricing new
SimplePricingPerStockRequest() deploy (pricing)
StockInfoRequest request new
StockInfoRequest(stockList) StockInfo si
StockInformationBroker.getInstance().collect
Info(request) // advice is activated
inside the deploy block
70
Dynamic Aspects, Virtual Classes Collaboration
Interfaces VII

• And of course you can extend the system with new
  strategies

abstract cclass DiscountPricing extends
SimplePricing abstract public cclass
Customer protected int discountState 4
public void charge(Item item)
if (discountState 0) discountState 4
else super.charge(item)
discountState--
cclass DiscountPricingPerStockRequest extends
DiscountPricing PerStockRequestBinding
final PerStockRequest pricing new
DiscountPricingPerStockRequest () deploy
(pricing) ...
71
C O N T E N T S

• PLE Concepts
• Software System Families
• Process and Terminology
• Variability
• Feature Modeling
• Binding Times
• Classical PLE Implementation
• Source time
• Compile time
• Deployment/Configuration time
• Link time
• Run time
• MDD-AO-PLE
• What is MDD
• What is AO
• What is MDD-AO-PLE
• More Terms and Concepts

• MDD-AO Implementation
• Intro to Case Study
• The Various (Meta-)Models
• Meta Model Modularization
• Terminology M2M Transformations
• Terminology Model Extension
• Libraries
• An Example House
• Tracing
• Orthogonal Variability
• Transformation and Template AO
• AO Modeling
• Code Level Aspects
• Negative Variability
• Testing
• Enforcing Conventions
• Product Line Evolution
• Summary

72
What is MDSD?

• Domain Driven Development is about making
  software development more domain-related as
  opposed to computing related. It is also about
  making software development in a certain domain
  more efficient.

73
What is MDSD? II

• Model-Driven Software Development is about making
  models first class development artefacts as
  opposed to just pictures.
• Various aspects of a system are not programmed
  manually rather they are specified using a
  suitable modeling language.
• The language for expressing these models is
  specific to the domain for which the models are
  relevant. The modeling languages used to describe
  such models are called domain-specific languages
  (DSL).
• Models have to be translated into executable code
  for a specific platform.
• Such a translation is implemented using model
  transformations.
• An approach based on model interpretation is also
  possible, but seldomly used I will ignore this
  here!

74
How does MDSD work?

• Developer develops model(s)based on certain
  metamodel(s).
• Using code generation templates, the model is
  transformed to executable code.
• Optionally, the generated code is merged with
  manually written code.
• One or more model-to-model transformation steps
  may precede code generation.

75
Models Meta Models

• A model is an abstraction of a real world system
  or concept.
• It only contains the aspect of the real world
  artifact that is relevant to what should be
  achieved with the model.
• A model is therefore less detailed than the real
  world artifact.
• MDD models are precise and processable.
• Complete regarding the abstraction level or
  viewpoint.
• The concepts used for building the model are
  actually formally defined.
• The way to do this is to make every model conform
  to a meta model.
• The meta model defines the terms and the
  grammar we can use to build the model.
• Models are instances of their respective meta
  models.

76
Meta Meta Models

• A meta model also has a meta model
• after all, a meta model is a model that plays the
  role of the meta model for some other model.
• The meta models meta model is called the meta
  meta model.
• A meta meta model typically looks more or less
  like the following

77
Meta Levels

• This diagram illustrates the various meta levels
  using
• UML as well as a custom meta model
• Caveat Note that absolute meta levels (as shown
  here) can be a problem and lead to strange
  statements better avoid them and consider this
  really only an example

78
Domain Specific Language

• A Domain Specific Language (DSL) is a formalism
  to build models. It encompasses
• the meta model of the models to be built
• some textual or graphical (or other)concrete
  syntax that is used to represent (draw) the
  models.
• In the context of product line engineering DSLs
  are used to bind variabilities.
• Consequently, feature diagrams are a special
  kind of DSL, one that can be used to express
  configurative variability.

79
What is MDSD? III
several
Metametamodel
target
subdomains
software
software
architecture
architecture
designexpertise
bounded area of
partial
knowlege/interest
composable
multiple
knowledge
viewpoint
multi-step
transform
Domain
single-step
semantics
compile
Model
Ontology
interpret
no
precise/
Domain
roundtrip
executable
Specific
Language
graphical
Metamodel
textual

• Related Approaches (Specializations)MDA, SF,
  DSM, GP,

80
Kinds of Variabilities

• There are two kinds of variability structural
  and non-structural
• Structural variability typically has to be
  described using creative construction DSLs
• Non-structural (or configurative) variability can
  be described using configuration languages.

81
Creative Construction DSLs

• A meta model that can be used for creatively
  constructing data structures.
• The following are two example models that can be
  constructed with a DSL that implements the meta
  model above.

82
Structural Models and Behavioral Models

• Most examples for DSLs define structures of
  applications.
• DSLs can also be used to express behavior.
• Configuration DSLs as well as creative
  construction DSLs can be used.
• Here ? is a configuration DSL that expresses the
  behavior of a connector in a component based
  system.
• An example ? of a creative construction DSL for
  expres-sing behavior is state machines.

83
C O N T E N T S

• PLE Concepts
• Software System Families
• Process and Terminology
• Variability
• Feature Modeling
• Binding Times
• Classical PLE Implementation
• Source time
• Compile time
• Deployment/Configuration time
• Link time
• Run time
• MDD-AO-PLE
• What is MDD
• What is AO
• What is MDD-AO-PLE
• More Terms and Concepts

• MDD-AO Implementation
• Intro to Case Study
• The Various (Meta-)Models
• Meta Model Modularization
• Terminology M2M Transformations
• Terminology Model Extension
• Libraries
• An Example House
• Tracing
• Orthogonal Variability
• Transformation and Template AO
• AO Modeling
• Code Level Aspects
• Negative Variability
• Testing
• Enforcing Conventions
• Product Line Evolution
• Summary

84
What is AOSD?

• AOSD is about localizing cross-cutting concerns
  into well-defined modules called aspects.
• Various approaches to AOSD are possible,
  including language extension (AspectJ) and
  framework/infrastructure-based approaches (such
  as Spring AOP, JBOSS AOP or AspectWerkz).
• A core characteristic of each AOSD tool is its
  join point model, i.e. the means by which the
  base code and the aspect code can be joined.
• Static and Dynamic join points can be supported
• The granularity of the join point model varies.
• Introductions/Inter-Type declarations are often,
  but not always possible

85
How does AOSD work?

• Developer developsprogram code
• Developer develops (or reuses) aspect code
• Developers specifies theweaving rules (defines
  pointcuts)
• Aspect Weaver weavesprogram and aspectstogether
  and producesthe aspectized program
• This may happen staticallyor dynamically

86
What AOSD is, too

• The above explanation of AOSD is what the
  mainstream considers AOSD to be.
• There are, however, two additional "aspects
• introductions
• and collaborations
• I will not focus on these in the main
  presentation I will provide some information at
  the end.

87
C O N T E N T S

• PLE Concepts
• Software System Families
• Process and Terminology
• Variability
• Feature Modeling
• Binding Times
• Classical PLE Implementation
• Source time
• Compile time
• Deployment/Configuration time
• Link time
• Run time
• MDD-AO-PLE
• What is MDD
• What is AO
• What is MDD-AO-PLE
• More Terms and Concepts

• MDD-AO Implementation
• Intro to Case Study
• The Various (Meta-)Models
• Meta Model Modularization
• Terminology M2M Transformations
• Terminology Model Extension
• Libraries
• An Example House
• Tracing
• Orthogonal Variability
• Transformation and Template AO
• AO Modeling
• Code Level Aspects
• Negative Variability
• Testing
• Enforcing Conventions
• Product Line Evolution
• Summary

88
What is MDD-AO-PLE

• As mentioned above, the core challenge of product
  line implementation, is the implementation of the
  product variability.
• Models are more abstract and hence less detailed
  than code
• Thus, the variability is inherently less
  scattered, making variability management on model
  level simpler!

89
What is MDD-AO-PLE II

• AO is used in several ways
• On model level, we use it for weaving models and
  meta models
• In the transformation, we weave variants into
  transformations and generators
• And on code level, we use it to directly
  implement fine-grained implementation variants.
• We provide more details on all of these aspects ?
  later, as well as examples.
• DefinitionMDD-AO-PLE uses models to describe
  product lines. Variants are defined on
  model-level. Transformations generate running
  applications. AO techniques are used to