Wrong use of extends

[Glassboy]

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.

[qwerty]

You got me This is not only funny but also - hmmm - paraphysical/philosophical. I'll get that podcast in any case!

q.

[Paolo F Cantoni]

@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

[qwerty]

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.

[Paolo F Cantoni]

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