Faculty of Informatics and Information Technologies Slovak University of Technology

1
Faculty of Informatics and Information
Technologies Slovak University of Technology
Design Patterns Instantiation Based on Semantics
and Model Transformations

• Peter Kajsa and Lubomír Majtás
• kajsa,majtas_at_fiit.stuba.sk

2
Program of Presentation

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

3
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

4
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.
5
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.

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

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

Sample model of developing application
7
Outline of Problems
Example of Observer pattern application in
Borland Together Architect (2)

• UML template of Observer pattern

Sample model of developing 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.

8
Outline of Problems
Example of Observer pattern application in
Borland Together Architect (3)

• UML template of Observer pattern

Sample model of developing application
Integration of pattern instance is necessary
Lack of specialization process support it is
necessary to integrate the pattern instance into
model of developing application.
9
Outline of Problems
Example of Observer pattern application in
Borland Together Architect (4)

• UML template of Observer pattern

• UML template of Observer pattern
• The template provides only one from lot of
  concrete pattern
• structures or variants

Sample model of developing application
Integration of pattern instance is necessary
Lack of specialization process support it is
necessary to integrate the pattern instance into
model of developing application.
Lack 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).
10
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

11
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
• 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.
• the developer specifies which variant of the
  pattern to use, and in what way they want it
  generated.
• the rest of the pattern instance structure is
  automatically generated by model transformations
  to lower levels of abstraction according to the
  instance specification.

12
Method of Instantiation

• 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

Model of the pattern
Code template of the pattern

• 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

13
Simple example of Observer pattern instantiation
(0)
(Step 0) Intention of applying Observer pattern
14
Simple example of Observer pattern instantiation
(1)
(Step 0) Intention of applying Observer pattern
(Step 1) Suggesting pattern instance occurrence
via application of semantic marks - stereotypes

• 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.

15
Simple example of Observer pattern instantiation
(2)
(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.

16
Simple example of Observer pattern instantiation
(3)

• 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.

17
Simple example of Observer pattern instantiation
(4)

• 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.

18
Simple example of Observer pattern instantiation
(5)
(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.

19
Simple example of Observer pattern instantiation
(6)
20
Simple example of Observer pattern instantiation
(7)
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.
21
Advanced example of Observer pattern
instantiation

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

22
Advanced example of Observer pattern
instantiation

• 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.

23
Advanced example of Observer pattern
instantiation

• 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.

24
Advanced example of Observer pattern
instantiation

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

25
Advanced example of Observer pattern
instantiation

• The result of transformation to PSM-Java

26
Advanced example of Observer pattern
instantiation

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

27
Advanced example of Observer pattern
instantiation

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

28
Advanced example of Observer pattern
instantiation

• The Subject abstract class has been generated.

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

29
Advanced example of Observer pattern
instantiation

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

30
Advanced example of Observer pattern
instantiation

• 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
31
Advanced example of Observer pattern
instantiation

• 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.

Source code of Subject
32
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

33
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.
34
Sample section of pattern model of Observer
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.

35
Sample section of pattern model of Observer

• For the second type of marks the following
  notation has been defined
• ?StereotypeNameMeta-attributeNamevalue
  ( 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.

36
Realization of transformations
37
Realization of transformations
38
Realization of transformations
39
Realization of transformations
40
Realization of transformations
41
Realization of transformations
42
Realization of transformations
43
Realization of transformations
44
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.

45
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).

46
Sample section of UML profile

• 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.

Metaclass for which are stereotype designated.
Tagged values or meta-attributes of stereotypes.

Each tagged value has its own type e.g.
Boolean or Enumeration and so.
Constraints Context DesignPatternsProfileObserv
es inv self.modelOfNotificationDesignPatternsProf
ileModelsOfNotification sending implies
self.encapsulateSubjectStatetrue
47
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 Mediator
• Transformation of the highest level of
  abstraction (PIM) to the lower level (PSM - Java)
  and transformation of PSM to source code (Java)
• Incremental consistency check mechanism
• Visualization of pattern instances and its
  participants
• Pattern models for the patterns Factory Method,
  Decorator, Observer, Chain of Responsibility and
  Mediator

48
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.

49

• Thanks for your attention

50
Thanks for your attention
51
Simple example of Observer pattern instantiation
(5)

• 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.

52
Advanced example of Observer pattern
instantiation

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

53
Sample section of pattern model of Observer
pattern
54
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.
• 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
• ?StereotypeNameMeta-attributeNamevalue
• 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.

55
Sample section of UML profile

• 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

Metaclass for which are stereotype designated.
56
Sample section of UML profile

• 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.

Metaclass for which are stereotype designated.
Tagged values or meta-attributes of stereotypes.

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