Fundamentals of UML. Educational manual. Sholpan Jomartova

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

      1. UML abbreviation means:

      a) uniform models of 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

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