A UML Profile for Enterprise Ontology
José Cordeiro
, Joaquim Filipe
and Kecheng Liu
EST Setúbal/IPS, Rua do Vale de Chaves, Estefanilha
2910-761 Setúbal, Portugal
j.cordeiro@computer.org, j.filipe@est.ips.pt
The University of Reading, Whiteknights, Reading, RG6 6AF, U.K.
Abstract. Enterprise Ontology (EO) is a new subject that applies the Ψ-theory
to the development and conception of social information systems. This theory,
proposed by Jan Dietz, is based on the Language Action Perspective. In order
to model an enterprise this theory presents a modelling method composed by
four distinct aspect models, which use a collection of tables and diagrams to
express themselves. A domain specific language was supplied for those dia-
grams that it is not standard or easily portable. In order to make these diagrams
more useful and available this paper proposes the use of the Unified Modelling
Language (UML) to represent EO most important diagrams where the EO main
concepts are shown. The use of UML will bring some important benefits such
as portability, interoperability, wider audience and understanding among oth-
ers. In this sense a UML 2 profile has been created for representing the dia-
grams mentioned. An example of application of this profile is shown and an ex-
tended discussion of its creation is made. This will address the difficulties and
issues found when metamodelling the solution using UML and will help to as-
sess the feasibility of UML for this kind of problems.
1 Introduction
The Ψ-theory proposed by Jan Dietz [2] provides the foundations for designing and
engineering of enterprises seen as social information systems. This theory captures
the stable essence of any organization by focusing on commitments and the way peo-
ple interact using language. This focus on language rather than material actions or
technology comes from the Language Action Perspective view of the world (see, for
example, [14]) in which it is based. The Ψ-theory comprises a modelling method
composed by four distinct aspect models: the construction model, the process model,
the action model and the state model. A methodology named “Design and Engineer-
ing Methodology for Organizations” (DEMO) is the basis for this modelling method
[2], [3]. As many modelling methods, a few diagrams are used as a way of expres-
sion. Because these diagrams constitute the main communicational mean for repre-
senting the structure of the enterprise according to the Ψ-theory we are interested in
include these diagrams together with other diagrams in information system develop-
ment projects. This is not easy due to the proprietary language used by these diagrams
and its lack of interoperability with other modelling languages. Also a formal verifi-
Cordeiro J., Filipe J. and Liu K.
A UML Profile for Enterprise Ontology.
DOI: 10.5220/0004464500070020
In Proceedings of the 2nd International Workshop on Enterprise Systems and Technology (I-WEST 2008), pages 7-20
ISBN: 978-989-8111-50-0
2008 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved
cation is not automatically made and there are only a small number of tools to work
with those diagrams. To overcome these problems we propose to use the Unified
Modelling Language (UML), to express the most important diagrams of those mod-
els. UML is today a de facto standard widely used for modelling purposes, having
numerous tools available and its use will bring us some important benefits such as:
A wider audience will be able to use and understand the diagrams.
Diagram interoperability and inclusion in software projects
Formal representation and automatic verification of the diagrams
In this sense this paper presents and proposes a new UML 2 profile for representing
those different types of diagrams. The difficulties and issues raised in the profile
creation will also be the focus of this work because they will show the feasibility and
the problems of using UML for such purposes.
This paper is organised as follows: section 2 presents related work, section 3 summa-
rizes the main concepts of Enterprise Ontology (EO), the proposed UML Enterprise
Ontology profile will be shown and exemplified in section 4, section 5 will present
issues and rationale related to the EO profile development and finally, conclusions
will be given in section 6.
2 Related Work
We found just a small number of papers that refer to the use of UML with DEMO. In
[13], Shishkov and Dietz suggest using DEMO to derive UML use cases. In this work
a mapping from DEMO Business Transactions to UML Use Cases is proposed. In
fact there is a general tendency to separate the use of DEMO and UML. For example,
in [7] DEMO is used to model the business processes prior to information systems
modelling using UML. Nevertheless, the most significant work relating UML and
DEMO is [11]. In this paper instead of a direct UML representation it is proposed a
language mapping between DEMO models and UML. This mapping is accomplished
in three phases: first a concept mapping between both languages is made, next a nota-
tional mapping is performed and at last there is a diagram transformation. In fact, a
similar approach is taken when we create the UML profiles as we will see. In UML
profiles concept matching is used to find the appropriate metaclasses corresponding
to the DEMO model elements, also a notational option is taken for the created stereo-
types and finally some new diagrams are created for showing the new model ele-
ments. Even so according to this paper it will be necessary to have the original
DEMO diagrams instead of a direct UML representation as we pretend.
Regarding UML profiles much work has been done and some references will be
pointed afterwards when appropriate.
3 Enterprise Ontology
Enterprise Ontology (EO) captures the essential aspects of any organization by focus-
ing on the ontological level of business where people interact, commit themselves and
Fig. 1. The Basic Transaction Pattern (adapted from [3]).
produce results. At this level people use language acts as the driver of any business
transaction or coordination acts. EO is about the construction and operation of an
organization. The Ψ-theory establishes the basis and the theoretical support for EO.
The Ψ-theory is composed by four axioms and one theorem. The first axiom – the
Operation Axiom – presents an organization as a group of actors performing two
kinds of acts: coordination acts (C-acts) and production acts (P-acts). C-acts are lan-
guage acts used by actors to engage themselves in commitments and to ultimately
originate the P-acts responsible for producing the effective work. The result of per-
forming a C-act is a coordination fact (C-fact), whereas the result of performing a P-
act is a production fact (P-fact) or production result. The second axiom – the Transac-
tion Axiom – comes from the observation that P-acts and C-acts seems to occur in a
universal pattern called transaction. This transaction is a key concept of the Ψ-theory
and EO. The complete transaction pattern is seen as a socionomic law that underlies
the conducting of any business always and everywhere. This transaction has its roots
in the notion of conversation for action [14] and the Workflow Loop [8] both from
the Language Action Perspective. In fig. 1 we depict the basic transaction pattern
which has three phases: an order phase where the negotiation about the P-act to be
executed takes place. In this phase two types of C-acts are usually performed: a re-
quest by the initiator actor and a promise to accomplish it by the executor actor. The
next phase is the execution phase where the P-act is actually performed. Finally, the
result phase ends the transaction with the performance of a C-act stating the comple-
tion of execution of the P-act by the executor actor and a C-act by the initiator actor
accepting the result. The third axiom – the Composition Axiom – is concerned with
the interrelation of P-facts in a production world (the P-world). In particular the en-
closing relationship between transactions is analysed. Finally, the fourth axiom – the
Distinction Axiom – is about the human abilities that have a significant role in per-
forming C-acts namely the performa, informa and forma abilities. The performa abil-
ity is considered the essential human ability for doing business and is part of the onto-
logical level of EO. The Organization Theorem completes the Ψ-theory by stating
that “the organization of an enterprise is a heterogeneous system that is constituted as
the layered integration of three homogeneous systems: the B-organization (from busi-
ness), the I-organization (from intellect), and the D-organization (from Document)”
[2, p.115].
Fig. 2. The four DEMO aspect models (adapted from [2]).
For designing and engineering organizations EO is supported by the DEMO meth-
odology. The DEMO methodology defines the required steps for that purpose and
uses a modelling method composed by four distinct aspect models: the construction
model, the process model, the action model and the state model that together consti-
tutes the complete ontological knowledge of an organization (fig. 2). The construc-
tion model (CM) specifies transactions types, associated actors roles and information
banks (conceptual stores of C-facts or P-facts). The CM is divided in two similar
models: the interaction model (IAM) and the interstiction model (ISM) that shows us
respectively the active and the passive influences between actor roles. The process
model (PM) details the CM by showing the specific transaction patterns for each
transaction type in the CM. The action model (AM) is the most detailed level and it
specifies the action rules that serve as guidelines for the actors. The last model, the
state model (SM) specifies the state space of the P-world. It includes object classes,
fact types, result types and ontological coexistence rules. In general these models are
expressed by different diagrams and tables. Table 1 show us the different diagrams
and tables used by each of them and what they depict. As it is shown the AM doesn’t
use any diagram and the SM uses a very specific type of diagram that doesn’t pre-
sents directly the main concepts of EO, namely the transaction types, and we decided
not to represent them using UML. Thus, in this work we will be interested in provide
UML diagrams to mirror the following diagrams: ATD, PSD and ABD.
4 The Enterprise Ontology Profile
In figure 3 a part of the metamodel for the UML Profile created for EO is presented.
In this metamodel it is shown the equivalent UML elements for the DEMO Actor
Transaction Diagram (ATD) elements. The corresponding stereotypes and constraints
for this profile are detailed in table 2. Discussion of the creation of the complete pro-
file is made in the next section.
Table 1. DEMO aspect models.
Model Expressed by Typical contents
Actor Transaction Diagram (ATD)
Actor roles, transaction types and
their connecting links
Transactions Result Table (TRT) Transaction and result types
Process Structure Diagram (PSD)
C-act/C-result, P-act/P-result, causal
and conditional links and responsibil-
ity areas of actor roles
Information Use Table (IUT)
Process steps and object class, fact
types or result types
Action Action Rule Specifications (ARS) Action rules
Object Fact Diagram (OFD)
Object classes, fact types, result
types and existential laws
Object Property List (OPL) Property types, object classes, scales
Actor Bank Diagram (ABD)
Information banks, actor roles and
information links
Bank Contents Table (BCT)
Object classes, fact types, result
types and production banks
Table 2. EO stereotype definitions part 1 – ATD elements.
Name TransactionType
Extended Class Class Notation
Description Represents the transaction type concept.
Constraints ------
Notes The name of the transaction should be a capital T
followed by the transaction number (ex: T02 )
Name Actor Role
Extended Class Class
Description Represents the elementary actor role concept.
Constraints ------
Notes No special notation. Usually it is shown as a rectangle with the actor role name
inside. The actor role name should be a capital A followed by the actor role
number (ex. A02)
Name CompositeActorRole
Base Class ActorRole Notation
Description Represents the composite actor role concept.
As a class but filled
using a gray colour
Constraints ------
Notes The actor role name should be the capitals CA followed
by the actor role number (ex. CA03)
Name ActorRoleLink
Extended Class Association
Description A relationship between an actor role and a transaction type
Constraints 1) It is a binary association
2) Must connect a TransactionType and an ActorRole element
3) It is an abstract metaclasse
Name InitiatorLink
Base Class Actor RoleLink
Description A special kind of an ActorRoleLink that connects an ActorRole and a
TransactionType where the ActorRole plays the role of the initiator of the
Constraints ------
Notes Usually no adornments are shown.
There is an implicit navigation from the actor role to the transaction.
Table 2. EO stereotype definitions part 1 – ATD elements(cont).
Name ExecutorLink
Base Class Actor RoleLink Notation
Description A special kind of an ActorRoleLink that connects
an ActorRole and a TransactionType where the
ActorRole plays the role of the executor of the
The line end with
the black square
must be connected
to the actor role
Constrains ------
Notes There is an implicit navigation from the
transaction to the actor role.
Name Organization
Extended Class Package Notation
Description Represents a group of actor roles and transaction
types which belong and take place inside an
Constrains ------
Notes The name of the package is placed upon its upper
boundary line
A special UML diagram – the AT diagram – one of diagrams which we
propose for this profile is a special case of a UML Class diagram. This dia-
gram is used for showing actor roles and transaction types and the links be-
tween them and mimics the original DEMO ATD. In figure 4 an example of
an ATD is given and in figure 5 the same diagram is reproduced with the EO
profile applied to it.
Fig. 3. Example of the DEMO ATD of a pizzeria (adapted from [2]).
Fig. 4. An UML AT Diagram applied to the pizzeria example using the EO Profile.
Fig. 5. EO profile metamodel part 2 - UML representation of PSD elements.
In figure 6 it is shown the second part of the EO profile which includes
the equivalent UML elements for the DEMO Process Structure Diagram
(PSD) elements. The corresponding stereotypes and constraints for this profile
are detailed in table 3.
Table 3. EO Profile stereotype definitions part 2 – PSD elements.
Name CoordinationAct
Extended Class Action Notation
Description Represents the C-act concept.
Constraints ------
Notes Just one symbol meaning the combination of a C-
act with a C-result
Name ProductionAct
Extended Class Action Notation
Description Represents the P-act concept.
Constraints ------
Notes Just one symbol meaning the combination of a P-
act with a P-result
Name ResponsibilityArea
Extended Class ActivityPartition Notation
Description Represents the responsibility area concept
Constraints isDimension = true
Notes It will not be possible to have nesting of actor
roles because each actor role establishes a unique
Table 3. EO Profile stereotype definitions part 2 – PSD elements(cont).
Name CausalLink
Extended Class ControlFlow
Description A link used to show the control flow between C-act and P-acts.
Constraints ------
Notes It is equivalent of the causal link
Name Activation
Extended Class InitialNode
Description It represents the start of a process. It can be placed inside a Responsibility Area
meaning self activation or outside meaning external activation.
Constraints ------
As in the case of the AT Diagram a new UML diagram – the Process Structure
Diagram - was created to show DEMO PSD using UML. This diagram is a special
case of a UML Activity Diagram. Unfortunately UML diagrams are not part of the
main specification of UML, they are not model elements, therefore we have to intro-
duce these diagrams informally and it will not be possible to formalize some aspects
of the diagrams, for example positioning rules for the included elements. An example
of a PSD is given in figure 7. In figure 8 it is shown a UML PS diagram with the EO
Profile applied.
Fig. 6. An UML PS Diagram applied to the pizzeria example using the EO Profile.
Figure 9 shows the third and last part of the EO profile which includes the equiva-
lent UML elements for the DEMO Actor Bank Diagram (ABD) elements. The cor-
responding stereotypes and constraints for this profile are detailed in table 4. Also a
new UML diagram – the Actor Bank Diagram - is proposed for representing the
DEMO ABD. This diagram is also a special case of a UML Class Diagram. This
diagram is very similar to the ATD.
Fig. 7. Example of the DEMO PSD of a pizzeria (adapted from [2]).
Fig. 8. EO profile metamodel part 3 - UML representation of ABD elements.
Table 4. EO Profile stereotype definitions part 3 – ABD elements.
Name InformationBank
Extended Class Class
Description A production or a coordination bank.
Constraints ------
Name CoordinationBank
Base Class InformationBank Notation
Description Represents a coordination bank
Constraints ------
Notes The coordination bank name should be the capitals CB
followed by the bank number (ex. CB02)
Name CompositeCoordinationBank
Base Class CoordinationBank Notation
Description Represents a composite coordination bank
Constraints ------
Notes The composite coordination bank name should be the
capitals CCB followed by the bank number (ex. CCB02)
Name ProductionBank
Base Class InformationBank Notation
Description Represents a production bank
Constraints ------
Notes The production bank name should be the capitals PB
followed by the bank number (ex. PB03)
Name CompositeProductionBank
Base Class ProductionBank Notation
Description Represents a composite production bank
Constraints ------
Notes The composite production bank name should be the capitals
CPB followed by the bank number (ex. CPB04)
Name InformationLink
Extended Class Association Notation
Description A connection relating actor roles and information banks
Constraints 1) It is a binary association
2) Must connect an InformationBank and an ActorRole
5 EO Profile Creation
If we want to have the benefits of using UML tools such as model interchange, model
validation and model storage it is necessary to create UML Profiles instead of a com-
plete metamodel for representing the DEMO diagrams. Thus, and in order to build
these profiles we should follow some guidelines (see for example [4]). In a general
and simple view these guidelines recommend to create first a domain metamodel, to
choose from this metamodel the relevant elements, to extend the appropriate UML
metamodel elements with some of those elements and to define additional constraints
and tagged values (see [12]). In our case we found as not necessary to create the do-
main metamodel because we already have the domain elements which correspond to
the DEMO diagram elements. In spite of skipping this step and although simple the
remaining process it has many issues, difficulties and compromises specially because
we are metamodeling non object-oriented theories. In the next sections some of the
issues and problems found for each DEMO diagram will be reported. It should be
also noted that the EO UML profile that was created uses version 2.1.2 of the UML
superstructure and infrastructure specifications [9], [10].
5.1 Development Issues - AT Diagram
The ATD diagram shows mainly actor roles, transaction types and links connecting
them. For transaction types we don’t have any similar UML model element and in
this situation it is usual to extend the metaclass ‘class’ as a representation of a con-
cept. Thus, the initiator or executor links between transaction types and actor roles
should be expressed using the association metaclass. This is the most powerful rela-
tionship between model elements that is used to connect classifiers. The problem is
the representation of actor roles. In UML we have an actor element that matches the
concept of an actor role, it is a classifier and support associations as well but this
element has limited capabilities compared to classes. So, the best solution was to
express actor roles using classes as well. This will allow a more powerful expression
of actor roles, it will permit to create composite actor roles based on elementary actor
roles using the inheritance and composition concepts of object-orientation and it will
have some extra benefits when creating the EO profile elements for the PSD DEMO
diagram. The last ATD element that we need to represent is the boundary of an or-
ganization. This is a grouping element that joins transactions, actor roles and links
belonging to an organization, but some transactions with external actor roles are not
placed completely inside the organization boundary but are seen as belonging to the
boundary itself. This cannot be represented used the common UML grouping ele-
ment, the package. Elements of a package belong to the package and not to its boun-
dary. Other UML grouping elements such as the activity partition or the subject (of a
use case) are not suited for this purpose, they can only surround very specific UML
model elements and the related concepts don’t match with our goals. So, we adopted
as a solution to use the package extension but to limit the elements of the organization
package for being transaction types where all the actors are organizational actor roles
and all the actor roles belong to the organization. A possibility is to show the boun-
dary transaction types using a second package which includes only boundary transac-
Regarding the notation we choose to make the UML Profile elements close to the
original notation used in the DEMO diagrams. UML allows some flexibility in the
notation and this possibility to make it close to the original or to the traditional UML
as identified in [1] is used by our solution.
5.2 Development Issues - PS Diagram
The DEMO PSD shows two combined symbols for correspondingly C-acts/C-results
and P-acts/P-results. The links between these symbols are made using causal and
conditional links. Also external and self-activation lines are used to represent the start
of the depicted processes. A last element in these diagrams is a grouping element
defining the responsibility area of an actor role. Giving the “business process” nature
of these kinds of diagrams it would be most useful to represent them using an UML
activity like diagram. For this purpose their elements should be equivalent to the
typical UML activity elements. In fact this is possible because the main elements, C-
acts/C-results and P-acts/P-results, can be represented by extending the UML action
element. If we consider just the C-acts and P-acts, they are both some kind of action
and they are suited to be represented as actions. We should make implicit the pro-
duced C-results and P-results; it will be possible to see them as the output of the cor-
responding actions. Regarding the notation we will make it close to the original PSD
elements. We choose to represent C-acts and P-acts using the combined symbol and
thus making explicit the associated C-results and P-results. The C-act/C-result symbol
is depicted as a single UML element hiding the combined nature of the symbol. This
symbol results from joining a circle – a C-fact (or C-result) type - and a square – a C-
act type - but this combination cannot be made using UML. There is no possibility to
combine two different UML elements without creating a new element with no con-
nection to the original symbols. The same applies to the P-act/P-result symbol which
uses a square for the P-act and a diamond for the P-fact (or P-result) type that it is
represented as a single symbol. UML doesn’t allow us to combine model elements
but we took advantage of the flexibility in the notation. Regarding the causal link it is
in fact a kind of a UML control flow causing the flow to jump from one act to the
next. In the case of the conditional link there is no equivalent UML element but we
can use some of the UML elements to produce the same effect as the conditional link.
In the case of the conditional link appear at the end of a conditional branch it can be
replaced by a decision node at the beginning of the branch and a merge node at the
end. In case of appearing at the end of a concurrent branch it can be replaced by a
fork at the beginning and a join at the end. This last case is illustrated in fig. 8. In the
PSD also responsibility areas are used to delimit a group of acts performed by an
actor role. In this case an extension of activity partition is suited for this goal and can
play the same role. This solution is optimal because we choose before to use UML
extended class elements for actor roles. Thus, actor roles will be the responsible
agents for the corresponding C-acts or P-acts. At last for activation lines UML also
provide model elements, we can use the Initial node of the activity diagram connected
to a C-act using a control flow to express the starting point of a process. If this Initial
node lies inside a responsibility area where it is connected to a C-act it means a self
activation, otherwise if it lies outside the responsibility area it means an external acti-
vation. Just a final remark to point the necessity of including a final flow node to
indicate the end of a process. There is no similar model element in the original PSD.
5.3 Development Issues - AB Diagram
The last part of the UML profile concerns the creation of the corresponding UML
elements for the DEMO ABD. This diagram is similar to the PSD and it can use most
of the elements defined before. We just need to express as well elementary and com-
posite production and coordination banks and information links. These banks are just
a kind of databases and can be shown using an extension of the UML class. Also we
can use the object oriented mechanisms to differentiate from elementary and compo-
site production and coordination banks. The ABD uses also a combined symbol for a
production and coordination bank that refers to an information bank. An information
as a general kind of bank can be expressed as a base class and we can use inheritance
to derive the production and coordination banks. We lose the combined nature but we
gain in expressivity. Finally the information link is naturally expressed as an exten-
sion of an association because it relates stereotypes of classes.
Table 5. Summary of identified UML issues.
UML issue Comments
diagram is not an
UML metamodel
It is not possible to adequately formalize relationships between dia-
grams and model elements because the diagrams are not UML ele-
UML metamodel
grouping elements with
limited options
The most important grouping UML element - the package – provides
a special kind of grouping that doesn’t allow representing elements
that belong to two packages simultaneously; this is the case of
boundary elements such as some of the transaction types in AT
diagrams. Other UML grouping elements such as the Activity
Partition and the Subject have limited application given the
restrictions in the elements they may contain.
UML metamodel ele-
ments usually have
hidden aspects
Some simple UML elements cannot be used to represent similar
concepts because they cannot be freely associated with other ele-
ments. This is hidden and it is a consequence of the rigidity of the
UML metamodel when defining these elements. In the case of the
actor element its limited capabilities make it preferable to use classes
to represent actor roles although an actor was a better matching con-
UML metamodel
elements without
combinations among
It is not possible to combine different UML elements in one joint
element preserving the original meaning of the individual elements.
The example was the C-act/C-result and the production
bank/coordination bank elements which had unique symbols for the
combined element.
6 Conclusions and Future Work
In this paper a UML profile for Enterprise Ontology was introduced. This profile
brings important benefits for the underlying DEMO methodology such as:
Possibility to communicate the diagrams to information system and soft-
ware development teams and to include them with other diagrams in the
same projects
Interoperability of the diagrams with other model tools
Consistency, verifiability and formalization of the diagrams
Concerning the profile creation this paper has raised some issues that are resumed in
table 5. It should be noted as well that the stereotypes created in this profile intro-
duced a reduced number of constraints in order to have enough freedom when using
UML. Some additional constraints can be added if there is the necessity of a more
formal and rigid expression of the produced diagrams.
This work is part of a research project that has as a goal to create a unified and
fundamental theory for software development that integrates some relevant concepts
of three different socio-technical theories, namely Organizational Semiotics [6], the
Theory of Organized Activity [5] and the Language Action Perspective represented in
this paper by the Ψ-theory and the DEMO methodology. Concerning the UML profile
development issues raised in this paper, they complement another group of issues
identified in [1]. As a future work a UML profile of the new theory will be proposed
that will share some of the elements and concepts presented in this paper and in [1].
1. Cordeiro, J., Liu, K.: UML 2 Profiles for Ontology Charts and Diplans - Issues on Meta-
modelling. Proc. of EMISA 2007: 191-204, (2007).
2. Dietz, J. L.: Enterprise Ontology – Understanding the Essence of Organizational Operation.
In: Enterprise Information Systems VII. Eds. C. Chen, J. Filipe, I. Seruca, and J. Cordeiro.
Springer, Dordrecht, The Netherlands (2006)
3. Dietz, J. L.: The deep structure of business processes. Communications of the ACM 49, 5,
58-64. (May 2006)
4. Fuentes, L. and Vallecillo, A.: An Introduction to UML Profiles. UPGRADE, The Euro-
pean Journal for the Informatics Professional, 5(2):5-13 (2004). ISSN: 1684-5285.
5. Holt, A.: Organized Activity and Its Support by Computer, Kluwer Academic Publishers,
Dordrecht, The Netherlands (1997).
6. Liu, K.: Semiotics in Information Systems Engineering, Cambridge University Press,
Cambridge, UK (2000).
7. Mallens, P., Dietz, J., and Hommes, B-J.: The Value of Business Process modelling with
DEMO Prior to Information Systems modelling with UML. In Proc. EMMSAD’01, Inter-
laken, Switzerland (2001).
8. Medina-Mora, R., Winograd, T., Flores, R., Flores, F. The Action Workflow approach to
workflow management technology. In J. Turner and R. Kraut, Eds., Proceedings of the 4th
Conference on Computer Supported Cooperative Work. ACM, New York (1992).
9. OMG: Unified Modeling Language Superstructure Specificacion, v2.1.2. Available:
http://www.omg.org/spec/UML/2.1.2/Infrastructure/PDF/ (Apr 2008)
10. OMG: Unified Modeling Language Infrastructure Specificacion, v2.1.2. Available: http://
www.omg.org/spec/UML/2.1.2/Superstructure/PDF/ (Apr 2008)
11. Rittgen, P.: A language-mapping approach to action-oriented development of information
systems. Eur. J. Inf. Syst. 15, 1, 70-81. (Feb. 2006)
12. Rumbaugh, J., Jacobson, I. and Booch, G.: The Unified Modeling Language Reference
Manual (2nd edition), Addison-Wesley, Reading, MA (2005)
13. Shishkov, B. and Dietz, J.: Deriving Use cases from Business processes, the Advantages of
DEMO. In: Enterprise Information Systems V. Eds. O. Camp, J.B.L. Filipe, S. Hammoudi,
and M. Piattini. Kluwer Academic Publishers, Dordrecht/Boston/London (2004)
14. Winograd, T. and Flores, F.: Understanding Computers and Cognition. Ablex Publishing
Corporation, Norwood, NJ, USA (1986).