From: Laura on
Dear all,
I need a little help to depict a sequence diagram.

My use case is : a client issues a request to a Servlet.
The Servlet registers to a TimerListener and then starts a remote back-
end service.

If the service is not completed within "x" seconds then the
TimerListener invokes the timerExpired methods and return a "Server
busy" page to the client.

I'd like to depict this scenario with a sequence diagram but I don't
know how to handle the TimerListener event ( that can raise if the
back-end operation takes too long).

Any help ?
Thanks a lot
Laura

From: H. S. Lahman on
Responding to Laura...

> Dear all,
> I need a little help to depict a sequence diagram.
>
> My use case is : a client issues a request to a Servlet.
> The Servlet registers to a TimerListener and then starts a remote back-
> end service.
>
> If the service is not completed within "x" seconds then the
> TimerListener invokes the timerExpired methods and return a "Server
> busy" page to the client.
>
> I'd like to depict this scenario with a sequence diagram but I don't
> know how to handle the TimerListener event ( that can raise if the
> back-end operation takes too long).

It depends upon whether the timer is explicitly modeled in the
subsystem. Since most timers are OS services, they are usually treated
as external entities. In that case you would treat them like a use case
actor. If the timer has unique properties for the problem in hand and is
explicitly modeled, then it would be treated just like another other object.

BTW, some people don't bother creating swimlanes for use case actors.
They just provide arrows to/from the relevant objects w/o anything on
the other end. Personally I don't like that practice because one can
create interaction diagrams for partial processing and then it may be
ambiguous where the messages are going /within/ the subsystem.

FWIW, though, a timer introduces inherently asynchronous behavior
because you usually cannot tell when the timer will trigger relative to
other processing that is ongoing. In that case a Collaboration Diagram
might be a better choice because there is no need to "hard-wire" a
particular sequence of messages.


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl(a)pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info(a)pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH