1. BTS430 Design Model: Sequence Diagrams involving collections

2. Opening Up “the black box”  Let’s look at how collections (lists) are handled …* * Larman, Chapter 15, pages 233-234.

3. Iteration over a collection  A common algorithm is to iterate over all members of a collection (such as a list or map), sending the same message to each. Often, some kind of iterator object is ultimately used, such as an implementation of java.util.Iterator or a C++ standard library iterator, although in the sequence diagram that low- level "mechanism" need not be shown in the interest of brevity or abstraction.

4. Iteration over a collection  At the time of this writing, the UML specification did not (and may never) have an official idiom for this case. Two alternatives are shown—reviewed with the leader of the UML 2 interaction specification—in Figure 15.16 and Figure 15.17.

5. Figure 15.16 Iteration over a collection using relatively explicit notation.

6.  Note the selector expression lineItems[i] in the lifeline of Figure 15.16. The selector expression is used to select one object from a group. Lifeline participants should represent one object, not a collection.

7. Figure 15.16 Iteration over a collection using relatively explicit notation.  In Java, for example, the following code listing is a possible implementation that maps the explicit use of the incrementing variable i in Figure 15.16 to an idiomatic solution in Java, using its enhanced for statement (C# has the same).

8. Java code for Figure 15.16 public class Sale { private List lineItems = new ArrayList (); public Money getTotal() { Money total = new Money(); Money subtotal = null; for ( SalesLineItem lineItem : lineItems ) { subtotal = lineItem.getSubtotal(); total.add( subtotal ); } return total; } // … }

9. Figure 15.17. Iteration over a collection leaving things more implicit.  Another variation is shown in Figure 15.17; the intent is the same, but details are excluded. A team or tool could agree on this simple style by convention to imply iteration over all the collection Elements.

10. Figure 15.17. Iteration over a collection leaving things more implicit.

11. An example of a sequence diagram using a list The Parking Lot Example

13. Actor (Parking Clerk)System The parking clerk requests to start a new registration The system displays a list of parking lots which have available spaces, time periods, and a customer and vehicle information form. The clerk checks off that the customer is staff and enters the customer information—name, address, phone, campus address, and the car ownership information, including make, model, colour and plate number. The clerk also selects the appropriate time period for the parking pass. The clerk then requests to proceed with the registration. The system checks if the customer has any overdue school fees or unpaid fines. The customer does not. The system redisplays all of the entered information so that the clerk can review it with the customer. The clerk requests to pay.The system displays a payment screen. The customer is paying by credit card so the clerk enters card number and expiry. Once everything is entered the clerk requests to proceed The system validates the credit card with the bank system, submits the payment for processing to the bank and creates an invoice. The system also creates a new parking pass record for the customer, vehicle, lot, and timeframe selected. The quantity of available spaces for the lot selected is reduced by one. The parking pass record includes a parking pass ID. The system then displays the invoice (which can be printed) showing customer name and ID, lot, time frame, parking pass ID, method of payment and the total paid.

14. The parking clerk requests to start a new registration The system displays a list of parking lots which have available spaces, time periods, and a customer and vehicle information form. Who should take responsibility for retrieving all lot information (there are many parking lots)? The handler, because the lot object only knows about one lot—itself. The handler creates an empty array (or list) of Lot objects. In the sequence diagram you don’t need to show this or you can show this as in the diagram below—what this says is that a handler creates a lot object or each entry in the array. In the sequence diagram lotList[lotInd] is the lot object at position lotInd in the array lotList.

15. The clerk checks off that the customer is staff and enters the customer information—name, address, phone, campus address, and the car ownership information, including make, model, colour and plate number. The clerk also selects the appropriate time period for the parking pass. The clerk then requests to proceed with the registration. The system checks if the customer has any overdue school fees or unpaid fines. The customer does not. The system redisplays all of the entered information so that the clerk can review it with the customer. Notes: In this part of the sequence diagram the system will need to create staff and vehicle objects. Another design decision/consideration is the following: perhaps we should create a parking pass object here? After all, the lot is selected and we have date information. Note also that I have shown the parking pass object asking the lot for the lot name. This is not specifically in the scenario but it is something that will probably be required. Notice also that I have named the Staff object s, the Vehicle object v and the ParkingPass object pp so that I can refer to them in the parameters.

16. The clerk checks off that the customer is staff and enters the customer information—name, address, phone, campus address, and the car ownership information, including make, model, colour and plate number. The clerk also selects the appropriate time period for the parking pass. The clerk then requests to proceed with the registration. The system checks if the customer has any overdue school fees or unpaid fines. The customer does not. The system redisplays all of the entered information so that the clerk can review it with the customer.

17. The customer is paying by credit card so the clerk enters card number and expiry. Once everything is entered the clerk requests to proceed The system validates the credit card with the bank system, submits the payment for processing to the bank and creates an invoice. The system also creates a new parking pass record for the customer, vehicle, lot, and timeframe selected. The quantity of available spaces for the lot selected is reduced by one. The parking pass record includes a parking pass ID. The system then displays the invoice (which can be printed) showing customer name and ID, lot, time frame, parking pass ID, method of payment and the total paid. Notes: If we look at the domain class diagram we see Payment and CreditCard classes. At this point in the design I think that payment would be handled by the bank system—it would keep any payment records required; all we would need to know is that the invoice was paid. We might need some kind of payment type; and normally we would stop and design that but for simplicity’s sake we’re modeling without it right now. Also, instead of modeling the bank system as an actor, when we get more information and are modeling in more detail we might model an interface to the bank system, for example a BankSystemAdapter.

18. The customer is paying by credit card so the clerk enters card number and expiry. Once everything is entered the clerk requests to proceed The system validates the credit card with the bank system, submits the payment for processing to the bank and creates an invoice. The system also creates a new parking pass record for the customer, vehicle, lot, and timeframe selected. The quantity of available spaces for the lot selected is reduced by one. The parking pass record includes a parking pass ID. The system then displays the invoice (which can be printed) showing customer name and ID, lot, time frame, parking pass ID, method of payment and the total paid.