Wrong use of extends

[Glassboy]

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.

[KP]

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.

[qwerty]

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.

[Glassboy]

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.

[Paolo F Cantoni]

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

[Glassboy]

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.
 

[Geert Bellekens]

 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

[Paolo F Cantoni]

 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

[Paolo F Cantoni]

[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

[qwerty]

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.

[Glassboy]

]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>

[Paolo F Cantoni]

]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

[AndyJ]

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.

 

[qwerty]

You said it: it's not a use case, it's a state (or constraint). Full stop.

q.

[Geert Bellekens]

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