> ----------
> From: Jason Gorman[SMTP:[EMAIL PROTECTED]]
> Sent: 15 February 2001 16:32
> To: Angay, Huseyin (Huseyin)** CTR **
> Subject: RE: (ROSE) Test scenarios
>
> Hi
>
> Which "spirit" of use cases is this?
>
The one that says that the use cases capture interaction between actors and
the system.
> Rigour is *always* a good thing.
>
Sure. I do not criticise rigour as you may have noticed. I expect it in use
cases. But I expect use cases to be use cases, too.
Class Diagrams are rigorous. So are State Transition Diagrams. So are
program specs written for Jackson Structured Design. I use them or used
them. None are Use Cases.
By the way, you may have missed the text I interpersed with your original
message. I did explain in there what I thought was going against this
"spirit" of use cases.
> Remember, this is software *engineering*!
>
I do try to forget sometimes, especially when I get home in the evening.
Despite my best efforts however, I am one such engineer. Have been for quite
some time.
> Look at cleanroom or catalysis. If
> you want high quality software then I recommend this approach.
>
> Inputs to use cases are implicitly supplied by the actor(s), as they are
> the
> external client. You do not need another use case purely for collecting
> inputs, and the physical manner in which inputs are collected is not part
> of
> the use case (eg, by form, by fax, by carrier pigeon...)
>
The whole point about use cases is to explore the interaction between actors
and the system. In trivial examples like cash machines, with which most of
us are familiar, this may be a moot point. When your actors become other
complex systems, or people carrying out complicated tasks, the carrier
pigeon vs. fax debate becomes pretty important. The strength of the use
cases comes from their ability to explore these different interactions.
There are other methods for documenting the guts of what is happening in the
system.
> The use case is
> logically the same in all respects. If it is not then there is something
> wrong with the use case.
>
Teh secondary use case (if there is one) may be the same in all cases. The
one that deals with bumping up and down the figures for the current balance,
updating the transaction log for the account holder and so on.
The primary use cases that are triggered by the actors differ wildly
depending on whether you withdraw cash from an automated machine or do it by
writing a cheque over the counter in the bank.
> You can use storyboarding to describe UI interactions, and append this to
> the use case, but it is not the point of the use case.
>
I've obviously missed a trick or two in the last seven years. My clients
indicate that they find the use cases useful because they allow us to
capture those interactions. I am not talking about what the UI looks like or
which buttons the operator presses. I am talking about the fact that most
users find the flow of events between the users and the system quite
important. There may be a lot of difference between authenticating someone's
account before or after the request for cash is sent to the system: a second
phone call in the former case -- that's why most ATMs will let you enter
both your pin number and the requested amount, then tell you that you
entered the wrong pin number, because the number and the request go in the
same message, saving another call. Inconvenient for the odd user who enter
the wrong number, a great saving for the bank. And definitely ~not~ obvious
to everyone.
And that's a trivial example. When you start talking about actors as other
systems that use complicated protocols to talk to our system or some systems
that demand or provide real-time information, things get very complicated
and very quickly. Distinct modes of communication often have wildly
different effects on the system's behaviour, even when the subject is the
same.
> I would avoid the
> complexities of use case models (<<includes>>, <<extends>> etc etc)
> because
> the metamodel is vague and disjoint with the rest of UML. Far too much
> time
> is being spent arguing about use cases. We need a much simpler and more
> precise metamodel.
>
>
I won't argue over connections between use cases. That's a different story
altogether.
But even without those, the real strength of use cases is in the way they
explore actor-system interaction, not in a precise specification of system's
internal activities. The examples you described came under the second
category.
We do need the latter described, but this can be done in an operation
description.
Regards,
Huseyin
> Cheers
>
> Jason
>
>
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Angay, Huseyin
> (Huseyin)** CTR **
> Sent: 15 February 2001 14:42
> To: '[EMAIL PROTECTED]'
> Subject: RE: (ROSE) Test scenarios
>
>
>
> Hi, Jason.
>
> What you describe works as a rigorous program specification, but I think
> it
> is stretching the spirit of use cases quite a lot.
>
>
> > ----------
> > From: Jason Gorman[SMTP:[EMAIL PROTECTED]]
> > Reply To: Jason Gorman
> > Sent: 15 February 2001 12:29
> > To: Angay, Huseyin (Huseyin)** CTR **
> > Cc: [EMAIL PROTECTED]
> > Subject: RE: (ROSE) Test scenarios
> >
> >
> > Hi
> >
> > A use case is simply a description of some external behaviour. In that
> > sense
> > it is just some operation that queries or transforms the business
> objects
> > of
> > the system (which is why you need to model enough of the business
> objects
> > in
> > order to write an effective use case).
> >
> > Like all behaviours, a use case has pre and post-conditions that define
> > the
> > semantics (meaning) of that behaviour. For example, to withdraw cash
> from
> > an
> > ATM you might have a use case that could be summed up by:
> >
> > System::withdrawCash(accountid : String, amount : float)
> >
> Where do the account id and the amount come from?
> Does another use case collect this information, then <<include>> this one?
> Parameterised use cases are good for describing actions often used in
> different contexts, but this seems like a method to me.
>
> > pre:
> > amount > 0 and amount <= Account.allInstances->select(id =
> > accountid).availableFunds
> >
> > post:
> > Account.allInstances->select(id = accountid).getBalance =
> > Account.allInstances->select(id = accountid).getBalance@pre - amount
> >
> These confirm that the information gets collected outside the use case
> scope. In that case, what does the use case describe? I suspect nothing
> more
> than the internal processing. There is a place for this in use cases, but
> the user interaction aspect is the most important part of use cases.
> Without
> it, they become program specs. Pseudo-code would do just as well in that
> case.
>
> > You can logically derive all the secenarios from these pre and
> > post-conditions by building a response matrix (a kind of decision table)
> > which maps input scenarios to outcomes by looking at all the possible
> > combinations of input logic (and discrete object states, if there are
> more
> > than one). For example, scenario one might be:
> >
> > amount > 0 and amount <= Account.allInstances->select(id =
> > accountid).availableFunds
> >
> > Scenario two might be:
> >
> > amount > 0 and not amount <= Account.allInstances->select(id =
> > accountid).availableFunds
> >
> > Scenario three would be:
> >
> > (not amount > 0) and amount <= Account.allInstances->select(id =
> > accountid).availableFunds
> >
> > And scenario four would be:
> >
> > (not amount > 0) and (not amount <= Account.allInstances->select(id
> > =
> > accountid).availableFunds)
> >
> > When you build the software you must consider all the possible
> scenarios,
> > and not be selective ("Oh, let's just look at a couple of scenarios")
> > because if you don't then your use case specification is incomplete. The
> > worst possible crime is to say "Oh, we can do the other scenarios in the
> > next iteration"!!! If there are too many scenarios then your behaviour
> is
> > too complex and you need to simplify it. Your scenarios must match
> exactly
> > what the system testers are expecting, so you do not wait for them to do
> > the
> > analysis - do it yourself and compare it with what the system testers
> have
> > come up with. The TEST is the use case specification (and not the word
> > document...)
> >
> How do you do scenarios? Do you document them all individually?
>
> > Also, try to avoid scenarios like:
> >
> > 1. The cash is withdrawn
> > 2. Validation fails
> >
> > This is not helpful.
> >
> > Regards
> >
> > Jason Gorman
> > http://www.xml-objects.com
> >
> >
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Angay, Huseyin
> > (Huseyin)** CTR **
> > Sent: 15 February 2001 12:05
> > To: '[EMAIL PROTECTED]'
> > Subject: RE: (ROSE) Test scenarios
> >
> >
> >
> > You'd rarely ever write the scenarios themselves. (The only time I find
> > these useful is when going through complicated scenarios with users.
> Even
> > then, the scenarios are thrown away once the use case is written.) The
> use
> > case text should be able to cover all the scenarios in a general form.
> The
> > analyst job is to simplify and generalise scenarios to the point that
> you
> > can work out the different scenarios from as little text as possible.
> >
> > Testers should be given enough training to be able to read the use case
> > text
> > and write or generate the code for test scenarios from those.
> >
> >
> > Regards,
> > Huseyin Angay
> > Karabash Ltd.
> > www.karabash.co.uk
> >
> > > ----------
> > > From: Antonio Jean Claude[SMTP:[EMAIL PROTECTED]]
> > > Reply To: Antonio Jean Claude
> > > Sent: 15 February 2001 9:25
> > > To: 'Kopetzky, Volker'; [EMAIL PROTECTED]
> > > Subject: RE: (ROSE) Test scenarios
> > >
> > >
> > > Thanks for your answer,
> > >
> > > This was very helpful.
> > > Tell me if I am wrong: a UC scenario is a instance of a UC. UC
> scenarios
> > > should cover all main and alternative flows and their variations.
> These
> > > artifacts are created by the analysts.
> > >
> > > How detailed should these UC scenarios be?
> > > Should they be as detailed as :
> > > SCENARIO 1:
> > > Message 1
> > > Attrubute 1 = A1
> > > Attrubute 2 = A2
> > > Expected results:
> > > Object1 created with AttributeA = A1
> > > Object2 created with AttributeB = A2
> > > Link created between Object1 and Object2
> > > Message 2
> > > ....
> > >
> > > plus a written description of the UC scenarios.
> > >
> > > In which case, for one use case the analysts can end up with an
> > incredible
> > > amount of UC scenarios.
> > >
> > >
> > > Or should they only focus on the written description of the UC
> scenarios
> > > and
> > > leave the testers to draw the actual messages?
> > >
> > >
> > > Cheers,
> > >
> > > Jean-Claude
> > >
> > >
> > > -----Original Message-----
> > > From: Kopetzky, Volker [mailto:[EMAIL PROTECTED]]
> > > Sent: 14 February, 2001 9:06 PM
> > > To: Antonio Jean Claude;
> > > "'=SMTP:[EMAIL PROTECTED]'"@ns2.cargolux.com
> > > Subject: AW: (ROSE) Test scenarios
> > >
> > >
> > > Jean Claude,
> > >
> > > well, everyone should provide input for the testers!
> > >
> > > It's more the thinking about who owns the requirements that are to be
> > > tested.
> > > Every role in your team provides/influences requirements:
> > > - analysts (e.g. business rules, 'boundary' requirements, ..)
> > > - designers (e.g. RDBMS mechanisms, Messaging requirements, ..)
> > > - developers (e.g. coding conventions, implementation requirements,
> ..)
> > >
> > > My suggestion would be that every role provides specific requirements.
> > > Every (testable) requirement type has an attribute 'Test: yes/no'.
> > >
> > > The testers then can filter the requirements and implement the
> > 'requested'
> > > tests. With some integration, empty test scenarios can be
> 'precreated',
> > > and
> > > the tester also has access to further needed documentation (e.g. a
> > > UC-scenario
> > > can be used to navigate to the use case document).
> > >
> > > With best regards,
> > > Volker
> > > TIPS & TRICKS:
> > > Try 'Help:Extended Help' in any Rational Tool
> > > ********************************************************************
> > > Volker Kopetzky
> > > Senior Systems Engineer/Expert Phone: +49 / 89 - 62838 - 293
> > > Rational Software eFax: +49 / 89 - 62838 - 593
> > > Keltenring 15 Fax: +49 / 89 - 62838 - 269
> > > D-82041 Oberhaching MailTo:[EMAIL PROTECTED]
> > > Germany URL: http://www.rational-software.de/exp/vzk
> > > ********************************************************************
> > > Rational...
> > > -> Suite:
> > > http://www.rational.com/products/rs/index.jtmpl
> > > -> Requisite Pro:
> > > http://www.rational.com/products/reqpro/index.jtmpl
> > > -> Unified Process:
> > > http://www.rational.com/products/rup/index.jtmpl
> > > -> Rose - unoffical website:
> > > http://www.rationalrose.com
> > > -> Upgrades:
> > > http://www.rational.com/sitewide/support/upgrades/
> > >
> > >
> > > -----Ursprüngliche Nachricht-----
> > > Von: Antonio Jean Claude [mailto:[EMAIL PROTECTED]]
> > > Gesendet: Mittwoch, 14. Februar 2001 11:11
> > > An: [EMAIL PROTECTED]
> > > Betreff: (ROSE) Test scenarios
> > >
> > >
> > >
> > > Hi all,
> > >
> > > This is more a question of organisation than a Rose question.
> > > Our project is divided into 4 groups:
> > > - analysts
> > > - designers
> > > - developpers
> > > - testers
> > >
> > > The analysts are working on Use Case description and Conceptual
> Diagrams
> > > (Class diagram representing Domain concepts). They describe use cases
> > with
> > > a
> > > flow or events.
> > >
> > > Should they take care of the creation of the Test scenarios?
> > > If not, who are the best candidates to create them?
> > >
> > > Thanks,
> > >
> > > Jean-Claude
> > >
> ************************************************************************
> > > * Rose Forum is a public venue for ideas and discussions.
> > > * For technical support, visit http://www.rational.com/support
> > > *
> > > * Admin.Subscription Requests: [EMAIL PROTECTED]
> > > * Archive of messages:
> > > http://www.rational.com/products/rose/usergroups/rose_forum.jtmpl
> > > * Other Requests: [EMAIL PROTECTED]
> > > *
> > > * To unsubscribe from the list, please send email
> > > *
> > > * To: [EMAIL PROTECTED]
> > > * Subject:<BLANK>
> > > * Body: unsubscribe rose_forum
> > > *
> > >
> >
> *************************************************************************
> > >
> ************************************************************************
> > > * Rose Forum is a public venue for ideas and discussions.
> > > * For technical support, visit http://www.rational.com/support
> > > *
> > > * Admin.Subscription Requests: [EMAIL PROTECTED]
> > > * Archive of messages:
> > > http://www.rational.com/products/rose/usergroups/rose_forum.jtmpl
> > > * Other Requests: [EMAIL PROTECTED]
> > > *
> > > * To unsubscribe from the list, please send email
> > > *
> > > * To: [EMAIL PROTECTED]
> > > * Subject:<BLANK>
> > > * Body: unsubscribe rose_forum
> > > *
> > >
> >
> *************************************************************************
> > >
> > ************************************************************************
> > * Rose Forum is a public venue for ideas and discussions.
> > * For technical support, visit http://www.rational.com/support
> > *
> > * Admin.Subscription Requests: [EMAIL PROTECTED]
> > * Archive of messages:
> > http://www.rational.com/products/rose/usergroups/rose_forum.jtmpl
> > * Other Requests: [EMAIL PROTECTED]
> > *
> > * To unsubscribe from the list, please send email
> > *
> > * To: [EMAIL PROTECTED]
> > * Subject:<BLANK>
> > * Body: unsubscribe rose_forum
> > *
> >
> *************************************************************************
> >
> >
> > ************************************************************************
> > * Rose Forum is a public venue for ideas and discussions.
> > * For technical support, visit http://www.rational.com/support
> > *
> > * Admin.Subscription Requests: [EMAIL PROTECTED]
> > * Archive of messages:
> > http://www.rational.com/products/rose/usergroups/rose_forum.jtmpl
> > * Other Requests: [EMAIL PROTECTED]
> > *
> > * To unsubscribe from the list, please send email
> > *
> > * To: [EMAIL PROTECTED]
> > * Subject:<BLANK>
> > * Body: unsubscribe rose_forum
> > *
> >
> *************************************************************************
> >
> ************************************************************************
> * Rose Forum is a public venue for ideas and discussions.
> * For technical support, visit http://www.rational.com/support
> *
> * Admin.Subscription Requests: [EMAIL PROTECTED]
> * Archive of messages:
> http://www.rational.com/products/rose/usergroups/rose_forum.jtmpl
> * Other Requests: [EMAIL PROTECTED]
> *
> * To unsubscribe from the list, please send email
> *
> * To: [EMAIL PROTECTED]
> * Subject:<BLANK>
> * Body: unsubscribe rose_forum
> *
> *************************************************************************
>
>
************************************************************************
* Rose Forum is a public venue for ideas and discussions.
* For technical support, visit http://www.rational.com/support
*
* Admin.Subscription Requests: [EMAIL PROTECTED]
* Archive of messages:
http://www.rational.com/products/rose/usergroups/rose_forum.jtmpl
* Other Requests: [EMAIL PROTECTED]
*
* To unsubscribe from the list, please send email
*
* To: [EMAIL PROTECTED]
* Subject:<BLANK>
* Body: unsubscribe rose_forum
*
*************************************************************************
