[Skip Navigation] [CSUSB] / [CNS] / [Comp Sci Dept] / [R J Botting] / [Samples] / uml2
[Index] [Contents] [Source Text] [About] [Notation] [Copyright] [Comment/Contact] [Search ]
Tue Sep 18 15:27:23 PDT 2007

Contents


    UML Dynamic Models

      Introduction

      This is one a part of a set of notes on the Unified Modelling language -- [ uml.html ]

      Scenarios and UseCases

      Scenarios and Use-Cases are an ideal place to start a project. They must be expressed in terms that the user and client understands and can (and should) avoid all technical jargon. The set of usecases answer the questions:
      1. Who wants to use this software?
      2. What do they want to do with it?

      A scenario describes a particular user getting something useful done. A usecase is a set of similar scenarios all with the same type of user and all ending when the user finds out that the process is complete. The user must begin a usecase and must know when it is complete. The user must be active entity - an actor - and communicates with the system to achieve the goal of the usecase.

      A usecase is written out in a natural language like English. UML provides a notation for naming and classifying both actors and usecases. Here is a UML diagram that shows three usecases: "add class", "drop class", "get roster", and "submit work" and two actors: "Student" and "Teacher".

      Four Usecases

      Notice the use of a "stick figure" to indicate a class of actors. The usecase is indicated by an oval. Communication is modeled as a simple link between an actor and an usecase.

      It is also possible to use the UML generalization relationship between classes of actors: For example a Graduate Student might be a special kind of Student and so could share the Add Class Scenario. The generalisation link is also used between Usecases to indicate that one usecase is a special case of another one, or that one usecase makes use of another one.

      Interaction Diagrams

        These allow you to work out how your classes can help the user solve problems. Sequence diagrams make the timing of various operations clear. Collaboration diagrams are better for modelling a complex interaction or algorithm. There is no reason why you shouldn't draw both.

        Sequence Diagrams

        Historically, Charles Babbage was the first person to draw a diagram were each part of a machine was shown as a vertical line, time flows down the page, and connections between the parts flow across the page. This idea has been reinvented several times in the last 10 years.

        A Sequence Diagram

        The above diagram indicates the following sequence of events (inside our program):


        1. JoDoe asks to drop a class, the request is handled by Jo's Student object -- -- --(jd)
        2. jd asks the Section --(s) to drop jd.
        3. s (the section) passes the message to an Enrollment --(e) which self-destructs.
        4. s reports success to jd.
        5. jd reports success to Joe.

        Each vertical line indicates an existing object. When it is active it the line becomes a rectangle. Connections can show flow and whether it is synchronous(----->) or asynchronous(with only half an arrowhead!). Normally the steps are described on the left hand side of the diagram.

        Collaboration Diagrams

        A collaboration diagram shows how a collection of objects and classes work together (Latin: co - labor = work together) to fulfill a use-case. Each step in the process is numbered and follows a link from one object to another. Here is an example - a first sketch of how the system helps a student add a section:

        Add Class Collaboration Diagram

        The diagram above describes the following:


        1. Jo Doe, a student asks to add a class by giving Jo's student id -- -- --(sid)
          and a section id--(sd).
        2. The student class uses the sid to get Jo's object -- (jd) The jd object is passed to the section.
        3. The Section class uses the find operation to find the asked for Section object -- -- --(s)
        4. s finds out which course it is and passes s and jd into the Enrollment class which
        5. constructs a new added enrollment linking jd to s.

        Exercise. There are some obvious errors and ommissions in the above diagram -- fix them!

      . . . . . . . . . ( end of section Interaction Diagrams) <<Contents | End>>

      State Transition Diagrams

      State transition diagrams have been a part of computer science and computer programming since the 1940's. David Harel in the middle 1980's reinvented the state transition diagram in a form that has become popular in many different notations and methods. UML incorporates Harel's StateCharts as a way to work out, document and verify the gross patterns of behavior of an object in a class.

      The basic rules are easy to state.

      Here are a pair of examples showing the life of an idealized Student.

      State Diagram of a Student

      You will notice that in the above pair of diagrams the bottom one has the name of a state in the upper diagram. This means that the the state has been refined. It is also possible to redraw the two diagrams as a single diagram with the refinement replacing the unrefined state.

    . . . . . . . . . ( end of section Dynamic Models) <<Contents | End>>

    Glossary

    Note. In this glossary a definition is written like this
     		defined_term::=what_the_term_means.
    When there are several alternative meanings they are separated by a vertical bar symbol: "|". This is an informal extension of the notation John Backus and Pete Naur developed in 1960. [ BNF in glossary ] [ BNF in comp.text.Meta ] [ algol60.syntax.html ]

  1. UML::=Unified Modelling Language.

  2. actor::=an entity that starts scenarios and gets results from them.

  3. attributes::=values that an object or class is responsible for maintaining.
  4. application_domain::=a collection of more or less similar solutions.

  5. operations::=things that an object in a class knows how to do.

  6. results::=the end points of a set of scenarios.
  7. result::=the end point of a scenario.

  8. scenarios::=plural of scenario.
  9. scenario::=A description of how a particular actor achieves a tangible result.

  10. subtype::=One class is a subtype of another class if all the operations of the second class of object also apply to objects of the first type - perhaps in a different way.

  11. usecase::=a set of scenarios sharing a a class of similar actors achieving similar tangible results documented by a natural language text and pictured as an oval.

End