2.4 Model driven approaches and Architecture
2.4.4 eXecutable and Translatable UML (
2.4.5.1 Models and transformations
There are two possible transformations that can be identified with respect to model driven approaches. They are known asHorizontal Transformation and Vertical Transformation Punter et al.[2008], which are illustrated in Figure 2.14.
Horizontal Transformation V ertical T ransformation Abstract Model(n)
Abstract Abstract Model(n+1)
Concrete Model(n) Concrete Model(n+1)
Implementation Model(n)
Implementation Implementation Model(n+1)
Figure 2.14: Horizontal and vertical transformations of models,Rech et al.[2009]. The identification of transformation depends on the direction in which it is happening. If it is happening from a higher-level to a lower-level (or vice versa), it is known asVerticaltrans- formation; for example, transformation from PIM to PSM or PSM to Code. Even reverse engi- neering code to obtain the high level models is considered as vertical transformation. Contrary to this,Horizontaltransformation occurs when the transformation happens at the same level. In the case of horizontal transformations, the transforming is usually between models at the same level; i.e. between two abstract models of the same hierarchical level. Typical examples of this include code refactoring and code refinement, where one model is transformed into another at the same level based on the business needs.
Irrespective of the type of transformation, there are a few quality parameters present across all of them. Table 2.8 summarises some of theMDSD factorsthat have an effect on different QAs, from the point of view of three types of transformation techniques,Rech et al.[2009]:
1. Horizontal transformation approach – proposed byRöttger et al.[2004], uses partial au- tomation techniques (to transform context models) to provide good response times in mod- els by refining them.
2. Horizontal approach – proposed by Merilinna et al. [2004], uses complete automation techniques (to transform architectural models), in order to provide better performance and reliability in models by refactoring them. This approach is good to use during the evalu- ation of architectural facts.
2.4. MODEL DRIVEN APPROACHES AND ARCHITECTURE
3. Vertical approach – proposed byKurtev[2005], uses complete automation (e.g. for UML models) to provide better adaptable models by synthesising them.
CHAPTER
2.
BACKGROUND
Input Quality
Proposal Purpose Type of artefact attributes Automation
Zou et al.[2003] Reverse engi-
neering (mi- gration)
Vertical (CM- to-PIM)
Program Code Coupling and co-
hesion
No
Röttger et al.[2004] Refinement Horizontal Context models Response time Partial
Merilinna[2005] Refactoring Horizontal
(PIM-to-PIM) Architectural mod- els Performance, availability, reliability Yes
Kurtev[2005] Synthesis Vertical (PIM-
to-PIM)
UML class models Adaptability Yes (Mistral)
Markovic et al.[2005] Refactoring Horizontal (PIM-to-PIM)
UML class models Syntactical correctness
No
Sottet et al.[2006] – – Interface models Compatibility,
error protection, homogeneity- consistency
No
Ivkovic et al.[2006] Refactoring Horizontal
(PIM-to-PIM) Architectural mod- els expressed in UML Maintenance, performance and security No
Kerhervé et al.[2006] Synthesis, re- finement
Horizontal and Vertical
Information models Response time,
network de-
lay, network
bandwidth
2.4. MODEL DRIVEN APPROACHES AND ARCHITECTURE
Patterns and Transformation:
Each of the techniques mentioned in Table 2.8 takes an input model and converts it into an output model, except for the first approach byZou et al.[2003], which reverses the code to get models. The transformation process is accomplished with the help of supporting transformation tools and techniques.
Some of the tools and engines used for this purpose make use of certain patterns and styles to achieve the transformation. Figure 2.15 illustrates the relationships between models - models, and models - real world elements (domains), while Figure 2.16 illustrates the implementation of the observer pattern (as an example), which shows the transformation from one model to another, along with the dependency between GUIs and entities.!
! ! ! ! ! ! ! ! !"#$%&'(')&*+,"-./0"1'2&,3&&.'4-5&*/'+.5'%&+*'3-%*5'' ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !
"#$%&'!
()*%+!,#-+.!*+*$*'/01!2#.*+!
(2#.*+!*+*$*'/01!2*/%!2#.*+!
(2*/%!2#.*+! 3+*$*'/01!4%-5*/!
(6-/7%8/09!*:5!;#.*1! "*08-&< *0! "*08-&< *0! 4- %' 07# -% /&# $! !"#$%&'(#)*+,# -.*/01%.)*-2%/#(2.,$-# 1.%)#3%(,'0#42-5%&-# /,,(#%1#),-*)%(,'#21#4,# 5*6,#*''#/,$,00*.7# 2/1%.)*-2%/#%/#-5,# )%(,'0#Figure 2.15: Relationship between models and real world.
Sometimes, the output models may have properties which are different from the input mod- els. In those cases, patterns may be used to create the output models with precision and desired quality. For example, while converting general domain models (e.g. architectural models) to specific models (e.g. quality model), the reusability metrics must be maintained, as discussed by Becker[2008] andMoreno et al.[2008] performance model in Section 2.5.3.6. Also the struc- tures in the models corresponding to the solution structure provided by a particular pattern are created using transformations. There are several aspects or forces which affect the applicability of a pattern, such as its qualities,Schumacher et al.[2006]. Also, there are several variations of each pattern which can be used according to the needs, as each variation often comes with some advantages and drawbacks. The user of the pattern has to study these and take the design decisions accordingly,Stahl et al.[2006].
Utilising MDSD approaches makes it easy to use patterns in some situations by providing code generation features with the help of models. For example, to create manually the depen- dencies and event registrations along with notifications for the observer pattern in the code is a difficult job. It is much easier to create models which represent these aspects and generate the code from those models. It may be necessary occasionally to customise or extend the pattern
GU Domain Metamodel Report View Entity (Open) «observ es» «interface» EntityObserver entityChanged() Target MetaModel GUIBase entityChanged() Report Base View Base Dialog Base
Entity Implementation Base addObserver(observer o) removeObserver(observer o) Update();
Figure 2.16: Domain Meta-Model-To-Target Meta-Model Transformation (for the Observer
Pattern and the dependencies between GUI and Entities are clear in both models), Stahl et
al.[2006].
based models to enable code generation.
While using patterns in the model driven environment, it is important to segregate the ap- plication and transformation models since the pattern usage is different for each. The decisions regarding the patterns in transformations must be made by the developer who creates the trans- formations, and the application developer needs to make decisions about the implementation details of those patterns. Pattern description and documentation issues are discussed in Chap- ters 3 and 4.
2.4.5.2 Pattern Languages with respect to SA (in brief)
Pattern languages are generally groups of patterns intended to solve a particular problem which might be complex and too minute to be solved by normal meansGreenfield et al.[2004]. Some examples of pattern languages are Enterprise Application Architecture Patterns, Fowler et al. [2003], Security Patterns, Schumacher et al.[2006] and Remoting patterns, Greenfield et al.[2004].
These groups of patterns shall usually be well-defined and sequential. Each pattern is de- pendent upon the preceding pattern and hence the dependencies also should be well-defined. However, these patterns are indicative of the system’s behaviour. They are designed to solve common problems within the system. Hence, it is a good approach to describing, combining, and classifying SPs. On the other hand, the Gang of Four (GoF) and Pattern-Oriented Software
2.4. MODEL DRIVEN APPROACHES AND ARCHITECTURE
Architectures (POSA) patterns are more generic and it is possible to use any pattern independent of the others.
However, according toAlexander et al. [1977]: “No pattern is an isolated entity. Each pattern can exist … only to the extent that it is supported by other patterns. So, patterns are not individual independent entities and any pattern can exist only when it receives support from other patterns.” Patterns can form much of any architecture, that’s why it is important to this research objective, as can be seen from the analysis of the RCS-reference model in Chapter 6.
The use of UML macro definitions is to create models that are sometimes defined as pat- terns by certain tools and modelling approaches. However, many dispute this because a pattern is considered to be much more complex,Greenfield et al.[2004]. At the same time, it is agreed that building groups of patterns which address some generic problem makes their usage and in- tegration much easier with systems. For example, the Enterprise Data Model built bySilverston et al.[2009] using patterns, aims to solve the problems related to the enterprise architecture and database domains.
The strengths and weaknesses of these kinds of approaches are described below:
1. Strengths – They provide a good balance between creation of general patterns to solve specific needs. They are consistent and easy to integrate.
2. Weaknesses – It is difficult to arrive at a common modelling style as there are several levels and layers of patterns involved. Also, it is difficult to understand the rules regarding pattern usage, because several models with multiple levels of details are combined together. Despite the weaknesses of some of these approaches, the idea of pattern languages is still useful when it comes to modelling and automation. According to Schmidt et al. [2000] and Greenfield et al.[2004], the main features that should be present in a pattern language are:
1. The language should provide patterns which deal with all aspects of software development, such as architecture specification, architecture refining and system implementation. 2. The patterns should be created according to some common schema so that all the patterns
in the family are consistent with each other and can be searched and compared easily. 3. All the relationships between a family of patterns, such as dependencies, associations,
extensions and containment, should be well-defined and known.
4. The structure should be easy to navigate and to provide alternate options.
5. Implementation guidelines should be well-defined and documented so that the patterns can be easily implemented within applications.
6. The patterns should expose information about their structure, rules, etc., so that they can be modified easily if needed.
Pattern languages are useful for the creation of meta-model elements, which are needed in the creation of Domain Specific Language (DSL). For example, in the case of a Remoting pattern implementation in order to generate remoting infrastructure elements, pattern languages
are useful to identify the elements that need to be represented by DSL. Some of these elements are interfaces, invoker, request handlers for client and server, pooling, leasing elements for Life- Cycles, and communication elements, such as callbacks and poll objects. For all these elements, the pattern languages can be useful in identifying the configurable factors for each. Other in- formation concerning the elements, such as their structure and their relationships, can also be encompassed in a meta-model using DSL.
All this proves the usefulness of patterns with respect to the model driven approach. How- ever, according toLange et al.[2005] andRech et al.[2009], quality concerns related to indi- vidual patterns and merging of patterns, interfacing between patterns, etc., still remain unclear. Chapters 3 and 4 of this thesis will explore some of these concerns.
• Pattern Family is a subset of Pattern Language:
According toAlexander [1979], patterns in problems often lead to the discovery of solu- tion patterns. Also, pattern families help in finding reusable generic solutions to several domain related problems irrespective of the field and sub-domainsGreenfield et al.[2004]. Aa an ex- ample, the Remoting PatternsVölter et al.[2004] and the Security patternsSchumacher et al. [2006] are patterns that combine to work together inside the same domain, whereas in case of the Garland family of patterns (described byShaw et al.[1996]) every family is considered as a single pattern with several components such as the case in the Client-Server family. Each family is made up of three elements: Property types, Constraints, and Structures.
According toSchmidt et al.[2000] (POSA-V2), many of the popular patterns are merely used for the creation of frameworks and hence those frameworks can be considered as concrete implementations of the abstract patterns. In fact, most of the efficient frameworks are made up of several pattern implementations,Greenfield et al.[2004]. Similar to the pattern families, the modelling languages can also be combined together to form a blueprint for domain specific software development. Due to these features, modelling languages are considered to be more efficient and feature-rich as compared to normal programming languages. With this in mind, it might be a good idea to consider the generation of frameworks as pattern families. A group of patterns working together to achieve a common goal can be implemented together to cre- ate a framework with automation techniques. For example, distributed applications often use web services and web methods. Patterns can be used to implement these requirements and a combined framework may be generated to be utilised by the distributed applications on various platforms.
Studies have also shown that as the level of abstraction increases, the contribution towards solving a problem decreasesGreenfield et al.[2004]. However, the decrease in patterns utili- sation to solve problems, is affected by other factors other than abstraction levels, as described in Chapter 4. Keeping this in mind during pattern creation and implementation, the scope of the problem needs to be kept narrow in order to increase the applicability of the patterns. Most of the earlier patterns mentioned in theGoF Book, and POSA-V1 are quite broad and generic
2.4. MODEL DRIVEN APPROACHES AND ARCHITECTURE
in nature ,while most of the newer patterns are more specific to a particular problem domain. For example, security patterns deal with the problems associated with the security domain. The patterns defined by POSA-V2 have been categorised as pattern languages and pattern systems, as explained in Chapter 3. However, the informal details provided for these patterns, and several other patterns as well, are not sufficient for quality measurements or for automations. Measure- ment of quality is a notable concern in most cases.
• Weaving patterns into languages:
The references available about patterns are not sufficient to explain how to use patterns or to create solutions for problems,Greenfield et al.[2004]. Also, patterns are extremely important to create models and to address quality related issues. TheKim et al.[2006] workshop tried to address some of these issues with the help of the Alloy tool. This workshop also tried to address mapping specifications between architectures and models, while maintaining properties like consistency, reliability, and style compliance.
The patterns development trend in the last two decades is focusing more towards the de- velopment of pattern families and languages as opposed to individual patterns,Schmidt et al. [2000],Schumacher et al.[2006],Manolescu et al.[2006] ,Zimmermann et al.[2008],Schmidt et al.[2013]. Combining several patterns into one language is known as weaving patterns into languages. It has also been predicted that pattern languages are the way forward for solving domain specific concerns and coarse problems,Greenfield et al.[2004].
A pattern language could be considered as a way to define modelling languages. Most of the formal languages are made up of several patterns which are already in use by other languages. For example, languages like C# and Java are made up of properties, events, delegates, etc. The definitions of these patterns can be used by the compiler to generate implementation details. The main difference between the pattern language and modelling language is that the implementa- tions details are exposed in the case of pattern languages whereas they are encapsulated partially or completely in the case of modelling languages.
2.4.6
Conclusion
In the context of Software Architecture (SA), this section explored model driven approaches and their different flavours. It also explored the importance of patterns with respect to the model driven approach in terms of domain models and transformation models. The grouping of patterns into families and languages was also discussed along with their relationship with the modelling methods. To conclude this section, it has been found that the MDSD and SPs are important technologies that could help in improving the field of SA description and evaluation.