I can't tell you in terms of a cert exam - I don't do certs myself. But as moderator of the JSF forum I can tell you some things about JSF that may help your diagramming strategy.
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.