Fundamentals of UML. Educational manual. Sholpan Jomartova

language;

      b) Unified Modeling Language;

      c) unitary language for mock-up;

      d) unified template language.

      2. The UML is used only for software modeling:

      a) yes;

      b) no.

      3. The process most closely associated with the UML language is called:

      a) modeling process;

      b) Rational Unified Process;

      c) Extreme Programming;

      d) Agile method.

      4. Standardization Group, which approved the UML, is called:

      a) Unified Modeling Group;

      b) Object Modeling Group;

      c) Object Management Group;

      d) The Four Amigous.

      5. Use case diagrams are used to create macro description of a system:

      a) yes;

      b) no.

      6. Class diagram is a dynamic system of model's classes:

      a) yes;

      b) no.

      7. Good UML model contains at least one of each diagram type:

      a) yes;

      b) no.

      8. Sequence diagrams differ from collaboration diagrams with … (choose all that apply):

      a) sequence diagrams are interaction diagrams, and collaboration diagrams are not;

      b) sequence diagrams represent events in time; collaboration diagrams represent classes and messages without time ordering;

      c) time sequence is specified by assigning numbers to sequence diagrams;

      d) nothing from above.

      9. A group of scientists, most closely associated with creation of the UML, has a nickname:

      a) «Gang of Four»;

      b) «The Three Musketeers»;

      c) «Three Comrades»;

      d) «Dynamic duo».

      10. Activity diagrams are suitable for displaying object state unlike use case diagrams:

      a) yes;

      b) no.

      CHAPTER № 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