1 / 72

Teaching slides Case study

Teaching slides Case study. Case study Contents. Introduction Software requirement specifications Use cases & SRS for OBAAS 1.1 & OBAAS 1.2 Software high level design Data flow & component diagrams for OBAAS 1.1 & OBAAS 1.2 User interface design & construction

mlarson
Download Presentation

Teaching slides Case study

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. Teaching slides Case study

  2. Case studyContents • Introduction • Software requirement specifications • Use cases & SRS for OBAAS 1.1 & OBAAS 1.2 • Software high level design • Data flow & component diagrams for OBAAS 1.1 & OBAAS 1.2 • User interface design & construction • Mock up screens for OBAAS 1.1 & OBAAS 1.2 • Software middle layer design & construction • Class, object, sequence & statechart diagrams for OBAAS1.1 & OBAAS 1.2 • Database design & construction • Software testing

  3. Case studysoftware requirement management – OBAAS 1.1 System use case for OBAAS 1.1

  4. Case studysoftware requirement management – OBAAS 1.1 Create bank account use case for OBAAS 1.1

  5. Case studysoftware requirement management – OBAAS 1.1 • When the user clicks on the Create account menu, the user should be taken to the Create account page. This page should contain a form where there are textboxes for Username, Password, Retype password, Phone number, and Address. There should be another textbox named Category for which the data should be non-editable and it should have a default value “U”. The textboxes for Password and Retype password should not display the characters and should show only an asterisk for each character entered by the user. The Create account page should have two buttons, Submit and Clear. When the user provides information in the textboxes for Username, Password, and Retype password; and the information in the textboxes for Password and Retype password match; and did not leave any textboxes empty; and clicks on the Submit button then the user information should be stored in the database of OBAAS. In that case, the user account should be created and the user is taken to a page containing a message confirming the successful account creation and the account number assigned to the user.

  6. Case studysoftware requirement management – OBAAS 1.1 • If the Clear button is clicked then the information provided by the user in the textboxes should be cleared and no information from the Account creation form should be stored in the database. If the information provided in the Password and Retype password fields does not match and the user clicks on the Submit button then a dialog box should appear with the message “Entries in the password/retype password fields are not matching. Please ensure password/retype password are the same” and an OK button. When the user clicks on the OK button on the dialog box, the system should dismiss that dialog box and the user should be at the Create account page where the user can enter the information again. If a textbox was left empty and the user clicked the Submit button then a dialog box should inform the user to fill that empty textbox.

  7. Case studysoftware requirement management – OBAAS 1.1 Check account balance use case for OBAAS 1.1

  8. Case studysoftware requirement management – OBAAS 1.1 • Since OBAAS is not connected to any real bank account, when the online account is created for a user, there will be no balance in the account. Testing such a system for functions such as bill payment or money transfer will not be possible. Therefore, we will be depositing US$ 500 in the user’s account when the account is created in OBAAS. • When the user clicks on the Account balance menu, the Account balance page appears. On this screen, a form is displayed with textboxes for Account number, Username, and Password. The textbox for Password should not display the characters and should show only an asterisk for each character entered by the user. There are also two buttons, Submit and Clear, on this form. If the user fills these textboxes and clicks on the Submit button then the information submitted by the user should be checked for correctness by matching it with the information in the database and if it is found to be correct then the amount should be displayed in the next screen.

  9. Case studysoftware requirement management – OBAAS 1.1 • If the user fills incorrect information and clicks on the Submit button then a dialog box should appear with the message “The username/password you entered is incorrect. Please enter correct entries” and an OK button. When the user clicks on the OK button on the dialog box, the system should dismiss that dialog box and the user should be at the Account balance page where he/she can enter the information again. If a textbox was left empty and the user clicked the Submit button then a dialog box should inform the user to fill that empty textbox. There should be a Clear button on the Account balance page to reset all the text fields at any time.

  10. Case studysoftware requirement management – OBAAS 1.1 Service request use case for OBAAS 1.1

  11. Case studysoftware requirement management – OBAAS 1.1 • When the user clicks on Service request menu, the Service request page should appear. Currently, using the Service request page, a user can only request a cheque book from the bank. On receiving a cheque book request, the bank will send a new cheque book, through a courier service, to the address that was provided by the user while creating the account online. On this Service request page, a form should be displayed with textboxes for Account number, Username, and Password. There should be a Service request dropdown menu with only cheque book request item in it. There should also two buttons, Submit and Clear, on this form. The textbox for Password should not display the characters and should show only an asterisk for each character entered by the user.

  12. Case studysoftware requirement management – OBAAS 1.1 • If the user fills the textboxes and selects “request a cheque book” from the dropdown list for Service request and clicks on the Submit button then the information submitted by the user should be checked for correctness by matching it with the information in the database and if it is found to be correct then a message confirming the cheque book issue should be displayed. If the user fills incorrect information in the checkboxes and clicks on the Submit button then a dialog box should appear with the message “The username/password you entered is incorrect. Please enter correct entries” and an OK button. When the user clicks on the OK button on the dialog box, the system should dismiss that dialog box and the user should be at the Service request page where he/she can enter the information again. If a textbox was left empty and the user clicked the Submit button then a dialog box should inform the user to fill that empty textbox. There should be a Clear button on the Service request page to reset all the text fields at any time.

  13. Case studysoftware requirement management – OBAAS 1.1 Bill payment use case for OBAAS 1.1

  14. Case studysoftware requirement management – OBAAS 1.1 • When the user clicks on Bill pay menu, the Bill pay page appears. Currently, using the Bill pay page, a user can only pay the bills for two different service providers (billers). On this Bill pay page, a form should be displayed with textboxes for Account number, Username, Password, and Amount. There should also be a dropdown menu for selecting the Biller. There should be two buttons, Submit and Clear, on this form. The textbox for Password should not display the characters and should show only an asterisk for each character entered by the user.

  15. Case studysoftware requirement management – OBAAS 1.1 • If the user fills the textboxes and selects a biller from the dropdown list and clicks on the Submit button then the information submitted by the user should be checked for correctness by matching it with the information in the database and if it is found to be correct then that amount should be transferred to the account of the Biller and the same amount should be subtracted from the account of the user. A screen confirming the bill payment should be displayed to the user. The system will also check in the database if the account of the user has enough account balance to pay the bill. A message “Not sufficient funds in the account. This transaction cannot be performed” should be displayed to the user in case of insufficient funds. The user can dismiss this message box by clicking on its OK button. After dismissing the message box the user will be displayed the bill payment page again. The user can pay another bill of any amount equal to or less than the balance in the account.

  16. Case studysoftware requirement management – OBAAS 1.1 Close account use case for OBAAS 1.1

  17. Case studysoftware requirement management – OBAAS 1.1 • When the user clicks on Close account menu, the Close account page should appear. On this screen, a form should be displayed with textboxes for Account number, Username, and Password. There should be two buttons, Submit and Clear, on this form. The textbox for Password should not display the characters and should show only an asterisk for each character entered by the user.

  18. Case studysoftware requirement management – OBAAS 1.1 • If the user fills these textboxes and clicks on the Submit button then the information submitted by the user should be checked for correctness by matching it with the information in the database and if it is found to be correct then the account closure page should be displayed to the user. If the user fills incorrect information and clicks on the Submit button then a dialog box should appear with the message “The username/password you entered is incorrect. Please enter correct entries” and an OK button. When the user clicks on the OK button on the dialog box, the system should dismiss that dialog box and the user should be at the Close account page where he/she can enter the information again. If a textbox was left empty and the user clicked the Submit button then a dialog box should inform the user to fill that empty textbox. There should be a Clear button on the Close account page to reset all the text fields at any time.

  19. Case studysoftware requirement management – OBAAS 1.2 System use case for OBAAS 1.2

  20. Case studysoftware requirement management – OBAAS 1.2 Money transfer use case for OBAAS 1.2

  21. Case studysoftware requirement management – OBAAS 1.2 • When the user clicks on Money transfer menu then Money transfer page should appear. On this screen, a form is displayed with textboxes for Username, Password, From Account (the user account number), Amount, and To account (the account number of the party to which the money will be transferred) fields. There are also two buttons, Submit and Clear, on this form. The textbox for Password should not display the characters and should show only an asterisk for each character entered by the user. If the user fills the textboxes and clicks on the Submit button then the information submitted by the user should be checked for correctness by matching it with the information in the database. If the account balance of the user, prior to this transaction, is higher than or equal to the amount that needs to be transferred then the system should proceed with the transaction.

  22. Case studysoftware requirement management – OBAAS 1.2 • When the transaction is successful then the system should display a message containing the amount that was transferred and the account number to which the money was transferred. If the account balance is less than the amount to be transferred then an error message should be displayed on a dialog box informing the user about the insufficient funds. If the user fills incorrect information and clicks on the Submit button then a dialog box should appear with the message “The username/password you entered is incorrect. Please enter correct entries” and an OK button. When the user clicks on the OK button on the dialog box, the system should dismiss that dialog box and the user should be at the Money transfer page where he/she can enter the information again. If a textbox was left empty and the user clicked the Submit button then a dialog box should inform the user to fill that empty textbox. There should be a Clear button on the Money transfer page to reset all the text fields at any time.

  23. Case studysoftware requirement management – OBAAS 1.2 Service request use case for OBAAS 1.2

  24. Case studysoftware requirement management – OBAAS 1.2 • When the user clicks on Service request menu, the Service request page should appear. On receiving a cheque book request, the bank will send a new cheque book, through a courier service, to the address that was provided by the user while creating the account online. On this screen, a form should be displayed with textboxes for Account number, Username, and Password. There is also a Service request dropdown menu. There are also two buttons, Submit and Clear, on this form. The textbox for Password should not display the characters and should show only an asterisk for each character entered by the user. If the user fills the textboxes and selects “request a cheque book” from the dropdown list for Service request and clicks on the Submit button then the information submitted by the user should be checked for correctness by matching it with the information in the database and if it is found to be correct then a message confirming the cheque book issue should be displayed.

  25. Case studysoftware requirement management – OBAAS 1.2 • If the user fills incorrect information and clicks on the Submit button then a dialog box should appear with the message “The username/password you entered is incorrect. Please enter correct entries” and an OK button. When the user clicks on the OK button on the dialog box, the system should dismiss that dialog box and the user should be at the Service request page where he/she can enter the information again. If a textbox was left empty and the user clicked the Submit button then a dialog box should inform the user to fill that empty textbox. There should be a Clear button on the Money transfer page to reset all the text fields at any time. In OBAAS 1.2, there is a service fee of US$ 5 for each cheque book request. This fee should be deducted from the bank account of the user. If the user’s bank account balance is below US$ 5 then the service request for a cheque book should not be entertained. A dialog box with a message “insufficient funds” should be displayed to the user in such case.

  26. Case studysoftware high level design – OBAAS 1.1 Component diagram for OBAAS 1.1

  27. Case studysoftware high level design – OBAAS 1.1 • Account balance: The use case states that the user can find the account balance of his/her bank account. In the component design, the account balance page searches the account database to find the account balance for the user. • Service request: The use case states that the user can request a new cheque book from the bank. The user can go to the service request page. The user selects the cheque issue service request from a drop down list at the service request page. When a cheque book is issued, the service database is updated.

  28. Case studysoftware high level design – OBAAS 1.1 • Bill payment: The use case states that the user can pay the bills using OBAAS. In the component design, when the user wants to pay a bill he/she goes to the Bill payment page. The user selects a service provider from the list then the user can pay the bill amount from the Bill payment page. After bill payment, the user account is updated because the bill payment is done from the user account. • New account: The use case states that a user can create a new account in OBAAS. In the component design, the account creation page lets the user to create his/her account in the system. • Account closure: The use case states that the user can close his/her online bank access account. In the component diagram, an account closure page is provided so that the user can close the account.

  29. Case studysoftware high level design – OBAAS 1.2 Component diagram for OBAAS 1.2

  30. Case studysoftware high level design – OBAAS 1.2 OBAAS 1.2 has 2 differences as compared to OBAAS 1.1. There is a additional feature for money transfer facility between any bank accounts. Account holders can transfer money from their own bank account to any other bank account. The other difference is that there is a service fee of $5 for new cheque book requests. This amount will be deducted from the bank account of the account holder.

  31. Case studysoftware high level design – OBAAS 1.1 Data flow diagram for OBAAS 1.1

  32. Case studysoftware high level design – OBAAS 1.2 Data flow diagram for OBAAS 1.2

  33. Case studysoftware high level design – OBAAS 1.2 Data flow diagram for OBAAS 1.1 & OBAAS 1.2 are depicted in above diagrams. A data flow diagram shows data flows when some event gets triggered and some business logic runs. The data flow starts from an external entity and passes through a process (business logic). Finally data manipulation or data view is done in an data store.

  34. Case studysoftware user interface design – OBAAS 1.1 Create account user screen for OBAAS 1.1

  35. Case studysoftware user interface design – OBAAS 1.1 Create account response user screen for OBAAS 1.1

  36. Case studysoftware user interface design – OBAAS 1.1 Dialog box for incorrect username / password in OBAAS 1.1

  37. Case studysoftware user interface design – OBAAS 1.1 Account user balance screen for OBAAS 1.1

  38. Case studysoftware user interface design – OBAAS 1.1 Account balance response user screen for OBAAS 1.1

  39. Case studysoftware user interface design – OBAAS 1.1 Bill payment user screen for OBAAS 1.1

  40. Case studysoftware user interface design – OBAAS 1.1 Bill payment response user screen for OBAAS 1.1

  41. Case studysoftware user interface design – OBAAS 1.1 Service request user screen for OBAAS 1.1

  42. Case studysoftware user interface design – OBAAS 1.1 Service request user screen for OBAAS 1.1

  43. Case studysoftware user interface design – OBAAS 1.1 Close account user screen for OBAAS 1.1

  44. Case studysoftware user interface design – OBAAS 1.1 Close account user screen for OBAAS 1.1

  45. Case studysoftware user interface design – OBAAS 1.2 Service request user screen for OBAAS 1.2

  46. Case studysoftware user interface design – OBAAS 1.2 Service request user screen for OBAAS 1.2

  47. Case studysoftware user interface design – OBAAS 1.2 Money transfer user screen for OBAAS 1.2

  48. Case studysoftware user interface design – OBAAS 1.2 Money transfer user screen for OBAAS 1.2

  49. Case studysoftware middle layer design – OBAAS 1.1 Class diagram for OBAAS 1.1

  50. Case studysoftware middle layer design – OBAAS 1.1 Class diagram for OBAAS1.1 is shown above. In the classes we have created, we can see that we have not included database connection management. We will discuss database connection management now as all transaction in OBAAS results in saved or modified records in the database system. From the component design we can also see that database connection is required on each web page many times. This means, the connection with the database is an activity that is required to be performed many times. You can also realize that each class we have designed in OBAAS will be connecting to the database many times. Thus it will be better to pool all the database connection related activities inside a pool of specialized classes which will be dealing only with database connection management.

More Related