{"id":71164,"date":"2022-03-16T12:42:23","date_gmt":"2022-03-16T16:42:23","guid":{"rendered":"http:\/\/ideascale.com\/%e5%8d%9a%e5%ae%a2\/%e4%b8%8d%e5%90%8c%e7%b1%bb%e5%9e%8b%e7%9a%84%e4%b9%8c%e9%b8%a6%e5%9b%be\/"},"modified":"2024-02-20T04:39:01","modified_gmt":"2024-02-20T08:39:01","slug":"%e4%b8%8d%e5%90%8c%e7%b1%bb%e5%9e%8b%e7%9a%84%e4%b9%8c%e9%b8%a6%e5%9b%be","status":"publish","type":"post","link":"https:\/\/ideascale.com\/zh-hans\/%e5%8d%9a%e5%ae%a2\/%e4%b8%8d%e5%90%8c%e7%b1%bb%e5%9e%8b%e7%9a%84%e4%b9%8c%e9%b8%a6%e5%9b%be\/","title":{"rendered":"\u5168\u90e8 14 \u79cd UML \u56fe\u8868\u7684\u5b8c\u6574\u5217\u8868"},"content":{"rendered":"
The Unified Modeling Language System (UML) is the industry standard for simplifying software architecture. It involves a set of specific graphic notation techniques to represent visual models of complex software ecosystems. Developers use various types of diagrams to illustrate various aspects of software systems and each of these is often constructed with different types of UML diagrams.<\/p>\n
Depending on the type of UML diagram, it may or may not include both software and hardware components, and in this article, we will discuss the 14 different types of UML diagrams.<\/p>\n
Two Broad Categories<\/b><\/p>\n
UML 2.2 is the latest accepted norm across the industry spectrum. It comprises 14 types of UML, each serving specific purposes. These 14 categories come within two main groups, static UML and dynamic.<\/p>\n
The static type is also known as structural diagrams. The other name for the dynamic UML diagram is behavioral UML.<\/p>\n
The static UML represents various interpretations of the software architecture when it is not active. The static view defines the components and classes as discrete but interconnected units. Depending on the type of representation, the structural diagrams can be of seven sub-types.<\/p>\n
Class Diagram<\/b><\/p>\n
Class diagrams are the most common UML diagrams. They categorize components into various key classes, methods, and attributes. The relationship between these elements is key and is partially what makes the class diagram unique.<\/p>\n
Object Diagram<\/b><\/p>\n
The object UML diagram exhibits the state of the static software architecture at any given point of a function. These diagrams also display the fixed relationship between the various classes and connect elements similar to the class diagram. Tallying the object diagram with the class view helps verify the software solution’s accuracy.<\/p>\n
Deployment Diagram<\/b><\/p>\n
The deployment diagram deals with the entire deployment of the software architecture, including both software and hardware components. It is particularly useful when deploying software systems across computing networks with varied configurations.<\/p>\n
Composite Structure Diagram<\/b><\/p>\n
The composite structure diagram exhibits the internal structure of various classes. The detailed chart displays a complete picture of the classifiers, including the parts, ports, and connectors. These are similar to class diagrams, but the approach is more granular. Here, the main emphasis is on showing the individual components of classes rather than the extensive connections between elements.<\/p>\n
Package Diagram<\/b><\/p>\n
In UML, a package refers to a group of relevant elements. These include documents, classes, and other packages. Every single element has a specific position inside the package hierarchy. These packages are shown as a file folder in UML and are the emphasis of the package diagram.<\/p>\n
Profile Diagram<\/b><\/p>\n
The profile diagram is a relatively new sub-type introduced in UML 2. It indicates a generic mechanism for extending UML models to particular domains. For example, there can be separate profile diagrams for aerospace and healthcare software systems representing the attributes unique to these domains.<\/p>\n
Component Diagram<\/b><\/p>\n
The component diagram exhibits the structural connections between the various components of the software system. It also shows the interfaces and connectors of the software architecture.<\/p>\n
The behavioral UML diagram exhibits the software architecture’s state when used. It has four key subtypes.<\/p>\n
The last type is the interaction diagram. The interaction UML diagram consists of four sub-types of its own.<\/p>\n
State Machine Diagram<\/b><\/p>\n
This mode represents the objects at different states at a given point of operation. It is critical to display finite state transitions.<\/p>\n
Activity Diagram<\/b><\/p>\n
This UML model exhibits the workflow within the software system. The control flow from one point to another in the software system is critical in understanding its operation.<\/p>\n
Use Case Diagram<\/b><\/p>\n
These diagrams represent the complete picture of system activity involving use cases and actors (users). It shows the different functions achieved under the influence of actors.<\/p>\n
Sequence Diagram<\/b><\/p>\n
This UML diagram displays the interactions between different objects in the software hierarchy. Arrows are used to represent interactions between different processes.<\/p>\n
Communication Diagram<\/b><\/p>\n
This type of interaction diagram focuses on the messages passed between the objects in the software system.<\/p>\n
Interaction Overview Diagram<\/b><\/p>\n
These are similar to activity diagrams, but they represent a larger scale. They represent a sequence of interaction diagrams of the dynamic system. It also shows the series of actions by simplifying complex interactions to simple graphical representations.<\/p>\n
Timing Diagram<\/b><\/p>\n
This sub-type of interaction diagrams depicts the object behavior charted in a specific time bracket. It is critical to interpret the state transitions and object behavior within duration constraints.<\/p>\n