Introduction
Since I work at the Kiel University, I teach UML to the students in the 3rd and 4th semester of computer science. At the latest when they need to work out a UML component diagram and a corresponding deployment diagram, the following questions arise:
What is a UML software component? What is the difference between a class, a package, and a component?
For this reason, we address these questions in this post. First, we look at some definitions to distinguish a component from other UML entites.
Component vs. (Class, Package, and Library)
Let’s start with the most important message of this post: Consider a component as a composition of classes, packages, and sub components that is accessible only by other components and only via interfaces.
TODO
Communication within and between components
TODO UML notation
Example Component Diagram
When creating a component diagram, remember that it must depict additional semantics compared to all other diagram types such as class and package diagrams. Otherwise a component diagram is useless and can be thrown away.
TODO diagram with components (android, server, db) and sub components: A3, User, Role, ORM, …
Example Component Representations in Java
Since the Java programming language does not provide the abstraction of components, we need to represent it with the means Java offers us.
Hence, we discuss the three following representations of a component possible in the Java universe.
- The class-based approach
- The package-based approach
- The library-based approach
Due to Java’s direct support for interfaces, we represent a component’s interface by one or more Java interfaces.
The class-based approach
In this approach, we represent a component by a class that implements all interfaces the corresponding component should provide.
The package-based approach
TODO
The library-based approach
TODO