3.5. Case Study

3.5.1. Vision Document

A vision document contains more than those things needed for the modeling effort. It also contains financial and scheduling pertinent information. The following sections are those parts of the Vision Document spelled out in Section 3.3.1, “Vision Document” above. In practice this format need not be followed religiously, but is used here for consistency.

3.5.1.1. Summary

The company wishes to produce and market a line of ATM devices. The purpose of this project is to produce the hardware and the software to drive it that are both maintainable and robust.

3.5.1.2. Goals

To produce better designed products based on newer technology. Follow the MDA philosophy of the OMG by producing first a Platform Independent Model (PIM). As current modeling technology does not admit of maintaining the integrity of the connection between the PIM and Platform Specific Models (PSMs), the PIM will become comparatively stable before the first iteration of the PSM is produced. The software platform will be Java technology. The system will use a simple userid (from ATM card) and password (or PIN) mechanism.

3.5.1.3. Market Context

Equipment currently on the market is based on older technology for both hardware and software. This technology has not reached the end of its useful life, making it unlikely that the vendors of that gear are going to update it in the near future. On the other hand newer technology is available that would put us at a competitive advantage if implemented now.

3.5.1.4. Stakeholders

Among the stakeholders for this system are the Engineering Department, the Maintenance Department, and the Central Computer Facility. The full list of these stakeholders and the specific individuals representing them are.

  • Engineering.  Bunny, Bugs

  • Maintenance.  Hardy, Oliver

  • Computer Facility.  Laurel, Stanley

  • Chief Executive Officer.  Hun, Atilla The

  • Marketing.  Harry, Oil Can

3.5.1.5. Key Features

Cash deposit, cash withdrawal, and account inquiries by customers. Customers include people who have accounts at the owning bank as well as people who wish to make withdrawals from accounts in other banks or from credit card accounts.

Maintenance of the equipment by the bank's engineers. This action may be initiated by the engineer on a routine basis. It may also be initiated by the equipment that can call the engineer when it detects an internal fault.

Unloading of deposits and loading of cash by officials of the local bank branch. These actions occur either on a scheduled basis or when the central computer determines that the cash supply is low or the deposit receptacle is liable to be getting full.

An audit trail for all activities will be maintained and sent periodically to the bank's central computer. It will be possible for the maintenance engineer to save a copy of the audit trail to a diskette for transporting to the central computer.

Both dialup and leased line support will be provided. The ATM will continue to provide services to customers when communications with the central computer is not available.

3.5.1.6. Constraints

The project must be completed within nine months. It must cost no more than 1,750,000 USD excluding production costs. Components may be contracted out, but the basic architecture as well as the infrastructure will be designed in house. Close liaison must be maintained between the software development and the design, development and production of the hardware. Neither the hardware nor the software shall be considered the independent variable, but rather they shall be considered equal.

3.5.1.7. Appendix

The following are the actors that directly support this vision. Additional actors may be identified later that are needed to support this or that technology. They should not be added to this list unless they are deemed to directly support the vision as described in this document.

  • Central Computer

  • Customer

  • Local Branch Official

  • Maintenance Engineer

The following are the use cases that directly support this vision. Additional use cases may be identified later that are needed to support this or that technology or to support the use cases listed here. They should not be added to this list unless they are deemed to directly support the vision as described in this document.

  • Audit

  • Customer Uses Machine

  • Maintain Machine

3.5.2. Identifying Actors and Use Cases

For the ATM case study, we will elaborate on the examples in Section 3.3, “Output of the Requirements Capture Process”, Figure 3.4, “Use case diagram for an ATM system showing include relationships.” and Figure 3.5, “Use case diagram for an ATM system showing an extend relationship.”, and progress to identify additional actors and use cases that comprise our model of the ATM system. Figure 3.4, “Use case diagram for an ATM system showing include relationships.” and Figure 3.5, “Use case diagram for an ATM system showing an extend relationship.” exemplified the essential concepts and components of a use case diagram such as, use cases, actors, multiplicity, and include / extend relationships. They showed the relationships between the actors and use cases, and demonstrated how these actors and use cases interact.

In Figure 3.4, “Use case diagram for an ATM system showing include relationships.” we see a use case diagram for an ATM system consisting of «include» relationships for the use cases, Maintain ATM and Use ATM. Maintain ATM was further defined by two use cases, "Maintain Equipment" and "Reload ATM". Use ATM was further defined in terms of the behavior of three simpler use cases: "Deposit Cash", "Withdraw Cash" and "Query Account".

More to be written...

3.5.3. Associations (To be written)

To be written...

3.5.4. Advanced Diagram Features (To be written)

To be written...

3.5.5. Use Case Specifications (To be written)

To be written...

3.5.6. Supplementary Requirements Specification (To be written)

To be written...