J.14. Wrap-Up

Now that we have presented the complete ATM implementation, you can see that many issues arose during implementation for which we did not provide detailed UML diagrams. This is not uncommon in an object-oriented design and implementation experience. For example, many attributes listed in the class diagrams were implemented as C# properties so that clients of the classes could gain controlled access to the underlying private instance variables. We did not make all of these properties during our design process, because there was nothing in the requirements document or our design process to indicate that certain attributes would eventually need to be accessed outside of their classes.

We also encountered various issues with simulating hardware. A real-world ATM is a hardware device that does not have a complete computer keyboard. One problem with using a computer keyboard to simulate the keypad is that the user can enter non-digits as input. We did not spend much time dealing with such issues, because this problem is not possible in a real ATM, which has only a numeric keypad. However, having to think about issues like this is a good thing. Quite typically, software designs for complete systems involve simulating hardware devices like the cash dispenser and keypad. Despite the fact that some aspects of our ATM may seem contrived, in real-world systems, hardware design and implementation often occurs in parallel with software design and implementation. In such cases, the software cannot be implemented in final form because the hardware is not yet ready. So, software developers must simulate the hardware, as we have done in this case study.

Congratulations on completing the entire software engineering ATM case study! We hope you found this experience to be valuable and that it reinforced many of the concepts that you learned in Chapters 111. We would sincerely appreciate your comments, criticisms and suggestions. You can reach us at [e-mail]. We will respond promptly.