Adding the term "actor" to the DCI glossary

[Matthew Browne]

This is related to the other thread I started, but since then I have clarified my thoughts more and I want to focus this thread specifically on my proposal to add the term "actor" to the DCI glossary.

In order to explain why I think this is important, I want to first bring up something mentioned in the Lean Architecture book: the distinction between user roles and object roles. User roles are for the most part synonymous with UML actors (except in the case of actors that aren't users, like an external system), whereas object roles refer to objects playing roles in DCI code.

In a recent post on this group, Trygve said the following about the relationship between the terms "role" and "actor":

The word "role" comes from early 17th century: from obsolete French roule "roll," referring originally to the roll of paper on which the actor's part was written (Oxford). So a role is performed by an actor (rolePlayer object, noun) who plays the role (roleMethods, verbs).

This definition of an actor as a rolePlayer is of course valid for DCI but has a different meaning than the term "actor" in UML.

Because use cases and actors (as defined in UML) are very relevant to discussions of the DCI design process, this leads to an ambiguity: in UML, "actor" refers to a user role (or "external system role" as the case may be), whereas in discussions of DCI code, "actor" is often used to mean an individual object playing a role (please correct me if I am mistaken in this).

Thus I think it's important for the term "actor" to be formally defined for DCI, especially for people coming from a UML background. These two meanings are quite different, and both come up frequently in DCI discussions (as we have seen here).

Although I'm not the best person to write a formal definition, in the interest of contributing what I can, I've drafted the following definition as a starting point...I'm sure it will need revision (it's long for one thing), but you have to start somewhere, right?

Actor

Definition 1.
The first definition concerns the perspective of the system as a whole, as well as the users who interact with it.

1. An Actor is a role that interacts with the system, usually played by a user of the system. An Actor can also be a role played by an external system.

The term "role" in the above definition refers simply to the regular English-language meaning of the word "role."

However, it is also true that actors are commonly implemented as Roles in DCI code (but only if necessary for a given context).

Definition 2.
The second definition concerns the perspective of DCI code and the objects in the computer's memory in a running system, in which these objects should parallel the end users' and/or programmers' mental models.

2. An Actor is an individual object that plays one or more Roles. Synonymous with "Role Player."

~~~

Looking at this definition I'm concerned that it might be more confusing than helpful to newcomers, so please suggest improvements.

Perhaps one of these definitions should be preferred over another in DCI, or perhaps some adjective could be used to distinguish them, but in any case I think the ambiguity should be addressed.

Personally I think it might be a good for the second definition to be discouraged, since we already have the term "Role Player", and because "Actor" is already defined in UML.

[James O Coplien]

On Apr 27, 2013, at 6:11 , Matthew Browne wrote:

object roles refer to objects playing roles in DCI code

I object (with emphasis on the appropriate syllable...).

A role is a name of an object, not an object.

The term "actor" was coined (or at least popularized) by Carl Hewett to designate an active object (i.e., one with its own program counter). I think that adds confusion to the computational model and communicates something that is potentially incompatible with DCI, which is based on sequential execution between object methods. "Object" works for me.

[Matthew Browne]

Sorry, I didn't phrase that well. Object roles are roles, not objects, obviously. I was just getting at the fact that object roles are roles in a DCI context (a code-level concept) and are not the same as user roles, which have to do with the actual users of the system.

The term "actor" was coined (or at least popularized) by Carl Hewett to designate an active object (i.e., one with its own program counter). I think that adds confusion to the computational model and communicates something that is potentially incompatible with DCI, which is based on sequential execution between object methods. "Object" works for me.

I agree with you that the term "object" works fine here; after all, it's the objects that play the roles and we can discuss them without needing the terms "actor" and "role player."

But "actor" is still a relevant term when discussing use cases, is it not? And use cases are a part of the DCI design process.

While it would be ridiculous to suggest adding every UML term to the glossary, I think the term "actor" is comes up often enough in discussions of going from analysis to DCI code to warrant its formal definition as far as DCI is concerned. Perhaps that just means borrowing the UML definition of actor if the other usage is deemed unnecessary.

Does anyone else think it would be useful for "actor" to be defined in the glossary?

--
You received this message because you are subscribed to a topic in the Google Groups "object-composition" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/object-composition/dLJXMiG7Vuk/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to object-composit...@googlegroups.com.
To post to this group, send email to object-co...@googlegroups.com.
Visit this group at http://groups.google.com/group/object-composition?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Marc Grue]

On 28/04/2013, at 02.26, Matthew Browne <mbro...@gmail.com> wrote:

> Does anyone else think it would be useful for "actor" to be defined in the glossary?

Yes. At least to minimize confusion about the term which has proven to recur.

[Trygve Reenskaug]

In OOram, we modeled system behavior as a flow of messages from one role to another. A few roles could spontaneously send a message without a visible  stimulus, and some received a message without a resulting message send. We called them environment roles.

OOram could not accept messages without a sender because the environment roles were essential to role model inheritance. (I had some pretty hard fighting for this view in the initial formulation of UML. For example, Bran Selic in his Real-Time Object-Oriented Modeling (ROOM) lets unexplained messages arrive from outside the system, there are no environment roles).  I naturally expected to find the need for environment roles in DCI and was surprised that I couldn't use them. The ultimate goal of DCI is to provide the end user with a mental model that explains what goes on the the system he is using. The model is object oriented, and there is a direct relationship between model roles and system objects. The environment is, by definition, outside the system and its objects are not visible in the model.

I'm working on an article about what I call "True Object Orientation. A Lingua Franca of Computing ". There are two main sections. The first is about a TrueOO metamodel that is shared by users and programmers alike. TrueOO is separated into two (orthogonal) parts: DynamicOO for system behavior and StaticOO for system state. The second main section is for programmers and describes the implementation of trueOO with DCI.

TrueOO is recursive; what appears as an object in one model may be represented as a system on the level below. A DCI Context fits on one level on this hierarchy. A DCI Context may call on a sub-context and so on recursively. I find it untidy to mix several level in the same model, so there is no room for environment objects in DCI. On the other hand, I see no problem with moving out from a DCI Context and model its user environment. The realization of specific system behavior will then appear as a single object, a Context. This is done in the PlayBills Context that calls BankTransfer as a sub-context.  The rolePlayers on the high level can well be human actors and can be called Actors if this simplifies end user understanding.

I liked Ivar Jacobson's introduction of Actors in his Objectory process instead of my environment roles because he removed recursion from the end user mental models. So I believe the term 'Actor' should be used on one, concrete level of the OO hierarchy.

IMO, your definition 2 could cause a lot of confusion, particularly when used recursively.

On 2013.04.28 01:11, Matthew Browne wrote:

Actor

Definition 1.
The first definition concerns the perspective of the system as a whole, as well as the users who interact with it.

1. An Actor is a role that interacts with the system, usually played by a user of the system. An Actor can also be a role played by an external system.

The term "role" in the above definition refers simply to the regular English-language meaning of the word "role."

However, it is also true that actors are commonly implemented as Roles in DCI code (but only if necessary for a given context).

Definition 2.
The second definition concerns the perspective of DCI code and the objects in the computer's memory in a running system, in which these objects should parallel the end users' and/or programmers' mental models.

2. An Actor is an individual object that plays one or more Roles. Synonymous with "Role Player."

--

Trygve Reenskaug      mailto: try...@ifi.uio.no
Morgedalsvn. 5A       http://folk.uio.no/trygver/
N-0378 Oslo             http://fullOO.info
Norway                     Tel: (+47) 22 49 57 27

[Matthew Browne]

IMO, your definition 2 could cause a lot of confusion, particularly when used recursively.

I completely agree; that's why I suggested that definition 2 be avoided in favor of the term "role player" or simply "object."

Thanks for the very interesting background...I look forward to your article.

On the other hand, I see no problem with moving out from a DCI Context and model its user environment. The realization of specific system behavior will then appear as a single object, a Context. This is done in the PayBills Context that calls BankTransfer as a sub-context.  The rolePlayers on the high level can well be human actors and can be called Actors if this simplifies end user understanding.

This is an interesting idea but what would be the practical benefit? The users only interact with the system through the user interface, so what data or behavior would need to be represented in the system with regard to user roles and/or "environment roles" as you call them other than the messages coming from the user interface (already managed by the UI layer), and use case behavior in DCI contexts?

It's intriguing but I'm not understanding the application.

[Trygve Reenskaug]

On 2013.05.15 06:43, Matthew Browne wrote:

On the other hand, I see no problem with moving out from a DCI Context and model its user environment. The realization of specific system behavior will then appear as a single object, a Context. This is done in the PayBills Context that calls BankTransfer as a sub-context.  The rolePlayers on the high level can well be human actors and can be called Actors if this simplifies end user understanding.

This is an interesting idea but what would be the practical benefit? The users only interact with the system through the user interface, so what data or behavior would need to be represented in the system with regard to user roles and/or "environment roles" as you call them other than the messages coming from the user interface (already managed by the UI layer), and use case behavior in DCI contexts?

It's intriguing but I'm not understanding the application.

One application is to use true OO for general modeling,  e.g., business process modeling. No programming so not DCI.

Another application could be a program for the integration of SOA services. This idea popped up after a talk I gave to an insurance company who were actually doing a SOA project. Objects in the program would be users of the services; Jacobson would probably call them 'Actors'.

[Matthew Browne]

Thanks Trygve, that makes more sense to me now.

I liked Ivar Jacobson's introduction of Actors in his Objectory process instead of my environment roles because he removed recursion from the end user mental models. So I believe the term 'Actor' should be used on one, concrete level of the OO hierarchy.

Yes, it makes communication easier when "actor" only has one meaning. I don't think a single definition is possible for "role" though, since the term is commonly used outside of DCI.

Another application could be a program for the integration of SOA services. This idea popped up after a talk I gave to an insurance company who were actually doing a SOA project. Objects in the program would be users of the services; Jacobson would probably call them 'Actors'. --