I mean "acceptable" for the OCMJEA examinator.
Otherwise could you post some "graphic" example.
The stereotype of the class (stuff between << >>) indicated whether the class is JSF, managed bean, EJB etc.
Edit: Don't forget there is a front controller FacesServlet in between the JSF page and managed bean
Therefore I am using this notation, which I discovered is given in the example assignment in the Oracle Book.
Ready to switch to a new tool :-)
Also, did I really need to put xhtml and FacesServlet ? Faces servlet is supposed to be given by the "technology" (jsf) where's the point in specifying it in the class diagram. Please consider these last two questons as a lack of uml knowledge on my side.
Leonardo Celati wrote:Also, did I really need to put xhtml and FacesServlet ? Faces servlet is supposed to be given by the "technology" (jsf) where's the point in specifying it in the class diagram. Please consider these last two questons as a lack of uml knowledge on my side.
Apparently yes. Suppose you didn't use JSF, no framework whatsoever. Plain old servlet. Will you consider having a front controller servlet?
If you do use another framework like Struts or Spring, these themselves have a front controller. Beside front controller is a core J2EE design pattern.
It doesn't matter what JEE technology you use, but should understand why you use it in the first place along with its pros and cons.
Whatever you got in the class diagram will also be in sequence diagram as you move from tier to tier.
First, a number of IDEs apparently generate template backing beans giving them names like "XxxxController". That is wrong. A JSF backing bean is not an MVC Controller, it's a modified Model. It can also serve as anchor to sub-Models, which can be other JSF Managed beans and/or general POJOs including Persistence Model objects. In rare cases, a Persistence Model object can itself be a JSF backing bean, but since JSF's mechanisms for instantiation and wiring are limited, that's usually not a good idea.
To be precise, a JSF backing bean is a UI Model* which can also house event listeners and business methods (action methods). It does not perform the functions of an MVC Controller, which would be to synchronize the values in the Model and View. In JSF, the master Controller is part of the FacesServlet, sub-controllers exist in JSF tag implementations. Since creating your own JSF binary tags is something best done only if a whole raft of simpler solutions cannot suffice, I prefer to say that you should "never" write any Controller code when using JSF.
There are a number of factory/wiring frameworks that can implement JSF functionality, including the original JSF faces-config/annotation, CDI and (to an extent) the Spring Framework. Since these mechanisms are not, strictly speaking, application logic or components, my own opinion is that any diagrams of the application should probably not be showing any differences in which means of bean instantiation or wiring is done. But that's my opinion, and others may have different ones.
The xhtml is a View Template. Technically, that makes it a constant data structure, although some people do have the regrettable tendency to code business logic on them. The actual View is generated by the rendering engine of JSF. JSF actually supports multiple rendering engines, but usually the HTML engine is the one everyone uses.
In practical terms, I wouldn't normally diagram the FacesServlet in, or the tag classes or the built-in validators, for the same reason that I wouldn't do detailed mapping of the Java core class libraries. They are invariant, and therefore including them in the application diagram would tend to bury the app-specific information under a load of repetitious details. They have their own, external diagrams, generally as part of the spec that defines them. Of course, here again needs may vary. After all one of the reasons I have little patience with cert exams is that they often focus overmuch on minutiae .
Finally, JSF is a navigation-based technology, where the selection of the next View is frequently determined by selections made in the preceeding view mitigated by a backing bean(s). So practical diagramming of a JSF app is often defined in terms of workflows and in resources (such as Views and Models) that facilitate the workflows.
* Except when it isn't. The 3 types of components of a JSF Managed Bean are UI model properties, listeners, and action methods (which are fired by the listener mechanism). So a backing bean can be all logic, with no actual model data. But that still doesn't make it a Controller.
As a View backing bean, it's Presentation. As an Action handler, that would make it Business. Although recommended design is that any major business logic should be in a separate business-only bean.
Note also, that a Managed Bean in JSF terms is any JEE object that JSF can instantiate. It is perfectly possible to define Managed Beans that are logic-only and have them instantiated and injected automatically into one or more managed presentation Model objects. Such an app might be diagrammed wuth the UI model Managed Beans in the Presentation Tier and the business logic Managed Beans in the Business Tier. And the mixed-use Managed Beans are your call!