ch05.htm

corba比较入门级的介绍详细间接了corba访问发布各种细节。

</UL>

<P>From this analysis, you can see that the system will include at least three major
classes: <TT>Bank</TT>, <TT>Account</TT>, and <TT>Customer</TT>. Now you need to
focus your attention on the attributes and behaviors of such objects.
<H4><FONT COLOR="#000077">Bank</FONT></H4>
<P>Several of the system requirements suggest behaviors that should be included in
the <TT>Bank</TT> class:

<UL>
	<LI>Supports multiple banks.<BR>
	<BR>
	
	<LI>Although not actually a behavior of a <TT>Bank</TT>, this capability requires
	that more than one <TT>Bank</TT> object can exist. Furthermore, in a CORBA application,
	this requirement suggests that a mechanism exist that can provide clients with visibility
	to <TT>Bank</TT> objects. One approach is to require <TT>Bank</TT>s to register with
	the Naming Service so they can be located by clients; another approach is to create
	a separate object--<TT>BankServer</TT>, for instance--that provides visibility to
	<TT>Bank</TT> objects. This application uses the latter approach.
</UL>



<BLOCKQUOTE>
	<P>
<HR>
<B>Note:</B>In a C++ or Java application that does not use CORBA, you can very well
	provide a static method of <TT>Bank</TT> that would return a list of <TT>Bank</TT>
	objects, which is a reasonable approach. However, because CORBA objects don't support
	static methods, an alternative approach--such as those mentioned previously--is required.
	
<HR>


</BLOCKQUOTE>


<UL>
	<LI>Supports multiple accounts within banks.<BR>
	<BR>
	
	<LI>This requirement suggests that a <TT>Bank</TT> maintain a list of its <TT>Account</TT>s,
	although this list might not necessarily be accessible to objects outside the <TT>Bank</TT>.<BR>
	<BR>
	
	<LI>Supports the capability to open (create) new accounts.<BR>
	<BR>
	
	<LI>This requirement suggests that a <TT>Bank</TT> support an operation such as <TT>createAccount()</TT>,
	which presumably will take as input a <TT>Customer</TT> (or group of <TT>Customer</TT>s)
	and perhaps an opening balance and will return a new <TT>Account</TT> object. In
	other words, <TT>Bank</TT> will provide the following operation:
</UL>


<DL>
	<DD><FONT COLOR="#0066FF"><TT>createAccount(customer : Customer, openingBalance :
	float) : Account</TT></FONT>
</DL>

<PRE></PRE>

<UL>
	<LI>Supports the capability to close (delete) existing accounts.<BR>
	<BR>
	
	<LI>Because an <TT>Account</TT> must first exist in order to be deleted, this behavior
	could actually belong either to the <TT>Bank</TT> class or to the <TT>Account</TT>
	class. For the sake of consistency with <TT>createAccount()</TT>, it is included
	in the <TT>Bank</TT> class.<BR>
	<BR>
	
	<LI><TT>deleteAccount()</TT>, as this operation might be called, doesn't require
	any information other than the <TT>Account</TT> to be deleted, so its signature might
	look like this:
</UL>


<DL>
	<DD><FONT COLOR="#0066FF"><TT>deleteAccount(account : Account) : void</TT></FONT>
</DL>

<PRE></PRE>


<BLOCKQUOTE>
	<P>
<HR>
<B>Note:</B>You will often encounter situations like the preceding one, where there
	is no clear answer as to where certain behavior should be placed. Use your best judgment,
	or sometimes even make an arbitrary decision. 
<HR>


</BLOCKQUOTE>


<UL>
	<LI>Supports the capability to enumerate a bank's accounts.<BR>
	<BR>
	
	<LI>It was suggested previously that a <TT>Bank</TT> would maintain a list of its
	<TT>Account</TT>s; this requirement suggests that the <TT>Bank</TT>'s <TT>Account</TT>s
	be made accessible to other objects. In a real-world system, access to <TT>Account</TT>
	information should probably be restricted, but because there is no such requirement
	in this system (yet), this operation is straightforward:
</UL>


<DL>
	<DD><FONT COLOR="#0066FF"><TT>getAccounts() : Account[]</TT></FONT>
</DL>

<PRE></PRE>

<UL>
	<LI>The <TT>[]</TT> notation indicates that <TT>listAccounts()</TT> returns an array
	of <TT>Account</TT> objects.
</UL>

<P>Additional attributes of a <TT>Bank</TT> might prove useful; for instance, the
<TT>Bank</TT> should probably have a name and perhaps an address. For this application,
these attributes will be kept simple:</P>
<PRE><FONT COLOR="#0066FF"><TT>name : string</TT>
<TT>address : string</TT>
</FONT></PRE>
<H4><FONT COLOR="#000077">BankServer</FONT></H4>
<P><TT>BankServer</TT> is a class that was unanticipated in the preliminary analysis
but popped up during your analysis of the <TT>Bank</TT> class. The <TT>BankServer</TT>
class is very simple, its only job being to provide visibility to <TT>Bank</TT> objects.
In order to provide this capability, the following operations are required: Register
a <TT>Bank</TT> with the <TT>BankServer</TT>, unregister a <TT>Bank</TT> from the
<TT>BankServer</TT>, and list all <TT>Bank</TT>s currently registered with the <TT>BankServer</TT>.
More formally, these operations are defined as follows:</P>
<PRE><FONT COLOR="#0066FF"><TT>registerBank(bank : Bank) : void</TT>
<TT>unregisterBank(bank : Bank) : void</TT>
<TT>getBanks() : Bank[]</TT>
</FONT></PRE>
<P>For the purposes of this application, no other capabilities are required of the
<TT>BankServer</TT> class.
<H4><FONT COLOR="#000077">Account</FONT></H4>
<P>The next class you will consider is the <TT>Account</TT>. This class implements
a great deal of the <TT>Bank</TT> application's initial functionality. Here is how
the <TT>Account</TT> class meets the requirements of the system design:

<UL>
	<LI>Supports multiple customers holding accounts.<BR>
	<BR>
	
	<LI>This capability is supported by a many-to-one relationship between <TT>Customer</TT>s
	and <TT>Account</TT>s, but it also implies that an <TT>Account</TT> object will support
	an operation that shows which <TT>Customer</TT>s are associated with that <TT>Account</TT>:
</UL>


<DL>
	<DD><FONT COLOR="#0066FF"><TT>getCustomers() : Customer[]</TT></FONT>
</DL>

<PRE></PRE>

<UL>
	<LI>Supports customers holding multiple accounts.<BR>
	<BR>
	
	<LI>This capability, coupled with the requirement to support multiple customers holding
	accounts, implies a many-to-many relationship between <TT>Customer</TT>s and <TT>Account</TT>s
	(rather than the many-to-one relationship mentioned previously). However, the actual
	functionality related to this requirement belongs in the <TT>Customer</TT> class.<BR>
	<BR>
	
	<LI>Supports the capability to determine an account's owner(s).<BR>
	<BR>
	
	<LI>This capability implies an operation that returns the <TT>Customer</TT>s associated
	with a given <TT>Account</TT>. Incidentally, this operation was already provided
	previously.<BR>
	<BR>
	
	<LI>Supports the capability to withdraw funds from an account.<BR>
	<BR>
	
	<LI>The capability to withdraw funds from an <TT>Account</TT> would most likely come
	in the form of a <TT>withdraw()</TT> operation, which takes the amount to be withdrawn
	as an argument. For the sake of convenience, this operation will return the new balance
	of the <TT>Account</TT>:
</UL>


<DL>
	<DD><FONT COLOR="#0066FF"><TT>withdraw(amount : float) : float</TT></FONT>
</DL>

<PRE></PRE>

<UL>
	<LI>Supports the capability to deposit funds into an account.<BR>
	<BR>
	
	<LI>Depositing funds has the same semantics as withdrawing funds; the amount to be
	deposited is an argument, and the return value is the new balance of the <TT>Account</TT>:
</UL>


<DL>
	<DD><FONT COLOR="#0066FF"><TT>deposit(amount : float) : float</TT></FONT>
</DL>

<PRE></PRE>

<UL>
	<LI>Supports the capability to transfer funds between accounts within a single bank.<BR>
	<BR>
	
	<LI>Transferring funds between <TT>Account</TT>s is slightly more complicated than
	simply depositing or withdrawing funds. In this case, the second <TT>Account</TT>
	must also be specified. The amount of the transaction must be specified as well,
	of course. As with the <TT>deposit()</TT> and <TT>withdraw()</TT> operations, the
	<TT>transfer()</TT> operation will return the new balance of the <TT>Account</TT>
	(meaning the <TT>Account</TT> from which the funds are transferred):
</UL>


<DL>
	<DD><FONT COLOR="#0066FF"><TT>transfer(other : Account, amount : float) : float</TT></FONT>
</DL>

<PRE></PRE>

<UL>
	<LI>Supports the capability to transfer funds between accounts in different banks.<BR>
	<BR>
	
	<LI>This capability is already supported by the <TT>transfer()</TT> operation because
	the <TT>Account</TT> passed to that operation can belong to any <TT>Bank</TT>. Therefore,
	it is unnecessary to provide a separate operation for transferring funds between
	<TT>Account</TT>s in different <TT>Bank</TT>s.<BR>
	<BR>
	
	<LI>Supports checking accounts (which don't gain interest).<BR>
	<BR>
	
	<LI>Supports savings accounts (which do gain interest).
</UL>