?? chapb-0.htm
字號:
<HTML><HEAD><TITLE>Guide to Notation</TITLE><SCRIPT>function setFocus() { if ((navigator.appName != "Netscape") && (parseFloat(navigator.appVersion) == 2)) { return; } else { self.focus(); }}</SCRIPT></HEAD><BODY BGCOLOR="#FFFFFF" onLoad="setFocus()";><A NAME="top"></A><A NAME="chapter_notation"></A><P>We use diagrams throughout the book to illustrate important ideas.Some diagrams are informal, like a screen shot of a dialog box or aschematic showing a tree of objects. But the design patterns inparticular use more formal notations to denote relationships andinteractions between classes and objects. This appendix describesthese notations in detail.</P><A NAME="auto1000"></A><P>We use three different diagrammatic notations:</P><OL><A NAME="auto1001"></A><LI>A <STRONG>class diagram</STRONG> depicts classes, their structure, andthe static relationships between them.</LI><A NAME="auto1002"></A><P></P><A NAME="auto1003"></A><LI>An <STRONG>object diagram</STRONG> depicts a particular object structureat run-time.</LI><A NAME="auto1004"></A><P></P><A NAME="auto1005"></A><LI>An <STRONG>interaction diagram</STRONG> shows the flow of requests betweenobjects.</LI></OL><A NAME="auto1006"></A><P>Each design pattern includes at least one class diagram. Theother notations are used as needed to supplement the discussion.The class and object diagrams are based on OMT (Object ModelingTechnique) [<A HREF="bibfs.htm#rumbaugh_omt" TARGET="_mainDisplayFrame">RBP+91</A>, <A HREF="bibfs.htm#rumbaugh_omt_joop" TARGET="_mainDisplayFrame">Rum94</A>].<A NAME="fn1"></A><A HREF="#footnote1"><SUP>1</SUP></A>The interaction diagramsare taken from Objectory [<A HREF="bibfs.htm#jacobson_oose" TARGET="_mainDisplayFrame">JCJO92</A>] and the Booch method [<A HREF="bibfs.htm#booch_ood" TARGET="_mainDisplayFrame">Boo94</A>]. These notations are summarizedon the inside back cover of the book.</P><A NAME="abstractclass"></A><A NAME="secB-1"></A><H2><A HREF="#secB-2"><IMG SRC="gifsb/down3.gif" BORDER=0 ALT="next: Object Diagram"></A>Class Diagram</H2><A NAME="auto1007"></A><P><A HREF="#ncdn">Figure B.1a</A>shows the OMT notation for abstract and concrete classes. A classis denoted by a box with the class name in bold type at the top.The key operations of the class appear below the class name. Anyinstance variables appear below the operations. Type informationis optional; we use the C++ convention, which puts the type namebefore the name of the operation (to signify the return type),instance variable, or actual parameter. Slanted type indicatesthat the class or operation is abstract.</P><A NAME="absclass"></A><A NAME="ncdn"></A><A NAME="notation_pseudocode"></A><P ALIGN=CENTER><IMG SRC="Pictures/class088.gif"><BR><BR>Figure B.1: Class diagram notation</P><A NAME="auto1008"></A><P>In some design patterns it's helpful to see where client classesreference Participant classes. When a pattern includes a Clientclass as one of its participants (meaning the client has aresponsibility in the pattern), the Client appears as an ordinaryclass. This is true in <A HREF="pat4ffs.htm"TARGET="_mainDisplayFrame">Flyweight (195)</A>,for example. When the pattern does not include a Client participant(i.e., clients have no responsibilities in the pattern), butincluding it nevertheless clarifies which pattern participantsinteract with clients, then the Client class is shown in gray, asshown in <A HREF="#ncdn">Figure B.1b</A>.An example is <A HREF="pat4gfs.htm" TARGET="_mainDisplayFrame">Proxy (207)</A>. A gray Clientalso makes it clear that we haven't accidentally omitted the Clientfrom the Participants discussion.</P><A NAME="association"></A><A HREF="#ncdn">Figure B.1c</A> shows variousrelationships between classes. The OMT notation for class inheritanceis a triangle connecting a subclass (LineShape in the figure) to itsparent class (Shape). An object reference representing a part-of oraggregation relationship is indicated by an arrowheaded line with adiamond at the base. The arrow points to the class that is aggregated(e.g., Shape). An arrowheaded line without the diamond denotesacquaintance (e.g., a LineShape keeps a reference to a Color object,which other shapes may share). A name for the reference may appearnear the base to distinguish it from otherreferences.<A NAME="fn2"></A><A HREF="#footnote2"><SUP>2</SUP></A></P><A NAME="auto1009"></A><P>Another useful thing to show is which classes instantiate whichothers. We use a dashed arrowheaded line to indicate this, sinceOMT doesn't support it. We call this the "creates" relationship.The arrow points to the class that's instantiated. In<A HREF="#ncdn">Figure B.1c</A>,CreationTool creates LineShape objects.</P><A NAME="auto1010"></A><P>OMT also defines a filled circle to mean "more than one." Whenthe circle appears at the head of a reference, it means multipleobjects are being referenced or aggregated.<A HREF="#ncdn">Figure B.1c</A> shows that Drawing aggregatesmultiple objects of type Shape.</P><A NAME="auto1011"></A><P>Finally, we've augmented OMT with pseudocode annotations to letus sketch the implementations of operations.<A HREF="#ncdn">Figure B.1d</A> shows the pseudocode annotationfor the Draw operation on the Drawing class.<A NAME="secB-2"></A><H2><A HREF="#secB-3"><IMG SRC="gifsb/down3.gif" BORDER=0 ALT="next: Interaction Diagram"></A> Object Diagram</H2><A NAME="auto1012"></A><P>An object diagram shows instances exclusively. It provides asnapshot of the objects in a design pattern. The objects are named"a<EM>Something</EM>", where <EM>Something</EM> is the class ofthe object. Our symbol for an object (modified slightly fromstandard OMT) is a rounded box with a line separating the objectname from any object references. Arrows indicate the objectreferenced.<A HREF="#notation_object_diagram_notation">Figure B.2</A>shows an example.<A NAME="notation_object_diagram_notation"></A><P ALIGN=CENTER><IMG SRC="Pictures/objec026.gif"><BR><BR>Figure B.2: Object diagram notation</P><A NAME="secB-3"></A><H2><A HREF="#last"><IMG SRC="gifsb/down3.gif" BORDER=0 ALT="next: navigation"></A>Interaction Diagram</H2><A NAME="auto1013"></A><P>An interaction diagram shows the order in which requests between objectsget executed.<A HREF="#notation_interaction_diagram_notation">Figure B.3</A> is aninteraction diagram that shows how a shape gets added to a drawing.<A NAME="notation_interaction_diagram_notation"></A><P ALIGN=CENTER><IMG SRC="Pictures/inter044.gif"><BR><BR>Figure B.3: Interaction diagram notation</P><A NAME="auto1014"></A><P>Time flows from top to bottom in an interaction diagram. A solidvertical line indicates the lifetime of a particular object. Thenaming convention for objects is the same as for object diagrams—theclass name prefixed by the letter "a" (e.g., aShape). If the objectdoesn't get instantiated until after the beginning of time as recordedin the diagram, then its vertical line appears dashed until the pointof creation.</P><A NAME="auto1015"></A><P>A vertical rectangle shows that an object is active; that is, it ishandling a request. The operation can send requests to other objects;these are indicated with a horizontal arrow pointing to the receivingobject. The name of the request is shown above the arrow. A requestto create an object is shown with a dashed arrowheaded line. Arequest to the sending object itself points back to the sender.</P><A HREF="#notation_interaction_diagram_notation">Figure B.3</A> shows that the first request is from aCreationTool tocreate aLineShape. Later, aLineShape is Added to aDrawing, whichprompts aDrawing to send a Refresh request to itself. Note thataDrawing sends a Draw request to aLineShape as part of the Refreshoperation.<A NAME="last"></A><P><A HREF="#top"><IMG SRC="gifsb/up3.gif" BORDER=0></A><BR><A HREF="chapCfs.htm" TARGET="_mainDisplayFrame"><IMG SRC="gifsb/rightar3.gif" ALIGN=TOP BORDER=0></A> <A HREF="chapCfs.htm" TARGET="_mainDisplayFrame">Foundation Classes</A><BR><A HREF="chapAfs.htm" TARGET="_mainDisplayFrame"><IMG SRC="gifsb/leftarr3.gif" ALIGN=TOP BORDER=0></A> <A HREF="chapAfs.htm" TARGET="_mainDisplayFrame">Glossary</A></P><HR><A NAME="footnote1"></A><P><SUP>1</SUP>OMT uses the term "object diagram" torefer to class diagrams. We use "object diagram" exclusively torefer to diagrams of object structures.</P><A NAME="footnote2"></A><P><SUP>2</SUP>OMT also defines <STRONG>associations</STRONG>between classes, which appear as plain lines between class boxes.Associations are bidirectional. Although associations are appropriateduring analysis, we feel they're too high-level for expressing therelationships in design patterns, simply because associations mustbe mapped down to object references or pointers during design.Object references are intrinsically directed and are thereforebetter suited to the relationships that concern us. For example,Drawing knows about Shapes, but the Shapes don't know about theDrawing they're in. You can't express this relationship withassociations alone.</P></BODY></HTML>?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -