Читать книгу Fundamentals of UML. Educational manual - Sholpan Jomartova - Страница 2

Usе Casе Dіagram

Brief content:

Content precedents

Usе Casе Dіagrams

Levels precedents

Precedents and opportunities (or suggestions)

Content precedents

Precedents – atechnology for determining the functional requirements for the system. The work is unprecedented in the description of typical interactions between the users of the system and the system itself and provide a description of its functioning.

Scenario (scenarіo) – asequence of steps that describe the interaction between the user and the system. In the on-line shop can be a scenario of «Buying goods» (Buu a Product), in which the following occurs:

The buyer browses the catalog and place the selected products in the basket. If you wish to pay for the purchase, he enters credit card information and make payment. The system checks the authorization of a credit card and confirms the payment for the goods by email.

This scenario describes only one situation which may occur. However, if credit card authorization fails, then this situation can serve as the subject of a different scenario. In another case, a purchase can make a regular customer for which the verification of purchase information and credit card is optional, and it will be the third scenario.

One way or another, but all of these scenarios are similar. The bottom line is that in all three scenarios, the user has the same goal: to buy goods. Users can not always do it, but the goal remains. That is the goal of the user is the key to the case law precedent is a set of scenarios, united by a common goal.

In terms of precedent users called actors. Actor (actor) is a kind of role played by the user to the system. Actors can be a user, user sales representative, sales manager and merchandiser. Actors acting in the precedents.

One actor can perform several precedents; and vice versa, according to the precedent one can operate several actors. Usually, a lot of customers, so the client can play the role of many people. In addition, one person can play several roles, such as sales manager, acting as a sales representative for the client. The actor does not have to be a man. If the system does not provide the service that the other computer system, the other system is an actor.

In fact, the actor – notthe right term; perhaps the term role (role) would fit better.

There is no standard way to describe the contents of a precedent; in different cases, use different formats. Below is the overall style of use. Usually begins with the selection of one of the scenarios as the main success scenario (maіn success scenarіo). First, a body of precedent, in which the main success scenario is a sequence of numbered steps. Then takes another script and inserted into an extension (ehtensіon), describing it in terms of changes in the main success scenario. Extensions can be successful – auser has reached his goal, as is the case 3a, unsuccessful, or, as in the embodiment 6a.

Each has a precedent leading actor that sends a service request system. Lead actor – anactor, a desire which tries to satisfy a precedent which is usually, but not always, is the initiator of a precedent. At the same time there may be other actors with which the system also interacts during precedent. They are called secondary actors.

Each step in the precedent – anelement of interaction between the actor with the system. Each step should be a simple statement and should clearly state who perform this step. Step should demonstrate the intention of the actor, not the mechanics of his actions.

Expansion within the precedent indicates a condition that leads to interactions other than those described in the main scenario is successful (success maіn scenarіo, MSS), and determines what those differences. Extension name begins with the step at which it is determined by the condition, and provides a brief description of this condition. The steps are numbered in the same manner as in the main successful scenario. Terminate these steps return to the description of the main points of a successful script, if necessary.

The structure of a precedent –it's a great tool for finding alternatives to the main success scenario. At each step, you need to ask questions: «What else can happen?» And, in particular, «What could go wrong?» Is usually better to first explore all possible conditions for the extension, so you do not get bogged down in the quagmire of the work on the consequences. Thus, it becomes possible to consider more conditions that lead to fewer mistakes which then have to catch.

The complex step in the precedent can be represented by another precedent. In terms of language UML said that the first case involves (іncludes) second. There is no standard way to show in the text of the inclusion of a precedent, but underline that suggests a hyperlink, works well, and in many tools really is a hyperlink. Thus, in the example above, the first step includes a template «scans the directory and selects items to purchase».

Included precedents may be useful in case of complex steps, which otherwise would clutter the main scenario, or when the same steps are present in several scenarios. However, it is better not to try to break precedents in the podpretsedenty and use them for functional decomposition. This decomposition is – agood way to lose a lot of time.

Along with the steps, you can insert the script in case additional general information.

– Precondition (pre-condіtіon) describes the actions always follow the system before it is allowed to start operation precedent. This is useful information that enables developers to not check some conditions in their program.

– Warranty (guarantee) describes the binding of the system at the end of the work the template response. Successful guarantee executed after a successful scenario; the minimum guarantee executed after any scenario.

– Trigger (trіgger) defines the event that triggers the execution of a precedent.

When considering additional elements better to do too little than too much.In addition, it is recommended to apply every effort to make a precedent concise and easy to read. Needless detailed precedent that is difficult to read, mostwill lead to failure, than to achieve the goal. It is not necessary to record all the details.

The level of detail required in the precedent, dependent on the level of risk that precedent. Most parts are needed in the beginning only a few key use cases, you can specify the other just before their implementation.

Usе Casе Dіagrams

The UML is silent about the contents of a precedent, but is a chart format, allowing it to display (Figure 2). Although the diagram is sometimes useful, you can do without it. When developing a precedent should not make a lot of effort to create the chart. Instead, focus on the text content of precedents.

It is best to think about case diagram using the graphical table showing the contents. She recalled the context diagram used in the structural method because it shows the boundaries of the system and its interaction with the outside world. Use case diagram shows the actors, use cases, and relationships between them:

– Which actors perform a particular precedent

– What are the precedents include other precedents

The UML apart relationship «іnclude», there are other types of relations between use cases, such as the ratio of «ehtend». Strongly recommends to avoid it. Too often, entire teams of developers for a long time immersed in the consideration of the various relationships between use cases, unnecessarily wasting power. It is better to pay more attention to the textual description of a precedent.

Figure 2. Usе Casе Dіagram

Levels precedents

A common problem is that precedents that carried away by the user's interaction with the system can not draw attention to the fact that the best way of resolving the problem can be a change of the business process. You can often hear reference to the precedents of precedents and business processes. Of course, this terminology is not accurate, but it is generally considered that the precedent system (sustem use case) describes the features of the interaction with the software, while the precedent of the business process (busіness use case) is the reaction of the business process in the action of the client or an event.

Often used next level diagram of precedents. The base case is to «sea level». Precedents level «sea» (sea level) are usually separate and lead actor interaction system. These precedents provide leading actors any useful result and usually take from a couple minutes to an hour. Precedents exist in the system, if they are included in the precedents level «sea», called precedents level «fish» (fіsh level). Precedents of the highest level, the level of «kite» (kіte level) show how precedents sea levels are set to greater interaction with business processes. Usually precedents level «kite» is a precedent of business processes and at the level of the «sea» and at the «fish» are precedents system. Most precedents should belong to the level of «sea». The level can be specified at the beginning of a precedent, as shown in the example above.

Precedents and opportunities (or suggestions)

Many features of the system approaches are used to describe the system requirements; extreme programming (Ehtreme Programmіng) capabilities of the system are referred to the wishes of the user. A common question is how to establish a correspondence between features and use cases.

Use possibilities – agood way to divide the system into blocks when planning an iterative process, whereby each iteration provides a certain number of features. Hence, although both receiving describe requirements, their goals are different.

Describe the features can be at once, but many experts feel more comfortable in the first place to develop use cases, and then to generate a list of options. The possibility can be represented by a precedent to precedent scenario, a step in precedent or in any behavior, such as adding another method of calculating the depreciation in the assessment of the property, which is not listed in the description of the precedent. Usually opportunities are more clearly defined than the precedents.

When applicable precedents

Precedents are a valuable tool for understanding the functional requirements of the system. The first version of precedents must be drawn up at an early stage of the project. A more detailed version of precedents should appear immediately before the implementation of this precedent.

It is important to remember that use cases represent the view of the system from the outside. Therefore, the correspondence between classes and use cases within the system usually does not happen.

The more the precedent, the less valuable it becomes case diagram. Despite the fact that in the language of the KMT says nothing about the text precedents, namely the text content of precedent is a basic value of this technology.

Most dangerous precedent is that the developers make them very complex and stuck to them. In the presence of a small amount of information it received a short, easy to read document that will be the starting point for questions. If too much information, it is unlikely that someone will do it to study and try to understand.

1. Symbol of a precedent is:

a) line;

b) directed segment;

c) human figure;

d) oval containing text.

2. An actor can only be a human:

a) true;

b) false.

3. A symbol indicating dependency relationship:

a) a line;

b) a line with a triangle pointing to the dependent element;

c) a dotted line with an arrow pointing to dependent element;

d) a dotted line with an arrow pointing to element on which other elements depend.

4. A stereotype of the attitude is shown:

a) as text in angle quotes;

b) as plain text near the line of relationship;

c) as word <<stereotype>> inside an oval.

5. <<Include>> stereotype is used to indicate reuse of functionality, modeled with another precedent:

a) true;

b) false.

6. <<Extend>> stereotype is used to model additional system functions:

a) true;

b) false.

7. Generalization in the UML is implemented as:

a) polymorphism;

b) aggregation;

c) inheritance;

d) interfaces.

8. Each function of a system should be shown as a precedent:

a) true;

b) false.

9. In <<extend>> stereotype extension arrow points to:

a) a base use case;

b) expansion use case.

10. It is important to implement simple use cases first in order to ensure successful completion of initial stages:

a) true;

b) false.