Here are some questions that have been asked frequently in the UML world are: What is a use case diagram? Why Use case diagram? or simply, Why use cases?. Some people don't know what use case is, while the rest under-estimated(译:低估) the usefulness of use cases in developing a good software product. Is use case diagram underrated(译:低估)? I hope you will find the answer when finished reading this article.
So what is a use case diagram? A UML use case diagram is the primary form of system/software requirements for a new software program under developed. Use cases specify the expected behaviour (what), and not the exact method of making it happen (how). Use cases once specified(译:说明) can be denoted(译:表示) both textual(译:原文) and visual representation (such as UML). A key concept of use case modeling is that it helps us design a system from end user's perspective. It is an effective technique for communicating system behavior in the user's terms by specifying all externally(译:外表) visible system behavior.
A use case diagram is usually simple. It does not show the detail of the use cases:
It only summarizes some of the relationships between use cases, actors, and systems.It does not show the order in which steps are performed to achieve the goals of each use case.As said, a use case diagram should be simple and contains only a few shapes. If yours contain more than 20 use cases, you are probably mis-using(译：误用) usecase diagram.
The figure below shows the UML diagram hierarchy(译:层级) and the positioning of UML Use Case Diagram. As you can see, use case diagrams belong to the family of behavioural diagrams.
Note that:
There are many different UML diagrams that serve different purposes (as you can see from the UML diagram tree above). You can describe those details in other UML diagram types and documents, and have them be linked from use cases.Use cases represent only functional requirements of a system. Other requirements such as business rules, quality of service requirements, and implementation constraints must be represented separately, again, with other UML diagrams.
These days use case modeling is often associated with UML, although it has been introduced before UML existed. Its brief history is as follow:
In 1986, Ivar Jacobson first formulated textual and visual modeling techniques for specifying use cases.In 1992 his co-authored book Object-Oriented Software Engineering - A Use Case Driven Approach helped to popularize the technique for capturing functional requirements, especially in software development.Use case diagrams are typically develop in early stage of development and people often apply use case modeling for the following purposes:
Specify the context of a systemCapture the requirements of a systemValidate a systems architecture(译:架构)Drive implementation and generate test casesDeveloped by analysts together with domain expertsA standard form of use case diagram is defined in the Unified Modeling Language as shown in the Use Case Diagram example below:
Notation DescriptionVisual RepresentationActor
Someone interacts(译:交互) with use case (system function).Named by noun.Actor plays a role in the businessSimilar to the concept of user, but a user can play different rolesFor example: A prof. can be instructor and also researcherplays 2 roles with two systemsActor triggers use case(s).Actor has responsibility toward the system (inputs), and Actor have expectations from the system (outputs).Use Case
System function (process - automated or manual)Named by verb + Noun (or Noun Phrase).i.e. Do somethingEach Actor must be linked to a use case, while some use cases may not be linked to actors.Communication Link
The participation(译:参与) of an actor in a use case is shown by connecting a actor to a use case by a solid link.Actors may be connected to use cases by associations, indicating that the actor and the use case communicate with one another using messages.Boundary of system
The system boundary is potentially(译:可能地) the entire system as defined in the requirements document.For large and complex systems, each modules may be the system boundary.For example, for an ERP system for an organization, each of the modules such as personal, payroll, accounting, etc.can form a system boundary for use cases specific to each of these business functions.The entire system can span all of these modules depicting the overall system boundaryUse cases share different kinds of relationships. Defining the relationship between two use cases is the decision(译:决定) of the software analysts of the use case diagram. A relationship between two use cases is basically modeling(译:建模) the dependency(译:依赖) between the two use cases. Reuse(译:重用) of an existing use case by using different types of relationships reduces the overall effort required in developing a system. Use case relationships are listed as the following:
Use Case RelationshipVisual RepresentationExtends
Indicates that an "Invalid Password" use case may include (subject to specified in the extension) the behavior specified by base use case "Login Account".Depict(译:描述) with a directed arrow having a dotted line. The tip of arrowhead points to the base use case and the child use case is connected at the base of the arrow.The stereotype "<<extends>>" identifies as an extend relationshipInclude
When a use case is depicted as using functionality of another functionality of another use case, this relationship between the use cases is named as an include or uses relationship.A use case includes the functionality described in another use case as a part of its business process flow.A uses relationship from base use case to child use case indicates that an instance of the base use case will include the behavior as specified in the child use case.An include relationship is depicted with a directed arrow having a dotted line. The tip of arrowhead points to the child use case and the parent use case connected at base of the arrow.The stereotype "<<include>>" identifies the relationship as an include relationship.Generalization
A generalization relationship is a parent-child relationship between use cases.The child use case in the generalization relationship has the underlying business process meaning, but is an enhancement(译:增强) of the parent use case.Generalization is shown as a directed arrow with a triangle arrowhead.The child use case is connected at the base of the arrow. The tip of the arrow is connected to the parent use case.A Use Case diagram illustrates(译:说明) a set of use cases for a system, i.e. the actors and the relationships between the actors and use cases.
The include relationship adds additional(译:附加的) functionality not specified in the base use case. The <<Include>> relationship is used to include common behavior from an included use case into a base use case in order to support re-use of common behavior.
The extend relationships are important because they show optional(译:可选的) functionality or system behavior. The <<extend>> relationship is used to include optional behavior from an extending use case in an extended use case. Take a look at the use case diagram example below. It shows an extend connector and an extension point "Search".
A generalization relationship means that a child use case inherits the behaviour and meaning of the parent use case. The child may add or override the behaviour of the parent. The figure below provides a use case example by showing two generalization connectors that connect between the three use cases.
The figure below shows a use case diagram example for a vehicle systems. As you can see even a system as big as a vehicle sales system contains not more than 10 use cases! That's the beauty of use case modeling.
The use case model also shows the use of extend and include. Besides, there are associations that connect between actors and use cases.
Often, people find it easiest to start the requirements elicitation process by identifying the actors. The following questions can help you identify the actors of your system (Schneider and Winters - 1998):
Who uses the system?Who installs the system?Who starts up the system?Who maintains the system?Who shuts down the system?What other systems use this system?Who gets information from this system?Who provides information to the system?Does anything happen automatically at a present time?Identifying the Use Cases, and then the scenario-based elicitation process carry on by asking what externally visible, observable value that each actor desires. The following questions can be asked to identify use cases, once your actors have been identified (Schneider and Winters - 1998):
What functions will the actor want from the system?Does the system store information? What actors will create, read, update or delete this information?Does the system need to notify an actor about chances in the internal state?Are there any external events the system must know about? What actor informs the system of those events?Now, check the tips below to see how to apply usecase effectively in your software project.
Always structure and organize the use case diagram from the perspective of actors.Use cases should start off simple and at the highest view possible. Only then can they be refined and detailed further.Use case diagrams are based upon functionality and thus should focus on the "what" and not the "how".Use case granularity refers to the way in which information is organized within use case specifications, and to some extent, the level of detail at which they are written. Achieving the right level of use case granularity eases communication between stakeholders and developers and improves project planning.
Alastair Cockburn in Writing Effective Use Cases gives us an easy way to visualize different levels of goal level by thinking in terms of the sea:
Note that:
While a use case itself might drill into a lot of detail about every possibility, a use-case diagram often be used for a higher-level view of the system as blueprints.It is beneficial to write use cases at a coarser level of granularity with less detail when it's not required.I hope you can answer "what is use case diagram" now and can apply use case in your project. If you want to learn more about other UML diagram types, please check the UML guide: Overview of the 14 UML Diagram Types.
原文地址：https://online.visual-paradigm.com/tutorials/use-case-diagram-tutorial/
参考这篇译文：https://blog.csdn.net/chktsang/article/details/79698115
用例图参考案例：https://online.visual-paradigm.com/diagram-examples/use-case-diagram/
