Ella Roubtsova

CSP parallel composition of aspect models

We present an approach to aspect specification based on the Protocol Modelling paradigm, which uses CSP parallel composition as the mechanism for combining partial behaviour specifications. Using the Protocol Modelling approach enables local reasoning about the behaviour of the whole model based on knowledge of behaviour of the composed aspects, and we present the proof of this key property in this paper. We describe how Protocol Modelling allows the definition of aspect join points and weaving relationships at the model level, and how different aspects may use different abstractions over the same domain. We illustrate this using a small case example.

Composition semantics for executable and evolvable behavioral modeling in MDA

The vision of MDA is to decouple the way that application systems are defined from the specification of their deployment platform. Achieving this vision requires that Platform Independent models are rich enough to capture the behavior of the application, and to support reasoning and execution of functional behavior. We focus on state transition modeling as being the best able to support MDA and appraise the two types of state machine (Behavior State Machines and Protocol State Machines) defined in UML. We conclude that, for different reasons, neither has semantics that are well placed to serve as a basis for PIM level behavior modeling. We propose that state transition modeling can be both simplified and strengthened by providing semantics that support process algebraic composition. We claim a number of important advantages for this. Firstly, it provides a common language for defining a range of behavioral abstractions, including software components, behavioral contracts and cross-cutting aspects. Secondly that it better supports analysis of models, by exploiting the formal analysis techniques of process algebra. Thirdly, the semantics enable model execution and testing at the platform independent level across a wider domain than is possible with current UML formalisms.

Protocol Modelling Semantics for Embedded Systems

The properties of a domain oriented modelling approach or language are determined by the dominant semantics of the domain. A significant subclass that needs particular attention, because of its prevalence, is that of deterministic interactive embedded systems. Embedded systems contain both hardware and software components interacting with each other and with the users. The components should be modelled separately, and behaviour should be explicitly defined in order to ensure correct interaction between the components. In this paper we argue that a semantic framework known as protocol modelling provides a good basis for modelling interactive deterministic embedded systems. Firstly, we explain how protocol modelling represents interaction, and how it supports Hoares CSP composition operator, thus allowing components of the solution to be modelled separately. Secondly, we show how protocol modelling can employ different modelling notations, focusing particularly on coloured Petri nets and state charts. Finally, we describe how it guarantees local reasoning about the trace behaviour of a composite based on consideration of the components. We illustrate these explanations using a simple mobile phone case study.

I2SD: reverse engineering Sequence Diagrams Enterprise Java Beans from with interceptors

An Enterprise Java Beans (EJB) interceptor is a software mechanism that provides for introducing behavior implemented as separate code into the execution of a Java application. In this way EJB interceptors provide a clear separation of the core functionality of the bean and other concerns, such as logging or performance analysis. Despite the beauty of the idea behind the interceptors, developing, testing and managing dependencies introduced by the interceptors are considered to be daunting tasks. For example, the developers can specify interceptors at multiple locations and by multiple means. However, different locations and specification means influence the order of the interceptor invocation, which is governed by more than fifteen different intertwined rules according to the EJB standard. To facilitate development of EJB applications we have designed I2SD, Interceptors to Sequence Diagrams, a tool for reverse engineering EJB applications with interceptors to UML sequence diagrams. I2SD provides the developer with a visual feedback and can be used by quality managers to get a broader understanding of the way interceptors are used in their project.

Motivation and Guaranteed Completion in Workflow

This paper presents an approach to designing interactive workflow to achieve guaranteed completion. The approach is based on the idea of modeling motivation, representing how the workflow solicits actions from its environment. The concept of motivation is used to differentiate between actions that are solicited by the workflow and actions that are not solicited, and happen spontaneously. We describe how to analyze progress in workflows that contain both solicited and spontaneous actions and establish guaranteed completion. We describe how to reason about time, and determine the maximum time a workflow requires to reach completion.

Reverse Engineering Sequence Diagrams for Enterprise JavaBeans with Business Method Interceptors

Enterprise JavaBeans (EJB) is a component technology commonly used for enterprise application development. Recent EJB 3.0 specification involves interceptors, a mechanism providing means to dynamically introduce additional behavior into the execution of a bean. As multiple interceptors can be applied to the same bean, and the order of interceptor invocation can be affected by a variety of specification rules, complexity of interceptors invocation can easily become a burden for the developers or maintainers. In order to help the developers we propose an algorithm for reverse engineering UML sequence diagrams from EJB 3.0 programs.

Abstractions, composition and reasoning

We propose that different process algebraic composition techniques, combined with consideration of the restrictions on the ability of different parts of a system to share data and state, can provide a basis for identifying abstractions at the Platform Independent level of modelling. The paper presents our ideas and is aimed to initiate a discussion about the basis for identification of abstractions and the related areas of composition, reasoning and interface specifications, at the platform independent level.

Executable Protocol Models as a Requirements Engineering Tool

Functional prototypes and simulations are a well recognized and valued tool for building a shared understanding of requirements between users and developers. However, the development of such artifacts does not sit well with traditional modeling techniques, which do not lend themselves to direct execution. Consequently building prototypes and simulations becomes a diversion from the mainstream development process, and sometimes even competes with it. We propose that the resolution to this conflict lies in promoting the role of executable behavioral models, so that artifacts supporting behavioral simulation are a by-product of the mainstream modeling process. We discuss why conventional modeling techniques are not suited to this, and we describe an innovative behavioral modeling technique, Protocol Modeling, that is well suited to direct execution. Using Protocol Modeling, a behavioral entity (business object or process) is modeled in terms of its event protocol: the conditions under which it accepts or refuses events. Such models capture the behavioral integrity rules at the level of business events; and can be composed using the semantics of Hoares CSP, allowing concise and incremental representation. Direct execution of the model is achieved using a tool that simulates a normal user interface, so that non-technical stakeholders can review and explore behavior while requirements are being solidified.

MODULAR BEHAVIOUR MODELLING OF SERVICE PROVIDING BUSINESS PROCESSES

We examine possibilities for modularizing the executable models of Service Providing Business Processes in a way that allows reuse of common patterns across different applications. We argue that this requires that we can create independent models for different aspects of the process, and then compose these requirements related partial behavioral models to form a complete solution. We identify two areas of modeling that should be separable from the main, application specific, process model: the underlying subject matter with which the process is concerned, and standard reusable process-level behavior that is common across many processes. Using an example of a Service Providing Business Process concerned with Accreditation of Prior Learning we show that the Protocol Modeling approach has the capability to support modularization of functional and non-functional requirements, when other paradigms cannot completely support it.

Behavior Modeling -- Foundations and Applications: International Workshops, BM-FA 2009-2014, Revised Selected Papers

The paper discusses the key role of abstraction and explicitness in modelling, and argues that abstract, precise, and explicit business domain and process models based on a small system of concepts described in the work of classics of systems thinking, economics, and computing science make possible successful communications between business and IT stakeholders, and thus lead to successful projects. The simple and elegant business models substantially use a system of reusable patterns (relationships), from fundamental (applicable to all models) to business-generic and business-specific. The stable invariants of the business domain are clearly separated from the volatile business processes and especially from the IT-imposed requirements (often restrictions). Modelling practices including the need for human decision often forgotten in modelling, the barriers to adoption of formal modelling, and the overly complex or otherwise inadequate tools used by or imposed on modellers are also described. “One of my major complaints about the computer field is that whereas Newton could say, ‘If I have seen a little farther than others it is because I have stood on the shoulders of giants,’ I am forced to say, ‘Today we stand on each other’s feet.’ Perhaps the central problemwe face in all of computer science is howwe are to get to the situation where we build on top of the work of others rather than redoing so much of it in a trivially different way.” R.W. Hamming, Turing Award Lecture, 1968 When an artefact is to be designed and manufactured, it is necessary to determine what it is, where it is, and what it does. To do that, a specification of semantics, both of the artefact and of the appropriate fragment of the environment, is essential. This specification – at an appropriate abstraction level and from an appropriate viewpoint – should be understandable not only to the designers andmanufacturers of the artefact but also, and more importantly, to its users and to those who will pay for it. This has been a rule in any engineering discipline and should have been a rule in software engineering. More often than not, this did not happen. 1 Abstraction and Reusable Patterns “None of it is new; but sensible old ideas need to be repeated or silly new ones will get all the attention.”