Ebx ML Collaboration Modeling Met A Model

Draft Version 0.
1
DO NOT DISTRIBUTE
1
2
3
4
5
6
Collaboration Modeling Metamodel

& UML Profile
Draft Version 0.1
7Contents
8Document Revision History........................................................i
9Executive Summary.................................................................iii
10Preface....................................................................................v
111. Introduction........................................................................1
122. The Business Operations Map Metamodel..............................3
13
2.1 Model Abstract Syntax....................................................................3
14
2.1.1 Stereotypes and Tagged Values..............................................3
15
2.1.2 Well-formedness Rules...........................................................5
16
2.2 Model Semantics.............................................................................6
17
2.3 Model Management Abstract Syntax..............................................6
18
19
2.3.2 Well-formedness Rules...........................................................7
20
2.4 Model Management Semantics.......................................................8
213. The Business Requirements View Metamodel........................9

22
3.1 Model Abstract Syntax....................................................................9
23
24
3.1.2 Well-formedness Rules.........................................................17
25
3.2 Model Semantics...........................................................................18
26
3.3 Model Management Abstract Syntax............................................19
27
3.3.1 Stereotypes and Tagged Values............................................19
28
29
3.4 Model Management Semantics.....................................................20
4
304. The Business Operational View Metamodel..........................22
31
4.1 Model Abstract Syntax..................................................................22
32
33
34
4.2 Model Semantics...........................................................................32
35
4.2.1 Business Activities................................................................33
36
4.2.2 Requesting Business Activity................................................41
37
4.2.3 Object Flow...........................................................................41
38
4.2.4 Business Collaboration Protocol............................................41
39
4.2.5 BOV-to-BRV Mapping............................................................41
40
4.3 Model Management Abstract Syntax............................................42
41
42
43
4.4 Model Management Semantics.....................................................43
445. The Functional Service View Metamodel..............................45

45
5.1 Model Abstract Syntax..................................................................45
46
47
48
5.2 Model Semantics...........................................................................53
49
5.2.1 Agent 54
50
5.2.2 BusinessService....................................................................54
51
5.2.3 ServiceTransaction................................................................55
52
5.2.4 NetworkComponent..............................................................55
53
5.2.5 BusinessMessage..................................................................55
54
5.2.6 MessageEnvelope.................................................................55
55
5.2.7 BusinessActionMessage........................................................55
56
5.2.8 BusinessSignalMessage........................................................55
6
57
5.2.9 RequestingServiceTransaction..............................................55
58
5.2.10
RespondingServiceTransaction..................................56
59
5.2.11
Service Collaboration.................................................56
60
5.2.12
BusinessActionMessage.............................................57
61
5.2.13
ElementId..................................................................57
62
5.2.14
InformationEntity.......................................................57
63
5.2.15
MessageEnvelope......................................................57
64
5.2.16
BusinessActionMessage.............................................58
65
5.2.17
BusinessSignalMessage.............................................58
66
5.2.18
UnstructuredMessage................................................58
67
5.2.19
StructuredMessage....................................................58
68
5.3 Model Management Abstract Syntax & Semantics......................58
696. Model Notation..................................................................61

70
6.1 Stereotype Notation......................................................................61
71
6.2 Model Diagrams............................................................................61
72
6.2.1 Business Operations Map Diagrams.....................................61
73
6.2.2 Business Requirements View Diagrams................................63
74
6.2.3 Business Operational View Diagrams...................................64
75
6.2.4 Functional Service View Diagrams........................................66
76
77
6.2.5 Implementation Framework View DiagramsError! Bookmark

not defined.
787. Bibliography......................................................................70
79Figures
80Figure 1.
BOM Abstract Syntax.....................................................................3
81Figure 2.
BOM Illustration.............................................................................6
82Figure 3.
BOM Model Management Abstract Syntax.....................................7
8
83Figure 4.
BOM Model Management Illustration.............................................8
84Figure 5.
BRV Abstract Syntax......................................................................9
85Figure 6.
BRV Illustration............................................................................18
86Figure 7.
BRV Model Management Abstract Syntax....................................20
87Figure 8.
BRV Model Management Illustration............................................21
88Figure 9.
BOV Abstract Syntax....................................................................23
89Figure 10. BOV Illustration............................................................................33

90Figure 11. Requesting Business Activity States............................................36
91Figure 12. Responding Business Activity States...........................................37
92Figure 13. BOV-to-BRV Syntax Map...............................................................42
93Figure 14. BOV Model Management Abstract Syntax...................................43
94Figure 15. BOV Model Management Illustration............................................44
95Figure 16. FSV Abstract Syntax.....................................................................46
96Figure 17. Example Process Area Diagram...................................................62
97Figure 18. Example Business Process Activity Diagram................................62
98Figure 19. Example Business Use Case Diagram..........................................63
99Figure 20. Example Business Collaboration Diagram...................................64
100Figure 21. Example Commercial Transaction Diagram.................................65
101Figure 22. Example Business collaboration protocol Diagram......................66
102
103Document Revision History

104
0.1
105
10
8/11/2000
First draft translation of BCF 2.0 version 2.0
106Executive Summary
107Business partners must collaborate if they are to remain competitive. A high level of
108collaboration is possible when business partners link their businesses processes through an
109interface of network computer e-business services that enforce commercial trading agreements
110modeled as collaborative exchanges of business information, in agreed sequences and within
111agreed timeframes. A commercial trading agreement is modeled as a business process model
112expressed with the Unified Modeling Language (UML) and the Object Constraint Language
113(OCL). The UML is a language expressive enough to specify the structure and behavior of
114objects that interact in any conceptual domain of discourse. A process model, however, is a
115specification of the structure and behavior of objects interacting at business partner interfaces, a
116specialized domain of discourse. This document describes an extension to UML to include
117business process domain specific syntax and semantics. This extension is termed the e118Business Process Metamodel. The metamodel is organized into the following views so that
119each process model can be viewed from a number of perspectives.
120
121
The Business Operations Map (BOM) metamodel the partitioning of business

processes into business areas and business categories.
122
123
The Business Requirements View (BRV) metamodel the view of a business

process model that captures the requirements of a business collaboration protocol.
124
125
126
The Business Operational View (BOV) metamodel - the view of a business process
model that specifies the contract formation process for various types of commercial
contracts.
127
128
129
The Functional Service View (FSV) metamodel - the view of a business process
model that specifies the electronic formation of commercial contracts using an electronic
medium.
130These perspectives support an incremental model construction methodology and provide levels
131of specification granularity that are suitable for communicating the model to business
132practitioners, business application integrators and network application solution providers.
11
12
133History
134This document represents the concerted effort by the ebXML Business Process team to ensure
135that the best of practice in system and process specification. The work stems from an effort
136initiated in April 2000 where several representatives of industry leaders met in Seattle,
137Washington. During this meeting 8 to 10 methodologies where analyzed, and audited against
138each other. The modeling elements of each methodology were identifies, classified and
139organized into a metamodel which represented the nominal modeling elements required to
140specify an electronic commerce process and commercial collaboration. After several months of
141intense evaluation and analysis, it was determined that to construct a full metamodel and
142methodology the work would require more than one to two years to complete the work. Since
143the Business Collaboration Framework delevoped by Edifecs Commerce, Inc represented a
144complete unit of work and was in use by the RosettaNet Consortium, ebXML would use the BCF
145contributed by Edifecs as the base and framework for the ebXML methodology, integrate the
146work that had been accomplish to date and produce a specification in a matter of weeks in lieu
147of years. We owe a debt of gratitude to all those who have participated in this work and to
148Edifecs Commerce for their contribution to this effort.
149
150
151
13
iv
152Preface
153Business process models specify interoperable business processes that allow business
154partners to collaboration. These models are specified using the Unified Modeling Language
155(UML) and the Object Constraint Language (OCL). This document describes the UML
156metamodel extension for specifying business process models.
157There are a number of reasons to use the UML and the OCL to specify these models.
158
159
The UML provides a visual language that eases the construction and interpretation of ebusiness collaboration models.
160
161
The UML provides an extension mechanism so that domain specific, object-oriented

metamodels can be easily defined.
162
163
The OCL is a programming language independent method for expressing integrity and
well-formedness constraints in metamodels and models.
164
165
The UML can be persisted using XMI an XML application. Models are easy to share
and translate using tools that provide XMI support.
166Purpose of the Document

167The purpose of this document is to define a business process metamodel. The metamodel is
168used to enforce the syntax and semantics of business process models so that tools can be built
169to construct, and applications can be built to execute, compliant models.
170Intended Audience
171The UML is a rich modeling language that is expressive enough to construct object models for
172many purposes, from many viewpoints and within many contexts. UML modelers who need to
173specifically construct business process models must use this document to check the integrity
174and compliance of their models. If an automated integrity and compliance checker assists these
175modelers then that program must check these models against the metamodel specified in this
176document.
177Prerequisites
178It is assumed that the audience will be familiar with or have knowledge of the following
179technologies and techniques:
180
Business process modeling techniques and principles
181
182
The UML syntax and semantics, the UML metamodel and the UML extension
mechanism
183
The OCL syntax and semantics
184Scope of the Document

185This document specifies a metamodel for constructing business process models.
14
15
186Style Conventions
187This document uses typographical and language conventions to convey specific meanings.
188Typographical Conventions
189The use of a bold/italic font indicates a UML or business process metamodel entity name.
190Language Conventions
191This specification adopts the conventions expressed in the IETFs1 RFC 2119 Key Words for
192Use in RFCs to Indicate Requirement Levels. The key words MUST, MUST NOT,
193REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED,
194MAY, and OPTIONAL in this document are to be interpreted as described in RFC 2119.
195Acknowledgements
196ISO: The following terms are borrowed from the ISO Standard specification for Open-EDI.
197
Business Operational View (BOV)
198
Functional Service View (FSV)
199Telecommunications Management Forum (TMF): The following terms are derived from the
200TMF documents.
201
202
203
Business Operations Map (BOM). This is a generalization of the Telecom Operations

Map (TOM) defined by the TMF. A BOM is a super-category of an industry specific
business operations map such as the TOM.
204
205
The Fabricate, Assurance and Billing (FAB) business areas used to create the top-level
nodes for services industries.
206Supply Chain Council. The following terms are taken from the Supply Chain Council
207documents.
208
209
210
Business Operations Map (BOM). This is a generalization of the Supply Chain

Operations Reference (SCOR) model defined by the Supply Chain Council. A BOM is a
super-category of a domain specific business operations map such as SCOR.
211
212
The Plan, Source, Make, Deliver business areas are used to create top-level nodes for
Discrete or Continuous Goods Supply Chains.
213Edifecs Commerce: Edifecs is administering the creation of the Business Collaboration

214Framework (BCF) documents. The BCF is a collection of documents that prescribe the policy,
215architecture and specifications for executing business processes in electronic commerce, the
216Internet for e-business.
217
218
161 http://www.ietf.org
17
vi
18
219
1.
Introduction
220Business partners collaborate by linking their planning and execution business

221processes. This allows each partner to derive business efficiencies and to react quicker
222to customer demand. Business execution processes span the end-to-end flow of
223products and information from consumer demand through product sourcing and back to
224final product consumption. In discrete or continuous goods industries, collaboration is a
225series of source, make and deliver business processes2 executed by each business
226partner in the collaboration. Service industries collaborate in a series of fulfill, assure and
227bill business processes3 executed by each business partner in the collaboration.
228Business partners implement business process links through an interface of network
229computer e-business services that enforce commercial trading agreements modeled as
230collaborative exchanges of business information, in agreed sequences and within
231agreed timeframes. A commercial trading agreement is modeled either as a Commercial
232Transaction (CT) or a Business Collaboration Protocol (BCP). A CT is a
233request/response exchange of business information between the initiator of the
234transaction and the responder to the transaction request. A BCP is a choreograph of
235CTs where either party to a trading agreement can initiate and respond to commercial
236transactions until the terms of their agreement are met. For example, creating a
237purchase order can be a CT where all the terms of an offer are accepted in a response
238or it can be a BCP where the terms of an offer are accepted piecemeal in multiple
239responses.
240Business processes are partitioned, arranged and interrelated using a Business
241Operations Map (BOM) to promote human understanding and to facilitate specific
242business model configurations (e.g. build-to-order and build-to-stock). The map and
243associated process models can be incrementally constructed using the TMWG modeling
244methodology.
245Process models are expressed using the Unified Modeling Language (UML) and the
246Object Constraint Language (OCL) both of which are standards maintained by the
247Object Management Group4 (OMG). The UML is a language expressive enough to
248specify the structure and behavior of objects that interact in any conceptual domain of
249discourse. A process model, however, is a specification of the structure and behavior of
250objects interacting business partner interfaces, a specialized domain of discourse. The
251UML metamodel (the model that defines the UML modeling language) is extended to
252include domain specific syntax and semantics using extension mechanisms know as
253stereotyping. A business process metamodel is thus defined as an extension of the UML
254metamodel by extending the UML stereotype syntax and semantics with the syntax and
255semantics of the business process domain. Process models are then constructed using
256the syntax of the metamodel. Tools and applications that support the syntax and
257semantics of the business process metamodel will be able to support the construction
258and execution of business processes that execute on the ebXML compliant transports.
259This document is a precise definition of the UML metamodel extension that facilitates the
260expression of a business processes as an object-oriented model. This extended
261metamodel is termed the e-Business Process Metamodel. The metamodel is organized
192 Taken from the Supply Chain Operations Reference (SCOR) model found at
20http://www.supply-chain.org.
213 Taken from the Telecom Operations Map (TOM) found at http://www.tmforum.org.
224 http://www.omg.org
23
24
262into the following views so that each process model can be viewed from a number of
263perspectives.
264
265
The Business Operations Map (BOM) metamodel the partitioning of

business processes into business areas and business categories.
266
267
268
The Business Requirements View (BRV) metamodel the view of a business

process model that captures the Use Case scenarios, inputs, outputs, constraints
and system boundaries for commercial transactions and their interrelationships.
269
270
271
The Business Operational View (BOV) metamodel - the view of a business

process model that captures the semantics of business information entities and
their flow of exchange between roles as they perform business activities.
272
273
274
275
The Functional Service View (FSV) metamodel - the view of a business

process model that specifies the network component services and agents and
their message (data) exchange as interactions necessary to execute and validate
a business process.
276
277These perspectives support an incremental model construction methodology and
278provide levels of specification granularity that are suitable for communicating the model
279to business practitioners, business application integrators and network application
280solution providers.
281The BRV, BOV and FSV of a process model are network communications protocol
282neutral.
283
284.
285
286
25
26
287
2.
The Business Operations Map Metamodel
288The Business Operations Map (BOM) of a business process model specifies the Use
289Case scenarios, input and output triggers, constraints and system boundaries for
290business areas, business processes, business collaboration protocols, commercial
291transactions and their interrelationships. Business process are partitioned, arranged and
292interrelated using a BOM to promote human understanding and to facilitate specific
293business model configurations (e.g. build-to-order and build-to-stock).
294This section specifies the abstract syntax and semantics of a BOM model and model
295management packages. The abstract syntax of models is defined using stereotypes and
296tagged values. The semantics of models are specified using the truth semantics of well
297formed-formula expressed with OCL expressions and with natural language.
298
2.1
Model Abstract Syntax

2.1.1Stereotypes and Tagged Values
299
300
301
302
303
Figure 1 specifies the modeling elements, and their interrelationships, that

are used to express the structure and behavior of objects in a BOM
model. Each element and interrelationship permitted in a BOM is defined
in the metamodel specified in this section of the document.
27
28
Business Operations Map Metamodel
<<stereotype>>
Busi nessProcess
baseElement = UseCase
preconditions : String
beginsWhen : Stri ng
definition : String
endsWhen : String
exceptions : Stri ng
postcondi tions : String
traceability : String
<<stereotype>>
T ransition
baseElement = Relationship
triggerEvent : String
transitionConditions : String
concurrentT ransition : String
1
<<stereotype>>
Busi nessTask
1
<<stereotype>>
Busi nessProcessActivityModel
baseElement = Acti onState

ti meToPerform : T imeExpression
+col laboratesWi th
1
baseElement = Acti vityGraph
304
305
307
308
Figure 1. BOM Abstract Syntax
BusinessProcess5
309
310
311
312
A business process is a Use Case that is used to gather

requirements about business processes. Inputs to the business
process must be specified in the preconditions and outputs from
the business process must be specified in the post-conditions.
313
Tagged Values:
314
315
preconditions. Preconditions are constraints that must be

satisfied starting the Use Case.
316
317
beginsWhen.
Describe the initial event from the actor that

starts a Use Case.
318
319
320
definition.
A set of simple sentences that state the actions

performed as part of the Use Case. Include
references to Use Cases at extension points.
321
322
endsWhen.
Describe the condition or event that causes

normal completion of the Use Case.
295 Use cases should consider the inclusion of measure, metric and meter parameters for a
30business process. Measures are quantifiable properties; a metric an expression of some
31performance calculation and a meter is a comparison of the metric to a benchmark.
32
33
323
324
325
exceptions.
326
327
postconditions. Post-conditions are constraints that must be

satisfied ending the Use Case.
328
329
330
traceability.
331
332
333
334
335
List all exception conditions that will cause the

Use Case to terminate before its normal
completion.
An explicit list of requirements, identified by

category, that are either partially or completely
satisfied by this used case.
BusinessProcessActivityModel
A business process activity model specifies the behavioral aspects
of a business process. The model specifies a flow of control
between tasks.
BusinessInterfaceTask
336
337
338
339
A business interface task is a task that is performed by one

business partner in collaboration with another business partner
performing another business interface task. A business process is
decomposed into business tasks and business interface tasks.
340
Tagged Values:
timeToPerform. A task is work that is performed with respect to
time. There may be a specific time within which
the task must be performed.
341
342
343
344
Associations:
collaboratesWith. A business interface task is performed in
collaboration with another business interface
task. For examples, a create purchase order
task is performed in collaboration with a create
sales order task.
345
346
347
348
349
350
Transition
351
352
353
354
355
356
357
A transition is a directed relationship between a client (source) use

case and a supplier (target) use case. This relationship specifies a
process transition to a target business process use case triggered
by the completion of a source business process (a state in which
all the post-conditions of the use case are satisfied) or triggered
by a activity state transition within the client (source) use case.
The transition occurs only when transition conditions are satisfied.
358
Tagged Values:
359
360
361
362
triggerEvent.
363
364
transitionConditions. TransitionConditions are constraints that

must be true in order for the transition to the
34
The activity state transition within the client

(source) use case definition activity graph that
triggers the transition to the supplier (target) use
case.
35
supplier (target) use case to occur. These
conditions must be testable values on the
business data entities visible to the client
(source) use case and its definition activity
graph.
365
366
367
368
369
concurrentTransition. A flag indicating that the transition occurs

on an internal activity transition within the client
(source) activity graph. Both the client (source)
and supplier (target) will continue concurrently.
370
371
372
373
Associations:
374
375
376
377
SourceUseCase A transition describes the trigger event and

conditions occurring in the client (source) use
case.
378
379
380
TargetUseCase The supplier (target) use case is executed when

the trigger event and transition conditions occur
within the client (source) use case.
2.1.2Well-formedness Rules
381
382
The following well-formedness rules apply to the BOM metamodel.
383
384
[1] The collaboratesWith association must be navigable from the client

use case to the supplier use case only.
385
386
[2] Business process activity models must have one initial state and at
least one end state.
387
2.2
Model Semantics
388
The semantics of each element of the BOM metamodel is defined in this section.
389
Figure 2 illustrates the interrelationships between the BOM modeling elements.
1 +source
0..*
1 +target
0..*
BusinessProcess
Transition
1
BusinessProcessActiv ity Model
390
391
392
393
394
395
396
36
BusinessInterf aceTask
1..*
Figure 2. BOM Illustration

A business process is a sequence of business tasks performed by one business
partner alone, and business interface tasks performed two or more business
partners. A business process activity model should only contain activity states
that are either Business Interface Task specifications or that are interpreted as
business tasks.
37
397
398
399
Each task can be further decomposed into activities. Business process can be
decomposed into sub-processes using the includeassociation stereotype
defined in the UML.
400
401
402
403
A transition relationship specifies a change in state of a business process that is

triggered by the completion of some part of the business process. A transition
relates a source business process and a target business process. The direction
of the transition is from the source to the target.
404
405
406
407
408
409
410
411
412
413
2.3
Model Management Abstract Syntax
The BOM model management organizes business process Use Cases and
business process activity models into a framework of business areas and
process areas. These modeling elements are organized as logical, business area
and sub-process categories arranged in a framework for understanding their
interrelationships. The framework is termed a Business Operations Map (BOM).

Figure 3 shows the metamodel for managing the BOM model. The
modeling elements used to manage and organize these three
specifications are defined in this section.
<<stereotype>>
BusinessOperat ionsMap
baseElement = Model
industry Segment : String
<<stereotype>>
Busi nessCategory
baseElement = Package
category Schem a : String
category : String
BusinessArea
ProcessArea
414
415
Figure 3. BOM Model Management Abstract Syntax
416
417
The following stereotypes and tagged values are contained in the BOM
management metamodel.
418
BusinessOperationsMap
419
420
421
422
423
424
38
A Business Operations Map is a framework for understanding

business area sub-process interrelationships. This framework is
termed a Business Operations Map (BOM).
BusinessArea
A business area is a category of decomposable business process
areas. A business area collates business processes areas.
39
425
BusinessCategory
426
427
A business category is an abstraction category for reusing tagvalues. A business category collates sub-categories.
428
Tagged Values:
429
430
categorySchema. The name of the categorization schema used

to reference Use Cases.
431
432
433
category.
434
The category identifier used to reference a

business area or business process set of Use
Cases.
ProcessArea
435
436
437
A process area is a category of business processes and

commercial transactions. A process area collates business
processes and commercial transactions.
438
439
440
The following well-formedness rules apply to the business operational

map metamodel package.
441
[1] A BOM must contain at least one Business Area.
442
[2] A Business Area must contain at least one Process Area.
443
[3] A Process Area must contain at least one Business Process.
444
2.4
Model Management Semantics
445
446
The semantics of each element of the BOM model management metamodel is

defined in this section.
447
448
Figure 4 illustrates the interrelationships between the BOM model management

elements.
Business Operations Map Model Management Semantics

0..n
Busi nessOperationsMap
Busi nessProcess
1..n
1..n
Busi nessArea
1..n
ProcessArea
449
450
40
Figure 4. BOM Model Management Illustration
41
451
452
453
454
455
456
457
A business operations map comprises business areas. The Supply Chain

Council6 defines plan, source, make and deliver business areas in their Supply
Chain Operations Reference (SCOR) model. The model describes business
processes in the Discrete and Continuous Goods Supply Chain. The
Telecommunications Management Forum7 defines fulfill, assure and bill business
areas in their Telecom Operations Map (TOM). The map describes business
processes in the Services industry.
458
459
460
461
Business areas comprise process areas. A process area is a sequence of

business processes that implements a particular business model. Business areas
such as Deliver stocked product and Deliver make-to-order products are two
different business models that use many of the same business processes.
426 http://www.supply-chain.org.
437 http://www.tmforum.org.
44
45
462
3.
The Business Requirements View Metamodel
463The Business Requirements View (BRV) of a process model specifies the Use Case
464scenarios, input and output triggers, constraints and system boundaries for Commercial
465Transactions (CTs), Business Collaboration Protocols (BCPs) and their
466interrelationships.
467This section specifies the abstract syntax and semantics of the BRV of a CT and BCP
468model and model management packages. The abstract syntax of models is specified
469using stereotypes and tagged values. The semantics of models are specified using the
470truth semantics of wellformed-formula expressed with OCL expressions and with
471natural language.
472
473
474
475
476
477
478
3.1

Figure 5 specifies the modeling elements and their interrelationships that

are used to express the structure and behavior of objects in the BRV of a
CT and BCP model. Each element and interrelationship permitted in a
BRV is defined in the metamodel specified in this section of the
document.
Business Requirements View Metamodel
<<stereotype>>
PartnerType
<<stereotype>>
BusinessCollaborationUseCase
baseElement = Class
baseElement = UseCase
beginsWhen : String
definition : String
endsWhen : String
exceptions : String
postconditions : String
traceabi lity : Stri ng
recordMetrics : Bool ean
<<stereotype>>
Busi nessCollaboration
baseElement = Coll aboration
beginsWhen : String
definition : String
endsWhen : String
exceptions : String
postconditions : String
1
+collaboration
+base
+realization
0..n
<<stereotype>>
Realize
baseElement = Relationship
0..n
CommercialTransactionUseCase
requestingBusinessFuncti on : String
respondingBusinessFunction : String
479
480
46
Figure 5. BRV Abstract Syntax
10
47
481
482
483
484
BusinessCollaborationProtocolUseCas
A business collaboration protocol Use Case is used to gather
requirements for e-business collaboration protocol specifications.
BusinessCollaboration
485
486
487
488
489
A business collaboration model specifies the input and output

relationships between business collaboration Use Cases and
Agents. Agents provide input triggers to Use Cases and business
collaboration Use Cases can provide input triggers and output
triggers to and from other business collaboration Use Cases.
490
491
492
493
494
A business collaboration model captures business information

constraints imposed by a specific partner type collaboration. For
example, sending a business document to a US Government
agency requires a Standard Industry Classification (SIC) code to
be included with the business information.
495
Tagged Values:
496
497
preconditions. Conditions that must be true before starting the

Use Case.
498
499
beginsWhen.

starts a Use Case.
500
501
502
definition.

503
504
endsWhen.

505
506
507
exceptions.

completion.
508
509
postconditions. Conditions that must be true before ending the

Use Case.
510
511
512
513
514
A business collaboration use case is an abstraction for a business

collaboration protocol Use Case and a commercial transaction
Use Case. The abstraction permits the reuse of the business
collaboration realization relationship.
515
516
517
518
519
520
521
522
A completed use case assumes that some one thing of

measurable value be created either as a service performed of a
product created. Four appropriate classes of measure that can be
applied to use case performance: quantity measure, quality
measure, time of performance measure and resource usage or
consumption measure. Each use case should have an identified
set of appropriate measures. As a minimum, at least one quantity
measure should be employed.
48
11
49
523
Tagged Values:
524
525
preconditions. Conditions that must be true before starting the

Use Case.
526
527
beginsWhen.

starts a Use Case.
528
529
530
definition.

531
532
endsWhen.

533
534
535
exceptions.

completion.
536
537
postconditions. Conditions that must be true before ending the

Use Case.
538
539
540
traceability.
An explicit list of requirements, identified by

category, that are either partially or completely
satisfied by this used case.
541
542
Associations:
realization.
543
544
A business collaboration is a realization of a

business collaboration use case.
545
546
547
548
A commercial transaction Use Case is used to gather

requirements for commercial transaction specifications.
549
Tagged Values:
550
551
552
553
requestingBusinessFunction.
The business function that is
implemented by the requesting business partner
who is performing a role with respect to the use
case e.g. Procurement.
554
555
556
557
respondingBusinessFunction. The business function that is

implemented by the responding business
partner who is performing a role with respect to
the use case e.g. Fulfillment.
558
Realize
559
560
A relationship between a business collaboration Use Case and the

realization of a Use Case.
561
Associations:
562
563
50
base.
The base Use Case for the collaboration in the

realization relationship.
12
51
collaboration.
564
565
566
567
568
569
The collaboration realization for the base Use

Case.
PartnerType
A partner type is an actor in a business collaboration Use Case.
Partner types are Manufacturer, Distributor, Retailer, End User,
Carrier and Financier8.
570
528 This list of partner types should not be considered complete. However it appears to
53sufficient for Supply Chain Industries. There needs to be some effort into service oriented
54industries. i.e. - Telecom
55
13
56
Economic Modeling Elements
<<stereotype>>
BusinessEntity
baseElement = Class
<<stereotype>>
Economic Resource
Definition
baseElement = Class
classifies
<<stereotype>>
Economic Resource
baseElement = Class
measurement
location
<<stereotype>>
Agreement
baseElement = Class
AgreementType : String
classifies
<<stereotype>>
Business Event
baseElement = Class
<<stereotype>>
Economic Event
baseElement = Class
measurement
<<stereotype>>
Economic Contract
baseElement = Class
initiateCondition : String
terminationCondition : String
<<stereotype>>
Commitment
baseElement = Class
measure : String
due : Date
<<stereotype>>
Dual ity
baseElement = relationship
<<stereotype>>
Reproci ty
<>> baseElement = relationship
571
572
57
Figure 6. Economic Elements Abstract Syntax
14
58
573
574
575
BusinessEntity
Business Entity is an abstraction for any artifact that is important
in the execution of a business collaboration.
576
577
578
Agreement
579
580
581
582
583
An agreement is an arrangement between two partner types that

specifies in advance the conditions under which they will trade
(terms of shipment, terms of payment, collaboration protocols,
etc.) An agreement does not imply specific economic
commitments.
584
Tagged Values:
585
586
587
588
589
590
591
592
AgreementType AgreementTypes classify and structure

Agreements. For example, an AgreementType
might specify the kinds of terms and conditions
that must be agreed upon for any instance of an
Agreement of the particular type. Examples of
agreement types might include trading partner
agreements and yearly economic contracts.
Associations:
593
594
governs.
One agreement may govern another agreement,

recursively.
595
participation.
Partner types participate in agreements.
596
597
598
599
600
601
602
603
EconomicContract
A contract is subtype of agreement between partner types that
some actual economic exchanges will occur in the future.
Contracts can have recursive relationships with other contracts,
for example, yearly contracts with monthly releases and weekly or
daily shipping schedules. Contracts are containers for collections
of commitments. For example, a purchase order is a contract
wherein the line items are commitments.
604
605
Tagged Values:
606
607
608
609
initiateCondition. An economic contract term of effect is

determined by the initiateCondition. This is an
OCL constraint and may be mesurable elements
such as a date, event or system metric.
610
611
612
613
terminactionCondition An economic contract is no longer in

effect if the terminationCondition has been true
after the qualification of the iniateCondition. This
is an OCL constraint and may be mesurable
59
15
60
elements such as a date, event or system
metric.
614
615
616
Associations:
617
618
establishes.
619
620
621
622
623
An economic contract establishes two or more

commitments.
Economic Commitment
An economic commitment is an obligation to perform an economic
event (that is, transfer ownership of a specified quantity of a
specified economic resource type) at some future point in time.
Order line items are examples of commitments.
624
625
Tagged Values:
626
627
measure.
The of measurement of an economic resources

of the specified type to be transferred.
628
629
630
631
due.
The condition that determines when the transfer

of ownership is promised to occur. This is an
OCL constraint and may be defined by elements
such as a date, event or system metrics.
632
Associations:
633
634
fulfills.
Commitments may be fulfilled by economic

events.
635
636
from.
A commitment is an obligation from one partner

type.
637
638
to.
A commitment is an obligation to another partner

type.
639
640
641
reciprocal.
A commitment always has reciprocity

relationships with one or more other
commitments.
642
specifies.
Commitments specify economic resource types.
643
644
645
646
647
Reciprocity
Reciprocity is a mandatory relationship between two or more
commitments. Commercial contracts require reciprocal
commitments, called consideration.
EconomicResourceType
648
649
650
651
652
653
An economic resource type is the abstract classification or

definition of an Economic Resource. For example, in an ERP
system, ItemMaster or ProductMaster would represent the
Economic Resource Type that abstractly defines an Inventory Item
or Product. Forms of payment are also defined by economic
resource types, e.g. currency.
61
16
62
654
Associations:
655
656
classifies.
resources.
Economic resource types classify economic
657
658
659
660
661
662
classifies.
Economic Resource Types may have recursive

relationships, so that for example broad
classifications like "product" could group smaller
classifications like "product family", which in turn
could have as members the specific "product
masters" with SKU numbers..
663
specifies.
Commitments specify economic resource types.
664
EconomicResource
665
666
667
668
An economic resource is a quantity of something of value that is

under the control of an enterprise, which is transferred from one
partner type to another in economic events. Examples are cash,
inventory, labor service and machine service.
669
Tagged Values:
670
671
672
measurement. The number and unit of the economic resource.

Unit may be a unit of measure for products, a
unit of time for services, or a currency for cash.
673
674
location.
675
The location where the economic resource

currently resides or is available.
Associations:
676
677
classifies.
678
679
resourceFlow. Economic resources flow from one partner type

to another via economic events.
680
681
682
683
684
685
686
687
688
Economic resources are classified by economic

resource types.
BusinessEvent
A business event is a significant change in the state of one or
more entities within a business, e.g. the taking of an order or a
price change.
EconomicEvent
An economic event is the transfer of control of an Economic
Resource from one partner type to another partner type.
Examples would include sale, cash-payment, shipment, and
lease.
689
690
691
692
63
Tagged Values:
measurement. The number and unit of the economic resource.
that is being transferred.
17
64
693
Associations:
694
695
696
697
698
699
700
701
702
duality.
Duality is a relationship between Economic

Events, where one is the legal or economic
consideration of the other. Examples include a
payment for a product or service. If one
economic event occurs, but its dual or expected
consideration has not occurred, the giving
partner type has an imputed claim against the
taking partner type for the value of the economic
resources transferred.
703
704
fulfills.
An economic event may fulfill a prior

commitment.
705
706
707
participation.
At least two partner types must participate in an

economic event, one to give the economic
resources, the other to take them.
708
709
resourceFlow. Economic resources flow from one partner type

to another via economic events.
710
711
712
713
714
715
Duality
Duality is a relationship between Economic Events, where one is
the legal or economic consideration of the other. Examples include
a payment for a product or service. Duality relationships occur
between two or more economic events.
.
716
717
718
719
The following well-formedness rules apply to the business requirements

view metamodel package.
720
721
722
723
724
[1] All associations between partner types and business Use Cases must
specify the partner type as the source of the association and the
source association end must have a name that is the role of the
partner type with respect to the commercial transaction Use Case
to which it interfaces.
725
726
[2] A commercial transaction Use Case may not be used in an extend

association.
727
728
[3] Commercial transaction Use Cases may not be the source of an

include association.
729
730
731
732
[4] Compliant models must have all Use Cases stereotyped as

BusinessCollaborationProtocolUseCase, to at least be either
the source of an include association or the target of an
extend association.
733
734
[5] The name of the association between a partner type and a Use Case
must be the name of input/output triggers of the Use Case.
65
18
66
735
736
737
[6] All partner types in the model (classes stereotyped PartnerType)

must be defined as partner types e.g. Manufacturer, Distributor,
Retailer, Carrier, Financier and End User.
738
739
[7] Economic contracts must have at least two partner types as

participants.
740
[8] Each economic contract must establish at least two commitments.
741
742
[9] Each commitment must have a reciprocity relationship with at least

one other commitment.
743
744
745
746
747
[10]
748
3.2
If an economic event fulfills a prior commitment, the economic

resource type of the economic resource transferred by the
economic event must be compatible to the economic resource
type promised in the commitment. Compatible means either the
same type or a subtype.of the type of the commitment.
Model Semantics
749
The semantics of each element of the BRV metamodel is defined in this section.
750
Figure 7 illustrates the interrelationships between the BRV modeling elements.
67
19
68
Business Requirements View Semantics
BusinessT ask
(from Business Operations Map Metamodel)
1..n
mapsTo
+role
PartnerType
+participates
0..n
+realizati on
1..n
Busi nessCollaboration
1..n
governs
2..*
forms
<<stereotype>>
resultsIn
0..*
<<stereotype>>
Agreement
reprocity
<<stereotype>>
Economic Resource Definition
reserves
<<stereotype>>
Commitment
0..*
classifies
establish
2..*
<<stereotype>>
Economic Contract
0..*
fulfills
classifies
<<stereotype>>
Economic Resource
0..*
resourceFlow
<<stereotype>>
Economic Event
0..*
+terminator
1..*
+initiator
duality
751
752
Figure 7. BRV Illustration
753
754
755
756
757
A business collaboration use case maps to two business interface tasks specified
in a Business Operations Map. One task is the originator of a commercial
contract and the other is a responder to the commercial contract. The business
collaboration Use Case can either be a business collaboration protocol
specification or a commercial transaction specification.
758
759
760
761
762
763
A commercial transaction specifies an initiating business partner starting the

contract formation process by communicating a business document request to a
responding business partner. A responding partner accepts the conditions of the
commercial contract in zero or more returning business signals (e.g. an
acknowledgement of receipt) followed by an optional responding business
document (e.g. an acknowledgement of acceptance)9.
764
765
766
767
A business collaboration protocol choreographs commercial transactions when

the contract formation process requires a number of requesting and responding
business document exchanges. For example the creation of a purchase order
request can be specified as a business collaboration protocol that choreographs
699 Business Collaboration Protocol = ( Request Signal*, Response? ) +
70
20
71
768
769
770
771
772
773
774
both a purchase order and notification of acceptance commercial transactions. In

these instances the responding business partner does not accept the entire
purchase order offer in a response to the initial commercial transaction request.
Instead the partner communicates line item acceptance of the purchase order
using many notifications of acceptance over an agreed period. The contract is
formed when the initiating business partner is a able to reconcile all the
notifications of acceptance with the original purchase order request.
775
776
A partner type performs a specific role in business collaboration. The partner

roles are not employee or organization titles.
777
778
779
780
781
782
783
784
785
786
787
A businessrequirements use case should capture both the requirements for

forming commercial contracts and the requirements for auditing the formation of
commercial contracts. A commercial transaction models the start and end of a
commercial contract formation process. This is not always sufficient to capture
the start and end of an auditable commercial formation process. For example, an
offer and acceptance contract is formed once an originating partner receives the
agreed acceptance document. The fact that the sending partner does not
receive a verification of proper receipt for an acceptance business document is
immaterial to the formation of the contract. It may be important, however, if the
sending partner wishes to retain an audit trail of the process for a receiving party
to verify proper receipt of the business document.
788
789
790
791
792
793
794
795
796
797
798
Economic contracts carry two or more reciprocal commitments, which are

promises that future economic events will occur, specifying particular economic
resource types. Commercial contracts require reciprocal commitments, called
considerations. Subsequently, the promised economic events may fulfill the
commitments, transferring ownership of actual economic resources of the
committed types from one partner type to another. For example, a purchase
order is an economic contract, typically committing one partner type to deliver a
product or service of a specified type, and the other partner type to pay for it.
The delivery of the product or service might be the first economic event (fulfilling
one commitment) and obligating (by the duality relationship) the reciprocal
partner type to pay the committed price.
799
800
801
802
803
804
805
72
3.3
The BRV model can be a business collaboration protocol Use Case model or a
commercial transaction Use Case model, as well as business collaborations.

Figure 8 shows the metamodel for managing the BRV model. The
modeling elements used to manage and organize these modeling
elements are defined in this section.
21
73
Business Requirements View Model Management
<<stereotype>>
Busi nessRequi rementsVi ew
baseElement = Model
<<stereotype>>
CommercialTransacti onUseCase
requesti ngBusi nessFunction : Stri ng
respondingBusinessFunction : String
<<stereotype>>
Busi nessCollaborati on
baseElement = Coll aboration
begi nsWhen : String
definition : Stri ng
endsWhen : String
exceptions : String
postcondi tions : Stri ng
806
807
Figure 8. BRV Model Management Abstract Syntax
808
809
The following stereotypes and tagged values are contained in the BRV
model management metamodel.
810
BusinessRequirementsView
811
812
The Business Requirements View specifies the requirements for

one or more business collaborations.
813
814
815
The following well-formedness rules apply to the business requirements

816
817
[1] A business requirements view model contains one or more

Commercial Transaction Use Case.
818
819
[2] Each Commercial Transaction Use Case is realized by a Business

Collaboration.
820
3.4
821
822
The semantics of each element of the BRV model management metamodel is

defined in this section.
823
824
Figure 9 illustrates the interrelationships between the BRV model management

and model elements.
74
22
75
BusinessRequirementsView
1
0..*
825
826
827
828
76
Figure 9. BRV Model Management Illustration

A business requirements view is a model of the requirements of a single
business collaboration Use Case and its realizations as business collaborations.
23
77
829
4.
The Business Operational View Metamodel
830The BOV of a process model specifies the flow of business information10 between
831business roles as they perform business activities. The business process specification
832can be formal an in the formation of offer/acceptance commercial contracts as well as
833informal as in the announcement of new products.
834This section specifies the abstract syntax and semantics of the BOV of a CT and BCP
835model and model management packages. The abstract syntax of models is specified
836using stereotypes and tagged values. The semantics of models are specified using the
837truth semantics of wellformed-formula expressed with OCL expressions and with
838natural language.
839
840
841
842
843
844
845
846
847
848
849
4.1
The syntax of e-business collaboration models comprises stereotypes and

tagged values. The semantics of e-business collaboration models are specified
using the truth semantics of wellformed-formula (specified as OCL expressions)
and with language.

Figure 10 specifies the modeling elements and their interrelationships that
are used to express the structure and behavior of objects in the BOV of a
CT and BCP model. Each element and interrelationship permitted in a
BOV is defined in the metamodel specified in this section of the
document.
850
7810 The use the term business information is intensional as the BRV of a business process
79must capture the semantics of business information exchanged and not the data format or
80storage format of the information that is specified in the FSV.
81
24
82
<<stereotype>>
<<stereotype>>
BusinessPartner
+partner
BusinessCollaborationProtocol
baseElement = Activ ity Graph
2..*
baseElement = Class
<<stereotype>>
<<stereotype>>
BusinessDocument
DocumentEnv elope
baseElement = Class
baseElement = Class
<<stereotype>>
FunctionalRole
+role
1..*
baseElement = Class
OrganizationalRole
EmployeeRole
Busi nessActivity
StructuredDocument
UnstructuredDocument
body : dataTy pe = String
baseElement = ActionState
isAuthorizationRequired : Boolean
isNonRepudiationRequired : Boolean
timeToPerf orm : TimeExpression
timeToAcknowledgeReceipt : TimeExpression
timeToAcknowledgeAcceptance : TimeExpression
<<stereotype>>
InformationEntity
baseElement = Class
isConf idential : Boolean
isTamperProof : Boolean
isAuthenticated : Boolean
<<stereotype>>
RequestingBusinessActivity
<<stereotype>>
RespondingBusinessActivity
retry Count : NaturalNumber

isNonRepudiationOf ReceiptRequired : Boolean
<<stereotype>>
CommercialTransact ionActiv ity
+transaction
baseElement = ActionState
timeToPerf orm : TimeExpression
isConcurrent : Boolean
isIntelligibleCheckRequired : Boolean
<<stereotype>>
CommercialTransacti on
baseElement = Activ it y Graph
isSecureTransportRequired : Boolean
851
852
853
Figure 10. BOV Abstract Syntax
BusinessActivity11
854
855
856
The business activity is the state of a business action executed by

a partner role during commercial transaction. This is an abstract
class that is not a stereotype.
857
Tagged Values:
858
859
860
861
862
863
864
865
866
867
IsAuthorizationRequired. If a partner role needs authorization to

request a business action or to respond to a
business action then the sending partner role
must sign the business document exchanged
and the receiving partner role must validate this
business control and approve the authorizer. A
responding partner must signal an authorization
exception if the sending partner role is not
authorized to perform the business activity. A
sending partner must send notification of failed
8311 A business activity is derived from the UML Action State model element. This enables
84multiple exit and entry transitions for the requesting and responding activity states. A business
85activity is not derived from the UML Call State model element that typically models the
86behavior of an operation. An Activity state does not have an internal transition, exit action or a
87do activity. The entry action of a Call State is a single call action.
88
25
89
868
869
870
authorization if a responding partner is not

authorized to perform the responding business
activity.
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
isNonRepudiationRequired. If non-repudiation of origin and

content is required then the business activity
must store the business document in its original
form for the duration mutually agreed to in a
trading partner agreement. A responding partner
must signal a business control exception if the
sending partner role has not properly delivered
their business document. A requesting partner
must send notification of failed business control
if a responding partner has not properly
delivered their business document.
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
timeToPerform. Both partners agree to perform a commercial

transaction within a specific duration. A
responding partner must exit the transaction if
they are not able to respond to a business
document request within the agreed timeout
period. A sending partner must retry a
commercial transaction if necessary or must
send notification of failed business control
(possibly revoking a contractual offer) if a
responding partner does not deliver their
business document within the agreed time
period. The time to perform is the duration from
the time a business document request is sent by
a requesting partner role until the time a
responding business document is properly
received14 by the requesting partner role. Both
partners agree that the business signal
document or business action document
specified as the document to return within the
time to perform is the Acceptance Document15
This property provides the following audit

controls:
Verify sending role identity (authenticate)12
Verify the identity of the sending role (employee
or organization). For example, a drivers license
or passport document with a picture is used to
verify an individuals identity by comparing the
individual against the picture.
Verify content integrity13 Verify the integrity
of the original content sent from a partner role
i.e. check that the content has not been altered
by a 3rd party while the content was exchanged
between partners.
9012 The BCF specifies digital signatures for partner-to-partner non-repudiation of origin and
91content.
9213 The BCF specifies MD5 or SHA-1 message digest algorithms and asymmetric encryption to
93provide content integrity.
9414 Properly received is legally defined in a trading partner agreement. Refer to the Create
95Trading Partner Agreement commercial transaction specification in the BCF.
9615 This is not a business acceptance document.
97
26
98
916
917
in an on-line offer/acceptance contract formation

process.
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
TimeToAcknowlegeReceipt. Both partners agree to mutually

verify receipt of a requesting business document
within specific time duration. A responding
partner must exit the transaction if they are not
able to verify the proper receipt of a business
document request within the agree timeout
period. A sending partner must retry a
responding partner does not verify properly
receipt of a business document request within
the agreed time period. The time to
acknowledge receipt is the duration from the
time a business document request is sent by a
requesting partner until the time a verification of
receipt is properly received by the requesting
business partner. This verification of receipt is an
audit-able business signal and is instrumental in
contractual obligation transfer during a contract
formation process (e.g. offer/accept).
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
timeToAcknowledgeAcceptance. Both partners agree to the

need for a business acceptance document to be
returned by a responding partner after the
requesting business document passes a set of
business rules. The time to acknowledge
business acceptance of a requesting business
document is the duration from the time a
requesting partner sends a business document
until the time an acknowledgement of
acceptance is properly received by the
requesting partner. A responding partner must
exit the transaction if they are not able to
acknowledge business acceptance of a
business document request within the agreed
timeout period. A sending partner must retry a
responding partner does not acknowledge
acceptance of a business document within the
agreed time period.
960
961
962
963
A requesting business activity is a business activity that is

performed by a partner role requesting commerce from another
business partner role.
964
Tagged Values:
965
966
99
isNonRepudiationOfReceiptRequired. Both partners agree to

mutually verify receipt of a requesting business
27
100
document and that the receipt must be nonreputable. A receiving partner must send
notification of failed business control (possibly
revoking a contractual offer) if a responding
partner has not properly delivered their business
document.
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
Non-repudiation of receipt provides the following

audit controls.
Verify responding role identity (authenticate) 16
Verify the identity of the responding role
(individual or organization) that received the
requesting business document.
of the original content of the business document
request.
retryCount.
Both partners agree to the number of times to

retry a transaction when a time-out-exception
condition is signaled. This parameter only
applies to time-out signals and not business
process controls or document content
exceptions.
990
991
992
A responding business activity is a business activity that is

performed by a partner role responding to another business
partner roles request for commerce.
993
Tagged Values:
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
isIntelligibleCheckRequired. Both partners agree that a

responding partner role must check that a
requesting document is not garbled (unreadable,
unintelligible) before verification of properly
receipt is returned to the requesting partner.
Verification of receipt must be returned when a
document is accessible but it is preferable to
also check for garbled transmissions at the
same time in a point-to-point synchronous
business network where partners interact
without going through an asynchronous service
provider.
InformationEntity
An information entity realizes structured business information that
is exchanged by partner roles performing activities in a
commercial transaction. Information entities include or reference
other information entities through associations.
10116 The BCF specifies digital signature for partner-to-partner non-repudiation of origin and
102content.
10317 The BCF specifies MD5 or SHA-1 message digest algorithms and asymmetric encryption to
104provide content integrity.
105
28
106
1011
1012
1013
1014
A secure information entity is an information entity with security

controls. Security controls must be specified when information
must be secured within an enterprise until it is accessed by an
authorized partner role.
1015
1016
1017
1018
These parameters on this model element must be specified in a

manner that ensures document integrity by maintaining a chainof-custody from the sender to the intended recipient of the
business information.
1019
Tagged Values:
1020
1021
1022
isConfidential. The information entity is encrypted so that

unauthorized parties cannot view the
information.
1023
1024
1025
1026
1027
1028
isTamperProof. The information entity has an encrypted

message digest that can be used to check if the
message has been tampered with. This requires
a digital signature (senders digital certificate
and encrypted message digest) associated with
the document entity.
1029
1030
1031
isAuthenticated. There is a digital certificate associated with the

document entity. This provides proof of the
signers identity.
1032
1033
1034
StructuredDocument
A structured document is a information entity container.
1035
1036
An unstructured document is any document that is not comprised

of document entities.
1037
Tagged Values:
1038
1039
1040
1041
1042
1043
1044
1045
1046
dataType.
This property specifies the document type. It is

recommended that a registered MIME type by
used for this property (refer to
http://www.iana.org) for registered MIME types.
Partners can agree to use their own
experimental MIME types.
OrganizationalRole18
Only an organization performs a particular role in an e-business
collaboration. An employee does not perform these activities.
10718 Specifying an organizational role is a FSV requirement to model a network component design
108that can support an organization performing the specified business activity. An employee
109cannot perform this activity.
110
29
111
1047
FunctionalRole19
1048
1049
1050
A partner role is a functional role, an employee role or an

organizational role. Either an employee role or an organizational
role can perform a functional role.
1051
1052
An organizational role must be performed by a conforming

network component that provides a business service.
1053
1054
1055
1056
1057
1058
1059
EmployeeRole20
An employee for business/legal reasons can only perform an
employee role. Usually the details of the employee must be
captured and stored/transmitted to another partner for
auditing/liability purposes when the two partner roles are not in the
same organization.
CommercialTransaction
1060
1061
1062
1063
1064
1065
1066
1067
1068
A commercial transaction is a set of business information and

business signal exchanges amongst two commercial partners that
must occur in an agreed format, sequence and time period. If any
of the agreements are violated then the transaction is terminated
and all business information and business signal exchanges must
be discarded. Commercial transactions can be formal as in the
formation of on-line offer/acceptance commercial contracts and
informal an in the distribution of product announcements.
Commercial transactions can comprise sub-transactions.
1069
Tagged Values:
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
isSecureTransportRequired. Both partners must agree to

exchange business information using a secure
transport channel. The following security
controls ensure that business document content
is protected against unauthorized disclosure or
modification and that business services are
protected against unauthorized access. This is a
point-to-point security requirement. Note that
this requirement does not protect business
information once it is off the network and inside
an enterprise. The following are requirements for
secure transport channels.
Authenticate sending role identity21 Verify
the identity of the sending role (employee or
organization) that is initiating the role interaction
11219 Specifying a partner role is a FSV requirement to create a network component design that
113can support an employee as well as an organization when performing the specified business
114activity.
11520 Specifying an employee role limits the number of network component configurations that
116must be considered in the FSV of the model. Only specify an employee role if only an employee
117can perform the specified business activity.
11821 The BCF specifies digital certificates and SSL to verify the identity of sending (and receiving)
119roles (individuals and organizations).
120
30
121
1085
1086
1087
1088
(authenticate). For example, a drivers license or

passport document with a picture is used to
verify an individuals identity by comparing the
individual against the picture.
1089
1090
1091
1092
Authenticate receiving role identity Verify

the identity of the receiving role (employee or
organization) that is receiving the role
interaction.
1093
1094
1095
1096

of the content exchanged during the role
interaction i.e. check that the content has not
been altered by a 3rd party.
1097
1098
1099
1100
1101
1102
1103
1104
Maintain content confidentiality23

Confidentiality ensures that only the intended,
receiving role can read the content of the role
interaction. Information exchanged during role
interaction must be encrypted when sent and
decrypted when received. For example, you seal
envelopes so that only the recipient can read the
content.
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
A business collaboration protocol choreographs one or more
commercial transaction activities. A business collaboration
protocol is not a transaction and should be used in cases where
transaction rollback is inappropriate. For example, a buying
partner may request a purchase order creating from a selling
partner. The selling partner may partially accept purchase order
and thus complete the transaction but may only return shipping
information on part of the order. The buying partner is sent any
number of later notifications regarding the outstanding portions of
the order until the order is completely reconciled.
partner.
The partners that collaborate are enumerated so

that they can be associated with the roles that
they provide in each of the commercial
transaction activities.
BusinessPartner
The business partners that participate in business collaborations
are enumerated for each business collaboration protocol. Partners
provide the initiating and responding roles in the protocol.
role.
The roles provided by each of the partners in the

business collaboration protocol. A partner
provides each initiating and responding role in a
commercial transaction activity.
12222 The BCF specifies digital certificates and SSL to provide point-to-point content integrity.
12323 The BCF specifies digital certificates and SSL for point-to-point encryption and decryption.
124
31
125
1128
CommercialTransactionActivity
1129
1130
1131
1132
A commercial transaction activity is a business collaboration

protocol activity that executes a specified commercial transaction.
The commercial transaction activity can be executed more than
once if the isConcurrent property is true.
1133
Tagged Values:
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
timeToPerform. Both partners agree to perform a commercial

transaction activity within a specific duration.
The originating partner must send a failure
notification to a responding partner on timeout. A
responding partner simple terminates its activity.
The time to perform is the duration from the time
a commercial transaction activity initiates the
first commercial transaction until there is a
transition back to the initiating commercial
transaction activity. Both partners agree that the
business signal document or business action
document specified as the document to return
within the time to perform is the Acceptance
Document24 in an on-line offer/acceptance
contract formation process.
1149
1150
1151
1152
transaction.
This property relates a specific commercial

transaction to a commercial transaction activity.
The commercial transaction activity executes the
commercial transaction.
1153
1154
1155
1156
1157
1158
isConcurrent.
If the commercial transaction activity is

concurrent then more than one commercial
transaction can be open at one time. If the
commercial transaction activity is not concurrent
then only one commercial transaction activity
can be open at one time.
1159
1160
1161
DocumentEnvelope
A document envelope is a container for structured and
unstructured business documents.
1162
1163
1164
The following well-formedness rules apply to the business operational

1165
BusinessActivity
1166
1167
[1] If non-repudiation is required then the input or returned business

document must be a tamper-proofed entity.
1168
1169
1170
[2] If authorization is required then the input business document and

business signal must be an authenticated or a tamper proofed
secure entity.
127
32
128
1171
1172
1173
1174
[3] The time to acknowledge receipt must be less than the time to
acknowledge acceptance if both properties have values.
1175
1176
1177
[4] If the time to acknowledge acceptance is null then the time to perform
an activity must either be equal to or greater than the time to
acknowledge receipt.
1178
1179
1180
[5] The time to perform a transaction cannot be null if either the time to
acknowledge receipt or the time to acknowledge acceptance is not
null.
1181
1182
[6] If non-repudiation of receipt is required then the time to acknowledge

receipt cannot be null.
1183
1184
[7] The time to acknowledge receipt, time to acknowledge acceptance

and time to perform cannot be zero.
1185
1186
[8] If non-repudiation is required at the requesting business activity, then

there must be a responding business document.
1187
1188
1189
1190
[9] The time to acknowledge receipt, time to acknowledge acceptance

and time to perform properties must be specified for both the
requesting and responding business activities and they must be
equal.
1191
1192
1193
[10]
1194
1195
1196
[11]There must be one output transition whose target state vertex is a

final state specifying the state of the machine when the activity is
successfully performed.
1197
1198
1199
[12]
There must be one output transition whose target state vertex is a

final state specifying the state of the machine when the activity is
not successfully performed.
1200
1201
[13]
There must be one output transition to an object state that in turn

has one output transition to a responding business activity.
1202
1203
1204
[14]
There must be zero or one input transition from an object state

that in turn has one input transition from a responding business
activity.
1205
1206
1207
[15]
There must be one input transition from an object state that in turn
has one input transition from a requesting business activity.
1208
1209
[16]
There must be zero or one output transition to an object state that

in turn has an output transition to a requesting business activity.
129
timeToAcknowlegeReceipt < timeToAcknowlegeAcceptance
There must be one input transition whose source state vertex is

an initial pseudo state.
33
130
1210
Object Flow State
1211
1212
[17]
The source and target of an object flow must not be the same
business activity.
1213
1214
[18]
The source and target of the requesting object flow must be

opposite to the source and target of the responding object flow.
1215
Information Entity
1216
1217
1218
1219
[19]
The associations on an information entity must be aggregation

relationships with other information entities to form a partonomy, a
hierarchical decomposable arrangement of business document
parts.
1220
1221
[20]
The information entity associations only must be navigable from a

containing entity to an element entity (has-part relationship).
1222
1223
[21]
Constraints on an information entity association must be specified

on the role of the part (supplier) with respect to the whole (client).
1224
1225
[22]
The client and supplier of an entity association must not be the

same entity.
1226
Business Collaboration Protocol
1227
1228
[23]
1229
4.2
A business partner cannot provide both the initiating and

responding roles of the same commercial transaction activity.
Model Semantics
1230
1231
The semantics of each element of the BOV model metamodel is defined in this
section.
1232
Figure 11 illustrates the interrelationships between the BOV model elements.
131
34
132
CommercialTransactionActiv ity
1..*
1
1
+transaction
1
+partner
+role
2..*
BusinessPartner
RequestingBusinessActiv ity
1..*
+performedBy
FunctionalRole
RespondingBusinessActiv ity
1..*
BusinessActivity
+performs
1..*
+source
0..n
0..1
0..*
+type
DocumentEnv elope
+target
0..*
ObjectFlowState
+1..2
1..*
BusinessDocument
signedBy
signedBy
+head
0..*
0..*
Inf ormationEntity
+body
+hasPart
StructuredDocument
0..*
+partOf
0..*
1233
1234
Figure 11. BOV Illustration
4.2.1Business Activities
1235
1236
1237
1238
1239
1240
1241
1242
A business activity is an activity performed by a partner role participating

in a commercial transaction. There are two business activities in a
commercial transaction each of which is performed by one of two partners
engaged in a commercial endeavor. A business partner that is initiating
the commercial transaction performs a requesting business activity. A
business partners that is responding to a request to engage in a
commercial transaction perform a responding business activity.
1243
1244
1245
A commercial transaction specifies either a synchronous or asynchronous

flow of control between two activities. The commercial transaction is a unit
of work. All of the interactions in a commercial transaction must succeed
133
35
134
1246
1247
or the transaction must be rolled back to a defined state before the

transaction was initiated.
1248
1249
1250
1251
1252
There are two business signals that can be asynchronously returned to

the initiator of the commercial transaction: a business signal to verify
proper receipt of a business document request and a business signal to
non-substantively confirm the acceptance of a requesting business
document for business processing.
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
If any of the time out parameters are exceeded, a time out exception must
be thrown. If the retryCount property on the responding business
activity is greater than zero then the commercial transaction must be reinitiated (or a notification of failed business control possibly revoking a
contractual offer must be sent). All business signals and business
documents returned after the transaction was initiated and up until the
time out exception must be discarded. The recurrence property specifies
the number of times a commercial transaction must be initiated. If the
recurrent property value is 3 then the commercial transaction can be
initiated a total of 4 times (the first initiation plus 3 retries). The time to
perform property specifies the time to perform a single commercial
transaction.
1265
1266
A responding partner simply terminates if a timeout is thrown. This

prevents responding commercial transactions from hanging indefinitely.
1267
1268
1269
1270
1271
1272
A partner role that initiates an asynchronous commercial transaction does

not need to receive any business signals. A partner role that initiates a
synchronous business transaction must be able to receive business
signals and must block until the flow of control is returned. This should not
preclude the initiation and execution of multiple concurrent commercial
transactions, however.
1273
1274
1275
1276
1277
If any business exceptions (includes negative receipt and acceptance

acknowledgements) are signaled then the commercial transaction must
terminate. The commercial transaction must not be re-initiated even if the
retryCount parameter is not zero. Commercial transactions must only
be retried if a timeout exception is thrown.
1278
1279
There are two business signals that are used for on-line commercial
contract formation and auditing:
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
Acknowledge receipt business signal. The UN/EDIFACT model

Trading Partner Agreement (TPA) suggests that a partners
should agree on the point at which a message can be "said" to
be properly received and this point should be when a receiving
partner can "read" a message. They suggest this should be the
point after which a message passes a structure/ schema
validity check. Note that this is not a necessary condition for
verifying proper receipt, only accessibility is. The property
isIntelligibleCheckRequired allows partners to agree that a
message should be readable before its receipt is verified25.
13525 This is the convention specified for RosettaNet commercial transactions.
136
36
137
1290
1291
1292
1293
1294
1295
1296
1297
1298
Acknowledge acceptance business signal. The UN/EDIFACT

model TPA suggests that partners should agree on the point at
which a message can be "said" to be accepted for business
processing and this point should be after the contents of a
business document have passed a business rule validity check.
For example, if I order 100000000000 copies of a single book
from Amazon I am assuming it will fail some business rule
check. These business rules are often found in trading
contracts.
1299
1300
1301
Figure 12 and Figure 13 show the valid activity states for requesting and
responding partner roles respectively. The behavior of each role is
determined by the values specified for each business activity.
1302
1303
1304
1305
1306
Business models may find it convenient to develop commercial

transaction design patterns to facilitate the development of their
specifications (refer to BCF#8 for definitions). The following five propertyvalue conventions for commercial transactions have proven useful in the
application of the metamodel to existing business requirements.
1307
1.
Business Transaction
1308
2.
Request / Confirm
1309
3.
Query / Response
1310
4.
Request / Response
1311
5.
Notification
1312
6.
Information Distribution
1313
1314
These conventions are applied by stereotyping the requesting business

activity with the following syntax.
1315
Transaction
Stereotype
Business Transaction
ServiceTransactionActivity
Request / Confirm
RequestConfirmActivity
Query / Response
QueryResponseActivity
Request / Response
RequestResponseActivity
Notification
NotificationActivity
Information Distribution
InformationDistributionActivity
1316
1317
1318
138
37
139
businessDocumentReq uest[
timeToPerform = null ]
newBusinessDocumentRequest
[ timeToPerform ! = 0 ]
Idle
do/ wait
on exception/ ^requestor.revokeDocumentRequest
on newBusinessDocumentReq uest/ responder.businessDocumentRequest
on acknowledgeReceiptTimeOut[ recurrence not exceeded ]/ ^responder.businessDocumentReq uest
on acknowledgeAcceptanceTimeOut[ recurrence not exceeded ]/ ^responder.businessDocumentRequest
on performanceTimeOut[ recurrence not exceeded ]/ ^responder.businessDocumentRequest
exception
exception
businessDocumentResponse
acknowledgeReceiptTimeOut
performanceTimeOut
documentProperlyReceived[
timeToAcknowlegeReceipt =
timeToPerform ]
timeToAcknowlegeReceipt ! = null ]
timeToAcknowledgeReceipt = null and
timeToAcknowlegeAcceptance = null ]
Waiting f or Business Processing Response
documentProperlyReceived[
timeToAcknowledgeAcceptance =
null ]
do/ wait
on documentResponseReceived[ isAuthorizationRequired = true ]/ checkAuthorization
on documentResponseReceived[ isNonRepudiationRequired = true ]/ checkNonRepudiation
Waiting f or Verif ication of Proper Receipt

do/ wait
on receiptAcknowledged[ isNonRepudiationOfReceiptRequired = true ]/ checkNonRepudiation
documentResponseReceived
receiptAcknowledged
documentAccepted[
timeToAcknowlegeAcceptance <
documentProperly Receiv ed[
timeToAcknowlegeAcceptance != null ]
acknowlegeAcceptanceTimeOut
exception
Waiting f or Business Document Acceptance
documentAccepted[ timeToAcknowledg eAcceptance = timeToPerform ]
do/ wait
on acceptanceReceived[ isAuthorizationReq uired = true & (timeToAcknowledgeAcceptance = timeToPeform) ]/ checkAuthorization
acceptanceReceived
1319
1320
140
Figure 12. Requesting Business Activity States
38
141
[ timeToPerf orm != 0 ]
documentAccepted[ timeToAcknowledgeAcceptence = timeToPerf orm ]
documentAccessible[ timeT oAcknowledgeReceipt = timeT oPerform ]
Idle
acknowledgeAcceptanceTimeOut
acknowl edgeReceiptT imeOut
do/ wait
on exception/ ^requestor.rejectDocumentRequest
exception
exception
businessDocumentResponse
controlsApproved[ timeToPerform = nul l ]
exception
exception
perf ormanceTimeOut
businessDocumentRequest
Processing Business Document
Applying Process Controls
entry / processBusinessDocument
do/ ^requestor.businessDocumentResponse
on businessDocumentRequest[ isNonRepudiationRequired = true ]/ checkNonRepudiation

on businessDocumentRequest/ checkSequenceControls
controlsApproved[
timeToAcknowledgeReceipt = null ]
controlsApproved[
timeToAcknowledgeR
eceipt != null ]
documentAccepted[
timeToAcknowledgeAcceptance !=
timeToPerf orm ]
documentAccessible[
timeToAcknowledgeAcceptan
ce = null &
timeToAcknowledgeReceipt
!= timeToPerform ]
Accepting for Busi ness Processing

on documentAccessible[ isIntelligableCheckRequired = f alse ]/ checkDocumentGrammar
on documentAccessible[ isAuthorizationRequired = true ] / checkAuthorization
on documentAccessible/ checkDocumentContent
do/ ^requestor.acknowledgeDocumentAcceptance
documentAccesible[
timeToAcknowledgeAcceptance != null
Verifying Proper Receipt

on controlsApprov ed[ isIntelligibleCheckRequired = true ]/ checkDocumentGrammar
do/ ^requestor.acknowledgeDocumentReceipt
1321
1322
142
Figure 13. Responding Business Activity States
39
143
1323
1324
The following table specifies the property-values for requesting business activities
for each of the commercial transaction stereotypes.
1325
Time to
Acknowledge
Receipt
Time to
Acknowledge
Acceptance
Time to Perform
Authorization
Required
Non-repudiation
of Origin and
Content
Non-repudiation
of Receipt
Recurrence
Business
Transaction
2hrs
6hr
24hr
true
true
true
Request /
Confirm
null
null
24hrs
false
false
true
Request /
Response
null
null
4hrs
false
false
null
Query /
Response
null
null
4hrs
false
false
null
Notification
24hrs
null
24hrs
false
true
true
Information
Distribution
24hrs
null
24hrs
false
false
false
1326
1327
1328
The following table specifies the property-values for responding business activities
for each of the commercial transaction stereotypes.
1329
Time to
Acknowledge
Receipt
Time to
Acknowledge
Acceptance
Time to Perform
Authorization
Required
Non-repudiation
of Origin and
Content
144
Business
Transaction
2hrs
6hr
24hr
true
true
Request /
Confirm
2hrs
null
24hrs
true
false
Request /
Response
null
null
4hrs
false
false
Query /
Response
null
null
4hrs
false
false
40
145
1330
1331
1332
1333
Notification
24hrs
null
24hrs
false
false
Information
Distribution
24hrs
null
24hrs
false
false
It is recommended that the following stereotype be used on the responding

business activity when authorization is required for a responding activity to
respond to a business document request.
1334
Business Activity
Authorized Activity
1335
1336
1337
1338
1339
1340
1341
Stereotype
AuthorizedActivity
Another convention that makes the application of these stereotypes easier is to

only stereotype the requesting business activity when a symmetrical business
relationship is designed. With this convention the time to perform, time to
acknowledge receipt, time to acknowledge acceptance, non-repudiation and
authorization requirements are assumed symmetrical and thus applicable equally
to both the requesting and responding business activities.
4.2.1.1
Timeout Exceptions
1342
1343
1344
1345
1346
1347
A time-out parameter must be specified whenever a requesting partner

expects one or more responses to a business document request. A
requesting partner must not remain in an infinite wait state. There must be
a time-out parameter specified for each expected response. There are four
possible responses and hence four potential time-out specifications:
1348
1349
Acknowledge Receipt. The time a responding role has to acknowledge

receipt of a business document.
1350
1351
1352
Non-Substantive Acknowledge Business Acceptance. The time a

responding role has to non-substantively acknowledge business
acceptance of a business document.
1353
1354
1355
Substantive Acknowledge Business Acceptance. The time a responding

role has to substantively acknowledge business acceptance of a business
document.
1356
1357
Perform Transaction. The time a commercial transaction has to complete.
1358
1359
1360
1361
The time-out value for each of the time-out parameters is absolute i.e. not
relative to each other. All timers start when the requesting business
document is sent. The timer values must comply with the well-formedness
rules in the previous section.
1362
1363
1364
If the retry count is not zero and a time-out condition is signaled for any of
the expected responses then the original business document must be
resent from the initiating partner role. The original business document
146
41
147
1365
1366
must be sent even if responding acknowledgements have already been

received.
1367
1368
1369
1370
1371
If an initiating partner receives a response after a time-out condition is

signaled and the original business document has already been resent then
this must be ignored. A responding partner that receives a business
document from a retry must terminate their responding transaction for the
previous business document and the retry request must be serviced.
1372
1373
1374
1375
1376
1377
Upon sending a business document retry, it MUST be guaranteed that the

sending party resends an identical business document, save for a
timestamp. Otherwise, a receiving partner must be capable of rolling back
an incoming business document at any point in time through the
acknowledgment interval, acceptance interval, and back-end processing
interval.
1378
1379
1380
1381
1382
1383
When the time to perform an activity equals the time to acknowledge

receipt or the time to acknowledge business acceptance then the highest
priority time out exception must be used when the originator provides a
reason for revoking their original business document offer. The time to
perform exception is lower priority than both the time to acknowledge
receipt and the time to acknowledge business acceptance.
1384
1385
1386
4.2.1.2
Business Protocol Exceptions
A business protocol exception terminates the business transaction. The

following are business protocol exceptions.
1387
1388
1. Negative acknowledgement of receipt. The structure/schema of a

message is invalid.
1389
1390
2. Negative acknowledgement of acceptance. The business rules are

violated.
1391
1392
3. Performance exceptions. The requested business action cannot be

performed.
1393
1394
4. Sequence exceptions. The order or type of a business document or

business signal is incorrect.
1395
1396
5. Syntax exceptions. There is invalid punctuation, vocabulary or

grammar in the business document or business signal.
1397
1398
6. Authorization exceptions. Roles are not authorized to participate in

the commercial transaction.
1399
1400
7. Business process control exceptions. Business documents are not

signed for non-repudiation.
1401
1402
1403
1404
1405
1406
A responding role that throws a business protocol exception signals the

exception back to the requesting role and then terminates the commercial
transaction. A requesting role that throws a business protocol exception
terminates the transaction and then sends a notification revoking the
offending business document request. The requesting role cannot send a
business signal to the responding role.
148
42
149
1407
1408
4.2.1.3
Pattern Property Modification Rules
The following rules apply when modifying design pattern properties.
1409
1410
1. If the convention for a time property value is >0 then it cannot be

changed to NA.
1411
1412
1413
2. If the convention for a time property value is NA then it cannot be

changed. This is because the change would add or remove a role
interaction that is not allowed, as it will change the convention.
1414
1415
1416
1417
1418
3. The non-repudiation values specified in the convention cannot be

changed except that both Query/Response and Request/Confirm
can be changed to non-repudiation required. Changing any of the
other non-repudiation values would change the semantic meaning
of the commercial transaction.
1419
1420
1421
4. The Authorization Required property can only be changed to N. It

cannot be changed to Y if it is already set to N according to the
convention.
1422
1423
1424
1425
1426
1427
1428
1429
4.2.2Requesting Business Activity

Preconditions and post-conditions may be specified when there are
structure or content constraints that apply to the document when it is used
in a particular commercial transaction.Preconditions are specified in the
guard of a transition from the initial pseudo state to a requesting business
activity. Post-conditions are specified in the guard of a transition from a
requesting business activity to state vertex that is the state of the machine
when the business activity is successfully performed.
4.2.3Object Flow
1430
1431
1432
1433
Business documents flow states specify the business document flow between
roles as they perform business activities. Each business document has a source
and target business activity.
1434
1435
1436
1437
1438
1439
An object flow has a type that is a document envelope. An envelope contains one
or more structured and unstructured business documents. A business document is
signed if non-repudiation of origin and content is required. A detached signature is
used to provide non-repudiation of origin and content of a business document as it
pertains to the entire document. The signature must be part of the business
document for authorization as the content of the document is authorized.
1440
1441
1442
Structured business documents contain information entities. Information entities

contain other information entities. Containment is modeled using UML
associations.
1443
1444
4.2.4Business Collaboration Protocol
1445
1446
1447
4.2.5BOV-to-BRV Mapping
150
A BOV model is the business operational view of a business process that meets
the requirements of a business process as described in a BRV model. Figure 14
43
151
1448
1449
illustrates the elements of the BOV metamodel that map to elements of the BRV
metamodel.
<<stereoty pe>>
FunctionalRole
<<stereotype>>
PartnerType
1..n
mapsT o
(f rom Business Requirements View Metamodel)
<<stereotype>>
mapsT o
<<stereotype>>
mapsT o
CommercialT ransactionUseCase
BusinessCollaborationProtocolUseCase
1450
Figure 14. BOV-to-BRV Syntax Map
1451
1452
1453
1454
1455
1456
1457
1458
1459
A functional role in the BOV is a refinement of a partner type performing a

particular role as described in a commercial transaction Use Case. A commercial
transaction is an activity graph that is a refinement of a commercial transaction
Use Case. Partner roles are modeled in a commercial transaction activity graph
and partner types and their roles are modeled in a Use Case model. The
conditional constraints on business information that are described in BRV
collaborations are described using business information entity constraints and
business information constraints.
1460
1461
A business collaboration protocol activity graph is a refinement of a business

collaboration protocol Use Case.
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
152
4.3
Business process models specify business process participants interacting while

executing a business process. A complete business process model must comprise the
following modeling elements: business process information, business process
participants, and business process flow. The modeling elements used to manage and
organize these three modeling elements are described in this section.

Figure 15 shows the metamodel for managing business process models. The
modeling elements used to manage and organize these three specifications are
described in this section.
44
153
<<stereoty pe>>
BusinessOperationalView
baseElement = Model
1472
1473
Figure 15. BOV Model Management Abstract Syntax
1474
1475
The following stereotypes and tagged values are contained in the business
operational view management metamodel.
1476
1477
1478
1479
The business operational view of an e-business collaboration model

comprises diagrams and specifications that show the flow of business data
entities between roles as they perform business activities.
1480
1481
1482
The following well-formedness rules apply to the business operational view

metamodel package.
1483
1484
1485
[1] A business operational view must comprise one commercial transaction or

business collaboration protocol state machine.
1486
4.4
1487
1488
The semantics of each element of the BOV model management metamodel is defined in
this section.
1489
1490
Figure 15 illustrates the interrelationships between the BOV model management and
model elements.
154
45
155
DocumentEnv elope
1..2
FunctionalRole
BusinessDocument
1..*
+roles
2..*
BusinessPartner
+partners
2..*
0..1
1..*
1..*
CommercialTransactionActiv ity
+transaction
1491
1492
1493
1494
1495
Figure 16. BOV Model Management Illustration

The Business Operational View contains all the objects and activity graphs in the BOV
model. A BOV model can comprise zero or one business collaboration protocol
specification and can comprise one or more commercial transaction specifications.
1496
156
46
157
1497
5.
The FunctionalService View Metamodel
1498This Functional Service View (FSV) of the e-business business collaboration metamodel
1499captures the syntax and semantics of business actions and their exchange between network
1500components that provide business services. The FSVs metamodel specifies the elements of an
1501execution process (Service Collaboration) that comprises business transaction exchange
1502between network component business services as a result of the execution of business activities.
1503The functional service model is a reification of the business operational view model.
1504The first part of this section specifies the syntax and semantics of execution processes. The
1505second part of this section specifies the organizational management elements of these execution
1506process models.
1507
1508
1509
1510
1511
1512
1513
158
5.1

Figure 17 specifies the modeling elements and their interrelationships that are
used to express the structure and behavior of objects in the FSV of a Commercial
Transaction and Business Collaboration Protocol model. Each element and
interrelationship permitted in a FSV is defined in the metamodel specified in this
section of the document.
47
159
Functional Service View Metamodel (Collaboration Elements)

<<stereotype>>
ServiceTransaction
baseElement = Class
isAuthenticationRequired : Boolean
timeToPerform : TimeExpression
timeToAcknow ledgeReceipt : TimeExpression
timeToAcknow ledgeAcceptance : TimeExpression
<<stereotype>>
RequestingServi ceTransacti on
<<stereotype>>
Respondi ngServiceTransaction
recurrence : Natural Number

isNonRepudi ationOfRecei ptRequired : Boolean
isIntel ligibl eCheckRequi red : Boolean
<<stereotype>>
NetworkComponent
<<stereotype>>
ServiceCollaboration
baseElement = Class
baseElement = Collaboration
<<stereotype>>
BusinessServ ice
<<stereotype>>
Agent
+forService
return(a : BusinessAction)
transfer(a : BusinessAction)
<<stereotype>>
MessageEnvel ope
baseElement = Cl ass
<<stereotype>>
BusinessActionMessage
callTransaction(a : RequestingServ iceTransaction)

request(a : BusinessAction)
signal(a : BusinessSignal)
response(a : BusinessAction)
return(a : BusinessAction)
checkProcessControls()
checkSecurityControls()
BusinessMessage
<<>baseElement = Class
BusinessSignalMessage
1514
1515
160
Figure 17. FSV Abstract Syntax
48
161
1516
1517
1518
Agent
1519
1520
An agent is a network component that must implement protocols up to the

agent layer of the e-business network application, communications model.
1521
Associations:
1522
1523
forService.
An agent acts on behalf of a service.
Operations:
1524
1525
1526
return(a:BusinessActionMessage). Return a business action message to

this agent. This agent becomes the owner of the business
action. The argument may not be null.
1527
1528
1529
transfer(a: BusinessActionMessage). Transfer a business action message

to this agent. This agent becomes the owner of the
business action. The argument may not be null.
1530
BusinessService
1531
1532
A business service is a network component that responds to business

transaction requests initiated by other services.
1533
Operations:
1534
callTransaction(a: RequestingServiceTransaction).
1535
1536
response(a:BusinessAction). Response to a timed (synchronous)

business action request.
1537
1538
request(a:BusinessAction). Request to perform a business action. This

request can be timed or asynchronous.
1539
1540
signal(a:BusinessAction). Asynchronous signal returned for security,

auditing and execution control.
1541
1542
1543
return(a:BusinessAction). Return a business transaction from an

enterprise component after a business action has been
performed.
1544
1545
checkProcessControls(). Requests the Business Service to validate the

current state of the current business transaction.
1546
1547
checkSecurityControls().Requests the Business Service to validate the

security controls of the current business transaction.
1548
1549
1550
Associations:
transactions. The ServiceTransactions that support this BusinessService.
ServiceTransaction
1551
1552
A ServiceTransaction is a mutually binding interaction between an initiating

service and a responding service.
162
49
163
1553
Tagged Values:
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
isNonRepudiationRequired. If non-repudiation of origin and content is

required then the business activity must store the
business document in its original form for the duration
mutually agreed to in a trading partner agreement. A
responding partner must signal a business control
exception if the sending partner role has not properly
delivered their business document. A requesting partner
must send notification of failed business control if a
responding partner has not properly delivered their
business document.
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
timeToPerform. Both partners agree to perform a commercial transaction

within a specific duration. A responding partner must exit
the transaction if they are not able to respond to a
business document request within the agreed timeout
period. A sending partner must retry a commercial
transaction if necessary or must send notification of failed
business control (possibly revoking a contractual offer) if
a responding partner does not deliver their business
document within the agreed time period. The time to
perform is the duration from the time a business
document request is sent by a requesting partner role
until the time a responding business document is
properly received28 by the requesting partner role. Both
partners agree that the business signal document or
business action document specified as the document to
return within the time to perform is the Acceptance
Document29 in an on-line offer/acceptance contract
formation process.
1593
1594
1595
1596
1597
1598
1599
1600
timeToAcknowlegeReceipt. Both partners agree to mutually verify receipt

of a requesting business document within specific time
duration. A responding partner must exit the transaction if
they are not able to verify the proper receipt of a business
document request within the agree timeout period. A
sending partner must retry a commercial transaction if
necessary or must send notification of failed business
control (possibly revoking a contractual offer) if a
This property provides the following audit controls:

Verify sending role identity (authenticate)26 Verify the
identity of the sending role (employee or organization).
For example, a drivers license or passport document with
a picture is used to verify an individuals identity by
comparing the individual against the picture.
Verify content integrity27 Verify the integrity of the
original content sent from a partner role i.e. check that the
content has not been altered by a 3rd party while the
content was exchanged between partners.
16426 The BCF specifies digital signatures for partner-to-partner non-repudiation of origin and content.
16527 The BCF specifies MD5 or SHA-1 message digest algorithms and asymmetric encryption to provide
166content integrity.
16728 Properly received is legally defined in a trading partner agreement. Refer to the Create Trading
168Partner Agreement commercial transaction specification in the BCF.
170
50
171
responding partner does not verify properly receipt of a
business document request within the agreed time period.
The time to acknowledge receipt is the duration from the
time a business document request is sent by a requesting
partner until the time a verification of receipt is properly
received by the requesting business partner. This
verification of receipt is an audit-able business signal and
is instrumental in contractual obligation transfer during a
contract formation process (e.g. offer/accept).
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
timeToAcknowledgeAcceptance. Both partners agree to the need for a

business acceptance document to be returned by a
responding partner after the requesting business
document passes a set of business rules. The time to
acknowledge business acceptance of a requesting
business document is the duration from the time a
requesting partner sends a business document until the
time an acknowledgement of acceptance is properly
received by the requesting partner. A responding partner
must exit the transaction if they are not able to
acknowledge business acceptance of a business
document request within the agreed timeout period. A
sending partner must retry a commercial transaction if
necessary or must send notification of failed business
control (possibly revoking a contractual offer) if a
responding partner does not acknowledge acceptance of
a business document within the agreed time period.
1627
1628
Associations:
1629
1630
requestingAction. The BusinessActionMessage that initiates this

ServiceTransaction.
1631
1632
1633
1634
respondingAction. The BusinessActionMessage that is the response to

theRequestingAction Not all requesting actions require a
response message. In this case a non-substantive
acknowledgement is sufficient.
1635
1636
receiptAcknowledgement. A BusinessSignalMessage that affirms receipt

of a BusinessActionMessage.
1637
1638
exceptions.
1639
1640
1641
1642
1643
1644
acceptanceAcknowledgement. An acceptanceAcknowledgement is a
BusinessSignalMessage that affirms the acceptance of a
action request. This business signal is an acceptance
from a legal viewpoint. Through this acceptance
mechanism, responsibility for the transaction is
transferred to the responding business service.
BusinessSignalMessages that report control or process

exceptions.
1645
172
51
173
1646
NetworkComponent
1647
1648
A network component is a logical computing component in a distributed

network environment.
1649
Tagged Values:
1650
1651
1652
1653
1654
1655
1656
1657
1658
isSecuredTransportRequired. Both partners must agree to exchange

business information using a secure transport channel.
The security controls ensure that business document
content is protected against unauthorized disclosure or
modification and that business services are protected
against unauthorized access. This value is derived from
the isSecuredTransportRequired property of the
CommercialTransaction in the BOV.
BusinessMessage
1659
1660
A BusinessMessage is a document or information that is exchange

between business processes.
1661
Associations:
1662
1663
1664
header.
Message header that contains security, signature and

dictionary reference information.
MessageEnvelope
1665
A MessageEnvelope is container used to route BusinessActionMessages.
1666
Associations:
1667
1668
header.
Message header that contains security, signature and

1669
1670
body.
One or more business messages that are carried with this

envelope.
1671
prototype.
Identification of the message envelope prototype.
1672
1673
1674
1675
1676
A BusinessActionMessage is a specialized StructuredMessage used to
convey BusinessDocuments (from BOV) between two business processes
via a network component.
1677
1678
A BusinessSignalMessage is used to convey control and exception

conditions between two business processes.
1679
Associations:
1680
1681
1682
174
forAction.
References the BusinessActionMessage that this

BusinessSignalMessage correlates to. Signals are
returned to an initiating service by a responding service.
52
175
1683
RequestingServiceTransaction
1684
1685
A RequestingServiceTransaction is the initial business transaction within a

CommerialTransaction.
1686
Tagged Values:
1687
1688
1689
1690
1691
recurrence. Specifies the number of attempts a

RequestingServiceTransaction may be sent in response
to a control exception. Control exceptions are those which
were generated as a result of a control failure (e.g.
TimeOut, Authentication, ect)
1692
1693
1694
1695
1696
1697
isNonRepudiationOfReceiptRequired. The
isNonRepudiationOfReceiptRequired is derived from the
RequestingBusinessActivity(BOV) and indicates that both
partners agree to mutually verify receipt of a requesting
business document and that the receipt must be nonreputable.
1698
1699
RespondingServiceTransaction
1700
1701
1702
A RespondingServiceTransaction is the responding business transaction

within a CommercialTransaction to a particular
RequestingServiceTransaction.
1703
Tagged Values:
1704
1705
1706
1707
1708
isIntelligibleCheckRequired. Both partners agree that a responding

partner role must check that a requesting document is not
garbled (unreadable, unintelligible) before verification of
properly receipt is returned to the requesting partner.
1709
1710
1711
A ServiceCollaboration comprises a set of interactions (service request)

between network components, which comprises one business
collaboration (from BOV).
1712
Associations:
1713
1714
components.
References the NetworkComponent that participates in

this collaboration.
1715
1716
interactions.
References the BusinessTransactions that are exchanged

between the NetworkComponents.
1717
1718
176
53
177
Business Signals
Busi nessSi gnalMessage

Acknowledgement
AcceptanceAcknowledgement
ReceiptAcknowl edgement
Excepti on
ControlException
BusinessExcepti on
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
1740
1741
1742
1743
178
Figure 18. FSV Abstract Syntax (Business Signals)
Acknowledgement
An acknowledgement is an asynchronous business signal that
acknowledges some aspect of a received business action message
(request). The acknowledgement is sent to the service from which the
business action message was received.
AcceptanceAcknowledgement
An acceptance acknowledgement business signal is returned to the
initiating service if the business action message (request) content is valid
with respect to the responding services business rules and the responding
service is willing to perform further processing activities with this content.
The initiating service must not assume that the responding service will act
on a request that has not been accepted by the responding service. A
trading partner agreement must agree that a receiving service has legally
accepted a business action request (BusinessActionMessage ) when the
BusinessActionMessage has been accpeted by the receiving service. At
this point there is transference of legal responsibility for the fulfillment of
this request by the receiving service. This signal is required if the
correlating ServiceTransaction has the
timeToAcknowledgeAcceptance attribute set to a duration greater than
zero.
BusinessSignal
A business signal is an object that is transmitted asynchronously back to
an activity that initiated the transfer of business process execution control.
54
179
1744
ControlException
1745
1746
1747
1748
1749
1750
1751
1752
1753
1754
A ControlException signals an error condition in the management of a

ServiceTransaction within a ServiceCollaboration. This signal is
asynchronously returned to the initiating service that originated the
request. This exception must terminate the ServiceCollaboration. These
errors deal with the mechanisms of message exchange such as
verification, validation, authentication and authorization and will occur up to
message acceptance. Typically the rules and constraints applied to the
message will have only dealt with structure, syntax and message element
values.
ProcessException
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764
A ProcessException signals an error condition in a business activity. This

signal is asynchronously returned to the initiating service that originated
the request. This exception must terminate the ServiceCollaboration.
These errors deal with the mechanisms that process the
ServiceTransaction and will occur after message verification and
validation. Typically the rules and constraints applied to the message will
deal the semantics of message elements and the validity of the request
itself and the content is not valid with respect to a responding services
business rules. This type of exception is usually generated after an
AcceptanceAcknowledgement has been returned.
1765
1766
ReceiptAcknowledgement
1767
1768
1769
1770
1771
1772
1773
1774
Acknowledges the receipt of a BusinessActionMessage. This business

signal is returned by the responding service to acknowledge the receipt of
a BusinessActionMessage if it is syntactically and structurally valid. A
trading partner agreement must agree that a receiving service has legally
received a business action request (BusinessActionMessage ) when the
BusinessActionMessage can be read by the receiving service. This
signal is required if the correlating has the timeToAcknowledgeReceipt
attribute set to a duration greater than zero.
1775
1776
1777
The following well-formedness rules apply to the FSV metamodel package.
1778
[1]
1779
5.2
Model Semantics
1780
The semantics of each element of the FSV metamodel is defined in this section.
1781
Figure 19 illustrates the interrelationships between the FSV modeling elements.
180
55
181
FSV Semantic Model

<<stereotype>>
com ponents
baseElement = Collaboration
1..n
<<stereotype>>
NetworkComponent
EnterpriseComponent
baseElement = Class
1..n
perform()
perform()
return()
isValid()
isAcceptable()
+actor
1..n
<<stereotype>>
BusinessServ ice
<<stereotype>>
Agent
+forService
return()
transfer()
callTransaction()
request()
signal()
response()
return()
checkProcessControls()
checkSecurityControls()
1
<<stereotype>>
+transacti ons
+requestingAction
1
+respondingActi on
0..1
1..n
+receiptAcknowledgement
<<stereotype>>
ServiceTransaction
baseElement = Class
isAuthenticationRequired : Boolean
timeToPerform : TimeExpression
timeToAcknow ledgeReceipt : TimeExpression
timeToAcknow ledgeAcceptance : TimeExpression
<<stereotype>>
RequestingServiceT ransaction
RequestingState
(from Requester)
1
1..n
recurrence : NaturalNumber
isNonRepudiationOfReceiptRequired : Boolean
+exceptions
0..1
0..n
0..1
+acceptanceAcknowledgement
<<stereotype>>
RespondingServiceT ransaction
isIntelligibleCheckRequired : Boolean
RespondingState
(from Responder)
1..n
1782
1783
1784
1785
1786
1787
1788
1789
1790
Figure 19. FSV Model Semantics
5.2.1Agent
An agent acts on behalf of a service. An agent can be a user agent such as a web
browser but may also be an agent acting on behalf of another service. An agent is
a network component that must implement protocols up to the agent layer of the
e-business network application, communications model. An agent has no network
identity as a business service component. A user agent acts as an intermediary
between a business service and an employee.
5.2.2BusinessService
1791
1792
1793
1794
1795
1796
A business service is a network component that responds to business transaction

requests initiated by other services. A business service implements protocols in all
of the layers of the e-business network application, communication model.
Business services monitor the execution of service collaborations. A service
component has network identity as a business service.
182
56
183
5.2.3ServiceTransaction
1797
1798
1799
1800
1801
1802
1803
1804
1805
A ServiceTransaction is a mutually binding interaction between an initiating

service and a responding service. There may be zero or more business signals
exchanged during the interaction that can be used for security, auditing and
process control. A set of business transactions as defined by a
CommercialTransaction (from BOV) is a unit of work. Both services in the
CommercialTransaction (CT) must agree to the CTs conclusion or both sides
must roll back to a state before the intial RequestingServiceTransaction was
initiated.
1806
1807
1808
A timed ServiceTransaction is a synchronous transaction that must complete

within the specified time. An asynchronous transaction is a one-way exchange of
a business action.
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
5.2.4NetworkComponent
A network component is a logical computing component in a distributed network
environment. Network transport security is specified and enabled by the
networkcompoent.
5.2.5BusinessMessage
A BusinessMessage is an information document that is exchange between
business processes. The message header provides for security, signature and
5.2.6MessageEnvelope
A MessageEnvelope is used to define routing information and privacy properties
for one or more BusinessActionMessage that is contained within the message
envelope. The MessageEnvelope is the highest level of containment for
information that is exchange between two business processes.
5.2.7BusinessActionMessage
A BusinessActionMessage is a specialized StructuredMessage used to convey
BusinessDocuments (from BOV) between two business processes via a network
component.
5.2.8BusinessSignalMessage
A BusinessSignalMessage is a specialized StructuredMessage used to convey
control and exception conditions between two business processes as it relates to
a particular BusinessActionMessage request. A BusinessSignalMessage is
transmitted asynchronously back to an business process that initiated the transfer
of business process execution control.
5.2.9RequestingServiceTransaction
1832
1833
1834
1835
1836
1837
A RequestingServiceTransaction is the initial business transaction within a

CommerialTransaction. When a CommercialTransaction fails, the rollback is to the
state of the system and business process as it was just before the initiation of the
transaction. If the recurrence property is set to a positive value the request is tried
again until the count is decremented to zero. Retrys only occur on the receipt of a
184
57
185
1838
1839
1840
1841
control exception which may an indicator that the failure could have been
technical in nature. If the exception was a process exception then the recurrence
counter is not applicable, since the exception was generated due to the failure of
a business rule and must be redress by higher level processes.
1842
1843
1844
1845
1846
1847
1848
1849
1850
1851
1852
1853
If a isNonRepudiationOfReceiptRequired is true, this indicates that both partners

agree to mutually verify receipt of a requesting business document and that the
receipt must be non-reputable. A receiving partner must send notification of failed
business control (possibly revoking a contractual offer) if a responding partner has
not properly delivered their business document.
1854
1855
1856
1857
1858
1859
1860
1861
1862
1863
1864
1865
1866
1867
1868
Non-repudiation of receipt provides the following audit controls.

Verify responding role identity (authenticate) 30 Verify the identity of the
responding role (individual or organization) that received the requesting business
document.
Verify content integrity31 Verify the integrity of the original content of the
business document request.
5.2.10
RespondingServiceTransaction
A RespondingServiceTransaction is the responding business transaction within a

CommercialTransaction to a particular RequestingServiceTransaction. Typically all
CommercialTransaction are defined in RequestingServiceTransaction/
RespondingServiceTransaction pairs. If the isIntelligibleCheckRequired property
is ture then both partners agree that a responding partner role must check that a
requesting document is not garbled (unreadable, unintelligible) before verification
of properly receipt is returned to the requesting partner. Verification of receipt
must be returned when a document is accessible but it is preferable to also
check for garbled transmissions at the same time in a point-to-point synchronous
business network where partners interact without going through an asynchronous
service provider.
5.2.11
Service Collaboration
A ServiceCollaboration specifies the interactions between network components. It

specifies the conditions and/or constraints by which interactions are executed.
1870Message Model Semantics
1871Figure 21 specifies the semantics for the definition of business messages.
18630 The BCF specifies digital signature for partner-to-partner non-repudiation of origin and content.
18731 The BCF specifies MD5 or SHA-1 message digest algorithms and asymmetric encryption to provide
188content integrity.
189
58
190
1872
<<stereotype>>
MessageEnvel ope
baseElement = Class
+body
+prototype
0..n
Busi nessMessage
0..1
<<>baseElement = Class
0..1
ElementId
baseElement = ModelElement
+prototype
+prototype
StructuredMessage
+header
+header
+body
1..n
1..n
1..n
<<stereotype>>
Entity
baseClass = "Class"
isSecureEntity : Boolean
isSignatureEntity : Boolean
abreviation : String
dicti onaryReference : String
0..1
UnstructuredMessage
body : String
<<stereotype>>
Busi nessSi gnalMessage

forActi on
1873
1874
Figure 20. FSV Message Model Semantics
1875
5.2.12
1876The BusinessActionMessage specifies the business activity that processes a business request
1877and the header and body of the message. The BusinessActionMessage maps to the business
1878document that was defined in the BOV and defines process routing and security constraints
1879
5.2.13
ElementId
1880The ElementId identifies the dictionary prototype template that defines the MessageEvelope,
1881BusinessMessage and the Entities used in the construction of the message.
1882
5.2.14
InformationEntity
1883An Entity is the basic element for specifying information elements. Along with the name and type,
1884it specifies privacy and security for the information.
1885
1886
5.2.15
MessageEnvelope
1887A MessageEnvelope is the highest level container for transporting business documents between
1888business processes via network components.
191
59
192
1889
5.2.16
1890A BusinessActionMessage is a specialization of a StructuredMessage used to invoke a business
1891process in the receiving system.
1892
5.2.17
1893A BusinessSignalMessage is a specialization of a StructuredMessage used to convey control
1894and process exceptions occurring in a business process in the receiving system to a business
1895process in the initiating system.
1896
5.2.18
UnstructuredMessage
1897A UnstructuredMessage is a specialization of a BusinessMessage used to transport arbitrary bit
1898streams such as would be the case for images, video and audio.
1899
5.2.19
StructuredMessage
1900A StructuredMessage is a specialization of a BusinessMessage used to transport structured
1901information.
1902
1903
1904
1905
1906
5.3
Model Management Abstract Syntax & Semantics
The following stereotypes and tagged values are contained in the functional
service view management metamodel. Figure 20 illustrates the interrelationships
between the FSV model management and model elements.
1907
193
60
194
Functional Service View Model Management
<<stereotype>>
Functi onalServiceView
baseElement = Model
1..n
<<stereotype>>
+theTransactionDialogs
components
+executionProcessParti cipants
1..n
interactions
1..n
<<stereotype>>
NetworkComponent
executionProcessInteraction
1..n
business Actions
1..n
<<stereotype>>
Busi nessTransaction
+requestingAction
0..1
+respondingAction
1
<<stereotype>>
1..n
1908
1909
Figure 21. BOV Model Management Illustration
1910
195
61
196
1911
6.
Business Dictionary Metamodel
1912
6.1
1913
6.2
Model Semantic
1914
6.3
Model Management
1915
6.4
Model Management Semantic
197
62
198
1916
6.5
Model Notation
1917This section defines the notation used to specify business process models and the diagrams
1918used to view the model. The model is viewed through a number of static and dynamic diagrams
1919that are constrained versions of those provided by the UML.
1920
6.6
Stereotype Notation
1921
1922
1923
Model elements are indicated with stereotype keywords in guillemets (stereotype

name). A stereotype keyword name in a model must be syntactically equivalent to the
class name of the respective stereotype class in the metamodel.
1924
1925
The following are special stereotyped icons for extension elements. These icons are
taken from the UML Extension for Business Modeling, version 1.1, 1 September 199732.
Icon
Stereotype
PartnerType
1926
1927
1928
1929
6.7
Model Diagrams
The following model diagrams are used to view business process models.
6.7.1Business Operations Map Diagrams

6.7.1.1
Process Area Diagram
1930
1931
1932
A process area diagram is a constrained form of a UML Use Case

diagram. Figure 14 is an example of a process area diagram.
1933
1934
1935
1936
1937
1938
1939
1940
A process area diagram illustrates a sequence of business processes

modeled as Use Cases. Business processes are sequenced from left-toright or from right-to-left of the diagram (a convention taken from the
Supply Chain Operations Reference Model33). The flow convention is
useful to communicate a flow of products down the Supply Chain and a
flow of product demand up the Supply Chain. The flow of products is from
left-to-right of the diagram and the flow of product demand is from right-toleft of the diagram.
19932 Can be found at http://www.rational.com and http://www.omg.org.

20033 Refer to http://www.supply-chain.org
201
63
202
<<Transition>>
1941
1942
1943
1944
1945
1946
1947
1948
1949
<<Transition>>
<<BusinessProcess>>
<<BusinessProcess>>
<<BusinessProcess>>
Reserve Inventory and

Determine Delivery Date
Receive Enter and

Validate Order
Process Inquiry and Quote
Figure 22. Example Process Area Diagram

Business information in a business process Use Case preconditions and
post-conditions can be listed above and below each Use Case icon
respectively. This will provide a diagram similar to those in the Supply
Chain Operations Reference Model.
6.7.1.2
Business Process Activity Diagram
A business process activity diagram is a constrained form of a UML activity

diagram. Figure 15 is an example of a business process activity diagram.
Start
<<BusinessInterf aceTask>>
Create Sal es Order
<<BusinessInterf aceTask>>
Delete Sal es Order
End
1950
1951
1952
1953
1954
203
Figure 23. Example Business Process Activity Diagram

A business process activity diagram illustrates a sequence of business
tasks and business interface tasks. Business tasks are UML activities
interpreted as business tasks.
64
204
1955
1956
1957
1958
6.7.2Business Requirements View Diagrams

6.7.2.1
Business Use Case Diagram
A business Use Case diagram is a constrained form of a UML Use Case

diagram. Figure 16 is an example of a business Use Case diagram.
+buyer
<<Communicate>>
+sell er
Manuf acturer
Distributer
<<Communicate>>
<<communicate>>
+seller
<<Communicate>>
<<Communicate>>
+buyer
<<BusinessInterf aceProcessUseCase>>
Create Purchase Order Process
+sell er
+buyer
<<Communicate>>
Retailer
End User
1959
1960
1961
1962
1963
1964
1965
1966
1967
1968
205
Figure 24. Example Business Use Case Diagram

A business use case diagram illustrates the partner types that
collaboratively execute a business collaboration protocol or commercial
transaction. The diagram also illustrates each partner types role in the Use
Case.
6.7.2.2
Business Collaboration Diagram
A business collaboration diagram is a constrained form of a UML Use

Case diagram. Figure 14 is an example of a business collaboration
diagram.
65
206
+seller
<<Communicate>>
End User/Manuf acturer Create Purchase
Order
Manuf acturer
<<Communicate>>
+buyer
<<Communicate>>
+sell er
+buyer
<<Communicate>>
End User
End User/ Distributor Create Purchase Order
+buyer
Distributer
<<Communicate>>
<<Communicate>>
+sell er
End User/ Retailer Create Purchase Order
Retailer
1969
1970
1971
1972
1973
1974
1975
1976
1977
Figure 25. Example Business Collaboration Diagram

A business collaboration diagram illustrates a particular configuration of
business partner collaboration to document an business information
requirements that are not applicable to the general business Use Case
from which the collaboration is realized. For example, sending a business
document to a US Government agency requires a Standard Industry
Classification (SIC) code to be included with the business information.
6.7.3Business Operational View Diagrams

6.7.3.1
Commercial Transaction
1978
1979
1980
1981
1982
1983
A commercial transaction is an activity graph. Figure 19 is an example of a

commercial transaction diagram. Note that the object flow is modeled as
state transitions in this diagram due to a limitation of Rational Rose, a UML
modeling tool used to create the models. This state notation should be
replaced with the object flow notation as soon as possible.
207
66
208
: Buyer
: Seller
START
<<BusinessT ransacti onActivi ty>>

Create Purchase Order
Purchase Order
Acceptance
[ FAIL ]
FAILED
[ SUCCESS ]
<<Authori zedActivity>>
Process Purchase Order
Request
END
Purchase Order
Request
1984
1985
1986
1987
1988
1989
1990
1991
209
Figure 26. Example Commercial Transaction Diagram

6.7.3.2
Diagram
Business collaboration protocol
Figure 20 is an example of a commercial transaction diagram. A business

collaboration protocol is an activity graph. There are no conditionals or
synchronization states in the model. Those states do not apply to an
interface process but rather to an internal enterprise decision process.
67
210
: Buyer
: Seller
[ COMPLET E ]
START
<<CommercialTransactionActiv ity >>
[ INCOMPLET E ]
Create Purchase Order
<<CommercialTransactionActiv ity >>
Notify of Purchase Order

Acceptance
[ FAIL ]
[ FAIL ]
[ SUCCESS ]
FAILED
[ SUCCESS ]
FAILED
END
END
1992
1993
Figure 27. Example Business Collaboration Protocol Diagram
6.7.4Functional Service View Diagrams
1994
<<Functional>>
Field Labor Scheduler
(from Negotiate Reservation (BOV))
mapsToRole
<<Business Service>>
FieldLaborSchedulerService
mapsToRole
<<Functional>>
WorkOrder Coordinator
mapsToRole
<<Agent>>
FieldLaborSchedulerAgent
WorkOrderCoordinaterService
mapsToRole
<<Agent>>
WorkOrderCoordinaterAgent
<<Functional>>
Customer
mapsToRole
CustomerService
mapsToRole
<<Agent>>
CustomerAgent
1995
211
68
212
<<BusinessAction>>
AvailableTimeSlotsQueryAction
(from Availible TimeSlots Query )
mapsToDocument
<<BusinessDocument>>
AvailableTimeSlotsQuery
<<BusinessAction>>
AvailableTimeSlotsResponseAction
mapsToDocument
AvailableTimeSlotsResponse
<<BusinessAction>>
TimeSlotReservationRequestAction
(from Request TimeSlot Reservation)
mapsToDocument
TimeSlotReservationRequest
<<BusinessAction>>
TimeSlotReservationConfirmationAction
<<BusinessAction>>
TimeSlotOfferAction
(from Offer Available TimeSlots)
<<BusinessAction>>
TimeSlotOfferResponseAction
(from Offer Available TimeSlots)
mapsToDocument
mapsToDocument
mapsToDocument
TimeSlotReservationConfirmation
<<DocumentEnvelope>>
TimeSlotOfferEnvelope
<<DocumentEnvelope>>
TimeSlotOfferResponseEnvelope
1996
213
69
214
5. TimeSlotReservationRequest
1. Availible TimeSlot Query
: WorkOrder
Coordinator
: Field Labor
Scheduler
2. Availible TimeSlots Response
6. TimeSlotReservationResponse
3. TimeSlotOffer
4. TimeSlotResponse
: Customer
1997
: CustomerService
: CustomerAgent
: FieldLaborSchedulerAgent
: Fiel dLaborSchedulerService
1. callTnx()
1.1. return(doc : T imeSlotReservationRequestAction)
1.1.1. transfer(doc : TimeSlotReservationRequestAction)

1.1.1.1. request(doc : TimeSlotReservationRequestAction)
1.1.1.1.1. signal( : ReceiptAcknowledgement)
2. response( : TimeSlotReservati onConfirmati onAction)

2.1. signal( : ReceiptAcknowledgement)
3. queryTnx()
3.1. return(doc : T imeSlotReservationConfirmationAction)
1998
215
70
216
TimeSlotReservationConfirmation
acceptance
boolean
confirmationIdentification
{TimeSlotReservationConfirmation.acceptance = TRUE}
<<FundamentalBusinessDataEntity>>
M
FreeFormText
confirmedReservation
0..1
{TimeSlotReservationConfirmation.acceptance = TRUE}
<<BusinessDataEntity>>
TimeSlotReservation
0..1
1999
217
71
218
2000Bibliography
2001 The Next Generation of UN/EDIFACT, Reference Guide from the Techniques and
2002Methodologies Working Group (TMWG), Revision 12, 1998.
2003UML Semantics, Object Management Group, http://www.omg.org, Version 1.1., 1997.
2004The Object Constraint Language: Precise Modeling With Uml (Addison-Wesley Object
2005Technology Series) by Jos B. Warmer , Anneke G. Kleppe Addison-Wesley Pub Co (March
20061999); ISBN: 0201379406
2007The Unified Modeling Language Reference Manual (Addison-Wesley Object Technology Series)
2008by James Rumbaugh, Ivar Jacobson, Grady Booch Addison-Wesley Pub Co (December 1998);
2009ISBN: 020130998X
2010The Unified Modeling Language User Guide (The Addison-Wesley Object Technology Series) by
2011Grady Booch, Ivar Jacobson, James Rumbaugh Addison-Wesley Pub Co (October 1998); ISBN:
20120201571684
2013
2014
219
72

Ebx ML Collaboration Modeling Met A Model

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Ebx ML Collaboration Modeling Met A Model

Uploaded by

Copyright:

Available Formats

Draft Version 0.

Collaboration Modeling Metamodel

2.1 Model Abstract Syntax....................................................................3

2.1.1 Stereotypes and Tagged Values..............................................3

2.1.2 Well-formedness Rules...........................................................5

2.2 Model Semantics.............................................................................6

2.3 Model Management Abstract Syntax..............................................6

2.3.1 Stereotypes and Tagged Values..............................................6

2.3.2 Well-formedness Rules...........................................................7

2.4 Model Management Semantics.......................................................8

213. The Business Requirements View Metamodel........................9

3.1 Model Abstract Syntax....................................................................9

3.1.1 Stereotypes and Tagged Values..............................................9

3.1.2 Well-formedness Rules.........................................................17

3.2 Model Semantics...........................................................................18

3.3 Model Management Abstract Syntax............................................19

3.3.1 Stereotypes and Tagged Values............................................19

3.3.2 Well-formedness Rules.........................................................20

3.4 Model Management Semantics.....................................................20

4.1 Model Abstract Syntax..................................................................22

4.1.1 Stereotypes and Tagged Values............................................22

4.1.2 Well-formedness Rules.........................................................30

4.2 Model Semantics...........................................................................32

4.2.1 Business Activities................................................................33

4.2.2 Requesting Business Activity................................................41

4.2.3 Object Flow...........................................................................41

4.2.4 Business Collaboration Protocol............................................41

4.2.5 BOV-to-BRV Mapping............................................................41

4.3 Model Management Abstract Syntax............................................42

4.3.1 Stereotypes and Tagged Values............................................42

4.3.2 Well-formedness Rules.........................................................43

4.4 Model Management Semantics.....................................................43

445. The Functional Service View Metamodel..............................45

5.1 Model Abstract Syntax..................................................................45

5.1.1 Stereotypes and Tagged Values............................................45

5.1.2 Well-formedness Rules.........................................................53

5.2 Model Semantics...........................................................................53

5.3 Model Management Abstract Syntax & Semantics......................58

696. Model Notation..................................................................61

6.1 Stereotype Notation......................................................................61

6.2 Model Diagrams............................................................................61

6.2.1 Business Operations Map Diagrams.....................................61

6.2.2 Business Requirements View Diagrams................................63

6.2.3 Business Operational View Diagrams...................................64

6.2.4 Functional Service View Diagrams........................................66

6.2.5 Implementation Framework View DiagramsError! Bookmark

BOM Abstract Syntax.....................................................................3

BOM Model Management Abstract Syntax.....................................7

BOM Model Management Illustration.............................................8

BRV Abstract Syntax......................................................................9

BRV Model Management Abstract Syntax....................................20

BRV Model Management Illustration............................................21

BOV Abstract Syntax....................................................................23

89Figure 10. BOV Illustration............................................................................33

103Document Revision History

First draft translation of BCF 2.0 version 2.0

The Business Operations Map (BOM) metamodel the partitioning of business

The Business Requirements View (BRV) metamodel the view of a business

The UML provides an extension mechanism so that domain specific, object-oriented

166Purpose of the Document

Business process modeling techniques and principles

The OCL syntax and semantics

184Scope of the Document