1 / 18

Design Model: Sequence Diagrams for Collection Iteration

Learn how to handle and iterate over collections (lists) in sequence diagrams. See examples and code implementation in Java.

riversr
Download Presentation

Design Model: Sequence Diagrams for Collection Iteration

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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.16Iteration 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. Figure 15.16Iteration over a collection using relatively explicit notation.

  7. Figure 15.16Iteration 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. public class Sale { private List<SalesLineItem> lineItems = new ArrayList<SalesLineItem>(); public Money getTotal() { Money total = new Money(); Money subtotal = null; for ( SalesLineItem lineItem : lineItems ) { subtotal = lineItem.getSubtotal(); total.add( subtotal ); } return total; } // … } Java code for Figure 15.16

  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

  12. 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.

  13. 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.

  14. 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.

More Related