Integrating Non-Functional Properties in Model Driven Development: A Stepwise Refinement View

Published Online August 2012 in MECS DOI: 10.5815/ijitcs.2012.09.01

Even if the commissioned component is delivered without NFR specification, it can be reconstructed by reverse engineering methods such as static code analysis and analyses of execution traces [5]. However, as such a reconstructed NFR description can differ from a manually specified one; the refinement calculus still is needed to show the compliance.

The notion of model transformation is an essential element for MDA aiming at automated model transformation. Transformations may be bi-directional. Four different types of transformation are introduced in MDA: PIM to PIM, PIM to PSM, PSM to PSM and PSM to PIM to [6]. He refines the definition of transformation by classifying transformations into two categories: horizontal and vertical. Figure 1 summarizes the relationships of the different types of transformations. It is hard to define a fixed number of PIMs and PSMs for software systems. For example, models may be written with various modeling languages, e.g. UML and ADLs (Architecture Description Language), resulting in several models at the same level of abstraction and for several platforms (e.g. Java and CORBA), which, leads to several PIMs with low different level of abstraction.

Fig 1: Different levels of abstraction in model driven engineering

Domain-Specific Modeling (DSM) has become an important part of Model-Driven Engineering (MDE) to address the complexity of software systems. A DomainSpecific Modeling can be used to declaratively define a software system with specific domain parameter and specific Non-functional requirements according to the business problem. Various software artifacts (e.g., code, simulation scripts and XML deployment description files) can be generated automatically from the models. By increasing the level of abstraction, DSM leads to hold key rational assets from technology obsolescence, resulting in low-level details to specify a given system, which can lead toward improvements for supporting end-user [7].

• III.    Related Work

• 3.1    UML-based methods

• 3.2    Formal methods

• 3.3    Hybrid ethods

Traditionally, there are two methods to model and refine behaviors, including UML-based methods and formal methods. Recently integrated methods have received increasing attention by taking full advantage of UML and formal methods. Some representatives are reviewed as follows [8]:

Based on the UML specifications, codes can be generated automatically through stepwise model refinement, using Model-Driven Architecture (MDA) technology, and this process is measurable [9]. Many researchers have worked on the refinement theory and methodology for UML-based modeling. In [10] a tool to support the refinement of non-functional constraints in UML models has been provided [4]. It formally defines the relationship between the behavior inheritance consistency of a refined model and the behavioral preservation of a refactored model according to the original model.

Several authors have proposed to model NFRs using UML extensions [1] [11], including the OMG standard UML profiles MARTE [12] and QoS-Profile [13]. Others designed a specific meta-model to present NFRs [14] [15].

Formal specifications can be used to provide a precise supplement to natural language, and can be validated and verified, so leading to the early detection of software specification errors. From early research about proving correctness of programs, such as [16] and [17], a refinement calculus of specifications to codes has developed. Such as the refinement of Z [18] B [19], Event-B [20], ASM [21], etc has been proposed. The refinement calculus, developed independently by Morgan [22] [23] and Morris [24], provides a uniform method for deriving programs from specifications.

Actually automatism is not one of the traditional focuses in the researches of formal modeling and refinement. Besides, there are too many possible directions for each refinement step, and thus it is difficult to achieve efficient automatics for refinement without context and constraints.

Given a set of NFRs, [14] proposes a set of patterns that satisfy QoS requirements through model transformation.

In [25], the proposed patterns consider architectural aspects. Other examples are [26] and [27]. In these approaches each kind of NFR may be seen as a whole dimension of the software. [28] and [29] propose analyzing each NFR type separately and also to use different abstraction levels for NFRs (at CIM, PIM and PSM levels). As a conclusion, we may say that although several valuable approaches have been proposed that deal with NFRs in the MDD process, none of them propose a stepwise integrated refinement view, which is the goal of this paper.

• IV.    Non-Functional Property-Driven Software Engineering Approach

The approach we propose in this paper originates from, and contributes to, a broader research framework, which we refer to as a Non-Functional Property-Driven Software Engineering Approach. The roadmap in fact defines an enhanced model-driven software engineering approach where, among the others, models of nonfunctional properties become first-class entities beside functional properties. The considered non-functional properties describe both characteristics owned by a software system or by parts of it and non-functional requirements the developed software system must satisfy. Figure 2 graphically illustrates the approach by showing the process underlying it. In the figure 2, boxes represent different levels of abstractions, inspired by four layers MOF architecture, bold arrows labeled with meaning ”conform to” represent the conformance relation between the models and the relative metamodel; and, finally, simple arrows show the control flow of the process.

The process in Figure 2 is divided into three parts or integrated field: i) Property Modeling; ii) Improvementbased Software Engineering; iii) Model-Driven Software Engineering.

In the sub-process of property modeling the nonfunctional properties, include descriptive and prescriptive. Also a non-functional property can be quantitative or qualitative. The former needs to specify the metrics used to quantify it and qualitative properties are related to the concept like security that cannot be measured exactly [30].

Fig 2: quality-driven model driven engineering

Several attempts have been made to define common non-functional property definition formalism, but the most promising is the upcoming UML MARTE profile. The NFP package of the profile contains a generic meta-model for the definition of NFPs; including qualitative and quantitative ones (Figure 3). The Non-

Fig 3: A customized non-functional meta-model

There are two sides to develop systems with nonfunctional properties: Component developers must implement components in such a way that they have determinable non-functional properties and application

Functional Property has three optional attributes that NFP type, NFP Value Specification and Unit. These properties can be instantiated and attached to any model element of the system model in order to express new aspects of non-functional characteristics.

designers and the runtime system must use these components so that the non-functional properties required from the application can be guaranteed.

We are not primarily interested in how components must be implemented. Instead, we assume a model-driven development approach with determinable and first entity non-functional properties to be available. Based on this, we provide a framework, which allows

• •    Component developers to describe the nonfunctional properties of the components they have developed, and

• •    Application designers to describe how these components are used to provide guaranteed nonfunctional properties of an application.

• 4.1    Refinement of NFR using model transformation

Figure 5 illustrates refinement as a process of transforming an abstract model into a specified design using a sequence of design decision. This is a mapping process between a high-level, abstracted representation and its successive specified descriptions. In the computational refinement of the class of designs, inheritance can be employed as a technique to maintain class characteristics. One of choice to trade off between different NFR at architecture level is using ATAM. Architecture Trade-off Analysis Method (ATAM) [31] is a scenario-based software architecture evaluation method. The goals of the method are to evaluate an architecture level design that takes into account multiple quality properties and to gain insight to whether the implementation of the architecture will meet its requirements.

A rule-based formalism provides computational means to achieve refinement. This is illustrated in figure 5 which is a rule-based representation of the refinement.

Transformations should be developed along a cycle ranging from platform-independent transformations down to platform-specific transformations. Platforms here should be understood as the tools that allow the specification, design and execution of transformations. Such tools may provide various languages to express platform-specific transformations such as J, Visual Basic, or XSLT [32]. This is in line with the separation of concerns between PIM and PSM in the MDA, and leads to the concepts of platform independent transformation (PIT) and platform specific transformation    (PST). Platform independent transformations are models of the transformation program, relying on a generic library of simpler transformations and transformation primitives. They will be refined to the point where they can be used as the source to generate platform specific transformations. Then if UML is the language of PIT, PSTs are models of tool specific formalisms or API. For example, while XSLT is a textual language, it is possible to consider a MOF-compliant meta-model of XSLT; the PST is then an XSLT model which is serialized out of sight to its XML representation.

The transformation template in figure 4 demonstrates that existing transformation language rules convert one pre-pattern to one post-pattern. However, an extension is required to support selection between consequent patterns based on an input NFP policy specification. This also shows that the transformation can be defined concisely and largely in a declarative manner, with a complex formal specification of component and connector behavior contained separately in the different ADL repository. Source and target of a transformation rule may be any two levels of the refinement schema in figure 4.

The tracing of transformation between different level results back to a Trace link(S,T) relation . These are applications of tracing technique in MDE. This has to be taken into account when transforming a PIM_NF into a PSM NF .

Transformation rules

Source Pattern

Match precondition in source model

Precondition }

Target Pattern

Match postcondition target model

Postcondition

}

Add Traceability Link between Source and Target elements Trace link(Source, Target)

Fig 4: Customizable model to model transformation

• V.    Non-Functional Requirement Model-Driven Development

The proposed framework to integrate non-functional property in model driven development has been shown in the figure 5. It has four levels of abstraction:

PIM_NF :  Non-Functional Platform Independent

Model is a representation of the business logics of the system along with estimates of non-functional characteristics, such as the amount of resources that the logic needs to be executed. The model must be expressed through a notation that allows the specific type of analysis) e.g., Queuing Networks for performance analysis, or Bayesian Belief Networks for reliability analysis (In some cases, it is not possible to obtain numerical values for platform independent nonfunctional analysis. This is due to the relation between typical non-functional metrics (such as response time) and platform characteristics (such as network latency) that are not available in a PIMNF. Therefore, within the

PIM NF class we intend to represent models that permit to estimate certain metrics with an acceptable degree of approximation. Relying on the measured metrics and on the data available about the model parameters, a PIM_NF evaluation can represent a good support to early development decisions.

Domain experts can specify a system's usage in terms of workload, user behavior and parameters (i.e., abstract characterizations of the parameter instances

РЯ—-..

PIMNF/PSMNF

Detail of Platform Technology''.РЯ

--РЯ

PSMNF

PSMNF

PSMNF

Obtain the Code

CODEnF

CODEnF

CODEnF

Design Decision /Design Trade-off

PIMNF

PIMNF/PSMNF

Fig 5: The approach for non-functional model-driven architecture framework

users utilize). Software architects may also construct usage models from requirements documents.

This pure abstract behavior model is at the top of its refinement process, which cannot be the refinement model of any other behavior models; an implementation model is at the bottom of its refinement process, which cannot be refined by any other behavior models.

PIM NF /PSM NF : The value of this layer is twofold: firstly, it makes easy analysis, communication and understanding of the system design at a higher level than detail of platform and code. Secondly, in the transformation from PSM to code, the PSM can act as a PIM (independent of programming language abstractions), allowing multiple mappings from model to code. This level makes the approach more flexible. Since the Non-functional property implementation of a component is influenced by many factors according to the architectural design decision and trade off between requirements (using methods like ATAM), the refinement framework should take this into account by offering several levels of refinement. The model may be constructed from the description of the behavioral requirement expressed in the architecture models. This model mixes PIM and PSM levels that specifies some functionality satisfying the NFRs.

The PIT takes PIM NF as input and produces PIM NF /PSM NF , stands for those NFRs that concern the architecture.

PSMNF: A Non-Functional Platform Specific Model contains variables and parameters that represent the software structure and dynamics, as well as the platform where the software will be deployed. In a classical MDA approach a platform is represented by a set of subsystems and technologies that provide a coherent set of functionalities through interfaces and clear usage patterns (e.g. J2EE, CORBA, etc.). In a non-functional context a platform must also include the characteristics of the underlying hardware architecture, such as the CPU speed and the failure probability of a hardware connection. The results of the analysis of a PSMNF can be used as a target for comparison to the actual system metrics. This model can then be used to explore the system behavior in the real world (e.g. extremely heavy workloads).

As an example of the approach, consider a performance analysis tool like AnyLogic developed by XJ Technologies. This technology is a leading provider of dynamic simulation tools, technologies and consulting services for business applications using multi-method simulation tool, and allows combining different methods in one model. The object-oriented model design paradigm supported by AnyLogic provides modular and incremental construction of large models. The simulation engine is based on Java technology (platform specific), which makes it possible to use the functionality provided by the Java runtime library in simulation models.

One of the shortcomings of current approaches in this area is the lack of formalisms that provide foundations for automated architecture synthesis. This certainly sounds like an interesting direction to explore. Transformations have the potential for encoding development knowledge, so this may be useful. There is already some work out there that uses transformations for ensuring non-functional properties to explore this literature.

• VI.    Conclusion And Future Work

Non-functional properties of software should be specified early in the development process. In a distributed process of software development, this means that non-functional requirements must be taken into account in the specification, and the developing party of a component needs to deliver the implemented component with the precise description of its nonfunctional properties and a conformance checking that guarantees the satisfying of implemented component requirements. Round-trip mapping between architecture design decision and implementation is also an interesting area of research (to pass from PIM NF to PIM NF /PSM NF ), which aims at keeping architecture and implementation in sync.

The proposed development process brings together two techniques that are used to ensure the quality of model-driven software: Non-functional engineering and software refinement. The novelty of this approach is the integrated refinement view of non-functional properties based on the standard description of MDA. Using sophisticated NFR language descriptions like the RDSEFF formalism of the Palladio Component Model [33] or CQML+, developers can make NF predictions at early stages of the development process, but also checking if the Non-functional requirements are met by the final product or not, need suitable measures.

The future work will focus on using different formal methods like finite automata and the resource demand calculus, which make it possible to prove valid NFP refinement on different levels of abstraction.