Summary of Use case analysis techniques

Turn from: http://blog.csdn.net/icu/archive/2006/03/07/617638.aspx preface

Now that RUP is at its zenith, demand analysis is the first step and can be seen as a prerequisite for advanced system analysts, so if you use object-oriented analysis techniques to describe the requirements.

In a demand analysis process, there are project descriptions, risk analysis, use case diagrams, and descriptions, which are part of the project recommendations.

One of the most important, and most need to learn, is the use case description. So where is the key point of the use case description? Determining system Boundaries

Identifying clear system boundaries is about determining what is in the system. What's outside the system. The system boundary is determined by the performer and use case.

So, our first step is to find the performer, the executor is a role, we can think about the following several questions to decide: Who is using the system. Who is maintaining. Who's starting? Who's shutting down. Who gets information from this system. Who provides information for this system. Is there an automatic thing that happens in the expected time. And so on, to determine the performer.

Identify the performer, it is necessary to determine the use case, the use case is a system of behavior, for the performer to produce measurable value results.

The use case description is generally a verb noun structure.

It is necessary to construct a table that clearly defines the use case and the performer in the form of a noun interpretation.

If the use case diagram is too large, then separate or take the form of a package.

The arrows in the use case diagram indicate one-way or two-way, depending on the information being delivered.

If it is an external timing event, you can take the time as a performer.

Requirements are within the system and cannot be seen by the performer, so this requirement is not reflected in the use case diagram. Archive Use Cases

The archive use case is to represent the use case in the form of a document. The basic use cases mainly include: preconditions (preconditions are when the use case starts, must be in what state) the post condition (the end of the use case, the system in what state) event flow. (The event stream is a series of statements).

The event stream contains some loop statements. You can use a for, while loop.

A use case is a communication tool that works only when the reader communicates how the system works.

Use cases are written from the standpoint of the performer.

The requirements for non-event streams can be described in the special requirements of the use case.

The event flow is divided into two parts: a basic path and an optional path.

All normal operation is the basic path.

A path that is different from the base path and allows the selection of different sequence of events, is an optional path, or the handling of various exception cases is also an optional path.

Optional path, preferably marked with a different paragraph number.

What is a scene. A scene is a specific path through a use case.

Inclusion of Use cases: if you find that you want to copy the same part of the content frequently when writing various use cases, then you have a part of the common behavior, then you can use a containment relationship to abstract this common behavior. Include use cases must have included use cases, this use case is complete.

Extension of use case: increase the behavior of the use case without changing the original use case. One of the key concerns is that the extension point, when it reaches this extension point, if the condition is true, is that the precondition of this extension is true, the step of this extension will be executed.

Inheritance of Use cases: the inheritance of use cases represents one use case (child) as a special implementation of another use case (parent), and the executor's inheritance means that one performer (child) can accomplish the task of another performer (parent).

Interfaces: Interfaces are not part of the performer and use cases. An interface is a description of the interaction between the performer and the use case.

Text in the document can be a concise description of the system, then some of the text branches a lot of time, the use of graphs is a very good way, graphical use cases are also a good means. We can use three kinds of graphs to refine and materialize use cases.

Activity diagram: A step that describes a use case. Activity diagrams describe the activities and relationships between activities that meet the needs of a use case. (Some books define the activity diagram as a subset of the state diagram)

Timing diagram: Describes the interaction between the performer and the system. In a time series diagram, each entity has a dashed line below it, representing the object life cycle. The return value of the acknowledgment is indicated by a dashed arrow.

After learning to write use cases, there is a question, how well can the use cases be written? Is the use case refinement to what extent is good. To answer this question, there are three questions to consider: Who needs to read and approve the document. Who needs to use this document. What we want to do with this document. Use cases may be for end users and developers, or managers, and deciding how much detail to put into use cases is a very important thing. Can be the same use case to do different levels of detail of the version, to different people to see, pay attention to maintain this correspondence relationship.

Use case Document Template:

Includes system introduction, risk factors, system-level use cases (one or more diagrams that reflect all use cases and performers in the system, no need to include relationships between use cases, such as include, extend, and generalize), architecture, sub-use cases, non-functional requirements including availability, system, security, persistence, redundancy, performance, scale, standardization and so on.

You can use activity diagrams to describe and represent the relationships and processes between use cases.

dividing large systems:

If you are making a large system, it is very important to divide the large system into small systems. Select the most important part of the system first. The main architectures are as follows:

An MVC structure, a layer used to show, a layer for control, a layer for data storage. For example, Jsp,struct is the architecture.

Second, pipeline and filter system structure. The main idea is that a part of the input data, processing the data, then output, the next section receives, processes, and so on, such as Freeradius,jradius is this architecture.

Thirdly, the object-oriented architecture pattern. The system is defined according to the data and is associated with various functions. The use case validation architecture can be used, and each subsystem should have:

---a single function

---strong polymerization---each of its parts has a strong correlation with each other

----Loose COUPLING---the completion of its work is less dependent on other subsystems

There is no significant communication between----and the minimum communication----subsystem of other subsystems.

The operations in the interface are from the time series diagram. Each subsystem is considered as a whole system, and each system has performers and use cases. Constantly divide the large system into small systems, when the system is small enough, there is no need for more division there is enough detail to achieve.

Topic Summary: A topic summary refers to what we use or work with in use cases. is to create a basic element of the system, which is a way to describe the domain. A simple way to find a topic summary is to find the entity or data used. By using the time series diagram to draw the scene, the system object can be replaced by the topic summary, the subsystem is also replaced by a system summary, so that the message sent to the subsystem is sent to the topic summary and performer information, and most importantly to determine the behavior of the topic Summary, determine the topic summary and their behavior, the design of the class lay the foundation.

Through the time series diagram, we find the topic summary, we can find the summary must make the corresponding message, and then the message to participate in the use case class, participate in Class View is to tell us what classes to develop.

The use case tries to show the workflow in the system and is the basis of the black box test and User Guide.

The subsystem view shows the subsystems that make up the system and is the basis of system reuse and maintenance.

The use Case view is a presentation of the system's appearance, and only the system view shows the subsystems that make up the system, one from the customer perspective and one from the development perspective.

Usually the first iteration deals with the highest risk, and the second iteration deals with the secondary risk. using use cases to estimate work:

1. Weighted by the performer

Performer Type	Describe	Factor
Simple	Program Interface	1
Ordinary	Interaction and protocol-driven interfaces	2
Complex	(Graphics interface	3

2. Use case weighting:

Use case type	Describe	Factor
Simple	Up to 3 transactions with a maximum of 5 analysis classes	5
Ordinary	4-7 transactions, 5-10 analysis classes	10
Complex	More than 7 transactions, more than 10 analysis classes	15

The concept of a transaction here is a path, including an optional path, which is a set of atomic operations.

An unadjusted use case point (UUCP) is obtained by adding the weighted total of the use case to the weighted total of the performer.

3, Technical factor weighting: the complexity of the calculation project technology, can take advantage of the technical complexity factor. The rank of each factor is determined from 0 to 5. 0 rank means that this factor is not related to the project, and 5 represents it as the most important. Then use the factor to multiply the weights of each factor and add them.

Factor number	Factor description	Weight
T1	Distributed system