UML Symbols and legends

The three "allies" James Rumbaugh, Grady booch, and Ivar Jacobson created UML in 1995 and integrated their respective methods (OMT, booch development method, and OOSE) into a whole. In 1997, OMG used UML as an actual public standard.

To a large extent, UML is a graphical language used to describe, record, design, and construct a solution. The powerful role of UML is that it provides a public language for users, developers, analysts, customers, and other shareholders in the software development process so that all Members can understand and communicate with each other. Furthermore, UML is independentProgramming LanguageTherefore, it is widely used. When using this language, the development team does not need to make technical decisions before analyzing, describing, and agreeing to requirements, workflows, and constraints.

These models have one thing in common. To design and describe software solutions, a single model cannot meet the requirements. No model is sufficient to describe the problem or design a solution. A set of models are always required. New users of UML often ask this question: Which model should I use? There is no clear answer to this question, because it depends on the complexity of the solution and the characteristics of shareholders. If the problem with the solution is simple and clear, for example, a software solution built displays a web page (ASP) that describes the opening time of the sales department, the other solution calculates the annual tax payable of all individuals or units, so the former MODEL certainly does not have many, and is not as detailed as the latter. The case studies in this book will discuss when to use models. Based on experience, the number and details of the model should reach the level where all shareholders can handle the solution.

UML includes three types of models: functions, behaviors, and implementations. The feature category model is used to collect requirements and describe features. The behavior class model is used to describe the objects and user behavior of the solution. The implementation category model is used for the physical implementation of solution functions and behaviors.

Function: use case diagram and class diagram
Behavior: Interaction diagram (sequence diagram and collaborative diagram), status diagram, and activity diagram
Implementation: component diagram and deployment Diagram

I. Function Diagram
Function diagram: build a model of the solution features. In other words, if you want to figure out what the solution can do, view the function diagram. The function diagram is a use case diagram and a class diagram. View these figures to learn more about the functions and development methods of the solution. The sequence chart also displays the function, but the sequence chart is classified into the behavior class, because their behavior-oriented features are more obvious.

1. use case diagram
Generally, we first construct an example diagram to collect user requirements. The use case diagram shows the solution from the user's perspective. The solution should be discussed in a language that the user can understand. Triggers and database constraints should not be mentioned at this stage. The Use Case Model consists of actors and use cases and their relationships.

An actor refers to someone or something that interacts with the system. Actors either receive information from the solution or pass the information to the system. The figure of actors is a humanoid. Actors often represent people (such as users) and another IT system. For example, an enterprise resource planning (ERP) system can receive data from e-commerce solutions. In other words, an ERP system is an operator of e-commerce solutions. Examples of personnel actors include customers who take money from ATMs. The customer here is an operator related to the ATM system.

A use case is a process, which indicates that the symbol is an elliptic

2. Class Diagram
Class diagrams are used to collect requirements. It raises a question, if possible, and verifies that the system can fulfill the requirements. Generally, you can view class diagrams from the perspective of the project team and developers.

In the class diagram, draw logical and physical entities and relationships between objects in the solution. In other words, construct the model of the class recognized in the use case diagram. In this example, the candidate objects include customer and order. Therefore, the customer class and order class models are constructed in the class diagram. These may be traditional object-oriented classes, or non-object-oriented classes such as ASP pages, database tables, or COM + components.

The UML class represents a rectangle, as shown in 3-6. The figure shows that this class has some attributes (customerid and date) and some methods (new, placeorder, and delete ).
In the class diagram, classes are related to each other. For example, a customer can put several orders into the system. The relationships between classes are expressed by solid lines, as shown in 3-7.

Ii. behavior diagram
A behavior diagram describes the behavior or interaction of a solution. This type of graph builds what happens in the solution. Only by understanding this content can we develop a solution.

1. Interaction Diagram
UML has two types of interaction diagrams: sequence diagram and collaborative diagram. The difference between the two types of graphs is that the sequence chart displays tasks in chronological order based on time, while the collaboration chart displays the interaction between tasks and Information (objects. In the collaboration diagram, the time is displayed in encoding format, which is difficult to select. Although there are these fundamental differences, the two types of graphs share the same: they are used to show how objects interact with users to execute tasks.

For beginners of UML, it is difficult to remember which interaction diagram should be used. Fortunately, you can solve this problem in a simple way. You can judge from the graph name. The sequence diagram describes how to perform interactions in chronological order. The collaboration diagram shows the interaction between information and tasks, but emphasizes the time. These two types are sometimes used at the same time, but some policies should be used when building an interactive model:

If is based on time then

Sequence Chart

Else (focusing on organizational aspects)

Collaboration Diagram

End if

2. Status chart
In designing an object-oriented solution, a state chart is used to display the object's life cycle.

The solid box symbol represents the status, and the solid line arrow represents the conversion. In addition, the solid circle indicates the start point, and the solid circle plus an empty circle indicates the end point.

Note:

A status chart is used only to display the various possible states of an object and how to switch from one state to another. In other words, the life cycle of an object is represented by a state chart.

3. activity diagram
It seems that the activity diagram is hard to understand. However, the activity diagram only describes the workflow and who completed the work, similar to the popular data flow chart. In fact, the activity chart can be regarded as a data flow chart.

The symbols used by the activity chart are similar to those used by the status chart. In the activity diagram, an extended oval is used to represent the activity and a rounded corner is used to represent the State. As the name suggests, "activity" is the action to be executed, such as the validate order ). "Status" indicates the possible status of the object. For example, after an order is verified, the order enters the validated order status. The interesting part of an activity chart is the lane, represented by a vertical line. Using swimming channels, you can gain a broad understanding of the various actors/departments in the system and the tasks they perform. If there are too many actors involved or frequent switching between the lanes, errors or delays may occur. These problems can be found through the activity diagram. This analysis helps optimize the business process.

The activity diagram provides an overview of the system and workflow. Sometimes, the activity diagram is also used for process modeling.
3. Implementation Diagram
The implementation diagram describes how to package and implement the solution. This is very helpful for implementing and restoring solutions.

1. Component Diagram
As the name implies, a component diagram refers to the way in which the actual physical component model is built in the solution. Widget Chart DisplaySource codeComponents, COM + components, and other binary and executable components. The component diagram also displays the component interface.

Interfaces are the communication methods between components. For example, a car's interface is a dashboard and a pedal. You can use the "interface" to communicate with a car. The order component can contain a method to cancel the order. The interface specifies the order ID required to perform this operation. In other words, to delete the order object, the order must be the order transfer order ID to be deleted.

Component diagram used to design solutions

2. Deployment Diagram
The deployment diagram shows the deployment method of the solution, which consists of the processor, device, and connector. "Processor" is a hardware item for executable components. A device is a hardware device that does not have the ability to execute components, such as a modem or printer. The connector is the relationship between the processor and the device.

A deployment diagram describes the physical computers on which the component runs and how the solution interacts with the hardware. You can also specify the number of node types in the solution through the deployment diagram.

A symbol is a box that displays the physical part.

Relationships between classes

UML classifies the relationships between classes into the following five types.

● Association: there is a specific correspondence between instances of Class A and Class B.

● Dependency: services provided by Class A and Class B

● Aggregation: Class A is the overall Class, Class B is the local class, and Class A objects are composed of Class B objects.

● Generalization: Class A inherits Class B

● Implementation: Class A implements the B Interface

Association)

Association refers to the specific correspondence between classes, which is expressed by arrows with solid lines in UML. Compare and associate classes by quantity

There are three types:

● One-to-one Association

● One-to-Multiple Association

● Multiple-to-Multiple Association

Note: The Association can also be divided into one-way Association and two-way Association.

Dependency)

Dependency refers to the call relationship between classes, which is expressed by arrows with dotted lines in UML. If the Class A contains the attributes or methods of Class B,

Or Class A is responsible for instantiating Class B, so Class A depends on Class B. Unlike associations, you do not need to define B-type attributes in Class.

Aggregation)

Clustering refers to the relationship between the whole and the part, which is expressed by a diamond arrow with solid lines in UML.

Clustering can also be divided into two types:

● The clustered subsystem can be disassembled and replaced. This is a common clustering relationship.

● The clustered subsystem cannot be disassembled or replaced. Such aggregation is called a strong Clustering or composition relationship.

Note: strong aggregation (composition) can be expressed by solid diamond arrows with solid cables.

Generalization)

Generalization refers to the inheritance relationship between classes. In UML, it is represented by a triangle arrow with a solid line.

Implementation)

Implementation refers to the relationship between classes and interfaces. In UML, a triangular arrow with a dotted line is used.

The following describes the gof design patterns:

Arrow and triangle indicate the Child class relationship.

The dotted arrow line indicates that one class instantiates an object of another class, and the arrow points to the class of the object to be instantiated.

A normal arrow line indicates an acquaintance (acquaintance is also called an association or reference), meaning that an object only knows another object. Familiar objects may request mutual operations, but they are not responsible for each other. They only indicate loose coupling between objects.

An arrow line with a rhombus at the end indicates aggregation, which means that an object has another object or is responsible for another object. Generally, an object contains another object or a part of another object. Aggregation means that the aggregate object has the same lifecycle as its owner.
Abstract class names are in italic, and abstract operations are also in italic. The figure can include the operation pseudoCode, The code will appear in the box with a pleat, and use the dotted line to connect the pleat box with the operations implemented by the Code.

Simple Description

package
package. Used to aggregate and organize a part of the model (Use Case, class, and so on ).
actor
participants. It represents a user or other external drivers.
Use Case. Use Case describes the behavior of a part of the system. Generally, use case records requirements for a system function, which is demonstrated by responses to actions or events.
<> relationship
includes a link. The Use Case relationship marked as <> link can introduce other use case functions. This is a convenient way to separate use cases and avoid a single use case that is too large.
<> relationship
Expand the relationship. When the use case relationship marked as <> relationship does not repeat the descriptions and requirements of the existing use case, the behavior of the existing use case can be specialized.
dependency. As its literal meaning, it indicates that one thing depends on another thing. This means that one thing understands another thing and needs another thing to function.
note
annotation. The purpose of providing annotations in a UML diagram is to briefly describe the content of the chart.
component. A component generally represents a software unit. It may be a DLL, an execution file, or a database.
node. A node generally represents a machine that can run one or more system components.
class. Classes in UML are the same as classes in Object-Oriented Programming, that is, they define and encapsulate a group of behaviors and attributes. Class is instantiated at runtime to create an object.
Object
object. The object is a class instance. For example, "myclass myobj = new myclass;" creates a myobj object.