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

More documents

Recommendations

Info

8 Bernhard Thalheim and Klaus-Dieter Schewe A query is an (open) S-formula. Moreover, a view is a query adorned by names (labels) for free variables. Due to our definitions, views are hierarchical too. 2.3 ASM Specification of Database System Behaviour The database system state DBS is structured into four state spaces: (input states I, output states O, DBMS states E, database states DB). The input states I accommodate the database input to the database systems, i.e. queries and data. The output space O allows to model the output data and error messages. The internal state space E of the DBMS represents the DBMS states. The database content of the database system is represented in the database states DB. The four state spaces are typically structured. This structuring is reflected in all four state spaces. For instance, if the database states are structured by a database schema then the input states can be structured accordingly. The main database functions are modelled by modification, retrieval or internal control programs that are run in parallel: Modification programs allow to modify the database state if is enabled: if I(req) ≠ λ ∧ E(modify) = enabled ∧ I(req) ∈ Update then I(req) := λ , O(errMsg) := ..., D := ... , E := ... Retrieval rules allow to retrieve the content of the database: if I(req) ≠ λ ∧ E(retrieve) = enabled ∧ I(req) ∈ Update then I(req) := λ , O(errMsg) := ..., O(answer) := ... DBMS control rules allow to change the database state and the internal state of the database: if E(DBMSstateChange) and E(modify) = disabled then D := ..., E := ... The description can be extended in a similar fashion to sets of inputs instead of a singleton input. The ASM programs are based on ASM rules ModifyInput(request,DBMS state, DB state), ModifyOutput(request,DBMS state, DB state), ModifyDB(request,DBMS state, DB state), ModifyControl(request,DBMS state, DB state), RetrieveOutput(request,DBMS state, DB state), RetrieveDB(request,DBMS state, DB state), RetrieveControl(request,DBMS state, DB state), ControllerDBMS(DBMS state, DB state), and ControllerDB(DBMS state, DB state). These rules run in parallel. They express general DBMS functions for state modification: modify : (req, ,s,d) ↦→ ( ,errMsg,s’,d’) retrieve : (req, ,s,d) ↦→ ( ,answ∪errMsg,s,d) controller : ( , ,s,d) ↦→ ( , ,s’,d’) Modifications may cause deadlock. In order to overcome them the controller enables scheduling, recovery, and optimization. An modification can be imposed completely to the database for support of transaction semantics.
ASM Foundations of Database Management 9 Summarizing we observe that ASM’s can be used for definition of operational semantics of database systems. 2.4 Co-Design of Structuring, Interaction and Behavior Information systems design starts with database structuring and bases functionality on structuring. Typically, it uses various abstraction layers [13]: application domain layer for a rough specification of the application domain and its influence on the information system, requirements acquisition layer for the description of requirements such as main business data and business processes, business user layer or the predesign layer [5, 13] for the specification of business user objects and business workflows, conceptual layer for the conceptual description of structuring and functionality and implementation layer describing the implementation, i.e. code, SQL structures, interfaces and user views. Nowadays application tend to be distributed and components collaborate with each other [10]. Information systems provide services to users depending on their application tasks, portfolio, user stories and context [11, 12]. Therefore, we represent the four dimensions of information systems specification and their layers in Figure 2.4. Application domain layer ❆❆ ❆ Scoping ❆ Requirement ❄ ❆ acquisition ❳ ❳ ❆ layer Variating ❆ ❆ ❳❳ ❳ ❳ Business ❄user ❆ layer Collaboration ❆ Designing ❳ ❳ ❳❳ Interactivity specification ❆ Conceptual ❄ ❳ Structuring ✁ ✁✁✁✁✁✁✁✁✁✁✁✁✁ specification layer Implementing specification ❄ ❳❳❳ ❳ ❳❳❳ Implementation layer Functionality specification Fig. 2. The abstraction layer model for information systems specification The structuring and functionality can be described as an abstract state machine. The stories of users, their profile, context and portfolio can be combined into an ASM-based description of the story space [2]. Interaction description can be based on notions developed in linguistics and in movie business [9]. According to the co-design approach we can distinguish two levels of consideration: Database system development layers: The specification of database systems can be of different granularity and levels of detail. Typical development layers
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 83: 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 ...

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?