1. BTS430 Design Model: Sequence Diagrams

2. BTS430 Use case Model Domain Model Design Model Code

3. Larman, APPLYING UML AND PATTERNS Sequence Diagrams Design Class Diagrams

4. Three Tier Architecture Presentation Layer (UI classes) Logic Layer (data classes holding business logic) Data Layer (databases, DBMS, data access classes)

5. Handler/Façade/Controller Presentation Layer (UI classes) Logic Layer (data classes holding business logic) Data Layer (databases, DBMS, data access classes) controller

6. Handler/Façade/Controller  Use Case Handler class—e.g. ManageCustomerHandler “use case façade” “ use case controller”  DBHandler class “DBfacade” “DB controller”

7. Handler/Façade/Controller  Protects logic layer from variations in the presentation layer and the data layer UI, DBMS, DB changes, and so on  Promotes “cohesion” within each layer  Promotes “low coupling” between layers  Promotes reuse  Directs messages to the appropriate objects

8. Opening Up “the black box” Presentation Layer (UI classes)

9. Opening Up “the black box” Presentation Layer (UI classes) Logic Layer (data classes holding business logic)

10. Opening Up “the black box” Presentation Layer (UI classes) Logic Layer (data classes holding business logic) Data Layer (databases, DBMS, data access classes)

11. WARNING The code samples used in this slide are not necessarily “correct” in terms of syntax; They are used only to demonstrate relationships between models and code.

12. Opening Up “the black box” public class RegistrationHandler { User user; public RegistrationHandler() { } public void startRegistration() { user = new User(); } public void enterRegistrationInfo(char name,char addr,char occup,char emailID,char pwd){ user.enterRegistrationInfo(name,addr,occup,emailID,pwd); }

13. public class User { private char name; private int addr; private char occup; private char emailID; private char pwd; public User() { } public void enterRegistrationInfo(char nm,char ad,char oc,char em,char p,char pr){ this.name = nm; this.addr = ad; this.occup = oc this.emailID = em; this.pwd = p; DBHandler.getInstance.insert(....); }

14. Opening Up “the black box”  Let’s look at a Parking Example …

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

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

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

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

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

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