• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

MVC sequence diagram

 
Juee Doo
Ranch Hand
Posts: 232
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi All,

I am working on Part II.

I use my MVC in my design.

I used many J2ee pattern in my design. such FrontController,Service to Worker, SessionFacade....

When i draw the sequence diagram, i have a trouble.

Because of many Pattern classes used, most of them are not business related, but they effect in every request process.

eg. The user issue a request, the ruquest will to Filter,FrontController,Service to Work Dispatcher, and then goto the Worker that process business. when process end, the FrontController will forward to the result page.

If i put all of above into each sequence of each use case, there will be many duplicate.

So, I give a separate sequence to desc the main framework of my design. it includes above business irrelative classes.

But, when i create the sequence diagram for use case, i find it difficult to avoid above classes.

1> the user send request to Worker, and then need to return the result page. because not have FrontController. If i draw stimulus from Worker to resultPage, it conflicts with my design, because the design is: the result page is forward by FrontController not by Worker.

2> The stimulus name is must exist in the called class?

 
Ronald Wouters
Ranch Hand
Posts: 190
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I had a similar problem. In my design I make use of JSF framework. As you know JSF has things like NavigationHandler, ViewHandler and stuff...
I did not want to show all the internal JSF flow that happens when navigating from one page to another. I would have to repeat that in each sequence diagram.
So I put a generic "display" message on the diagram even though no such method exists in reality, (remember the difference between a uml "message" and "operation" ?) with a note saying "internal JSF flow not shown for clarity". As you will agree, clarity and therefor good communication should be a primary purpose of any diagram. Removing the "clutter" of the internal JSF flow, in my opinion makes for a much clearer and therefor better to understand diagram, by the assignment assessor (and anyone else).

Regards
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic