UML basics: component Diagram

UML basics: component Diagram

Original article: http://www.ibm.com/developerworks/rational/library/dec04/bell/index.html

Purpose
The main purpose of a component diagram is to display the structural relationship between system components. In UML 1.1, a component represents an implementation project, such as a file and a runableProgram. Unfortunately, this is in conflict with the term component, which is more common and refers to something like a COM component. With the passage of time and the continuous release of UML, the UML components have lost most of their original meaning. UML 2 formally changes the essential meaning of the component concept. In UML 2, components are considered to be independent and provide one or more interfaces in the encapsulation unit of a system or subsystem. While the UML 2 specification does not strictly declare it, components are larger design units that present things, which are generally implemented using replaceable components. However, unlike in UML 1.x, components must have strict logic and are constructed during design. The main idea is that you can easily reuse and/or replace a different component implementation in your design, because a component encapsulates behavior and implements a specific interface. 1

In component-based development (CBD), component diagrams provide architects with a natural form of starting to model the solution. The component diagram allows an architect to verify that the required functions of the system are implemented by the component, ensuring that the final system will be accepted.

In addition, component diagrams are useful communication tools for different groups. The diagram can be presented to key project initiators and implementers. Generally, when a component diagram connects the implementers of the system, the component diagram can usually make the project sponsor feel relaxed, because the diagram shows an early understanding of the entire system to be established.

The producer finds that the component diagram is useful because the component diagram provides them with a high-level architecture view of the system to be created, which will help developers start to build implementation roadmap, and decide on task allocation and/or improvement of demand skills. System Administrators can find component diagrams useful because they can get an early view of logical software components that will run on their systems. Although the system administrator will not be able to identify physical devices or physical executable programs from the graph, they still welcome the component diagram, because it provides information about components and their relationships earlier (this allows the system administrator to easily plan subsequent work ).

Symbol
Currently, the component diagram Symbol Set makes it one of the most easily drawn UML diagrams. Figure 1 shows a simple component diagram using the former UML 1.4 symbol. This example shows the relationship between the two components: an order system component using the inventory system component. As you can see, in UML 1.4, there is a large square with two protruding small blocks on the left to represent components.

Figure 1: This simple component diagram uses the UML 1.4 symbol to display the General dependency of order system.

The above UML 1.4 symbols are still supported in UML 2. However, the UML 1.4 symbolic set cannot be well adjusted in a large system. The reason for this is as follows:ArticleThe rest of the diagram will see the same, and UML 2 significantly enhances the symbolic set of the component diagram. While maintaining its ease of understanding, the UML 2 symbol can be better tuned and has more information.

Let's build a component diagram step by step according to the UML 2 Specification.

Basic
Now, drawing a component in UML 2 is similar to drawing a class on a class diagram. In fact, in UML 2, a component is only a special version of the class concept. This means that the symbol rules applicable to classifier classes are also applicable to component classifiers. (If you have read and understood my previous article about the general structure chart and class diagram details [http: // www. examples ).

In UML 2, a component is drawn as a vertical rectangle stacked with small pieces. In UML 2, a high-level abstract view of a component can be modeled using a rectangle, including the component name and the text and/or icons of the component prototype. The text of the component prototype is "«component»", and the component prototype icon is a large rectangle with two protruding small rectangles on the left (the symbol element of the component in UML 1.4 ). Figure 2 shows that the component can be represented by three different methods in the UML 2 Specification.

Figure 2: Different Methods for drawing component name Areas

When you draw a component in a diagram, it is important that you always include the component prototype text (the component in double angle brackets, as shown in 2) and/or icons. Why? In UML, a rectangle without any prototype classifier is interpreted as a Class component. The component prototype and/or icon are used to differentiate the rectangles used as component elements.

Provide/require interface modeling for components
The order component shown in Figure 2 represents all valid symbolic elements. However, a typical component diagram contains more information. An additional area can be attached to a component element under the name area. As mentioned above, a component is an independent unit that provides one or more public interfaces. The provided interface represents the formal contract of the service provided by the component to its users/customers. Figure 3 shows that the order component has a second partition to indicate the interfaces provided and required by the order component.

Figure 3: The additional area shows the interfaces provided and required by the order component.

In the order component example in figure 3, the component provides interfaces named orderentry and accountpayable. In addition, the component also requires another component to provide the person interface.

 

Other modeling methods for component interfaces

UML 2 also introduces another method to display interfaces provided and required by components. This method is to create a large rectangle with the component name in it and place it outside the rectangle in the interface symbol in the UML 2 Specification. The second method is illustrated in figure 4.

Figure 4: An Alternative method (compared to figure 3): Use the interface symbol to display the interface that the component provides/requires

In the second method, a complete circular interface symbol at the end represents the interface provided by the component-"Lollipop" is the stenographer of the interface classifier to implement the relational symbols. The interface (also called socket) symbol with only half a circle at the end represents the interface required by the component (in either case, the interface name is placed near the interface symbol itself ). Even if figure 4 looks quite different from figure 3, both charts provide the same information-for example, the Order component provides two interfaces: orderentry and accountpayable, and the order componentRequirementsPerson interface.

 

Modeling of component relationships

When expressing the relationship between a component and other components, the lollipop and outlet symbol must also contain an dependency arrow (as shown in the class diagram ). In the component diagram with a lollipop and a socket, note that the dependency arrow is drawn from a strong (required) outlet and Its arrow points to the supplier's lollipop, as shown in Figure 5.

 
Figure 5: How order system components depend on other components

Figure 5 shows that the order system component depends on the customer resource library and the inventory system component. Note that the interface names customerlookup and productaccessor are rewritten in Figure 5. In this example, this may seem unnecessary, but the symbol does allow different interfaces (and different names) in each component dependent on implementation differences (for example, A component provides a small required sub-class interface ).

 

Subsystem

In UML 2, a subsystem classifier is a special version of a component classifier. Because of this, the subsystem symbol elements inherit all the Component symbol set rules like the Component symbol elements. The only difference is that a sub-system symbol element replaces component with the subsystem keyword, as shown in figure 6.

Figure 6: An Example of subsystem Elements

The UML 2 specification is vague about how to differentiate subsystems and components. From the modeling point of view, the specification does not regard components as different from subsystems. Compared with UML 1.x, the ambiguity of the UML 2 model is new. But there is a reason. In UML 1. in section X, a sub-system is considered as a software package, and the software package symbol is confusing to many UML practitioners. Therefore, in UML 2, subsystems are used as special components, because this is the most UML 1. X users know how it works. This change does introduce the blur into the diagram, but this blur is more of a realistic reflection against errors in the UML 2 Specification.

At this point, you may be scratching your head and wondering when to use component elements and when to use subsystem elements. Quite frankly speaking, I don't have a direct answer for you. I can tell you that in the UML 2 specification, when to use components or subsystems depends on the modeler's methodology. I personally like this answer because it helps ensure that UML and methodology are mutually independent, which will help keep it universally usable in software development.

 

Beyond basic

A component diagram is one of the easier-to-understand diagrams, so there is not much content beyond the basics. However, you may think it is a little difficult.

Display the internal structure of the component

Sometimes it makes sense to display the internal structure of a component. In my previous article on class diagrams, I showed how to model the internal structure of the class. Here, when it is composed of other components, I will focus on how to model the internal structure of the component.
To display the internal structure of a component, you only need to draw the component larger than usual and place the internal part in the name area. Figure 7 shows the internal structure of the store component.

 
As shown in figure 7, the store component provides the orderentry interface and requires the account interface. The store component consists of the Order, customer, and product components. Note that the orderentry and account interface symbols of store have a square on the edge of the component. This square is called a port. Simply put, a port provides a way to display the modeling componentProvision/requirementsHow the interface is associated with the part in it. By using the port, we can separate the internal parts of the store component from the external instance. In Figure 7, the orderentry port represents the orderentry interface of the order component. At the same time, the account interface required by the Internal Customer component is allocated to the necessary account port of the store component. By connecting to the account port, the internal parts of the store component (such as the customer component) can have local characteristics of unknown external entities representing the port interface. The required account interface is implemented by the external component of the store group. 5

In Figure 7, you may also notice the differences between the internal connections between internal components and those shown in Figure 5. This is because the profiling of the internal structure is a collaboration graph nested in the classifier (in our example, a component), because a collaboration graph shows the entity or role in the classifier. The relationship between internal components is represented by a composite connector called UML. Bind a composite connector to a componentProvideInterface to another component'sRequiredInterface. The composite connector is represented by a tightly connected lollipop and socket symbol. Draw these combinations of connectors in this way to make lollipops and sockets easy to understand.

 

In addition, this PPT is good: UML-based component Modeling