Elaboration Phase
Three iterations were planned for the elaboration phase. The following items were updated or created as part of the first two iterations (the last iteration has not been started):
Updated risks list (started during the inception phase)
Initial architecture document
Design model
An executable prototype of critical functionality
Initial implementation model
A generally complete use case model (all use cases, all actors, and most flow of events completed)
Additionally, an analysis model was developed as part of this project. It was decided to maintain it for future reference and activities related to this project.
Elaboration Iteration#1
Updated Risk Factors
A new concern has been raised that the performance of Enterprise JavaBeans (EJB) may not meet expectations. This is a significant risk (risk level 8). To mitigate this risk, we decided to move to EJB 2.0 release early on to take advantage of enhancements in this area.
Requirements Update
Administrative services requirements are not yet sorted out due to scheduling issues (lack of availability) for key decision makers from the customer side.
After discussions with customer stakeholders about the scheduling risks, a decision was made to defer the investment services related use cases to a future release.
Updated Iteration Plan (Summary)
Table 16-3 provides an updated iteration plan.
Detailed Sequence Diagrams
Some representative sequence diagrams developed during this iteration are shown in Figures16-6 to 16-9.
Figure 16-6. List transactions main scenario sequence diagram
Figure 16-7. Pay bills main sequence diagram
Figure 16-8. Login main sequence diagram
Figure 16-9. Detailed transfer funds sequence diagram
| Phase | Iterations | Duration (in weeks) |
|---|---|---|
| Inception | Initial Iteration | Complete |
| Elaboration | Elaboration Iteration#1 (basic use cases) | 3 |
| Elaboration Iteration#2 (EJB 2.0) | 3 | |
| Elaboration Iteration#3 (support for custom bill payment services and administrative services) | 3 | |
| Construction | Construction Iteration | 3 |
| Transition | Transition Iteration | 2 |
Class Diagrams
Figures 16-10, 16-11, and 16-12 show some of the class diagrams associated with use cases undertaken in this iteration.
Figure 16-10. List transactions class diagram
Figure 16-11. Pay bill class diagram
Figure 16-12. Login class diagram
Packaging Diagram
Figure 16-13 shows the initial packaging diagram for our example.
Figure 16-13. Initial packaging diagram
Component Dependency Diagram
Figure 16-14 shows the component diagram for the account entity bean from the HomeDirect example.
Figure 16-14. Component diagram for Account entity bean
Elaboration Iteration#2
This section summarizes the key points from the elaboration iteration#2.
Requirements Update
After reviewing the prototype, customers identified that the transaction confirmation procedures needed to be changed. Instead of displaying a confirmation page, they would like the user to provide confirmation by entering a password along with other information. This change needs to be made.
Administrative services requirements were sorted out as well.
Implementation Details
The primary activity for this iteration was the migration of the work to the EJB 2.0 release. No new functionality was introduced in this iteration; however, some changes were made to the implementation in switching to the EJB 2.0 release.
A summary of implementation related changes required for the transition from EJB 1.1 to EJB 2.0 are as follows:
All container-managed persistence (CMP) fields in the entity beans have been changed to work with 2.0 CMP. This involved removing the direct references to these fields from the EJB source and changing all accessors to be abstract and removing their code.
Because of the modifications mentioned in the preceding implementation change, a few accessors that had nonstandard code bodies had to be modified to use that code in a business method. Clients now call the business method first, which in turn calls the accessor as needed. (The AccountType accessors on the Account EJB are an example.)
All components of the application needed to be reassembled from scratch because the deployment tools have changed significantly.
Finder methods now use EJB QL to specify their queries rather than normal SQL.
findByPrimaryKey methods are now hidden from the deployer and generated automatically by the tools, using specific naming conventions. To remain compatible with the deployment tools, all table names and column names needed to be modified to match these conventions.
Please see the README.html file accompanying the software for more information on the table and column name changes that needed to be made.
Elaboration Iteration#3
The elaboration iteration#3 is a reader led iteration. Instead of providing solutions, we identify problems that you can try to solve on your own. The problems build on the software provided, so you can continue on with the project outlined in this chapter.
Three sets of use cases have been provided in the form of detailed flow of events.
Requirements Update
The current list of transactions lists all transactions. The customer would like the ability to list only those transactions that are associated with a specific account as selected by the user.
Suggestions for the Iteration
Suggestions and guidelines regarding activities to undertake during this iteration include
Update the risks list and adjust iteration plans as required
Incorporate the new use cases in the use case model as appropriate
Develop initial sequence diagrams for each use case main flow of events
Revisit architecture if warranted to ensure it can accommodate these requirements
Develop View of Participating Classes (VOPC) diagrams for each use case
Update the implementation
Update component and deployment diagrams to reflect the updated implementation model
Modify the list transactions use case to match the requirements as outlined in the immediately preceding requirements update section of this iteration
Enhance the user profile EJB to contain and report information such as e-mail information, user phone number, and address
Set up asynchronous logging of every transaction to a backup file via a message-driven bean
Use Cases to Be Implemented in This Iteration
The following sections provide an overview of the use cases that will be implemented in this iteration.
Custom Vendor Bill Payment Services
The custom Vendor Bill Payment service consists of two main use cases. They are Pay Vendor Bills and Modify Vendor List. The main and alternate flow of events for these use cases are provided as follows.
Use Case: Pay Vendor Bills
Main flow of events: The customer successfully logs in and chooses to pay bills. The system presents the customer with a list of vendors previously set up by the customer and prompts the customer to choose a vendor, enter a total payment amount, and enter a payment date. The customer selects the vendor and enters the required information. The system verifies that the customer's checking account has sufficient funds for the payment and asks the customer to confirm payment. The system debits the amount to the customer's checking account and credits the amount to the vendor account. The system issues a confirmation number to the customer. The use case ends when the customer logs out.
Alternate flow of events: The customer does not have a vendor list set up. The system displays an error message and directs the user to first add the desired vendors to the customer's vendor list.
Alternate flow of events: Sufficient funds are unavailable in the customer's checking account. An error message is displayed to the customer, and the bill payment transaction is cancelled.
Use Case: Modify Vendor List
Main flow of events: The customer successfully logs in and requests that a change be made to the vendor list for future bill payments. The system presents the current list of vendors and buttons to add or delete a vendor. The customer chooses to add a vendor by selecting the Add button. The system prompts the user to enter a vendor name. The customer enters a vendor name. The system verifies the vendor name with the list of vendors registered with the bank. The system presents all matching vendor names to the customer, asks the customer to select one of the vendors, and provides vendor-related account information in the space provided. The customer selects the vendor and enters the number of the account being maintained with the vendor. The system verifies that the account number entered for the vendor matches the account number format provided by the vendor. The system displays an updated vendor list with the name of the vendor added to the list of vendors enabled for bill payment. The use case ends.
Alternate flow of events: The customer chooses a vendor from the list of vendors already enabled for bill payment and specifies the delete operation. The system removes the name of the vendor from the list of vendors enabled for bill payment and displays an updated list of vendors.
Alternate flow of events: The vendor-specific account number entered by the customer as part of the add vendor function is invalid. The system displays an error message and prompts the customer to reenter the correct vendor-specific account number.
Administrative Services Use Cases
Administrative services are provided via a separate application. Use cases for the administrative application are detailed in the following sections.
Use Case: Manual Account Update
Main flow of events: The administrator logs in and selects to update an account manually. The system prompts the administrator for either the customer ID or the account number. The system locates the account based on the information provided and displays the types of transactions available. This includes credit and debit functions. The administrator chooses the transaction type and enters an amount and a text reason. The system carries out the transaction and debits or credits the account as selected. The use case ends.
Alternate flow of events: The customer ID or account number is invalid. The system displays an error message and prompts the administrator to reenter the information.
Alternate flow of events: The manual debit amount is more than the current balance. The system displays a reconfirmation dialog and informs the administrator of the imminent negative balance. Upon confirmation, the system performs the transaction even if the account produces a negative balance as a result of this action.
Use Case: Cancel Bill Payment
Main flow of events: The administrator logs in and selects the cancel bill payment option. The system prompts for a bill transaction confirmation number. The administrator enters the transaction confirmation number. The system retrieves the pending bill payment and prompts the administrator to confirm the cancellation. Upon administrator confirmation, the system deletes the record from the pending bills list and credits the customer account with an amount equal to the bill. The use case ends.
Alternate flow of events: The bill transaction number entered by the administrator is invalid. The system displays an error message and prompts the administrator to reenter the information.
The remaining use cases are optional as the customer has agreed to defer them to a future release.
Investment Services Use Cases
The initial investment services functionality revolves around two main use cases: buy security and sell security. Their main and alternate flow of events are described as follows.
Use Case: Buy Security
Main flow of events: The customer logs in, selects the investment account, and chooses to buy a security. The system prompts the customer to enter a security symbol, a quantity, a limit price, and other required information for the trade. The system verifies the accuracy of the symbol, calculates the approximate total charges for the security order, and displays a list of the customer's accounts from which payment will be deducted. The customer selects one of the accounts. The system verifies that sufficient funds are available, and then initiates the security purchase order on behalf of the customer. The system provides an order confirmation number to the customer. The use case ends.
Alternate flow of events: The security symbol entered by the customer is invalid. The system displays an error message and prompts the customer to reenter the symbol.
Alternate flow of events: Sufficient funds are not available in the chosen account. The system displays an error message and prompts the user to reenter the information or choose an alternate account for payment.
Use Case: Sell Security
Main flow of events: The customer logs in, selects the investment account, and chooses to sell a security. The system displays the list of securities currently held in the investment account and prompts the customer to choose the security, a quantity to be sold, and a price to be sold at. The system verifies that the required quantity of securities is available for the chosen security, calculates the approximate total charges for the security order, and displays a list of the customer's accounts to which the proceeds of the sale should be deposited. The customer selects one of the accounts. The system then initiates the security sale order on behalf of the customer. The system provides an order confirmation number to the customer. The use case ends.
Alternate flow of events: No securities are available in the customer's investment account. The system displays an error message to the customer.
Alternate flow of events: The chosen quantity for sale is more than the quantity available in the customer's investment account. An error message is displayed to the customer, and the customer is asked to reenter a smaller number for the quantity of security to be sold.