In the Software Engineering Case Study sections in Chapters 1 and 38, we introduced the fundamentals of object orientation and developed an object-oriented design for our ATM system. In Chapters 47, we introduced object-oriented programming in C#. In Chapter 8, we took a deeper look at the details of programming with classes. We now begin implementing our object-oriented design by converting class diagrams to C# code. In the final Software Engineering Case Study section (Section 11.9), we modify the code to incorporate the object-oriented concepts of inheritance and polymorphism. We present the full C# code implementation in Appendix J.
Visibility
We now apply access modifiers to the members of our classes. In Chapter 4, we introduced access modifiers public and private. Access modifiers determine the visibility, or accessibility, of an object's attributes and operations to other objects. Before we can begin implementing our design, we must consider which attributes and methods of our classes should be public and which should be private.
In Chapter 4, we observed that attributes normally should be private and that methods invoked by clients of a class should be public. Methods that are called only by other methods of the class as "utility functions," however, should be private. The UML employs visibility markers for modeling the visibility of attributes and operations. Public visibility is indicated by placing a plus sign (+) before an operation or an attribute; a minus sign () indicates private visibility. Figure 9.23 shows our updated class diagram with visibility markers included. [Note: We do not include any operation parameters in Fig. 9.23. This is perfectly normal. Adding visibility markers does not affect the parameters already modeled in the class diagrams of Figs. 7.217.25.]
Figure 9.23. Class diagram with visibility markers.
Navigability
Before we begin implementing our design in C#, we introduce an additional UML notation. The class diagram in Fig. 9.24 further refines the relationships among classes in the ATM system by adding navigability arrows to the association lines. Navigability arrows (represented as arrows with stick arrowheads in the class diagram) indicate in which direction an association can be traversed and are based on the collaborations modeled in communication and sequence diagrams (see Section 8.14). When implementing a system designed using the UML, programmers use navigability arrows to help determine which objects need references to other objects. For example, the navigability arrow pointing from class ATM to class BankDatabase indicates that we can navigate from the former to the latter, thereby enabling the ATM to invoke the BankDatabase's operations. However, since Fig. 9.24 does not contain a navigability arrow pointing from class BankDatabase to class ATM, the BankDatabase cannot access the ATM's operations. Note that associations in a class diagram that have navigability arrows at both ends or do not have navigability arrows at all indicate bidirectional navigabilitynavigation can proceed in either direction across the association.
Figure 9.24. Class diagram with navigability arrows.
Like the class diagram of Fig. 4.24, the class diagram of Fig. 9.24 omits classes BalanceInquiry and Deposit to keep the diagram simple. The navigability of the associations in which these classes participate closely parallels the navigability of class Withdrawal's associations. Recall from Section 4.11 that BalanceInquiry has an association with class Screen. We can navigate from class BalanceInquiry to class Screen along this association, but we cannot navigate from class Screen to class BalanceInquiry. Thus, if we were to model class BalanceInquiry in Fig. 9.24, we would place a navigability arrow at class Screen's end of this association. Also recall that class Deposit associates with classes Screen, Keypad and DepositSlot. We can navigate from class Deposit to each of these classes, but not vice versa. We therefore would place navigability arrows at the Screen, Keypad and DepositSlot ends of these associations. [Note: We model these additional classes and associations in our final class diagram in Section 11.9, after we have simplified the structure of our system by incorporating the object-oriented concept of inheritance.]
Implementing the ATM System from Its UML Design
We are now ready to begin implementing the ATM system. We first convert the classes in the diagrams of Fig. 9.23 and Fig. 9.24 into C# code. This code will represent the "skeleton" of the system. In Chapter 11, we modify the code to incorporate the object-oriented concept of inheritance. In Appendix J, ATM Case Study Code, we present the complete working C# code that implements our object-oriented design.
As an example, we begin to develop the code for class Withdrawal from our design of class Withdrawal in Fig. 9.23. We use this figure to determine the attributes and operations of the class. We use the UML model in Fig. 9.24 to determine the associations among classes. We follow these four guidelines for each class:
Figure 9.25. Initial C# code for class Withdrawal based on Figs. 9.23 and 9.24.
(This item is displayed on page 452 in the print version)
1 // Fig. 9.25: Withdrawal.cs 2 // Class Withdrawal represents an ATM withdrawal transaction 3 public class Withdrawal 4 { 5 // parameterless constructor 6 public Withdrawal() 7 { 8 // constructor body code 9 } // end constructor 10 } // end class Withdrawal |
Figure 9.26. C# incorporating private variables for class Withdrawal based on Figs. 9.23 and 9.24.
(This item is displayed on page 452 in the print version)
1 // Fig. 9.26: Withdrawal.cs 2 // Class Withdrawal represents an ATM withdrawal transaction 3 public class Withdrawal 4 { 5 // attributes 6 private int accountNumber; // account to withdraw funds from 7 private decimal amount; // amount to withdraw from account 8 9 // parameterless constructor 10 public Withdrawal() 11 { 12 // constructor body code 13 } // end constructor 14 } // end class Withdrawal |
Figure 9.27. C# code incorporating private reference handles for the associations of class Withdrawal based on Figs. 9.23 and 9.24.
(This item is displayed on page 452 in the print version)
1 // Fig. 9.27: Withdrawal.cs 2 // Class Withdrawal represents an ATM withdrawal transaction 3 public class Withdrawal 4 { 5 // attributes 6 private int accountNumber; // account to withdraw funds from 7 private decimal amount; // amount to withdraw 8 9 // references to associated objects 10 private Screen screen; // ATM's screen 11 private Keypad keypad; // ATM's keypad 12 private CashDispenser cashDispenser; // ATM's cash dispenser 13 private BankDatabase bankDatabase; // account information database 14 15 // parameterless constructor 16 public Withdrawal() 17 { 18 // constructor body code 19 } // end constructor 20 } // end class Withdrawal |
Figure 9.28. C# code incorporating method Execute in class Withdrawal based on Figs. 9.23 and 9.24.
1 // Fig. 9.28: Withdrawal.cs 2 // Class Withdrawal represents an ATM withdrawal transaction 3 public class Withdrawal 4 { 5 // attributes 6 private int accountNumber; // account to withdraw funds from 7 private decimal amount; // amount to withdraw 8 9 // references to associated objects 10 private Screen screen; // ATM's screen 11 private Keypad keypad; // ATM's keypad 12 private CashDispenser cashDispenser; // ATM's cash dispenser 13 private BankDatabase bankDatabase; // account information database 14 15 // parameterless constructor 16 public Withdrawal() 17 { 18 // constructor body code 19 } // end constructor 20 21 // operations 22 // perform transaction 23 public void Execute() 24 { 25 // Execute method body code 26 } // end method Execute 27 } // end class Withdrawal |
This concludes our discussion of the basics of generating class files from UML diagrams. In the final Software Engineering Case Study section (Section 11.9), we demonstrate how to modify the code in Fig. 9.28 to incorporate the object-oriented concepts of inheritance and polymorphism, which we present in Chapters 10 and 11, respectively.
Software Engineering Case Study Self-Review Exercises
9.1 |
State whether the following statement is true or false, and if false, explain why: If an attribute of a class is marked with a minus sign (-) in a class diagram, the attribute is not directly accessible outside of the class. |
9.2 |
In Fig. 9.24, the association between the ATM and the Screen indicates:
|
9.3 |
Write C# code to begin implementing the design for class Account. |
Answers to Software Engineering Case Study Self-Review Exercises
9.1 |
True. The minus sign () indicates private visibility. |
|
9.2 |
b. |
|
9.3 |
The design for class Account yields the code in Fig. 9.29. Note that we include private instance variables availableBalance and totalBalance to store the data that properties AvailableBalance and TotalBalance, and methods Credit and Debit, will manipulate. Figure 9.29. C# code for class Account based on Figs. 9.23 and 9.24.
|
Preface
Index
Introduction to Computers, the Internet and Visual C#
Introduction to the Visual C# 2005 Express Edition IDE
Introduction to C# Applications
Introduction to Classes and Objects
Control Statements: Part 1
Control Statements: Part 2
Methods: A Deeper Look
Arrays
Classes and Objects: A Deeper Look
Object-Oriented Programming: Inheritance
Polymorphism, Interfaces & Operator Overloading
Exception Handling
Graphical User Interface Concepts: Part 1
Graphical User Interface Concepts: Part 2
Multithreading
Strings, Characters and Regular Expressions
Graphics and Multimedia
Files and Streams
Extensible Markup Language (XML)
Database, SQL and ADO.NET
ASP.NET 2.0, Web Forms and Web Controls
Web Services
Networking: Streams-Based Sockets and Datagrams
Searching and Sorting
Data Structures
Generics
Collections
Appendix A. Operator Precedence Chart
Appendix B. Number Systems
Appendix C. Using the Visual Studio 2005 Debugger
Appendix D. ASCII Character Set
Appendix E. Unicode®
Appendix F. Introduction to XHTML: Part 1
Appendix G. Introduction to XHTML: Part 2
Appendix H. HTML/XHTML Special Characters
Appendix I. HTML/XHTML Colors
Appendix J. ATM Case Study Code
Appendix K. UML 2: Additional Diagram Types
Appendix L. Simple Types
Index