Shorter life cycles of products and services require faster changing business models. Information systems must quickly adjust to the adapted business models. Business models are usually described by their own proprietary notation, which is incompatible with UML - the de-facto modeling standard in software engineering. In order to allow a straight-through modeling approach from business models over business process models to software artifacts, it is desirable to use a common modeling approach. Thus, we suggest to map existing concepts to describe business models onto the UML notation. In our work we mainly focus on inter-organizational systems. A promising approach describing a business model for an inter-organizational network of actors is delivered by e3-Value. In this paper, we present a discussion of di erent approaches to represent the e3-Value concepts by means of UML. A UML notation for e3-Value is a precondition to future work on aligning e3-Value to UMLbased approaches specifying inter-organizational business processes.
Service-oriented Architectures (SOA) are said to provide a means of quickly
adapting IT to changing business needs. However, most approaches focus only on
the IT layer. Instead, we propose an integrated approach for inter-organizational
systems spanning from business models over business process models to their
execution in a SOA. An integrated approach starts with analyzing the economic
drivers for a business collaboration. This means describing the business models
in terms of economic values that are exchanged between business partners.
Candidate approaches to be used on this level of abstraction are e3-Value [
In order to guarantee that each partner deserves its economic value they have
to agree with each other on the inter-organizational business processes to realize
the value exchanges. A resulting global choreography may be described by the
UN/CEFACT modeling methodology (UMM) which is speci cally designed for
this purpose [
In order to allow a straight-through modeling approach, it is desirable to base the di erent steps in developing inter-organizational systems on a single modeling paradigm. Most of the steps described above are already based on UML. This means they customize the general purpose language UML by means of stereotypes, tagged values and constraints for their speci c purpose. Only the de nition of the value exchanges is not based on UML. Thus, the de nition of the UML pro le for value exchanges completes an overall UML based approach for inter-organizational systems. Since the e3-Value approach speci cally targets business models in an inter-organizational environment, it is our goal to transform its concepts to a UML pro le. In this paper we discuss di erent options for representing e3-Value in UML. A UML-based e3-Value notation is a precondition to seamlessly integrate it with the UMM. However, a detailed analysis of this integration is out of scope for this paper and is up to future work. 2 2.1 e3-value at a glance
Basic concepts
e3-Value is an ontology-based methodology for modeling and designing business
models for business networks [
The e3-Value ontology de nes a number of concepts that will be brie y
outlined in this section. The concepts are described in more detail in [
Actors represent parties engaged in a value exchange. They are considered as independent economic entities that strive for pro tability (in case of an enterprise) or maximizing their economic utility (in case of an end-consumer) by carrying out value activities. These pro table or utility-increasing value activities are intended to be directly and unambiguously assigned to the corresponding actors. By conducting value activities actors exchange value objects that are valuable to one or more actors of the business network. As mentioned before, these objects are "things of value" - either material, such as physical goods, products or money, or non-material (e.g. services, capabilities or experience).
Actors signal their will to provide or request value objects through interfaces. In the e3-Value ontology these interfaces are called value ports. The rationale of value ports is to abstract from an actor's internal processes and instead concentrate exclusively on the external connection to other business partners (i.e. actors) and other components. Two value ports are connected to each other via a value exchange. The latter depicts one or more potential trades of value objects between value ports. The values o ered to or requested from the environment are represented by so-called value o erings, representing sets of equally directed value ports. The concept of value o erings allows the mapping of "object bundling" in case that objects are of value and can be requested or provided only in combination. This means that an o ering may consist of several value object s to be exchanged. One or a maximum two value o erings - in general one incoming and one outgoing - are subsumed by a value interface typifying the concept of economic reciprocity and showing which value object is o ered in return for another. Each actor may have multiple value interfaces grouping individual value ports. The exchange of values is atomic - i.e., value objects in an o ering are exchanged through the value interface on all of its value ports (each exchanging exactly one value object ) or none of them.
For creating appropriate visual representations of the value models a graphical notation is provided - the stated elements are represented in gure 1.
For creating appropriate visual representations of the value models a graphical notation is provided; the stated elements are represented in Figure 1.
Actor
AVcatilvuiety InVtearlfuaece VPaolrutse ExVcahlaunege with OVbajelucets
Payment
Goods foArkN/jDoin forOk/Rjoin StSimtaurltus StiSmtouplus 2.2
In this subsection we demonstrate the e3-Value concepts by means of an example from the waste management domain. We consider the international - i.e. crossborder - trading of waste. In this case study waste is traded between an exporter and an importer. In principle we must distinguish two di erent kinds of trading. In the majority of cases the exporter has to pay the importer for the waste handling, i.e. for the recovery or disposal of the waste. Accordingly, waste and money is given to the importer and the exporter gets the service of waste handling in return. In the minority of cases, the waste is traded like a regular good. The trading of re-cycled paper is a typical example of such a case. This means the importer has to pay for the waste. In other words the importer gets the waste, and the exporter receives money in return.
Moreover, the international trading of waste has some legal implications. Competent authorities in the countries of the exporter and the importer control the trading. Accordingly, the exporter has to inform the export authority about a waste transport. The exporter delivers relevant environmental information about the transport and the export authority issues a transport allowance in return. The value of a transport allowance is considered equally to ful ll the legal regulations and, thus, to avoid possible nes. Similarly, the importer has to provide environmental information about the transport to the import authority in order to get the transport allowance for importing the waste. The export authority and the import authority have a natural interest in providing each other with the relevant environmental information collected on each side. Thereby, both competent authorities are able to obtain the full information about the waste transport on each side. [Environmental Information] [TransportAllowance]
Exporter [Environmental Information] [TransportAllowance]
Importer Request Waste Transport
Receive Waste Request Waste Transport Transfer Waste
[Waste] [Waste Handling]
[Waste]
This section focuses on mapping the e3-Value concepts to a UML pro le. In
addition to a prose description of the concepts, e3-Value comes with a MOF-like
meta model specifying the concepts and the relations between them (c.f. [
A mapping to a UML pro le is not straightforward due to the signi cant di erences between the e3-Value meta model and the UML meta model. Since UML originates from software engineering, none of the UML standard diagrams has originally been intended to capture e3-Value semantics. It is necessary to analyze which of the existing UML standard diagrams and corresponding model elements are best suited for a customization towards UML. In the following subsections we discuss ve di erent alternatives by means of the waste management example and state their strengths and shortcomings. 3.1
Value activities are a cornerstone of e3-Value. At a rst glance it seems to be consequent to map them to activities and activity diagrams, respectively. A possible solution for the waste management scenario based on activity diagrams is depicted in Figure 3.
Each e3-Value actor results in a UML activity partition assigned to a corresponding UML actor. The activity partition shows his area of responsibility. In the waste management example the activity diagram includes four activity partitions for the following actors: exporter, export authority, import authority, and importer. Each value activity is mapped to a UML activity showing the stereotype value activity. In the waste management example, each party performs an activity request waste transport. Furthermore, the exporter performs transfer waste and the importer performs receive waste.
We use UML activity parameters to model value exchanges. An activity parameter describes the input or output to/from a UML activity. It follows, that an o ering activity carries an output parameter, whereas a consuming activity carries an input activity. The ow of a value object is described by an exchange from the output parameter to the input parameter. The value object itself is a stereotype based on the UML metaclass class. This value object is assigned to both, to the input parameter and to the output parameter. To illustrate these concepts we take a look at the value exchanges between the exporter and the export authority on the left hand side of gure 3. The value exchanges are realized between the activities called request waste transport on each partner's side. The value object environmental information is assigned to the output parameter of the exporter's activity as well as to the input parameter of the export authority's activity in order to realize the value exchange from the exporter to the export authority. The ow of the value object transport allowance goes the other way round.
A major drawback of this variant is the fact, that it lacks the concepts of value ports and value interfaces. These concepts are required to group value exchanges for denoting the atomicity of a set of value exchanges. There is no concept in UML activity diagrams that corresponds to an e3-Value value port. For representing value interfaces one might think of UML parameter sets to group multiple parameters. However, the semantics of a parameter set allow to group either input or output parameters, but does not allow a mix of input and output parameters. Furthermore, multiple parameter sets of the same activity are in an XOR relationship with each other - which does not correspond to the e3-Value semantics. Due to these two reasons, UML parameter sets do not t the requirements of our mapping. A workaround denoting the atomicity of two or more value exchanges is attaching a constraint to the respective object ows. In gure 3 we de ned such a constraint - mandating an AND relationship between the value exchanges of the exporter and the export authority. For the sake of readability we refrain from showing this kind of constraint between other value exchanges in gure 3.
For mapping e3-Value scenario paths we utilize the pseudo states for modeling ows in UML activity diagrams. The start stimulus and the stop stimulus of e3-Value are mapped to UML initial and nal states, respectively. The AND fork/joins are mapped to the UML concepts of fork/joins, whereby e3-Value OR fork/joins correspond to UML decisions/merges in our mapping. In gure 3, the decision node within the transfer waste activity of the exporter indicates a choice of two di erent scenarios: either exchanging waste for money or exchanging waste and money for the service of waste handling. Similarly, the fork node immediately after the initial state denotes that the exporter must conduct a value exchange with the export authority (environmental information against transport allowance) and a value exchange with the importer as explained above.
It is important to note that a scenario path does not specify a control ow amongst the activities nor does it mandate any sequences in time. In order to stress this fact we refrain from using the UML connector type control ow. Instead, we use the concept of a trace - a stereotyped UML dependency - to describe the scenario paths. Usually a trace should lead to a value interface. Since the concept of a value interface cannot be represented in this variant a trace leads to any value port being part of a set of value ports that are graphically grouped to a value interface. 3.2
The boundaries variant is somewhat similar to the activity parameter variant. It is also based on UML activity diagrams. The representation of e3-Value actors and e3-Value value activities still remains the same. However, as shown in gure 4 value exchanges are modeled using the UML object node notation instead of the activity parameter notation. In other words, the exchange of a value object is modeled by an object ow starting from the o ering activity to the value object modeled as object node leading to the consuming activity. Although the seman:EnvironmentalInformation :TransportAllowance
:EnvironmentalInformation :TransportAllowance :ExportAuthority «ValueActivity» Request Waste Transport :Exporter «ValueActivity» Request Waste Transport «ValueActivity» Transfer Waste tics is the same as in the activity parameter variant, the object node notation allows grouping the exchanged value objects. We use the concept of interruptible regions provided by UML for describing the atomicity of value exchanges being part of a value scenario - e.g., the exchange of transport allowance in return to environmental information between the exporter and the export authority. In activity diagrams, interruptible regions usually denote boundaries for exception handling. Nevertheless, we are able to use boundaries to express the semantics of economic reciprocity of two or more value exchanges.
The usage of interruptible regions results in a big drawback. Since interruptible regions must not be the source or the target of any UML connector, we are not able to represent scenario paths. Similar to the activity parameter variant, the inability to represent the e3-Value concepts of value ports and value interfaces is a major shortcoming. Although the boundary variant bene ts from compact and simple diagrams, it is inadequate for describing more complex e3Value scenarios. 3.3
The interface variant is also based on UML activity diagrams, but provides
another solution for value exchanges. As shown in gure 5 this solution makes
use of UML interfaces. A value interface is a stereotyped UML interface that
is now used to bind value exchanges to an atomic unit. A value activity may
have one to many value interfaces - each connected with a UML dependency.
According to our example in gure 5, the exporter has a total of three value
interfaces. One is bound to request waste transport, the remaining two are
bound to the value activity transfer waste. A value exchange between two value
interfaces is described by the UML concept of an information ow. Information
ows describe circulation of information in a system in a general manner [
The interface variant also provides scenario paths - described by similar concepts as introduced for the activity parameter variant. Although the de nition of this variant lacks the explicit notion of value ports, it is the rst mapping variant described so far that allows for modeling implicitly all e3-Value concepts by means of UML. In terms of value ports, UML purists might correctly argue, that the concept of a connector end as de ned in the UML meta model corresponds to a value port in e3-Value. However, for the sake of simplicity - and since connector ends are not supported by most UML tools - we refrain from stereotyping the connector ends of an information ow as a value port. «ValueInterface» «ValueO«bfjleocwt»» Waste «ValueInterface» «ValueObject» Money
«flow» «ValueObject» WasteHandling «ValueInterface» «ValueO«fblojewc»t» Waste «ValueInterface»
«flow» «ValueObject» Money
«flow» :ExportAuthority :ImportAuthority Similar to the interface variant, the signal variant (c.f. gure 6) covers all e3Value concepts. However, it di ers from the interface variant in terms of modeling value interfaces and value ports. In the signal variant, value interfaces are represented as stereotypes based on UML activities. Value interfaces are modeled as child elements of the value activity they belong to.
As shown in our waste management example in gure 6, we place the value interfaces inside of the value activities. Unlike in the interface variant, value ports are modeled explicitly using the concept of UML signals. We use send signal actions to indicate outgoing value ports and receive signal actions for representing incoming value ports. Each signal action - no matter if incoming or outgoing - is stereotyped as a value port. As we know from e3-Value , value ports must be part of exactly one value interface. Correspondingly, we place the stereotyped UML signals within the value interfaces they are part of.
The concepts for representing value exchanges and scenario paths look alike the ones used in the interface variant. Value exchanges are described using information ows. The value object that is conveyed through the value exchange is assigned as the information ow's classi er. For de ning the scenario path we apply the concept of the trace dependency combined with some elements borrowed from UML diagrams in order to describe AND and OR fork/joins. :ExportAuthority
:ImportAuthority «ValueActivity» Request Waste Transport «ValueInterface» «ValuePort»
«ValueActivity»
Request Waste Transport «EVnvailruoenO«mfbleojenwct»at»lInformation«Va«luVeaI nluteerPfoarct»e» «ValuePort»
«flow» «ValueObject»
EnvironmentalInformation
The signal variant provides the user with all e3-Value concepts when using UML for business modeling. Some UML purists may disagree with the nested UML activities and actions in order to model value ports and value interfaces of a value activity. Those nested activities - missing start and end nodes - do not result in a well de ned sequence of activity ows. However, this is a result of the di erent semantics of ows in e3-Value and in UML activity diagrams.
In order to overcome the incompliance in the ow semantics between e3-Value and UML activity diagrams, we propose another solution based on UML use case diagrams (c.f. gure 7). An e3-Value actor is again represented by a UML actor.
ExportAuthority An actor may be connected to one or more use cases representing value activities.
Thus, each use case gets the stereotype value activity assigned. Considering our example in gure 7, we model four business partners named exporter, export authority, import authority and importer. Each business partner is connected to his stereotyped value activities. For example, the exporter is associated with two use cases - request waste transport and transfer waste - both stereotyped as value activity.
In order to represent the value interfaces of a value activity we use UML
ports. According to the UML2 speci cation, ports represent interaction points
between a classi er and its environment [
Consider the value activity transfer waste of our example: This use case has two ports representing its value interfaces. One port shows the exchange of waste and money in return to waste handling. Thus, this port de nes three port interfaces - two providing ones indicating that waste and money is transfered to the value activity receive waste and one interfaces consuming the service of waste handling. The other port of transfer waste has two interfaces - one provides waste and the other one consumes money in return.
The value exchanges between the ports and their interfaces are described like in the interface and signal variant. We denote them by information ows leading from providing interfaces to consuming interfaces. The classi er of this information ow corresponds to the value object sent in this value exchange. Scenario paths are again described by the concept of a trace dependency. We use trace dependencies to describe possible paths of value interfaces with UML pseudo states representing AND/OR fork and joins.
In summary, we prefer the use case variant for mapping e3-Value models to UML. It results in comprehensible business models representing the whole set of e3-Value semantics. In addition, the use case variant is fully compliant to the UML meta model. Furthermore, e3-Value is a method for requirements gathering and will be used as such as part of the UMM. In the UML - and also in the UMM - the concept of a use case serves as a mean for eliciting the requirements of a system. Thus, it is reasonable to model e3-Value concepts by means of use case diagrams rather than by activity diagrams. 4
There have been a lot of di erent approaches to model business by means of
UML. However, most of the processes focus on modeling business processes. A
good evaluation of di erent approaches of modeling business processes by means
of UML activity diagrams is provided in [
In the research eld of ontology-based e-business modeling other
non-UMLbased concepts, similar to e3-Value, have been proposed in the past. The REA
(Resource-Event-Agent) business model ontology evolved from a generalized
framework for modeling accounting information systems [
The identi cation of the objects of value exchanged within a business network
is not always straightforward. In our example, participants exchange documents
ful lling legal regulation and avoiding nes. These documents are objects of
value. A discussion about the notion of value objects is given in [
Further ontological approaches comprise the AIAI Enterprise Ontology [
The contribution of this paper are ve di erent variants for de ning a UML pro le for e3-Value. UML is considered as the "lingua franca" in software engineering. However, UML lacks standardized means for describing business models from a value perspective. e3-Value - an approach for value-based requirements engineering - is an ideal complement for designing e-business systems with UML.
When mapping e3-Value to UML we had to consider two somewhat con icting aspects: On the one hand side, all e3-Value concepts should also be present in a corresponding UML pro le. On the other hand side, resulting UML diagrams must be easily understood by business experts with limited UML knowledge. Inasmuch these diagrams must not be overloaded. In our research work, we started o with a mapping towards activity diagrams that include value activities with input/output parameters. At rst glance, this solution seemed to be the obvious choice, since the resulting diagram results in the same look and feel as e3-Value diagrams. Unfortunately, not all e3-Value concepts may be mapped in this solution. So we continued with developing alternative variants based on activity diagrams. However, we learned that all the proposed solutions either fail in mapping all e3-Value concepts or result in overloaded diagrams that are hard to read for business people.
Finally, we based the UML pro le for e3-Value on use case diagrams. We prefer this solution to the ones based on activity diagrams. It also provides a better integration with the UN/CEFACT modeling methodology (UMM) which serves as a starting point of our research. Being editors of the UMM speci cation - which is de ned as a UML pro le for inter-organizational systems - we are looking for an approach that captures the business justi cation for interorganizational systems. We believe that the UML pro le for e3-Value satis es these needs. Due to page constraints we were not able to outline the dependencies between UMM and e3-Value. Accordingly, a detailed description of integrating e3-Value into UMM is up to future work.
A UML pro le for e3-Value may be used in any UML based software development process and not just in relationship with UMM. Others may prefer a di erent variant according to their speci c needs. Whatever variant is chosen users bene t from our work since they are able to use standard UML tools for modeling e3-Value. We are convinced that this further potentiates the di usion of e3-Value due to a better integration into the software engineering process.