bts430 design model: sequence diagrams. bts430 use case model domain model design model code

BTS430

Design Model: Sequence Diagrams

BTS430

Use case Model

Domain Model

Design Model Code

Larman, APPLYING UML AND PATTERNSLarman, APPLYING UML AND PATTERNS

Sequence Diagrams

Design Class Diagrams

Three Tier Architecture

Presentation Layer (UI classes)

Logic Layer (data classes holding business logic)

Data Layer (databases, DBMS, data access classes)

Handler/Façade/Controller




controller

controller


Use Case Handler class—e.g. ManageCustomerHandler “use case façade” “ use case controller”

DBHandler class “DBfacade” “DB 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

Opening Up “the black box”

: OnlineUserSystem

startRegistration()

enterRegistrationInfo(name,address,occupation,emailID,pwd,retypePwd)

link to newsletter





: OnlineUser : RegistrationHandler

enterRegistrationInfo(name,address,occupation,emailID,pwd,retypePwd)

link to newsletter

startRegistration()




: OnlineUser : RegistrationHandler : User : DBHandler

enterRegistrationInfo(name,address,occupation,emailID,pwd)

link to newsletter

startRegistration()

create()


insert()


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.




link to newsletter

startRegistration()

create()


insert()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);

}}



link to newsletter

startRegistration()

create()


insert()

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 = octhis.emailID = em;this.pwd = p;

DBHandler.getInstance.insert(....);}

}


Let’s look at a Parking Example …

CreditCard

cardNumcardExpiryDate

PayrollDeduction

Lot

lotIDtotalSpacesavailableSpaces

Payment

paymentIDpayAmount

11made withmade with

Vehicle

platemakemodelyearVIN

ParkingPass

passIDstartDateendDate

1n

1n

allows entry into

Invoice

invoiceIDdatetotal

records payment for

11

11

<--describes pay method

Staff

FeeFine

Customer

custIDnameaddressphonecampusAddr

1

1

1

1

owns

1

1

1

1owns

n

1

n

1

pays

1

0..1

1

0..1

is a

Student

1

0..1

1

0..1

is a

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.

: Parking ClerkSystem

startNewRegistration()

parking lots, time periods

enterRegistrationInfo(customer info, vehicle info, lot, time period)

customer info, vehicle info, lot, time period

requestToPay()

proceedToPay(creditCardNum,expDate)

invoice information

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.






requestToPay()


invoice information

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

: Parking Clerk :

ParkingRegHandler

Loop

: DBHandlerlotList [lotInd] : Lot

1: startNewRegistration()

3: retrieveList(Lot)

2: create()






requestToPay()


invoice information



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.

: Parking Clerk :

ParkingRegHandler : Parking Fines

System

s : Staff v : Vehicle : DBHandler

enterRegistrationInfo(customerInfo,vehicleInfo,lotInd,timePeriod)

checkFines(s,v)

create(staffInfo)

addVehicle(vehicleInfo)

saveStaffAndVehicle()

create(vehicleInfo)

insert(s,v)

pp : ParkingPass

create()

setParkingPass(s,v,startDate,endDate,lotList[lotInd])

lotList [lotInd] : Lot

getLotName()






requestToPay()


invoice information








requestToPay()


invoice information



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.






requestToPay()


invoice information



: Parking Clerk :

ParkingRegHandlerlotList [lotInd] :

Lotinv : Invoice pp :

ParkingPass : DBHandler

: Bank System

proceedToPay(creditCardNum,Expdate,total)

deductSpace()

validateAndProcess(creditCardNum,Expdate,total)

savePass()

replace(lotList[lotInd])

insert(pp)

create(staff,vehicle,pp,amount)

insert(inv)

bts430 design model: sequence diagrams. bts430 use case model domain model design model code

Documents