ch05.htm

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

<P>These requirements suggest that specializations of the <TT>Account</TT> class
will exist. In particular, you will use <TT>CheckingAccount</TT> and <TT>SavingsAccount</TT>.
Although one could argue that the account type is actually an attribute of the <TT>Account</TT>
class, for the purposes of this application, the <TT>CheckingAccount</TT> and <TT>SavingsAccount</TT>
will be subclasses of <TT>Account</TT>. This approach makes sense because a <TT>SavingsAccount</TT>
has attributes and behaviors not applicable to a <TT>CheckingAccount</TT>, and vice
versa. Because these classes exhibit different behaviors, it is probably better to
create separate classes for each of them.</P>
<P>Finally, the <TT>Account</TT> should probably contain some additional attributes
to make it interesting. First, it should have an account number so that it can be
identified by a human customer (and also to identify the account on printed checks);
it would also be nice to retain the creation date of the account. Note that these
capabilities were not spelled out in the requirements, so you could technically do
without them. However, they are likely to become useful sooner or later, hence their
inclusion here:</P>
<PRE><FONT COLOR="#0066FF"><TT>accountNumber : string</TT>
<TT>creationDate : date</TT>
<TT>getAccountNumber() : string</TT>
<TT>getCreationDate() : date</TT>
</FONT></PRE>
<P>Notice that the operations listed here are redundant with the attributes. This
is in keeping with the typical practice of making attributes private and allowing
access to those attributes through accessor methods. Although you can choose not
to follow this convention for non-CORBA applications, access to attributes of CORBA
objects always takes place through accessor methods. Remember, though, that one advantage
to this convention is that it allows you, if you so desire, to restrict external
access to object attributes to reading only. Such is the case in this example, as
only accessors--no mutators--are provided. This ensures that attributes that should
be immutable--such as creation date and account number--cannot be altered.
<H4><FONT COLOR="#000077">CheckingAccount</FONT></H4>
<P><TT>CheckingAccount</TT>, which derives from <TT>Account</TT>, provides additional
attributes and behaviors. However, at this point in the application design, <TT>CheckingAccount</TT>
adds nothing new to <TT>Account</TT>.
<H4><FONT COLOR="#000077">SavingsAccount</FONT></H4>
<P><TT>SavingsAccount</TT>, which also derives from <TT>Account</TT>, provides additional
attributes and behaviors as well. In particular, a <TT>SavingsAccount</TT> has an
associated interest rate, along with an accessor and mutator for this attribute:</P>
<PRE><FONT COLOR="#0066FF"><TT>interestRate : float</TT>
<TT>getInterestRate() : float</TT>
<TT>setInterestRate(newRate : float) : float
setInterestRate()</TT> </FONT></PRE>
<P>returns the old interest rate as a convenience to the user.
<H4><FONT COLOR="#000077">Customer</FONT></H4>
<P>The <TT>Customer</TT> in this application is a relatively simple class because
it is mostly a consumer of services offered by other classes. Only one of the system
requirements falls to the <TT>Customer</TT> class's responsibility.

<UL>
	<LI>Supports customers holding multiple accounts.<BR>
	<BR>
	
	<LI>Because a customer can hold multiple accounts, it makes sense that the <TT>Customer</TT>
	class would support an operation that enumerates <TT>Account</TT>s held by that <TT>Customer</TT>:
</UL>


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

<PRE></PRE>
<P>Additionally, to make the <TT>Customer</TT> interesting, a few attributes will
be added to provide the <TT>Customer</TT>'s name, Social Security number (as a means
of identification), address, and mother's maiden name (for security reasons and just
plain old tradition):</P>
<PRE><FONT COLOR="#0066FF"><TT>name : string</TT>
<TT>socialSecurityNumber : string</TT>
<TT>address : string</TT>
<TT>mothersMaidenName : string</TT>
</FONT></PRE>
<P>To keep things simple, the address attribute is simplified into a string rather
than street address, city, state, ZIP code, and so on. However, providing a separate
<TT>Address</TT> class (which could possibly have derived classes as well) might
not be a bad idea for a more robust system.
<H4><FONT COLOR="#000077">A Word About Object Identity</FONT></H4>
<P>Notice that nowhere in the previously described classes is there any mention of
attributes whose purpose is to uniquely identify the object. (The possible exceptions
are the <TT>Customer</TT>'s Social Security number and the <TT>Account</TT>'s account
number, which will be discussed in a moment.) This is because object-oriented analysis
makes the assumption that objects implicitly have unique identity, making an identity
attribute redundant. Therefore, at the analysis level, classes should not contain
attributes that exist solely to identify the object.</P>
<P>There are exceptions to this rule. Most notably, a <TT>Customer</TT> has a <TT>socialSecurityNumber</TT>--an
attribute that exists primarily to uniquely identify the <TT>Customer</TT>. However,
this type of identity attribute is often used because it corresponds to a real-world
concept. A person, for example, has a unique identity simply by virtue of the fact
that he or she exists. The Social Security number, because it is a ubiquitous method
of identifying people (at least in the U.S.A.), is often convenient to use in software
applications.</P>
<P>Other identification attributes exist as well and are perfectly legitimate for
use in an application design. Another example is the account number in the <TT>Account</TT>
class. Account numbers are often used to identify an account on a printed check or
on a statement sent to the customer.</P>
<P>The key to understanding when identity attributes are appropriate is this: An
artificial identity attribute has no place in a class description, whereas an identity
attribute that exists in the real world--such as a <TT>socialSecurityNumber</TT>--is
acceptable and even useful.
<H3><A NAME="Heading10"></A><FONT COLOR="#000077">Creating an Application Class Diagram</FONT></H3>
<P>Now that you've identified the components (classes) of the system and described
their attributes and behaviors, you're ready to put them together into a cohesive
class diagram. The class diagram shows not only the classes themselves (including,
if desired, their attributes or operations) but also the relationships between classes.</P>
<P>Figure 5.4 shows the initial class diagram for the <TT>Bank</TT> application.
(You'll be making changes to the class diagram from time to time as the system design
evolves throughout the next few chapters.) Notice that this diagram introduces the
UML notation for class inheritance; the <TT>SavingsAccount</TT> and <TT>CheckingAccount</TT>
classes both inherit from the <TT>Account</TT> class.</P>
<P>Again, it is stressed that the analysis and design phase is an iterative process.
You will often find yourself going back and tweaking various aspects of the design
as you discover features that were left out or as you learn (stumble across) a more
elegant way of doing things. Revisiting and making changes to work you've already
completed is quite normal in this stage of the game. Strive for the highest possible
quality system design; when you begin implementing the system, sweeping changes to
the design become much more costly. Better to spend more time on it now, during the
design phase, when making changes is much cheaper. <BR>
<BR>
<A HREF="javascript:popUp('04.jpg')"><B>Figure 5.4.</B></A> <I>The </I><TT>Bank</TT><I>
application class diagram.</I>
<H3><A NAME="Heading11"></A><FONT COLOR="#000077">For Further Study...</FONT></H3>
<P>Of course, there is much, much more to object-oriented analysis and design than
is covered here. Also, a very important part of object-oriented methodology is the
development of <I>use cases,</I> which describe scenarios in which various parts
of the system interact. These scenarios contain <I>actors,</I> such as a user or
another object, that act on other objects. Use cases describe how an actor interacts
with the system, what the results are, and the order in which these events occur.
There are many possible use cases for a single scenario; for example, for a given
dialog box, there might be a use case for when the user enters valid data and a separate
use case for when the user enters invalid data.</P>
<P>Another powerful tool of object-oriented analysis and design is the <I>design
pattern.</I> Design patterns can be thought of as building blocks for more complex
object-oriented constructs. For instance, one common design pattern--one with which
you might already be familiar--is the <I>model-view</I> pattern. In this pattern,
one object, called a <I>model,</I> represents a piece of data or concept. Another
object, called a <I>view,</I> tells a model that it wants to receive updates whenever
the model's state changes. An example of a model class is a <TT>TemperatureSensor</TT>,
which monitors the outdoor temperature. A view class, such as <TT>TemperatureDisplay</TT>,
might be a view of the <TT>TemperatureSensor</TT> class, meaning that when the <TT>TemperatureSensor</TT>
detects a change in the outdoor temperature, it notifies the <TT>TemperatureDisplay</TT>
of the change. The <TT>TemperatureDisplay</TT> obtains and displays the new temperature
information. A model might have multiple views, as well; in this case, the <TT>TemperatureSensor</TT>
notifies multiple <TT>TemperatureDisplays</TT> when the outdoor temperature changes.</P>
<P>A number of excellent books have long been available on subjects such as use cases,
design patterns, and other important object-oriented concepts. Again, you are encouraged
to explore these topics in depth; knowledge of such concepts pay off in designing
any type of system--not just CORBA applications.
<H2><A NAME="Heading12"></A><FONT COLOR="#000077">Summary</FONT></H2>
<P>In this chapter, you took what was essentially a crash course in object-oriented
analysis and design. You learned a bit about the Unified Modeling Language, its notation,
and the basic methodologies involved. You applied these concepts to the design of
a basic <TT>Bank</TT> application. In the analysis and design phase, not much attention
is given to the details of implementation; in fact, it is recommended that you avoid
implementation details at this stage of application development. A system design
that does not depend on such details enjoys greater flexibility than a design that
is dependent on the details of a particular implementation.</P>
<P>In the analysis and design phase, you performed three major steps:

<UL>
	<LI>Investigated and defined the requirements for the system.<BR>
	<BR>
	
	<LI>Identified the potential classes that compose the system.<BR>
	<BR>
	
	<LI>Mapped the system requirements to class attributes and operations.<BR>
	<BR>
	
	<LI>Created a class diagram that integrated the classes in the system into a coherent
	model.
</UL>

<H3><A NAME="Heading13"></A><FONT COLOR="#000077">What Comes Next?</FONT></H3>
<P>In the final part of the design phase--on Day 6, &quot;Implementing Basic Application
Capabilities&quot;--you'll translate the system design into an IDL specification.
The IDL will be used as--you guessed it--a baseline for the system implementation.
You'll then proceed to do exactly this--implement the system's basic capabilities.
Future days will be spent enhancing the basic functionality.
<H2><A NAME="Heading14"></A><FONT COLOR="#000077">Q&amp;A</FONT></H2>

<DL>
	<DD><B>Q In the <TT>Bank</TT> application, what's to prevent someone from transferring
	funds between accounts without authorization?</B><BR>
	<B><BR>
	A</B> The short answer is this: absolutely nothing. This application, being an oversimplification
	of a real-world bank system, makes no attempts at providing security of any kind.
	Obviously, in a production system, there would have to be security measures in place
	to prevent this sort of thing. (If you're truly ambitious, design such a mechanism
	as an exercise.)<BR>
	<B><BR>
	Q What use are use cases?<BR>
	<BR>
	A</B> Use cases are a powerful tool in system design; in addition to helping the
	system architects/designers/developers better understand how the system works, the
	practice of building use cases can often uncover scenarios that may not have been
	anticipated. Murphy's Law being what it is, a user will likely uncover all unanticipated
	scenarios--usually with undesirable results--so it is always better for the application
	designers to find them first.
</DL>

<H2><A NAME="Heading15"></A><FONT COLOR="#000077">Workshop</FONT></H2>
<P>The following section will help you test your comprehension of the material presented
in this chapter and put what you've learned into practice. You'll find the answers
to the quiz and exercise in Appendix A.
<H3><A NAME="Heading16"></A><FONT COLOR="#000077">Quiz</FONT></H3>

<DL>
	<DD><B>1</B>. Identify the potential objects in the system described here: An ordering
	system allows customers to order products from a particular company. Each order consists
	of one or more line items, each of which identifies a quantity and a particular product.
	Each product, in turn, has an associated price.<BR>
	<B><BR>
	2</B>. What is UML and what is it good for?<BR>
	<B><BR>
	3</B>. For an order processing system design, one requirement given is &quot;must
	be fast.&quot; Is this a reasonable expression of this requirement, or could it be
	made better? If so, how?
</DL>

<H3><A NAME="Heading17"></A><FONT COLOR="#000077">Exercise</FONT></H3>
<P>Modify the system design so that a <TT>Bank</TT> consists of <TT>Branch</TT>es,
each of which owns some of the <TT>Customer</TT> <TT>Account</TT>s. Draw the class
diagram for the modified design.<FONT COLOR="#000077"></FONT></P>
<CENTER>
<P>
<HR>
<A HREF="../ch04/ch04.htm"><IMG SRC="../button/previous.gif" WIDTH="128" HEIGHT="28"
ALIGN="BOTTOM" ALT="Previous chapter" BORDER="0"></A><A HREF="../ch06/ch06.htm"><IMG
SRC="../button/next.gif" WIDTH="128" HEIGHT="28" ALIGN="BOTTOM" ALT="Next chapter"
BORDER="0"></A><A HREF="../index.htm"><IMG SRC="../button/contents.gif" WIDTH="128"
HEIGHT="28" ALIGN="BOTTOM" ALT="Contents" BORDER="0"></A> <BR>
<BR>
<BR>
<IMG SRC="../button/corp.gif" WIDTH="284" HEIGHT="45" ALIGN="BOTTOM" ALT="Macmillan Computer Publishing USA"
BORDER="0"></P>

<P>&#169; <A HREF="../copy.htm">Copyright</A>, Macmillan Computer Publishing. All
rights reserved.
</CENTER>


</BODY>

</HTML>