What's the purpose of Component Diagram

[Pietro Vigone]

Hi all,
I have doubts about the purpose of Component Diagram. I know just a little of the Rational Unified Process, and I have not found a large use of Component Diagrams in it: according to RUP, an architect draws Class Diagrams, where the classes are stereotyped as <<boundary>> or <<control>> or <<entity>>. In RUP, a Component Diagram would probably just duplicate information already given in Class Diagrams.
In Mark Cade's book it seems that the Class Diagram is mainly aimed to display the <<entity>> classes (which are not necessarily Entity EJBs, btw); while components, in the Component Diagram, are somewhat similar to <<boundary>> and <<control>> classes. Also, the Component Diagram gives an hint of the processing flow.
Am I wrong? Or, does somebody know if Cade follows some different but well known metodology or convention?
Thanks for your help
Pietro

[Rufus BugleWeed]

Cade and Roberts says the component diagram shows the dependencies of components on each other.
They are sort of vendor agnostic about a methodology, at least in coderanch.

[Pietro Vigone]

What is a component, and what is not?

[Rufus BugleWeed]

I suppose at a low level a component, in java terms, is something that implements an interface.
If some code is defined in terms of interfaces one component can be replaced with another. This is where the plugs on the component icon came from. One can unplug one component and plug in a new one.
If the desgin specifies a unigue class, only that class can be plugged in. Therefore it is not a component architechture.
In a given market, a televison is a component in a viewing system. It plug into a signal source and a power source. Plugging into it, is a user with certain language and mechanical needs. Mechanical needs like an on-off switch.

[Paul Newton]

Component diagrams and class diagrams are related, but different artifacts.
First, what is a component? This is an endless question. The UML spec defines it as "...a modular, deployable and replaceable part of a system that encapsulates implementation and exposes a set of interfaces". Okay, maybe not much clearer. But the intention is that a component is a packaging of classes - not usually a single class in itself (although this is possible). A component encapsulates some cohesive piece of functionality. In this way, a component is made up of ('specified' in UML terms) by one or more classifiers (e.g. classes).
To take a crude example, a component might be 'Customer Billing Component' that calculates the movements on a customer account. This component is made up of several classes (e.g. 'Customer', 'Money', 'Account', 'Order' etc).
A component model shows the dependencies between components (ReportPrinter uses CustomerBilling). It shows which classes are used to define a component. It also shows the '...artifacts that implement them' e.g. CustomerBilling is contained inside 'billing.jar'.
You can take UML as far as you like and use adornments to stereotype the dependencies ('reside', 'implement' etc). Although I think the goal of the SUN exam (or at least, judging by the Cade book) is just to understand the purpose of a Component diagram in the development process.
regards,
paul.
[ October 18, 2002: Message edited by: Paul Newton ]

[Pietro Vigone]

Thanks for your replies, but I am still wondering. I know the UML definition of a component, but this does not help much.
The exam is not truly agnostic about the methodology: it requires a methodology that uses Component Diagrams, while for example these diagrams seem not to be required in the RUP design phase.
According to Paul: "a component encapsulates some cohesive piece of functionality". This is similar to my hypothesis that a (Cade, Roberts) "component" is similar to a <<control>> class, whereas the classes to be drawn in the Class Diagram are the <<entity>> classes.
Paul, I don't understand your statement "A component model... shows which classes are used to define a component".
Also it lets me think when you say "the goal of the SUN exam... is just to understand the purpose of a Component diagram in the development process". Really? To understand, or to guess?
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.
Thanks everybody
Pietro

[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.
regards,
paul.

[Brian Smith]

can you please explain what is a sterotype class?
thanks.

[noel angel]

Hi Folks,
There are software and physical components.
A Component diagram is a representation of the physical software artifacts and how they are related. ( at a lower level than package diagrams!)
For example in C++ a physical component might be a header file.
In Java it might be a .class file which contains one or more classes
In windows it may be a .exe file
You can build one component diagram to represent each package or whatever you would like. UML is flexible that way...
In Rational Rose, it is necessary to provide a component diagram to do automatic code generation and reverse engineering code produces component diagrams.

[Nalla Senthilnathan]

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.
Thanks everybody
Pietro[/QB]

Hi Pietro,
I have a sample component diagram for an auction system example:
http://www.mycgiserver.com/~nsenthil/articles/auctiondbdesign.html
and subsystem-wise J2EE view of the component diagram like:
http://www.mycgiserver.com/~nsenthil/articles/auctionRegApp.html
This looks pretty close to the component diagram in Cade and Robert's book.
Nalla
[ August 02, 2003: Message edited by: Nalla Senthilnathan ]

[dbala subramaniam]

Hi All
I try define Component -Componenet is a set of classess which can be serialized as well as deserialized that's what Sun say
with regards
bala

[dbala subramaniam]

Hi All
After Sterotypes then I have one question which posted under Sterotypes heading , but I cannot clear since nobody replied
basically our diagram's UML as well as complaint.
But Class Diagram-as per UML
Sterotypes--Any GUI<<boundary>>
Servlet, ServiceLocator<<control>>
Any Business object(it can be session or entity bean)<<entity>>
so your classdiagram need to provide only these 3 sterotypes for UML complaince.
But I found many class diagrams- even Mark Cade sterotypes
<<StatelssBean>>etc,
so please any body clarify
also association I found <<creates>>, basically association must be 1 to 1 or 1 to many kind of relationship, but is it correct to put <<creates>>
please clarify
advanced thanks
with regards
bala

[Manjunath Subramanian]

Beautiful Explanation Paul. Thanks!

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.
regards,
paul.