The use case diagram of system analysis and design

The need for each product is a description of a specific problem in the real world, and some of the problem descriptions can be very intricate, so that when we analyze it, we feel we are not able to do it or even get overwhelmed.

Demand analysis is the basis of system design and development, the quality of demand analysis will directly affect the subsequent design and development, the serious impact on the success of the system. The use case diagram in UML is to facilitate our analysis and exchange of product requirements, but also for our product needs to translate into system requirements to facilitate.

Product requirements: Generally reflect the specific phenomenon on the spot, often by the product engineer/sales staff to collect or directly provided by users, the performance of the relatively loose, extensive, is a more realistic description.

System requirements: In general, after a certain analysis of product requirements, on which can not be realized or difficult to achieve the part of a certain trade-offs, at the same time, some of the more general requirements for clarity and refinement, and even some of the needs of a certain abstraction and reorganization. Some logic descriptions (i.e., abstract terms outside of reality) are sometimes incorporated into specific applications, which are more relevant to the software system. Generally after the review, the system requirements will be "Product requirements Specification said ," the way to provide, and become the scope of the system development basis.

Next I will introduce myself in the use case analysis process of some experience and recess.

first, "Somebody Do something" mode

When we analyze requirements, we can look for use cases/key use cases in the "Somebody do something" pattern, of course, where "somebody" can refer to people, things or other systems. We can "do something" as a use case, and then become a function of the system, that is, to meet a little demand. If we can do all the things, then our system will become.

Second, use case analysis should pay attention to matters

1, single scene, that is, each use case only to illustrate one thing, I personally oppose the all-encompassing "God" use cases.

2, simple principle, that is, every use case to be easy to understand, can be very clear, concise description of its function and function, without any ambiguity and superfluous imagination space.

3, uniqueness, that is, every thing/scene can only appear once, if other places to use the same scene can be used in the "reference" way to combine.

three, divide and conquer all the thought of breaking

1, N-Order problems

In the interview with the new staff, I usually ask a "Hanoi" problem, in the process I do not value the answer, only the way to solve the problem. That is, how to turn the "N-order problem into the N-1 order and finally become the problem of the 1 order" in recursion.

In fact, demand analysis is also a complex n-order problem, the final transformation into a 1-order problem process, this method from N to 1 not only in the demand analysis can be used, in fact, in other subsequent design is also very useful.

2. Top-down or bottom-up

Analysis of requirements we can use top-down or bottom-up analysis, I believe these people have heard, not to do in detail. Personally, I like the "top-down" approach to analysis, that is, from the "macro" to "micro" process, in fact, a bit like our task decomposition in the WBS decomposition method.

Apply "single scene", "Simple Principle" and "uniqueness" one by one to the scenarios described in the requirements and to the problems to be solved to meet the requirements.

Take our "Musicstore" project, the system is nothing more than "system to sell records" (of course, the demand is a bit simple), but to meet this requirement, we have to provide "the administrator to provide records" and "Customers buy records" and other functions. And so "administrator-provided recordings" may cause new features such as "Administrator-Created records," "Administrator-Modified albums," and "Administrator-deleted album materials", as well as "Customers who buy records" that may cause "customers to add records to the cart", "Customers to remove records in the cart" and "Customer Checkout" and other features. So again and again, we end up with the requirement that we can provide the "single scene," "Simple Principle," and "uniqueness" as a function that the user wants. If so, then our analysis process is basically the end, the reason is that the end, is because some complex needs only to analyze its appearance is far from enough, but also to stand in a higher overall perspective to further examine, may also have to be a certain reorganization or even abstraction, until the requirements of the system to meet, We will have a follow-up example.

3. Borders and Commissions

Boundary, in the scenario where the requirements are defined, there are some scenarios in which they work in a similar way and have a relatively close relationship with each other, so these use cases can form a relative closed interval, which is the use-case boundary.

Sometimes we also distinguish different boundaries according to different actors.

For example: "The administrator creates the record material", "the administrator modifies the record material" and "the administrator deletes the record material" may think is "manages the record material" such a boundary.

Since VS2010 does not provide boundary functionality, it is provided in subsystem. In order to better explain the problem so there are 2 pictures here, and the second one is drawn by the EA.

Sometimes we abstract a use case with relative cohesion within the same boundary as a use case.

, when it comes to use case analysis, when some use cases have gone beyond the current boundary, but have a close relationship with some use cases within the boundary, we can often consider the way of "entrusting" to simplify the analysis process.

Take the "Customer checkout" use case, it may trigger a "System query account Balance", "system Transfer" and a series of new use cases come out. At this point we may appear, in fact, my purpose is "checkout", as to how to checkout and checkout details is not my main topic in this scenario, it may be possible to determine "query account balance" and so on beyond the boundaries of this use case, so that we can "entrust the way" delegated to "UnionPay system payment", thus a stroke.

Sometimes we can simply assume that "service" is a delegate outside the boundary.

in the analysis we can not care about how the elephant put into the refrigerator, only care about the elephant can put in the refrigerator.

(This image is from the Internet)

4, the utilization of "Include" and "Extend" and "generalization"

The application of "include", "extern" and "generaliztion" is indispensable in the analysis of the use of regular meetings.

Include: mainly refers to the inclusion of these use cases, including does not refer to the child use case is bound to occur at the same time.

For example: Management and management of record information added album information Modify record information Delete record information Export album information

Extend: means that a use case must be triggered when a situation is satisfied.

Customer checkout triggers the sign in use case when not signed in.

The VS2010 provides extension points functionality because it is not found. In order to better explain the problem so there are 2 pictures here, and the second one is drawn by the EA.

Generaliztion: Generalization, in the use Case view I usually only use the actor above, in the actual use case is used less.

"Descriptive" of the system use case diagram

1. Do not "mesh"

Many people like to analyze all the use cases with a picture to show, small system Fortunately said, the system becomes a spider web, messy, I personally suggest try not to "mesh" use case diagram, so I do not know where to look.

2, the level of expression

In a multi-layered way to gradually refine the use case, from large to small, from the global to local layers of refinement. This is similar to the root and leaf way, in the subsequent subsystem analysis, sub-module analysis also greatly help.

3, cohesion

If the level is a vertical representation, then cohesion is a horizontal representation. It is generally used to plan for some more complete scenario processes. For example, our "Management record material" is a more cohesive performance, of course, cohesion of the thickness of the granularity can be combined with specific projects to decide.

4. Different primary and secondary

In the system use case diagram, and not necessarily all the use cases are all included, in the description and solve the problem, we actually most use case relationship only need to introduce the main use cases. If there is a "net" phenomenon, it makes the effect even more counterproductive.

5, gradually improve

Each system use case diagram is difficult to provide one step, many of the time is a gradual improvement of the process, some of my participation in some of the projects have been after several rounds of iteration before the basic stability.