Originally posted by Pietro Vigone:
Let me try with a different question: take a couple of diagrams from Cade and Robert's book, and explain me why something is a Component and something not.
Originally posted by Paul Newton:
A Component Diagram as defined by UML is not tied to any methodology. UML is simply a notation - it does not imply any process (RUP or otherwise).
UML defines the notion of components separately from classes. I realise that the UML definition is not entirely clear, but the idea is that a component is more oriented towards a module or replacable unit. This is typically a set of classes that together form a discrete part of the system. Try thinking in terms of abstraction - components are more high-level - think BillingComponent, ReportGenerator, SecurityManager, where classes are at a lower-level (Customer, Principal, Role, Account, Report etc).
A component is typically made up of other classes. A component diagram shows how classes relate to components, how components relate to other components, and how components relate to physical artifacts (files etc).
I think the source of your confusion comes from the difference between a component and a class. I have just looked at Cade's book, as this is the one you seem to be using. First of all, I would say that Cade is not necessarily the best book to learn about UML. It is written with a very specific purpose in mind (passing the exam), and its treatment of UML is very brief, and not always that clear.
There are 4 examples of Component Diagrams. I agree that if this is all you have to go on, then the difference between components and classes is not very clear. The SearchController servlet is shown as a component. Isn't this just a class? Well, yes, in this case it is. As UML states - a component can be made up of 1 or more classes.
Components become more interesting when you start building classes together into a single module. Think of an EJB. This typically has a bean implmentation (EnterpriseBean), a generated stub (EJBObject) and a home (EJBHome). There may be some other DAOs and other classes thrown in as well. This group of classes provide a single, coherent purpose - a component. You would show all the EJB classes on a class diagram, while you could show them as a single component on a component diagram (exposing a set of interfaces).
In the Cade example, the Component Diagrams only show dependencies betwen components (SearchController uses SearchEngine). But Component Diagrams can be much more expressive than this - you can show how the classes are packaged into the component (EJBHome, EJBObject, EnterpriseBean etc relating to the EJBComponent). You can show how the components are realised in files (MyBean is implemented in mybean.jar). None of this comes out from the Cade book, so that Component Diagrams start to look more like Class Diagrams. Or lets just say, that the benefits of a Component Diagram in the Cade book are not quite as apparent.
You referred to control and entity classes. These are sterotypes that are proposed in the Rational Unified Process, that came from Jacobson's Objectory work. They are simply sterotypes that can be attached to classes during the early analysis phases. They are useful for analysing Use Cases, and identifying the initial classes. These stereotypes have nothing to do with components in a Component Diagram. However, I can see why this might appear that way in the Cade examples.
Traditionally, I think design literature (and practice) has focused on the class abstractions at the expense of components. In addition, the UML specification has sometimes been criticised for a vague definition of components. With the more widespread use of components models (OLE/COM/DCOM/DNA, EJB, CORBA Component Model etc), this is starting to change.
I hope this helps. The best advice I can give is to take a look at some other UML resources. This will give you a much more rounded view of UML, and how it is used. 'UML Distilled' by Fowler is pretty much a classic. Craig Larman's 'Applying UML and Patterns' is one of the best books I have read concerning modelling and the development process. There are some books that deal more with components (Building Web Applications with UML by Jim Conallen). Look also at the UML spec - I know it is dry reading - but once you get used to the layout, it is invaluable.
Your final point about the exam - do you need to 'understand' or 'guess' the role of a Component diagram? Well - you would be better asking someone who has passed or written the exam. If the Cade book is representative of the exam, then I do not think the level of UML knowledge required is very detailed. The UML chapter in Cade is very brief and does little more than a quick fly-through of the main points.
Hope this helps.