Mika Siikarla

Transformations Have to be Developed ReST Assured

Model transformations do not simply appear. They have to be not-so-simply developed. In early phases of development, there may exist only an intuition or an educated guess on some of the characteristics of the transformation. Instead of assuming a pre-existing complete transformation specification, we embrace change and develop transformations incrementally, gradually refining them into more complete ones as the body of knowledge of the domain grows. We present an iterative process encompassing requirements capture, design and implementation of model transformations. We describe partial transformations as so called transformational patterns and iteratively refine them. We apply the approach to developing a transformation that is used in building APIs that comply with the ReST architectural style.

Combining OCL and Programming Languages for UML Model Processing

Model processing tasks, like model checking, merging, slicing, and synthesis, need ecien t and maintainable mechanisms to dene models, as well as to query, compare and manipulate information in them. Although the Object Constraint Language (OCL) is primarily meant for expressing constraints for UML models, it can also be used for various model processing purposes. In this paper we discuss the needs for, and possibilities of, using OCL for processing models, and show how we have applied and extended OCL. We also introduce a model processing tool using OCL as an integral part of model manipulation facilities. We especially emphasise the need of combined use of OCL and programming languages in UML model processing.

Variation Needs in Service-Based Systems

Even though service-orientation has been widely applied, there still is a lack of systematic and tool independent development methods. Partly due to that, little attention has been paid to accounting for variation. When developing a service-based system, it is important to identify which types of variation are relevant for the project and when is the right time to model them. If the variation needs are not recognized or they are ignored, it may hinder applicability and reuse and results in inflexible systems. If they are considered too late, it may require a lot of redecisions and rework. In this paper we explore variation needs in terms of the development process of service-based systems. This study results in a categorization of variation in service-based systems. We illustrate the categorization in a small example in telecommunication area.

Transformational Pattern System -- Some Assembly Required

In the context of Model Driven Architecture (MDA), most model transformation mechanisms aim for rigorously and unambiguously defined, fully automatic transformations. We argue that such techniques, even when fully mature, are not applicable in all cases of software development. These difficult cases would benefit from flexible and semi-automatic open transformations. We present a mechanism, so called transformational pattern system, and show how it can combine human made decisions and intentionally vague and incomplete rules to perform a transformation.

Decision Reuse in an Interactive Model Transformation

Propagating incremental changes and maintaining traceability are challenges for interactive model transformations, i.e. ones that combine automation with user decisions. After evolutionary changes to the source models the transformations have to be rerun. Earlier decisions cannot be used directly, because they may have been affected by the changes. Re-doing or verifying each decision manually is error-prone and burdensome. We present a way to model user interaction for transformations that are well (but not fully) understood. We model each decision as a set of options and their consequences. Also, we model the decision context, i.e. the circumstances (including model elements) affecting the decision. When a transformation is run, user decisions and their context are recorded. After a model change, a decision can be safely reused without burdening the user, if its context has not changed. The context maps source model elements to a decision, and thus provides traceability across the decision.

Open MDA using transformational patterns

No generally accepted understanding on the characteristics of MDA transformation mechanisms exists. Various approaches to support such transformations have been proposed. In this paper, we discuss general requirements for MDA transformation mechanisms. We claim that, above all else, transformation mechanisms should be open, i.e. clear, transparent and user-guided. We propose a new concept, a transformational pattern, as a basis of an MDA transformation mechanism. We exploit existing tool support for this concept and show a small example of how it can be applied. Finally, we analyse the ability of the proposed technique to fill the requirements.