BPMN and Beyond Business process modelling notation, workflow ...

More documents

Recommendations

Info

12 Bernhard Thalheim and Klaus-Dieter Schewe Mixed skeleton-driven refinement: Mixed refinement is a combination of refinement techniques. It uses a skeleton of the application or a draft of the architecture. This draft is used for deriving plans for refinement. Each component or module is developed on its own based on top-down or bottomup refinement. These different kinds of refinement styles allow to derive plans for refinement and and primitives for refinement. 3.3 Generic Refinement Steps and Their Correctness An engineering approach is based on a general methodology, operations for specification evolution, and a specification of restrictions to the modelling itself. Each evolution step must either be correct according to some correctness criterion or must lead to obligations that can be used for later correction of the specification. The correctness of a refinement step is defined in terms of two given ASM together with the equivalence relations. Already [8] has observed that refinement steps can be governed by contracts. We may consider a number of governments [1]. We should however take into account the choices for style and perspectives. Refinement pattern Perspectives and styles ✲ ❄ Derivation of generic refinement steps ✛ Development contract ❄ Generic refinement step Consistency conditions ✲ ❄ Derivation of specific refinement steps ✛ DBMS specification assumptions ❄ Refinement step Fig. 3. The derivation of correct refinement steps Given a refinement pattern, perspectives, styles and contract, we may derive generic refinement steps such as data refinement, purely incremental refinement, submachine refinement, and (m,n) refinement. The generic refinement is adapted to the assumptions made for the given application and to consistency conditions. Typical such consistency are binding conditions of rules to state and vocabulary through the scope of rules. The general approach is depicted in Figure 3.
ASM Foundations of Database Management 13 4 Conclusion The ASM approach allows the development of a theory of database system operating. It has the following advantages: – The signature of object-relational databases can be specified based on hierarchical predicate logic. Therefore, the theory of static integrity constraints can be entirely embedded into the theory of sequential abstract-state machines [4]. – The run of a database system is parallel. As an example that is not covered in this paper we elaborated transaction semantics that handles conflicts in concurrency. Parallel runs of transactions must behave in the same manner as a sequential run of the transactions. This concept is entirely covered by partially ordered runs. – Interaction of database systems with user or information systems can be handled by ASM as discussed above. – Database systems are considered on a variety of abstractions layers. Users consider a database system as an input-output engine with a powerful memory. At the conceptual layer, a database system is far more complex. The implementation is even more complex. Therefore, the consideration of database systems semantics requires also a powerful theory of refinement as provided by ASM. Our main aim in this paper is to develop a theory of database systems at the user layer. The other abstraction layers may be seen as refinements of the business user layer. We omitted all examples to the space limitations. The next abstraction level must consider specifical approaches of database engines at the implementation layer. In this case, we need a general notion of database semantics. Database dynamics has not yet been well understood. Transactions may serve as an example. So far we have only used sequential ASM. We might however use power ASM that allow to abstract from intermediate computational steps. Acknowledgement The authors would like to thank Egon Börger and to Andreas Prinz for their helpful comments and discussions. Egon Börger proposed to use power ASM instead of sequential ASM for the treatment of transactions. We than P. Schmidt for proofreading. References 1. A. Bienemann, K.-D. Schewe, and B. Thalheim. Towards a theory of genericity based on government and binding. In Proc. ER’06, LNCS 4215, pages 311–324. Springer, 2006.
Page 1 and 2:
BPMN and Beyond Business process mo
Page 3 and 4:
[Tha00] B. Thalheim. Entity-relatio
Page 5 and 6:
can be defined elementwise, constru
Page 7 and 8:
Our target reader is either knowled
Page 9 and 10:
3 Framework for BPMN Execution Mode
Page 11 and 12:
is usually required to be an atomic
Page 13 and 14:
workflow designer to define in a si
Page 15 and 16:
AndJoinGateTransition(node) = Workf
Page 17 and 18:
that it does not depend only on the
Page 19 and 20:
elow, an instance of WorkflowTransi
Page 21 and 22:
as they arrive” [15, Sect.9.3.3 p
Page 23 and 24:
to whose boundary e is attached and
Page 25 and 26:
if active(targetAct(e)) then Consum
Page 27 and 28:
. . . with the assistance of a soft
Page 29 and 30:
The BPMN standard forsees also that
Page 31 and 32:
ComplMultInstExit has to keep track
Page 33 and 34:
and that “The performers determin
Page 35 and 36:
One project of practical interest w
Page 37 and 38: OrSplitGateTransition(node) = let O
Page 39 and 40: 9.4 Activity Rules TaskTransition(t
Page 41 and 42: AdHocTransition(node) = [if Enabled
Page 43 and 44: ASM Modules Standard module concept
Page 45 and 46: 5. D. Batory and E. Börger. Modula
Page 47 and 48: On defining the behavior of OR-join
Page 49 and 50: Our definition is based upon a fram
Page 51 and 52: We advocate to separate the two dif
Page 53 and 54: In the token based approach to cont
Page 55 and 56: ConsumeAll({(t i , in i )) | 1 ≤
Page 57 and 58: one wants to impose as constraint o
Page 59 and 60: B1 D1 A1 Split 2 O B2 O Join 5 A2 S
Page 61 and 62: Token Sets To speak about the synch
Page 63 and 64: X Test 2 Assemble O Configure Test
Page 65 and 66: 19. J. Mendling, M. Moser, G. Neuma
Page 67 and 68: it is supposed to capture. In Sect.
Page 69 and 70: one may have in = out, so that the
Page 71 and 72: Separation Principle 5. The fifth e
Page 73 and 74: 5.2 Instantiating ComplexGateTransi
Page 75 and 76: the Z notation and offering the pos
Page 77 and 78: ASM Foundations of Database Managem
Page 87: ASM Foundations of Database Managem
Page 91 and 92: Extended Entity-Relationship Model
Page 93 and 94: or cluster type. In this case they
Page 95 and 96: omitted until they have been define
Page 97 and 98: The EER schema can be used to defin
Page 99 and 100: Specialisation and Generalisation B
Page 101: abnormal, infrequent and untypical
show all

BPMN and Beyond Business process modelling notation, workflow ...

Create successful ePaper yourself

Delete template?

Save as template?