When you have a business case in mind, how do you present it to your boss? A big block of text, or write a Demo? The boss is busy, and the boss may not understand the “fancy” technology you are talking about. Is there a way of presenting it that is cheaper to implement but contains more information? Yes, draw a picture!

From today, I will open a special topic to talk about some graphic modeling methods that are often used in our development. With the prologue over, we sail from UML views.

UML Use Case diagram

UML — Unified Modeling Language — is one of the most commonly used and important views in the business Modeling phase. Because it is easy to understand, it is often used in documentation or presentations across organizations; By cross-organization, I mean not just between development departments, but across product, design, test, operations, and so on. In UML designs, the first diagram is usually the use case diagram: yes, the one with the “little people.”

The Use Case diagram consists of three parts: Use cases, actors, and their relationships with each other. The form is a combination of ellipses, little people, and arrows.

example

Let’s not get into the specifics of an ellipse or an arrow. I think it’s best to start with specific Use cases. We tried to design a simple banking APP, which includes registration, login, transaction and other operations. Step by step, we disassemble the process of waving the use case diagram.

Systems

The first step in drawing a use case diagram is usually to drag out a large rectangular block and name it our target system — Banking App. A use case diagram typically has only one System, after which we place all of the System’s related functions (” use cases “) inside the System, with the stakeholders (” actors “) on the left and right sides of the System.

Actors

The second drawing element is the actor, the system stakeholder, which can be a person, an organization, an external device, or another system. In our Bank case, there are two related parties of the App: Customer and Bank.

Typically, there are two or three actors in a use case diagram, with the primary actor on the left side of the system and the secondary actor (the main actor’s response) on the right; Obviously our App is primarily customer-facing, so we put the customer on the left.

Use Case

The third step is to add specific use cases to the system, which are the functions or business blocks that the system provides. Our banking APP is relatively simple and only provides the following services:

  1. User login
  2. Check balance
  3. Transfer funds
  4. Make payment

Relationships

The fourth step is to connect the actors to the use cases, which we call Relationships. In the use-case diagram, the relationship can be further subdivided:

  • association

    “Associations” are the most naive and generic form of relationships — represented by solid lines in UML diagrams. As shown below, customers can log in, check balance, transfer and trade when operating the App, so we can simply bind customers with these use cases by “association”. On the bank side, when the customer checks the balance, transfers, and trades, it naturally needs to respond, so it also needs to be “associated” with these three use cases; The login operation is automatically authenticated by the system, so it is not connected to the bank.

  • include & extend

    For example, after the customer enters the user name and password, the system needs to verify the validity of login. This operation is an inevitable use case after each login. We will use <

    > to connect these two events. If the login fails “possibly”, the system displays an error message. We use <

    > to describe the relationship between this possible use case and the previous use case. In UML, “include” and “extend” are represented in the form of a dotted line + arrow, and the specific relationship form is annotated above the dotted line.

  • Generalization

    Another common type of relationship is called generalization, or inheritance. Inheritance is represented in UML as a solid line + hollow arrow. Take our bank App as an example. Nowadays, banks usually provide multiple account payment methods. You can either withdraw cash from your savings account or deduct money from some T+0 money fund accounts. These two subdivided payment methods, as shown below, can be represented as generalized use cases of the general payment use cases in the use case diagram:

    Of course, “generalization” (or “inheritance”) is not limited to use cases, but can also be in the form of an actor inheriting an actor, such that both VIP customers and regular customers can be generalized participants of a generic customer.

Extension points & Note

Finally, all UML views can actually be annotated, the technical term being Extension points and notes; These two comments are similar in nature, and both serve to illustrate:

  • Extension: Usually a note in the lower half of the use case ellipse, which is relatively small
  • Note: A text-like pattern with dotted lines connecting specific elements. It can be accompanied by more text

summary

Ok, so that’s the UML use case diagram in general. To review the usage scenarios of use case diagrams, in the product design phase, we can use use case diagrams to establish abstract relationships between users, systems, and functional services in order to describe the external dynamic characteristics presented by the product. In large factories, UML use case diagrams are usually drawn by the product manager or designer and then handed over to the development team for implementation.

We took an example of a banking App, which is actually a little bit big; In real world development, a Use Case diagram usually corresponds to a simple business flow. When writing use Case diagrams, we should also pay attention to abstracting closely related functional modules into a simple Case at the macro level, and then gradually drawing subdivided Case use Case diagrams for these larger functional modules.