Faculty of Informatics and Information Technologies Slovak University of Technology

Faculty of Informatics and Information Technologies

Slovak University of Technology

Peter Kajsa and Ľubomír Majtás{kajsa,majtas}@fiit.stuba.sk

Design Patterns Instantiation Based on Semantics and Model Transformations

Program of Presentation

Scope and goal of research Introduction Outline of problems Improvement proposal Method of pattern instantiation Realization Implementation Evaluation

Goal and Scope of Research

GOAL: to improve tool based support of design patterns instantiation and consider ideas of model driven, iterative and incremental development of software systems by the method of the pattern support

SCOPE of research: Design patterns

GoF patterns J2EE patterns

OMG standards and specifications Model Driven Architecture (MDA) MOF, UML, UML profily, OCL, XMI, QVT

Design patterns support in existing CASE and modeling tools

Borland Together Architect, IBM Rational Software Modeler, IBM Rational Software Architect, and others…

Introduction Design Patterns

represent abstracted, generalized and verified solutions of non-trivial problems of software design that occur repeatedly.

provide especially effective ways to improve the quality of software systems Since the patterns provide abstracted and generalized solutions, its application to

solve a specific problem requires to concretize and to specialize the solution described by the pattern *

* Návrat, P., Bieliková, M., Smolárová, M.: A technique for modelling design patterns. Knowledge-Based Software Engineering - JCKBSE'98, Smolenice, IOS Press, September 1998, s. 89-97.

Introduction Concretization process

recasts pattern abstract form into concrete realization with all its parts, methods, attributes, etc.

the more parts the structure of the pattern instance contains, the more concrete it becomes

majority of activities of this process depends on stable and fixed definition of the design pattern structure so that these activities are fairly routine.

it is good initial assumption for automation of this process Specialization process

lies typically in integrating of pattern into the specific context of the problem

it requires detailed understanding of the domain context and the specific application itself

this process is difficult to automate, because this knowledge is mainly available to developers and domain experts involved in the design process. Despite this, it is possible to make it much easier by providing an appropriate mechanism for pattern application.

Outline of Problems

Example of Observer pattern application in Borland Together Architect (1)

Sample model of Sample model of developing applicationdeveloping application

The support of design patterns available in traditional CASE or other modeling tools is usually based on UML templates of each design pattern.

Outline of Problems


UML UML template of Observer patterntemplate of Observer pattern Sample model of Sample model of

developing applicationdeveloping application

When pattern instance is created, the template of pattern is simply copied into the model of developing application with a minimal possibility for its modification and integration in the rest of model.

Outline of Problems




Integration of pattern instance is necessary

Lack of specialization process supportLack of specialization process support – it is necessary to integrate the pattern instance into model of developing application.

Outline of Problems




Integration of pattern instance is necessary

Lack of specialization process supportLack of specialization process support – it is necessary to integrate the pattern instance into model of developing application.

UML UML template of Observer patterntemplate of Observer pattern The template provides only one from lot of concrete pattern

structures or variants

Lack of concretization process supportLack of concretization process support – it is not allowed to developer to choose appropriate concrete pattern structure or variant (it is offered only one provided by the template).

Summarization of Problems

The common tools approaches are typically based on strict forward participant generation - participants in all roles are created according to a single template.

There is weak support of the concretization process – adjustments of concrete form of design patterns must be done manually

There is no support of specialization process - the recasting of the general form of the template of pattern into application specific form has to be done manually

There is no support of design pattern variations It is not possible to work with pattern instances at

more levels of abstraction

Improvement Proposal

IDEAS: to emphasize collaboration between the developer and the CASE tool. do not force the developer to model all the pattern participants explicitly. to consider ideas of model driven, iterative, and incremental

development of software systems. the developer only suggests and specifies the pattern instance

occurrence directly in the context while the rest of the instantiation process is automated.

PROPOSAL of pattern instantiation:1. the developer makes a suggestion by the application of semantics as to

where and what design pattern instance they want to apply in the model. 2. the developer specifies which variant of the pattern to use, and in what

way they want it generated. 3. the rest of the pattern instance structure is automatically generated by

model transformations to lower levels of abstraction according to the instance specification.

Method of Instantiation

Model of the pattern

Code template of the pattern

we split transformations and pattern models into more levels of abstraction in accord with ideas of the MDA development process

1. first the developer makes suggestion and specification of platform independent instance of design pattern at highest level of abstraction

2. then he runs transformation to PSM

3. next the developer specifies implementation details (e.g. data types) of pattern instance at platform specific level

4. at last he runs the transformation to source code

the model transformations automate the concretization process and are driven by pattern instance specification and by the pattern model as well.

the developers do not need to take care about concrete implementations details of pattern instances at the highest level of abstraction

Simple example of Observer pattern instantiation (0)

(Step 0) Intention of applying Observer pattern


(Step 1) Suggesting pattern instance occurrence via application of semantic marks - stereotypes(Step 0) Intention of applying Observer pattern

In the first step the developer suggests where and what design pattern instances they want to apply via semantic marks (stereotypes) application in the model – so they suggest the occurrence of instances.


(Step 2) Specifying pattern instance variant and adjustments via setting up values of meta-attributes (tagged values) of stereotypes

In the second optional step the developer specifies which variant of the pattern to use, and in what way he wants it generated – so they choose variant and the adjustments of the pattern instance.

This step is not mandatory because default values of meta-attributes of the stereotype are set and are available.


The developer has created specified platform independent instance of design pattern at highest level of abstraction.

The developers do not need to take care about concrete (implementations) details and can comfortably work with pattern instance at this level of abstraction.

Next he runs the transformation to the lower level of abstraction.


The transformation generate the rest of pattern structure in desired form in accord to pattern instance specification.

The pattern instance is properly specialized and it is in more concrete form now.


(Step 2b) Specifying implementation details of pattern instance

The transformation also adds explicit marks (stereotypes) to all pattern participants. So the developer can repeat the instantiation process at this level (PSM) directly from the

optional second step, i.e. specifying the instance and choosing a more detailed adjustments of pattern instance.



The transformation splits generated source code into two separate packages. The generated package is the base class package which is always overwritten by repeated transformation. The developed package is generated only by initial transformation. The developer can write a custom implementation here without the threat of it being overwritten.

Advanced example of Observer pattern instantiation

The example consists of application of three instances of Observer pattern.


One of instances has the following specification. The method of Observer notification is set as

callback, which mean that the update method of Observer takes Subject reference as parameter and subsequently the Observer gets the state of Subject from obtained reference.


The other two instances have the same specification. The method of Observers notification is set as sending, which mean that the update method of Observer takes as parameter the Subject State reference directly. Next we choose to encapsulate the Subject State as single object.


As we choose to encapsulate the Subject State as single object, we may also select the attributes of Subject which represent its state.


The result of transformation to PSM-Java


Subject State has been encapsulated as single object. Only selected attributes represented the state of Subject have been encapsulated.


Two interfaces of Observer have been generated. One takes Subject reference as update method parameter and the other takes AccountDataState (Subject State) reference.


The Subject abstract class has been generated. The Subject abstract class has been generated. The Subject class distinguishes two different interfaces of Observer.


Next we choose implementation details (for example, we choose java.util.ArrayList as Observer references collection data type in Subject)


Source code of Subject Generated source code of Subject class Implementation of all pattern methods

have been generated. java.util.ArrayList has been used as

Observer references collection data type


Source code of Subject Subject distinguishes two different interfaces of Observer.

First group of Observers takes AccountDataState (Subject State) reference as update method parameter.

Second group of Observers takes Subject reference as update method parameter.

Realization of transformations

Transformations are driven by properly specified and marked models of design patterns.

These prepared models cover all supported pattern variants and possible modifications.

Elements of these models are marked by stereotypes. There are two types of marks in pattern models:

Sample section of pattern model of Observer

The first type of marks - expresses the role of the element in the scope of the pattern. On the basis of this type of marks the transformation is capable of creating mappings between model of developing application and model of pattern.


The second type of marks - expresses an association of the element with the variant of the pattern. On the basis of this type of marks the transformation is capable of deciding which element should be generated into the model and which does not.


For the second type of marks the following notation has been defined: [~]?StereotypeName::Meta-attributeName::value; (“~” expresses negation “;” expresses AND)

An element from the pattern model is generated into the model only if the specified meta-attribute of the specified stereotype has set the specified value by the developer. If an element has no mark, it will be always generated into the model.









Sample modification of Observer pattern model

The developer is enabled to modify the pattern models by which the transformation is driven and in this way to model any custom model structure, or even to create a new one and achieve the tool based support for application of this structure. In consequence, the method provide also framework for addition of support for other custom model structures which are often created in models mechanically.

Realization of marks

we choose the semantical extension of UML in a form of UML profile as a standard extension of UML meta-model, since one of our goals is to remain compliant with the majority of other UML tools.

UML profiles provide a standard way to extend the UML meta-model semantics in the form of definitions of stereotypes, tagged values - meta-attributes of stereotypes, enumeration and constraints.

all these elements can be applied directly to specific model elements such as Classes, Attributes, and Operations and in this way it is possible to specify participants of design patterns and relations between them directly in the context (on the elements of the application model).

Authored UML profiles provide semantics to various pattern instance adjustments, suggestions and specifications.

It is not mandatory to apply all the semantics elements (stereotypes). The developer applies and specifies only what he needs to express.

Because of the default values of meta-attributes of stereotypes, the transformation always has enough information for default behavior

Inconsistent specifications of pattern instances are handled by OCL constraints which are part of UML profile as well.

Sample section of UML profile

Constraints: Context DesignPatternsProfile::Observesinv self.modelOfNotification=DesignPatternsProfile::ModelsOfNotification:: sending implies self.encapsulateSubjectState=true

Tagged values or meta-attributes of stereotypes.

Metaclass for which are stereotype designated.

Each tagged value has its own type e.g. Booleanor Enumeration and so.

Implementation Tool has been implemented as an IBM Rational Software Modeler transformation

plug-in. Architecture of implemented tool:

The following features have been implemented:Semantics in the UML profile for the patterns Factory Method, Decorator, Observer, Chain of Responsibility and MediatorTransformation of the highest level of abstraction (PIM) to the lower level (PSM - Java) and transformation of PSM to source code (Java)Incremental consistency check mechanismVisualization of pattern instances and its participants Pattern models for the patterns Factory Method, Decorator, Observer, Chain of Responsibility and Mediator

Evaluation The presented approach:

supports specialization of pattern instances. It is possible to specify participants of design patterns and relations between them directly in the context (on the elements of the application model).

supports and automates concretization of pattern instances via model transformations to lower levels of abstraction.

pattern instances are supported at three levels of abstraction (Pattern suggestion and specification level – PIM, Design model level – PSM and Source code level).

supports variability of patterns. A developer is allowed to decide which concrete form or desired variant of a pattern instance he wishes to generate into a model.

considers the three most important characteristics of model driven development. Adjustability – by allowing the control and adjustment of the results of model

transformations. Incremental consistency – element with an identical definition, it is not

duplicated, but instead, it is switched, and by separating the generated source code into two packages of classes, generated and developed.

Traceability – by automatically explicitly marking all participants of pattern instances after model transformations.

is compliant with majority of other UML tools.

Thanks for your attention

Thanks for your attention


The transformation also adds explicit marks (stereotypes) to all pattern participants. So the developer can repeat the instantiation process at this level (PSM) directly from the

optional second step, i.e. specifying the instance and choosing a more detailed adjustments of pattern instance.


The Subject abstract class has been generated. The Subject class distinguishes two different interfaces of Observer.

Sample section of pattern model of Observer pattern


Transformations are driven by properly specified and marked models of design patterns.

These prepared models cover all supported pattern variants and possible modifications.

Elements of these models are marked by stereotypes. There are two types of marks in pattern models.

The first type of marks expresses the role of the element in the scope of the pattern. On the basis of this type of mark the tool is capable of creating mappings between models.

The second type of marks expresses an association of the element with the variant of the pattern. On the basis of this type of mark the tool is capable of deciding which element should be generated into the model, and in which way and in what form.

For the second type of mark the following notation is defined: [~]?StereotypeName::Meta-attributeName::value;

An element from the pattern model is generated into the model only if the specified meta-attribute of the specified stereotype has the specified value. These marks can be joined via “;”, while the symbol “~” expresses negation. If an element has no mark, it will be always generated into the model.



Authored UML profiles provide semantics to various pattern instance adjustments, suggestions and specifications.

It is not mandatory to apply all the semantics elements (stereotypes). The developer applies and specifies only what he needs to express.

Because of the default values of meta-attributes of stereotypes, the transformation always has enough information for default behavior


Tagged values or meta-attributes of stereotypes.


Each tagged value has its own type e.g. Booleanor Enumeration and so.

Stereotype can be applied only on instance of meta-class for which is designated. When a stereotype is applied in the model, its instance is created. Each instance of stereotype can have set own values of its meta-attributes.

Documents

Faculty of Informatics and Information Technologies Slovak University of Technology