Instances and connectors : issues for a second generation process language

This work is supported by UK EPSRC grants GR/L34433 and GR/L32699Over the past decade a variety of process languages have been defined, used and evaluated. It is now possible to consider second generation languages based on this experience. Rather than develop a second generation wish list this position paper explores two issues: instances and connectors. Instances relate to the relationship between a process model as a description and the, possibly multiple, enacting instances which are created from it. Connectors refers to the issue of concurrency control and achieving a higher level of abstraction in how parts of a model interact. We believe that these issues are key to developing systems which can effectively support business processes, and that they have not received sufficient attention within the process modelling community. Through exploring these issues we also illustrate our approach to designing a second generation process language.Postprin

POSD - a notation for presenting complex systems of processes

When trying to understand the behaviour of large systems, such as the business processes of large enterprises, we often adopt diagramming techniques based on derivatives of data flow diagrams. For very complex systems such diagramming techniques suffer from the inability to abstract uniformly from arbitrary subcollections of components. In this paper we present an extension to conventional diagramming techniques which solves this problem. We describe how we have applied this technique to some very complex business systems and illustrate its main points with a simple example. While we have used the notation to present process models we conclude that it is applicable to the description of behaviour in any complex system of processes. Background We are concerned with the nature of change in large and complex computer-based systems. In particular we are concerned with distributed systems, comprising many individually complex, legacy components. Such systems have become the basis of all la..

Embedding requirements within the model driven architecture.

The Model Driven Architecture (MDA) is offered as one way forward in software systems modelling to connect software design with the business domain. The general focus of the MDA is the development of software systems by performing transformations between software design models, and the automatic generation of application code from those models. Software systems are provided by developers, whose experience and models are not always in line with those of other stakeholders, which presents a challenge for the community. From reviewing the available literature, it is found that whilst many models and notations are available, those that are significantly supported by the MDA may not be best for use by non technical stakeholders. In addition, the MDA does not explicitly consider requirements and specification. This research begins by investigating the adequacy of the MDA requirements phase and examining the feasibility of incorporating a requirements definition, specifically focusing upon model transformations. MDA artefacts were found to serve better the software community and requirements were not appropriately integrated within the MDA, with significant extension upstream being required in order to sufficiently accommodate the business user in terms of a requirements definition. Therefore, an extension to the MDA framework is offered that directly addresses Requirements Engineering (RE), including the distinction of analysis from design, highlighting the importance of specification. This extension is suggested to further the utility of the MDA by making it accessible to a wider audience upstream, enabling specification to be a direct output from business user involvement in the requirements phase of the MDA. To demonstrate applicability, this research illustrates the framework extension with the provision of a method and discusses the use of the approach in both academic and commercial settings. The results suggest that such an extension is academically viable in facilitating the move from analysis into the design of software systems, accessible for business use and beneficial in industry by allowing for the involvement of the client in producing models sufficient enough for use in the development of software systems using MDA tools and techniques

Background

POSD- a notation for presenting complex systems of processes When trying to describe the behaviour of large systems, such as the business processes of large enterprises, we often adopt diagramming techniques based on derivatives of data flow diagrams. For very complex systems such diagramming techniques suffer from the inability to abstract uniformly from arbitrary subcollections of components. In this paper we present an extension to conventional diagramming techniques which solves this problem. We describe how we have applied this technique to some very complex business systems and illustrate its main points with a simple example. While we have used the notation to present models of business processes we conclude that it is applicable to the description of behaviour in any complex system of processes