My Struggles with Interactions and Collaborations

Copyright Avancier Ltd 2106



A UML interaction diagram is a behavioral view of how roles cooperate in a process.

A UML collaboration diagram is a structural view that associates the roles in an interaction (or more than one? tbd).

A collaboration should include nothing irrelevant to the collaboration.

A collaboration is realized in persistent role/interface definitions that specify what actors can ask each other to do in transient interactions.


Using ArchiMate, you can draw a diagram that connects an N-way interaction to the N roles involved.

First, you draw a collaboration box to represent an N-way association between roles, then attach a box representing the N-way interaction to it.

ArchiMate further defines collaboration as a specialization of component and an aggregate of roles.

This paper is about whether those definitions make sense.


ArchiMate first defines a collaboration as temporary, and later defines it as logical or temporary.

Does such an abstract or transient concept truly inherit all the properties of component?

The roles associated in a collaboration are the same as the roles named in interactions attached to the collaboration

But what an actor does during an interaction is usually only part of a broader role.

Does a collaboration truly aggregate roles, or only associate roles?


This paper explores these and other uncertainties and ambiguities; it is partly illustrated in a related slide show (which lags behind this paper).

Aside on natural language v modeling language

The natural language used by system stakeholders is one thing; it is loose, ambiguous, contradictory, ever evolving.

The controlled language needed in a professional system modeling language is another.


We use the nouns “cooperation”, “collaboration” and “interaction” both interchangeably and with different nuances.

We use them when speaking of transient behaviors and persistent arrangements, and speaking of specific instances and general types.


These five sentences sound plausible:

·         The cooperation between 2 or more roles can be modeled in a process flow chart.

·         A cooperation between 2 or more actors happens in a process performance.

·         A cooperation is a performance of activities by 2 or more actors.

·         A cooperation is performed by an interaction of 2 or more actors.

·         A cooperation is an arrangement between interacting parties.


These sentences sound just as plausible:

·         The collaboration between 2 or more roles can be modeled in a process flow chart.

·         A collaboration between 2 or more actors happens in a process performance.

·         A collaboration is a performance of activities by 2 or more actors.

·         A collaboration is performed by an interaction of 2 or more actors.

·         A collaboration is an arrangement between interacting parties.


Most if not all these sentences sound plausible too:

·         The interaction between 2 or more roles can be modeled in a process flow chart.

·         An interaction between 2 or more actors happens in a process performance.

·         An interaction is a performance of activities by 2 or more actors.

·         An interaction is performed by a collaboration of 2 or more actors.

·         An interaction is an arrangement between collaborating parties.


We manage to converse using these words in a loose way without argument.

That doesn’t mean each word is readily attached to distinct and valuable concept in diagrams that represent human and computer activity systems.


In natural language, we often blur the distinction between types and instances.

In a controlled vocabulary (which a modelling language should be) distinguishing types and instances is more important. 

The types in modelling languages, such as role or process, are generic system elements.

The types in models, such as student or application, are specialisations of the more generic types.

Instances are particular things, such as an identifiable student or application-in-progress, that appear at runtime in reality.


For precision of specification, the UML standard distinguishes types from instances using different words.

Currently, the ISO 42010, TOGAF and ArchiMate standards tend to blur the type/distinction.

It is possible to imagine the ArchiMate standard drawing out the distinction as this table indicates.










People say ArchiMate draws no type/instance distinction as though it is virtue, and questions about types and instances are invalid.

Nevertheless, some types in a system description must be instantiated as actors in an operational system.

And some ArchiMate sentences mean different things depending on whether the words apply to types or instances.

Does “component” mean component type or a component instance?

Does “two or more active structure elements” refer to two or more roles, or two or more actors?

Does “interface” refer to a general interface definition, or the interface of an active component?

Scenarios to get you thinking

A process with two or more roles may not always need two or more actors.

Consider the following system migration path in which internal (employee) agents and external agents interact/collaborate/cooperate to process requests to book travel.


Baseline state: an internal agent/actor acts alone, never involves an external agent.

You draw a structure diagram showing Book Travel as a process box, connected to the internal agent role box by an assignment relationship line.


Transition state 1: an internal agent/actor may engage an external agent/actor.

The Book Travel type (in a flow chart or interaction diagram) must include two roles.

A Book Travel instance might not include two actors.

So, a Book Travel instance is always a process performance and sometimes an interaction also. Options include:


1.      draw an “association” line between the 2 roles and write <Books Travel with> on it

2.      draw a “used by” or “serves” line from the external role to the internal role

3.      draw a process box, and attach it by “assignment” lines to the 2 roles

4.      draw an interaction box , and attach it by “aggregation” lines to the 2 roles?


You can do the first three without ever thinking about, naming or drawing a collaboration element.

But on trying to draw the fourth, your CASE tool may insist you first attach a collaboration box between the two roles, then attach the interaction box to it.

Suppose you are not sure whether it is the right thing to do, so you stick with option 3 above for now.


Transition state 2: an internal agent/actor always engages an external agent/actor.

The Book Travel flow chart must include two roles; a Book Travel instance must include two actors.

Every Book Travel instance is now both a process performance and an interaction.

So you now decide to replace the Book Travel process box on the diagram by an interaction box.

You find your CASE tool insists you first attach a collaboration box between the two roles, then attach the interaction box to it.


Transition state 2: Internal agent/actors both find and select external agent/actors (to play the external agent role) on an ad-hoc basis.

If collaboration and interaction have the same life time, are they the same thing?

(And the collaboration would be the same thing as any other interaction attached to it.)


Target state: Internal agents and external agents must form agreements before cooperating in bookings.

Might you see these agreements as persistent collaborations under whose overarching structure interactions are allowed?


ArchiMate says an interaction is "a unit of collective behavior performed by (a collaboration of) two or more active structure elements".

I say an interaction box represents a logical and temporary cooperation of actors playing different roles in a process.

I don’t feel the need to mention the concept of a collaboration in this definition.


You might never draw an interaction box, because you can represent a behavior as service or process box instead.

But you should know what the box ought to mean in somebody else’s diagram (see above).

And know that ArchiMate says to draw a collaboration box before attaching an interaction box to it.


It is easy to say explain when ArchiMate requires a collaboration box in a diagram, but harder to explain why, and what it means.


ArchiMate offers several definitions of a collaboration, which seem to me not entirely consistent or entirely coherent.

Sometime it seems like an aggregate of roles – but only part-roles in interactions attached to that specific collaboration.

Sometime it seems like kind of component type – but one that cannot be instantiated.

It seems safer to think of it as an N-way association relationship between the N roles in one (or more) interactions.


“A collaboration is defined as a (temporary) grouping (or aggregation) of two or more structure elements, working together to perform some collective behavior.”

Temporary implies it has a start and an end; it is an instance that is instantiated for a period of time.

Later, the standard says “logical or temporary” which will be analyzed later.


It is easy to invent plausible sounding examples in natural language.

·         A travel booker is an aggregate of internal and external agents, working together to book travel.

·         An application is an aggregate of a thousand software components, working together to provide an information service.

·         A marriage is an aggregate of husband and wife, working to love, honour and obey each other.


But what is that aggregate collaboration exactly? When is it formed and destroyed or dispersed?

How does it differ from a behavior?  How does it perform behavior? It is the same as collaboration in UML?

Optional roles 

A collaboration is "an aggregate of two or more active structure elements, working together to perform a behavior.”

Are the elements roles, actors, or either? The lack of a type-instance distinction leads to some ambiguity. 


In our diagram, 2 interactions (A and B) are assigned to a 3-role collaboration.

In interactions of type B, one of the 3 roles is optional.

So an instance of interaction B may include only 2 actors.

Q1) Should we change the diagram in any way?


In our diagram, 3 interactions (B, C and D) are assigned to a 2-role collaboration.

In interactions of type D, one of the 2 roles is optional.

So an instance of interaction D may include only 1 actor.

Q2) Should we change the diagram in any way?

More scenarios to get you thinking

Suppose we have 3 actors (buyer A, seller B and broker C).

All 3 may appear in four different interactions (brokered sale, sale cancellation, sale return, annual statement of account).

So, we draw four different 3-way interaction diagrams.

OK, the questions surround what we mean by “role” and by “collaboration”.


Narrow roles specific to one interaction

Actors have different responsibilities in each of the four interactions.

We could define their small part in each interaction as a separate role, perhaps giving 12 roles in total.

And then define four collaborations, one for each interaction.

But that is not what people do in practice


An 2 of the 3 actors may appear also in their own 2-way interaction.

The prospect of defining several overlapping collaborations is not appealing.

The prospect of defining many narrow role definitions is even less appealing.

People usually aggregate narrow role responsibility definitions into broader roles.


Broad roles in N-way collaborations

Suppose we aggregate the actors’ parts in all interactions into 3 broad role definitions (buyer, seller and broker).

We can now define one 3-way collaboration, and attach all four interactions to it.

We can also define three 2-way collaborations, assuming there are corresponding 2-way interactions


Is the standard correct to define a collaboration as an aggregate of roles?

Surely a collaboration cannot be specified on its own?

Obviously, a collaboration associates the roles involved in an interaction.

The roles named in an interaction must be the roles related via the corresponding collaboration, and vice-versa.

With no collaboration between roles, there can be no interaction (that's a diagram drawing rule in ArchiMate).

With no concept of an interaction involving two or more roles, there can be no collaboration (that's a fact of life).


Structures (e.g. roles) are assigned to behaviors.

The responsibilities of a role must include the behaviors that actors in that role are asked to perform.

But it doesn't matter here whether "responsibility" corresponds exactly to “behavior” or not.

In practice, the responsibilities of a role are often (usually?) wider than the responsibilities relevant to one interaction that role appears in.

Further, one role may appear in several (2-way, 3-way, N-way) collaborations.

So the responsibilities of one role can be wider than the responsibilities exercised in any collaboration that role is related to.


UML is explicit that a collaboration excludes everything irrelevant to the collaboration.

Meaning it includes only all those responsibilities of roles relevant to an interaction associated with the collaboration.


An ArchiMate collaboration must be the same in so far as it aggregates role responsibilities relevant to related interactions

It does not include any other responsibilities of those roles, exercised in different collaborations.

Is it well defined as an aggregate of the broader roles?


Wife <is aggregated into> marriage <is aggregate of> husband.

That might be considered a sound statement, because wife and husband are narrow roles in the sense they have no meaning outside of marriage.


But drawing aggregation relationships to a collaboration seem misleading where the roles are broader.

E.g. customer <is aggregated into> sale <is aggregate of> salesman seems unsound

Because customer and salesman are broad roles that have responsibilities/behaviors outside of sale interactions.


Q) May an ArchiMate collaboration aggregate things that are irrelevant to the collaboration?

E.g. A Brokered Sale aggregates Buyer, Broker and Seller role responsibilities relevant to other 2-way collaborations?


Is the standard correct to define a collaboration as a specialization of a component?

ArchiMate has no concept of instantiation, no type-instance distinction

However, components must be instantiated as active structures before they can offer interfaces or perform behaviors at run time.

A collaboration cannot be instantiated to do things; only actors or components playing roles inside a collaboration can be instantiated.

So does the collaboration type really inherit from the component type.


In what sense does a collaboration exist?

An application collaboration typically models a logical or temporary collaboration of application components, and does not exist as a separate entity in the enterprise.”

Separate from what? The structural roles? A behavioral interaction?

When does it exist? During an interaction related to that collaboration?

When the first component involved in an interaction is instantiated? Or the second? Or all of them?

Surely a collaboration cannot be instantiated? Only its elements can be instantiated – and not necessarily at the same time?

Collaboration as N-way association

Behind every N-way collaboration is an N-way Association.

Because weaker relationships can stand in place of stronger ones.

E.g. wife <is aggregated into> marriage <is aggregate of> husband.

Can be relaxed to: wife <is associated with> marriage <is associated with> husband.

From which can be derived: wife <is associated with> husband.


Surely the definition of a collaboration would better be simplified?

If the standard said simply "a collaboration is an N-way association between the N roles involved in one in more interactions"

Then nobody would have to consider what it means for a collaboration to be an aggregate of roles or a specialization of a component. 

Because the more you think about those things, the harder it is to make sense of them, and they seem redundant to the standard.


If there is only one process/interaction involving two actors, then a diagram with both collaboration and interaction boxes is clunky.

But the collaboration box is a labor-saver that reduces the number of lines you need to draw when you place several interaction/process boxes (on a structural model diagram) and each of those interactions involve same actors or roles. 


In our example, the collaboration box acts as a connection point on an association between the 2 roles.

You can now attach several 2-actor behaviors to that 1 connection point.

And this saves you connecting each 2-actor behavior to both roles. (I am not sure I’d ever want to do that.)

UML collaboration – as I read it

A collaboration describes a structure of collaborating elements (roles), each performing a specialized function, which collectively accomplish some desired functionality.”

The purpose of a UML collaboration is to explain how communicating actors/components cooperate in roles to accomplish one or more tasks.

And to explain this in a structural view - without any irrelevant detail.

But note that a collaboration view is abstract; it explains less than an interaction diagram of the same scenario.


“Collaborations allow us to describe only the relevant aspects of the cooperation of a set of instances by identifying the specific roles that the instances will play.”

It identifies the roles played by actors within a related interaction; it must exclude any roles played by the same actors in other interactions.

So, the roles here are not necessarily the broad roles you might choose to define in your model.


UML’s main collaboration example shows three roles that cooperate in one interaction (a brokered sale).

As I read it, the brokered sale collaboration corresponds to only one interaction involving those three roles.

If it corresponded to any other interaction, then it would have to be renamed, and likely include detail irrelevant a brokered sale interaction.

So it seems the collaboration differs from the interaction only in that it is a structural rather than behavioral view of the same scenario.

It is a highly selective view of a structural model.


At some risk of misinterpretation, let me add the quote below:

“A collaboration specifies a view (or projection) of a set of cooperating classifiers.

It describes the required links between instances that play the roles of the collaboration, as well as the features required of the classifiers that specify the participating instances.

Several collaborations may describe different projections of the same set of classifiers.”

In other words (I think this tells us) several collaborations may describe different views of the same set of roles.

Each collaboration is a highly selective view of a structural model.


In UML, the definition of a collaboration is made in terms of roles’ interfaces.

A collaboration is often defined in terms of roles typed by interfaces.”

“An interface [describes] externally observable features required or provided by an instance.”

"A behavior of a collaboration will eventually be exhibited by a set of cooperating instances that communicate with each other by sending signals or invoking operations".

"Collaborations allow us to describe only the relevant aspects of the cooperation of a set of instances by identifying the specific roles that the instances will play."


The brokered sale interaction behavior involves three actors playing the three roles in the collaboration structure.

The brokered sale collaboration structure is embodied in the three roles as defined by their interfaces.

Or rather, in the *parts* of those role/interface definitions that are required for the brokered sale interaction behavior.

So, the brokered sale collaboration structure aggregates only the tasks involved in the brokered sale interaction behavior (it includes no irrelevant detail).

And the brokered sale interaction behaviour aggregates the same tasks.


As I read UML the brokered sale collaboration structure is unique to the brokered sale interaction behaviour.

A different interaction behavior, involving the same three same roles, would correspond to different collaboration/structure.

I could be wrong – but have yet to be given a reason to think so.

ArchiMate collaboration – as I read it

It seems to me the ArchiMate collaboration is significantly different from UML collaboration.

An application collaboration typically models a logical or temporary collaboration of application components, and does not exist as a separate entity in the enterprise.”


Green OR yellow makes sense; chalk OR cheese makes sense; the meaning of green OR chalk is obscure, since there are 4 options rather than 2.

But the reader might well presume the two options cannot be both green and chalk, meaning the options are:











The meaning of logical OR temporary is more obscure, because both words beg further definition.

The reader might well presume the two kinds of Collaboration cannot be both logical and temporary, meaning the options are:






Collaboration instance?


Collaboration type?



Collaboration as logical and persistent type

A collaboration might exist in the form of a logical and persistent contract.

The collaboration contract defines roles (or rather role responsibilities) relevant to interactions between the collaborating roles,

Role or interface definitions specify what actors can ask each other to do in one or more interactions.

In a diagram, one can draw boxes for those roles/interfaces.


Here, the collaboration doesn’t exist as an active object, distinct from the collaborating objects.

The logical types only specify behaviors, do not perform them.

However, an ArchiMate collaboration is supposed to be a component that performs behaviors.


Collaboration as physical and temporary instance

This sounds like an instantiated object, which exists in addition to the collaborating objects

To make sense of it, we have to know its creation and destruction events.

If those events are the start and end of an interaction, then there is no collaboration between interactions.

So it seems collaboration and interaction are merely two views of the same behavior.


Further analysis of “logical or temporary”

But both terms are open to various interpretations.

I think the reader is bound to suppose logical means descriptive type and physical means concrete instance.

And I guess that temporary means lives only as long as an interaction, whereas persistent means exists before and after an interaction.

Then, interaction and collaboration might be placed in the grid thus.






Collaboration instance


Collaboration type

2 or more Roles


2 or more Actors


For example:





Book Travel Interaction

Travel Booking Collaboration instance


Travel Booking Collaboration type

Internal Agent Role

External Agent Role


Internal Agent Actor

External Agent Actor


However, the Travel Booking Collaboration doesn’t, or doesn’t need to exist as a type.

The specification of an interaction makes clear what happens when actors or components collaborate.

The relevant role definitions specify all relevant responsibilities/behaviors.

And the collaboration instance (a temporary aggregation of actors) is an equally abstract concept.


BTW: There is another way to make sense of a collaboration instance.

That is, to imagine the temporary instantiation of distinct controller for an interaction.

E.g. in OO programming terms.





Transaction process

Session object


Entity class 1

Entity class 1

Entity object 1

Entity object 2

Collaboration as “passive interface” rather than “active structure”

I read UML as saying a collaboration is like a persistent contract (think of a marriage contract).

It is logical and persistent; it is embodied in the form of role or interface definition(s) that define services partners offer to each other. 

It is not embodied in an active structure element of the kind ArchiMate’s collaboration component appears to be.


UML "Behaviors may also be associated with interfaces or connectors to define the ‘contract’ between participants in a collaboration."

In other words, the collaboration/contract must exist before instances of the roles involved can interact in a behaviour specified in that contract.

This is my understanding of a collaboration, but one ArchiMate authors either seem not to share, or don’t want to make clear.


An ArchiMate interface is part of one and only component, it is component-bound. 

Such an interface doesn’t perform behaviors; it only collects requestable behavior types for the benefit of clients.

In my view, an interface is not an active structural element; it is a passive structure that clients can access.


Think of collaborations how UML defines them.

A collaboration be seen as a passive interface between roles rather than an active aggregate of roles.

E.g. a travel booking agreement defines services in the interface of an external agent.

E.g. a marriage defines services (e.g. love, honor and obey) in the interface between two married actors. 


The travel booking agreement or marriage contract is an interface definition that must exist before actors can each other interact or collaborate as defined in that interface.

But the interface is not itself active, it only defines activities that provider and consumer actors cooperate in.


In other words, one might interpret the collaboration box as a kind of interface or data entity - a precondition for interactions.

Think of it as a relatively persistent inter-actor contract (like travel booking agreement or a marriage contract) that defines the interface actors use to interact in subsequent services and processes (like love, honor and obey).

A few more questions 


Does a collaboration perform behaviour?

At some points, ArchiMate seems to align collaboration with interaction.


"An application collaboration typically models a logical or temporary collaboration of application components”

You cannot define words by reshuffling the same words! The definitive phrase is “a logical or temporary collaboration”.

“[It] does not exist as a separate entity in the enterprise.“

Meaning it is logical rather than concrete? Or concrete but transient, does not exist between interactions?


But the standard goes on to align a collaboration with a physical component that performs behaviour.


“[It] is a specialization of a component.”

So, by inheriting the properties of component, it does exist as a separate entity – but not at a different time from an interaction?

“[It] aggregates (co-operating) application components.”

So, it is a coarser-grained component?

“[It] is an active structure element “ 

So, it performs activities, like a component?

“An application interface may be used by an application collaboration” 

So, it invokes services, like a component?

and [it] may be composed of application interfaces.” 

So, it is exactly like an ArchiMate component!


The idea that a collaboration is a component is questionable. Can it be asked to perform a behavior?


Suppose "travel booker" is the collaboration involving internal and external agents.

The active structural elements are the actors who play the internal and external agent roles.

The travel booker collaboration itself doesn't perform any behaviors.

You cannot address it or ask it to do anything, you can only locate the internal agent and ask that actor to book some travel.


Suppose “marriage” is the collaboration between husband and wife.

A marriage has its own attributes (number, wedding date, husband name, wife name etc.).

But the active structural elements are the actors who play husband and wife roles.

The marriage itself doesn't perform any behaviors.

You cannot address it and ask it to do anything; you can only address the husband or the wife and ask them to do something.

And they can only address each other.


Could it be drawn as an aggregate role/actor/component?

“An aggregate of two or more active structure elements”

If a collaboration is an aggregate, do we need to draw collaboration box?

Can we instead show the aggregate by nesting element boxes inside an aggregate box? 

Even if we can, the concern here isn’t about drawing diagrams; it is about what the collaboration concept means.


Is it an aggregate of element types or instances?

“An aggregate of two or more active structure elements

ArchiMate's term "active structure element" is ambiguous; it embraces both roles and actors.

·         If the elements are roles (types), then our book travel example is an interaction, because the process type must involve two roles.

·         If the elements are actors (instances), then our book travel example may not be an interaction, because a process instance does not have to involve two actors.


Not distinguishing types and instances can make definitions ambiguous.

In this case, the two interpretations of the ArchiMate definition result in different models in our Book Travel scenarios.


Suppose your Book Travel process flow chart shows actors in both agent roles must be involved, so every process performance is an interaction.

You can draw a diagram with a "Travel Booker" collaboration box that connects internal and external agent role boxes.

And then connect a “Book Travel” interaction box to that collaboration box.


Suppose you modify the Book Travel process flow chart so that only some process performances involve an external agent/actor.

Should you retain the collaboration box in the diagram, but change the interaction box to a process box?


Suppose our internal agents choose to stop using external agents, though they are still allowed do so. 

There is still a collaboration box in the diagram (between roles), but no collaboration in reality (between actors).


Are elements “working together” when not active?

“An aggregate of … elements, working together to perform a behavior".

As I understand it, an actor/component instance must exist in reality before it is asked to work – to perform a behavior.

It must be addressable, so clients can find it and ask it to perform a behavior. And it may persist after completing a behavior.


Does it make sense to say active structure element types (such as roles) do work?

Surely they only define work to be done by actors or components that instantiate the types? 

Clients can’t ask a type (such as a role) to perform a behavior.


Does it make sense to say active structure element instances (actors and components) are working together when they may spend most of their time resting between behaviors?


Is “working together” a behavior rather than structure?

“An aggregate of … elements, working together to perform a behavior".

Does it makes sense to imply clients ask a collaboration instance (an aggregate of actors) to perform a behavior?

In reality, clients must ask one of the actors inside the collaboration, who may in turn decides whether to engage a second actor.


Suppose internal agents engage external agents on an ad hoc basis.

It seems the aggregate collaboration is only instantiated at the point in the process when the internal agent asks an external agent to help.

And if the aggregate is only a transient association between actors in a process – surely that is a behavior rather a structure?

Footnote: on people, actors and roles

In system description, a human actor is a person playing a role in the system, not the person per se.

We never model people; we model only the roles they play in operational systems we want to describe.

A human actor in a model is the name of the individual that plays a role in the operational system described, not that human as biological entity.

A human can be an actor many times over, and unrecognizable as the same human when acting in different systems and roles.

You may think of actor as the many-to-many link entity between human and role.

From the role end, an actor looks like a human; from the human end, an actor looks like a role.



Copyright Avancier Ltd 2106