ch05.htm

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

		<TD ALIGN="LEFT">Private attributes and operations of a class are available only to that class, excluding
			even subclasses.</TD>
	</TR>
	<TR ALIGN="LEFT" VALIGN="TOP">
		<TD ALIGN="LEFT"><TT>/</TT></TD>
		<TD ALIGN="LEFT">Derived attribute</TD>
		<TD ALIGN="LEFT">A derived attribute is an attribute that is dependent on another attribute. For example,
			although a person's age can be considered an attribute, it is dependent on the current
			date and the person's birth date. Derived attributes can also be public, protected,
			or private.</TD>
	</TR>
	<TR ALIGN="LEFT" VALIGN="TOP">
		<TD ALIGN="LEFT"><TT>$</TT></TD>
		<TD ALIGN="LEFT">Class attribute/operation</TD>
		<TD ALIGN="LEFT">A class attribute or operation can be accessed without an instance of the class.
			Class attributes and operations are analogous to static class members in C++ or Java.
			Class attributes and operations can also be public, protected, or private.</TD>
	</TR>
</TABLE>

<H4><FONT COLOR="#000077">Associations</FONT></H4>
<P>A class typically does not exist and act within a vacuum; generally it will interact
with other classes as well. Thus, it can be said that a class has relationships to
other classes. UML refers to these relationships as associations. A class has an
<I>association</I> with another class if it uses services of that class in some way.
Optionally, the association can be given a name; additionally, the roles that each
class plays in an association can be given names as well. Figure 5.2 illustrates
the notation for an association, which is indicated by a line drawn between two classes.</P>
<P><B>New Term: </B>An <I>association</I> between two classes means that the classes
are somehow related. Typically this means that one of the classes uses services of
the other or has a member which is an instance of the other class.</P>
<P>An association can also have <I>multiplicity,</I> meaning that a certain number
of one class can be associated to a certain number of the other class. For example,
Figure 5.2 indicates that a <TT>Customer</TT> can hold more than one <TT>Account</TT>.
Furthermore, an <TT>Account</TT> can be held by more than one <TT>Customer</TT> (as
is the case with joint <TT>Account</TT>s). Finally, an <TT>Account</TT> can be owned
by only one <TT>Bank</TT>. Essentially, there are three types of multiplicities in
relationships:

<UL>
	<LI>A <I>one-to-one</I> association is an association between exactly one of each
	type of object.<BR>
	<BR>
	
	<LI>A <I>one-to-many</I> (or, conversely, <I>many-to-one</I>) association is an association
	between exactly one of one type of object and zero or more of the other type.<BR>
	<BR>
	
	<LI>A <I>many-to-many</I> association is an association between zero or more of each
	type of object.
</UL>

<P><A HREF="javascript:popUp('02.jpg')"><B>Figure 5.2.</B></A> <I>UML class associations.</I>
<B><I><BR>
<BR>
</I>New Term: </B><I>Multiplicity</I> refers to the number of classes involved in
an association. Examples of multiplicity are <I>one-to-one,</I> <I>one-to-many,</I>
and <I>many-to-many.</I></P>
<P>Specifying multiplicity is optional; this information is sometimes omitted for
the sake of clarity in high-level class diagrams. However, you need to specify multiplicities
of associations before implementing your design, as the details of the implementation
depend on this multiplicity information.
<H4><FONT COLOR="#000077">Inheritance</FONT></H4>
<P>Inheritance is actually a special case of an association. It has the same meaning
as you would expect in an object-oriented language; a class that inherits from (or
derives from) another class (recall from Day 3 that this is referred to as the <I>superclass</I>)
inherits the nonprivate attributes and methods of that superclass. Again recalling
from Day 3, remember that the <I>derived class</I> can be substituted wherever its
base class is required (as a parameter to a method call, for instance); this behavior
is known as <I>polymorphism.</I></P>
<P>In UML, inheritance is represented as an arrow drawn from the derived class to
its base class. UML supports the notion of multiple inheritance as well; in this
case, arrows are drawn from the derived class to each of its base classes. Examples
of UML expressions of inheritance associations are illustrated in Figure 5.3.
<H3><A NAME="Heading5"></A><FONT COLOR="#000077">Basic Methodology</FONT></H3>
<P>Again, it is far beyond the scope of this book to discuss object-oriented analysis
and design methodologies in depth. However, a good first step in the analysis phase
is to identify the objects, or classes, that compose the system. Many objects in
the system are easy to identify; one method is to first write a description of the
system and its function. When the description is complete, review it and look for
nouns. When you encounter a noun, chances are that it will represent an object in
the system. For example, in the sentence &quot;Customers hold accounts in a bank,&quot;
potential object candidates are <TT>Customer</TT>, <TT>Account</TT>, and <TT>Bank</TT>.
This process, sometimes called object discovery, is very useful in understanding
the scope of a particular system. <BR>
<BR>
<A HREF="javascript:popUp('03.jpg')"><B>Figure 5.3.</B></A> <I>UML inheritance associations.</I>
<BR>
<BR>
After the candidate objects have been identified, you determine the relationships
between the classes. These relationships are often expressed in the form of verbs
in the system description. In the preceding example, for instance, you see that <TT>Customer</TT>s
hold <TT>Account</TT>s, suggesting a relationship between these two classes. Furthermore,
you can see that <TT>Account</TT>s are part of a <TT>Bank</TT>, although it is not
clear precisely what the relationship is between an <TT>Account</TT> and a <TT>Bank</TT>.
Associations between classes don't have to be named, although named associations
often provide additional insight into the design of a system.


<BLOCKQUOTE>
	<P>
<HR>
<B>Note:</B>If you infer from this process that classes ought to be named with nouns
	and associations ought to be named with verbs, you are correct. This naming scheme
	is a generally accepted convention of object-oriented analysis. Another convention
	is to give singular names to classes, for example, <TT>Account</TT> rather than <TT>Accounts</TT>.
	
<HR>


</BLOCKQUOTE>

<P>After the classes and their associations have been identified, you'll want to
spend some time determining the attributes and operations within classes. This requires
more thought than the first two steps, and chances are you won't get it right the
first time. In fact, the entire process is an iterative one. While identifying relationships
between classes, you might discover new classes, or while determining operations
on objects, you might discover new associations or new classes. In fact, your design
might change drastically from start to finish; this is a normal aspect of software
design. Multiple iterations of this process help you create a robust design, and
creating a solid design early on will help you avoid headaches later on in the development
phase. (It is often observed that the later in the development process a change needs
to be made, the more costly that change will be. Therefore, it is to your advantage
to spend a good amount of time refining your design.)
<H3><A NAME="Heading6"></A><FONT COLOR="#000077">UML Summary</FONT></H3>
<P>UML is a very broad-reaching tool that encompasses not only the static design
of a system (such as the class diagram) but also the dynamic design (including use
cases, state transition diagrams, and other tools). Because this book can barely
scratch the surface of UML and its functionality as a design tool, you should explore
either the Rational Software Corporation Web site (provided at the beginning of this
section) or one of several other sources for more information on UML.
<H2><A NAME="Heading7"></A><FONT COLOR="#000077">The Bank Example</FONT></H2>
<P>The next several chapters center around a single example--an electronic banking
system. In this chapter, you'll use object-oriented analysis to define the objects
in the system and create an application object model. In subsequent chapters, you'll
implement the system's basic functionality and then implement additional capabilities
and robustness. In the end, you'll have built a complex (although still trivial by
enterprise application standards) CORBA application. Along the way, you'll discover
some of the issues involved in building such a system.</P>
<P>The <TT>Bank</TT> application supports electronic banking. It allows for multiple
banks, multiple accounts (checking and savings), multiple customers, opening and
closing accounts, and the withdrawal, deposit, and transfer of funds between accounts.
(More capabilities are added in later chapters, but the basic <TT>Bank</TT> application
begins with this functionality.)
<H3><A NAME="Heading8"></A><FONT COLOR="#000077">Defining System Requirements and
Capabilities</FONT></H3>
<P>The first step in designing any system is to determine what the system needs to
do. Depending on the nature of the application, this process can involve meeting
with customers and/or potential users of the system, conducting market research,
or just providing a solution to a particular problem. Requirements often have to
be refined or clarified later, so don't be surprised if you find yourself revisiting
this step again.</P>
<P>For the <TT>Bank</TT> example, the capabilities of the basic system are defined
as follows:

<UL>
	<LI>Supports multiple banks<BR>
	<BR>
	
	<LI>Supports multiple accounts within banks<BR>
	<BR>
	
	<LI>Supports multiple customers holding accounts<BR>
	<BR>
	
	<LI>Supports customers holding multiple accounts<BR>
	<BR>
	
	<LI>Supports the capability to open (create) new accounts<BR>
	<BR>
	
	<LI>Supports the capability to close (delete) existing accounts<BR>
	<BR>
	
	<LI>Supports the capability to enumerate a bank's accounts<BR>
	<BR>
	
	<LI>Supports the capability to determine an account's owner(s)<BR>
	<BR>
	
	<LI>Supports the capability to withdraw funds from an account<BR>
	<BR>
	
	<LI>Supports the capability to deposit funds into an account<BR>
	<BR>
	
	<LI>Supports the capability to transfer funds between accounts within a single bank<BR>
	<BR>
	
	<LI>Supports the capability to transfer funds between accounts in different banks<BR>
	<BR>
	
	<LI>Supports checking accounts (which don't gain interest)<BR>
	<BR>
	
	<LI>Supports savings accounts (which do gain interest)
</UL>

<P>Notice that each line item describes one capability; for instance, the capabilities
to create and delete accounts compose separate line items. This convention facilitates
the development of testing requirements because the functionality described in each
line item is individually testable. Note also that when analyzing system requirements,
it is generally good practice to ensure that each capability is indeed testable.
For example, a requirement such as &quot;Must be easy to use&quot; is subjective
and so probably not testable. Avoid vague requirements like this; a more useful set
of requirements would list specific user-interface features that one might consider
&quot;easy to use.&quot;
<H3><A NAME="Heading9"></A><FONT COLOR="#000077">Defining System Objects</FONT></H3>
<P>Now that you have arrived at a set of system requirements, you are ready to determine
what objects exist in the system. As suggested previously, you do this by scanning
the application description and requirements for nouns. Nouns that you'll encounter
are <I>bank</I>, <I>account</I> (specifically, <I>checking</I> <I>account</I> and
<I>savings</I> <I>account</I>), <I>customer</I>, and <I>funds</I>. All these are
candidates for inclusion in the object model (or class diagram). One way to determine
whether a class should be created for a candidate is to ask yourself this question:
Is there an identity or behavior associated with this object? If the answer is yes,
then the candidate should be an object. Try this test on your list of candidate objects:

<UL>
	<LI><I>Bank:</I> A bank does indeed have identity; the Eighth National Bank is distinguishable
	from the CORBA Developers Credit Union. Furthermore, a bank has associated behavior;
	it can open and close accounts on behalf of customers, among other things. Therefore,
	you might conclude that <TT>Bank</TT> is indeed an object in your system.<BR>
	<BR>
	
	<LI><I>Account:</I> Accounts, like banks, have identity as well; they can be distinguished
	from each other. Also, accounts have associated behavior; funds can be deposited
	in, withdrawn from, and transferred between accounts. Therefore, <TT>Account</TT>
	will be an object in the system as well.<BR>
	<BR>
	
	<LI><I>Customer:</I> Customers certainly have identity--John Doe can be distinguished
	from Joe Blow, the person holding Social Security number 123-45-6789 can be distinguished
	from the person holding Social Security number 234-56-7890, and so on. Customers
	don't have any associated behavior, at least for the purposes of this application,
	but their identity alone suggests that <TT>Customer</TT> ought to be an object in
	the system.<BR>
	<BR>
	
	<LI><I>Funds:</I> Funds don't really have identity--one $150.00 amount is, practically
	speaking, indistinguishable from another $150.00 amount. There is no behavior directly
	associated with funds either; they can be deposited in, withdrawn from, and transferred
	between accounts, but this is a behavior of the account rather than the funds themselves.
	Finally, funds can be easily represented by a simple floating-point value rather
	than by a class. For these reasons, you probably do not want to include funds in
	the application's object model.