Do Component diagrams refer to physical components only?

Question

Is it true that a good test for whether something qualifies as a "component" in a UML component diagram, is that it's physically isolated?

Most definitions I've found (Wikipedia, TutorialsPoints,..) refer to the components as "files, libraries, executables, etc."

However, some illustrations (see http://agilemodeling.com/artifacts/componentDiagram.htm ) seem to model classes as components (eg "Student," "Seminar") which at first glance might give the indication that these are just some important classes in the application. However, reading further down under the heading "Creating Component Diagrams", it makes a lot of references to "network traffic" ("reduce the potential network traffic"); the implication being that the components as modeled are distinct processes or executables that communicate via network ports. This seems to imply that individual classes whose instances are in the same JVM (and I might add the same physical .jar) should be in the same component in the UML Component diagram. Is this always true? If not when are the cases where object instances in the same jar and same JVM would be seen as different components in this diagram?

Answer 1

No, a UML Component is not limited to physical file or something like that.

Physical might not even be a good term to talk about files on a system as you can't really touch a file. It's all just bits and bytes.

UML 2.5 defines a component as

A Component represents a modular part of a system that encapsulates its contents and whose manifestation is replaceable within its environment.

Furthermore it says

A Component is a self-contained unit that encapsulates the state and behavior of a number of Classifiers. A Component specifies a formal contract of the services that it provides to its clients and those that it requires from other Components or services in the system in terms of its provided and required Interfaces.

A Component is a substitutable unit that can be replaced at design time or run-time by a Component that offers equivalent functionality based on compatibility of its Interfaces. As long as the environment is fully compatible with the provided and required Interfaces of a Component, it will be able to interact with this environment. Similarly, a system can be extended by adding new Component types that add new functionality. Larger pieces of a system's functionality may be assembled by reusing Components as parts in an encompassing Component or assembly of Components, and wiring them together.

So a software application such as Skype or Chrome can be modeled as a component, but also the internal parts such as the chat engine , or the HTML renderer can be considered components.

Often the component structure is actually mirrored in the physical implementation; each component of a piece of software could be compiled into a single dll

Answer 2

In addition to excellent Geert's answer, it is often a good idea to encapsulate what normally seems like a class with all things related to it as a component when you don't necessarily always need it.

Imagine an application that enables managing company fleet. Typically it will come with support for cars. Yet you may want to be able to add additional components, to be able to handle planes, ships or bikes. You may as well not need cars in such cases. Each of those things will become components, even though you can model it simply as subclasses of the only class that resides in the system core called Vehicle. For instance you may have different elements related to those bikes, that are not enclosed in the class itself. Consider how different will be screens, maintenance models, everything related to different methods that can be applied on the sub-class level only.

Other example of component in such systems can be Drivers. This is no longer a sub-class of Vehicle but some separate class that interacts with Vehicles. Again, depending on the situation you might be interested only in Cars that are in the company or have them linked to Drivers who are assigned to them or even allowed to use them. Thus you come up with an entirely different set of dependencies, screens, methods etc. which are not just related to the Driver itself, but it's interaction with the surroundings.

In general while this is not limited to that, Component is a good way of thinking how can you split your system into smaller parts that can be detached or attached to the system adding or removing accordingly part of its functionality.