Sparx Systems Forum
Enterprise Architect => Bugs and Issues => Topic started by: qwerty on November 02, 2015, 10:01:24 pm
-
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".
-
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
-
I think - to a certain extent - you're confusing syntax for semantics.
-
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
-
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.
-
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.
-
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
-
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.
-
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.
:D
-
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?)
-
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.
-
[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
-
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/
-
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! TMUffe - after Paolo
Paolo
-
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 (http://www.sparxsystems.com/cgi-bin/yabb/YaBB.cgi?num=1446016975/6#6). 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.
-
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.
I don't understand your use of vertex in this context.
-
This is a very interesting discussion, with Paolo on the side of nominative determinism and the importance of giving something the exact, correct name, and Glassboy on the side of Shakespeare: "A rose by any name..." I suspect the answer is somewhere in between. Sure, the authors of UML could have chosen any name for their stick figure, but the fact that they chose an existing English language word with specific meaning suggests that they wanted the metaphorical baggage that comes with that word. However, I don't think you should try to understand a UML model by saying "in English, actor means <X> so that's how we should interpret it in UML"; you have to be aware of the metaphor in the name without staring directly at it.
-
Are you suggesting that a Login is an extension of Register?
Not suggesting, but what I see often is that Login augments other UCs to say "you might need to do Login in order to perform the UC" (which is wrong either since it's functional decomposition). But since Login is not a UC there is no point in either extending it or being extended by some other UC. I know that a good example is hard to find. So either name it completely abstract or find a good example and do not use a wrong example since that simply leads to confusion.
q.
-
This is a very interesting discussion, with Paolo on the side of nominative determinism and the importance of giving something the exact, correct name, and Glassboy on the side of Shakespeare: "A rose by any name..." I suspect the answer is somewhere in between. Sure, the authors of UML could have chosen any name for their stick figure, but the fact that they chose an existing English language word with specific meaning suggests that they wanted the metaphorical baggage that comes with that word. However, I don't think you should try to understand a UML model by saying "in English, actor means <X> so that's how we should interpret it in UML"; you have to be aware of the metaphor in the name without staring directly at it.
I'm flattered by the comparison to Shakespeare, but my actual point is the meaning of words changes over time so syntactic and semantic convergence is only temporary, and to try and force them to always converge would be to under take the trials of Sisyphus.
-
This is a very interesting discussion, with Paolo on the side of nominative determinism and the importance of giving something the exact, correct name, and Glassboy on the side of Shakespeare: "A rose by any name..." I suspect the answer is somewhere in between. Sure, the authors of UML could have chosen any name for their stick figure, but the fact that they chose an existing English language word with specific meaning suggests that they wanted the metaphorical baggage that comes with that word. However, I don't think you should try to understand a UML model by saying "in English, actor means <X> so that's how we should interpret it in UML"; you have to be aware of the metaphor in the name without staring directly at it.
(Neil) KP knows me too well! He HAS been interacting with me for over a decade! Yes I am on the side of normative determinism, for a number of reasons:
I got started on the modelling lark after reading Jean Raymond Abrial's 1970's paper Data Semantics where he says (paraphrased): "The reason we can't build systems that work is that we can't unambiguously tell each other what we want." More than 40 years later, my experience has been that ""The reason we can't build systems that work is that we can't unambiguously tell each other what we want." :'(
In general discussion, we can be a bit free and easy with language, however, when we need to be precise, we need to be precise. The Helsinki principle should therefore apply.
Not withstanding the metaphorical baggage coming along with choosing a specific term for a concept, one of the requirements of the semantics of a language is that that concept has a particular naming form and the two need to agree in order for the language to work. How many of you have experienced being asked to do something in "words of command"?
The meaning of words does change, but I have argued for many decades, that the current trend is to devolution, not evolution! The meaning of some words is now impossible to determine. We are NOT corrected when we use a word incorrectly. On live radio, I once accused the editor of the Australian Macquarie Dictionary of "adding to the entropy of the language".
A rose may smell as sweet whatever it's name, but if I tell you something is a rose and I actually hand you a stinging nettle, you'll appreciate the importance of normative determinism... ;)
And for what it's worth, "going back to the source" and thinking about the "metaphorical baggage" that KP mentioned, I believe, has allowed me to better understand how to produce useful, normative, models of reality - the proof will be in the pudding which we're currently baking.
"Rigour is your friend!"
Paolo
-
I got started on the modelling lark after reading Jean Raymond Abrial's 1970's paper Data Semantics where he says (paraphrased): "The reason we can't build systems that work is that we can't unambiguously tell each other what we want." More than 40 years later, my experience has been that ""The reason we can't build systems that work is that we can't unambiguously tell each other what we want."
I blame requirements gathering. If we see someone struggling to put a shoe on we give them a shoe horn. But if they tell us they struggle to put there shoes on we come up with solutions ranging from longer laces to strengthening their arms.
The reason that consumer software (cloud and mobile app) is far out performing enterprise software is that one is an exercise where a team or individual builds a great shoe horn and the other there maybe a lace lengthener which you can sort of use as a lever.
-
But if they tell us they struggle to put there shoes on we come up with solutions ranging from longer laces to strengthening their arms.
Very often the problem starts even before that because they DON'T tell us they struggle to put their shoes on. They just tell us they need longer laces, or stronger arms, or smaller feet, or bigger shoes, or all of the before.
Often requirements are given in the form of solution, without stating the problem they are supposed to solve.
The challenge for a good analyst is to try and find the real requirement and then come up with possible solutions for it.
Geert
-
But if they tell us they struggle to put there shoes on we come up with solutions ranging from longer laces to strengthening their arms.
Very often the problem starts even before that because they DON'T tell us they struggle to put their shoes on. They just tell us they need longer laces, or stronger arms, or smaller feet, or bigger shoes, or all of the before.
Often requirements are given in the form of solution, without stating the problem they are supposed to solve.
The challenge for a good analyst is to try and find the real requirement and then come up with possible solutions for it.
Geert
Go for it Geert!
As Henry Ford said: "If I'd asked my customers, they would have asked for faster horses!".
Paolo
-
[size=14][SNIP][/size]
I blame requirements gathering. If we see someone struggling to put a shoe on we give them a shoe horn. But if they tell us they struggle to put there shoes on we come up with solutions ranging from longer laces to strengthening their arms.
The reason that consumer software (cloud and mobile app) is far out performing enterprise software is that one is an exercise where a team or individual builds a great shoe horn and the other there maybe a lace lengthener which you can sort of use as a lever.
Consumer software is (relatively) trivial compared to enterprise line of business systems.
Single Line of Business applications are, in turn, simpler than trying to achieve enterprise wide integration.
Paolo
-
Ah, the dining philosophers have come together. Perfectly thinking about the use of fork and spoon. But forgetting life. So what about the original issue? I can't look into the editor's mind. But obviously (thanks Paolo) he was not able to create an analogy of his ideas in my mind. Fail.
q.
-
]Consumer software is (relatively) trivial compared to enterprise line of business systems.
Single Line of Business applications are, in turn, simpler than trying to achieve enterprise wide integration.
Paolo
Exactly the point. Imagine if enterprise software became a collection of simple things that worked well. <insert your favorite Douglas Adams technology quote here>
-
]Consumer software is (relatively) trivial compared to enterprise line of business systems.
Single Line of Business applications are, in turn, simpler than trying to achieve enterprise wide integration.
Paolo
Exactly the point. Imagine if enterprise software became a collection of simple things that worked well. <insert your favorite Douglas Adams technology quote here>
Unfortunately, that DOESN'T solve the fact integration problem. If anything, it - potentially - exacerbates it.
It turns out, that the reason you can be nimble with consumer applications is that you can effectively ignore any integration with any other processes going on contemporaneously or sequentially.
In another post, you mention that you hold sessions with business users shown only the "moving parts" they interact with. This is fine for expository sessions where you show how a given user set interacts with the evolved processes.
Trying to get business people actually any group of people) to look out the same window and see the same scene is, often, like "herding cats". But until you get them to see the same reality (see Q, I DO think about life - but also about which forks and spoons I need to sup with ;)) you can't provide a viable solution.
Paolo
-
I'm always interested in piping in whenever someone claims that "Log in" is not a Use Case.
In circumstances where different functionality is presented to the Actor, depending on the Actor's state [Logged in|Not Logged in], I'm more than happy to see Actor Logs In to System as a Use Case.
;D
-
You said it: it's not a use case, it's a state (or constraint). Full stop.
q.
-
As Henry Ford said: "If I'd asked my customers, they would have asked for faster horses!".
Paolo
Nice one! Need to remember that one for when I'm teaching requirement analysis :)
Geert
-
You said it: it's not a use case, it's a state (or constraint). Full stop.
q.
Not so fast Batman!
A UseCase is: "a specification of behaviour" Each UseCase’s subject represents a system under consideration to which the UseCase applies. [UML Superstructure v2.5 - paraphrased]
So, if I'm a User and my state is [Not Logged In]; I, generally, can't do very much that is substantive. I need to trigger the system to change my state from [Not Logged In] to [Logged In] so that I can do substantive things with the system. I want to specify the behaviour that the system and users need to exhibit during that transition process. Is THAT not a UseCase under the specification above?
If not, why not?
If it is, what is the form of naming the UseCase so it is clear that it is a "specification of behaviour"?
Perhaps: "Login User"?
"Log In" is not a state, "(Not) Logged In" are. As always, it's ALL in the words.
Thoughts?
Paolo
-
How about going down a few sentences:
A UseCase may apply to any number of subjects. When a UseCase applies to a subject, it specifies a set of behaviors performed by that subject, which yields an observable result that is of value for Actors or other stakeholders of the subject.
So you are getting value from logging in, I guess. Where can I apply for your job?
q.
-
Surely authorized and\or authenticated are the relevant states :)
-
LOL.
Half right.
It's a pre-condition on all the Use Cases that only exist for a logged in Actor.
Where do you describe all of the user interactions that are required to successfully achieve a log in.
Allow for in and out of radio range (a third party network), on and off a local network, the different authentication methods supported (biometric, physical tokens, etc.).
Are you going to put that into every Use Case? Of course not, those things have to have taken place before that use case starts.
Where then? The supplementary spec?
You're jumping through a lot of hoops to avoid the obvious.
Even if you're talking about a simple system that lets strangers log in online, where are you recording the different user experiences according to the login method. (Create an account, Face-book login, Google login, Paypal login etc.)
Are these user interactions a secret or something?
:D
-
PPS.
The system that I'm using as my reference model for this discussion, allows roughly one-third of the functionality to a user that is not logged in. (Mapping/Vehicle location functionality).
Being logged in allows the actor to communicate with back-at-base systems via the application (send and receive tasks, messages, and enquiries on back-end systems).
-
PPS.
The system that I'm using as my reference model for this discussion, allows roughly one-third of the functionality to a user that is not logged in. (Mapping/Vehicle location functionality).
Being logged in allows the actor to communicate with back-at-base systems via the application (send and receive tasks, messages, and enquiries on back-end systems).
Yeah not liking your answer. Just because your users haven't interacted with a dialog box of some sort doesn't mean that there isn't already an identity factor at play. A system may know who a user is without a user doing anything. Generally authenticating allows a user to access non-public (classified something) information and to write.
What you're calling "logging in" is just a user supplying 1..2 identity factors in person.
-
So where do you write-up all the user interactions then?
If not in a Use Case?
-
So you are getting value from logging in, I guess. Where can I apply for your job?
As I said, it's not just the actor that needs to get value from a use case. It's any stakeholder.
-
@Andy: none of the stakeholder will care how the authentication is performed. The best you can get: it must be secure. Or at the outer range: it must be 2 way authentication. It's never "you must enter user/password" or the like. So those steps will become simple implementation details. You can deduct them from requirements. And you will never ever tell those constraints become something that delivers added value.
I can't recall who and in which thread said: you don't need an activity diagram for trivial things. This is more than trivial. And. It. Is. Not. Any. Use. Case.
@Simon: the stakeholder just wants to see his requirements to be fulfilled. See above...
q.
-
--Snip--
The System Presents the Actor with a range of authentication methods.
The Actor chooses a method.
--Snip--
Alt Flow: Fingerprint scanning
Alt Flow: SecureID token
Alt Flow: Outside of radio communications range
Alt Flow: Multiple persons in the patrol
Exception Flow: Authorisation fails
Once again,
Where do you define all the Actor/System interactions if not in a Use Case? Hmm???
-
@Simon: the stakeholder just wants to see his requirements to be fulfilled. See above...
UML 2.5 SpecificationA 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.
(Emphasis mine)
The result is observable. The value requirement for it being a valid use case is literally met automatically if the customer is asking for it as a use case. I can't see how your position is remotely defensible without ignoring the UML specification.
-
Wow, you have been busy while I've been asleep! ;D
I think the issue comes down to one of perspective. For some scenarios, acquiring or demonstrating authentication is the UseCase. For other scenarios it is a constraint - the user must be authenticated.
If the system (proxy for a stakeholder) requires the user to be authenticated to instantiate certain behaviours and the user can be in an unauthenticated state then there has to be some observable behaviour to authenticate the user. That behaviour specification surely is a UseCase.
Paolo
-
This could turn into this forum's version of The Infinity Monkey Cage's when is a strawberry dead saga.
-
@AndiJ: You do not need to write any use case for authentication. It's as simple as connecting a requirement. What steps would one need for an authentication?
- Click the user name field
- type user name
- click the password field
- type the password
- click ok
Is it that what you expect to come with a "use case" so one can implement the system?
What you CAN do is to define an authentication subsystem (if that is needed). Inside that you may well define use cases. Since the added value here is to get authentication (and nothing else) I have no issue with using a use case. But on a business perspective: Login is not a use case.
Placing a Login on the level of business use cases is im my opinion the same as putting nutrition (only a healthy worker is a good worker) or lacing shoes (prevent accidents) on the business level.
q.
-
This could turn into this forum's version of The Infinity Monkey Cage's when is a strawberry dead saga.
I guess you mean this: http://www.bbc.co.uk/programmes/b02ykcwhwhich is Flash (so I can't watch). Any non-Flash so non-UKer know what you're talking about?
q.
P.S. Oh there's a download MP3 below :-) Sounds like Doug Adams is back.
-
This could turn into this forum's version of The Infinity Monkey Cage's when is a strawberry dead saga.
I guess you mean this: http://www.bbc.co.uk/programmes/b02ykcwhwhich is Flash (so I can't watch). Any non-Flash so non-UKer know what you're talking about?
q.
P.S. Oh there's a download MP3 below :-) Sounds like Doug Adams is back.
There's a podcast available. It's worth going back to the beginning and listening to them all.
-
You got me ;D This is not only funny but also - hmmm - paraphysical/philosophical. I'll get that podcast in any case!
q.
-
@AndiJ: You do not need to write any use case for authentication. It's as simple as connecting a requirement. What steps would one need for an authentication?
- Click the user name field
- type user name
- click the password field
- type the password
- click ok
Is it that what you expect to come with a "use case" so one can implement the system?
What you CAN do is to define an authentication subsystem (if that is needed). Inside that you may well define use cases. Since the added value here is to get authentication (and nothing else) I have no issue with using a use case. But on a business perspective: Login is not a use case.
Placing a Login on the level of business use cases is im my opinion the same as putting nutrition (only a healthy worker is a good worker) or lacing shoes (prevent accidents) on the business level.
q.
Oh... My bad... I was talking about System UseCases all through my stuff (but didn't make that clear) :-[...
I totally agree that authentication at the Business UseCase level is a requirement and NOT a Business UseCase.
So, q, we're in agreement again (I hope)... (Since we usually are, I was wondering why we weren't in this case).
Paolo
-
I often had this problem when talking about use cases. I don't like Superstructures in that respect since it neglects this important aspect. There should be Business Use Case and Use Case. As a work around we used stereotypes <<business>>/<<tech>> to get around this.
q.
-
I often had this problem when talking about use cases. I don't like Superstructures in that respect since it neglects this important aspect. There should be Business Use Case and Use Case. As a work around we used stereotypes <<business>>/<<tech>> to get around this.
q.
Yes, many "Standards" suffer from a degree of "sloppiness". I allow as you can get "snow-blinded" by looking at the same text, over and over again, so I'm a bit charitable there.
Paolo