Recovering Business Process Diagrams from UML Diagrams Maria Carmen Leonardi, Maria Virginia Mauco, Laura Felice INTIA, Departamento de Computaci6n y Sistemas Universidad Nacional del Centro de la Provincia de Buenos Aires Tandil, Argentina {cleonard, vmauco, Ifelice}@exa.unicen.edu.ar
German Montejano, Daniel Riesco Universidad Nacional de San Luis San Luis, Argentina {gmonte, driesco}@unsl.edu.ar
Narayan Debnath Winona State University Winona, USA
[email protected]
Abstract-
Enterprises
increasingly
automate
business
and
processes tasks, which make them highly dependent on their information systems. However, the documentation for business processes is rarely available; therefore the systems are often difficult to understand and maintain. In this paper we propose an initial strategy to recover the business processes of an organization from sequence diagrams. The strategy contains a set of heuristics that allow the manipulation of the components of a sequence diagram to define the BPMN components; at the same time, traceability information is recorded.
Business
Process
Modeling
Notation
Diagrams;
UML
Interaction Diagrams; Model Driven Architecture.
I.
INTRODUCTION
Enterprises increasingly automate business and processes tasks, which make them highly dependent on their information systems. These applications enable organizations to automatically perform their daily operations that are governed by business rules which are continuously modified. These continuous changes are forcing organizations to adapt their business processes and to evolve their supporting business applications in order to be competitive [12]. However, the documentation for business processes is rarely available; therefore the systems are often difficult to understand and maintain.
In the last years, software reengineering has become an important discipline within Computer Science to enhance and modernize systems. OMG has proposed ADM Task Force [2] for the modernization of legacy systems in the context of Model Driven Architecture (MDA) [14]. There are a lot of proposals in this direction [7, 8, 9] that concretely obtain UML diagrams from code. But UML diagrams are expressed in terms of object paradigm, so far from stakeholders' way of thinking. One of the main tasks is to obtain models that are understandable to stakeholders, because they have the knowledge to enhance the old software with the new requirements [10]. Therefore, it is necessary that the reverse engineering process reaches a stakeholder-level abstraction, like the one proposed in [11, 15, 16, 17]. Abstraction level transformation is the process that, following not formalized guidance or methodology, consumes a formal description of the initial artifact at a given level of abstraction and produces a formal description of the resultant artifact at another level of abstraction [2]. It can either increase or reduce the level of abstraction. In our case, we need to increase the level of abstraction, to represent the model with concepts known by stakeholders who are the owners of the problem space. In this paper we propose a strategy to obtain a business model, representing a CIM from MDA perspective [14], expressed in terms of Business Process Modeling Notation (BPMN) [5], from sequence diagrams (that are parts of MDA PSM models). In this way, we extend the proposal of our
research group [8] and cover all the phases of a reverse engineering process, i.e. from code to business models. The strategy, in this initial phase, is a set of heuristics that manipulate the sequence diagram in order to model the components of a business process diagram allowing traceability between the source and the target models. The paper is organized as follows: Sections 2 and 3 briefly defme the background concepts. Section 4 describes the strategy and exemplifies it. In Section 5 we present some discussions and future work. II.
THE UML INTERACTION DIAGRAMS
Sequence diagrams and collaboration diagrams, called interaction diagrams, are two of the diagrams used by UML for modeling the dynamic aspects of systems. An interaction diagram is a diagram that shows an interaction, which consists of a set of objects and their relationships, including the messages that may be dispatched among them. A sequence diagram is an interaction diagram that emphasizes the order of messages, i.e. it is used primarily to show the interactions between objects in the sequential order that those interactions occur [4]. Graphically, this diagram is a table that shows objects arranged along the X axis, beginning with the object that initiates the interaction in the left. Messages are ordered in increasing time from top to bottom along Y axis. Control flows are modeled using a special notation. In most sequence diagram appears the System Border. It is a bar in the left side that represents the interface with everything outside the blocks in the diagram, such as external actors, and consequently it can correspond to different outside of the system [13]. Figure 3 in Section 4 shows and example of a sequence diagram. A complete description of this kind of diagrams can be found in [4, 13]. III.
BUSINESS PROCESS MODELING DIAGRAM
Business Process Modeling Notation (BPMN) is an OMG standard for process modeling [5]. The idea behind BPMN is to defme a simple mechanism for creating business process models, while at the same time being able to handle the complexity inherent to business processes. The approach taken to handle these two conflicting requirements was to organize the graphical aspects of the notation into specific categories. This provides a small set of notation categories so that the reader of a BPMN Diagram can easily recognize the basic types of elements and understand the diagram. Within the basic categories of elements, additional variation and information can be added to support the requirements for complexity without dramatically changing the basic look and feel of the diagram. The four basic categories of elements are: Flow Objects, Connecting Objects, Swimlanes, and Artifacts. Flow Objects are the main graphical elements to defme the behavior of a Business Process. There are three kinds of Flow Objects: Event (something that happens during the course of a business process), Activity (a work that a company performs), and Gateway (controls divergence and convergence of a Sequence Flow). The Flow Objects are connected together in a diagram to create the basic structure of a business process. There are three Connecting Objects that provide this function:
Sequence Flow (shows the order in which activities will be performed in a process), Message Flow (used to show the flow of messages between activities), and Association (associates information with Flow Objects).There are two ways of grouping the primary modeling elements through Swimlanes: the Pool to represent a Participant in a Business Process, and the Lane, that is a SUb-partition within the pool to organize and categorize activities. Finally, the basic Artifacts are of three types: Data Object (information consumed or produced by activities), Group (grouping of activities that does not affect the Sequence Flow), and Annotation (text annotation to provide additional information). Figure 1 shows an example of a BPMN diagram. For a complete description of this diagrams refer to [5].
Figure I. BPMN diagram example (extracted from [5] page 61)
IV.
THE STRATEGY TO DERIVE BPMN DIAGRAMS
In this section we present a strategy to obtain a BPMN Diagram from class and sequence diagrams. The strategy, shown in Figure 2, consists of a set of heuristics which analyze each component of the interaction diagram in order to create or modify one 0 more components of the business process diagram. Each heuristic has a name, an abbreviation and a brief natural language description. Traceability is crucial in any transformation process. The links between the business specification document and the code are essential to locate the parts of code that contribute to implement specific functionality [1]. Therefore, in our proposal, simple traceability information is generated for each BPMN component produced by the heuristics in order to keep related the source sequence diagram component and the target business component. As sequence diagrams are extracted from code by [8], we keep business models and code related.
Hl_FPPD: Finding Potential Process Diagram Description: All the sequence diagrams that have a System Border and as first object life line an object belonging to a 2 «boundary» class become a potential process diagram. 1 Some notations use actors instead of System Border to distinguish which actor is involved in the diagram or a single arrow from the outside. We have the System Border because our sequence diagrams are recovered from code and we do not know who the external actor is. However, any of the notations is valid for our strategy. 2
A boundary class represents an interface between the system and some entity outside the system: a person or another system. Its role is to mediate the exchange of information with the outside world, and to insulate the system from changes in its surroundings. In UML there is an stereotype to represent it: «boundary». Generally they are derived from View. (http://www.ts.mah.seIRUPlRationaiUnifiedProcess/).
o
Heuristics Interaction diagram syntax Business process diagram syntax
-h:.----Traceability Model
Figure 2. Transformation Strategy
These diagrams represent the actions requested by the "outside" corresponding to the main activities of the business. The heuristic ignores all the interaction diagrams that do not contain this kind of classes as the fIrst object because they represent complementary actions. The name of the message sent by the System Border becomes the initial event of the process diagram.
Example: Figure 3 shows a sequence diagram corresponding
to a Debit Transaction sequence diagram.
In this case the Bank is an object belonging to «boundary» class, therefore, Hl_FPPD takes this diagram as a potential process diagram. As the fIrst message has not a name, the process diagram and the initial event will not have a special name. Figure 4 shows the trace information. Process diagram: Processdiagraml Heuristic: Hl]PPD Source: Transaction Sequence Diagram
Figure 4. Trace information
With the application of Hl_FPPD over all the sequence diagrams we detect the diagrams that represent the main activities of the business and model each of them as a potential process diagram. Then, the following heuristics are applied to these diagrams.
sequen�e SUb_S,qUenCe
amount
Sub
e
H2_DBA:
I
_
__________________�"I�_"_c:�-----------------------------_
2
Defining the Business Activities
Description: H2_DBA defmes the activities as follows: - A subsequence of messages with a defmed semantic becomes a BPMN activity. The name of the activity is the fIrst message in the subsequence. - If the messages in the sequence diagram contain parameters, a BPMN data object is created. This data object becomes an input of the activity (heuristic H4_FBR).
slDrePholDOKhec
--
�� [e
e
I I ; -------------------r---
------------------------
addlnsuffientFun Fee ( )
notEReturnedChec
'!o-
- If the subsequence contains a pair of set/get methods, heuristic H4_FBR deals with them.
(theCheck)
r
o o
I
(theCheck)
t
re tu rnCheck (thec eck) =-,
__
I I Figure 3. Debit Transaction sequence diagram [3]
- If there is a fmal return message, then it is modeled as a data object that will be an output of the activity. How to defme a subsequence? - A subsequence is a set of messages between an initial message from an object and a returning message for the same object before the fmal of the Y axis. - A subsequence is a set of messages between an initial message from the System Border object (or actor) and another initial message from it. - A subsequence is a set 0 messages inside a control mark (for example conditional, loop). This activity is marked as control
type activity and it will be exploited later by H3_DBCF.
Example: H2_DBA defmes as business activities the three subsequences shown with a circle in Figure 3 and names them with the first message of each one. The latest activity corresponds to a an alternative flow of message in the sequence diagram: then, it is specially marked to be later refmed. Figure 5 shows the BPMN notation for the activities and Figure 6 describes, partially, the trace information generated by the application of the H2_DBA.
[
Get
Amount
1[
Get Balance
J[
ALT ACTIVITY
[balance >= amount]
J
Example: H3_DBCF defmes the business control flow. Between the activities "Get amount" and "GetBalance" no special control is found, therefore a sequential flow is defmed. Between "GetBalance" and "[balance >= amount]" activities the heuristic shows an alt control, so a conditional sentence will be defmed. The expression of the condition is the alt expression of the sequence diagram. This activity has to be exploited later in order to show the correct behavior for the alternatives. This is done by applying H2_DBA to this parts of the sequence diagram, obtaining two new activities: addDebitTransaction and addInsufIcientFundFee. Figure 7 shows the results of the application of H3_DBCF, and Figure 8 part of the generated trace information. Process Diagram: Processdiagraml
Figure 5. Activities derived from the sequence diagram
Components: Conditional Flow From activity: GetBalance Expression: [balance
Process Diagram: Processdiagraml
>=
amount]
Heuristic: H3 DBCF
Components: Activity
Source: All expression in sequence diagram
Name: Get Amount Heuristic: H2 DBA Source: Debit Transaction Interaction diagram Subsequence:
Messages: Bank Check
�
�
amount
GetAmount(
�
Bank
Figure 8. Trace information
)
�
Check
H4 DBD:
Defining the Business Data
Description:
This
heuristic
looks
for
the
classes
that
represent the data of the business:
Process Diagram: Processdiagraml
- For each object in the sequence diagram heuristic looks
Components: Activity Name: Get Balance
for the corresponding class in the class diagram to discover what kind of logic it represents.
Primitive classes of the
language are discarded, for example primitive types, control Figure 6. Trace information for the derived activities
H3_DBCF:
classes (exceptions, security, etc.). The rest of the classes represent the logic of the business. For each of these classes
Defining the Business Control Flow
Description:
Flow between activities (modeled through gateways) depends on the kind of the first message of the subsequence that originated the second activity:
- If the message has a guard, heuristic models a conditional gateway - If the message has an alt, heuristic models an if-then gateway
H4_DBD models as BPMN data object the business classes that receive
get or set messages in the sequence diagram.
The
data object will be related to the activity representing the class that send the get or set message. The name of the data object will be the name of the class followed by the name of the message. Parameters of the message of the sequence diagram are also analyzed. If a data object appears as a parameter in a message, a data flow is defmed from the data object to the
- If the message has a opt, heuristic models an if gateway - If the message has a loop, heuristic models a returning flow to the activity
activity that contains the message with the parameter.
- If none of these marks appear, heuristic models a sequential flow.
:?
b = -1 tj t c � � _ _ _ _ a _ _ _ _ [ ,� --' --_B e_J -0-1,-__AmG ��n _t Jl Ye eb n addD
itTra saction
�o""tl
1
no
e
addlnsufici n tFundF
Figure 7. The business process obtained by the application ofH3_DBCF
ee
Example: H4_DBD considers The check and the Account classes in the sequence diagram. Because they are not primitive classes, they are modeled as BPMN business data. As they receive get and set messages, BPMN data are created and they are related to the activities that contain the get or set messages. Figures 9 and 10 show the result.
� � t
Get Balance
• f:I
� Thecheck:
Account:
Amount
Balance
v.
CONCLUSIONS
In this paper we propose an initial strategy to recover the business processes of an organization from sequence diagrams. The strategy contains a set of heuristics that allow the manipulation of the components of a sequence diagram to defme the BPMN components; at the same time, traceability information is recorded. Traceability is widely recognized as an important factor for program comprehension, software maintenance, impact analysis, and reuse of existing code components [6]. In particular, traceability plays an important role in any transformation process, because it keeps the rationales of the source of each component and facilitates future changes in the models. The business model derived by the strategy has to be enhanced by software engineers with the help of business experts. It is not possible a total automation because the models have different abstraction levels. The most difficult part is perhaps the abstraction of an activity that is how to fmd the limits of a set of messages that represent an activity. But the obtained models are a starting point to recover the logic of the business and they are easily understandable by the business analysts, who have the knowledge of the organization.
Figure 9. Data Objects
Process Diagram: Processdiagraml Components: Data Object Name: Account: Balance Heuristics: H4_DBD Source: getBalance message and Balance return message
Figure 10. Trace Information for Balance Data Object
Parameters are analyzed in order to model a data flow between activities. In this case, only a data flow is modeled between Get amount and addDebitTransation activities (because heuristic found the parameter amount). Figure 11 shows the fmal business process diagram.
...
Information Systems are a crucial asset of the organizations but once the business application is built, it has to be maintained and evolved in order to include all the changes on the requirements, the technology used, or the business processes supported. All these changes may require different treatments according to their impact, ranging from small improvements to the deployment of a new Information System [11]. Therefore software reengineering is and will be a crucial area, being a big challenge to research and business software people. A lot of work still remains to do. We have to enhance and complete the heuristics, and defme a way to compose the business diagrams obtained by the strategy to obtain the main activities of the organization. We plan to design a prototype to implement the heuristics and traceability information registration.
addDebitTransaction
1
no
addlnsuficientFundFee
Account:
Figure I I. Final Business Process corresponding to Debit Transaction sequence diagram
[9]
REFERENCES [I]
Antoniol, G.; Canfora, G.; Casazza, G.; de Lucia, A; Merlo, E. Recovering Traceability Links between Code and Documentation. IEEE Transactions on Software Engineering, 18 (10). 2002. pp. 970983.
[2]
Architecture-Driven Modernization (ADM) http://www.omg.orgladml (accessed July 2009).
[3]
Bell, D. UML's Sequence Diagram.IBM, Software Group. http://www.ibm.comldeveloperworks/rationallIibrary/3101.html (accesed July 2009).
[4]
Booch, G.; Rumbaugh, J.; Jacobson, I. The Unified Modeling Language User Guide. Addison Wesley. 1998.
[5]
Business Process Modeling Notation, VI.I. OMG Document Number: formal/2008-O 1-17 Standard document. http://www.omg.orglspecIBPMN/I.IIPDF (accessed July, 2009).
[6]
De Lucia, A; Di Penta, M.; Oliveto, R.; Zurolo, F. COCONUT: COde COmprehension Nurturant Using Traceability. 22nd IEEE International Conference on Software Maintenance (ICSM'06). 2006. pp 274-275.
[7]
Dugerdil, P. Using RUP to Reverse-engineer a Legacy Sys!e�. http://www.ibm.comldeveloperworks/rationallIibrarylsep06/dugerdd/m dex.html (accessed July 2009).
[8]
Task
Force.
Favre, L. Formalizing MDA-Based Reverse Engineering Processes. Proceedings of the 6th ACIS International Conference on Software Engineering Research, Management and Applications. IEEE Computer Society. 2008, pp 153-160.
Fenglian Xu; Wood,A Reverse Engineering UML Class and Sequence Diagrams from Java Code with IBM Rational Software Ar�hitec�. IBM Resources. 2008. www. ibm.comldeveloperworks/ratlOnallhbrary/ 08/0610_xu-woodlindex.html, (accessed June 2009).
[10] First International Workshop on Reverse Engineering to Requirements (RETRS'05). http://www. cs.toronto.edulkmlretr/ (accessed July 2009). [II] Grau Colom, G. An i·-based Ree�ginee�ing Fram�wor� for . Requirements Engineering. Doctoral TheSIS. Umversltat Pohtecmca de Catalunya. http://www.tdx.catlTDX-0312109-120337 (accesed July 2009). [12] Guo Jin, Zou Ying. Detecting Clones in Business Applications. 15th IEEE Working Conference on Reverse Engineering. 2008. pp 91-1001. [13] Jacobson, I.; Booch, G.; Rumbaugh, J. The Unified Software Development Process. Addison Wesley. 1999. [14] Model Driven Architecture (accessed July 2009).
(MDA)
http://www.omg.orglmdal
[15] Rodriguez, A; Caro, A LIS2BP: Una Propuesta para Obtener Procesos de Negocio a partir de los Sistemas Heredados. IDEAS2009, XII Conferencia de Ingenieria de Requisitos y Ambientes de Software. Colombia, 2009. pp. 29-42. [16] Zou, Y.; Lau, T.C.; KontogiamJis, K.; Tong, T.; �cKegney, Roo Mo�el Driven Business Process Recovery. Proceedmgs. 11th Workmg Conference Reverse Engeneering. 2004. pp. 224-233. [17] Zou, Y.; Hung, M. An Approach for Extracting �orkflows from E Commerce Applications. Proceedings 14th International Conference on Program Comprehension. 2006. pp. 127-136.
