Wrong use of extends

[qwerty]

Someone really tried to learn something from http://www.sparxsystems.com.au/resources/tutorial/use_case_model.html. Dear Roy: would you care to at least draw the extends into the right direction. And - if possible in any way - do not use Login as use case. It is none.

q.

P.S. Thinking about "the wrong way" I come to the conclusion that the direction can't be told. Simply because Login is no use case it can not be extended. I first thought of "you need to optionally log in to Register".

[Paolo F Cantoni]

While we're at it, a "customer" is a Role, not an Actor.  It is an a role being played by an actor, but "in those days" roles didn't exist.  But Roles can't do anything -they have no agency.  So what we really have is a an actor in a role - traditionally (i.e. in the middle ages) called a player.  Players are normatively named for both actor type and the role, so here: Person As Customer.  However, colloquially, they can be named after the role  ie "Customer"  hence the confusion in the old UseCases.

So what are we to make of UseCases?  Is there a place form them in today's modelling?  How should they be updated to coexist with things like ArchiMate, BPMN etc.?

Paolo

[Glassboy]

I think - to a certain extent - you're confusing syntax for semantics.

[Paolo F Cantoni]

I think - to a certain extent - you're confusing syntax for semantics.

Can you elaborate?  I've been going around this for a while and I'm not sure I've got it straight in my mind - son any help is appreciated.

Paolo

[qwerty]

Honestly, I always saw (and still see) actors as a synonym for roles. It is the abstraction of a behavior set for a group of people having the same goals. For that reason they interact with the same use cases.

q.

P.S.: In real life an actors plays a role. Isn't that so? That would likely imply that an actor is an instance of a role. I have seen a lively discussion about that on LinkedIn where someone argued OMG should have used role rather than actor.

[Glassboy]

I think - to a certain extent - you're confusing syntax for semantics.

Can you elaborate?  I've been going around this for a while and I'm not sure I've got it straight in my mind - son any help is appreciated.

Paolo

What you're saying is semantically correct (in English and probably every other Indo-European language), but the syntax of something like a use case doesn't necessarily need to follow the semantics of English.

Syntax relates to the order of elements, whereas semantics relates to the meaning.  

You could change the label user in a usecase to role (or person in role)  but the syntax would say the same.  Which in the end is just saying that these three labels are functioning as synonyms, and over time we have become more precise in our terminology.

[Paolo F Cantoni]

What you're saying is semantically correct (in English and probably every other Indo-European language), but the syntax of something like a use case doesn't necessarily need to follow the semantics of English.

Syntax relates to the order of elements, whereas semantics relates to the meaning.  

You could change the label user in a usecase to role (or person in role)  but the syntax would say the same.  Which in the end is just saying that these three labels are functioning as synonyms, and over time we have become more precise in our terminology.

Thanks, Glassboy

I think that's what I'm agreeing with.  However, the semantics is bound in the syntax - in English there is an order of word types but that is quite flexible.  "Time flies like an arrow" being the classic example.  Depending upon which word metatype you assign o the word in the clause can have (I think up to 5-6) different meanings(allowing for the existence of Time Flies - like Fruit Flies).

My research over the last decade has convinced me that the more rigorous the relationship between the modelling syntax (especially including naming of objects according to their metatype) and the semantics, the better and more insightful the model.


Paolo

[qwerty]

My research over the last decade has convinced me that the more rigorous the relationship between the modelling syntax (especially including [highlight]naming of objects[/highlight] according to their metatype) and the semantics, the better and more insightful the model.

You should read Wittgenstein. Things are only what their name is - and vice versa.

q.

[Uffe]

My research over the last decade has convinced me that the more rigorous the relationship between the modelling syntax (especially including [highlight]naming of objects[/highlight] according to their metatype) and the semantics, the better and more insightful the model.

You should read Wittgenstein. Things are only what their name is - and vice versa.

True, but then Wittgenstein was a beery swine who was just as sloshed as Schlegel.

[qwerty]

I guess that if the truth is told by an a_s_s_h_o_l_e it's still the truth

q.

(why can't you turn of this scrappy censoring module which forces one to emphasize words you don't want to?)

[Glassboy]

My research over the last decade has convinced me that the more rigorous the relationship between the modelling syntax (especially including naming of objects according to their metatype) and the semantics, the better and more insightful the model.


Paolo

Well there are dialectal differences in English and language drift.  I don't see any value in constantly changing the label we attach to actor, we just need to understand what it is a synonym for.  

That doesn't mean that some better method shouldn't replace Use cases.

[Paolo F Cantoni]

[size=14][SNIP][/size]

Well there are dialectal differences in English and language drift.  I don't see any value in constantly changing the label we attach to actor, we just need to understand what it is a synonym for.  

That doesn't mean that some better method shouldn't replace Use cases.

Thanks for your input, I'm (and hopefully others) are finding this very interesting and useful.
"Changing the label we attach to actor" - not sure what you mean here.  

A number of methodologies and their syntaxes have the element "Actor" but they don't mean quite the same thing.  Having looked at a reasonably large number, I've come to the conclusion that an Actor  is an "Entity with agency - the ability to act."  So I don't think I'm "changing the label.  If that definition is valid, then actors are things like "Person", "Organisation", "Organisational Unit" and so on - concrete types of entities. Consequently, "Customer" is not an entity, it is a Role (a collection of behaviours groups for some purpose) being played by an Actor.  Indeed ArchiMate requires you to assign the Role to an Actor.  Similarly, the Actor just is..  It can only exhibit behaviour by playing a Role.   A Role, however,  while a collection of behaviours, has no agency - that's why it has to be "played" by an Actor to actually get anything done.  Since a Role can be played by more than one Actor and and Actor can play many roles, we need an intersector ("Player") that says: in this situation, I am this actor playing that role.

Getting back to UseCases, I think that have a lot of merit and can be used in models that include ArchiMate elements.  Elsewhere, we've recently discussed in a common repository there should be one instance of a concept.  So I think if I use Player as the "Actor" in the Use Case, I can connect a UseCase to the rest of the "universe of discourse".  If I use Player in most places where ArchiMate has either an Actor or a Role (connected to some situation/activity), then I am talking about the same concept as in the UseCase.

Paolo

[Glassboy]

You're forgetting that there are two language elements to an actor.  There is the stickman sigil and the collection of letters we choose to label it with.

If you look at the stickman and your brain accesses the "entity with agency" concept then it's largely irrelevant that the text actor is often appended, the same way its irrelevant what SCSI and TWAIN actually mean.

As for Archimate, I think that's a whole other mess, I'd refer you to http://masteringarchimate.com/2015/09/04/open-letter-to-tog-2/

[Paolo F Cantoni]

You're forgetting that there are two language elements to an actor.  There is the stickman sigil and the collection of letters we choose to label it with.

If you look at the stickman and your brain accesses the "entity with agency" concept then it's largely irrelevant that the text actor is often appended, the same way its irrelevant what SCSI and TWAIN actually mean.

As for Archimate, I think that's a whole other mess, I'd refer you to http://masteringarchimate.com/2015/09/04/open-letter-to-tog-2/

Well I'm familiar with Gerben's work and have a copy of his book and I mainly agree with most things he says.

But that's part of my point.

In my case, however, when my brain sees the "stick man", it says" this vertex represents an "Entity with Agency" and so I expect it to be named as for an Entity".  I don't expect it to be named as an Activity, for example.  I also expect that if two vertices a have the same name and metatype - they represent the same thing.

It's all about:
Concistency, konsistency, consistensy! ^TM_{Uffe - after Paolo}


Paolo

[Eve]

at least draw the extends into the right direction

Are you suggesting that a Login is an extension of Register? The extend relationship is intended to specify "how and when the behavior defined in the extending UseCase can be inserted into the behavior defined in the extended UseCase". If a registration requires a login to be performed as part of it, then that extends relationship is appropriate.

if possible in any way - do not use Login as use case. It is none.

UML describes a use case as: "A UseCase specifies a set of actions performed by its subjects, which yields an observable result that is of value for one or more Actors or other stakeholders of each subject."

Generally the argument against Login as a usecase is the point about value. It certainly meets all of the other criteria of that description. In this era of pervasive tracking a login event has definite value to stakeholders.

While we're at it, a "customer" is a Role, not an Actor.  It is an a role being played by an actor

That's exactly what UML says: "An Actor specifies a role played by a user or any other system that interacts with the subject."

So creating an actor for customer is the way the creators of UML intended it to be used.

But Roles can't do anything -they have no agency.

All that means is that the agency playing the role is outside of the scope of UML. It's the role that's the interesting thing, which is why an actor should be named according to the role being played.

It might be worth looking at the discussion on entity or role for BPMN. Unlike UML, BPMN does provide classes for both.

I have seen a lively discussion about that on LinkedIn where someone argued OMG should have used role rather than actor.

The description of an actor in UML 2.5 reflects that it's about a role being used. Role may be a better pedantic choice of terminology, but actor is a simpler concept (especially for non-technical stakeholders) and fits with the highly iconic stick figure notation.