Informatica 31 (2007) 407-417 407
Modeling eGovernment processes with UMM
Philipp Liegl and Rainer Schuster
Studio Digital Memory Engineering, Research Studios Austria Thurngasse 8/20, 1090 Vienna
{pliegl, rschuster}@researchstudio.at, http://dme.researchstudio.at Marco Zapletal
Electronic Commerce Group, Vienna University of Technology Favoritenstr. 9-11/188, 1040 Vienna marco@ec.tuwien.ac.at, http://www.ec.tuwien.ac.at
Christian Huemer
Business Informatics Group, Vienna University of Technology Favoritenstr. 9-11/188, 1040 Vienna huemer@big.tuwien.ac.at, http://www.big.tuwien.ac.at
Birgit Hofreiter
Faculty of Information Technology, University of Technology Sydney PO Box 123, Broadway NSW 2007, Australia birgith@its.uts.edu.au, http://www.it.uts.edu.au/
Robert Mosser
Inst. of Distributed and Multimedia Systems, University of Vienna Liebiggasse 3/3-4, 1010 Vienna robert.mosser@univie.ac.at, http://www.cs.univie.ac.at
Keywords: inter-organizational business processes, UMM, UML, eGovernment Received: July 31, 2007
The Uni ted Nati on's Center for Trade Facili tation and Electronic Business (UN/CEFACT) is a standardization body known for its work on UN/EDIFACT and ebXML. One of its most recent developments is UN/CEFACT's Modeling Methodology (UMM). The UMM standard is used to model inter-organizational business processes in the B2B domain. With the increasing availability of electronic governmental services over networks, the frontier between B2B and B2G/G2G disappears. Today one expects a governmental institution to react like any other business partner. Therefore also governments now face the interoperability and compatibility issues as regular businesses do. In order to allow two governmental institutions to collaborate, a methodology uniquely depicting the inter-organizational process from a global perspective is needed. In this paper we propose to use UN/CEFACT's Modeling Methodology in the eGovernment domain. UMM allows the definition of a global choreography which is then being used to derive local orchestrations for each business partner. Such orchestrations can then be used by enterprise applications in a service oriented context. As an example, a real-world scenario from the waste transport domain within the European Union will be shown. Furthermore the possible integration in the context of the We-Go project [3] is examined.
Povzetek: Predstavljeno je modeliranje procesov e-uprave z UMM.
1 Introduction
The multitude of eGovernment initiatives and efforts which have been made in the last few years have shown the emerging significance of the domain. With more and more governmental institutions being present on the Internet, other businesses expect a governmental institution to react like a regular business does e.g. offering key business functionalities via services accessible over the Internet. When fulfilling these expectations gov-
emmental institutions face the same problems as regular businesses. Therefore the distinction commonly made between government-to-government (G2G), business-to-business (B2B), and business-to-government (B2G) is not appropriate any more.
In the context of eGovernment a distinction is made between informational services, communicational services and transactional services. Information services provide content to citizens and enterprises in an unidirectional way. Communication services are providing information content
408 Informática 31 (2007) 407-417
P. Liegl et al.
too but in a bidirectional way, hence allowing feedback. Most of the eGovernment services in use today are either informational or communicational services. Whereas these two service types do not impose real technological challenges, transactional services are more difficult to implement. A transactional service allows enterprises and citizens to interact with governmental institutions in order to execute official functions e.g. announce a waste transport from country A to country B.
Business interactions which before were done face-to-face with a government official are now conducted electronically over a network. The implementation of such a transactional service becomes more difficult if many enterprises are actively using the service in an automated manner. In particular larger enterprises will use the interfaces provided by the government and invoke them through their own enterprise system. If such a process is conducted in an automated manner between two independent electronic systems, the business process itself and in particular the order in which the business messages are exchanged, must be well defined. Figure 1 shows an example of transactional services in the eGovernment domain. In order to perform transactional services between two business partners a set of alignments is necessary.
In the first step the legal requirements must be set and well-defined. Before an eGovernment transaction can be executed the necessary policies and guidelines must be set. Policy alignment means that the involved parties must act in a specific legal area. Given that the parties operate in a well-defined and safe legal framework, there still may be open legal space which must be filled by contracts between the parties. Therefore, a contractual alignment between the parties is required in order to close any legal gap.
Directly influenced by the legal settings is the organizational layer. This layer focuses on the alignment of the shared business logic between the two participating parties. Once the involved business partners have agreed upon a global perspective, the process can be executed. Hence the "contract" defined on the organizational layer governs the technical execution e.g. the exchange order of business messages (process alignment) and what business messages are exchanged (information alignment). In terms of business alignment the business layer defines a global choreography to which the two business partners must comply. The global choreography is then used to derive the local orchestrations for each business partner. This guarantees that both local orchestrations comply to the global choreography and are thus complementary.
The choreography defined on the organizational layer must be executed between the two involved information systems. In other words, a workflow of business document exchanges must be implemented. In order to keep the business applications of the involved business partners as flexible as possible to the inter-organizational business process, the use of a business service interface is suggested. A business service interface as described in figure 1 forms a sort of proxy layer between the own business application and
the business application of the business partner. The business service interface uses a declarative approach to define the execution order of the business process (e.g. BPEL) and can therefore be quickly adjusted to any changes in the underlying business process.
In order to help governmental institutions to implement transactional services we propose to use UN/CEFACT's Modeling Methodology. The United Nations Center for Trade Facilitation and Electronic Business (UN/CEFACT), known for its standardization work in the field of UN/ED-IFACT [23] and ebXML [16], has developed the so called UMM standard. UMM stands for UN/CEFACT's Modeling Methodology and enables to capture business requirements independent of the underlying implementation technology such as Web Services or ebXML. In regard to figure 1 UMM provides a formal mechanism to define the requirements for the organizational and technical layer.
The remainder of this paper is structured as follows: Section 2 explains the UMM standard in detail by using an example from the waste management domain. In section 3 we introduce our UMM modeling tool called UMM Add-In and its support features for the UMM standard. The integration of the UMM standard in the roll-out of the We-Go project will be the subject of section 4. Section 5 gives an overview about other research efforts in the field of inter-organizational business processes. The paper concludes with an outlook and future research issues.
2 UN/CEFACT's Modeling Methodology
UN/CEFACT's Modeling Methodology (UMM) is a UML based methodology for capturing the requirements in an inter-organizational business process. It is independent of the underlying transfer syntax. The overall goal of the UMM methodology is to create a global choreography of the business process. If two business partners interacting with each other both define their own choreography for the business process, the resulting choreographies are unlikely to match. UMM pursues a top down approach by first defining the global choreography from which the local choreographies are derived. Hence it is ensured, that both choreographies are complementary.
UMM is built upon the UML meta model and defined as a UML profile [25] e.g. a set of stereotypes, tagged values and OCL constraints. Its current version is 1.0 based on UML 1.4 [17]. The predecessor based on UML 2.0 is currently under development.
In the following section we will outline a real-world UMM example from the eGovernment domain in the European Union.
MODELING EGOVERNMENT PROCESSES WITH UMM
Informatica 31 (2007) 407-417 409
e-Government Transactional Services
Organization A
(Governmental Organization)
Business Operations Model
Business Processes
e-Government Collaboration Model
Legal Alignment
Policy Alignment
Contractual Alignment Organizational Alignment
Process Alignment
SL
Information Alignment
SL
Technical Alignment
Workflow Alignment
Business Document Type Alignment
Data Format Alignment
Messaging Alignment
Transport Protocol Alignment
Security Alignment
Service Description Alignment
Organization B
(Citizen, Enterprise, Governmental Organization)
Business Operations Model
Business Processes
Figure 1: Transactional services in the eGovernment domain
2.1 A UMM example from the eGovernment domain
In this section we briefly describe the steps of UMM and the resulting artifacts. For a better understanding we walk through the UMM by the means of a simple example from the waste transport domain as it is used in the European Union today. A waste transport taking place between two countries in the European Union will be analyzed. The transport of goods and persons within the EU is not subject to strict regulations any more. However the transport of waste between two European countries underlies regulations accompanied by a multitude of forms and administrative documents. One major goal of the European Union is to facilitate the waste transport by supporting the transport process with information technology means and to decrease the amount of paper documents involved.
The relevant artifacts of our example are depicted in figure 2. On the left hand side of this figure we see the structure of our waste management model. A UMM business collaboration model comprises three main views: the business domain view (BDV), the business requirements view (BRV), and the business transaction view (BTV). The three top level packages of any UMM model are always stereotyped in accordance to these views. For relevant artifacts in the tree-view on the left hand side of figure 2 the according diagrams are shown on the right hand side of the figure.
The BDV is used to gather existing knowledge from stakeholders and business domain experts. In interviews the business process analyst tries to get a basic understanding of the business processes in the domain. The use case descriptions of a business process are on a rather high level. One or more business partner types participate in a business process and zero or more stakeholders have an interest in dependency with the process. The BDV results in
a map of business processes, i.e. the business processes are classified. Thus, the BDV package includes business area sub-packages. UN/CEFACT suggests to use business areas according to the Common Business Process Catalog [24]. Each business area consists of process area packages that correspond to the Open-edi phases (planning, identification, negotiation, actualization, and post-actualization) [10]. In our waste management example the relevant business areas are logistics and regulation. Logistics covers at least the process areas of actualization and post-actualization. The business area regulation only contains the process area actualization. We do not want to detail here all the business processes that may be important to the domain experts and stakeholders in these areas. Due to size restrictions we do not present the structure of business areas and process areas in the business domain view of figure 2.
The BRV consists of a number of different sub-views. The business process view (1) and the business entity view (2) are both very project specific. The business process view gives an overview about the business processes, their activities and resulting effects, and the business partners executing them. The activity graph of a business process may describe a single partners process, but may also detail a multi-party choreography. The business process analyst tries to discover interface tasks creating/changing business entities that are shared between business partners and thus, require communication with a business partner. Discovery of interface task is more important in this step than modeling an exact control flow of activities. In our example we detail a multi-party business process for an end-to-end waste transport (1). The four parties involved in the process are exporter, export authority, import authority and importer. Due to space limitations the exporter and the im-
408 Informática 31 (2007) 407-417	P. Liegl et al.
Figure 2: UMM Overview
MODELING EGOVERNMENT PROCESSES WITH UMM
Informatica 31 (2007) 407-417 409
porter have been simplified. The exporter pre-informs the export authority about an upcoming waste transport. The export authority in turn informs the import authority of the country the waste transport is imported to. The import authority then informs the importer. After the waste transport has been conducted the importer informs the import authority about the arrived waste transport. The import authority then informs the export authority of the country the waste transport originated from. Finally the export authority notifies the exporter about the successful waste transport.
The information exchanged between business partners is about the business entities waste transport. A waste transport object is created with the state announced. Later it is set either to the state rejected or accepted. Finally, after the waste transport took place the waste transport state is set to arrived. These so-called shared business entity states must be in accordance with the business entity lifecycle of waste transport. The lifecycle is defined in the state chart of the business entity view (2). Due to space limitations the process view in (1) has been simplified and the options for setting the waste transport to accepted or rejected have been left out.
Since the same tasks take place between a different pair of business partner types, it is not appropriate to describe these tasks for each pair again and again. Instead, these tasks are defined between authorized roles. A transaction requirements view defines the business transaction use case for a certain task and binds the two authorized roles involved. The authorized roles are defined in the exact context of the business transaction use case. In our example we have two transaction requirements views: announce waste transport (3), and announce transport arrival (4). By coincidence the authorized roles in announce waste transport and announce transport arrival have the same name, namely notifier and notifiee.
The collaboration requirements view includes a business collaboration use case. The business collaboration use case aggregates business transaction use cases or nested business collaboration use cases. This is manifested by include associations. In our example the business collaboration use case manage waste transport (5) includes the business transaction use cases announce waste transport (3) and announce transport arrival (4). Furthermore, the authorized roles participating in the business collaboration use case must be defined within the context and namespace of the collaboration requirements view. We call the roles notifier and notifiee. Again the homonymous names are coincidental. The notifier is the one who initiates the manage waste transport and the notifiee is the one who reacts on it. The authorized role notifier in announce waste transport arrival (4) is not the same as the one in manage waste transport (5). This means, we have two authorized roles notifier, each defined in the namespace of its view. Maps to dependencies are used to define which authorized role of a business collaboration use case plays which role in an included business transaction use case (or nested business collaboration use case). In our example the notifier of
manage waste transport (5) plays the notifier of announce waste transport (3) but also the notifier in announce transport arrival (4). The notifiee of manage waste transport (5) plays the notifiee of announce waste transport (3), but also the notifiee of announce transport arrival (4).
A business collaboration use case may have many business collaboration realizations that define which business partners play which authorized roles. Due to space limitations the concept of business collaboration realizations is
not further elaborated here.
The BTV builds upon the BRV and defines a global choreography of information exchanges and the document structure of these exchanges. The choreography described in the requirements of a business transaction use case is represented in exactly one activity graph of a business transaction. A maps to dependency between them allows traceability between the requirements and the business transaction, which is defined in a business interaction view. In our example, the announce transport arrival requirements (4) are mapped to a corresponding choreography (8). The same mapping is made for the announce waste transport requirements (3+7).
A business transaction is characterized as follows: If an authorized role recognizes an event that changes the state of a business entity, it initiates a business transaction to synchronize with the collaborating authorized role. A business transaction is an atomic unit that leads to a synchronized state in both information systems. We distinguish one-way and two-way business transactions: In the former case, the initiating authorized role reports an already effective and irreversible state change that the reacting authorized role has to accept. In the other case, the initiating partner sets the business entity/ies into an interim state and the final state is decided by the reacting authorized role. It is a two-way transaction, because business information flows from the initiator to the responder to set the interim state and backwards to set the final and irreversible state change. Irreversible means that returning to an original state requires compensation by another business transaction.
Owing to this strict definition, a UMM business transaction follows always the same pattern: A business transaction is performed between two authorized roles that are already known from the business transaction use case and that are assigned to exactly one business transaction swim-lane each. Each authorized role performs exactly one activity. An object flow between the requesting and the responding business activity is mandatory. An object flow in the reverse direction is optional. In our example the business transactions announce waste transport (7) is a two-way transaction whereas announce transport arrival (8) is a one-way transaction. Sending the waste movement form envelope (7) sets the interim state arrived of the business entity waste transport. The reply in the announce waste transport sets it to the state accepted or rejected. Finally the notification in announce transport arrival (8) sets the final state of the business entity waste transport to arrived.
408 Informática 31 (2007) 407-417
P. Liegl et al.
The requirements described in a business collaboration use case are choreographed in the activity graph of a business collaboration protocol, which is defined in a business choreography view. This one-to-one relationship is denoted by another maps to dependency. In our example, the manage waste transport requirements (5) are mapped to the business collaboration protocol shown in (9). A business collaboration protocol choreographs a set of business transaction activities and/or business collaboration activities. A business transaction activity is refined by the activity graph of a business transaction. In our example, the business collaboration protocol of manage waste transport (9) consists of two business transaction activities: announce waste transport and announce transport arrival. Each of them is refined by its own business transaction (7,8). Maps to dependencies keep track of this refinement. Business collaboration activities - which are not used in our example - are refined by a nested business collaboration protocol.
The business information views are used to define the structure of business documents exchanged in business transactions. Each of the four information envelopes exchanged in the two business transactions lead to a business information view describing the envelope's document structure. Due to space limitations only two information envelopes are shown namely waste movement form envelope and transport arrival form envelope. An information envelope consists of a header and a body. The header carries auxiliary information and the body holds the actual business document exchanged during the transaction. UMM itself does not prescribe a particular format for the exchanged business document. However the use of so called core components [26][28] is suggested.
3 A tool support for UMM
Since UMM is defined as a UML profile, a business analyst may use any UML tool to model UMM business collaboration models. As we outlined in the beginning, UMM artifacts are based on a specific subset of UML to capture complex business collaborations. Between these artifacts, a number of dependencies and constraints exist. If a regular UML tool is used for UMM, these rules are not enforced. Furthermore, a modeler is not prevented from using modeling elements that are not part of UMM's meta model. However, valid models are required for at least two reasons. Firstly, if a business process model is shared between partners, it has to be formally correct in order to ensure an unambiguous communication in terms of the modeled business domain. Secondly, a UMM model allows the generation of machine-interpretable process and business document specifications to configure B2B information systems. Obviously, deriving artifacts following a model driven approach works only for valid models. Consequently, a modeling tool considering UMM-specifics is needed. Instead of developing a new modeling tool from scratch, we decided
to build our UMM tool on top of the commercial UML tool Enterprise Architect. The UMM Add-In utilizes Enterprise Architect's UML functionality and extends it by implementing the UMM-specifics. The UMM Add-in supports the business analyst by the following main features:
1.	UMM-specific toolbar
2.	UMM requirements engineering support
3.	Semi-automatic generation of UMM artifacts
4.	Validation of the UMM model
5.	Generating process specifications for B2B information systems
6.	Core Component support
3.1	UMM specific toolbar
In order to create a UMM model it is convenient to drag and drop UMM stereotypes from a toolbar onto the modeling canvas. Thus, the stereotypes as defined in the UML profile for UMM are integrated into Enterprise Architect and provided in a toolbar. The toolbar itself is organized in sections that correspond to the UMM views. This helps the user applying the right stereotypes in a certain UMM step. In order to prevent the user from using UML elements not part of the UMM subset, the toolbar is restricted to the UMM stereotypes and UML standard elements required by UMM.
3.2	UMM requirements engineering support
Requirements engineering is not only important for software development processes, but is also an critical task in business process modeling. Usually a lot of different people with different backgrounds are involved in the development process of a business model. In order to close this gap of various levels of business knowledge and expertise, the requirements of a business model must be documented in natural language. The outcome of this process is a common understanding of each part of the business scenario. Usually the business knowledge is collected during interviews between the business analysts and the business domain experts.
Especially in UMM the requirements engineering plays a major role. UN/CEFACT recommends using a set of so-called worksheets in order to capture the gathered business information. A UMM worksheet has its pre-defined structure containing standardized elements and is assigned to a specific part in the business model. Traditionally, worksheet templates have been filled out using a word processor. This leads to a great number of external paper documents. Since most of the worksheet information is captured later on in tagged values, this result in duplication of efforts and a danger of inconsistency. Thus the worksheet editor of
MODELING EGOVERNMENT PROCESSES WITH UMM
Informatica 31 (2007) 407-417 
409
5 IWasteManagement i
B [m] í:E!uíineíí Domain Vie1.-......Waste Management
Waste Management - _J -sEusinessAreas- Logistics
I -sProcessAreas- Actualization I -sProcessAreas- Post-Actualization
+ [z[] í:E!uíineííRequirementíVie1.-......Waste Management
+ [Is] -sEusinessTransactionViews- Waste Management
Figure 3: Semi-automatic generation of BDV's initial package structure
the UMM Add-In integrates the requirements engineering into the UMM model. Once the business domain knowledge is acquired, the information is directly stored in the corresponding tagged value of the assigned UMM artifact.
The worksheet editor offers an interactive form including all elements specified by UN/CEFACT. Additionally self-defined worksheets may be created using an XML based worksheet definition language (WDL). Each UMM artifact, which needs to be documented, has an XML based property file, in order to specify the layout, the structure and the content of the worksheet. This guarantees a flexible adaptation of worksheets to special business needs and to changes due to an update of the UMM meta model. In order to ensure traceability, some artifacts of a UMM model are interlinked - e.g. the business transaction in the business transaction view has a dependency to the corresponding business transaction use case in the business requirements view. Thus, business requirements information must not differ between such UMM worksheets. In order to avoid inconsistency the worksheet editor provides the modeler with business information already entered to prior worksheets having seman-tically the same content.
The communication between the business domain expert and the business analysts is usually based on some model reports. Thus, such reports must be generated from the model. The modeler is able to generate document reports using the export functionality of the worksheet editor. The user either exports the gathered information into Microsoft Word, or publishes HTML pages of the business model requirements. Furthermore, the whole documentation can be stored in an XML based format for backup purposes as the XML files can be re-imported into the model.
3.3 Semi automatic generation of UMM artifacts
In the section above we have demonstrated how the worksheet editor is used for capturing business requirements of a UMM model. The worksheet editor offers an added value by generating UMM artifacts automatically from the captured requirement information. Thereby, the modeler is re-
leased from routine tasks. Instead of modeling recurring UMM patterns manually the UMM Add-In creates such artifacts automatically using the input of the worksheets the modeler already entered.
In figure 3 such a workflow is depicted. The worksheet of the business domain view captures information about business areas and process areas. Since UMM recommends using a set of hierarchically pre-defined business and process areas according to the Common Business Process Catalog (CBPC) [24], the package structure of the BDV differs only by the modeler's choice of package constellations. The structure of business areas and process areas - which may follow a matrix - is transformed into a tree-structure of packages. Instead of manually creating this tree-structure, the modeler simply checks the relevant cells in the pre-defined matrix and the package structure is created. In our waste management example the business area logistics together with its process areas actualization and post-actualization have been generated automatically using this matrix.
Another candidate for a semi-automatic generation is the business transaction. The structure of a business transaction follows always the same pattern. However, instances of business transactions differ from each other with respect to the exchanged information, the names of the activities and the participating roles. The business transaction announce waste transport has been generated by the UMM Add-In using the form depicted in figure 4. Since every business transaction has a corresponding business transaction use case, the UMM Add-In offers the modeler a list of all business transaction use cases already defined in the BRV. Once a use case is selected, the modeler is presented with possible participating roles and information envelopes. Thereby the modeler saves a lot of time instead of manually creating each business transaction manually from scratch.
3.4 Validation of a UMM model
With the increasing complexity of a UMM model an inexperienced user often loses the overview and possible flaws
408 Informática 31 (2007) 407-417
P. Liegl et al.
BusinessTransactionSwim Responder :Notifiee
«InformationEnvslops» WasteM ovementResponseEnvelope
ir
Figure 4: Semi-automatic generation of a business transaction
in the model remain undetected. A foible in the model such as a missing connector might not be an issue if the model is just used to communicate the structure of the inter-organizational business process between humans. If however, the model is used to derive business artifacts in an automated manner, a syntactically valid model is a prerequisite. As shown in the next chapter the UMM model can for instance be used to generate BPEL or BPSS documents. If the model is not correct the generator will most likely produce invalid documents or the generation fails completely.
Given these prerequisites, the UMM Add-In has a validation feature that allows checking the formal validity of a given UMM model. The validator is based on the OCL constraints incorporated in the UMM foundation module [25]. It however, does not interpret the OCL constraints directly but the logic is incorporated in the program code. The validator feature of the UMM Add-In allows two types of validation runs - bottom-up validation and top-down validation. The former one is used to validate sub-packages of a given UMM model and the latter one is used to perform a validation run on the whole model. After a validation run the errors found in the model are presented to the modeler. By double-clicking on an error message a detailed description of the error is shown.
Apart from the possibility to validate a given UMM model the validator will also help new users to get acquainted to the UMM standard. Many users do not read the whole specification but start modeling from scratch on a try and error basis. Especially the bottom up validator will gradually help the inexperienced user to create a valid UMM model and antagonize the argument, that UMM is too hard to learn or apply.
3.5 Generating process specifications for B2B information systems
In our UMM Add-In, we support the derivation of process descriptions for Web Services and ebXML - the two major approaches for implementing SOAs. In case of Web Services, we support the Business Process Execution
Language (BPEL), for ebXML the tool generates choreographies according to the Business Process Specification Schema (BPSS). On a conceptual level, mappings from UMM to BPSS [8] and from UMM to BPEL [7] [9] have already been proposed. In our tool, the implemented transformation algorithms follow these approaches. The generated process specifications represent the local orchestrations which are derived from the global UMM choreography. In a real world scenario these process specifications are taken and fed into the business service interfaces of the participating business partners. Because each specification was derived from the global UMM choreography, the two business service interfaces participating in the inter-organizational business process are complementary and electronic business can be conducted in an automated manner.
3.5.1 Generating BPEL from UMM
BPEL describes the flow of a business process as a sequence of interactions between Web Services. An interaction is represented by an activity pointing to the respective service. Business partners participating in a process might provide services to the process and consume other partner's services. BPEL denotes the sequence of such Web Service calls, maps service calls to concrete Web Services and collates service consuming and service providing to the process participants. Thereby, BPEL describes the respective business process from a specific partner's point of view. Considering a business process internal to a company, whereby the company fully controls the logic of the process, the BPEL approach works fine. The process can easily be composed by orchestrating the required services in order to achieve the desired output. However, considering a complex B2B scenario that requires the participants to agree on process choreography, an approach whereby each participant describes its own view on the process in isolation will fail. In other words, if each business partner of a collaborative process describes its own BPEL the resulting process descriptions characterizing the same process will most likely not match. Thus, having BPEL ap-
MODELING EGOVERNMENT PROCESSES WITH UMM
Informatica 31 (2007) 407-417 409
plied in a B2B environment necessitates first a global view on the process, like UMM provides it, in order to gain complementary process descriptions.
In order to support this approach, the UMM Add-In allows the generation of partner-specific BPEL processes from a global UMM choreography. Since services are referenced by their WSDL in BPEL, the tool generates also a WSDL for each partner, describing the set of services he or she has to provide. Due to space limitations, we do not show the actual BPEL result.
3.5.2 Generating BPSS from UMM
BPSS denotes the choreography of a B2B business process for ebXML environments. It captures the flow of a collaborative process from a global viewpoint describing how each participant has to act in order to fulfill his or her part of the business process. BPSS is defined as an executable subset of the UMM specifying a B2B process by the concepts of a business collaboration consisting of business transactions. Although the BPSS specification does not mandate using UMM to gain BPSS process definitions, its use is recommended. Due to its alignment to UMM, BPSS allows the configuration of a business service interface according to the rich semantics of UMM business collaboration models. Given the space limitations the BPSS output is not show either.
4 UMM in the WeGo project context
The WeGo project Enhancing Western Balkan eGovern-ment Expertise [3] targets to boost eGovernment awareness and knowledge in order for Western Balkan Countries (WBC) to reach higher productivity and EU conformance. The major aim of the project is the transfer and the successful adoption of eGovernment best practices and knowledge. The project itself is split up into four distinctive yet complementary pillars namely: We-Go Interoperability Framework, We-Go Application Trials, We-Go Academies and We-Go Knowledge Net.
One of the main objectives of the project is the establishment of the WeGo Interoperability Framework with focus on transactional cross-border services and EU alignment. A second major task is the transfer of best practices for corresponding transactional application domains using demonstration prototypes. Services addressed by the project include eCustoms - New Computerized Transit System (NCTS), eJustice cross-border cases - Automation of Court Procedures (ACP), European Companies Register (ECR) and European Land Information System (EULIS), eAdministration - Electronic Filing System (implementation of paperless government) and eTrade Facilitation for European Waste Transport (EUDIN). Another goal is the establishment of eGovernment Academies to support and complement the Interoperability Framework and demonstration prototypes efforts and to establish a solid foundation for future regional eGovernment course program
deployments. Finally the project aims on the establishment of an eGovernment Knowledge Net built by a system of federated registries to give easy access to relevant pieces of information, such as specifications or complete services including the solution and documentation. The WeGo Knowledge Net will encourage the re-use of existing approaches that will increase the likelihood of interoperability out of the box.
The analysis phase for the WeGo Interoperability Framework showed that there is a high need for clear and structured modeling and description of processes in the eGov-ernment area. Governments face interoperability issues when establishing cross-organizational services between different public authority bodies within the same or even different countries or services including European Union institutions. As mentioned above, cross-national services are covered by the WeGo project, e.g. in the eJustice and eCustoms area. The success of eGovernment heavily depends on the appropriate design and specification of processes in the application domain. Although the requirements in the various eGovernment domains may vary (as clearly indicated by the WeGo project) the specification of eGovernment processes should follow general, well-accepted design principles, such as UMM. A uniform structure and modeling of inter-organizational processes helps to increase business process interoperability. UMM is qualified to support that effort since it is a methodology for unambiguous definition of inter-organizational business processes. As an example, the eTrade Facilitation for European Waste Transport (EUDIN) system is not only based on IT-platform standards such as XML and Web Services, but also on standards describing the business logic of the system. One of the latter is UMM that has been used to define the business processes.
UMM is powerful but may be a challenge for users not familiar with it. Knowledge required to make use of UMM is made available through the WeGo Knowledge Net by providing specifications, tutorials or complete business process models for re-use. Another channel for the distribution of UMM know-how are the WeGo Academies.
5 Related Work
Over the last couple of years, a lot of methodologies for modeling business processes have been developed. Some of them are based on special notations often defined by standardization bodies. Others customize the UML for business process modeling needs. Traditionally, business process modeling focuses on modeling business processes internal to an organization fulfilling customer needs. More recent approaches also take inter-organizational business processes into account. Another criteria for distinguishing business process modeling approaches is its binding to the supporting IT infrastructure. Some approaches are mainly used in the requirements specification phase to support the communication with business domain experts. Resulting
408 Informática 31 (2007) 407-417
P. Liegl et al.
models usually hide implementation complexity and are on a rather abstract level. Other approaches are more implementation oriented and rather provide a graphical interface for workflow languages or Web Service orchestrations/choreographies.
Recently, the Business Process Modeling Notation (BPMN) [18] has attracted a lot of attention. BPMN is standardized by the Object Management Group (OMG) in order to enhance a uniform modeling notation for business processes, which is understandable by all business users - from the business analysts to the technical developers. In order to realize this goal, BPMN incorporates aspects of already advanced modeling notations (e.g. UML activity diagrams, IDEF [15], ebXML BPSS [27], RosettaNet [20], etc.). In order to close the gap between the business process design and the business process implementation, BPMN has a standardized mapping from BPMN to BPEL (Business Process Execution Language) [5].
Another very popular notation in business engineering are the Event-driven Process Chains (EPCs). EPC is a business process modeling language, focusing on control flow dependencies of activities in a business process. It is utilized in the ARchitecture of Integrated Information Systems (ARIS) by Scheer [21] as the central method for the conceptual integration of the functional, organizational, data, and output perspective in information systems design.
In addition to special business modeling notations, some approaches extend the UML meta model for this purpose. Initially, UML was designed to capture requirements for object oriented software systems in a graphical manner. Nevertheless some UML concepts, like UML activity diagrams, may be adopted for business process modeling. Korherr and List propose a UML profile for modeling business processes considering business process goals and performance measures [12]. Since the UML 2 activity diagram does not include such concepts, the UML meta model has been extended by a set of stereotypes and tagged values. On the one hand side this approach focuses on integrating measurable values into a business model at the conceptual layer. On the other hand side it specifies a mapping of UML models to BPEL, in order to make these values available for execution and monitoring. However, this approach is developed for modeling business processes internal to an organization. Further UML based approaches restricted to an internal view are proposed in [14] and [19].
For the purpose of representing and managing B2B business processes considering an inter-organizational view, Kim proposes a UML 1.x based modeling approach [11]. He uses activity diagrams for modeling collaborative processes as a flow of transactions in order to create an ebXML compliant business process specification. A transaction is a message exchange between two business partners and is represented as an activity in the activity graph. The flow of data exchanged between business partners is then captured in sequence diagrams.
A more IT-oriented approach is proposed by Tyndale-Biscoe et al. [22]. The authors present a UML 1.4 profile
for the integration of business processes and software development used in an EU funded project. The UML profile provides the mapping between real world business concepts and software artifacts.
Kramler et al. [13] use UML 2 for depicting the choreography of Web Services. Unlike traditional business process modeling, additional requirements must be considered for service collaborations - e.g. security management or transaction management. In their paper the authors split the models into a layered architecture - collaboration, transaction, and interaction level, in order to compare these levels of granularity with the eCo framework [6]. The modeling technique is based on the considerations for a mapping to the Business Process Specifications Scheme (BPSS) and the Business Process Execution Language (BPEL).
6 Conclusion and Outlook
In this paper we have presented UN/CEFACT's Modeling Methodology (UMM), a language for designing B2B processes. UMM is defined as a profile for UML 1.4. In other words, the UML meta model has been extended by a set of stereotypes, tagged values and constraints in order to adjust UML for the semantics required by B2B. In theory, UMM models can be created by any UML tool. However, as we outlined there is a significant need for a customized UMM tool considering the UMM-specifics. Therefore, we developed the UMM Add-In - a plug-in for the commercial UML tool Enterprise Architect. This tool supports business analysts in creating UMM compliant business collaboration models. The functionality of the Add-In was characterized in the main part of this paper.
UN/CEFACT's Modeling Methodology in combination with our UMM Add-In is already in use in a couple of -mostly eGovernment related - projects for capturing collaborative business processes. The German Government uses UMM in order to define business collaborations between the local and federal governments. In this project a so-called XOV Framework [4] is responsible for a harmonization of different XML based standards used in the public administration by using the concepts of UMM and Core Components. A further project using UMM has been set up by the Australian Government and is called GovDex [1]. The Department of Finance and Administration uses UMM and Core Components in order to improve the efficiency and effectiveness of business process collaborations across policy portfolios (e.g., taxation, human services, etc.) and administrative jurisdictions. The Canadian Administration is trying to apply the principles of UMM to describe the activities of governmental agencies. This work is known as the Governments of Canada Strategic Reference Model (GSRM) [2].
Future research efforts will concentrate on the development of the successor of the current UMM standard - UMM 2.0. At the time when UMM 1.0 was developed the support for UML 2.0 in modeling tools was poor. However today
MODELING EGOVERNMENT PROCESSES WITH UMM
Informatica 31 (2007) 407-417 409
UML 2.0 is state of the art and therefore UMM 2.0 will be based on UML 2.0. Current research is also conducted in the field of business document modeling. The current version of the UMM Add-In supports the Core Component Technical Specification 2.01. The next version of CCTS (3.0) is currently under development. It is planned that future versions of the UMM Add-In support the latest CCTS standard as well.
During the We-Go project UMM will be used to model eGovernment processes in the Western Balkan Region. Valuable feedback from this usage will be used to further improve the UMM and its tool support. Lessons learned from finished UMM projects will be analyzed and suggested changes will be introduced in UMM 2.0.
References
[1]	GovDex Framework. http://www.govdex.gov.au.
[2]	Governments of Canada Strategic Reference Model. http://www.tbs-sct.gc.ca/index_e.asp.
[3]	We-Go EU project. http://www.wego-project.eu, Proposal No 045472, Contract No 045472.
[4]	XOV Framework. http://www.osci.de (german).
[5]	BEA, IBM, Microsoft, SAP AG and Siebel Systems. Business Process Execution Language for Web Services, May 2003. Version 1.1.
[6]	eCo Working Group. eCo Architecture for Electronic Commerce Interoperability, 1999.
[7]	B. Hofreiter and C. Huemer. Transforming UMM Business Collaboration Models to BPEL. In Proceedings of OTM Workshops 2004, volume 3292, pages 507-519. Springer LNCS, 2004.
[8]	B. Hofreiter, C. Huemer, and J.-H. Kim. Choreography of ebXML business collaborations. Information Systems and e-Business Management (ISeB), June 2006.
[9]	B. Hofreiter, C. Huemer, P. Liegl, R. Schuster, and M. Zapletal. Deriving executable BPEL from UMM Business Transactions. In Proceedings of the 2007 International Conference on Services Computing, pages 178-186. IEEE, 2007.
[10]	ISO. Open-edi Reference Model, 2004. ISO/IEC JTC 1/SC30 ISO Standard 14662, Second Edition.
[11]	H.Kim. Conceptual Modeling and Specification Generation for B2B Business Processes based on ebXML. In SIG-MOD Rec., vol. 31, no. 1, pp. 37-42, 2002.
[12]	B. Korherr and B. List. Extending the UML 2 Activity Diagram with Business Process Goals and Performance Measures and the Mapping to BPEL. In Proceedings of the ER-Conference on Conceptual Modeling (Workshop BP-UML'06). Springer, Nov. 2006.
[13]	G. Kramler, E. Kapsammer, G. Kappel, and W. Retschitzeg-ger. Towards Using UML 2 for Modelling Web Service Collaboration Protocols. In Proceedings of the First International Conference on Interoperability of Enterprise Software and Applications (INTEROP-ESA'05), Feb. 2005.
[14]	B. List and B. Korherr. A UML 2 Profile for Business Process Modelling. In ER 2005 Workshop Proceedings, 2005.
[15]	R. J. Mayer, P. C. Benjamin, B. E. Caraway, and M. K. Painter. A Framework and a Suite of Methods for Business Process Reengineering. Business Process Reengineering: A Managerial Perspective, pages 245-290, 1995.
[16]	OASIS, UN/CEFACT. ebXML - Technical Architecture Specification, February 2001. Version 1.4.
[17]	Object Management Group (OMG). Unified Modeling Language Specification, Apr. 2005. Version 1.4.2, http://www.omg.org/docs/formal/05-04-01.pdf.
[18]	OMG - Object Management Group. Business Process Modeling Notation Specification 1.0, 2006.
[19]	M. Penker and H.-E. Eriksson. Business Modeling With UML: Business Patterns at Work. Wiley, 2000.
[20]	RosettaNet. RosettaNet Implementation Framework: Core Specification, December 2002. V02.00.01.
[21]	A.-W. Scheer. ARIS - Business Process Modeling. Springer, 2000.
[22]	S. Tyndale-Biscoe, O. Sims, B. Wood, and C. Sluman. Business Modelling for Component Systems with UML. In Proceedings of the Sixth International Enterprise Distributed Object Computing Conference (EDOC'02. IEEE Press 2002, 2002.
[23]	UN/CEFACT. Electronic Data Interchange, September 2006. D.06A.
[24]	UN/CEFACT International Trade and Business Process Group (TBG14). UN/CEFACT Common Business Process Catalog, Nov. 2003. Version 0.95.
[25]	UN/CEFACT Techniques and Methodologies Group. UN/CEFACT's Modeling Methodology (UMM), UMM Meta Model - Foundation Module, Oct. 2006. Technical Specification, http://www.unece.org/-cefact/umm/UMM_Foundation_Module.pdf.
[26]	UN/CEFACT TMG. Core Components Technical Specification - Part 8 of the ebXML Framework, November 2003. v2.01.
[27]	UN/CEFACT TMG. UN/CEFACT - ebXML Business Process Specification Schema, 2003.
[28]	UN/CEFACT TMG. BCSS - UML Profile for Core Components based on CCTS 2.01, October 2006. Candidate for version 1.0.