UML use case diagrams for doing things

PJ’s iOS development routine

An overview of object-oriented technology

Basic object-oriented modeling principles: abstraction, encapsulation, inheritance, and classification.

Basic object-oriented software Engineering: OOA (Object-oriented analysis), OOD (Object-oriented Design), OOP (Object-oriented Programming) and OOSM (Object-oriented Software Maintenance)

The concept of an object is: an abstraction of an entity in a problem domain; The concept of a class is a description of one or more objects with project properties and behavior

Definition of property: a data item describing the static characteristics of an object; Definition of a service: A sequence of operations describing the dynamic characteristics (behavior) of an object.

The definition of a class includes three elements: name, attribute, and operation.

There are three main features of object-oriented presentation design: encapsulation, inheritance and polymorphism.

Three system models should be established in object-oriented system analysis: object model, function model and dynamic model.

Use case diagram

participants

Participants refer to external entities outside the system that need to use or interact with the system, including people, devices, and external systems.

Use cases

A use case is a sequence of verbal descriptions of an interaction between an actor using a function of the system. It can be said that the process of software development is use-case driven.

A use case is a dynamic description of system behavior, which belongs to the dynamic modeling part of UML. The modeling mechanism in UML includes static modeling and dynamic modeling. The static modeling mechanism includes class diagram, object diagram, component diagram and deployment diagram. Dynamic modeling mechanisms include use case diagrams, sequence diagrams, collaboration diagrams, state diagrams, and activity diagrams.

Theoretically, all the use cases of a software system can be drawn, but in the actual development process, the use case analysis only needs to find out those important and complicated use cases. Don’t try to represent all requirements in the form of use cases. Requirements come in two basic forms: functional and non-functional. Use cases describe only functional requirements, and many of those that are difficult to express in UML are non-functional requirements.

Generalization relationship

Official explanation: Generalization represents the relationship between general and special. In the generalization relationship between use cases, the child use case inherits the behavior and meaning of the parent use case, and the child use case can also add new behavior and meaning or overwrite the behavior and meaning of the parent use case.

The relationship between a subclass and its parent class.

Contains the relationship

Official explanation: Inclusion is the relationship between two use cases, where the behavior of one use case (base use case) contains the behavior of the other (inclusion use case).

PJ’s explanation: Reuse a function.

In the ATM system of a bank, there are four cases: deposit, withdrawal, Account balance inquiry and transfer, all of which require the user to log in to the ATM. That is, they include the user’s login behavior. Therefore, the behavior of a user logging in to the system is the same action in these use cases and can be extracted as a separate inclusion use case.

“Deposit”, “Withdraw”, “Query user balance” and “Transfer” are the basic use cases, and “Login” is the containing use case, as shown below:

By extracting the common user login behavior, the basic use cases “deposit,” “Withdraw,” “Query user balance,” and “transfer” no longer include user login behavior.

The online shopping system needs to check the credit card of the customer when the member registers for online shopping, to check whether the credit card number is valid and whether the credit card has enough funds for payment.

In the figure above, is it necessary to isolate the behavior of checking credit as a separate use case (as an inclusion use case), which is not necessary when the behavior of checking credit only occurs in the “online shopping” activity? When the behavior of credit checks occurs in other activities, it should be extracted for software reuse.

Develop relationships

Official explanation: In extended relationships, there are more rules for the implementation of extended use cases. Basic use cases must declare several “extension points”, and extended use cases can only add new behaviors and meanings to these extension points.

PJ’s explanation: Basic use cases can be selected to execute extended use cases after meeting certain conditions.

A library lending system. When the reader returns the book, if the book is borrowed for an extended period of time, there will be a certain late fee, as a fine.

comprehensive

In the online shopping system, when a registered member is browsing the website, he may decide to buy some goods at the moment, and when he decides to buy some goods, he must put them into the shopping cart and then place an order.

If the requirements of the online shopping system are changed to: registered members can shop online directly and decide to shop online temporarily after browsing products, it can be changed to the following figure:

Use case description

A use case without description is like a table of contents in a book. People only know the title of the table of contents, but do not know the specific contents of the table of contents. A use case represented only by graphical symbols cannot provide all the information of the use case itself, and the complete function of the use case must be described in text. In fact, the use case description is the main part of the use case, is an essential part of the subsequent interaction diagram analysis and class diagram analysis.

Use cases describe sequences of actions performed by the system when actors and software systems interact, so these sequences should contain sequences of actions for normal use (main event flow), but also sequences of actions for non-normal use of the software system (sub-event flow).

A simple use case description can be in the following format

Item description	instructions
Use case name	Withdrawals.
Use case description	To make cash available to the depositor if there is sufficient money in the depositor’s account and subtract the amount withdrawn from the depositor’s account.
participants	Depositors.
precondition	The depositor logs into the system correctly.
postconditions	Depositor’s account balance is adjusted.
The main flow of events	(1) The depositor selects the “Withdrawal” option on the main screen,Begin to use cases(The emergence of this word is important). (2) The ATM prompts the depositor to input the amount he/she wants to withdraw. (3) The depositor enters the amount to be withdrawn. (4) ATM confirms whether the depositor’s account has sufficient amount. If the amount is insufficient, the sub-event stream is executed`b` 。If there is a problem connecting to the host, an exception event flow is executed`e`. (5) THE ATM deducts the amount taken from the depositor’s account. An ATM provides its customer with cash to withdraw. (7) ATM machines print withdrawal certificates. (8) Enter the main interface. ATM machines offer the following options: deposit, withdrawal, inquiry and transfer.Use case ends(The emergence of this word is also important).
The child event flow`b`	B1. Prompt the depositor that the balance is insufficient. B2. Return to the main screen and wait for the customer to select the option again.
Flow of abnormal events`e`	E1. The depositor’s host is disconnected. E2. The system shuts down automatically, exits the customer’s bank card, and the use case ends.

A complex use case is mainly reflected in the excessive steps and parts of the basic operation flow and the optional operation flow. In this case, the technique of “scenario (or script)” can be used to describe the use case, rather than using a large number of parts and subsidiary flows.

Use case modeling

Use case models are mainly used in requirements analysis.

steps

Identify the actors and systems outside the system, determine the boundaries and scope of the system;
Determine the expected system behavior of each participant and the basic business requirements of the participant for the system;
Consider these system behaviors as basic use cases;
Prioritize use cases;
Refine the use case. Use generalization, inclusion, extension and other relations for processing;
Write use case descriptions for each use case;
Draw use case diagrams;
Write project vocabularies.

Determining system boundaries

System boundary refers to the boundary between systems. A system can be thought of as an organic whole formed by a series of interacting elements with specific functions. The parts that are not part of this organic whole can be considered external systems. Thus system boundaries define who or what actors use the system and what specific services the system can provide to the actors. System boundaries determine the actors.

In a fund trading system that only provides trading funds for trading clients, the participants are trading clients, and the trading clients can operate the system functions of buying funds and selling funds. Thus, the system has two use cases: buy fund and sell fund.

Further analysis found that the varieties of funds should exist in the system, otherwise trading customers can not carry out fund trading. However, neither of the two existing use cases in the system can complete the management of fund varieties, so it can be confirmed that the management of fund varieties should be completed in other systems.

So, we need to develop this system, and there are only two use cases: buy fund and sell fund.

Make an adjustment to Example 1. Trading clients can buy and sell funds in a fund trading system that provides both fund trading and fund variety entry. Because also need to fund variety management (input, modify, delete and query), by the fund company staff to operate. So the system’s participants are trading clients and fund company employees. System boundaries can be changed to look like the following:

How to identify participants

Who will use the main functions of the system?
Who will need systematic support to complete their daily tasks?
Who will have to maintain, manage, and ensure that the system works?
Who will provide information, usage information, and maintenance information to the system?
What hardware devices does the system need to handle?
Does the system use external resources?
Does the system need to interact with other systems?
Who is interested in the results produced by the system?

Issues needing attention:

All actors are external to the subsystem;
Participants interact directly with the system;
Actors refer to the roles they play when interacting directly with the system, rather than specific people or things. For example, instead of the PJ interacting with the academic administration system, the student interacts with the academic administration system;

How do you determine use cases

Identifying use cases can be done from scratch by looking at the list of actors listed, considering how each actor uses the system and what services the system needs to provide.

What functionality do participants request from the system?
What are the specific tasks of each participant?
Do participants need to read, create, undo, modify, and store some information about the system?
Does the participant have events that need to be notified to the system? Does the system have events that need to be notified to participants?
What functions do these events represent?
What I/O functions does the system require?
Are all functional requirements utilized by use cases?

Note the following issues:

Each use case has at least one actor;
At least one use case per participant;
If there is a use case with no actor and, upon double checking, still no actor, consider incorporating that use case into another use case;
If there is an actor who does not use a case and, upon re-examination, the actor still does not use a case, you can consider how the actor interacts with the system, or a new use case is identified by the actor, or in fact the actor itself is redundant.

Project vocabulary

This what ghost, have not seen, have not heard of……

Use-case package

Tweak the use case model

If two use cases are always activated in the same order, you may need to combine them into one use case.

Don’t be too specific

The design of the system is not considered in the use case description, so the user interface is not involved.

mo4tech.com (Moment For Technology) is a global community with thousands techies from across the global hang out!Passionate technologists, be it gadget freaks, tech enthusiasts, coders, technopreneurs, or CIOs, you would find them all here.

UML use case diagrams for doing things

An overview of object-oriented technology