How much detail should be gone into when using JSF/Struts

I'm currently doing part 2 and have decided to use JavaServer Faces in my solution, but the problem I'm having is that I'm not sure how much detail I should go into.

Surely it's not sufficient to treat the framework as a 'black box', and surely I don't need to design every Component, Validator, Renderer, etc. However, if I take a middle-of-the-road approach, I'm just describing the JSF lifecycle (which anyone can get out of a book)!

Any suggestions? Surely, anyone that has used Struts has had a similar issue?

Cheers!

Originally posted by Andy Fisher:
I'm currently doing part 2 and have decided to use JavaServer Faces in my solution, but the problem I'm having is that I'm not sure how much detail I should go into.

Surely it's not sufficient to treat the framework as a 'black box', and surely I don't need to design every Component, Validator, Renderer, etc. However, if I take a middle-of-the-road approach, I'm just describing the JSF lifecycle (which anyone can get out of a book)!

Any suggestions? Surely, anyone that has used Struts has had a similar issue?

Cheers!

Hey Andy,

My suggestion for you is, try to keep your design the simpliest as possible. Architecture design means that you should create an design from a very higher point of view.

So, try to think only in the architectural issues, like MVC framework. Think only in views, controllers and models. If you use an specific technology, you could create an architecture that is poor, because the technology can became obsolete (like Struts).

An real and good architecture, must be technologyless to promove yours adaptability. You should can use this design for five years from now. If the developers and system enginners decide to use an framework, your architecture MUST SAY TO THEM, WHICH KIND OF FRAMEWORK TO USE.

As an tip, you could mention in your documentation, which possible frameworks to use. Remember: As an architect:

"YOU SHOULD KNOW THE BEST AND SHORTEST WAY, BUT THE DEVELOPERS MUST DISCOVER THE DESGINED MAP"

Good Luck!

Yeah, that sounds perfect. Cheers!

...just a thought: when I'm doing my class/sequence diagrams, should I go down to the level of defining 'Factory Method', 'Observer', etc. patterns?

Originally posted by Andy Fisher:
...just a thought: when I'm doing my class/sequence diagrams, should I go down to the level of defining 'Factory Method', 'Observer', etc. patterns?

Well, I can�t tell you if you should or not put those architectural patterns in the diagrams since this a kind of decision that relies your vision of the assignment.

The only thing that I could tell you is, YES, you can put it this patterns in the diagrams. If you do not put it, that�s ok, no problem.

The essence of UML is describe a system without words and conversation. The most important is: PASS THE INFORMATION!

Best Regards!

Hi ranchers!
Can someone take a look at this? I have my doubts about it...
Does this mean that it's not an architect's role to determine which technology is to be used? Have someone passed part II undcer this philosophy?
Best regards
XM

Guys, can someone shed some extra lights over this?

Marx,

Does this mean that it's not an architect's role to determine which technology is to be used?

The architect's role is to define precisely which technology is to be used. These days, every developer is extremely biased about their technical preferences and ignorance plays a huge role in many decisions. Therefore, the architect has to be the ultimate decision maker and document these decisions to the best of her/his abilities.

Regards,
Dan

Sounds reasonable,
thanks for your comments Dan,
XM