UMLUse case diagram
The use case diagram mainly uses a diagram to represent the main event process of the system. It is mainly used to describe the customer's needs, that is, the user wants the system to complete certain functional actions, the general understanding of the use case is the functional module of the software. The designer creates and explains Use Case Diagrams based on the customer's needs to describe the functional modules of the software and the call relationships between these modules.
The use case diagram consists of use cases, participants, and relationships. The use cases are connected to each other to reflect the entire structure and function of the system to the user, corresponding to the software structure and function decomposition.
A use case is a behavior visible outside the system and is a complete service provided by the system for one or more actors. In principle, use cases are independent and parallel, and there is no subordination between them. However, in order to reflect the business relationship between some use cases and improve maintainability and consistency, the use cases can abstract several relations, including, extend, and generalization.
Relationship between Use Case charts
1. Include)
- Inclusion relationship: Use inclusion cases to encapsulate a group of similar actions (behavior fragments) that span multiple use cases, so that multiple (base) use cases can be reused. The relationship between the basic case control and the contained case, and whether the event stream of the included case will be inserted into the event stream of the base case. The base use case can depend on the result of the execution of the use case, but neither party can access the attributes of the other party.
- Applications with inclusion relationships: reuse. (1) When an event in a use case flows through a complex process, we can abstract an event stream into an included use case to simplify the description of the use case. (2) when the use cases are too detailed, a basic use case can be abstracted to include these fine-grained use cases. This is similar to encapsulating an algorithm of a program into a sub-process in a process design language, and then calling this sub-process from the main program.
- For example, the service always has the function of maintaining XX information. If you use this function as a use case, it is too complicated to describe, edit, and modify the information in the use case details; if it is divided into new use cases, edit use cases, and delete use cases, the Division is too detailed. The contained relationship can be used to clarify the relationship.
2. Extended)
- Extensioning: encapsulate a relatively independent and optional action in the base case with the extension case, and then let it claim the extension from the base case.
Point) to make the basic use case behavior more concise and more concentrated. Add new behaviors for the extended use case. The extended use case can access the attributes of the base use case. Therefore, it can determine whether to execute itself based on the current status of the extension points in the base use case. However, the extended use case is invisible to the base use case.
- For example, you can export and print the query results in the system. For queries, whether or not the query can be exported or printed is the same, and export and printing are invisible. Imports, prints, and queries are relatively independent, and new behaviors are added for queries. Therefore, you can use the extended relationship to describe:
3. Generalization)
- General relationship: the child case is similar to the parent case, but shows more special behavior. The child case inherits all structures, behaviors, and relationships of the parent case. A child use case can use a behavior of the parent use case or reload it. The parent case is usually abstract. Generalization is rarely used in practical applications. Special behaviors in subcases can be used as alternative streams in the parent case.
- For example, there may be many tasks that require approval from department leaders in the business, but the approval process is very similar. In this case, the general relationship can be expressed as follows:
Relationship between class charts
Classification: generalization, dependency, Association (aggregation and combination), and implementation relationship.
1. Generalization)
- Generalization is the relationship between the parent class and the Child class. The Child class inherits all the structures and behaviors of the parent class. You can add new structures and behaviors in the subclass, or override the behavior of the parent class.
2. Dependency)
- Dependency: A usage relationship. Changes to a specific thing may affect the use of the thing. When you want to show that one thing is used when another thing is used, there is a relationship between the two elements. Changes in one element (Service Provider) will affect the other element (customer ), or to it (customer)
Provide the required information.
- Association and generalization are dependent, but they have more special semantics, so they have their own names and detailed semantics. The dependency is represented by a virtual arrow pointing from the customer to the provider, and a constructor keyword is used to differentiate its type. Generally, dependency is reflected in the way a class uses another class as a parameter.
3. Association)
- Association is a structured relationship, that is, an object is associated with another object. Given two associated classes, you can get the objects of another class from the object of one class. There are two-element and multi-element relationships. Associations are implemented by class member variables.
- Aggregation)
Aggregation is a special association. It describes the "hasa" relationship, indicating that the entire object has partial objects. Aggregation is strongly correlated, emphasizing the relationship between the whole and the part. The whole and part are aggregated. Like the association relationship, the aggregation relationship is implemented through the member variables of the class.
A combination is a form of aggregation. It has a stronger relationship of ownership and emphasizes that the overall and partial lifecycles are consistent. Overall responsibility for partial lifecycle management. If the entire object is destroyed, some parts must be destroyed together. If the owner is copied, some parts must be copied together. Like associations, composite relationships are implemented through class member variables.
4. Implementation)
- The implementation relationship specifies a contract between two entities. In other words, one entity defines a contract, and the other entity guarantees the fulfillment of the contract.
After drawing the UML diagram of the charging system for the data center, I found that I still don't quite understand the relationship between the use case diagram and the class diagram. So I also referred to some online materials and felt that the analysis was quite clear, this is why I want to help other students.
