Another 2 cents:
A user does not go to the system just to log in. Still, it has to be done.
The "right" way to describe log-in in use cases is probably to insert the
following lines into every use case, which needs the user to be logged in:
Step i: The User enters user name and password.
Step i+1: The System validates user name and password.
Exception to step i: The User is already logged in. => Skip steps i
and i+1.
Exception to step i+1: The user name and password are not valid. =>
Repeat from step i.
The lines above will need a lot of writing (and testing) to be done if there
are more than a few use cases. In this case, one would normally create an
included login use case that contains the lines above, and then <<include>>
the login use case in the "real" use cases.
So (IMHO), login is not a use case; it is an included use case. Included use
cases more or less resembles macros to be inserted into "real" use cases.
The above solution works well, as long as one has only a limited number of
"preconditions". Otherwise, the "real" use cases may get cluttered with
lines stating the correct order of use case inclusion etc.
A more elegant way is to regard the login use case and other "included" use
cases as "low level" use cases, which cause the system to change its state,
and then presume the resulting system state(s) as preconditions in the
"real" use cases. The low level login use case text will be nearly identical
to the included login use case text, except for the explicit state change:
Step i: The User enters user name and password.
Step i+1: The System validates user name and password and transits
to the user-logged-on state.
Exception to step i: The System is already in the user-logged-in
state. => Skip steps i and i+1.
Exception to step i+1: The user name and password are not valid. =>
Repeat from step i.
The precondition in the "real" use cases will be:
Precondition: The System is in the user-logged-in state.
Using this approach, it is easy to add complex preconditions that may be
based on a number of system states and substates. IMHO, the definition of
use cases should be extended with this kind of "low level" use cases, which
change the state of the system, but maybe have no other value to the user.
Bear in mind: "It is not the use cases that limit you, it is what you do
with them!"
Best regards
Lars Ivar Hauschultz
Project Manager
INFOCOM - a company in the Maersk Data Group
E-mail: mailto:[EMAIL PROTECTED]
Web: www.infocom.dk
-----Original Message-----
From: David O'Leary [mailto:[EMAIL PROTECTED]]
Sent: 14. marts 2001 02:16
To: [EMAIL PROTECTED]
Subject: Re: (ROSE) Whether Login and Logout are usecase or
pre-condition and post-condition?
I'd recommend you all go through the webinar titled, "Writing Good Use Cases
with Rational RequisitePro and Rational Rose". It should be in the Webinar
Archive.
In it they deal with this question for the ATM Example. They say it should
not be a use case because a user does not go to the system to login, they go
to the system to withdraw money, transfer funds, ... and to do these things
they have to log in.
So while logging in may not be part of the Use Case Diagram, it will
certainly be part of the Use Case Specification.
Use case Diagrams are not supposed to describe the implementation of the
system, merely who the uses are, and how the will use the application.
Hope this helps,
David O'Leary
Habanero Computing Solutions
----- Original Message -----
From: "Jason Gorman" <[EMAIL PROTECTED]>
To: "Logan Wilkins" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, March 13, 2001 7:00 PM
Subject: RE: (ROSE) Whether Login and Logout are usecase or pre-condition
and post-condition?
>
> Yep. Yet another weakness of use cases! I would pester your rational
> consultant about this one - they don't seem to cover permissons and
security
> in their DNA or J2EE frameworks. Well spotted!
>
> Jason Gorman
> http://www.xml-objects.com
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Logan Wilkins
> Sent: 13 March 2001 19:39
> To: Maheswari Subburaman; [EMAIL PROTECTED]
> Subject: RE: (ROSE) Whether Login and Logout are usecase or
> pre-condition and post-condition?
>
>
>
> Maheswari:
>
> My $.02 are that Login is a valid precondition. I use all sorts of
> preconditions to get to the stage of the system where I want to begin my
use
> case. For example:
>
> Preconditions:
> - User has logged in
> - User has clicked on Main Order Form
> - User has entered at least one valid hardware part number
>
> Why not use them? They are unambiguous (or should be) and make it very
easy
> to get to the action that I want to describe. I advise against making
> writing use cases harder than it needs to be. Keep it simple.
>
> Also, IMHO Login is a valid use case. The value it provides is that the
user
> gains access to a restricted system.
>
> Logan Wilkins
> Ciso Systems
>
>
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Maheswari Subburaman
> > Sent: Tuesday, March 13, 2001 2:10 PM
> > To: [EMAIL PROTECTED]
> > Subject: (ROSE) Whether Login and Logout are usecase or pre-condition
> > and post-condition?
> >
> >
> >
> > Hi Everyone,
> >
> > I know this question came on the forum many times,
> > still it troubles me to decide Login and Logout either
> > as independent use cases or just pre and post conditions
> > of other usecases which actually carry out the functionality
> > of the system or solve the purpose of the User.
> >
> > In one of the earlier questions I knew Login was taken as
> > a use case and then was considered as Pre-condition of
> > other use cases. But I am not able to get convenienced
> > that "Login" can be a usecase itself , since it indepenently
> > does not return some thing useful to the Actor. The actor
> > is going to access the required useful information only
> > after Login.
> >
> > For example I have a usecase "View race Information"
> > which is initiated by the actor known as "Member" .
> > To view this information the the member must have already
> > logged in. But I don't want to make Login as a separate use case,
> > because it does not return any thing to the actor as such.
> >
> > Now the problem is if Login is not a use case then what it is?
> > Where I can have it? If I can have it as a pre-condition then
> > I am worried where the flow of events which take place during
> > Login can be accomodated.
> >
> > Any suggestion most welcome.
> >
> > Thanks
> > Maheswari
> >
> > ************************************************************************
> > * 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
*
*************************************************************************
