Faculty of Informatics and Information Technologies Slovak University of Technology Peter Kajsa and Ľubomír Majtás 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

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

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

Outline of Problems Example of Observer pattern application in Borland Together Architect (4) UML template of Observer pattern Sample model of developing application Integration of pattern instance is necessary Lack of specialization process support Lack of specialization process support – it is necessary to integrate the pattern instance into model of developing application. UML template of Observer pattern The template provides only one from lot of concrete pattern structures or variants Lack of concretization process support 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).

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

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

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.

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.

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.

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.

Simple example of Observer pattern instantiation (6)

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.

Advanced example of Observer pattern instantiation  The example consists of application of three instances of Observer pattern.

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.

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.

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.

Advanced example of Observer pattern instantiation  The result of transformation to PSM-Java

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.

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.

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.

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)

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

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

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.

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

Realization of transformations

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::Observes inv 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. Boolean or 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 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

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

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.

Advanced example of Observer pattern instantiation  The Subject abstract class has been generated. The Subject class distinguishes two different interfaces of Observer.

Sample section of pattern model of Observer pattern

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: [~]?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.

Sample section of UML profile Metaclass for which are stereotype designated.  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

Sample section of UML profile Tagged values or meta-attributes of stereotypes. Metaclass for which are stereotype designated. Each tagged value has its own type e.g. Boolean or 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.