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­e­gories: be­hav­ioral 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­vid­ual system com­po­nents through a static con­cep­tu­al vi­su­al­iza­tion. Both logical and physical modelling aspects can be included.

In UML, com­po­nents are modular parts of a system that are in­de­pen­dent and can be replaced with equiv­a­lent com­po­nents. They are self-contained and en­cap­su­late struc­tures of any com­plex­i­ty. The en­cap­su­lat­ed elements interact with other com­po­nents ex­clu­sive­ly via in­ter­faces. In addition to having their own in­ter­faces, com­po­nents can also use the in­ter­faces of other com­po­nents, such as to access their functions and services. The in­ter­faces also document the re­la­tion­ships and de­pen­den­cies that exist in a software ar­chi­tec­ture in a component diagram.

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

The notion of com­po­nents has a broad de­f­i­n­i­tion in UML. Com­po­nents 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­po­nents (e.g. for database access), there are also spe­cial­ized com­po­nents that can relate to areas such as business and business processes. These re­la­tion­ships can be more complex, so UML provides the stereo­type <<subsystem>> to describe them.

Since component diagrams are modelled with an im­ple­men­ta­tion-oriented design, there are special im­ple­men­ta­tion com­po­nents that focus on in­di­vid­ual im­ple­men­ta­tion aspects. These com­po­nents can be used, for example, to implement other com­po­nents such as ex­e­cuta­bles (i.e. ex­e­cutable files with the extension *.exe) in Windows.

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

A component diagram provides an overview of a system from a bird’s eye per­spec­tive which documents the or­ga­ni­za­tion of system com­po­nents and their in­ter­re­la­tion­ships and de­pen­den­cies. Component diagrams provide an im­ple­men­ta­tion-oriented view, thus giving the developer insight into whether a system functions as a whole and fulfills its tasks and ob­jec­tives.

The main ob­jec­tives 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­sis­tence 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­chang­ing in­for­ma­tion with the customer since they help reduce the com­plex­i­ty, thus making projects and plans easier to un­der­stand and to com­mu­ni­cate 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­po­nents.

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­po­nents. 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­po­nents and ensuring they interact ef­fi­cient­ly.

Component-based software systems help save time and money in the planning and im­ple­men­ta­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­cial­ly when im­ple­ment­ing more complex projects. You can also com­pen­sate for a lack of in-house ex­pe­ri­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­ut­es 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.