Modeling variations in common processes

[ScottUML]

I'm trying to model how an http request is handled by an internal (and custom) servlet framework.  We have several servlets that extend a base servlet.  Each extension of our base servlet overrides factory methods to create instances of other objects the system uses.  But in all, the process of handling a request is roughly the same.  A controller object is created and control is passed to the controller, which is the variable behavior I want to model.

So what I created is a use case "Handle HTTP Request" that models the generic case of getting the request and passing off to the controller.  I created a participants class diagram that shows the base classes and all the extended objects.  In the sequence diagram, whenever I hit a juncture that involves extended behavior, I make a note (I'd like to link the note to the message but can't get it to stick).

Now I would like to model use cases where the controller is created as a result of this sequence.  How would this best be done?  I'd like to in a sequence diagram indicate that the "Handle HTTP Request" use case was invoked with a certain set of request parameters which created the controller and invoked it, which is where the current sequence begins.

Thanks for any input you can provide.

[sargasso]

I am having a lot of trouble understanding this.

I, personally, as a computer user have never had the desire to "Handle HTTP request".

ymmv

[qwerty]

This is likely because you are not a computer. Or, to be more accurate, a piece of software running on a computer.

Try a different odometer.

q.

[Geert Bellekens]

I can understand where bruce's comment comes from.
"Handle HTTP request" does indeed sound somewhat limited and technical to be a (SMART) primary use case.
One of the better means to decide whether or not your (primary) use case is a "good one" is the BOSS test:
Ask yourself: "Is my boss going to be happy if I <insert use case> 100 times?"

Geert

[qwerty]

We have spilt use cases into <<business>> and <<technical>>. Your statement is true for the <<business>> UCs. In case of the <<technical>> ones it must read: "Is my computer/software going to be happy if I <insert use case> 100 times?". A bit weird, but who knows what happiness is anyway?

q.