Fundamentals of UML. Educational manual. Sholpan Jomartova

Чтение книги онлайн.

СКАЧАТЬ 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 СКАЧАТЬ