meeting -*- Outline -*-

* Iteration 2 and Its Requirements (Larman, Chapter 21)

** emphasis (21.1)

   this iteration will focus on
        - essential object design
        - use of patterns to create a solid design
        - application of the UML to visualize the models

   won't talk much about requirements analysis or domain modeling

** from iteration 1 to 2 (21.2)

   at the end of the first iteration:

      - all software has been vigorously tested to get feedback
      - customers have been regularlly engaged in evaluation of the system
      - integration and stabilization of an internal release has occurred

------------------------------------------
   AT THE START OF THE 2nd ITERATION


  - reverse engineer the UML from code

  - requirements for this iteration
    are chosen

  - another requirements workshop
      most use cases written in fully
      dressed format

------------------------------------------

        participants in the requirements workshop include developers,
        as well as customers and architects

        Also (outside scope):
          - usability analysis underway
          - database modeling & impl. underway

** Iteration 2 requirements for the Airline Reservation system (21.3)

   NextGen acquired an airline, so we're now doing an airline
   reservation system :-)
------------------------------------------
     ITERATION 2 REQUIREMENTS FOR
      AIRLINE RESERVATION SYSTEM

Need to handle:








------------------------------------------
   ...
   - support for different 3rd party
     services:
        e.g., tax calculators with own interfaces
              accounting systems

   - complex pricing rules

   - pluggable business rules

   - a design to refresh the GUI window when the total cost of the
     reservation changes


   will consider these in the context of a Make Reservation use case,
        but will implement more scenarios and more functionality
        within each scenario (fewer simplifications)

   These variations are chosen to help illustrate design patterns,
         in a real business you might want to choose some other
         scenarios for this iteration

** Refinement of Analysis artifacts (21.4)

   No change to process sale use case (did a fully dressed version already).

   New SSDs to consider external systems (see fig 21.1)
       tax calculator, credit authorization service
       accounting system

   Draw new SSD showing

   o
  \|/                                   |---------------| |---------------|
   |                 |---------------|  |  <<actor>>    | |  <<actor>>    |
  / \                |  :Reservation |  | :TaxCalculator| |  :Credit      |
 : Agent             |   System      |  |               | | Authorization |
                     |---------------|  |---------------| |---------------|
   |                       |                    |                 |
   | makeNewReservation()  |                    |                 |
   |---------------------->|                    |                 |
|-----------------------------|                 |                 |
|  | addLeg(flight, qty)   |  |                 |                 |
|  |---------------------->|  |                 |                 |
|  |                       |  |                 |                 |
|  |  flightinfo           |  |                 |                 |
|  |< - - - - - - - - - - -|  |                 |                 |
|  |                       |  |                 |                 |
|  |   *[more flights]     |  |                 |                 |
|-----------------------------|                 |                 |
   |                       |                    |                 |
   |  endReservation()     |                    |                 |
   |---------------------->|                    |                 |
   |                       |  taxes :=          |                 |
   |                       |    getTaxes(reserv)|                 |
   |                       |------------------->|                 |
   |   total with taxes    |                    |                 |
   |< - - - - - - - - - - -|                    |                 |
   |                       |                    |                 |
   | makeCreditPayment     |                    |                 |
   |   (ccNum, expDate)    |                    |                 |
   |---------------------->|                    |                 |
   |                       |  appvl := approveCredit(request)     |
   |                       |------------------------------------->|
   |                       |                    |                 |
   |                       |    confnum := bookReservation(itinerary)
   |  confirmation number  |------------------------------------------> [DBMS]
   |< - - - - - - - - - - -|


   Domain model:
       Think if there are new concepts needed for the new scenarios

       To save time we'll suppress this,
          and let the new domain concepts come out
          during the design (but be careful)

   System operation contracts
       To save time we'll suppress this...