Section 9.14. (Optional) Software Engineering Case Study: Starting to Program the Classes of the ATM System


9.14. (Optional) Software Engineering Case Study: Starting to Program the Classes of the ATM System

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 48, we introduced object-oriented programming in Visual Basic. In Chapter 9, 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 Visual Basic code. In the final Software Engineering Case Study section (Section 11.8), we modify the code to incorporate the object-oriented concepts of inheritance and polymorphism. We present the full Visual Basic code implementation in Appendix J.

Visibility

We now apply access modifiers to the members of our classes. In Chapter 9, 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 9, 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.22 shows our updated class diagram with visibility markers included. [Note: We do not include any operation parameters in Fig. 9.22. This is perfectly normal. Adding visibility markers does not affect the parameters already modeled in the class diagrams of Figs. 7.247.27.]

Figure 9.22. Class diagram with visibility markers.


Navigability

Before we begin implementing our design in Visual Basic, we introduce an additional UML notation. The class diagram in Fig. 9.23 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.15). When implementing a system designed using the UML, you 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.23 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.23. Class diagram with navigability arrows.


Like the class diagram of Fig. 4.22, the one in Fig. 9.23 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.9 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.23, 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.8, 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.22 and Fig. 9.23 into Visual Basic code. This code will represent the "skeleton" of the system. In Chapter 11, we modify the code to incorporate the objectoriented concept of inheritance. In Appendix J, ATM Case Study Code, we present the complete working Visual Basic 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.22. We use this figure to determine the attributes and operations of the class. We use the UML model in Fig. 9.23 to determine the associations among classes. We follow the following four guidelines for each class:

  1. Use the name located in the first compartment of a class in a class diagram to declare the class as a Public class with an empty parameterless constructor. We include this constructor simply as a placeholder to remind us that most classes will need one or more constructors. In Appendix J, when we complete a working version of this class, we add any necessary arguments and code to the body of the constructor. Class Withdrawal initially yields the code in Fig. 9.24. [Note: If we find that the class's instance variables require only default initialization, we will remove the empty parameterless constructor because it is unnecessary.]

    Figure 9.24. Initial Visual Basic code for class Withdrawal based on Figs. 9.22 and 9.23.

     1  ' Class Withdrawal represents an ATM withdrawal transaction 2  Public Class Withdrawal 3     ' parameterless constructor 4     Public Sub New() 5        ' constructor body code 6     End Sub ' New 7  End Class ' Withdrawal 

  2. Use the attributes located in the class's second compartment to declare the instance variables. The Private attributes accountNumber and amount of class Withdrawal yield the code in Fig. 9.25.

    Figure 9.25. Visual Basic code incorporating Private variables for class Withdrawal based on Figs. 9.22 and 9.23.

      1  ' Class Withdrawal represents an ATM withdrawal transaction  2  Public Class Withdrawal  3     ' attributes  4     Private accountNumber As Integer ' account to withdraw funds from  5     Private amount As Decimal ' amount to withdraw from account  6  7     ' parameterless constructor  8     Public Sub New()  9        ' constructor body code 10     End Sub ' New 11  End Class ' Withdrawal 

  3. Use the associations described in the class diagram to declare references (or pointers, where appropriate) to other objects. According to Fig. 9.23, Withdrawal can access one object of class Screen, one object of class Keypad, one object of class CashDispenser and one object of class BankDatabase. Class Withdrawal must maintain references to these objects for sending messages to them, so lines 811 of Fig. 9.26 declare four references as Private instance variables. In the implementation of class Withdrawal in Appendix J, a constructor initializes these instance variables with references to the actual objects.

    Figure 9.26. Visual Basic code incorporating Private reference handles for the associations of class Withdrawal based on Figs. 9.22 and 9.23.

      1  ' Class Withdrawal represents an ATM withdrawal transaction  2  Public Class Withdrawal  3     ' attributes  4     Private accountNumber As Integer ' account to withdraw funds from  5     Private amount As Decimal ' amount to withdraw  6  7     ' references to associated objects  8     Private screenHandle As Screen ' ATM's screen  9     Private keypadHandle As Keypad ' ATM's keypad 10     Private cashDispenserHandle As CashDispenser ' ATM's cash dispenser 11     Private bankDatabaseHandle As BankDatabase ' account info database 12 13     ' parameterless constructor 14     Public Sub New() 15        ' constructor body code 16     End Sub ' New 17  End Class ' Withdrawal 

  4. Use the operations located in the third compartment of Fig. 9.22 to declare the shells of the methods. If we have not yet specified a return type for an operation, we declare the method with keyword Sub. Refer to the class diagrams of Figs. 7.247.27 to declare any necessary parameters. Adding the Public operation Execute (which has an empty parameter list) in class Withdrawal yields the code in line 19 of Fig. 9.27. [Note: We code the bodies of methods when we implement the complete ATM system in Appendix J.]

Figure 9.27. Visual Basic code incorporating method Execute in class Withdrawal based on Figs. 9.22 and 9.23.

  1  ' Class Withdrawal represents an ATM withdrawal transaction  2  Public Class Withdrawal  3     ' attributes  4     Private accountNumber As Integer ' account to withdraw funds from  5     Private amount As Decimal ' amount to withdraw  6  7     ' references to associated objects  8     Private screenHandle As Screen ' ATM's screen  9     Private keypadHandle As Keypad ' ATM's keypad 10     Private cashDispenserHandle As CashDispenser ' ATM's cash dispenser 11     Private bankDatabaseHandle As BankDatabase ' account info database 12 13     ' parameterless constructor 14     Public Sub New() 15        ' constructor body code 16     End Sub ' New 17 18     ' operations 19     Public Sub Execute() 20        ' Execute method body code 21     End Sub ' Execute 22  End Class ' Withdrawal 

Software Engineering Observation 9.7

Many UML modeling tools can convert UML-based designs into Visual Basic code, considerably speeding the implementation process. For more information on these "automatic" code generators, refer to the Web resources listed at the end of Section 3.9.


This concludes our discussion of the basics of generating class files from UML diagrams. In the final Software Engineering Case Study section (Section 11.8), we demonstrate how to modify the code in Fig. 9.27 to incorporate the object-oriented concepts of inheritance and polymorphism in Chapter 11.

Software Engineering Case Study Self-Review Exercises

9.1

State whether the following statement is true or false, and iffalse, 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.23, the association between the ATM and the Screen indicates that:

  1. we can navigate from the Screen to the ATM

  2. we can navigate from the ATM to the Screen

  3. Both a and b; the association is bidirectional

  4. None of the above

9.3

Write Visual Basic 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. We've mentioned "friendship" as an exception to private visibility. Friendship is discussed in Chapter 10.

9.2

b.

9.3

The design for class Account yields the code in Fig. 9.28. 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.28. Visual Basic code for class Account based on Figs. 9.22 and 9.23.

  1  ' Represents a bank account.  2  Public Class Account  3     Private accountNumber As Integer ' account number  4     Private pin As Integer ' PIN for authentication  5     Private availableBalance As Decimal ' available withdrawal amount  6     Private totalBalance As Decimal ' funds available + pending deposit  7  8     ' parameterless constructor  9     Public Sub New() 10        ' constructor body code 11     End Sub ' New 12 13     ' validates user PIN 14     Public Function ValidatePIN() As Boolean 15        ' ValidatePIN method body code 16     End Function ' ValidatePIN 17 18     ' property AvailableBalance 19     Public ReadOnly Property AvailableBalance() As Decimal 20        ' AvailableBalance property body code 21     End Property ' AvailableBalance 22 23     ' property TotalBalance 24     Public ReadOnly Property TotalBalance() As Decimal 25        ' TotalBalance property body code 26     End Property ' TotalBalance 27 28     ' credits the account 29     Public Sub Credit() 30        ' Credit method body code 31     End Sub ' Credit 32 33     ' debits the account 34     Public Sub Debit() 35        ' Debit method body code 36     End Sub ' Debit 37  End Class ' Account 



Visual BasicR 2005 for Programmers. DeitelR Developer Series
Visual Basic 2005 for Programmers (2nd Edition)
ISBN: 013225140X
EAN: 2147483647
Year: 2004
Pages: 435

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net