1

TECHNICAL REPORT

1

GESSI Research Center

Universitat Politècnica de Catalunya (UPC)

2

PROS Research Centre

Universitat Politècnica de València (UPV)

Title: Integration of i* and Communication Analysis

Corresponding author (s):

Dolors Costal dolors@essi.upc.edu Sergio España sergio.espana@pros.upv.es Marcela Ruiz lruiz@pros.upv.es

Document version number: 1.0 Final version: No Pages: 30

Release date: April 2013

Key words: Information systems, analysis, design, requirements engineering, model-driven development, Communication Analysis, i*, iStar, model transformation, integration, metamodelling, ontological commitment

Integration of

i* and Communication Analysis

Authors: 1Dolors Costal, 2Sergio España, 2Marcela Ruiz 1Xavier Franch, 2Óscar Pastor

2

INTEGRATION OF

i* AND COMMUNICATION ANALYSIS

Scope of this document

This report describes de integration of two requirements engineering methods; namely, i*, a goal-oriented

requirements engineering method [Yu and Mylopoulos 1994], and Communication Analysis, a communication-

oriented business process modelling and requirements engineering method [España, González et al. 2009]. This

work is intended to offer an integrated method that takes advantage of the intentional perspective of i* and the

communicational perspective of Communication Analysis. Joint together, we expect that analysts can start an

engineering project (or a reengineering project) by analysing organisational goals and then reason a business

process model that supports those goals. An overview of both methods is offered in Section 1, but they are not

described in full detail; refer to the literature for more information about the methods.

Comments

This work document involves information about the integration of i* and Communication Analysis (CA). The idea emerge

within ProS-Req project (WP2). Meeting ProS-Req (UPC) October 11th of 2011.

File name Integration_iStar+CA_v1.2_TechnicalReport.doc Print date 17/12/2013 17:39:00

Main authors Dolors Costal, Sergio España # Pages 30

Version Changes

0.01 Sergio defines the document structure.

Sergio adds information about CA (metamodel, definitions, ontological analysis).

TABLE OF CONTENTS

1. OVERVIEW OF THE METHODS ............................................................................................................................... 3

1.1. I* IN A NUTSHELL ....................................................................................................................................................... 3 1.2. COMMUNICATION ANALYSIS IN A NUTSHELL .............................................................................................................. 7

2. THEORETICAL INTEGRATION ............................................................................................................................. 12

2.1. ONTOLOGICAL ANALYSIS OF I-STAR ......................................................................................................................... 13 2.2. ONTOLOGICAL ANALYSIS OF COMMUNICATION ANALYSIS ....................................................................................... 17 2.3. ANALYSIS OF OVERLAPPING CONCEPTS .................................................................................................................... 19

3. METHODOLOGICAL INTEGRATION ................................................................................................................... 20

3.1. INTEGRATION OF THE METAMODELS ......................................................................................................................... 20

4. IMPLEMENTATION .................................................................................................................................................. 22

4.1. COMMUNICATION ANALYSIS MODELLING TOOL........................................................................................................ 23 4.1.1. Platform-specific metamodel for Communication Analysis requirements models ......................................... 23 4.1.2. CA modelling tool .......................................................................................................................................... 25

4.2. I* MODELLING TOOL ................................................................................................................................................ 25 4.2.1. Design of platform specific metamodel for i* ................................................................................................ 25 4.2.2. Implementation of i* modelling tool .............................................................................................................. 27

4.3. INTEGRATION OF MODELLING TOOLS ........................................................................................................................ 27 4.3.1. Integration of PSMmCA and PSMmi* ........................................................................................................... 27 4.3.2. Integrated modelling tools ............................................................................................................................. 28

REFERENCES ...................................................................................................................................................................... 28

3

1. OVERVIEW OF THE METHODS

1.1. i* in a nutshell

The i* framework [Yu 1995] proposes the use of two models, each one corresponding to a different abstraction

level: a Strategic Dependency (SD) model represents the intentional level and the Strategic Rationale (SR) model

represents the rational level. Different research groups have proposed variations to the modelling language

proposed in the i* framework. In this work, we follow that of the i* wiki {i*wiki, #1265} as departing point for

defining the i* concepts with a single update: we have omitted the instance (INS) relationship since, as it is

argued in [Lopez, Franch et al. 2011], it is a construct that should be considered at a different modelling level.

A SD model consists of a set of nodes that represent actors and a set of dependencies that represent the

relationships among them, expressing that an actor (depender) depends on some other (dependee) in order to

obtain some objective (dependum). The dependum is an intentional element that can be a resource, task, goal or

softgoal. It is also possible to define the importance (strength) of the dependency for each of the involved actors

using three categories: open, committed and critical.

A SR model allows visualizing the intentional elements into the boundary of an actor in order to refine the SD

model with reasoning capabilities. The dependencies of the SD model are linked to intentional elements inside

the actor boundary. The elements inside the SR model are decomposed accordingly to three types of links:

o Task-decomposition links state the decomposition of a task into different intentional elements. There is

a relation AND when a task is decomposed into more than one intentional element.

o Means-end links establish that one or more intentional elements are the means that contribute to the

achievement of an end. Each link indicates a relationship between an end, and a means for attaining it.

The "means" is expressed in the form of a task, since the notion of task embodies how to do something,

while the "end" is expressed as a goal. There is a relation OR when there are many means for an end,

which indicate the different ways to obtain the end.

o Contribution to softgoal links establish that one or more intentional elements affect the attainment of a

softgoal. It is possible to specify the positive or negative strength of the contribution.

Actors can be specialized into agents, roles and positions. A position covers roles. The agents represent particular

instances of people, machines or software within the organization and they occupy positions (and as a

consequence, they play the roles covered by these positions). The actors and their specializations can be

decomposed into other actors using the is-part-of relationship.

In the following, we provide a definition of the most relevant concepts of the framework.

An actor is an active entity that carries out actions to achieve goals by exercising its know-how.

Agents, roles and positions are sub-units of a complex social actor, each of which is an actor in a more

specialized sense.

Def. 1

An agent is an actor with concrete, physical manifestations, such as a human individual. It can be

human as well as artificial (hardware/software agents).

Def. 2

A role is an abstract characterization of the behavior of a social actor within some specialized context

or domain of endeavor. Its characteristics are easily transferable to other social actors.

Def. 3

A position is an intermediate abstraction between a role and an agent. It is a set of roles typically

played by one agent (e.g., assigned jointly to that one agent).

Def. 4

An is-a association is a relationship between actors such that one actor is a specialized case of another

actor.

Def. 5

An is-part-of association is a relationship between actors such that one actor is a subpart of another

actor. Aggregate actors are not compositional with respect to intentionality. Each actor, regardless of

whether it has parts, or is part of a larger whole, is taken to be intentional. There can be intentional

dependencies between the whole and its parts, e.g., a dependency by the hole on its parts to maintain

unity.

Def. 6

A plays association is a relationship between an agent and a role that transfers the characteristics of Def. 7

4

the role to the agent.

A covers relationship is a relationship between a position and a role such that the role is covered (i.e.

included) by the position.

Def. 8

A occupies relationship is a relationship between an agent and a position meaning that the agent

plays all of the roles that are covered by the position.

Def. 9

A goal (or hard goal) is an intentional desire of an actor, i.e. it is a condition or state of affairs in the

world that the actor would like to achieve.

Def. 10

A softgoal is a condition in the world which an actor would like to achieve but, unlike in the concept

of (hard-) goal, the criteria for the condition being achieved is not sharply defined a priori and is

subject to interpretation. Then, a softgoal is similar to a (hard) goal except that the criteria for the

goal's satisfaction are not clear-cut, it is judged to be sufficiently satisfied from the point of view of the

actor. The notion of softgoal satisfaction is described by the term satisficed meaning sufficiently

satisfied.

Def. 11

A task is something an actor wants to accomplish performed in a particular way. (A description of the

specifics of the task may be described by decomposing the task into further sub-elements.)

Def. 12

A resource is an entity, physical or informational such that an actor desires its provision. It is assumed

there are no open issues or questions concerning how the entity will be achieved.

Def. 13

A belief is a condition about the world that the actor holds to be true. A belief is distinct from a goal

in that the actor has no explicit desire to make the specified condition become true.

Def. 14

A task decomposition link is a relationship between a task and a component element of the task. A

task can be decomposed into four types of elements: a subgoal, a subtask, a resource, and/or a

softgoal. The task can be decomposed into one or many of these elements.

Def. 15

A means-end link is a relationship between an end, and a means for attaining it. The "means" is

expressed in the form of a task, since the notion of task embodies how to do something, while the

"end" is expressed as a goal.

Def. 16

A contribution to softgoal link is a relationship between a softgoal and an element that affects its

attainment. There are different types of contribution links: 1) make type which is a positive

contribution strong enough to satisfice the softgoal, 2) help type which is a partial positive

contribution, not sufficient by itself to satisfice the softgoal, 3) some+ type which is a positive

contribution whose strength is unknown, 4) unknown type which is a contribution to a softgoal whose

polarity is unknown, 5) some- which is a negative contribution whose strength is unknown, 6) hurt

type which is a partial negative contribution, not sufficient by itself to deny the softgoal and 7) break

type which is a negative contribution sufficient enough to deny a softgoal. 8) or type where the

softgoal is satisficed if any of its offsprings are satisficed. 9) and type where the softgoal is satisficed if

all of its offsprings are satisficed.

Def. 17

An actor boundary1 is the boundary of a subsystem of an organisational system that comprises the

goals and softgoals that are desired by the actor, the tasks that may be accomplished by the actor, the

beliefs of the actor and the resources managed by the actor.

Def. 18

1 The original definition from the istar Wiki is the following.

“An actor boundary indicates intentional boundaries of a particular actor. All of the elements within a

boundary for an actor are explicitly desired by that actor. In order to achieve these elements, often an

actor must depend on the intentions of other actors, represented by dependency links across actor

boundaries. In turn, an actor is depended upon to satisfy certain elements, represented by a

dependency link in the opposite direction.”

We consider that the original definition does not focus on the underlying concept but is biased

towards its representation: the notation indicates that the boundary is represented as a line made up

of alternately-spaced long and short dashes, which surrounds a set of model elements; the area within

the boundary is often coloured in grey and the boundary line is overlapped by an actor symbol.

Instead, we proposed an alternate definition based on our knowledge of the i* method, and which is

5

A strategic dependency indicates that one actor or one element in an actor’s boundary (depender)

depends on another actor or element in another actor’s boundary (dependee), in order to obtain some

objective (dependum). We distinguish among four types of dependencies, based on the type of the

objective (dependum): resource dependency, task dependency, goal dependency and softgoal

dependency

Def. 19

A dependee is an actor or an element in an actor’s boundary that is depended upon on a dependency

relationship.

Def. 20

A depender is an actor or an element in an actor’s boundary that is the depending on a dependency

relationship

Def. 21

A dependum is an element around which a dependency relationship centers. Def. 22

A goal dependency is a dependency in which the depender depends on the dependee to bring about a

certain state of affairs in the world (a goal). The dependee actor is free to, and is expected to make

whatever decisions are necessary to achieve the goal (namely, the dependum). The depender actor

does not care how the dependee goes about achieving the goal.

Def. 23

A task dependency is a dependency in which the depender depends on the dependee to carry out an

activity. The dependum names a task which specifies how the task is to be performed, but not why.

The depender actor has already made decisions about how the task is to be performed. Note that a

task description in i* is not meant to be a complete specification of the steps required to execute the

task. It is a constraint imposed by the depender on the dependee. The dependee actor still has

freedom of action within these constraints.

Def. 24

A resource dependency is a dependency in which the depender depends on the dependee for the

availability of an entity (physical or informational). By establishing this dependency, the depender

gains the ability to use this entity as a resource. A resource is the finished product of some

deliberation-action process. In a resource dependency, it is assumed that there are no open issues to be

addressed or decisions to be made.

Def. 25

A softgoal dependency is a dependency in which the depender depends on the dependee to perform

some task that meets a softgoal. A softgoal is similar to a goal except that the criteria of success are not

sharply defined a priori. The meaning of the softgoal is elaborated in terms of the methods that are

chosen in the course of pursuing the goal. The depender actor decides what constitutes satisfactory

attainment of the goal, but does so with the benefit of the dependee's know how.

Def. 26

An open dependency for the depender (uncommitted) is a dependency in which not obtaining the

dependum would affect the depender actor to some extent but not seriously.

Def. 27

A committed dependency for the depender is a dependency in which the depender actor has goals

which would be significantly affected (in that some planned course of action would fail) if the

dependum is not achieved.

Def. 28

A critical dependency for the depender is a dependency in which the depender actor has goals which

would be seriously affected (in that all known courses of action would fail) if the dependum is not

achieved.

Def. 29

An open dependency for the dependee (uncommitted) is a dependency in which there is a claim by

the dependee actor that it is able to achieve the dependum for some depender.

Def. 30

A committed dependency for the dependee is a dependency in which the dependee actor will try its

best to deliver the dependum, e.g., by making sure that its own dependencies are viable.

Def. 31

A critical dependency for the dependee is a dependency in which the dependee actor will make sure

not only of the viability of its own dependencies but also about the viability of its dependee’s

dependencies and its dependee’s dependee’s dependencies and so forth.

Def. 32

Figure 1 depicts a metamodel that contains many of the above-mentioned constructs. We have used the

metamodel for i* presented in [López, Franch and Marco 2011] as departing point and we have slightly modified

consistent with the use of this concept in most of the i* model denotations available in the literature.

The actor boundary is a sub-system boundary, where the sub-system is implicitly represented by the

area in grey.

6

it in order to: first, adapt it to the i* wiki version of the concepts and, second, make explicit some implicit

metaclasses.

Figure 1 i* language platform-independent metamodel

The following constraints restrict what can be expressed using the metamodel in Figure 1.

Table 1 Constraints for the i* metamodel

Constraints

C1 There cannot be two nodes with the same name except for those which are internal elements.

C2 There cannot be two internal elements that belong to the same actor boundary with the same name.

C3 Cycles are not allowed for actor links.

C4 The instances of IS-A and IS-PART-OF actor links must link actors of the same type.

C5 An instance of OCCUPIES must link an instance of AGENT and an instance of POSITION.

C6 An instance of COVERS must link an instance of POSITION and an instance of ROLE.

C7 An instance of PLAYS must link an instance of AGENT and an instance of ROLE.

C8 Two instances of an IS-A actor link cannot have the same instance of ACTOR in their FROM association

end.

7

1.2. Communication Analysis in a nutshell

Since information systems are a support to organisational communication, a communicational approach to

information systems analysis is necessary; that is, information systems requirements engineering should take

into account users’ communicational and informational needs. Communication Analysis is a requirements

engineering method that analyses the communicative interactions between the information system and its

environment [España, González et al. 2009]. Therefore, the method focuses on external information system

functions: information acquisition and distribution.

The methodological core of Communication Analysis is the information system analysis stage, the result of which is

an analysis specification, a communication-oriented documentation that describes the information system

disregarding its possible computerisation (see Figure 2). This way, the analysis specification produced by

Communication Analysis corresponds to the CIM layer of the Model Driven Architecture. This specification

includes a system decomposition that intends to reduce complexity, a set of communicative event diagrams that

describe business processes from a communicational perspective, a set of event specification templates that describe

each business activity in detail, and the object requirements that specify business objects from a user perspective.

C9 An instance of DEPENDUM cannot be an instance of BELIEF.

C10 An instance of TASKDECOMPOSITION must have an instance of TASK in its TO association end.

C11 An instance of TASKDECOMPOSITION must have an instance of GOAL, SOFTGOAL, RESOURCE or TASK in its

FROM association end.

C12 An instance of MEANS-END must have an instance of GOAL in its TO association end.

C13 An instance of MEANS-END must have an instance of TASK in its FROM association end.

C14 An instance of CONTRIBUTIONTOSOFTGOAL must have an instance of SOFTGOAL in its TO association end.

C15 An instance of CONTRIBUTIONTOSOFTGOAL must have an instance of GOAL, SOFTGOAL, BELIEF or TASK in

its FROM association end.

C16 Cycles are not allowed for the IELINK association except for those that involve only instances of

CONTRIBUTIONTOSOFTGOAL.

C17 There cannot be two instances of DEPENDENCY such that all three following conditions hold:

1) They are linked to the same instance of DEPENDUM

2) The actor linked by the DEPENDER association end or the actor to which the internal element

linked by the DEPENDER association end belongs to is the same actor for both dependencies

3) The actor linked by the DEPENDEE association end or the actor to which the internal element

linked by the DEPENDEE association end belongs to is the same actor for both dependencies

C18 For an instance of DEPENDENCY, the actor linked by the DEPENDER association end, or the actor to which

the internal element linked by the DEPENDER association end belongs to, cannot be the same as the

actor linked by the DEPENDEE association end, or the actor to which the internal element linked by the

DEPENDEE association end belongs to.

C19 An instance of BELIEF cannot be linked neither by a DEPENDER association end nor by a DEPENDEE

association end.

C20 The dependum of a goal dependency must be an instance of GOAL.

C21 The dependum of a task dependency must be an instance of TASK.

C22 The dependum of a resource dependency must be an instance of RESOURCE.

C23 The dependum of a softgoal dependency must be an instance of SOFTGOAL.

8

Co

mm

un

ica

tio

n A

na

lysis

me

tho

do

log

ica

l co

re

DESIGN SPECIFICATION

PROCESS PRODUCT

ANALYSIS SPECIFICATION

DATA MODEL

INFORMATION

SYSTEM

ANALYSIS

COMMUNICATIVE

EVENT DIAGRAMS

LEGEND

MODEL

(SUB) MODEL

START NODE

PRECEDENCE

RELATION

DEVELOPMENT

STAGE

END NODE

ARTIFACT

PRODUCTION

EVENT SPECIFICATION

TEMPLATES

SYSTEM

DECOMPOSITION

OBJECT

REQUIREMENTS

USAGE REQUIREMENTS

COMPONENT DESIGN

ARCHITECTURAL

DESIGN

SOURCE CODE

COMPUTERISED

INFORMATION

SUB-SYSTEM

DESIGN

SOFTWARE

IMPLEMENTATION

Figure 2. Methodological core of Communication Analysis within a wider development method

After the information system analysis stage, several situations are possible. For instance, the analysts can create

the design specification. Then the implementation can be carried out inside the same organisation that performed

the analysis or it can be outsourced. In either case, up to when this thesis started, the implementation has always

been carried out manually (i.e. not using model compilers).

Communication Analysis prescribes a requirements structure with five levels for the analysis and design

specifications; each requirement is ascribed to one requirements level. Figure 3 shows the requirements levels, as

well as the main activities performed and the artefacts created at each level. The requirements structure offers

two dimensions. One dimension is related to the static-dynamic duality (horizontal axis of Figure 3). The other

dimension is related to refinement (vertical axis of Figure 3).

L1.

System /

subsystems

L2.

Process

L3.

Communicative

interaction

L4.

Usage

environment

L5.

Operational

environment

(2)

COMMUNICATIVE

EVENT

DIAGRAMATION

(4)

COMMUNICATIVE

EVENT

SPECIFICATION

(6) USAGE

REQUIREMENTS

ELICITATION AND

INTERFACE DESIGN

(7) OBJECT

CLASSES

MODELLING

(1) STRATEGIC

DESCRIPTION OF

THE ORGANISATION

Requirements levels Communication Analysis activitiesDynamic perception Static perception

(3) BUSINESS

OBJECTS

IDENTIFICATION

(5) BUSINESS

OBJECTS

SPECIFICATION

order=

<order#+

client+

{ prod+

quant+

price }>

Activity Influence Outcome

COMPONENT

DESIGN

LOGICAL DESIGN

IMPLEMENTATION

Pro

ble

m s

pa

ce

So

luti

on

sp

ac

e

ProductionLEGEND

Business Object

Glossary

Detailed B.O.G

IS memory model

Problem

decomposition

Communicative

Event Diagram

Communicative

event templates

Interface design

model

Figure 3. The requirements structure and the Communication Analysis workflow

9

In levels L1 and L2, the analyst seeks to refine a complex system into subsystems and to obtain the repertoire of

communicative interactions that the users need for their work practice. Level L2 includes business process

modelling, which raises the issue of modularity. How can subsystems be identified? How many processes should

be defined? What is the appropriate granularity of a communicative interaction? When should the analyst stop

refining communicative interactions and start designing their support? To answer these questions,

Communication Analysis provides business process modelling criteria [González, España et al. 2009]; that is,

guidelines to guide requirements models modularly. From level L2 to level L3 the analyst makes a quantum leap

and starts specifying the identified communicative interactions. Another qualitative difference exists between

levels L3 and L4, since the analyst (or designer) shifts the focus of the specification from a pragmatic perspective

to a semantic and syntactic perspective; the requirements model is added details about how the messages are

edited and displayed (i.e. interface design). Also, whereas in L3 the focus was messages (data in motion), L4

focuses on the information system memory (data at rest) intended to ensure the persistence of the communicative

interactions. Lastly, the technological architecture is designed and the software application is implemented (this

can again involve data in motion in the form of component interaction and network communication, but now the

semiotic level is lower).

Communication Analysis has been successfully put into practice in medium and big software development

projects in enterprises and governmental organisations.

In the following, we provide definitions of the most relevant concepts of the method. The definitions have been

extracted from [España 2011] and build upon the concepts defined within the FRISCO report [Falkenberg, Hesse

et al. 1998].

An organisational unit is a sub-system of an organisational system, usually conceived with the goal

of reducing the complexity of organisational administration and management.

Def. 33

An organisational location is a specific place in space and time where a sub-system of the

organisational system is situated.

Def. 34

An organisational goal is a goal that ought to affect the actions of an organisational system (that is,

the behaviour of its actors).

Def. 35

A business indicator is a metric (a formula) that allows measuring a specific aspect of a set of

phenomena occurring in a subject system (or predicting future phenomena), along with the rules that

allow to carry out the measurement action and to interpret the result.

Def. 36

An organisational strategy is the set of interrelated organisational goals that is defined by the

managerial staff of an organisational system or sub-system, along with their corresponding business

indicators, a current value for each business indicator, a target value for each business indicator, and

an action plan intended for achieving the organisational goals.

Def. 37

An organisational actor is a goal-pursuing actor that interacts with the organisational system in some

way. Organisational actors either belong to the organisational system (e.g. they are bound to the

organisational system by, e.g., a contractual relationship, and thus their actions are expected to

conform to organisational norms) or they are external parties (i.e. they belong to the subject system

but not to the organisational system).

Def. 38

An organisational role is a set of organisational actors that are expected to perform a certain type of

actions conforming to the organisational norms; they are often considered to have a similar goal in

common, or to have a similar function.

Def. 39

A business process is a sub-system of the subject system, often expressed as an organisational norm

defining (among other things) a set of actions that intend to fulfil one or several organisational goals,

the organisational roles that take part in those actions, the state-transition structures that relate those

actions, and the expected pre-states (e.g. technology, materials, installations) and post-states (e.g.

products being created, services being provided) of the actions.

Def. 40

A communicative interaction is an exchange of messages, i.e. a sequence of mutual and alternating

message transfers between at least two organisational actors, called interacting partners (being either

human or non-human), whereby these messages contain some data about the subject system and are

expressed in languages understood by all communication partners, and whereby the action context

and the goal of the communicative interaction is made present in all interacting partners.

Def. 41

An ingoing communicative interaction is a communicative interaction whereby one of the interacting

partners is a regulated transition observer and another interacting partner belongs to the information

Def. 42

10

system. The main communicative goal of the interaction is to report to the information system a

regulated transition occurrence, for which purpose the regulated transition observer conveys pieces of

regulated-transition information to the information system actor.

An outgoing communicative interaction is a communicative interaction whereby one of the

interacting partners belongs to the information system and another interacting partner is a recalled

facts receiver. The main communicative goal of the interaction is to retrieve knowledge (i.e. recalled

facts) from the information system and to convey it to the recalled facts receiver.

Def. 43

Communicative event unity criteria are a set of unity criteria that serve the purpose of guiding the

information systems modelling action. It consists of three rules; namely trigger unity, communication

unity and reaction unity.

Def. 44

A communicative event is a composite transition; more specifically, a unitive conception unifying

several conceptions about an ingoing communicative interaction and the corresponding reaction of

the organisational system, whose modularity fulfils the communicative event unity criteria.

Def. 45

An event variant is each of the alternative transitions (if any) that take part in the state-transition

structure that defines the composition of a communicative event. Such event is said to be a

“specialised” communicative event.

Def. 46

A primary role for a given communicative event is a set of organisational actors that are expected to

act as regulated-transition observers, in the action context of that communicative event; that is, the set

of organisational actors that are designated responsible for reporting to the information system an

occurrence of a certain type of communicative event, by providing data.

Def. 47

A primary actor is an organisational actor playing a primary role in the action context of a

communicative event.

Def. 48

A receiver role for a given communicative event is a set of organisational actors that are expected to

act as a recalled facts receivers in the action context of a communicative event; that is, the set of

organisational actors that (having the rights to do so) request the retrieval of data from the

information system memory (i.e. the domain model denotation).

Def. 49

A receiver actor is an organisational actor playing a receiver role in the action context of a

communicative event.

Def. 50

The precondition of a communicative event is a rule determining the states in which the

communicative event is allowed to occur (i.e. the possible pre-states).

Def. 51

A precedence relation between two communicative events (say, A and B) is a rule consisting of a

relationship that defines the relative time between them. It indicates that, for communicative event B

to occur, A has necessarily occurred before. A is said to be a “direct precedent” (communicative event)

of B; conversely, B is said to be a “direct successor” (communicative event) of A. The precedence

relation is part of the precondition of the “direct successor” communicative event.

Def. 52

A business object is a composite thing of the subject system, which an organisational system is

interested in acquiring knowledge about.

Def. 53

A business object class is a type of business objects. Def. 54

A business object class property is an organisational norm that defines a piece of data that is relevant

for the organisational system in order to know about a specific business object class.

Def. 55

Message Structures is a modelling technique intended for specifying the message that corresponds to

a communicative interaction.

Def. 56

A support role for a given communicative event is a set of organisational actors that, in the action

context of that communicative event, participate as interacting partners, not being a primary actor or a

receiver actor. For instance, the support actor can participate as the channel of a message transfer, or

as an interface actor.

Def. 57

A support actor is an organisational actor playing a support role in the action context of a

communicative event.

Def. 58

11

Figure 4 depicts a metamodel that contains many of the above-mentioned constructs. The metamodel includes

the metaclasses intended for modelling the dynamic view of the information system. It mainly covers the three

first requirements levels: L1 concerned with organisational modelling and problem decomposition, L2 concerned

with business process modelling from a communicational perspective, and L3 concerned with communicative

event specification.

We have omitted some metaclasses intended for modelling the static view of the information system because,

after the integration of Communication Analysis with the OO-Method (an object-oriented conceptual modelling

method that conforms to the Model-Driven Architecture paradigm and provides automatic code generation

[Pastor, Gómez et al. 2001; Pastor and Molina 2007]), this aspect is expected to be covered by metaclasses of the

OO-Method (e.g. metaclasses related to normalised business object class information definitions; that is, those

metaclasses intended for modelling the computerised information system memory).

ORGANISATIONAL_

UNIT

MISSION

ORGANISATION

1:M

1:1UPPER

LOWER

NAME

DESCRIPTION

STRATEGY_DATE

ACTION_PLAN

STRATEGY

NAME

ACRONYM

DESCRIPTION

ADDRESS

CITY

POST_NUMBER

COUNTRY

ORGANISATIONAL_

LOCATION

NAME

DESCRIPTION

GOAL

NAME

DESCRIPTION

METRIC

INDICATOR

CURRENT_VALUE

TARGET_ VALUE

TARGET_DATE

OPERATIONALISATION

0:M

1:1

GOAL

OPERS OPERS

INDICATOR1:1

0:M

FIRST_NAME

LAST_NAME

PHONE_NUMBER

COMMENTS

ORGANISATIONAL_

ACTOR

0:M1:1ORG_MODULE STRATEGIES

NAME

DESCRIPTION

DUTIES

ORGANISATIONAL_

ROLE

1:M

1:MORG_UNITS

ORG_ACTORS

0:M

0:MACTORS

ROLES

1:M

1:M ORG_UNITS

ROLES

NAME

DESCRIPTION

COMMUNICATIVE_

INTERACTION

/ID

DESCRIPTION

COMMUNICATIVE

_EVENT

/ID

SPEC_COND

EVENT_

VARIANT

0:M

1:1SPECIALISATIONS

GENERALISATION

NAME

ACRONYM

DESCRIPTION

PROCESS

0:M

0:MORG_UNITS

PROCESSES

EVENTS

1:1PROCESS

1:M ID

SUPPORT

RECEIVER

PRIMARY

PRECEDENCE

LOGICAL_NODE

OR

AND

NODE

TARGET

1:1

INCOMING

0:M

1:1 0:MOUTGOINGSOURCE

END

0:M

1:1 ORG_ROLE

COM_ROLES

PRIMARY IN1:11:1

RECEIVER OUT1:10:M

SUPPORTS

1:1INTERACTION

0:M 0:M

1:1ENCAPS

OUTS

COMPLEX_

SUBSTRUCTURE

0:M1:1MESSAGE_STR

INTERACTIONS

NAME

DESCRIPTION

BUSINESS_

OBJECT_CLASS

FIELDS

OBJECT_CLASS1:1

0:M

START

NAME

DESCRIPTION

BUSINESS_

OBJECT_FIELD

0:M0:MOBJECT_CLASSES INTERACTIONS

NUMBER

NAME

PRECONDITION

ENCAPSULATION

1:11:1IN EVENT

INGOING

OUTGOING

NAME

DESCRIPTION

EXAMPLE

MIN_CARD

MAX_CARD

SUBSTRUCTURE

OPERATION

DERIVATION_FORMULA

EXAMPLE

FIELD

DOMAIN

IS_IDENTIFIER

DATA_FIELD

REFERENCE_

FIELD

0:M

1:1

COMPONENTS

DOMAIN

0:MREFERENCES

1:1

SPECIALISATION

AGGREGATION

ITERATION

0:M

1:1 EVENT

REQUIREMENTS

0:M

1:1SUBSTRUCTURE

CCONS

0:M

1:1SUBSTRUCTURE

SCONS

0:M

0:MEVENTS

GOALS

STRATEGY0:1

1:M OPERABLE_GOALS

1:M

1:MORG_LOCATIONS

ORG_MODULES

NAME

ACRONYM

DESCRIPTION

ORGANISATIONAL_

MODULE

GOALS

1:1ORG_MODULE

0:M

ID

DESCRIPTION

TEXTUAL_

REQUREMENT

CONTACT_

REQUIREMENT

MESSAGE_

REQUIREMENT

REACTION_

REQUIREMENT

STRUCTURAL_

CONSTRAINT

CONTEXTUAL_

CONSTRAINT

LINKED_

BEHAVIOUR

LINKED_

COMMUNICATION

TREATMENT

VERIFICATION_

REQUIREMENT

AVAILABILITY_

REQUIREMENT

ACCREDITATION_

REQUIREMENT

MEDIUM_

REQUIREMENT

0:M1:1INTERACTION MEDIUM_REQS

EVENT_

PRECONDITION

COMMUNICATIVE_

ROLE

IS_INTERFACE_ACTOR

MESSAGE_PARTI

CULARISATION

NAME

DESCRIPTION

MESSAGE_

STRUCTURE

0:1

1:1INITIAL

MESSAGE_STR

NAME

DESCRIPTION

COMMUNICATION

CHANNELINTERACTIONS

0:MCHANNELS0:M

0:1

0:1ROLE

AGGREGATION

Figure 4. Communication Analysis requirements models platform-independent metamodel

Table 2 presents two formulas corresponding to the derived attributes that calculate the identifier of

communicative events and event variants. This way, events of the Sales management process will have

identifiers of the form SALE 1, SALE 2, SALE 3, etc. Also, the variants of the specialised event SALE 3 have a

compound identifier of the form SALE 3.1 and SALE 3.2.

12

Table 2. Derivation formulas for the PIM metamodel of Communication Analysis

Derivation Formulas

F1 COMMUNICATIVE_EVENT.Id = concat( GENERALISATION.Id, IntToStr( Number ) )

F2 EVENT_VARIANT.Id = concat( PROCESS.Acronym, IntToStr( Number ) )

The following constraints restrict what can be expressed using the metamodel in Figure 4. These rules are part of

the grammars of Communication Analysis modelling languages.

Table 3. Constraints for the PIM metamodel of Communication Analysis

2. THEORETICAL INTEGRATION

Ontological analysis offers strong theoretical foundations to analyse and compare methods; it requires a

reference ontology and a procedure to perform the evaluation.

In general, the evaluation procedure consists of establishing a mapping among the concepts (a.k.a. constructs) of

the ontology and the concepts of the modelling technique (often the modelling primitives or the metaclasses are

employed). Then the evaluators assess to which extent the modelling technique covers the concepts of the

ontology, and vice versa.

Constraints

C1 A start node must not have incoming precedence relations.

C2 An end node must not have outgoing precedence relations.

C3 An and node must have two or more incoming precedence relations and only one outgoing

precedence relation. Take into account that the and node represents the and-join, since the and-split is

implicit.

C4 An or node must have only one incoming precedence relation and two or more outgoing precedence

relations. Take into account that the or node represents the or-merge, since the or-branch is implicit in

communicative event specialisation.

C5 Within each business process, each communicative event must have a distinct number.

C6 Within each specialised communicative event, each event variant must have a distinct number.

C7 A formula is either a specialisation condition, an initialisation formula or a derivation formula, but not

several of these at the same time (this means that an instance of FORMULA can only have a link via one

of the relationships).

C8 The initial substructure of a message structure cannot be a specialisation substructure. Thus, given an

instance of COMMUNICATIVE_EVENT, it cannot be linked via Message_Structure to a

COMPLEX_STRUCTURE of type SPECIALISATION.

C9 The minimum cardinality of a message structure field (an instance of FIELD) is 0 or 1, and the

maximum cardinality of a field is 1.

C10 The minimum and the maximum cardinality of an aggregation substructure (an instance of

SUBSTRUCTURE) is 1.

C11 The minimum and the maximum cardinality of a specialisation substructure (an instance of

SPECIALISATION) is 1.

13

CONSTRUCTS OF

MODELLING METHOD

CONSTRUCTS OF

REFERENCE ONTOLGY

Figure 5. Ontological analysis of a modelling method

There are many examples in the literature in which methods or modelling languages are analysed with the aim

of assessing their theoretical quality (in the sense of being well founded). For instance, in [Wand and Weber 1990;

Wand, Monarchi et al. 1995; Weber 1997; Weber 1999] the authors define the Bunge-Wand-Weber (BWW) model

by extending Bunge’s ontology, and they use this model as a reference ontology to evaluate information

modelling methods. Many ontological analysis have been done based on the BWW model, mainly on object-

oriented modelling languages [Opdahl and Henderson-Sellers 1999] [Opdahl, Henderson-Sellers et al. 2000]

[Opdahl and Henderson-Sellers 2002]. Other authors choose a different reference ontology. For instance, Milton,

Kazmierczak et al. [2001] propose Chisholm’s ontology as a reference. Besides providing a mapping of

constructs, their ontological analysis method also aims at providing qualitative information, which includes

identifying partial supports for ontological constructs [Milton and Kazmierczak 2004]. Guizzardi Pires et al.

[2005] propose a framework for the evaluation and redesign of modelling languages. They define four properties

(some of them related to the notions above) that a model should hold with respect to a domain abstraction;

namely, lucidity, soundness, laconicity and completeness. An ontological evaluation of the UML is provided,

using the Unified Foundational Ontology [Guizzardi 2005] as the reference ontology. In [Pastor, González et al.

2007] and [Pastor, España et al. 2008] a procedure for ontological evaluation is proposed; it is referred to as

conceptual alignment and it uses the FRISCO conceptual framework of information system concepts as a

reference ontology. It has been used to perform the ontological evaluation of the OO-Method, the Rational

Unified Process [Rational 2003], and Wisdom [Nunes and Cunha 2000] (the three evaluations are compiled in

[España 2008]).

CONSTRUCTS OF

MODELLING METHOD B

CONSTRUCTS OF

MODELLING METHOD A

CONSTRUCTS OF

REFERENCE ONTOLGY

CANDIDATE OVERLAPPING CONSTRUCTS

Figure 6. Ontological analysis as a means to guide method integration

In this work, we also use FRISCO as a reference ontology. However, our intention differs from the above-

mentioned works. We intend to ground the integration of two requirements engineering methods on a sound

theoretical basis. For this purpose, we analyse the ontological mappings of both methods in order to find related

concepts. Whenever two method concepts are mapped to the same ontological concept, then both method

concepts are overlapping and, therefore, they are candidates for the integration; that is, they can serve as

junctions. To the best of our knowledge, this use of ontological analysis has never been reported in the literature

before.

2.1. Ontological analysis of i-star

Table 4 provides a mapping between the constructs of i-star and the constructs of the FRISCO ontology.

14

With regards to the constructs of i-star, we distinguish between meta-class (of the method metamodel) and

concept (of the method); this provides an additional analysis of the extent to which the particular metamodel

(one among the many possible supports to the method) covers the concepts of the method.

Table 4. Mapping among constructs of i-star and the reference ontology

i-star construct FRISCO 1.1 construct

Concept Metaclass Concept

actor ACTOR actor

type (of actors)

set (of types of actors)

agent AGENT actor with a concrete physical

manifestation, for instance, a human

actor that carries out actions to

achieve goals by exercising its know-

how

role ROLE type of actors such that it

characterizes the behaviour of agents

(see also the plays association)

position POSITION set of types of actors; that is, a set of

roles typically played by one agent

(see also the covers association)

is-a association IS-A relationship between an istar.actor

(the “type”) and another istar.actor

(the “subtype”), meaning that the

latter is considered to be an

specialisation of the former

is-part-of association IS-PART-OF relationship between an istar.actor

(the “whole”) and another istar.actor

(the “part”), meaning that the latter is

considered to be part of the former

plays association PLAYS relationship between an actor (the

“agent”) and a type of actors, (the

“role”) meaning that the actor is of

that particular type

covers relationship COVERS set membership between a set of

types of actors (the “position”) and a

type of actors (the “role”) meaning

that “the role is covered by the

position”

occupies relationship OCCUPIES relationship between an actor (the

“agent”) and a set of types of actors

(the “position”) meaning that “the

agent plays all the roles covered by

the position”; that is, the actor is of all

the types that are member of the set

goal GOAL goal that is an intentional desire of an

actor

softgoal SOFTGOAL goal, more specifically, intentional

desire of an actor such that its

satisfaction criteria is not clear-cut

task TASK action that involves one actor in its

15

pre-state and in its post-state

resource RESOURCE input actand of an action such that an

actor desires its provision and there

are no open issues about how it will

be achieved (if it is a physical

resource)

data that is the input actand of an

action such that an actor desires its

provision and there are no open

issues about how it will be achieved

(if it is an informational resource)

belief BELIEF predicated thing that is a condition

about the world that an actor holds to

be true

task decomposition link TASKDECOMPOSITION relationship between an action (the

“task”) and an istar.goal or an

istar.softgoal or an istar.resource or

another action; in the latter case the

first action is a composite action

means-end link MEANS-END relationship between a goal (more

specifically, an istar.goal), and an

action (task) such that the goal is the

goal of that action (special input

actand of the action stating the

desired output state intensionally)

contribution to softgoal link CONTRIBUTIONTOSOFTGOAL relationship between a goal (more

specifically, an istar.softgoal) and

either a goal (an istar.goal or an

istar.softgoal) or a predicated thing

(more specifically, a belief) or an

action such that the attainment of the

istar.softgoal is affected by it

actor boundary not a metaclass, but a role of one:

ACTOR.boundary

sub-system with all the goals (either

istar.goals or istar.softgoals) desired

by the actor, actions where the actor is

involved, beliefs of the actor and

resources that are managed by the

actor

strategic dependency DEPENDENCY relationship composed of three

predicated things: first, an istar.actor

or component of the subsystem in an

istar.actor’s boundary which is the

dependee of the dependency, second,

another istar.actor or component of

the subsystem in an istar.actor’s

boundary which is the depender of

the dependency and, third, a goal (an

istar.goal or an istar.softgoal) or an

action (task) or a resource which is the

dependum of the dependency. It is

such that the depender depends on

the dependee to obtain the dependum

dependee not a metaclass, but a role of one: istar.actor or component of the

subsystem of an istar.actor’s

16

DEPENDENCY.dependee boundary which is the dependee of a

relationship that is a strategic

dependency

depender not a metaclass, but a role of one:

DEPENDENCY.depender

istar.actor or component of the

subsystem of an istar.actor’s

boundary which is the depender of a

relationship that is a strategic

dependency

dependum DEPENDUM a goal (either istar.goal or

istar.softgoal) or an action (task) or a

resource which is the dependum of a

relationship that is a strategic

dependency

goal dependency GOALDEPENDENCY relationship that is a strategic

dependency such that its dependum

component is an istar.goal

task dependency TASKDEPENDENCY relationship that is a strategic

dependency such that its dependum

component is an action (task)

resource dependency RESOURCEDEPENDENCY relationship that is a strategic

dependency such that its dependum

component is a resource

softgoal dependency SOFTGOALDEPENDENCY relationship that is a strategic

dependency such that its dependum

component is an istar.softgoal

open dependency for the

depender

OPENFORDEPENDER relationship that is a strategic

dependency such that not obtaining

the dependum would affect the

depender to some extent but not

seriously

committed dependency for the

depender

COMMITTEDFORDEPENDER relationship that is a strategic

dependency such that not obtaining

the dependum would cause some

action for achieving a goal to fail in

the depender

critical dependency for the

depender

CRITICALFORDEPENDER relationship that is a strategic

dependency such that the depender

has goals which would be seriously

affected (in that all known courses of

action would fail) if the dependum is

not achieved

open dependency for the

dependee

OPENFORDEPENDEE relationship that is a strategic

dependency such that there is a claim

by the dependee actor that it is able to

achieve the dependum for some

depender

committed dependency for the

dependee

COMMITTEDFORDEPENDEE relationship that is a strategic

dependency such that the dependee

actor will try its best to deliver the

dependum, e.g., by making sure that

its own dependencies are viable

critical dependency for the CRITICALFORDEPENDEE relationship that is a strategic

17

dependee dependency such that the dependee

actor will make sure not only of the

viability of its own dependencies but

also about the viability of its

dependee’s dependencies and its

dependee’s dependee’s dependencies

and so forth

During the ontological analysis, we have realized that an istar.goal is not exactly a frisco.goal. FRISCO does not

elaborate deeply the concept of goal; it simply considers it an input actand that influences actions, which is

enough for the purposes of the conceptual framework at the time it was proposed, but is clearly insufficient for

the purpose of analyzing a goal-oriented modeling method. It is well known that intentionality is a complex

concept {Malle, 1997 #522}; it has many nuances that become important when dealing with a goal-oriented

approach. To keep this analysis simple, we have aligned istar.goal with a frisco.goal, but we have qualified it

properly to acknowledge the distinction.

The istar.actor concept deserves some attention. It is a generalization of the agent, role and position i-star

concepts that are rather different among them and are aligned to three different FRISCO constructs, i.e. agent is

aligned to frisco.actor, role to type (of frisco.actors) and position to set (of types of frisco.actors). Therefore,

istar.actor has to be mapped to the three different mentioned constructs suggesting it suffers from a construct

overload (a construct overload means having a single language construct representing two or more ontological

constructs). [Guizzardi, Franch and Guizzardi, 2012] that presents a rigorous analysis of a set of i-star concepts,

states that the istar.actor concept only captures general relations between agent, role and position and other

modeling elements and, thus, it has no specific interpretation in itself. From this assertion it follows that actor has

not overload. However, in this respect, it must be pointed out that, since the generalization that relates agent,

position and role to istar.actor is incomplete (as can be seen in Figure 1), the designer has the possibility of not

specializing one specific istar.actor to agent, role or position. The designer must be aware that this use of the

language gives raise to an overload for that specific actor because it can be interpreted in three different ways.

This is not necessarily a bad property of the language since: 1) the overload can be avoided by simply

specializing the actor and, 2) for practical reasons, the designer might not be interested in discriminating between

the different interpretations in specific cases.

We observe that the resource concept has two different mappings to FRISCO constructs depending on whether

the resource is physical or informational. On the one hand, informational resource maps to “data that is the input

actand of an action”. On the other hand, since a physical resource cannot correspond to the data concept, it is

mapped solely to “input actand of an action”. This is a case of having a single language construct (resource)

representing two ontological constructs which are significantly different. The i-star language does not provide

the means to distinguish physical from informational resources. Therefore, the conclusion is that the resource

construct suffers from overload.

The mapping of the dependum concept might suggest a construct overload too, since a dependum may

correspond to several FRISCO constructs such as a goal or an action. However, we think this is not the case.

Dependum serves the purpose of capturing general relations between different i-star elements such as goals or

tasks and other modeling elements. Therefore, and similarly to the i-star actor concept, dependum has no specific

interpretation in itself. Additional similar cases are those of depender and dependee.

2.2. Ontological analysis of Communication Analysis

Table 5 provides a mapping between the constructs of Communication Analysis and the constructs of the

FRISCO 1.1 ontology.

With regards to the constructs of Communication Analysis, we distinguish between meta-class (of the method

metamodel) and concept (of the method); this provides an additional analysis of the extent to which the

particular metamodel (one among the many possible supports to the method) covers the concepts of the method.

Also note that, for the sake of brevity, we refer to some Communication Analysis concepts within the FRISCO 1.1

definitions; in such cases we use apostrophes (as Opdahl et al. do in [1999]). For instance, we refer as “business

18

object” to a predicated thing which is not a predicator, a relationship or a state, and it is part of the domain

model.

Table 5. Mapping among constructs of Communication Analysis and the reference ontology

Communication Analysis construct FRISCO 1.1 construct

Concept Metaclass Concept

L1 organisational system

(adopted)

ORGANISATION organisational system

organisational unit ORGANISATIONAL_UNIT organisational sub-system

organisational location ORGANISATIONAL_LOCATION N/A

organisational goal GOAL goal of an actor of an organisational

system

business indicator INDICATOR N/A

organisational strategy STRATEGY composite thing mainly consisting of

a set of operationalised goals

L2 organisational actor ORGANISATIONAL_ACTOR goal-pursuing actor

organisational role ORGANISATIONAL_ROLE type of goal-pursuing actors

business process PROCESS sub-system of the subject system,

often expressed as a norm

communicative

interaction

out of scope;

COMMUNICATIVE_INTERACTION is an

abstract meta-class

sequence of message transfers

ingoing communicative

interaction

INGOING sequence of message transfers;

related to the formulation of

regulated transition information

outgoing communicative

interaction

OUTGOING sequence of message transfers;

related to the formulation of recalled

facts

communicative event

unity criteria

out of scope;

not a modelling primitive but a

modelling guideline

set of rules which determine how

achieve modular business process

models (it corresponds to the concept

of unity criteria of the conceptual

framework for model modularity)

communicative event COMMUNICATIVE_EVENT composite transition

communicative event

occurrence

out of scope;

not part of an IS metamodel

transition occurrence

event variant EVENT_VARIANT transition taking part of a state-

transition structure of type choice

that defines a communicative event

primary role PRIMARY type of goal-pursuing actors, more

specifically a set of regulated-

transition observers

primary actor out of scope;

not part of an IS metamodel

goal-pursuing actor acting as a

regulated-transition observer

receiver role RECEIVER type of goal-pursuing actors, more

specifically a set of recalled facts

receivers

19

receiver actor out of scope;

not part of an IS metamodel

goal-pursuing actor acting as a

recalled facts receiver

precondition not a metaclass, but an attribute of

one:

ENCAPSULATION.precondition

norm that determines permissible

transition occurrences

precedence relation,

which is part of the

precondition

PRECEDENCE norm that determines permissible

transition occurrences

business object out of scope;

not part of an IS metamodel

predicated thing which is not a

predicator, a relationship or a state,

and it is part of the domain model

business object class BUSINESS_OBJECT_CLASS a type of “business object”; it is part

of the language of the domain model

L3 message structure MESSAGE_STRUCTURE type of messages; it is an input actand

of a composite transition (i.e. the

“communicative event”)

business object class

property

BUSINESS_OBJECT_FIELD predicator of “business objects”; it

acts as a norm that is part of the

language of the domain model

business object

representation

out of scope;

not part of an IS metamodel

representation that is part of the

domain model denotation

L4 support role SUPPORT type of goal-pursuing actors

support actor out of scope;

not part of an IS metamodel

goal-pursuing actor

2.3. Analysis of overlapping concepts

In this section, we present the use of the FRISCO ontology to find related concepts of the i-star and the

Communication Analysis requirements engineering models. We take as departing point the previous ontological

mappings and we analyse the concepts that map to the same or related FRISCO constructs because they are

candidates for the integration. We prefix concepts with ‘istar’, ‘CA’ or ‘frisco’ to stress if they belong to i-star,

Communication Analysis or FRISCO ontology, respectively. The candidates for the integration are the following:

1) istar.agent and CA.organisational actor. These two concepts map onto related FRISCO concepts

(frisco.goal-pursuing actor is a specialization of frisco.actor). Additionally, istar.agent is qualified as

having physical manifestation and know-how. We interpret this additional qualification as compatible

and also applicable to CA.organisational actor. Therefore, we consider the two concepts as overlapping.

2) istar.role and CA.organisational role. An istar.role maps into a type of frisco.actors such that it

characterizes their behaviour and a CA.organisational role maps into a type of goal-pursuing

frisco.actors. Then, these two concepts overlap, too.

3) istar.goal and CA.goal. An istar.goal maps into a frisco.goal that is an intentional desire of an actor and a

CA.goal maps into a frisco.goal of an actor of an organizational system. Then, both concepts map into a

frisco.goal with similar qualifications since both state that it belongs to an actor. Thus, we interpret that

istar.goals and CA.goals overlap.

4) istar.task and CA.communicative event. An istar.task maps into a frisco.action that involves one actor in

its pre-state and post-state and and a CA.communicative event maps into a composite frisco.transition.

Since a frisco.action is a transition involving a non-empty set of actors and a composite frisco.transition is

a structure of transitions (related by sequence, choice or concurrency structures), we can interpret that

the two concepts overlap under certain conditions. Since a istar.task involves exactly one actor, in cases

20

where a specific CA.communicative event involves more than one actor it will map into several tasks

(one for each involved actor). It must also be accomplished (for a specific task and communicative event

to overlap) that their level of modularity is the same. The Communcation Analysis method provides a

set of unity criteria to identify and encapsulate communicative events that help to define them at an

adequate level of modularity (see [González, España and Pastor 2009] for details). Therefore, a istar.task

maps into a CA.communicative event only if satisfies that unity criteria.

5) istar.resource and CA.message structure. An informational istar.resource maps into data that is the input

actand of an action such that an actor desires its provision. A CA.message structure maps into a type of

messages and it is an input actand of a composite transition. According to the FRISCO ontology, a

message is data transmitted by one actor (the sender) via a channel and intended for a non-empty set of

actors. Hence, we interpret that an informational istar.resource maps into a CA.message structure. On

the other hand, a physical istar.resource does not map into data. Therefore, we interpret that it does not

overlap to a CA.message structure due to the informational nature of the latter. Summing up, a

istar.resource maps into a CA.message structure only if it is informational.

3. METHODOLOGICAL INTEGRATION

Our intention is to facilitate applying i* and Communication Analysis combinedly, in engineering scenarios

where the analysis of the organisation and its business processes is undertaken by using the models proposed by

both methods.

To properly integrate i* and Communication Analysis, we first integrate their modelling languages from a

syntactic perspective by integrating the corresponding metamodels (shown in Sections 1.1 and 1.2). Then we

provide modelling guidelines that include semantic aspects and that take into account the pragmatic engineering

goal we have in mind.

3.1. Integration of the metamodels

To integrate i* and Communication Analysis metamodels, we analysed the overlapping concepts presented in

Section 2.3. For each pair of overlapping concepts we need to decide whether we keep both metaclasses or we

only keep one metaclass. We provide some heuristics to make such decision and the implications of each choice.

METAMODEL 2

METAMODEL 1

A

C D

B

METAMODEL 2

METAMODEL 1

A

D

B

METAMODEL 2

METAMODEL 1

A

D

B

C

a) Example of two metamodels to

integrate

b) Integration of metamodels

Case of concepts totally

equivalent (A≡C)

c) Integration of metamodels

Case of concepts aligned under

specific conditions

(A≅C)

Figure 7. Deciding which metaclasses to keep

In order to illustrate the heuristics to integrate both metamodels, the Figure 7 presents an example of two

metamodels to integrate and how to apply the heuristics. The exemplified metamodels are composed of generic

concepts without a specific method (see Figure 7 a.).

In some cases, both concepts are totally equivalent, in the sense that its alignment is clear-cut. In such cases, we

propose to only keep one metaclass. As a consequence, it needs to be decided which of the two metaclasses is

removed. Then, the relationships in which the removed metaclass participated need to be connected to the

metaclass that is kept (see Figure 7 b.).

21

In other cases, the alignment of two concepts is qualified with a condition or a statement clarifying under which

circumstances both concepts can be considered aligned. In such cases, we propose to keep both metaclasses. A

new relationship is created between both metaclasses (see Figure 7 c.).

In our specific case, we found three specific metaclasses in the Communication Analysis metamodel with

concepts totally equivalents to the i* metamodel (ORGANIZATIONAL_ROLE, ORGANIZATIONAL_ACTOR and GOAL).

According to the Communication Analysis metamodel, these metaclasses are part of the metamodel support for

the system/subsystem level [España, González et al. 2009]. This level is related to the point of view of

organisational structure and strategy; i.e. the information needed to manage the enterprise. The Communication

Analysis metamodel does not have enough support for modelling complex organisations. The metaclasses

provided in the Communication Analysis metamodel were conceived as a start point to allow a metamodel

extension with methods that are aiming to modelling strategy and goals.

As a result of this analysis, we have decided to use the concepts provided by the i* framework to extend

Communication Analysis metamodel. Following the heuristics to make decisions presented in Figure 7, it is

possible to propose an analysis of integration for each concept.

Figure 8 presents a view of the overlapping analysis for the GOAL concept. The metaclass GOAL in Communication

Analysis metamodel is replaced by the metaclass GOAL of the i* metamodel (see Figure 8 b.).

COMMUNICATION ANALYSIS METAMODEL

i* METAMODEL

/ID

DESCRIPTION

COMMUNICATIVE

_EVENT

NAMEDESCRIPTION

GOAL

GOALS EVENTS

0:M0:M

INTENTIONAL_ELEMENTGOAL

COMMUNICATION ANALYSIS METAMODEL

i* METAMODEL

/ID

DESCRIPTION

COMMUNICATIVE

_EVENT

GOALS

EVENTS

0:M

0:M

INTENTIONAL_ELEMENTGOAL

a) Views of i*metamodel and Communication

Analysis metamodel

b) Views integrated of i*metamodel and

Communication Analysis metamodel

Figure 8. Overlapping analysis of GOAL concept

The same analysis was applied to the metaclasses ORGANIZATIONAL_ROLE and ORGANIZATIONAL_ACTOR.

i* METAMODEL

COMMUNICATION ANALYSIS METAMODEL

NAME

DESCRIPTION

DUTIES

ORGANISATIONAL_

ROLE

0:M

1:1ORG_ROLE

COM_ROLES

AGGREGATION

IS_INTERFACE_ACTOR

COMMUNICATIVE_

ROLE

0:10:1

ROLE

AGGREGATION

FIRST_NAMELAST_NAMEPHONE_NUMBERCOMMENTS

ORGANISATIONAL_ACTOR

ROLES

0:M 0:M

ACTORS

ACTOR

AGENT POSITION ROLE

i* METAMODEL

COMMUNICATION ANALYSIS METAMODEL

0:M

1:1

COM_ROLE

ROLE

AGGREGATION

IS_INTERFACE_ACTOR

COMMUNICATIVE_

ROLE

0:1

0:1 ROLE

AGGREGATION

ACTOR

AGENT POSITION ROLE

a) Views of i*metamodel and Communication Analysis

metamodel

b) Views integrated of i*metamodel and

Communication Analysis metamodel

Figure 9. Overlapping analysis of ORGANIZATIONAL_ROLE and ORGANIZATIONAL_ACTOR concepts

In order to carry out the integration, first, subsets of both metamodels are having into account during the

integration process. Figure 1 presents the metamodel of the i* framework that was used in the integration

process. In this case, the complete metamodel is used. In the case of Communication Analysis, a subset of the

metamodel is used to take advantage of some concepts of the i*framework that are defined with more detail than

Communication Analysis.

The top of the Figure 4 presents the support that should be offered to support the requirements level L1

(system/subsystem, see Figure 2). Due to there are not goal analysis support and organisational strategy support

22

for this requirements level, the metaclasses that are part of this level are omitted: ORGANISATIONAL_LOCATION,

ORGANISATIONAL_MODULE, STRATEGY, ORGANISATION, ORGANISATIONAL_UNIT, OPERATIONALISATION, INDICATOR, GOAL,

ORGANISATIONAL_ACTOR and ORGANISATIONAL_ROLE. In the case of Level L3 (requirements level), a set of

metaclasses of this level are omitted in order to align both metamodels this view of the analysis are not

necessary. The metaclases are: TEXTUAL_REQUIREMENTS and its specialisations.

Figure 10 presents the metamodel integration; red lines indicate relationships among metaclasses of different

metamodels in case of complementary metaclasses. In addition, we could distinguish that the metaclasses

ORGANIZATIONAL_ROLE, ORGANIZATIONAL_ACTOR and GOAL that are part of the Communication Analysis metamodel

were identified as “overlapped metaclasses”, in this way, the metaclasses ROLE, AGENT and GOAL belong to i*

metamodel are chosen as the metaclasses to be instanced.

NODE

name: String

INTENTIONAL_ELEMENTDEPENDENCY DEPENDUM

CONT_TYPE

MAKE

HELP

SOME+

UNKNOWN

SOME-

HURT

BREAK

OR

AND

GOAL

TASK

RESOURCE

SOFTGOAL

BELIEF

SOFT_GOAL_DEPENDENCYRESOURCE_DEPENDENCYTASK_DEPENDENCYGOAL_DEPENDENCY

DEPENDENCY_PARTICIPANT

ACTOR

AGENT POSITIONROLE

INTERNAL_ELEMENT

TYPE: CONT_TYPE

IE_LINK

TASK_DESCOMPOSITION MEANS_END CONTRIBUTION_TO_SOFTGOAL

FROM*

TO*

*

* TO

FROM

*DEPENDER 1

DEPENDEE 1 *

11..*

BOUNDARYBELONGS TO

1

*

NAME

DESCRIPTION

COMMUNICATIVE_

INTERACTION

/ID

DESCRIPTION

COMMUNICATIVE

_EVENT

/IDSPEC_COND

EVENT_

VARIANT

0:M

1:1SPECIALISATIONS

GENERALISATION

NAMEACRONYMDESCRIPTION

PROCESS

EVENTS 1:1

PROCESS1:M ID

SUPPORT

RECEIVER

PRIMARY

PRECEDENCE

LOGICAL_NODE

OR

AND

NODE TARGET

INCOMING0:M

1:1

1:1

0:MOUTGOING

SOURCE

END

PRIMARY IN1:11:1

RECEIVER OUT1:10:M

SUPPORTS

1:1INTERACTION

0:M 0:M

1:1ENCAPS

OUTS

COMPLEX_

SUBSTRUCTURE

0:M

1:1 MESSAGE_STR

INTERACTIONS

NAMEDESCRIPTION

BUSINESS_

OBJECT_CLASS

FIELDS

OBJECT_CLASS1:1

0:M

START

NAMEDESCRIPTION

BUSINESS_

OBJECT_FIELD

0:M0:M

OBJECT_CLASSESINTERACTIONS

NUMBER

NAME

PRECONDITION

ENCAPSULATION

1:11:1

IN EVENT

INGOING

OUTGOING

SPECIALISATION

AGGREGATION

ITERATION

IS_INTERFACE_ACTOR

COMMUNICATIVE_

ROLE

NAME

DESCRIPTION

MESSAGE_

STRUCTURE

0:1

1:1

INITIAL

MESSAGE_STR

COM_ROLES

ROLE1:1

0:M

AGGREGATION

ROLE

0:1

0:1

GOALS

EVENTS0:M

0:M

TASKS

EVENTS1:1

0:M

RSC

MS

0:M

0:M

Figure 10. Integration of i*metamodel and Communication Analysis metamodel

4. IMPLEMENTATION

A technological support for the i* and Communication Analysis modelling languages is necessary to carry out

validations and future case studies. Metamodel and modelling supports are the core to build a framework with

metamodel integration capabilities. In this section we analyse existing metamodel implementation of both

modelling languages in order to select the most convenient technological support. In addition, we present

different analysis to select the most appropriated metamodel. As a result, a modelling tool that integrates the

methods will be presented.

23

We chose Eclipse (an open-source project to develop model-driven tools) as a technological platform. We used

Eclipse technologies such as Eclipse Modelling Framework (EMF)2 and Graphical Modelling Framework (GMF)3

to implement the metamodels and modelling tools for each method.

We have followed a Model-Driven Architecture (MDA) approach in order to develop a modelling tool for both

modelling methods. This way, the specification of Communication Analysis and i* (see section 1) correspond to

the Computation-Indepentend Model (CIM) layer of MDA. The abstract syntax of both methods are represented

by means of Platform-Independent Metamodels (PIMm) (see Figure 1 and Figure 4), which correspond to

Platform-Independent Model (PIM) layer of MDA. Accordingly with these PIMm, we have specified the

Platform-Specific Metamodels (PSMm) that are compliant with Eclipse technologies. These PSMm corresponds to

Platform-Specific Model (PSM) layer of MDA. Finally, we defined the concrete syntax of both languages

(graphical and textual appearance). The implemented modelling tools correspond to the Code Model (CM) layer

of MDA.

4.1. Communication Analysis modelling tool

4.1.1. Platform-specific metamodel for Communication Analysis

requirements models

Previous works present a Platform-Specific metamodel for Communication Analysis requirements models

(PSMmca) [Ruiz 2011]. This PSMmca involves a system/subsystem level, which corresponds with strategic

description of the organisation. Nevertheless, support for managing goal models and enterprise information is

missing. For this reason, we present an adaptation of PSMmca to specify business processes and requirements by

means of Message Structures (MS) and Communicative Event Diagrams (CED). These requirements models are

part of the process level and communicative interaction level. In order to integrate i* metamodel with CA

requirements metamodel, as we explained in section 3, the metaclasses corresponding with organisation and goal

information are omitted (ORGANISATIONAL_ROLE, ORGANISATIONAL_ACTOR, ORGANISATIONAL_ROLE_SET, GOAL,

OPERACIONALISATION, INDICATOR, STRATEGY, ORGANISATIONAL_MODULE, ORGANISATION, ORGANISATIONAL_LOCATION,

ORGANISATIONAL_UNIT).

Figure 11 shows the PSMmca. Information about metaclasses and relationships are detailed in {Ruiz, 2011 #33}.

2 http://www.eclipse.org/modeling/emf/

3 http://www.eclipse.org/modeling/gmp/

24

Figure 11. PSMm for Communication Analysis requirements models

The PSMmca is compliant with GMF technologies, for this reason, some metaclasses are added in order to

specify information related to graphical settings (e.g. the metaclass MODEL describes information about a

Communication Analysis requirements model. In addition, this metaclass is a container of elements).

25

4.1.2. CA modelling tool

We have developed a modelling tool in order to model communicative event diagrams. Figure 12 shows the

modelling tool to model communicative event diagrams.

Figure 12. Modelling tool for Communication Analysis requirements models. Example of SuperStationery Co.

4.2. I* modelling tool

4.2.1. Design of platform specific metamodel for i*

There are several metamodels to specify i* models. We analysed a PIM metamodel presented by {Lopez, 2011

#31}. This metamodel should be adapted to fulfil the requirements of GMF technologies. To design a PSM

metamodel for i* (PSMmi*), we have analysed three tool-oriented metamodels for i*. The first metamodel

analysed is the openome metamodel. The second metamodel analysed is a proposal presented by Giachetti 2011

{Giachetti, 2011 #34}. These metamodel is very appropriated because is gmf-oriented. The third metamodel

analysed is a proposal that aims at establish a unified metamodel for i* {Santos, 2008 #36}. We use this version to

model dependency relationships.

We decided to maintain the most of concepts concerning to the PIM metamodel for i* analysed in Section 3. For

this reason, we have adapted this metamodel with metaclasses and relationships in order to fulfil the GMF

technology requirements.

26

Figure 13 presents the PSMmi*, metaclasses and relationships in black are added in order to fulfil the GMF

technology requirements. Metaclases and relationships in gray are part of the PIM metamodel for i*.

Figure 13. PSM metamodel for i* language

27

4.2.2. Implementation of the i* modelling tool

4.3. Integration of modelling tools

4.3.1. Integration of PSMmCA and PSMmi*

28

4.3.2. Integrated modelling tools

REFERENCES

Andersson, B., M. Bergholtz, A. Edirisuriya, T. Ilayperuma, P. Jayaweera, P. Johannesson and J. Zdravkovic (2008a). Aligning goal models and business models - extended abstract. CAiSE'08 Forum. Z. Bellahsene, C. Woo, E. Hunt, X. Franch and R. Coletta. Montpellier, France, CEUR. 344: 13-16.

Andersson, B., M. Bergholtz, A. Edirisuriya, T. Ilayperuma, P. Jayaweera, P. Johannesson and J. Zdravkovic (2008b). Enterprise sustainability through the alignment of goal models and business models. 3rd International Workshop on Business/IT-Alignment and Interoperability (BUSITAL'08), CEUR.

Andersson, B., I. Bider, P. Johannesson and E. Perjons (2005). "Towards a formal definition of goal-oriented business process patterns." Business Process Management Journal 11(6): 650-662.

Andersson, B., A. Edirisuriya, T. Ilayperuma, M. Bergholtz, P. Johannesson and J. Zdravkovic (2007). On the alignment of goal models and business models. REA-25 - A celebration of REA enterprise model. G. L. Geerts. University of Delaware, Departament of Accounting & MIS.

Andersson, B., P. Johannesson and J. Zdravkovic (2009). "Aligning goals and services through goal and business modelling." Information Systems and e-Business Management 7(2): 143-169.

Cardoso, E., J. P. A. Almeida, R. S. S. Guizzardi and G. Guizzardi (2011a). "A method for eliciting goals for business process models based on non-functional requirements catalogues." International Journal of Information System Modeling and Design 2(2): 1-18.

Cardoso, E., J. P. A. Almeida, R. S. S. Guizzardi and G. Guizzardi (2011b). "A Method for Eliciting Goals for Business Process Models based on Non-Functional Requirements Catalogues." International Journal of Information System Modeling and Design (IJISMD) 2(2).

Cardoso, E. C. S., J. P. A. Almeida, G. Guizzardi and R. S. S. Guizzardi (2009). Eliciting goals for business process models with non-functional requirements catalogues. 10th Workshop on Business Process Modeling, Development, and Support (BPMDS 2009). T. Halpin, J. Krogstie, S. Nurcanet al, Springer LNBIP 29: 33-45.

Cardoso, E. C. S., R. S. S. Guizzardi and J. P. A. Almeida (2011). "Aligning goal analysis and business process modelling: a case study in health care." International Journal of Business Process Integration and Management 5(2): 144-158.

España, S. (2008). A generic model of Information Systems, Master thesis, Departamento de Sistemas Informáticos y Computación, Universitat Politècnica de València, Máster en Ingeniería del Software, Métodos Formales y Sistemas de Información

29

España, S. (2011). Methodological integration of Communication Analysis into a model-driven software development framework, PhD thesis, Research Centre in Software Production Methods (ProS), Universitat Politècnica de València, available http://hdl.handle.net/10251/14572

España, S., A. González and Ó. Pastor (2009). Communication Analysis: a requirements engineering method for information systems. 21st International Conference on Advanced Information Systems (CAiSE'09). Amsterdam, The Netherlands, Springer LNCS 5565: 530-545.

España, S., A. González, Ó. Pastor and M. Ruiz (2011). Integration of Communication Analysis and the OO-Method: Manual derivation of the conceptual model. The SuperStationery Co. lab demo. Technical report ProS-TR-2011-01, ProS Research Centre, Universitat Politècnica de València, Spain, http://arxiv.org/abs/1101.0105

Falkenberg, E. D., W. Hesse and P. Lindgreen (1998). A framework of information system concepts, IFIO WG.

González, A., S. España and Ó. Pastor (2009). Unity criteria for Business Process Modelling: A theoretical argumentation for a Software Engineering recurrent problem. Third International Conference on Research Challenges in Information Science (RCIS 2009). Fes, Morocco, IEEE: 173-182.

Guizzardi, G. (2005). On a unified foundational ontology and some applications of it in business modeling. Ontologies and business systems analysis. M. Rosemann and P. Green (ed.), IDEA Publisher.

Guizzardi, G., L. F. Pires and M. van Sinderen (2005). An ontology-based approach for evaluating the domain appropriateness and comprehensibility appropriateness of modeling languages. ACM/IEEE 8 th International Conference on Model Driven Engineering Languages and Systems (MoDELS 2005): 691-705.

Guizzardi, R. S. S., G. Guizzardi, J. P. A. Almeida and E. Cardoso (2010a). Bridging the Gap between Goals, Agents and Business Processes. Fourth International i* Workshop. Hammamet, Tunisia.

Guizzardi, R. S. S., G. Guizzardi, J. P. A. Almeida and E. C. S. Cardoso (2010b). Bridging the gap between goals, agents and business processes. 4th International i* Workshop. J. Castro, X. Franch, J. Mylopoulos and E. Yu. Hammamet, Tunisia, CEUR-WS.org. 586

Halleux, P., L. Mathieu and B. Andersson (2009). A method to support the alignment of business models and goal models. BUSITAL. 8: 121-135.

Kavakli, V. and P. Loucopoulos (1999). "Goal-driven business process analysis application in electricity deregulation." Information Systems 24(3): 187-207.

Khomyakov, M. and I. Bider (2000). Achieving workflow flexibility through taming the chaos. 6th International Conference on Object Oriented Information Systems (OOIS 2000). D. Patel, I. Choudhury, S. Patel and S. d. Cesare, Springer: 85-92.

Koliadis, G. and A. Ghose (2006). Relating business process models to goal-oriented requirements models in KAOS. Advances in Knowledge Acquisition and Management. A. Hoffmann, B.-h. Kang, D. Richards and S. Tsumoto (ed.). Berlin, Springer. LNCS 4303: 25-39.

Kueng, P. (2005). "Goal-oriented process modelling - expert view." Business Process Management Journal 11(6): 624-627.

Kueng, P. (2005 ). "Goal-oriented process modelling - expert view." Business Process Management Journal 11(6): 624-627.

Kueng, P. and P. Kawalek (1997). "Goal-based business process models: creation and evaluation." Business Process Management Journal 3(1): 17-38.

Lopez, L., X. Franch and J. Marco (2011). Making Explicit Some Implicit i* Language Decisions. 30th International Conference on Conceptual Modeling (ER 2011). Brussels, Belgium: 62-77.

Loucopoulos, P. and V. Kavakli (1999). Enterprise knowledge management and conceptual modelling. Conceptual modeling: Current Issues and future directions. P. Chen, J. Akoka, H. Kangassalu and B. Thalheim (ed.), Springer.

Milton, S. and E. Kazmierczak (2004). "An ontology of data modelling languages: a study using a common-sense realistic ontology." Journal of Dababase Management 15(2): 19-38.

Milton, S., E. Kazmierczak and C. Keen (2001). An ontological study of data modelling languages using Chisholm’s ontology. 11th European-Japanese Conference Information Modelling and Knowledge Bases, Maribor.

Morrison , E. D., A. K. Ghose, H. K. Dam, K. G. Hinge and K. Hoesch-Klohe (2011). Strategic alignment of business processes. 7th International Workshop on Engineering Service-Oriented Applications. Paphos, Cyprus.

30

Nunes, N. J. and J. F. e. Cunha (2000). "Wisdom: a software engineering method for small software development companies." IEEE Software 17(5): 113-119.

Opdahl, A. L. and B. Henderson-Sellers (1999). Evaluating and improving OO modelling languages using the BWW-Model. Ontology, Semiotics and Practice 1999 - Information Systems Foundations Workshop, Sydney, Australia, Macquarie University.

Opdahl, A. L. and B. Henderson-Sellers (2002). "Ontological evaluation of the UML using the Bunge–Wand–Weber model." Software and Systems Modelling 1(1): 43-67.

Opdahl, A. L., B. Henderson-Sellers and F. Barbier (1999). An ontological evaluation of the OML metamodel. IFIP TC8/WG8.1 International Conference on Information System Concepts: an integrated discipline emerging. E. Falkenberg, K. Lyytinen and A. Verrijn-Stuart. Univerity of Leiden, The Netherlands, Kluwer: 217-232.

Opdahl, A. L., B. Henderson-Sellers and F. Barbier (2000). An ontological evaluation of the OML metamodel. Proceedings of the IFIP TC8/WG8.1 International Conference on Information System Concepts: An Integrated Discipline Emerging, Kluwer, B.V.

Pastor, O., S. España and A. González (2008). An ontological-based approach to analyze software production methods. Information Systems and e-Business Technologies. United Information Systems Conferences (UNISCON 2008). R. Kaschek, C. Kop, C. Steinberger and G. Fliedl. Klagenfurt, Austria, Springer Lecture Notes in Business Information Processing (LNBIP). 5: 258-270.

Pastor, Ó., J. Gómez, E. Insfrán and V. Pelechano (2001). "The OO-method approach for information systems modeling: from object-oriented conceptual modeling to automated programming." Information Systems 26(7): 507-534.

Pastor, O., A. González and S. España (2007). Conceptual alignment of software production methods. Conceptual modelling in information systems engineering. J. Krogstie, A. L. Opdahl and S. Brinkkemper (ed.). Heidelberg, Germany, Springer: 209-228.

Pastor, O. and J. C. Molina (2007). Model-Driven Architecture in practice: a software production environment based on conceptual modeling. New York, Springer.

Pavlovski, C. J. and J. Zou (2008). Non-functional requirements in business process modeling. 5th Asia-Pacific Conference on Conceptual Modelling. Wollongong, NSW, Australia, Australian Computer Society, Inc. 79: 103-112.

Rational (2003). Rational Unified Process version 2003.06.00.65, Rational Software Corporation. Ruiz, M. (2011). A model-driven framework to integrate Communication Analysis and OO-Method,

Departamento de Sistemas Informáticos y Computación (DSIC), Universitat Politècnica de València

Soffer, P. and Y. Wand (2005). "On the notion of soft-goals in business process modeling." Business Process Management Journal 11(6): 663-679.

Wand, Y., D. Monarchi, J. Parsons and C. Woo (1995). "Theoretical foundations for conceptual modeling in information systems development." Decision Support Systems 15.

Wand, Y. and R. Weber (1990). "An ontological model of an information system." IEEE Transactions on Software Engineering 16(11): 1282 -1292.

Weber, R. (1997). Ontological foundations of information systems. Queensland, Australia, Coopers & Lybrand.

Weber, R. (1999). The Information Systems discipline: The need for and nature of a foundational core. IS Foundations Workshop; Ontology, Semiotics and Practice, Macquarie University.

Yu, E. and J. Mylopoulos (1994). From E-R to "A-R" - Modelling strategic actor relationships for business process reengineering. Proceedings of the13th International Conference on the Entity-Relationship Approach. Manchester, Springer-Verlag: 548-565.