Apply for a Mortgage use case

The Apply for a Mortgage use case describes how the user makes a request for a mortgage using a Java application. The application stores mortgage requests in a database, where the monitoring supervisor can approve or reject the request. To apply for a mortgage, the user must provide the application with a set of data, and the application must perform an operation to send the request to the mortgage request database. To keep it brief, the use case assumes that no errors occur.

Actor

A teller using the Java application to make a mortgage application on behalf of a customer.

Flow of events

  1. The user launches the mortgage application from the desktop.
  2. The desktop instantiates the defined flow processor, assigns a navigation controller to it by adding the navigation controller as a notifier in the processor context, and starts the processor.
    Note: The processor context holds all the data required during the lifetime of the processor. The processor views do not have their own context. Instead, they share the generic processor context.
  3. The processor displays a MortgageData1View for gathering the user data for the mortgage application. The view contains two buttons: a Cancel button to dispose of the view and terminate the process, and a Next navigation button to open a second peer view, MortgageData2View. The latter collects more user data for the mortgage application. The view panel defines both buttons and generates navigation events, which the processor ignores. The processor only acts on generic events fired by the navigation controller when a view is opened or closed.
    Note: When the MortgageData1View opens, it gets focus. If it is already open, the navigation controller gives it focus.
  4. The user enters the required input data in MortgageData1View and selects the Next button. The navigation controller opens the MortgageData2View and fires the viewOpened event, which triggers the processor to make a transition to its next state. The MortgageData2View contains entry fields for additional data and three buttons: a Back button to return to the previous view, a Cancel button to dispose of the view and terminate the process, and an Action button to launch the mortgage operation.
    Note: When the user clicks the Cancel button, the navigation controller disposes of the MortgageData1View and MortgageData2View, and generates closedView events. These signal the processor to make a transition to its FinalNotOK state.
  5. The user enters the data required for the MortgageData2View and selects the Action button. The processor moves into the state defined for this event, which executes the operation. The processor uses the data to perform the mortgageOper operation. The processor action responsible for executing the operations fires an okEvent, which indicates that the execution was successful.
  6. The processor displays the operation results in the MortgageResultsView using the navigation controller to open the view. The view contains an OK button that closes the view.
  7. The user selects the OK button. The navigation controller closes the MortgageResultsView, which fires a viewClosed event. This event triggers a transition in the processor.
  8. The use case ends when the Processor closes the two active panels, MortgageData1View and the MortgageData2View, and moves into a final state, FinalOK.

Alternate flow

When the operation does not succeed, the processor action responsible for executing the operations fires an error event. The processor uses the navigation controller to open the ErrorInfoView, which contains an OK button to close the view. When the user acknowledges the error message by selecting the OK button, the navigation controller closes the view. The Processor closes the two active open views and makes a transition to the FinalNotOK state.