meeting -*- Outline -*-

* Use Case Model: Drawing System Sequence Diagrams (Larman Ch. 9)

  The purpose of drawing system sequence diagrams is to
      - understand the problem domain better
      - in particular, to identify system events (inputs and outputs)

------------------------------------------
 SYSTEM SEQUENCE DIAGRAMS (SSDs) (CH. 9)

Goal:
  - identify system events
  - frame system as a "black box"
  - understand system behavior better

Do these for:
  - main success scenario
  - frequent or complex alternatives

Example:
  O 
 \|/                           |---------|
 / \   Process Sale Scenario   | :System |
:Cashier                       |---------|

  |       makeNewSale()            |
  |------------------------------->|
  |                                |
  |  enterItem(itemID, quantity)   |
  |------------------------------->|
  |                                |
  |     description, total         |
  |<-------------------------------|
  |        *[more items]           |
  |                                |
  |         endSale()              |
  |------------------------------->|
  |                                |
  |       totalWithTaxes           |
  |<-------------------------------|
  |                                |
  |       makePayment(amount)      |
  |------------------------------->|
  |                                |
  |     changeDue, receipt         |
  |<-------------------------------|
  
------------------------------------------

        The names :Cashier and :System should be underlined,
              as should name of use case.  

        There should be a box around the repeated messages.

        In general, show external factors as stick figures if people.

        In general, return values can be omitted is nothing is
        returned.

        Time flows goes down the page.

        Messages with parameters, like makePayment(amount),
                 are abstractions of system events
                 i.e., the cashier doesn't really send the message,
                       but pushes a button or something and an event
                       happens which may or may not be represented by a
                       message send in the actual system
        
        Explain how this corresponds to the use case.
        It is generated by inspecting the use case.

        These can be used to illustrate collaborations both between
        people and the system and between the system and other systems.

** System boundary (9.6)
        Q: Where's the system boundary here?
        Knowing this is important for deciding what events are system
        events.
        For example, whether the customer is generating system events
        or only the cashier.

** Naming system events and operations (9.7)
   Express system events and operations at the level of intent,
           not in terms of physical input or interface widgets.

   Q: Which is better as a system event name: "enterItem" or "scan"?
            enterItem expresses a content, and doesn't commit to some
            technology for how to do it.

   It helps to start the names of systems with a verb.    

** practice
------------------------------------------
       FOR YOU TO DO (IN TEAMS)

Create one or two SSDs for
your main use cases
(ones you'll use in the first iteration).
------------------------------------------

** Showing use case text (9.8)
   Can place the text or fragments of it to the left of the SSDs.

** Questions
   Q: Is a necessary to create SSDs for all scenarios of all use
   cases?
      no, only create them for some chosen scenarios of the current iteration

   Q: how long should you spend creating SSDs?
      "a few minutes" or a "half hour"