Action Relations:Basic Design Concepts for Behaviour Modelling and Refinement

This thesis presents basic design concepts, design methods and a basic design language for distributed system behaviours. This language is based on two basic concepts: the action concept and the causality relation concept. Our methods focus on behaviour refinement, which consists of replacing an abstract behaviour by a more concrete behaviour, such that the concrete behaviour conforms to the abstract behaviour. An important idea underlying this thesis is that an effective design methodology should be based on a properly chosen and precisely defined set of basic design concepts. Properly chosen design concepts represent essential system conceptions (mental images) that are derived from the real world and allow a designer to conceive and structure the essential characteristics of a system. The set of basic design concepts and their combination rules is called a basic design model. We explain how a design methodology supported by design notations and automated tools depends on the basic design model. We introduce and motivate a limited set of basic design concepts that are necessary to design distributed systems. These concepts are structured into two related conceptual domains: the entity domain and the behaviour domain. This thesis focuses on the behaviour domain, which consists of the action concept, the interaction concept and the concept of causality relation. Therefore, we elaborate the action and interaction concepts in more detail and give a formal definition of these concepts. The elaboration of the causality relation concept comprises the main part of this thesis. In order to enable a systematic and modular development of the causality relation concept, we identify the important characteristics of relations between actions and structure these characteristics in an abstraction hierarchy. An action models the essential characteristics of a unit of activity that is performed by a single entity. We consider the following characteristics of an activity as essential: the result that is established by the activity, the moment at which the activity is finished and makes its total result available, and the location at which this result is made available. These characteristics are modelled by means of the information, time and location attributes of an action, respectively. We consider an interaction as a refinement of an action, which models how an activity is performed through the cooperation of multiple entities. A causality relation defines one or more alternative conditions for the occurrence of an action in terms of how this action depends on the occurrences or non-occurrences of other actions. An action occurrence is caused by (or depends on) only one of its alternative conditions, although multiple of these conditions can be satisfied at the same time. We consider the uncertainty or probability that an action occurs when one (or more) of its alternative conditions are satisfied as an important concept in the design of relations between activities. This concept is represented by the probability attribute, which defines, for each alternative 390 Summary condition of an action, the probability that the action occurs when this condition is satisfied. We distinguish three types of probability attributes: (i) the uncertainty attribute supports two uncertainty values: must and may, (ii) the integral probability attribute quantifies these uncertainty values, such that the must value corresponds to probability value 1, and the may value corresponds to a probability value in the range (0..1), and (iii) the stochastic probability attribute uses the time attribute of an action as a stochastic variable, such that a probability distribution function defines for the time period in which the action is allowed to occur, the probability that the action actually occurs. We start with an initial definition of the causality relation concept that supports the design of temporal ordering relations between actions, including the uncertainty attribute. Four elementary causality conditions are defined: the start condition, the enabling condition, the disabling condition and the synchronization condition. These elementary conditions can be composed into more complex causality conditions using the conjunction (and-) and disjunction (or-) operators. The disjunction operator is used to define multiple alternative causality conditions for an action. The uncertainty attribute defines, for each of these alternative conditions, whether the action must or may occur when this condition is satisfied. The initial definition of the causality relation concept is extended with the information, location and time attribute. This extension supports the design of the following type of constraints for each of these attributes: (i) the range of possible values that can be established in an action, (ii) how the value of an action depends on the values established in other actions, and (iii) how the occurrence of an action depends on the values established in other actions. Constraints involving different attribute types are also allowed, e.g., the time and location value established in an action may be referred to as information values by another action. The integral and stochastic probability attribute can be used instead of the uncertainty attribute to quantify the uncertainty of action occurrences. Two interpretations of these probability attributes are distinguished: (i) the simple interpretation defines for each alternative condition of an action the probability that the action occurs when this condition is satisfied, and (ii) the extended interpretation defines for each alternative condition of an action the probability that the occurrence of the action is caused by this condition once this condition enables the action. The extended interpretation allows one to model the probability of individual actions in, e.g., choice, disabling and interleaving relations. In order to define the formal semantics of causality relations, a so called execution model is introduced. In this model, a behaviour is defined by enumerating all possible executions of this behaviour. An execution represents the outcome of a possible run of a system that performs a specified behaviour. This outcome comprises the actions that have occurred, the information, time and location values that have been established in these actions, and how action occurrences are related in the particular execution. An execution also gets one or more probability values, which represent the probability that this execution is the outcome of a system run. In this respect, a behaviour is considered an experiment and an execution is considered a possible outcome of this experiment. The sum of the probability of all possible executions of a behaviour is equal to 1. Based on the basic design language, we present an integrated set of methods to perform behaviour refinement. These methods support two basic types of behaviour refinement: 391 causality refinement, in which causality relations between abstract actions are replaced by causality relations involving their corresponding concrete actions and some inserted actions, and action refinement, in which an abstract action is replaced by an activity involving multiple concrete actions and their causality relations. The methods are based on the assessment of the conformance relation between the abstract behaviour and the concrete behaviour that is obtained from the abstract behaviour by means of causality refinement or action refinement. This assessment involves the determination of the abstraction of the concrete behaviour and the comparison of this abstraction with the original abstract behaviour. Rules to perform the abstraction and comparison operations have been developed. In this thesis we extend the basic design language with the causality-oriented structuring technique defined in [16]. This technique allows one to structure a complex behaviour in terms of simpler sub-behaviours and their relationships. In order to model (infinitely) repetitive behaviours, this technique is extended with the means to (dynamically) create multiple instances of a single sub-behaviour (type) definition, including the means to refer unambiguously to each individual behaviour instance. The ideas presented in this thesis are applied to two case studies. We apply our behaviour refinement method to the design of a system that supports a client-server interaction. At the highest abstraction level we assume that direct interactions between the client application and the server application are possible. At a lower abstraction level we implement these interactions using a federation of remote traders, which communicate via a common communication infrastructure. We also apply our basic design language to the modelling of the behaviour of the OSI Connection-oriented Transport Service. This case study also includes the modelling of timing and probability characteristics imposed by the QoS parameters of the transport service

A model-based approach to service creation

This paper presents a model-based approach to support service creation. In this approach, services are assumed to be created from (available) software components. The creation process may involve multiple design steps in which the requested service is repeatedly decomposed into more detailed functional parts, until these parts can be mapped onto software components. A modelling language is used to express and enable analysis of the resulting designs, in particular the behaviour aspects. Methods are needed to verify the correctness of each design step. A technique called behaviour refinement is introduced to assess the conformance relation between an abstract behaviour and a more concrete (detailed) behaviour. This technique is based on the application of abstraction rules to determine the abstraction of the concrete behaviour such that the obtained abstraction can be compared to the original abstract behaviour. The application of this refinement technique throughout the creation process enforces the correctness of the created servic

Semantic verification of Behavior Conformance

This paper introduces a formal yet practical method to verify whether the behavior design of a distributed application conforms to the behavior design of the enterprise in which the application is embedded. The method allows both enterprise architects and application architects to talk about designs in their own terms, and introduces a common set of terms as the linking pin between enterprise and application designs. The formal semantics of these common terms allows us to verify the conformance between an enterprise and its applications formally and automatically

An Engineering Approach towards Action Refinement

In the abstract modelling of distributed systems we may need methods to replace abstract behaviours by more concrete behaviours which are closer to implementation mechanisms. Furthermore, we may want these methods to preserve the correctness of such a replacement. This paper introduces an approach towards action refinement in which an abstract action is replaced by a concrete activity. This approach is based on a careful consideration of the `action' and `causality relation' architectural concepts, which enable an abstract action to be replaced by many alternative concrete activities in a general way. This approach is based on the application of abstraction rules to determine whether a concrete activity conforms to an abstract action, considering the context in which the concrete activity and the abstract action are embedde

On interoperability and conformance assessment in service composition

The process of composing a service from other services typically involves multiple models. These models may represent the service from distinct perspectives, e.g., to model the different roles of systems involved in the service, and at distinct abstraction levels, e.g., to model the service’s capability, interface or the orchestration that implements the service. The consistency among these models needs to be maintained in order to guarantee the correctness of the composition process. Two types of consistency relations are distinguished: interoperability, which concerns the ability of different roles to interoperate, and conformance, which concerns the correct implementation of an abstract model by a more concrete model. This paper discusses the need for and use of techniques to assess interoperability and conformance in a service composition process. The paper shows how these consistency relations can be described and analysed using concepts from the COSMO framework. Examples are presented to illustrate how interoperability and conformance can be assessed

An approach to relate business and application services using ISDL

This paper presents a service-oriented design approach that allows one to relate services modelled at different levels of granularity during a design process, such as business and application services. To relate these service models we claim that a 'concept gap' and an 'abstraction gap' need to be bridged. The concept gap represents the difference between the conceptual models used to construct service models by different stakeholders involved in the design process. The abstraction gap represents the difference in abstraction level at which service models are defined. Two techniques are presented that bridge these gaps. Both techniques are based on the Interaction System Design Language (ISDL). The paper illustrates the use of both techniques through an example

An Approach to Relate Viewpoints and Modeling Languages

The architectural design of distributed enterprise applications from the viewpoints of different stakeholders has been proposed for some time, for example, as part of RM-ODP and IEEE 1471, and seems now-a-days to gain acceptance in practice. However, much work remains to be done on the relationships between different viewpoints. Failing to relate viewpoints may lead to a collection of viewpoint models that is inconsistent, and may therefore lead to an incorrect implementation. This paper defines an approach that helps designers to relate different viewpoints to each other. Thereby, it helps to enforce the consistency of the overall design. The results of this paper are expected to be particularly interesting for Model Driven Architecture (MDA) projects, since the proposed models can be used for the explicit definition of the models and relationships between models in an MDA trajectory

Refinement of SDBC Business Process Models Using ISDL

Aiming at aligning business process modeling and software specification, the SDBC approach considers a multi-viewpoint modeling where static, dynamic, and data business process aspect models have to be mapped adequately to corresponding static, dynamic, and data software specification aspect models. Next to that, the approach considers also a business process modeling viewpoint which concerns real-life communication and coordination issues, such as meanings, intentions, negotiations, commitments, and obligations. Hence, in order to adequately align communication and dynamic aspect models, SDBC should use at least two modeling techniques. However, the transformation between two techniques unnecessarily complicates the modeling process. Next to that, different techniques use different modeling formalisms whose reflection sometimes causes limitations. For this reason, we explore in the current paper the value which the (modeling) language ISDL could bring to SDBC in the alignment of communication and behavioral (dynamic) business process aspect models; ISDL can usefully refine dynamic process models. Thus, it is feasible to expect that ISDL can complement the SDBC approach, allowing refinement of dynamic business process aspect models, by adding communication and coordination actions. Furthermore, SDBC could benefit from ISDL-related methods assessing whether a realized refinement conforms to the original process model. Our studies in the paper are supported by an illustrative example

A Combined Component-Based Approach for the Design of Distributed Software Systems

Component-based software development enables the construction of software artefacts by assembling binary units of production, distribution and deployment, the so-called components. Several approaches to component-based development have been proposed recently. Most of these approaches are based on the Unified Modeling Language (UML). UML has been increasingly used in component-based development, despite some shortcomings of this language. This paper presents a methodology for the design of component-based applications that combines a model-based approach with a UML-based approach. This combined approach tackles some of the limitations of UML, allowing a better control of the design proces

On Engineering Support for Business Process Modelling and Redesign

Currently, there is an enormous (research) interest in business process redesign (BPR). Several management-oriented approaches have been proposed showing how to make BPR work. However, detailed descriptions of empirical experience are few. Consistent engineering methodologies to aid and guide a BPR-practitioner are currently emerging. Often, these methodologies are claimed to be developed for business process modelling, but stem directly from information system design cultures. We consider an engineering methodology for BPR to consist of modelling concepts, their representation, computerized tools and methods, and pragmatic skills and guidelines for off-line modelling, communicating, analyzing, (re)designing\ud business processes. The modelling concepts form the architectural basis of such an engineering methodology. Therefore, the choice, understanding and precise definition of these concepts determine the productivity and effectiveness of modelling tasks within a BPR project. The\ud current paper contributes to engineering support for BPR. We work out general issues that play a role in the development of engineering support for BPR. Furthermore, we introduce an architectural framework for business process modelling and redesign. This framework consists of a coherent set of modelling concepts and techniques on how to use them. The framework enables the modelling of both the structural and dynamic characteristics of business processes. We illustrate its applicability by modelling a case from service industry. Moreover, the architectural framework supports abstraction and refinement techniques. The use of these techniques for a BPR trajectory are discussed