Level: primary
Donald Bellibm Global Service, IBM 2005 February 15
From Rational EDGE: This article introduces component diagrams, a structural diagram specified in new unified modeling languages 2.0.
This article is part of a series of articles in a series of articles in the basic diagram used in Unified Modeling Language 2.0 or UML. In previous previous UML class diagrams, I describe how the tag set of class diagrams is the basis for all UML 2 structural diagrams. With the trajectory of UML 2, the component map is introduced.
The main purpose of the figure of the figure is to display the structural relationship between system components. In UML 1.1, a component exhibits implementing items such as files, and running programs. Unfortunately, this is more common use with the term, and there is something like this COM component. Over time and the UML continuous version release, the UML component has lost most of the most meaning. UML 2 officially changed the essence of component concept; in UML 2, components are considered to be independent, and one or more interfaces are provided in a system or subsystem. Although the UML 2 specification does not rigorously declares it, the component is a larger design unit that presents things, which generally uses replaceable components. However, it is not like in UML 1.x, now, the components must have strict logic, design. The main idea is, 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 the assembly-based development (CBD), the component map provides a natural form that starts to model modeling. Component diagrams allow a architect to verify that the system is implemented by components, which ensures that the final system will be accepted.
In addition, component diagrams are useful for different groups. The figure can be presented to a key project initiator and implementing personnel. Typically, when the component map connects the system's implementation personnel, the component map usually makes the project initiator easily because the figure shows the early understanding of the entire system that will be established.
Developers discovery component maps are useful because component graphs provide them with high-level architectural views that will be built, which will help developers start building implementation, and decide on task assignment and (or) demand skills . System administrators found that component diagrams are useful because they can get an earlier view that will run the logic software components on their system. Although the system administrator will not be able to determine the physical device or physical executable from the graph, they still welcome component diagrams because it provides information about components and their relationships (this allows system administrators to easily plan The work behind.
Symbols in now, component diagram symbols It is one of the most easily drawn UML maps. Figure 1 shows a simple component diagram for 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, use a generous block, and there are two convex small squares on its left side to represent the component.
Figure 1: This simple component map uses UML 1.4 symbols to display the general dependencies of Order System
The above UML 1.4 symbols are still supported in UML 2. However, the UML 1.4 symbol set is not well adjusted in a larger system. The reason for this is that, as will be seen in the rest of this article, UML 2 significantly enhances the symbolic set of the component map. UML 2 symbols can be adjusted better under conditions that are easy to understand, and the symbol set also has more information.
Let us build a component map according to the UML 2 specification.
The foundation is now now painted in UML 2 is similar to drawing a class on a class diagram. In fact, in UML 2, a component is just a special version of the concept. This means that the symbol rules for classifiers are also applicable to component classifiers. (If you have read and understood the article I used to generally structural maps and class diagram details [http: // www. Ibm.com/developerworks/cn/RATIONAL/RATIONALEDGE/CONTENT/FEB05/Bell/index .html] You will be very easy to understand the component map). In UML 2, one component is drawn into a rectangle that can select a small piece. In UML 2, a high-level abstract view of the component can be modeled with a rectangular model, including the text and / or icon of the component prototype. The text of the component prototype is "« Component »", and the component prototype icon is a large rectangle of two convex small long squares on the left (symbolic elements of components in UML 1.4). Figure 2 shows that the components can be represented by three different methods in the UML 2 specification.
Figure 2: Different methods of the picture component name
When drawing a component on the map, it is important that you always include component prototype text (which Component in double angle brackets, as shown in Figure 2) and / or icon. Reason? In UML, a rectangular shape without any prototype classifier is interpreted as a class component. Component prototypes and / or icons are used to distinguish the rectangles of the component elements.
Provide / require interface modeling for components to model all valid symbol elements in Figure 2; however, a typical component diagram includes more information. A component element can be added additional zones below the name zone. As mentioned earlier, one component is a separate unit that provides one or more common interfaces. The interface provided represents the formal contract of the user / customer service that the component is provided to it. Figure 3 shows that the ORDER component has a second zone for representing an interface provided and required by the ORDER component. 2
Figure 3: This additional zone showing the interface provided and required for the ORDER component.
In the ORDER component example in Figure 3, the component provides an interface called Orderentry and AccountPayableABLE. In addition, components also require another component to provide a Person interface. 3
Other method of the component interface modeling is also introduced into another method to display an interface that the component provides and requires. This method is to create a large square with component names, and placed in the UML 2 specification outside the UML 2 specification in the UML 2 specification. This second method is illustrated in Figure 4.
Figure 4: An alternative method (compared to Figure 3): an interface to provide / required using an interface symbol display component
In this second method, there is a complete circumferential interface symbol representing the interface provided by a complete circumference of the interface - "Lollipop" is a speed diary for this interface classifier to realize the relationship symbol. Only half of the interface (also known as the socket) symbol on the end represents the interface required by the component (in both cases, the name of the interface is placed near the interface symbol itself). Even if Figure 4 looks great to Figure 3, two images provide the same information - for example, the Order component provides two interfaces: Ordeeringry and AccountPayable, and the Order component requires the Person interface.
The modeling of component relationships When the relationship between the component is in the relationship between the components, the lollipops and socket symbols must also include a dependent arrow (as used in the class diagram). On the assembly map with lollipops and sockets, pay attention to the arrows from a strong (required) socket, and its arrow points to the supplier's lollipop, as shown in Figure 5.
Figure 5: Displaying the ORDER system component to depends on the component of other components. Figure 5 shows that the Order system component relies on the customer repository and inventory system components. Note that the interface name CustomerLookup and ProductAccessor replicated in Figure 5. In this example, this can look unnecessary repetition, but the symbol does allow for each of the components that depend on the difference in realization (and different names) (for example, one component provides a smaller) Required interface subclass).
Subsystems In UML 2, the subsystem classifier is a special version of the component classifier. Because this, the subsystem symbol element icon component symbol element inherits all component symbol collection rules. The only difference is that a subsystem symbol element replaces Component by the subsystem keyword, as shown in Figure 6.
Figure 6: An example of a subsystem element
UML 2 specification is quite vague in how the subsystem is quite vague. From modeling, specifications do not believe that components are different from the subsystem. Compared to UML 1. X, this UML 2 model ambiguity is new. But there is a reason. In UML 1.x, a subsystem is considered a package, and this package symbol is confusing to many UML practitioners; therefore, the subsystem is used as a special component in UML 2, because this is the most UML 1. x Users understand its way. This change really introduces the fuzzy into the figure, but this blurry is more realistic in the UML 2 specification.
Here, you may be grabbling the scalp and feel doubts. When should I use the component element, when I use a subsystem element. Quite frankly, I have no direct answer to you. I can tell you that in the UML 2 specification, when it is determined by the component or subsystem to determine the methodology of the modeling. I personally like this answer because it helps ensure that UML and methodology are independent of each other, which will help keep it universally used in software development.
Beyond the basic component diagram is one of the more easily understood, so there is no many content of the basis. However, one aspect you can think of it is slightly difficult.
The internal structure of the display assembly sometimes shows the internal structure of the component. In my previous article about the class diagram, I show how to model the internal structure of the class; here, when it consists of other components, I will pay attention to how to model the internal structure of the component.
In order to display the internal structure of the component, you only need to draw the components than usual and place the inside of 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.
The STORE component provides an Orderentry interface and requires an Account interface to be used in the example shown in Figure 7. The Store component consists of three components: Order, Customer and Product components. Note why the Store's Orderentry and Account Interface symbols have a block on the edge of the component. This piece is called a port. Simply feel, port provides a method that shows how the interface provided / required by the modeling component is associated with the portion thereof. 4 With the port, we can separate the internal parts of the Store component from an external example. In FIG. 7, for the process, the Orderentry port represents the OrderEntry interface of the ORDER component. At the same time, the internal Customer component requires an Account interface to be assigned to the required Account port of the Store component. By connecting the Account port, the STORE component internal components (e.g., Customer Components) may have local features that represent the external entity that performs the port interface. The required Account interface will be implemented by the external components of the Store component. 5
In Figure 7, you may also notice that the internal connections between the internal components are different from those shown in FIG. This is because these depiction facts of the internal structure are collaboration maps nested in the classifier (in our example), because the collaboration diagram displays the entity or role in the classifier. The relationship between the modeling between the internal components is represented by a combined connector called UML. A combined connector binds an essential interface of an interface to another component. The combined connector is represented by a tightly connected lollipop and socket symbol. In this way, these combined connections make lollipops and sockets a symbol that is easy to understand. Conclusion Component chart is often a very important picture that is established in the initial stage of the project. However, the usefulness of the component diagram spans the life of the system. Components are invaluable because they model and documentize a system architecture. Because component graphicized system architecture, developers and system possible system administrators discovering that key products for this work help them understand the system.
The component diagram is also considered input of the software system configuration diagram, which will be the following article topic behind this series.
Footnotes 1 in UML1.x is called the actual item of components, referred to as the product in UML 2. A product is a physical unit, like a file, running program, script, database, and more. There is only one product that depends on the actual node; the class and components have no "position". However, a product may display components and other classifiers (eg, classes). A single component may be displayed by multiple products, which may be on the same or different nodes, therefore, a single component can be implemented indirectly on multiple nodes.
2 Even if the component is a separate unit, they may still depend on the services provided by other components. Due to this, the required interface of a component of the documentation is useful.
3 Figure 3 does not show the full context of the ORDER component. In a real model, ORDERENTRY, AccountPayable, and Person interfaces are present in the system's model.
4 In fact, ports apply to any type of classifier (for example, a class or other classifier may have in your model). In order to make this paper, I mentioned the port in the component classifier and their use.
5 Generally, when you draw a port and an interface dependency, the interface of the dependency party (required) will process all processing logic within the runtime. However, this is not a hard specification - for the surrounding components (for example, the STORE components in our example), use your own process logic, not only delegate the process to the dependent interface, is completely acceptable .
Reference
You can see this article in our website on our world.
About the author Donald Bell is an IT expert in IBM global service, where he and IBM customers are committed to designing and developing software solutions. J2EE.
