See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/259031977

A Pattern-Based and Model-Driven Approach for Deriving IT System Functional

Models from Annotated Business Models

Conference Paper · September 2013

DOI: 10.1007/978-3-319-07215-9_26

CITATIONS READS

7 17,312

4 authors:

Javier Berrocal Jose Garcia-Alonso

Universidad de Extremadura Universidad de Extremadura
123 PUBLICATIONS   748 CITATIONS    132 PUBLICATIONS   597 CITATIONS   

SEE PROFILE SEE PROFILE

Cristina Vicente-Chicote Juan Manuel Murillo

Universidad de Extremadura Universidad de Extremadura
108 PUBLICATIONS   696 CITATIONS    243 PUBLICATIONS   1,247 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Situational Context View project

1st IEEE/IFIP International Workshop on Intelligence Provisioning for Network and Service Management in Softwarized Networks (IPSN), co-located with NOMS 2022
(Budapest) View project

All content following this page was uploaded by Javier Berrocal on 22 April 2014.

The user has requested enhancement of the downloaded file.

A Pattern-Based and Model-Driven Approach
for Deriving IT System Functional Models from
Annotated Business Models∗

Javier Berrocal, José Garcı́a-Alonso, C. Vicente-Chicote and Juan Manuel Murillo

Abstract Companies increasingly demand IT systems to support (part of) their busi-
ness. In order to maximize return on investment, these systems need to be perfectly
aligned both with the business and with the legacy applications with which they will
be integrated. In this vein, this paper presents a pattern-based and model-driven ap-
proach for deriving IT system functional models from annotated business models.
First, we explain how to annotate the BPMN 2 business models with information
useful for deriving the functionalities. Then, we introduce a set of patterns aimed to
help identifying the functionalities and the relationships existing among them from
the annotated business models. Finally, we present an ATL model transformation
that, based on the previous patterns, allows us to obtain UML2 Use Case Diagrams.

1 Introduction

In the development of a software system, the business has to be deeply analysed in

order to understand the organization’s goals, its tasks and strategies, and the context
with which the system has to interact [7]. Thus, the software engineer can clearly
identify the system requirements aligned with the business [14].
Currently, there are proposals, such as BPCM [12] or BMM [5], offering some
guidelines for documenting this knowledge, so that it can be later analysed to define
the system requirements aligned with it. In order to facilitate this analysis, some
approaches, such as those proposed by Siqueira [16] and Vara [21], offer differ-
ent mechanisms for deriving the functional requirements from the business spec-
ification. These requirements capture the intended behaviour of the system [22].
∗ Additional material related to this paper can be found in the following website:

http://bpmn2uc.zentipede.org

Javier Berrocal, José Garcı́a-Alonso, C. Vicente-Chicote, Juan Manuel Murillo

University of Extremadura, Avda. de la Universidad s/n, 10003, e-mail: {jberolm, jgaralo, cristinav,
juanmamu}@unex.es

1
However, these approaches do not cover the derivation of the relationships between
functionalities or between them and other business elements (e.g., legacy systems).
Requirements relationships concern actions performed on one requirement that may
affect or interact with other elements [9]. Identifying these relationships in the early
stages of the development is crucial to achieve the business-IT alignment. Other-
wise, the system might need to be re-implemented or even re-designed [9], usually
meaning higher costs and project delays.
There are some approaches dealing with the identification of relationships be-
tween functional requirements. In particular, [10] and [18], like the present work,
are focused on the analysis of business processes. While the aforementioned ap-
proaches adequately meet a range of possible relationships, they do not address
some situations (e.g., Use Cases covering exception flows) and relationships (e.g.,
include relationships) that need to be covered to achieve a complete alignment.
The work presented in this paper tries to overcome some of these limitations by
(1) providing an algorithm for annotating BPMN 2.0 [6] business models with in-
formation relevant for extracting IT system functionalities from them; (2) defining
a comprehensive set of patterns for deriving the relationships existing among them
from the annotated business models; and (3) a set of model transformations imple-
mented in ATL [2] that, relying on the power of Model-Driven Engineering (MDE)
techniques [17], and based on the previous patterns, allow us to obtain UML2 Use
Case Diagrams. The proposed approach aims to improve the business-IT alignment
reducing the risk of system integration problems from the earliest stages. This work
is part of a more extensive work that advocates for making the relationships between
business elements and requirements explicit, so that they can be reused during the
overall system design process [4].
The rest of the paper is organized as follows. Section 2 motivates the research
and presents the case study used to illustrate the proposal. Section 3 outlines the
overall research line in which this work is framed. Section 4 proposes a method for
annotating business processes. Section 5 presents the patterns and the ATL trans-
formations defined for identifying the requirements relationships. Section 6 reviews
some related works and Section 7 draws the conclusions and future works.

2 Motivation

Business Driven Development is a discipline aimed at developing IT systems

aligned with the business [3]. Approaches, such as [12] and [5], support this disci-
pline by specifying how to document the business information. Business processes
specified at a business analysis level with these approaches can be used for spec-
ifying the functional requirements required to support them [19]. Figure 1 shows
a process, modeled with BPMN, for handling the orders of an online-shop. A de-
scription of this notation can be found in [1]. This figure only shows the part of the
process relevant to the present study. This model gathers information related to the
task sequencing, the roles responsibilities, and the input and output data.
Fig. 1 Business process for handling the orders of an online-shop.

Some approaches define methods that facilitate the derivation of Use Cases [10]
or Tasks Descriptions [21] from business processes. For example, in [21], the au-
thors define a new BPMN flow connector to specify which tasks are executed con-
secutively. All consecutive tasks are then mapped to a Task Description. For the
online-shop example, the engineer could use this connector to map all the consecu-
tive flow nodes concerning the placing of an order to a Task Description, and all the
consecutive flow nodes concerning its validation to another one.
For improving business-IT alignment, it is not enough to extract functional re-
quirements from business models; it is also essential to explicitly identify the rela-
tionships among them. For instance, in the online-shop example, let us associate a
Use Case to each of the two Task Descriptions previously described (order place-
ment and order validation, respectively). As shown in Figure 1, if any order is modi-
fied before being validated, it is made again. In order to document this interaction, a
relationship between the two Use Cases needs to be defined. If it is missed, a source
of misalignment will be introduced that will need to be corrected in a later stage.
Currently, some works define patterns for deriving the relationships between Use
Cases from process models. In [10] and [18] two patterns are defined. Although
these patterns are really useful, some relations are beyond their control (e.g., the re-
lations between Use Cases identified in exception or in parallel flows). For example,
in the online-shop example, two flows are merged into one by a parallel gateway. If
these flows are supported by different Use Cases, there should be an include rela-
tionship between them. This relation cannot be identified by the previous patterns.
In order to overcome this limitation, we have identified additional patterns ad-
dressing different situations for which relationships can be derived from the business
models. Furthermore, some of these new patterns also take into account the relations
between requirements and other business elements, such as legacy systems. These
relations can help avoiding system integration problems in later development stages.
3 Annotating the Business Processes for Deriving the System
Functionalities and Design

The research presented in this paper is part of a more extensive work aimed to make
the relationships between business elements and between requirements explicit, so
that they can be reused during the system design. A complete specification of the
work can be found in [4]. This work proposes new activities focused on the specifi-
cation and analysis of these relations. These activities are the following:
• Model the context information. The business processes are annotated with in-
formation, firstly, on the relationships between process tasks and business goals
or legacy systems and, secondly, on the system functionalities that are going to
support the business tasks. A set of annotations has been defined to model this
information. These annotations are added to the model by the engineer.
• Define the requirements relationships. The relationships between the system re-
quirements are specified. To identify these relationships from the previously an-
notated business processes, a set of patterns and ATL model transformations have
been defined. In addition, these transformations automatically derive the system
functional models.
• Analyse the requirements relationships. The requirements and their relationships
are analysed with the aim of delimiting the architectural patterns that facilitate
their fulfilment. We have defined model transformations to facilitate this task.
This paper focuses on part of the first and second activities. Specifically, for the
first activity, it indicates how the business tasks are annotated with the functional
requirements and the legacy systems that support them. For the second one, it details
how to automatically derive the system functionalities and their relationships.

4 Annotating the Business Processes

This section describes the methodology guiding the business expert and the require-
ments engineer in the annotation of the business processes (activity 1 in Section 3).
These annotations document the legacy systems and the Use Cases that are going to
support each business task.
Once the processes have been modeled, using some of the techniques previously
indicated, first, the engineers should indicate what business tasks are already sup-
ported by legacy systems. In order to model this information the Group artifact is
used. This artifact groups flow elements by a specific criterion. This criterion is
specified by the CategoryValue attribute. Each Legacy System (LS) is modeled in
the business process using a group with Category “LS” and Value “the LS’s name”.
Figure 2 shows the online-shop example process annotated with the legacy sys-
tem “LS:Stock Control”. This legacy system supports the “Restore Stocks” sub-
process and the “Reject Order” task. Thus, the points in which the new system has
to interact with this legacy system are also apparent in Figure 2.
Fig. 2 The online shop example process annotated with the BUCs.

Subsequently, the support the new system is going to provide to each business
task has to be defined. To do so, the engineers and the business experts have to
discuss what tasks are going to be automated, which are going to be performed with
the support of the system, and which are going to be done manually. To model this
information, a task is annotated as Service Task if it is going to be automated, User
Task if it is going to be supported, or Manual Task if it is going to be done manually.
Figure 2 shows the online-shop example process annotated with the kind of sup-
port that the system has to provide to each task. For example, the tasks “Make Order”
and “Validate Order” have been defined as supported tasks.
The next step is the identification of the system functionalities required to support
the process. For that purpose an algorithm is proposed. The algorithm ensures that
Business Use Cases (BUC)2 are identified at a proper granularity. It is based on
the Cockburn’s “Coffee-break” rule [8] and on the “Step” concept [10]. Both rules
indicate that a Use Case is a set of tasks that an actor can do without interruption.
The following pseudo-code presents the proposed algorithm. As we did before
with the legacy systems, we use the Group artifact to model each identified BUC.
The Category of all these groups is “BUC” and their Value is “the BUC‘s name”.
Algorithm for the identification of Business Use Cases
1. Begin with the first element of the business process.
2. All consecutive flow elements are part of the same BUC.

2 The term “Business Use Case” is used here to group business tasks, even though it is similar to
the term System Use Case [8].
 3. A BUC ends when:
A. The control flow passes from one Lane to another.
B. There is a time transition between tasks. This is:
I. There is a task marked as manual.
II. There is an intermediary event or a sub-process.
III. There is a communication with an external agent.
This indicates the start (input of data) or end
(output of data) of the BUC.
IV. There is a task performed by a legacy system.
C. The end of the process is reached

Figure 2 also shows the BUCs identified for the online-shop process. For in-
stance, the “BUC: Check Order” groups the elements for checking the order until
the result is sent to the customer. Modeling these elements in the BPMN diagrams
provides the engineer with a first approximation to the system functionalities, and
facilitates their discussion with the business experts.
The annotation of the business process is a guided set of activities in which the
business expert and the requirements engineer have to analise them in order to anno-
tate the business tasks. Nevertheless, the identification of the business tasks already
supported by legacy systems can be semi-automated [15]. Also, the algorithm for
the identification of BUCs can be implemented in order to provide a possible set of
functionalities supporting the process tasks.

5 Deriving the Functional Requirements and their Relationships

This section details how the new IT system functional requirements (defined using
a Use Case Diagram) and the relationships among them are automatically derived
from the annotated business processes by means of an ATL model transformation.

5.1 Deriving the Use Cases

Once the BUCs have been modeled, it is possible to derive a Use Case Diagram
from the annotated processes. First, the actors are extracted. These are the roles
responsible for each business task (modeled in BPMN with Pools or Lanes), and
the legacy systems with which the new IT system has to interact (modeled with the
Group artifact and the LS category). Then, each BUC is mapped to a Use Case.
rule lane2Actor{
from lane : inMM!Lane
to actor: outMM!Actor ( name <- lane.name,
generalization <- generalization),
generalization : outMM!Generalization(
general <- lane.getParent())
}
 An excerpt of the ATL transformation implemented to derive Use Case Diagrams
from the annotated business models is shown above. This excerpt presents a trans-
formation mapping each lane to an actor. In addition, it creates a generalization
relationship between the created actor and the actor extracted from the pool or the
lane containing the processed lane. For the online-shop, an actor depicting the Store
lane and a generalization between this actor and the Web-Shop actor are created.
Figure 3 shows the Use Case Diagram generated after applying the ATL trans-
formation to the process illustrated in Figure 2. The resulting diagram has been
arranged with UML2Tools [11]. As shown in Figure 3, all the pools, lanes and LSs
have been transformed into actors, and all the BUCs have been transformed into Use
Cases. Besides, the transformation also creates the relationships between actors and
between Use Cases and actors.

Fig. 3 Use Case Diagram

extracted from the annotated
online-shop example process.

5.2 Deriving the Relationships between Use Cases

Once the Use Cases have been extracted from the business processes, the relation-
ships between them need to be identified. For this purpose, a set of process patterns
has been defined identifying the most common situations for which Use Case rela-
tionships need to be modeled. Table 1 contains the patterns relevant to the online-
shop case study, and the Appendix gathers the most important ones identified as
part of this work. These patterns can identify relationships between Use Cases and
actors, between Use Cases and legacy systems, and include or extend relationships.
To facilitate their comprehension, a description, the source BPMN pattern, and the
derived use case fragment are detailed for each pattern.
Figure 3 shows the two relationships identified by applying the defined patterns
to the annotated online-shop example process, depicted in Figure 2.
The first one is an extend relationship between the “Make Order” and the “Vali-
date Order” Use Cases. This relationship is identified by the first pattern defined in
Table 1, since the “Validate Order” BUC contains an exclusive gateway from which
an alternative branch (grouped by the “Make Order” BUC) starts. The “Alterna-
tiveExclusiveGateway” ATL rule, defined below, implements this pattern. This rule,
Table 1 Patterns for identifying requirements relationships.
Description Source Pattern Use Case Fragment
If there is a BUC grouping some tasks, an exclusive or
inclusive gateway, and the gateway’s default flow, and
there is another business use case grouping the tasks de-
fined in an alternative branch, then an extend relation-
ship exists between the two use case, since the BUC in
the alternative branch extends the normal flow to follow
when the gateway is reached.
When two or more control flows are merged into one
by a parallel gateway and there is a BUC covering a
branch and, at least, the parallel gateway, then there
is an include relationship between the BUCs covering
each branch and the BUC containing the gateway; since
in order to continue the execution of the BUC contain-
ing the gateway, the other branches have to finalize.

first, identifies the source pattern in the business process. For each detected pattern,
the extending and extended uses cases are identified. Then, an “extension point” is
created in the extended Use Case. The extend relationship is created only if there is
not another extend relationship already defined between the two use cases. Other-
wise, the “extension point” is directly linked to the existing extend relationship. In
the online-shop example process, this pattern is identified twice, because two dif-
ferent exclusive gateways are covered by the “BUC:Validate Order”. The first time
it is identified, an “extension point” and an extend relationship are created to reflect
that, during the validation of an order, if a modification is required, a new order has
to be placed. The second time, only the “extension point” is created (the extend is
not duplicated) to reflect that if the order is not validated a new one can be placed.
rule AlternativeExclusiveGateway {
from seq : inMM!SequenceFlow ( seq.connectBUCs() and
if seq.sourceRef.oclIsTypeOf(inMM!ExclusiveGateway) then
if seq.sourceRef.default<>OclUndefined then
seq.sourceRef.default <> seq
else false endif
else false endif)
to ePoint : outMM!ExtensionPoint (
name <- seq.sourceRef.name+’_’+seq.name,
useCase<-thisModule.resolveTemp(seq.sourceRef.getBUC(),’uc’))
do {
if (not seq.alreadyExtended (seq.targetRef, seq.sourceRef)){
thisModule.createExtendRelationship(seq);
} else { seq.getExtend(seq.targetRef, seq.sourceRef).
extensionLocation <- seq.getExtend(seq.targetRef,
seq.sourceRef).extensionLocation.append(ePoint);}
}
}
 The second relationship, identified by the second pattern defined in Table 1, is an
include between the “Check Order” and “Additional Products” Use Cases. This pat-
tern is applied because the “Check Order” BUC contains a merger parallel gateway
and the “Additional Products” BUC covers the branch that has to be waited. The
ATL rule “MergerParallelBranch”, implementing this pattern, is presented below.
rule MergerParallelBranch {
from seq : inMM!SequenceFlow (seq.connectBUCs() and
if seq.targetRef.oclIsTypeOf(inMM!ParallelGateway) then
seq.targetRef.gatewayDirection.toString()=’Converging’
else false endif)
do{
if (not seq.alreadyIncluded(seq.targetRef, seq.sourceRef)){
thisModule.createIncludeRelationship(seq);}
}
}

The correct identification of these relationships is crucial. Their underspecifica-

tion, first, hinders the system design process and, second, increases the risk of poor
integration. In the example presented above, if the relationships between the “Make
Order” and “Validate Order” Use Cases were not explicitly defined then the archi-
tect would need to make an in-depth analysis of the business processes and the Use
Cases in order to identify them. If even so the relationships remain undefined, then
a business-IT misalignment will occur.

6 Related Work

Different works, such as [12] or [20], have proposed methodologies for modeling
the knowledge of an organization and the requirements of the systems aligned with
it. The specification of these requirements demands full attention during the in-depth
analysis of the business models. Other works, e.g. [10], [18], [21] and [16], focus
on how to re-use these models to facilitate the requirements specification.
In [10], the authors start from processes modeled with activity diagrams. From
these models they define mappings to identify the actors and the Use Cases, and a
situation that leads to define extend relationships. Our proposal increases this one by
defining a greater set of patterns, enabling the identification of other relationships
(e.g., include) and situations (e.g., exception flows).
In [18], the authors extract certain parts of a Use Case, identified in a process,
to another Use Case. Then, they present two patterns to identify the relationships
between the extracted and the initial Use Cases. Our proposal increases this one by
allowing the identification of relationships between consecutive Use Cases.
In [21], the authors define how to identify Task Descriptions in BPMN models.
In order to specify them with a proper granularity, they group the flow elements
that are performed consecutively. The identification of such elements is manually
done by the engineers. This may lead to the identification of different granularity
functionalities, depending on their experience. In this paper we have presented an
algorithm aimed to help the engineers identify functional requirements of a uniform
granularity.
Finally, [16] defines QVT transformations for deriving Use Case scenarios from
BPMN diagrams. In this approach, each process is mapped to a Use Case. Con-
versely, our methodology enables the creation of one or more Use Cases (and the
relationships between them) from each process, depending on their complexity.

7 Conclusions and Future Works

This paper presents a pattern-based and model-driven approach enabling software

engineers to obtain the system functional models (defined as UML2 Use Case Dia-
grams) from annotated business models (defined in BPMN 2.0). The resulting mod-
els contain not only the functionalities but also the relationships existing among
them. Making these relationships explicit improves the business-IT alignment and
avoids potential integration problems.
Currently, we are working on a semi-automated (supervised) implementation of
the algorithm for identifying BUCs (see Section 4). This implementation will offer
the engineer a possible configuration of BUCs supporting the process tasks. Besides,
we are working on the validation of the presented approach. To this end, it is being
used in the development of an IT system which will support the Indra‘s business
processes for quality assurance [13].

Acknowledgements This research was supported by the Spanish Ministry of Science and Inno-
vation under Project TIN2012-34945, and from the Department of Employment, Enterprise, and
Innovation of the Government of Extremadura as part of Project GR10129.

References

1. Allweyer, T.: BPMN 2.0: Introduction to the Standard for Business Process Modeling. Books
on Demand GmbH (2010)
2. ATLAS team: ATLAS Transformation Language (ATL). URL http://www.eclipse.org/atl/
3. Baltzan, P., Phillips, A.: Business Driven Information Systems, 2nd edn. McGraw-Hill (2008)
4. Berrocal, J., Garcı́a-Alonso, J., Murillo, J.M.: Modeling business and requirements relation-
ships for architectural pattern selection. In: J. Kacprzyk (ed.) Software Engineering Re-
search,Management and Applications 2013, Springer SCI. Springer (2013)
5. BMM: Business Motivation Model. URL http://www.omg.org/spec/BMM/
6. BPMN: Business Process Modeling Notation 2.0. URL http://www.bpmn.org/
7. Cardoso, E., Almeida, J., Guizzardi, G.: Requirements engineering based on business process
models: A case study. In: Enterprise Distributed Object Computing Conference Workshops,
2009. EDOCW 2009. 13th, pp. 320–327 (2009)
8. Cockburn, A.: Writing Effective Use Cases, 1st edn. Addison-Wesley Longman Publishing
Co., Inc., Boston, MA, USA (2000)
9. Dahlstedt, A.G., Persson, A.: Requirements interdependencies - moulding the state of research
into a research agenda. In: Ninth International Workshop on Requirements Engineering: Foun-
dation for Software Quality (REFSQ 2003), pp. 71–80 (2003)
10. Dijkman, R.M., Joosten, S.M.M.: Deriving use case diagrams from business process models.
Tech. Rep. TR-CTIT-02-08, University of Twente (2002)
11. Eclipse Plugin: UML2Tools. URL http://www.eclipse.org/modeling/mdt/?project=uml2tools
12. Gao, S., Krogstie, J.: A combined framework for development of business process support sys-
tems. In: A. Persson, J. Stirna, W. Aalst, J. Mylopoulos, M. Rosemann, M.J. Shaw, C. Szyper-
ski (eds.) The Practice of Enterprise Modeling, vol. 39, pp. 115–129. Springer (2009)
13. Indra Company: http://www.indracompany.com/
14. Kotonya, G., Sommerville, I.: Requirements engineering: processes and techniques. World-
wide series in computer science. J. Wiley (1998)
15. Perez-Castillo, R.: Marble: Modernization approach for recovering business processes from
legacy information systems. In: Software Maintenance (ICSM), 2012 28th IEEE International
Conference on, pp. 671–676 (2012)
16. Siqueira, F., Silva, P.: Transforming an enterprise model into a use case model using existing
heuristics. In: Model-Driven Requirements Engineering Workshop, pp. 21 –30 (2011)
17. Stahl, T., Voelter, M., Czarnecki, K.: Model-Driven Software Development: Technology, En-
gineering, Management. John Wiley & Sons (2006)
18. Stolfa, S., Vondrak, I.: Mapping from business processes to requirements specification. Tech.
rep., CUniversitat Trier (2006)
19. Traetteberg, H., Krogstie, J.: Enhancing the usability of bpm-solutions by combining process
and user-interface modelling. In: J. Stirna, A. Persson, W. Aalst, J. Mylopoulos, M. Rose-
mann, M.J. Shaw, C. Szyperski (eds.) The Practice of Enterprise Modeling, vol. 15, pp. 86–97.
Springer Berlin Heidelberg (2009)
20. Ullah, A., Lai, R.: Modeling business goal for business/it alignment using requirements engi-
neering. Journal of Computer Information Systems 51(3), 21–28 (2011)
21. de la Vara, J., Sánchez, J.: Bpmn-based specification of task descriptions: Approach and
lessons learnt. In: M. Glinz, P. Heymans (eds.) Requirements Engineering: Foundation for
Software Quality, vol. 5512, pp. 124–138. Springer, Berlin, Heidelberg (2009)
22. Wiegers, K.E.: Software Requirements, 2 edn. Microsoft Press, Redmond, WA, USA (2003)

Appendix: Addition Patterns for Deriving Relationships from

Annotated Business Models.

No. Description Pattern Use Case Fragment

Each BUC must be related to the actor represent-

01 ing the Lane/Pool that contains it. In this way, the
actor responsible for the Use Case is indicated.
When a BUC is preceded or followed in the con-
trol flow by a LS, there is a relation between
02
them. This relation indicates that the BUC must
receive or provide information to the LS.
If there is a BUC grouping some tasks, an exclu-
sive or inclusive gateway, and a gateway’s alter-
native flow, and there is another BUC grouping
03 the default branch, then an include relationship
exists between the two Use Cases, since the BUC
in the default branch represents the normal func-
tionality to follow when the gateway is reached.
No. Description Source Pattern Use Case Fragment
If there are several BUCs connected by an ex-
clusive or inclusive gateway, the BUC preceding
the gateway is related to the BUC covering the
default branch by an include relationship (since
04
it represents the normal functionality to follow).
Also, the BUC preceding the gateway is related
to the BUC in the alternative flow by an extend
(since it extends the normal flow).
When two or more control flows are merged into
one by an exclusive gateway, the BUC identified
after the merge has to be related to the BUCs of
05 each branch by means of an include relationship.
Thus, it reflects that whenever a BUC of a branch
is completed the BUC following the merge has to
be executed.

If several business use cases are connected by a

parallel gateway, then they have to be handled as
06
isolated business use cases; since the execution of
each branch is independent of the rest.

When two or more control flows are merged into

one by a non-exclusive gateway, and there is a
BUC covering each branch and the flow nodes
07 following the gateway, then there is no relation-
ship between the business use cases; since the
condition to start the BUC following the gateway
is the completion of the BUCs in the branches.
Processing sub-processes. If in the control flow
there are sub-processes, they will be treated in-
08 dependently. The business tasks detailed in the
sub-processes will not be encapsulated in the Use
Cases identified in the main process.
Processing exceptions. If there is a sub-process
in which the exceptions are handled, and all the
sub-process’s flows are covered by a single busi-
09 ness use case, then the exception is added to the
business use case as an exception scenario. The
exception will thus be handled together with the
business use case.
Processing exceptions. If there is a sub-process
in which the exceptions are handled, and the sub-
process’s flows are covered by several business
use case, then a new BUC must be created to con-
10
trol the exception flow. This has to be related by View publication stats
extend relationships to the BUCs covering sub-
process’s flows. The exception is thus encapsu-
lated in a BUC that extends to the others.