What happened to the use case model: use case diagrams

--A useful discussion on use-case model and its application

This is a discussion of use case model. How to build a use case model, how to write a use case description, what is the difference between it and the requirements specification, can it replace the requirement specification? Maybe here you can find the answer you want.

Enter the software industry a little longer than the people I am afraid will not be unfamiliar, the initial stage of software development is to talk about demand, write requirements specifications. The requirement specification is a very formal official document with the customer's final confirmation to the paper. What the software development should do, what to do, what not to do, how wide the scope of the project, requirements specifications are written clearly in black and white, who can not deny. Therefore, the requirement specification has always been an important accessory of software project development contract, and its status is very important.

But with the introduction of RUP, people are beginning to get confused. There is no requirement specification in RUP, but instead of a use case model. Now, some companies that are in the forefront of informatization are demanding to develop in accordance with the RUP unification process, and we are also beginning to try to use use case models to replace requirements specifications. However, I believe that some of the important questions about the use-case model have puzzled a lot of people (including me, of course): What is the difference between a use case model and a requirement specification? Where is the advantage of the use case model? Can the use case model replace the requirement specification? We have a tour of the use-case model around these issues.

Before I begin my discussion trip, we'd better take a question to explore:

What is the difference between a use case model and a requirement specification?

When you see this, you may be very dismissive and think that this question is not worth mentioning. Indeed, the difference between the use case model and the requirement specification is obvious in the format of the writing. But, from a deeper level of discussion, you will find that the problem is not that simple. Some people because of the superficial understanding of the use case model, the use case model as a requirement specification to write, format, although the format of the use case model, content is not the use Case model content, the other is self-defeating, confusing. The requirement specification is the product of the process-oriented era, so its core is to write the demand according to the process-oriented design idea; The use-case model is the product of object-oriented analysis/design, so its core idea is ooa/d (object-oriented analysis/design). I think it is too important to grasp this point. Understand it in order to understand how the use-case model should be designed in order to understand its differences with the requirements specification, in order to understand its role and advantages. Next, let's look at how the use case model should be designed.

How to build a use case model

Some beginners think that the use-case model is a picture of a use case diagram. In fact, this is wrong, use case models include use case diagrams, use case descriptions, and sometimes some simple action diagrams, state diagrams, and sequence diagrams. Use-case diagrams graphically show the relationships between use cases, participants, and system boundaries. A use case description is a detailed description of the use case, the participant, and the system boundary. In the description process, some key processes, as well as the state changes of key classes in these processes, can be graphically demonstrated using action diagrams, state diagrams, and sequence diagrams.

A Use case diagram

A use case diagram is the beginning of building a use case model. The process of building a use case model is usually to draw a use case diagram and then to write a use case illustration of a used case diagram. When writing use case descriptions, create action diagrams, state diagrams, and sequence diagrams to facilitate reading of the reader's understanding of some complex and deemed necessary places. A use case diagram focuses on three things: use cases, participants, and system boundaries.

1. Use Cases

A use case is a set of scenarios that describe how a participant uses the system to achieve its goals. This sounds abstract, but I usually take it for a while as a module in a function (although it's not tight but more practical). A use case emphasizes a set of scenarios in which there are few but functional commonalities between the groups, like multiple sub modules under a large functional module. Each of these sets of scenes forms a child use case, respectively. Sub-use cases can be subdivided, and the respective child cases may be formed. Use case analysis is such a gradual subdivision from coarse to fine to form a system's use case diagram. Use case diagrams are analyzed to a finer extent and should be determined by the circumstances of the business requirements. Too thick, it is not enough to explain the relevant details of the business, or to make a use case diagram information too much, affect people's understanding, the minute, not only will increase the workload, but also lose a lot of use cases of the relationship between the loss of the candle. In short, the more complex parts of the thin, simple part of the thick, to ensure that each use case diagram to maintain a strong correlation, to guide the future functional division.

At the same time, the use case emphasizes interaction between the participant and the system function, and the use case is the function of the system, and the participant can be temporarily understood as the person who uses the system. Therefore, most use cases correspond to one or more participants (but some of the child cases that are included in the use case, or the extended use cases that extend out) are not participants.

There are usually two relationships between use cases and use cases: inclusion and extension. A include relationship represents a dependency relationship, that is, a child case is a relatively independent part of the main use case that must be invoked. In use-case analysis, we should extract the relatively independent functions that are common to multiple use cases to form a child use case to provide a strong guarantee for future code reuse. An extended relationship means that a function is an extension of another function, that the extended function does not necessarily invoke the extended function, but that the extended function is the extension and extension of the extended function. When drawing a use case relationship, the containing relationship should be drawn as a dashed arrow pointing to the child case from the main use case and labeled "include", which means that the main use case contains a child case; the extension relationship should be drawn as a dashed arrow from the extended use case to the extended use case and labeled "Extend Indicates that the extension use case is an extension of the extended use case. The dashed arrows represent a dependency in UML that the customer element understands the provider and that the changes in the supplier affect the customer element (dependency is directed from the customer element to the supplier).

Encapsulation is one of the important ideas of object-oriented design. One of the prerequisites for the implementation of encapsulation is to classify the functions on the basis of the requirements, so that the functions with strong correlation are divided together, and only a few interfaces interact with the outside world. Use case analysis, from the outset of the original requirements of the functional division, the related functions are divided together, the common function to extract, indicating that the dependencies between the function and non-dependency relationship (including a representation of a dependency, and extension represents a dependency). This is a ooa/d that provides strong support for future OO design. These are the requirements specifications do not have, or not fully specific functions.