Maintating a Sesson Use Case

[Bertabs]

How do you represent a session maintanance in a use case diagram? An
example of what I am creating is this.

Suppose I am interfacing a social networking site, site A (which is a
system actor) and I am to create an application that would interface
its function such as the following:

- user can post comments

However my system will need to create a session with the system actor
first before he can post comments. thus the use case will look like
this,

user (actor) <<invokes>> post comments use case <<includes>> session
use case

My system will be the one to get the username and password of the user
so will I change the use case to

user (actor) <<invokes>> post comments use case <<includes>> login
<<includes>>session use case

I am confused since the user should login only once and reuse the
session( aka cookies) once he has logged in once and should not login
in again if the session is present.

[H. S. Lahman]

Responding to Bertabs...

> How do you represent a session maintanance in a use case diagram? An
> example of what I am creating is this.
>
> Suppose I am interfacing a social networking site, site A (which is a
> system actor) and I am to create an application that would interface
> its function such as the following:
>
> - user can post comments
>
> However my system will need to create a session with the system actor
> first before he can post comments. thus the use case will look like
> this,

This sounds like you have already designed your system and are
back-filling with use cases to describe it. My advice: Don't Do That!

Use cases define requirements for the design. You develop the use cases
first and then design the system around them.

>
> user (actor) <<invokes>> post comments use case <<includes>> session
> use case

That's fine as long as you have a separate use case for

user <<invokes>> session

to indicate that 'session' is also a primary activity. The problem is
that it tends to be tedious to include 'session' with all the other
primary activity use cases. Typically nobody does that because the rule
that the user must log in and create a session before doing anything
else can be expressed implicitly (as a problem space idiom) or
explicitly in the 'session' documentation.

An alternative is to make all the other primary activity use cases
variants of 'session', but that is really clumsy.


--
Life is the only flaw in an otherwise perfect nonexistence
-- Schopenhauer

Imagine how much more difficult physics would be if electrons had feelings
-- Richard Feynman

Rene Descartes went into a bar. The bartender asked if he would like a drink. Descartes said, "I think not," and disappeared.

H. S. Lahman
H.la...@verizon.net
software blog: http://pathfinderpeople.blogs.com/hslahman/index.html
software book: Model Based Development, Addison-Wesley, 2011
geology book: The Evolution and Utilization of Marine Resources, MIT Press, 1972