This week's book giveaway is in the OCPJP forum. We're giving away four copies of OCA/OCP Java SE 7 Programmer I & II Study Guide and have Kathy Sierra & Bert Bates on-line! See this thread for details.
I'm still pretty young in "real development" matters -- so hopefully this is the right place to annoy you all with my question. I'm trying to be able trace my "use-case" to a set of "use-case-realization-analysis" (which are just analysis classes, e.g. boundary, entity, control) to a set of "use-case-realization-design" classes, which would be my Struts guys and whatever else does the job.
The problem is, I don't know how detailed I should be. Here's what I have for my imaginary use case which does: client invokes action, Struts ActionServlet gets request, creates a FormBean, validates it with the validator, delegates to my Action, which delegates to some imaginary business delegate in my model, after which it return some ActionMapping, the ActionServlet returns the mapped JSP file. (Good ol' model-2 stuff.)
For my analysis realization, I have a customer (actor) <-> form (boundary) <-> worker (control) <-> thing (entity). Pretty simple, no biggie. And I think that's about the level of detail I need for an analysis realization (especially a made-up one). Those "<->" are supposed to links in my collaboration diagram.
For my design realization, I have customer (still just an actor) <-> ActionServlet (not traced from anything) <-> Action (traced from boundary-analysis guy) <-> worker (traced from control-analysis guy) <-> thing (traced from my entity-analysis guy). Now, of course my boundary and entity design classes may actually be multiple things, but that's beside the point.
I don't know if I really need to put my FormBean and the Validator in there somewhere. Ideally, I should be able to trace everything in my deployable component to some use-case-realization-design -> use-case-realization-analysis -> use-case -> feature, right? Should I still have traces for these "invisible" things -- which the ActionServlet use, but I don't explicitly in code, or should I include it as collaborations between the ActionServlet and the Validator and JSPs, etc?
I'm going to stop rambling now -- I figure for every extra line I type, somebody else closes their browser! Anybody have any advice? Oh -- sorry for all the arrows -- I wish I could include a picture, but oh well.
Thanks for any help.
Actually, it looks like I can do images: here's some - we'll see how this works. The names are different - sorry - but yeah. It's crude - I know.
I'm still pretty young in "real development" matters... The problem is, I don't know how detailed I should be.
Not to be crass, but how detailed your documents "should" be is rather subjective, to me anyway. Is there business value in lots of detailed UML diagrams? Does your customer want them? Does your manager want them?
I'd have a hard time seeing much business value in detailing with diagrams every user interaction with a Struts-based web application. In my experience, the different interactions tend to be very similar, following the pattern very much as you've outlined (except where you left out the form and validator). I think I'd prefer to at most describe the basic Struts interactions, as you've done, in a general sense, and suggest that pattern applies to most every interaction, with just a few names changed. Then, just write the code.
Also, note that I've noticed and used a few different tools that can take a Struts-based web application, and visually model the form-validator-action interactions, and tools that can generate interaction diagrams from source code. [ July 25, 2004: Message edited by: Dirk Schreckmann ]