Re: DCI Glossary suggestion

[Trygve Reenskaug]

DCI is a programming paradigm. Its concern is what happens in the computer at run time. Its concern is not the modeling of end user organization or work processes.

"In software and systems engineering, a use case is a list of steps, typically defining interactions between a role (known in UML as an "actor") and a system, to achieve a goal. The actor can be a human or an external system.

In systems engineering, use cases are used at a higher level than within software engineering, often representing missions or stakeholder goals. The detailed requirements may then be captured in SysML or as contractual statements." (Wikipedia)

Note that the Actors are marked as outside the system in the Wiki figure (http://en.wikipedia.org/wiki/Use_case)

"Use cases are a means for specifying required usages of a system. Typically, they are used to capture the requirements of
a system, that is, what a system is supposed to do. The key concepts associated with use cases are actors, use cases, and the subject.
A Use case can explain how and why a user wants to trigger a system operation. There can also be other sources of such triggers.  In all cases, the source of the trigger is outside the DCI metamodel."(UML 1.4.2)

Use cases are parts of specifications and are outside the DCI system boundary; specifications are only reified in DCI as Context provided operations. Use cases with their actors are specifications; DCI Contexts with their roles are implementations (code). That's why I can't see why the term 'Actor' should be included in the DCI glossary. We have included 'Use case' as an imprecise representation of user requirements. 'Actor' is a use case detail used by some, but it is too specific to replace 'use case' for the needs of DCI, IMO. May be we rather than add 'Actor' should simplify the glossary definition of 'use case' to emphasize that it belongs in the DCI environment

I see that higher level tools could embrace both specification and implementation, but most developers would probably be better served with independent  choices of tools for each of them. Example: a word processor for specification, BabyIDE or Marvin for implementation.

You also suggest that the term 'Actor' could replace 'Role' throughout. I think this is a very bad idea because it would confuse specification with implementation.

You may not find this satisfactory. In that case, I suggest that you propose the exact wording of a new entry for 'Actor' and argue why it needs to be included in the DCI glossary..

--Trygve

On 2013.05.12 00:30, Matthew Browne wrote:

Dear Trygve,
I am a member of the object-composition group and I have a great appreciation for DCI. Ordinarily I wouldn't contact you directly but I'm under the impression that you're the one who maintains the DCI glossary and I have a suggestion that hasn't garnered much response, but no one has offered any real arguments against it either.

My suggestion is to add the term "actor" to the DCI glossary. If you could comment on my post here, even if it's just to say you don't think this is necessary, I would appreciate it:

https://groups.google.com/d/msg/object-composition/dLJXMiG7Vuk/oL1C6b4hSrAJ

Given that "use case" is defined in the glossary I don't see why "actor" shouldn't be, and I'm no clearer on this after Jim's response.

Thanks,
Matt

On 2013.04.28 01:11, Matthew Browne wrote:

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."

~~~

[rune funch]

When we introduced RolePlayer in the glossary we had several candidates one of them being Actor. RolePlayer was as I recall it favored for not confusing an UML actor and a DCI RolePlayer. (I personally acttually favored Actor at that point). So you could say that we consciously decided to keep actor out of the glossary to not confuse it with use of the same word outside the DCI context.

2013/5/12 Trygve Reenskaug <try...@ifi.uio.no>

--
You received this message because you are subscribed to the Google Groups "object-composition" group.
To unsubscribe from this group and stop receiving emails from it, 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.
 
 

[Matthew Browne]

Thank you both for the responses...this is beginning to make more sense to me now.

DCI is a programming paradigm. Its concern is what happens in the computer at run time. Its concern is not the modeling of end user organization or work processes.

Thank you for the clarification, Trygve. Before your reply I was mistaken as to where DCI as a thought paradigm begins and ends. Obviously code is an important part of DCI, but I still think I'm correct in saying DCI is about more than just code. (As others on this forum have noted, DCI is a paradigm; probably the best example of this is that a DCI implementation of a use case without consideration of the end user's mental model wouldn't be DCI at all, just as programming in an object-oriented [or class-oriented] language doesn't automatically make one an object-oriented programmer).

But what you seem to be saying is that DCI (and DCI vocabulary) only enters the picture when we begin thinking about how we are going to write the code for a system or feature that has been specified (using UML or any other specification approach).

Given that, I can now understand why you don't feel "actor" belongs in the glossary.

You also suggest that the term 'Actor' could replace 'Role' throughout.

I never suggested that and I agree it would be a very bad idea. To clarify: I suggested that if the term "actor" is to have a part in discussions of DCI implementation, it should preferably have a single, unambiguous meaning. I was originally advocating that it should have the same meaning as it does in UML to avoid confusion, but I now see that that suggestion is irrelevant because UML actors are outside the scope of DCI.

May be we rather than add 'Actor' should simplify the glossary definition of 'use case' to emphasize that it belongs in the DCI environment

I think that could be a useful improvement to the glossary, since those with a UML background may make the same incorrect inference about the scope/boundaries of DCI as I did.

Thanks again,
Matt

[Matthew Browne]

On Sunday, May 12, 2013 5:53:06 AM UTC-4, Rune wrote:

When we introduced RolePlayer in the glossary we had several candidates one of them being Actor. RolePlayer was as I recall it favored for not confusing an UML actor and a DCI RolePlayer. (I personally acttually favored Actor at that point). So you could say that we consciously decided to keep actor out of the glossary to not confuse it with use of the same word outside the DCI context.

I'm glad that the decision was for the term "role player." Even after Trygve's post explaining the boundaries of DCI, I still think that re-defining terms that come up a lot in DCI-related design discussions to mean something different in DCI than they do outside of it should be avoided whenever possible.

I would now suggest that we (or anyone writing about DCI) avoid using the term "actor" at all unless they mean a UML actor -- in other words, when talking specifically about the code, never.

The only exception I can think of where the term "actor" is actually useful with regard to explaining DCI implementation concepts is when explaining the history of DCI's concept of roles (i.e. the analogy of actors on a stage playing roles).

Otherwise, "role player" or just "object" (as Jim suggested) are sufficient, and much less prone to confusion than "actor".

[rune funch]

2013/5/12 Matthew Browne <mbro...@gmail.com>

I still think that re-defining terms that come up a lot in DCI-related design discussions to mean something different in DCI than they do outside of it should be avoided whenever possible.

Actors (real person at theaters)  play roles so they are role players. it's wasn't a matter of redefining the word actor to mean something new but even when using a term that has several meanings even if you are using the term for it's original meaning can be misunderstood

[Matthew Browne]

> Actors (real person at theaters) play roles so they are role players.
> it's wasn't a matter of redefining the word actor to mean something
> new but even when using a term that has several meanings even if you
> are using the term for it's original meaning can be misunderstood

Very good point, but I think avoiding the term "actor" (unless you're
talking about UML actors) is very easy to do and has a good chance of
preventing unnecessary confusion.

I think I've said more than enough about this already so I won't make
any further efforts to convince anyone about it, but this is my strong
opinion.