|
From: Laura on 29 Aug 2007 04:31 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 29 Aug 2007 11:00 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
|
Pages: 1 Prev: Are you using Agile methods? If so, do you model? Next: Good OO book |