What is the difference in UML terms between a package and a component?

[Andrew Watters]

Firstly, apologies for the long post and thank you if you have the time to
read it. I would appreciate any input.

What I'm trying to do.
I'm drawing an architectural view that shows the key packages/components,
their relationships and the layer they belong to. If it helps: the
packages/components are things like Member, Commodity, Services; the layers
are Interface, Application, Domain, Infastructure.

Why I'm confused.
I started drawing both a package diagram and a component diagram to see how
things developed (using Together) and then realised that I can put
susbsytems on the component diagram. I think a subsytem is a stereo type of
a package (p482 of 'Agile Software Development' seems to agree with this
although the notion of this indicating behaviour has only increased my
confusion).
Also, I've gotten used to thinking of packages in java terms so that
com.xxx.member is a package. In this case the package is also a component,
by that I mean that I can build a member.jar. Some of my components contain
multiple java package trees. Having reverse engineered the classes using
Together I find that packages are shown inside each other. For example, if I
have package x and x.y, x.y is shown inside x. I think this means that
package x.y can see package x (and vica-versa) and additionally x
effectively hides x.y to anything outside x.

So various questions.
What is the diference between a package and a component? And a subsystem?
Is my package understanding correct - do sub-packages express information
about scope as I have described? And if this is so why does Together assume
x.y is inside x? Should I be renaming all my java packages?
For my view should I be using a package or component diagram?

Thanks
Andrew

[jason]

You could be forgiven for being confused. As a rule, I wouldn't take
what my modeling tool allows me to do as a definitive guide to what's
allowed in UML, but in this case it's perhaps sensible.

I have a fairly black-and-white definition of package vs. component. A
Package to me is a namespace - an organising principle that allows me
to break my models (and my code) up into manageable chunks. A
component to me is a unit of reuse. According to OO design principles,
the unit of reuse is the unit of release, so a component is a unit
that can be released (and therefore reused). I could release a set of
individual .class files or package them up in a .jar, .war or .ear
file. In all these cases, a .class, .jar, .war and .ear file could be
looked upon as a component (and not a package). I can package classes
in the same logical namespace into different .jar files and release
(and therefore reuse) them separately. It doesn't help that Java has
this concept of "packaging up" files to mean "putting them into the
same archive" - kind of a mixed metaphor, which is where I suspect the
confusion comes from.

You could draw .jar components inside UML packages to represent how
they're deployed into folders (file system namespaces), or draw .jar
components inside .war components, or a susbsystem package inside a
.jar file. They would all be valid as far as I'm concerned :-)

Jason Gorman
http://www.parlezuml.com

Post by Andrew Watters
Firstly, apologies for the long post and thank you if you have the time to
read it. I would appreciate any input.
What I'm trying to do.
I'm drawing an architectural view that shows the key packages/components,
their relationships and the layer they belong to. If it helps: the
packages/components are things like Member, Commodity, Services; the layers
are Interface, Application, Domain, Infastructure.
Why I'm confused.
I started drawing both a package diagram and a component diagram to see how
things developed (using Together) and then realised that I can put
susbsytems on the component diagram. I think a subsytem is a stereo type of
a package (p482 of 'Agile Software Development' seems to agree with this
although the notion of this indicating behaviour has only increased my
confusion).
Also, I've gotten used to thinking of packages in java terms so that
com.xxx.member is a package. In this case the package is also a component,
by that I mean that I can build a member.jar. Some of my components contain
multiple java package trees. Having reverse engineered the classes using
Together I find that packages are shown inside each other. For example, if I
have package x and x.y, x.y is shown inside x. I think this means that
package x.y can see package x (and vica-versa) and additionally x
effectively hides x.y to anything outside x.
So various questions.
What is the diference between a package and a component? And a subsystem?
Is my package understanding correct - do sub-packages express information
about scope as I have described? And if this is so why does Together assume
x.y is inside x? Should I be renaming all my java packages?
For my view should I be using a package or component diagram?
Thanks
Andrew

[H. S. Lahman]

Responding to Watters...

Post by Andrew Watters
So various questions.
What is the diference between a package and a component? And a subsystem?
Is my package understanding correct - do sub-packages express information
about scope as I have described? And if this is so why does Together assume
x.y is inside x? Should I be renaming all my java packages?
For my view should I be using a package or component diagram?

In UML a Package is primarily a configuration management artifact. It
exists to collect _model elements_ and does not necessarily have
semantic value. If you want to group all the model elements in, say, a
particular version of the software, one would use a package.

A Subsystem is a no longer a stereotype of Package; it is now derived
from Component. A subsystem represents a logical subdivision of the
application in the traditional software sense. It can have an
implementation (classes and/or other subsystems) and interfaces.
Subsystems are still identified in a Package Diagram.

A component is a replaceable module in the application (i.e., it is
implemented software encapsulated by an interface). It also represents
a logical unit of the application. However, while a subsystem is a
relatively large-scale module, a component can be at any scale from
subsystems to Java beans. So components can appear in a Package Diagram
(subsystems), a Class Diagram (classes), or a Component Diagram
(components like COM widgets or JBs).

*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
***@pathfindermda.com
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
blog (under constr): http://pathfinderpeople.blogs.com/hslahman
(888)-OOA-PATH

[Cristiano Sadun]

Post by Andrew Watters
What is the diference between a package and a component? And a subsystem?

A package is a logical subdivision of the solution space. A component is a
deployable artifact for which:

- one package can be spread over many components
- many packages can be contained in one component
- of course, there's the simple case in which one package <-> one
component, 1 to 1

Java packages aren't necessarily UML packages - they're actually used also
for physical mapping to directories etc. Of course they *can* be used in
the same way - it's just not a given.

An UML package represent a logical subdivision of the solution space: for
example, a subsystem, or a group of subsystems, etc. It's a way to identify
the important entities at a certain level of abstractions (for example
"rules engine", "activity monitor", "communication bus" etc).

A component on the other side is a physically deployable entity - a
concrete deliverable that can be run on a node (typically, a host).

It's just an additional level of decomposition that is orthogonal to the
"packages" one. A good example is client/server communication. Since u're
into java, I'll use RMI as an example (think EJBs if RMI is too lowlevel):
you normally have a package which realizes a remotely invocable operation.

However, for that package, you'll likely have two components: the server
part and the client distributable part. The server component is the one
that'll be deployed on the server, the client component will be given to
the clients. Note that they can well contain some classes in common - in
that case, the logical package is not only spread over two components, but
the spreading isn't even disjoint.

[Andrew Watters]

Thank you everyone very much for your replies. This is starting to make
sense, famous last words!

So a package is simply a grouping of model elements. A component is
logical entity in a system with a specified interface. And a subsystem
is a bigger/more general abstraction of a component.

For the view I'm looking to create it seems like I could happily use
packages or components depending on exactly what it is I want to
communicate. It's a shame that my modeling tool, Together, doesn't allow
me to draw packages inside packages. Nor does it allow me to draw
packages and components on the same diagram.

Thanks again for the replies.