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

This article is to share with you about the glossary of terms UML deployment diagram introduction, the editor thinks it is very practical, so share it with you to learn, I hope you can get something after reading this article, say no more, follow the editor to have a look.

To introduce you to the knowledge of UML deployment diagram, including general rules, nodes and components and dependencies and communication associations. Let's take a look at a detailed description of the UML deployment diagram.

UML deployment diagram of UML modeling style

A UML deployment diagram (object Management Organization 2001) depicts a runtime hardware node and a static view of the software components running on those nodes. The deployment diagram shows the hardware of the system, the software installed on the hardware, and the middleware used to connect heterogeneous machines. The purpose of creating a deployment model includes ∶ exploring issues related to the commissioning of the system. Explore the dependencies between your system and other systems in the production environment that may already exist or will be introduced. Describe the main deployment structure of a business application. Design a hardware and software structure of the embedded system. Describe an organization's hardware / network infrastructure.

I. General guidelines

1. Indicate software components on a specific project diagram

Figure 1 is a description of the UML deployment diagram of a university management system. The diagram describes how the major software components that contain a single application are configured into the production environment, which enables the project team to determine their deployment strategy.

Figure 1. UML deployment diagram for a specific project

two。 Nodes and communication associations focused on enterprise-level graphs

The UML deployment diagram is often thought of as a network diagram or technical architecture diagram, and figure 2 is an example of this style, which describes the technical infrastructure of a simple organization. Note that figure 2 is a very simple example. In a diagram like this, many organizations will have dozens or even hundreds of nodes.

Although it is useful to indicate the deployment of components within the limited scope of the diagram, such as figure 1, the diagram quickly becomes bulky. Figure 2 focuses on the high-level deployments of the enterprise, so the fine details of the software components configured on top of the hardware nodes do not need to be displayed. You can process this information in your CASE tool, but that doesn't mean you need to show them on the diagram.

Figure 2. UML deployment diagram of an organization

II. Nodes and components

A node, usually described as a three-dimensional box, represents a computing device, usually a single hardware device, such as a computer, network router, host, sensor, or personal digital assistant (PDA). The component, described as a rectangle, with two smaller rectangles protruding from the left side, is the same symbol used on the UML component diagram, which represents an intermediate product of the software, such as a file, framework, or domain component.

1. Naming nodes in descriptive terms

In figure 1, you can see that nodes have names, such as client, ApplicationServer, DatabaseServer, and Mainframe. All of these terms need to be immediately recognized by developers in the organization because these terms are used on a daily basis. Keep it simple.

two。 Model only important software components

Although figure 1 contains software components, it does not describe each software component. For example, there are probably other software components, such as operating systems and applications, installed on the client, but those components are not shown because they are beside the point. The fact is that each node may have dozens or even hundreds of software components configured on it, your goal is not to describe all the software components, but only to describe those components that are critical to the column sections of the system. If you need to explore the relationships between software components, you should create an UML component diagram instead, following the "appropriate Artifact" practice of Agile Modeling (AM) (Ambler2002) applications.

3. Apply a consistent layout to a component

Apply the same layout to the component on the UML deployment diagram as in the UML component diagram.

4. Apply the visual layout to the node

Figure 2 uses a visual layout to describe the node description node. For example, mobilePC is displayed as a notebook, while databases is represented by a traditional database cylinder symbol. It is impossible to set standards for visual layouts on UML deployment maps, and the general rule of thumb is to use appropriate clip art as you can see.

III. Dependence and communication association

Communication associations, often referred to as connections, are described as lines between connecting nodes. Dependencies between components are modeled as dotted arrows, the same symbols used in other UML diagrams.

1. Use version to indicate communication protocol

Communication associations support one or more communication protocols, each of which should be described using a UML version. You can see the HTTP, JDBC, and webservices protocols in figure 1, and they use this method. Table 1 provides a list of typical communication related layouts, and your organization may want to develop its own specific standards.

Table 1. The general version is communication association.

Version meaning

Asynchronously an asynchronous connection, perhaps via a message bus or message queue.

HTTP Hypertext transfer Protocol, an Internet protocol.

JDBCJava database connection, a set of JavaAPI written for database access.

ODBC open database connection, a set of Microsoft database access API.

RMI remote method call, a communication protocol for Java.

RPC communication via remote procedure calls.

Synchronize a synchronous connection, and the sender waits for a response from the receiver.

Webservices communicates via WebServices protocols such as SOAP and UDDI.

two。 Just model critical dependencies between components

The dependencies between the domain components configured on the application server in figure 1 are not modeled because they have nothing to do with the diagram (and they * are specific details modeled on the UML component diagram). However, the dependency between components on the database server is modeled because it helps to show database access. Domain components are indirect to the orientation of the database, and they need to go through a persistence framework, which is a common architectural practice (Ambler2001). Follow the practice of AM, simple description and modeling. Model only the information related to the task at hand.

The above is a brief introduction to the glossary UML deployment diagram, and the editor believes that there are some knowledge points that we may see or use in our daily work. I hope you can learn more from this article. For more details, please follow the industry information channel.

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.