details in diagram

[serzeel khan]

I want to know about the amount of details in the uml diagrams in the ocmjea part2 assignment.

1. if i,m using jsf in the presentation and since a master controller is present in the jsf implicitly.
I,m planning to skip the controller in the class diagram and show xhtml and managed beans instead.


2. In which diagram i have to show the business interfaces for session beans in the class diagram or component diagram

3.Suppose i have a session bean which is interacting with a web service,do i need to show the DAO in the class diagram or in component diagram.


I have read cade's chapter 9 and try to follow it ,but the diagrams are not uml complaints and filled with errors also.


i need suggestions on how to do this correctly.

[Jeanne Boyarsky]

1) There is no right or wrong answer. Do what makes sense. Why are you using XHTML and not a jsf page?

2) Definitely class diagram. Component diagram should show components which are the beans, but not the interfaces specifically.

3) Class diagram. Everything should be in the class diagram.

[serzeel khan]

Thank you for your response.
Few more things i like to know

1. If i use collaboration diagram instead of sequence diagram,do i need to give give reason why i choose collaboration diagram instead of sequence diagram.
In my assignment it is mentioned that "Create either a Sequence or Collaboration diagram for each use case provided".
And i feel comfortable in collaboration diagram.

2.For risk and mitigation, "i have to find the risk before designing the architecture and mitigate in the architecture" or "first i have to design the architecture than find the risk and give mitigation strategies."

Hope any one reply this.


thank you.

[Jeanne Boyarsky]

1) While you don't have to, I think you should. Sequence diagrams are much more common. And the reason to use a collaboration diagram should be that it is clearer, not because you feel more comfortable.

2) It's actually both. Largely before because you are thinking about how to mitigate risks. But you aren't going to mitigate all risks. Some you just have a plan/strategy for in case they occur.

[Paul Balm]

As far as the risks are concerned, I have found myself writing a few risks down, like this can go wrong and that can go wrong. Only to realize, that I was pointing out problems in my architecture, that I should fix rather than to demonstrate that there was a problem. In fact, I found myself writing that if x goes wrong, then I should just change y. So do it, and don't assume it won't be necessary. This is an architecture assignment after all.

What i'm saying is, you should think about the risks before and come up with an architecture that addresses (mitigates) them. When you're done, you write down the risks that have not been completely mitigated yet. When you're done writing down the risks, check them to make sure that you're not pointing out mistakes you made that you should fix.

If you do find your risks are actually mistakes or shortcuts in your architecture, my recommendation would be to fix the architecture and remove the risk.

[William P O'Sullivan]

I find white-boarding extremely important, especially when disconnected systems are involved.

Say an app server and a DB server. Draw two boxes and a line between them.

Now put a big red X on the line. Would you architecture support fail-over or HA?

It does all depend on the infrastructure as well, so for each requirement their can be different options.


I am nicknamed "Cassandra" because I can usually accurately predict when bad things happen,
but no-one believes me. I believe this is a talent acquired seeing so many badly designed systems
that do not plan or cater for risk ahead of time.

WP

[Paul Balm]

I think that that's an interesting idea -- thank you for posting it -- and I think it's a valuable practice for architects. But I think this may also be an example where real life and the OCMJEA certification diverge a little bit... Especially since you get to design everything from scratch, for every component (app server(s) and DB(s)) you use a cluster and you connect everything with high-availability routers (typically a router with a back-up router attached to it in case of a failure), and you're done. For OCMJEA at the hardware level, there isn't much more to it than that.

I think the risks that you should be concerned about for the certification (this is a certification forum after all) are more of the type: What if this external system takes forever to respond, and what if a hacker gets into my database.