Unit 4

Model Driven Architecture 

Middleware
 A software layer that masks hetereogeneity
 Placed between operating systems and application components
OMG’s Milestones
OMG is
founded
1989

1991 CORBA 2.0

CORBA
1.0, IDL 1996
MDA

1997
UML, MOF,
XMI, CWM
2001
The Object Management Group (OMG)
 An open membership

 creating a standard architecture for distributed network objects.

 The group provides only specifications, not implementations.

 Basic Concepts
Model: A model is often presented as a combination of drawings and text.

Viewpoint: Here ‘abstraction’ is used to mean the process of suppressing selected detail to establish a
simplified model.

Platform: A platform is a set of subsystems and technologies that provide a coherent set of functionality
through interfaces and specified usage patterns, which any application supported by that platform can use
without concern for the details of how the functionality provided by the platform is implemented.

Platform Independence: This is the quality that the model is independent of the features of a platform of any
particular type.

Pervasive Services: Pervasive services are services available in a wide range of platforms.

Model Transformation: Model transformation is the process of converting one model to another model of the
same system.
• Model Driven Architecture (MDA) is an effective design approach
that is taken by developers to capture the project requirements,
plans and implementation design and follow it to implement the
system.

• An approach to IT system specification that separates the specification

of system functionality from the specification of the implementation of
that functionality on a particular technology platform.
• Key points:

• MDA is a software design approach launched in 2001 by Object

Management Group (OMG).
• System functionality is first defined as Platform Independent Model through
domain-specific language like CORBA, .Net, the Web etc.
• PIM then translated to platform-specific models through domain-specific or
general purpose language like Java, C#, Python, etc.
• Translations between PIM and PSMs done using automated tools, like model
transformation tools.
• MDA model is related to multiple standards, such as Unified Modeling
Language (UML).
 Viewpoint
• Computation Independent Viewpoint: It focuses on the on the environment of
the system, and the requirements for the system. The details of the structure and
processing of the system are hidden or as yet undetermined.

• Platform Independent Viewpoint: It focuses on the operation of a system while

hiding the details necessary for a particular platform. A platform independent
view shows that part of the complete specification that does not change from one
platform to another. A platform independent view may use a general purpose
modeling language, or a language specific to the area in which the system will be
used.

• Platform Specific Viewpoint: It combines the platform independent viewpoint

with an additional focus on the detail of the use of a specific platform by a system.
MDA Models
• There are three major MDA models specified by MDA based on
the three viewpoints.
• These models can perhaps more accurately be described as
layers of abstraction since within each of these three layers a
set of models can be constructed, each one corresponding to a
more focused view of the system (user interface, information,
engineering, architecture, etc.)
1) Computation Independent Model (CIM):
1) The CIM combines the requirements and domain models. It models the
system in terms of how it will interact with its environment.
2) describe requirements and needs at a very abstract level, without any
reference to implementation aspects

2) Platform Independent Model (PIM):

The PIM is the design model. It describes the internal structure of the model
without regard to the hosting platform.
Define the behavior of the systems in terms of stored data and performed
algorithms, without any technical or technological details;

3) Platform Specific Model (PSM):

The PSM is the implementation model.
https://swi.cs.vsb.cz/RUPLarge/tech.rsa/guidances/concepts/mdd_and_mda_8F9B3685.html
Example 1
• Transformation between two UML models

• The source model is a PIM, which is transformed into a lower level,

more PSM for use with Java.
System Development Lifecycle and the MDA
approach PIM to PIM
mappings

PSM to PSM
mappings

UML MOF CWM

Time
PIM to PSM
mappings
(projection on a
specific platform)
Developing in MDA – Step 1:
the PIM (1/2)
 All MDA development projects start with the creation of a PIM
 PIM at this level represents business functionality and behaviour,
undistorted by technology details
 MDA application-modeling tools contain representations of Pervasive
Services and Domain Facilities allowing them to be used and/or
incorporated in the application via a menu selection
Developing in MDA – Step 2: the PSM
(1/2)
 Once the first iteration is complete, the PIM is input to the mapping
step which will produce a PSM
 Code is partially automatic and partially hand-written
 PIM can be mapped either to a single platform or to multiple
platforms
Developing in MDA – Step 3:Generating Application
(1/2)

 An MDA tool generates all or most of the implementation code for

the deployment technology selected by the developer
 Re-integration on new platforms can be done by reverse engineering
the existing application into a model and redeploy
Developing in MDA – Step 3:
Generating Application (2/2)
PIM

Maps to Maps to Maps to

CORBA Java/EJB Other

Model Model … Model

Maps to Maps to Maps to

CORBA Java/EJB … Other

• Advantages of MDA

• Portability: The migration of existing functionalities to new environments and platforms, as per the
business requirements, can be rapidly done.
• Productivity and Time-to-Market: Many of the tasks are automated and the development team can
concentrate on the core logic. Thus productivity is increased and time to reach market becomes
shorter.
• Quality: The consistency and reliability of the components built, contributes to the overall quality of
the system.
• Integration: The MDA greatly facilitates the production of integration bridges with legacy and/or
external system.
• Maintenance: Since the design is available in a machine-readable form, analysts, developers and
testers can directly access the specifications of the system and thus maintenance process is
simplified.
• Testing and Simulation: The models can be validated against requirements and tested against
various infrastructures.
• Return on Investment: The investments done on tools generates greater value
Aspect Oriented Programming(AOP) 
Programming paradigms
• Procedural programming
• Executing a set of commands in a given sequence
• Fortran, C, Cobol
• Functional programming
• Evaluating a function defined in terms of other functions
• Lisp, ML, OCaml
• Logic programming
• Proving a theorem by finding values for the free variables
• Prolog
• Object-oriented programming (OOP)
• Organizing a set of objects, each with its own set of responsibilities
• Smalltalk, Java, C++ (to some extent)
• Aspect-oriented programming (AOP)
• Executing code whenever a program shows certain behaviors
• AspectJ (a Java extension)
• Does not replace O-O programming, but rather complements it

23
The problem
• Some programming tasks cannot be neatly encapsulated in objects,
but must be scattered throughout the code
• Examples:
• Logging (tracking program behavior to a file)
• Profiling (determining where a program spends its time)
• Tracing (determining what methods are called when)
• Session tracking, session expiration
• Special security management
• The result is crosscuting code--the necessary code “cuts across” many
different classes and methods
24
Example
• class Fraction {
int numerator;
int denominator;
...
public Fraction multiply(Fraction that) {
traceEnter("multiply", new Object[] {that});
Fraction result = new Fraction(
this.numerator * that.numerator,
this.denominator * that.denominator);
result = result.reduceToLowestTerms();
traceExit("multiply", result);
return result;
} • Now imagine similar code in
... every method you might want
} to trace
25
Consequences of crosscutting code
• Redundant code
• Same fragment of code in many places
• Difficult to reason about
• Non-explicit structure
• The big picture of the tangling isn’t clear
• Difficult to change
• Have to find all the code involved...
• ...and be sure to change it consistently
• ...and be sure not to break it by accident
• Inefficient when crosscuting code is not needed
26
Why AOP
 Aspect oriented programming(AOP) 
• Aspect oriented programming(AOP) can be defined as the breaking of code into different
modules, also known as modularization, where the aspect is the key unit of modularity.

• AOP is the methodology to apply middleware services on application.

• AOP allows us to write application code and middleware services separately and allow to
link middleware services code with application through xml files or annotation.

• AOP breaks the program logic into distinct parts called as concerns.

• A cross-cutting concern is a concern that can affect the whole application and should be
centralized in one location in code as possible, such as transaction management,
authentication, logging, security etc.
• AOP is a programming paradigm that aims to increase modularity by allowing
the separation of cross-cutting concerns.

• Process of applying services or external services as transaction management

to our application classes without modifying the code.

• This services called as cross cutting concern.

• Aspect-Oriented Programming (AOP) complements Object-Oriented

Programming (OOP) by providing another way of thinking about program
structure. The key unit of modularity in OOP is the class, whereas in AOP the
unit of modularity is the aspect.
• Why use AOP?

• It provides the pluggable way to dynamically add the additional concern before, after or around
the actual logic. Suppose there are 10 methods in a class as given below:
class A{  
public void m1(){...}  
public void m2(){...}  
public void m3(){...}  
public void m4(){...}  
public void m5(){...}  
public void n1(){...}  
public void n2(){...}  
public void p1(){...}  
public void p2(){...}  
public void p3(){...}  
}  
• There are 5 methods that starts from m, 2 methods that starts from n and 3
methods that starts from p.
• Understanding Scenario I have to maintain log and send notification after
calling methods that starts from m.
• Problem without AOP We can call methods (that maintains log and sends
notification) from the methods starting with m. In such scenario, we need to
write the code in all the 5 methods.
• But, if client says in future, I don't have to send notification, you need to
change all the methods. It leads to the maintenance problem.
• Solution with AOP We don't have to call methods from the method. Now we
can define the additional concern like maintaining log, sending notification etc.
in the method of a class. Its entry is given in the xml file.
• In future, if client says to remove the notifier functionality, we need to change
only in the xml file. So, maintenance is easy in AOP.
Example of AOP

• An example is using a security policy in an application.

Typically, security runs through many elements of an
application. The application's security policy should be applied
equally to all existing and new parts of the application. At the
same time, a security policy in use can itself evolve. This is the
perfect place to use AOP.
1.Also, another example is logging. There are several advantages to
using the AOP approach to logging rather than manually adding logging
function: The code for logging is easy to add and remove: all you need
to do is add or remove a couple of configurations of some aspect.
2.All the source code for logging is kept in one place, so you don't need
to manually hunt down all the places where it is used.
3.Logging code can be added anywhere, whether in methods and
classes that have already been written or in new functionality. This
reduces the number of coding errors.
4.Also, when removing an aspect from a design configuration, you can be
sure that all the tracing code is gone and that nothing was missed.
5.Aspects are separate code that can be improved and used again and
again.
AOP is also used for exception handling, caching, and extracting certain functionality to make it reusable.
 The key difference between OOP and
AOP
• The key difference between OOP and AOP is that the focus of OOP is
to break down the programming task in to objects, which
encapsulate data and methods,
while the focus of AOP is to break down the program in to
crosscutting concerns.

• Reusability of code is at a great extent as compared to OOP.

Advantages of AOP
• Increased Modularity.

• Increased Maintainability.

• Increased Reusability

• Reduction in the size of the code.

AspectJTM
• AspectJ is a small, well-integrated extension to Java
• Based on the 1997 PhD thesis by Christina Lopes, A Language Framework for
Distributed Programming
• AspectJ modularizes crosscutting concerns
• That is, code for one aspect of the program (such as tracing) is collected
together in one place
• The AspectJ compiler is free and open source
• AspectJ works with JBuilder, Forté, Eclipse, probably others
• Best online writeup: http://www.eclipse.org/aspectj/
• Parts of this lecture were taken from the above paper
37
The Figure Element example

38
Terminology
• A join point is a well-defined point in the program flow
• A pointcut is a group of join points
• Advice is code that is executed at a pointcut
• Introduction modifies the members of a class and the relationships
between classes
• An aspect is a module for handling crosscutting concerns
• Aspects are defined in terms of pointcuts, advice, and introduction
• Aspects are reusable and inheritable
• Each of these terms will be discussed in greater detail

39
• AOP Concepts and Terminology
• AOP concepts and terminologies are as follows:

1. Join point
2. Advice
3. Pointcut
4. Target Object
5. Aspect
6. Weaving
AOP Concept:

•Aspect: Aspect is a class that implements enterprise application concerns that a

modularization of a concern that cuts across multiple classes. Transaction management is a
good example of a crosscutting concern in J2EE applications.
• In Spring AOP, aspects can be a normal class configured through spring xml configuration or
through regular classes annotated with the @Aspect annotation.

•Join point: A join point is a specific point in the application where we can plug-in the
AOP aspect. Such as method execution, exception handling, etc. In Spring AOP, a join
point always represents a method execution.

•Pointcut: a predicate that matches join points. Advice is associated with a pointcut expression
and runs at any join point matched by the pointcut (for example, the execution of a method
with a certain name). The concept of join points as matched by pointcut expressions is central
to AOP, and Spring uses the AspectJ pointcut expression language by default.
• Advice:
• Action taken by an aspect at a particular join point.
• Different types of advice include "around," "before" and "after" advice.
 Types of advice:

• Before advice: Advice that executes before a join point, but which does not have the ability to
prevent execution flow proceeding to the join point (unless it throws an exception).

• After returning advice: Advice to be executed after a join point completes normally: for example,
if a method returns without throwing an exception.

• After throwing advice: Advice to be executed if a method exits by throwing an exception.

• After (finally) advice: Advice to be executed regardless of the means by which a join point exits
(normal or exceptional return).

• Around advice: Advice that surrounds a join point such as a method invocation. This is the most
powerful kind of advice. Around advice can perform custom behavior before and after the
method invocation..
 Pointcut designator wildcards
• It is possible to use wildcards to declare pointcuts:
• execution(* *(..))
• Chooses the execution of any method regardless of return or parameter types

• call(* set(..))
• Chooses the call to any method named set regardless of return or parameter
type
• In case of overloading there may be more than one such set method; this
pointcut picks out calls to all of them
44
Pointcut designators based on types
• You can select elements based on types. For example,
• execution(int *())
• Chooses the execution of any method with no parameters that returns an int
• call(* setY(long))
• Chooses the call to any setY method that takes a long as an argument, regardless of
return type or declaring type
• call(* Point.setY(int))
• Chooses the call to any of Point’s setY methods that take an int as an argument,
regardless of return type
• call(*.new(int, int))
• Chooses the call to any classes’ constructor, so long as it takes exactly two ints as
arguments

45
Pointcut designator composition
• Pointcuts compose through the operations or (“||”), and (“&&”) and not (“!”)
• Examples:
• target(Point) && call(int *())
• Chooses any call to an int method with no arguments on an instance of Point, regardless of its
name
• call(* *(..)) && (within(Line) || within(Point))
• Chooses any call to any method where the call is made from the code in Point’s or Line’s type
declaration
• within(*) && execution(*.new(int))
• Chooses the execution of any constructor taking exactly one int argument, regardless of where
the call is made from
• !this(Point) && call(int *(..))
• Chooses any method call to an int method when the executing object is any type except Point

46
• Program in aspect which will use declare and Point.clone().

• aspect CloneablePoint {

declare parents: Point implements Cloneable;

•
declare soft: CloneNotSupportedException:
execution(Object clone());

•
Object Point.clone() { return super.clone(); }
}
• https://youtu.be/yhN1qjTrpY4
• https://youtu.be/QdyLsX0nG30
• https://www.slideserve.com/jane/introduction-to-aspect-oriented-programmin
g
• https://www.youtube.com/watch?v=POa6ZZKq79E