How to apply UML notation for web application

[Janet Yap]

Hi,
I am developing a web-based information system for my project. This system will be developed using based on Model-View-Controller model. I have the following problems in applying UML for the project:
1.Do we include boundary objects and controller object in an analysis class diagram?
2.According to my project manager, we can have ONLY ONE analysis class diagram for a project. I wonder how all the classes can be fit into a diagram if we have a large number of classes.
3.System sequence diagram is used to document all the external events to the System. Is this mean that an operation (or system event) need to be created for every user click at a HTML page. If a user need to perform 10 clicks on html pages to compete a use case, is that means there will be 10 system events in the system sequence diagram of the use case.
4.How many collaboration diagram will we have for a use case? Is it ONE for each use case or ONE for each system event of a use case? (i.e. if the use case has 5 system events/operation, then 5 collaboration diagrams need to be created?)
Please advise. Thanks.
[ March 15, 2004: Message edited by: Janet Yap ]

[Lasse Koskela]

There are no rules. Well, actually, there are rules but those are completely made up from thin air. Your PM saying "we can have ONLY ONE analysis class diagram for a project" is the kind of sign saying "run, don't walk, away from this project"...
Models should be about design, which is a creative activity. Rules like "one foo per bar" tend to limit the usefulness of models and push them towards mandatory documentation for documentation's sake.
I'd suggest reading some of the essays by Scott Ambler.
If you simply have no choice but to obey the project manager's rules, it's probably a must to drop any trace of perfectionism with regard to the models and concentrate on satisfying the PM's expectations. He doesn't care whether the models are useful so why should you? (a bit of exaggeration, but just a bit)

[Greg Reinl]

Your PM saying "we can have ONLY ONE analysis class diagram for a project" is the kind of sign saying "run, don't walk, away from this project"...

Amen to that...
But if you're stuck on this project, then as Lasse suggests, you just need to make the best of it. One other point I would like to make is that even though you may not have any choice but to produce one overwhelming class diagram for your PM's benefit, you still can do what makes sense for your own analysis and design, even if that is just on whiteboards or scrap paper.

[Janet Yap]

Thanks for your opinion. I agree with both of you. What is stated in the book may not be practical and may not being practised in the real world. All the examples used in the reference are of a simple one. Thus, it is possible to put all classes in an analysis diagram.
May I know what is the practice in the real project world? Are there normally have more than one analysis class diagram? Can I create an analysis class diagram for each use case instead?Can I just include persistent entity objects in an analysis class diagram?

[Ilja Preuss]

Originally posted by Janet Yap:
1.Do we include boundary objects and controller object in an analysis class diagram?

In my understanding, an analysis class diagrams describes the *problem* you need to solve. I don't think that the terms "boundary object" or "controller object" do have any meaning in that context (but I could be wrong).
Anyway, it fully depends on *why* you are drawing the diagram. If you think the knowledge will be vital at that stage and can't be communicated in a more effective way, include them. Otherwise don't.

2.According to my project manager, we can have ONLY ONE analysis class diagram for a project.

Why the hell would that be???

3.System sequence diagram is used to document all the external events to the System.

What for?

Is this mean that an operation (or system event) need to be created for every user click at a HTML page. If a user need to perform 10 clicks on html pages to compete a use case, is that means there will be 10 system events in the system sequence diagram of the use case.

Depends on what you want to model.

4.How many collaboration diagram will we have for a use case? Is it ONE for each use case or ONE for each system event of a use case? (i.e. if the use case has 5 system events/operation, then 5 collaboration diagrams need to be created?)

You need to create enough diagrams to be able to go the next step. You should create one collaboration diagram for each collaboration you find interesting to explore, but *only* if you don't know a more effective way to do so.

[Ilja Preuss]

Originally posted by Janet Yap:
Thanks for your opinion. I agree with both of you. What is stated in the book may not be practical and may not being practised in the real world.

I am curious - are you speaking about a specific book?

[Stan James]

People referring you to Scott Ambler's essays are right on. In a recent email newsletter he talked about the right reasons to document - to communicate to external groups, to communicate clearly to peers, to help yourself figure things out, etc - and the wrong reasons. Good things to check yourself against now & then.
Boundary & controller objects. Start with them there on your first cut. Depending on your framework and platform, controllers may go away as other objects take on the responsibilities. If they're not interesting after the third diagram, ditch em.
The ONE CLASS DIAGRAM is pretty silly. When I started using Rational Rose it was a neat epiphany to understand it held one MODEL but let you draw many DIAGRAMS with any subset of the model you needed to get some idea across. The difference between model & diagram might help you talk this through with the mgr. If he's seriously clueless about OOAD, try to enlighten him or brush up your resume.
Sequence diagram per external stimulus. Probably overkill, but a useful thing to think about. What I usually find is that the first one is very interesting, the second one is real similar, and most of the rest are (yawn) more of the same. You'll find yourself working out an architecture that explains the general case, and only the exceptional cases are interesting after that. I'm on a new system right now with an unfamiliar vendor architecture, so we're hammering out a notation to show multiple interactions in one diagram, trying to see what's important and what's not. We've done that first really interesting one so far. I'm sure by next month these diagrams will be much briefer and we'll have a vocabulary of standard bits that make most pictures unnecessary.
Collaboration diagrams - break em up when they get too messy to read.
Try to relax, adapt your design techniques to the situation, don't feel locked into any "right" set of artifacts or processes. I hope you can have fun at this in your environment.

[Mcgill Smith]

I liked this book
"Building web applications with uml" by Jim Conallen.