Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

Detailed introduction of UML component diagram

2025-01-19 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Development >

Share

Shulou(Shulou.com)06/03 Report--

This article mainly explains the "detailed introduction of UML component diagram", the content of the article is simple and clear, easy to learn and understand, the following please follow the editor's ideas slowly in depth, together to study and learn "detailed introduction of UML component diagram"!

Modeling of component relationship

When representing the relationship between a component and other components, lollipops and socket symbols must also include a dependency arrow (as used in the class diagram). On the UML assembly diagram with lollipops and sockets, note that the dependent arrow is drawn from the strong (required) socket, and its arrow points to the supplier's lollipop, as shown in figure 5.

Figure 5: UML component diagram showing how Order system components depend on other components

Figure 5 shows that the Order system components depend on the customer repository and inventory system components. Notice the interface names CustomerLookup and ProductAccessor copied out in figure 5. In this example, this may seem like unnecessary repetition, but symbols do allow different interfaces (and different names) in each component that depends on implementing differences (for example, a component provides a smaller required interface subclass).

Sub-system

In UML 2, the subsystem classifier is a special version of the component classifier. Because of this, subsystem symbol elements inherit all component symbol set rules like component symbol elements. The difference is that a subsystem symbol element is replaced by the subsystem keyword component, as shown in figure 6.

Figure 6: an example of a subsystem element

The UML 2 specification is rather vague about how to distinguish subsystems from components. From a modeling point of view, the specification does not see any difference between components and subsystems. Compared with UML 1. X, this UML 2 model ambiguity is new But there's a reason. In UML 1. X, a subsystem is considered a software package, and this package symbol is causing confusion to many UML practitioners; therefore, UML 2 treats the subsystem as a special component because this is the way that the largest number of UML 1. x users know about it This change does introduce ambiguity into the diagram, but this ambiguity is more of a realistic reflection against errors in the UML 2 specification.

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

Transcend the foundation

The UML component diagram is one of the easier diagrams to understand, so there is not much to go beyond the basics. However, there is one aspect that you can think of as slightly difficult.

Display the internal structure of the component

Sometimes it makes sense to show the internal structure of the component. In my previous article on class diagrams, I showed how to model the internal structure of a class; here, when it is made up of other components, I will focus on how to model the internal structure of components.

To show the internal structure of the component, you just need to draw the component larger than usual and place the inner part in the name area. Figure 7 shows the internal structure of the Store component.

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

Using the example shown in figure 7, the Store component provides the OrderEntry interface and requires the Account interface. The Store component consists of three components: Order,Customer and Product components. Notice why the OrderEntry and Account interface symbols of Store have a square on the edge of the component. This square is called a port. In a simple sense, the port provides a way to show how the interface provided / required by the modeling component is related to the part of it. 4 by using ports, we can separate the internal parts of the Store component from the external instance. In figure 7, for the process, 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 assigned to the required Account port of the Store component. By connecting the Account port, the internal parts of the Store component, such as the Customer component, can have local characteristics that represent unknown external entities that execute the port interface. The required Account interfaces will be implemented by external components of the Store component. five

In figure 7, you may also notice that the internal connections between the internal components are different from those shown in figure 5. This is because these depictions of the internal structure are collaboration diagrams nested in the classifier (a component in our case), because the collaboration diagram shows the entities or roles in the classifier. The relationships modeled between internal components are represented by what UML calls a composite connector. A composite connector binds the interface provided by one component to the required interface of another component. The combined connectors are represented by tightly connected lollipops and socket symbols. Drawing these combined connectors in this way makes lollipops and sockets easy to understand symbols.

Conclusion

UML component diagrams are often very important diagrams that an architect builds at the beginning of a project. However, the usefulness of UML component diagrams spans the life of the system. UML component diagrams are invaluable because they model and document the architecture of a system. Because UML components document the architecture of the system, developers and potential system administrators will find that the key products of this work help them understand the system.

UML component diagrams are also seen as input to software system configuration diagrams, which will be the topic of later articles in this series.

Footnote

1 is called the actual project of the component in UML1.x, and the product in UML 2. A product is a physical unit, such as a file, runnable program, script, database, and so on. Only one product depends on the actual node; classes and components have no "location". However, a product may display components and other classifiers (such as classes). A single component may be displayed by multiple products, and they may be on the same or different nodes, so a single component can be implemented indirectly 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 for 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 presented in the model of the system.

4 in fact, ports are suitable for any type of classifier (for example, a class or other classifiers that may be available in your model). To keep this article concise, I mention ports in component classifiers and their use.

Generally speaking, when you draw the dependency between a port and an interface, the interface of the dependent party (requirement) will handle all the processing logic during the run time. However, this is not a hard rule-for the surrounding components (for example, the Store component in our example), it is perfectly acceptable to use your own process logic, rather than just delegating the process to the dependent interface.

Thank you for your reading, the above is the content of "detailed introduction of UML component diagram", after the study of this article, I believe you have a deeper understanding of the detailed introduction of UML component diagram, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Development

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report