The differences between able OOAD people on how to use basic tools are a
never-ending fascination to me. Modelling of login as a use case is a
good example of a vexed question that may be best answered with
Tarkington's (Perverse) Principle: "It's better that it be standard
than that it be good." Hence, lacking a standard, there is no answer.
Still, here's my take. If it is behaviour, you can model it, but you
have to decide how. You model big hunks of behaviour with use case
descriptions and diagrams. You model the smallest chunks of behaviour
with code (which just happens to execute, so you might as well stop at
that point).
A login is necessary black box behaviour of the system. It gives
something of value to an actor: access. So, I won't think ill of you if
you make it a use case that some use cases <<include>>. A login is also
trivial enough so that I won't think ill of you if you just insert it as
behaviour within selected use case descriptions for the system.
Certainly, my students want to make use cases of logins (you'd have to
beat them with a stick to stop them), and that appears to be the naive
approach. If it isn't right, it's probably close enough.
With respect to logouts, I'd ask this: is your logout going to be about
as subtle as pulling out the power plug? If there are no subtleties to
logging out that would be visible to an actor, you don't need to model
it, even though logout gives something of value to the actor (dismissal
of unwanted access). If there are subtleties that matter (such limiting
access in logged-out conditions for data security/access control), then
you might model the logout as a use case. If the extreme triviality of
the logout process makes you feel guilty about making a use case of it,
you are a diligent human being.
A trivial behaviour may, nonetheless, have a logical role in the
behaviour of the system that justifies making that behaviour a use case
that has a description and appears in one or more use case diagrams.
-Eric
Maheswari Subburaman wrote:
>
> 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
*
*************************************************************************
