My Struggles with Interactions
and Collaborations
Copyright Avancier Ltd 2106
http://avancier.website
Abstract
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).
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.
Types |
Instances |
Role |
Actor |
Event |
Occurrence |
Process |
Performance |
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?
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?
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?
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?
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.)
“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.
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:
|
Green |
Yellow |
Chalk |
|
OK |
Cheese |
OK |
|
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:
|
Logical |
Physical |
Temporary |
|
Collaboration
instance? |
Persistent |
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.
|
Logical |
Physical |
Temporary |
Interaction |
Collaboration
instance |
Persistent |
Collaboration type 2
or more Roles |
2
or more Actors |
For example:
|
Logical |
Physical |
Temporary |
Book
Travel Interaction |
Travel
Booking Collaboration instance |
Persistent |
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.
|
Logical |
Physical |
Temporary |
Transaction
process |
Session
object |
Persistent |
Entity
class 1 Entity
class 1 |
Entity
object 1 Entity
object 2 |
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).
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.
“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.
“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).
“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?
“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?
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
http://avancier.website