UML series learning-component Diagram

A component diagram is used to reflect the physical structure of the Code. From the component diagram, you can understand the compiler and runtime dependencies between software components (such as source code files or dynamic link libraries. You can use a component diagram to divide the system into cohesion components and display the code structure.

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 runable program. 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 developer 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 a road map for implementation, 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 that, as we will see in the rest of this article, UML 2 significantly enhances the symbolic set of component diagrams. 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 component prototype text 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. 2

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. 3

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 letter itself ). Even though 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, the order component also requires the person 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.

Figure 7: the internal structure of this component is composed of other components.

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 method that shows how the interfaces provided/required by the modeling component are associated with the parts in it. 4. 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 component. 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. A composite connector binds the interface provided by one component to the required interface of another component. 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.

Conclusion

A component diagram is often a very important diagram built by an architect at the early stage of the project. However, the usefulness of component graphs spans the life of the system. Component diagrams are priceless because they model and document a system architecture. Because component diagrams document the system architecture, developers and system administrators may find that key products of this job help them understand the system.

The component diagram is also considered as the input of the software system configuration diagram, which will be the topic of the article later in this series.

Footer

1 is called the actual project of the component in uml1.x and is called the product in UML 2. A product is a physical unit, such as a file, a executable program, a script, a database, and so on. Only one product depends on the actual node, and the class and component do not have a "location ". However, a product may display components and other classifiers (such as classes ). A single component may be displayed through multiple products, which may be on the same or different nodes. Therefore, a single component can be indirectly implemented on multiple nodes.

2. Even if components are independent units, they may still depend on the services provided by other components. Because of this, it is useful to document the required interfaces of a component.

Figure 3 does not show the complete Context of the order component. In a real model, the orderentry, accountpayable, and person interfaces are displayed in the system model.

4. In fact, the port applies to any type of classifier (for example, a class or another Classifier in your model ). To make this article concise, I mentioned ports in the component classifier and their usage.

5. Generally, when you draw a dependency between a port and an interface, the interface of the dependent Party (requirement) will process all the processing logic during the running time. However, this is not a hard rule-for the surrounding components (for example, the store component in our example), use their own process logic, rather than entrusting a process to a dependent interface, it is completely acceptable.

References

For more information, see the original article on the developerworks global site.

Http://www.ibm.com/developerworks/rational/library/dec04/bell/index.html
　

About the author
Donald bell is an IT expert in IBM Global Services, where he and IBM clients work together to design and develop J2EE based on software solutions.

How to Create a UML component Diagram

1. on the "file" menu, point to "new" and "software", and then click "UML Model diagram ".

2. In the tree view? (Tree View: shows a hierarchy in the UML Navigator window. Each UML element or view (Chart) is represented by an icon. The UML template automatically creates a tree view for the model .) Right-click to include the component diagram in it? (Component diagram: displays the implementation diagram of the code structure. From the component diagram, you can understand the compiler and runtime dependencies between software components (such as source code files or dynamic link libraries .) Package or subsystem, and then click "component diagram" on the "new" menu ".

A blank page is displayed, and the "UML component" mold is displayed at the top. The workspace displays "components" as watermarks ". A chart icon is added to the Tree View.

Annotation ?? If you cannot see the tree view, point to "View" in the "UML" menu and click "Model Resource Manager ".

3. Drag the component shape to the drawing page for each component to be represented.

4. Drag the interface shape to the drawing page as needed and stick the endpoint without circles to the component shape.

Add Interfaces to classes, components, or other elements

In a static structure? (Static structure diagram: a chart that displays the static structure of a model, that is, the existing elements (such as classes and types), the internal structure of these elements, and their relationships .) , Components? (Component: In the component diagram and deployment diagram, the component refers to the allocable Implementation Unit in the system. For example, a component can represent a physical module of code (source, binary, or executable file) or a business document in a human system .) Or deployment? (Deployment diagram: displays the implementation diagram of the runtime system structure. From the deployment diagram, you can understand the physical relationship between software and hardware components and the component distribution of processing nodes .) In the figure, drag the sugar-shaped "interface" shape to the drawing page.

Will the endpoint without a circle be attached to the class? (Class: an object set with similar structures, behaviors, and relationships in a static structure diagram. The class is declared in the class (static structure) diagram, representing the concept of the modeled system .) Connection Points on components or other elements.
Double-click the "interface" shape to add names, operations, and other property values.
Prompt

You can also use a rectangle "interface" shape similar to the class to represent the interface. This shape can be used when you want to display a group of interface operations.

To change the shape type of the displayed interface, right-click the "interface" shape and click "show as class interface" or "show as Sugar interface ".

5. Use the "dependency" shape to represent the relationship between components or interfaces of one component and other components.

The dependency between UML elements.

Drag the dependency shape from the "UML static structure", "UML deployment", or "UML component" mold to the drawing page, and place it next to the element you want to associate.

Attaches the endpoint with an arrow to the connection point of another element on which the element depends. Attaches an endpoint without arrows to a connection point on an element dependent on another element.

Double-click the dependency to add the name and constructor? (Constructor: Expression of difference in usage. Constructor is a subclass of an existing element. It has the same characteristics and relationships with this element, but its purpose and possible additional constraints are different .) And other attributes.
Prompt

If you want to indicate a trail? (TRACE: A trace is a dependency that indicates the historical relationship between two elements (these two elements represent the same concept of different semantic levels or different perspectives .) , Optimization? (Optimization: A dependency that indicates the historical or derivative relationship between two elements with ing relationships. You can add the ing description to the dependency in the annotation .) , Use? (Usage: A dependency that indicates that one element needs the presence of another element to correctly implement or execute the function .) Or bind? (Binding: A dependency that indicates the binding relationship between a parameterized class (Template) parameter and the actual value to create a binding (that is, a non-parameterized) element .) Dependency. You can use the trace, precision, use, or bind shape in the "UML static structure" mold.

6. Double-click any shape to open the "UML attributes" dialog box, where you can add names, properties, operations, and other properties.

7. Save the chart.