The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
On Scott Ambler's discussion of Component Diagrams. The diagrams "use the lollipop symbol to indicate an implemented interface"
You can take that literally as a Java interface, or the call between one component and another might involve RMI, EJB, sockets, SOAP or whatever you use. See the Deployment Diagram.
So that means the implementations of "components" and how they expose their interfaces to the world could be very different. Sometimes a component is a single class, though it would be a rare class that is worthy of being called a component. In a monolithic system a component might be a package or a hierarchy of packages. If you want to deploy components separately, perhaps share them with your friends, maybe they ought to be packaged up in jars. If you want to let anyone on the internet use them, like the Google maps APIs, they'll need remote access.
Did any of that fit what you expected? What kind of components are you working on? [ September 13, 2006: Message edited by: Stan James ]
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Jean louc Rippon
Joined: May 24, 2006
Thanks for your replay In fact I work with software component in UML 2.0, do you have somme reference, I need please references which talk only about component in UML, not UML in general.
Joined: Jan 29, 2003
The Component Diagram page I linked before goes on to discuss implementation options. It's really quite good.
I don't think you'll find a book or web site about "UML Components And Nothing Else" (though you might find such a store on Rt 40 in New Jersey). If you follow the second link I gave above you'll find components on the deployment diagram. In a real system you'll find class diagrams and interaction diagrams that describe what's inside a component. My point is that trying to look only at components won't get you very far. The model underlying a stack of UML diagrams is very rich and each diagram is just one way of peeking into it.
So I guess I'm curious why you're so focused on components? Homework?