UML component diagrams: efficient modelling systems with software modules

The Unified Modeling Language (UML) is a commonly accepted ISO standard for de­vel­op­ing software and more complex system ar­chi­tec­tures. This modelling language uses different types of diagrams for planning and de­vel­op­ment processes in object-oriented pro­gram­ming.

The latest version (UML 2.5) has 14 different diagram types which are roughly divided into two cat­egor­ies: be­ha­vi­our­al and struc­tur­al diagrams. The latter category includes component diagrams. In the following, we will explain what a component diagram is and explain how to draw a component diagram through a concrete example. You will also learn what UML component diagrams are used for.

UML component diagrams show the re­la­tion­ships between in­di­vidu­al system com­pon­ents through a static con­cep­tu­al visu­al­isa­tion. Both logical and physical modelling aspects can be included.

In UML, com­pon­ents are modular parts of a system that are in­de­pend­ent and can be replaced with equi­val­ent com­pon­ents. They are self-contained and en­cap­su­late struc­tures of any com­plex­ity. The en­cap­su­lated elements interact with other com­pon­ents ex­clus­ively via in­ter­faces. In addition to having their own in­ter­faces, com­pon­ents can also use the in­ter­faces of other com­pon­ents, such as to access their functions and services. The in­ter­faces also document the re­la­tion­ships and de­pend­en­cies that exist in a software ar­chi­tec­ture in a component diagram.

Com­pon­ents usually en­cap­su­late classes and are thus also described as a sub-form or spe­cial­isa­tion of a class. Similar to a class, they have a composite structure and can be more precisely defined using at­trib­utes, methods, op­er­a­tions, and so on. Com­pon­ents can be a col­lec­tion of classes and can, for example, be im­ple­men­ted at runtime by one or more classes. Although com­pon­ents are often equated with classes, there are some dif­fer­ences. While com­pon­ents generally require in­ter­faces for in­ter­ac­tion, classes can also access a method directly.

The notion of com­pon­ents has a broad defin­i­tion in UML. Com­pon­ents include various parts of the system, such as databases, packages, files, and libraries (e.g. dynamic-link libraries or DLLs). In addition to technical com­pon­ents (e.g. for database access), there are also spe­cial­ised com­pon­ents that can relate to areas such as business and business processes. These re­la­tion­ships can be more complex, so UML provides the ste­reo­type <<subsystem>> to describe them.

Since component diagrams are modelled with an im­ple­ment­a­tion-oriented design, there are special im­ple­ment­a­tion com­pon­ents that focus on in­di­vidu­al im­ple­ment­a­tion aspects. These com­pon­ents can be used, for example, to implement other com­pon­ents such as ex­ecut­ables (i.e. ex­ecut­able files with the extension *.exe) in Windows.

Multiple com­pon­ents come together to form a more complex system ar­chi­tec­ture. Com­pon­ents can also contain other com­pon­ents and build on each other, so a component can require another component (i.e. a de­pend­ency re­la­tion­ship). In addition, software modules can refer to different phases of execution. Some com­pon­ents are primarily used for planning and de­vel­op­ment in the design stage, while other com­pon­ents are used at the software’s runtime. These are also referred to as design and runtime com­pon­ents.

A component diagram provides an overview of a system from a bird’s eye per­spect­ive which documents the or­gan­isa­tion of system com­pon­ents and their in­ter­re­la­tion­ships and de­pend­en­cies. Component diagrams provide an im­ple­ment­a­tion-oriented view, thus giving the developer insight into whether a system functions as a whole and fulfils its tasks and ob­ject­ives.

The main ob­ject­ives and uses of this diagram type are to model component-based software systems, define software ar­chi­tec­ture and divide systems into sub­sys­tems (e.g. graphical user in­ter­faces (GUI), business fields, and per­sist­ence in re­la­tion­al databases). In addition, these sub­sys­tems and their in­ter­faces are assigned specific tasks and functions inside a system.

In the business world, UML component diagrams are an important means of ex­chan­ging in­form­a­tion with the customer since they help reduce the com­plex­ity, thus making projects and plans easier to un­der­stand and to com­mu­nic­ate to others. Component diagrams also support and simplify software de­vel­op­ment ad­min­is­tra­tion, such as by combining classes into man­age­able com­pon­ents.

The modular approach of this diagram type also helps to make projects more cost-effective and efficient since software systems can be modelled as struc­tured func­tion­al re­la­tion­ships from reusable com­pon­ents. For example, component diagrams clearly visualize which building blocks can be used multiple times and where in the ar­chi­tec­ture. System designs can be optimally oriented towards reusing com­pon­ents and ensuring they interact ef­fi­ciently.

Component-based software systems help save time and money in the planning and im­ple­ment­a­tion phase of a system since existing elements can be reused. In addition, using tried and tested software modules reduces potential risks and sources of error, es­pe­cially when im­ple­ment­ing more complex projects. You can also com­pensate for a lack of in-house ex­per­i­ence and knowledge since third-party modules can be purchased to implement systems.

You could use these basic elements to draw a simple component diagram using the free open-source software JGraph.

The level of detail in a component diagram can be further enhanced by defining the elements involved even more precisely using the UML standard. For example, a class can be defined more precisely using at­trib­utes and op­er­a­tions. The options for more precisely defining classes are described in detail in our article on class diagrams. Ad­di­tion­al drafting and modelling options include use case diagrams and state diagrams.