类图-对象图和交互图
来源:互联网 发布:可以货到付款的软件 编辑:程序博客网 时间:2024/06/13 03:21
We use diagrams throughout the book to illustrate important ideas. Some diagrams are informal, like a screen shot of a dialog box or a schematic showing a tree of objects. But the design patterns in particular use more formal notations to denote relationships and interactions between classes and objects. This appendix describes these notations in detail.
We use three different diagrammatic notations:
- A class diagram depicts classes, their structure, and the static relationships between them.
- An object diagram depicts a particular object structure at run-time.
- An interaction diagram shows the flow of requests between objects.
Each design pattern includes at least one class diagram. The other notations are used as needed to supplement the discussion. The class and object diagrams are based on OMT (Object Modeling Technique) [RBP+91,Rum94].1 The interaction diagrams are taken from Objectory [JCJO92] and the Booch method [Boo94]. These notations are summarized on the inside back cover of the book.
Class Diagram
Figure B.1a shows the OMT notation for abstract and concrete classes. A class is 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. Any instance variables appear below the operations. Type information is optional; we use the C++ convention, which puts the type name before the name of the operation (to signify the return type), instance variable, or actual parameter. Slanted type indicates that the class or operation is abstract.
Figure B.1: Class diagram notation
In some design patterns it's helpful to see where client classes reference Participant classes. When a pattern includes a Client class as one of its participants (meaning the client has a responsibility in the pattern), the Client appears as an ordinary class. This is true in Flyweight (195), for example. When the pattern does not include a Client participant (i.e., clients have no responsibilities in the pattern), but including it nevertheless clarifies which pattern participants interact with clients, then the Client class is shown in gray, as shown in Figure B.1b. An example is Proxy (207). A gray Client also makes it clear that we haven't accidentally omitted the Client from the Participants discussion.
Figure B.1c shows various relationships between classes. The OMT notation for class inheritance is a triangle connecting a subclass (LineShape in the figure) to its parent class (Shape). An object reference representing a part-of or aggregation relationship is indicated by an arrowheaded line with a diamond at the base. The arrow points to the class that is aggregated (e.g., Shape). An arrowheaded line without the diamond denotes acquaintance (e.g., a LineShape keeps a reference to a Color object, which other shapes may share). A name for the reference may appear near the base to distinguish it from other references.2Another useful thing to show is which classes instantiate which others. We use a dashed arrowheaded line to indicate this, since OMT doesn't support it. We call this the "creates" relationship. The arrow points to the class that's instantiated. InFigure B.1c, CreationTool creates LineShape objects.
OMT also defines a filled circle to mean "more than one." When the circle appears at the head of a reference, it means multiple objects are being referenced or aggregated.Figure B.1c shows that Drawing aggregates multiple objects of type Shape.
Finally, we've augmented OMT with pseudocode annotations to let us sketch the implementations of operations.Figure B.1d shows the pseudocode annotation for the Draw operation on the Drawing class.
Object Diagram
An object diagram shows instances exclusively. It provides a snapshot of the objects in a design pattern. The objects are named "aSomething", whereSomething is the class of the object. Our symbol for an object (modified slightly from standard OMT) is a rounded box with a line separating the object name from any object references. Arrows indicate the object referenced.Figure B.2 shows an example.
Figure B.2: Object diagram notation
Interaction Diagram
An interaction diagram shows the order in which requests between objects get executed.Figure B.3 is an interaction diagram that shows how a shape gets added to a drawing.
Figure B.3: Interaction diagram notation
Time flows from top to bottom in an interaction diagram. A solid vertical line indicates the lifetime of a particular object. The naming convention for objects is the same as for object diagrams—the class name prefixed by the letter "a" (e.g., aShape). If the object doesn't get instantiated until after the beginning of time as recorded in the diagram, then its vertical line appears dashed until the point of creation.
A vertical rectangle shows that an object is active; that is, it is handling a request. The operation can send requests to other objects; these are indicated with a horizontal arrow pointing to the receiving object. The name of the request is shown above the arrow. A request to create an object is shown with a dashed arrowheaded line. A request to the sending object itself points back to the sender.
Figure B.3 shows that the first request is from aCreationTool to create aLineShape. Later, aLineShape is Added to aDrawing, which prompts aDrawing to send a Refresh request to itself. Note that aDrawing sends a Draw request to aLineShape as part of the Refresh operation.
Foundation Classes
Glossary
1OMT uses the term "object diagram" to refer to class diagrams. We use "object diagram" exclusively to refer to diagrams of object structures.
2OMT also defines associations between classes, which appear as plain lines between class boxes. Associations are bidirectional. Although associations are appropriate during analysis, we feel they're too high-level for expressing the relationships in design patterns, simply because associations must be mapped down to object references or pointers during design. Object references are intrinsically directed and are therefore better suited to the relationships that concern us. For example, Drawing knows about Shapes, but the Shapes don't know about the Drawing they're in. You can't express this relationship with associations alone.
- 类图-对象图和交互图
- (转载)UML交互图——鲁棒图的三元素:抽象对象,实体对象和控制对象
- UML面向对象设计基础 chapter 5 对象交互图
- UML交互图(顺序图和交互图)
- 利用HttpURLConnection对象和Internet交互
- 利用HttpURLConnection对象和Internet交互
- 利用HttpURLConnection对象和Internet交互
- 利用HttpURLConnection对象和Internet交互
- 利用HttpURLConnection对象和Internet交互
- javascript之external和VC对象交互
- 面向对象分析与设计课程学习之交互图
- 交互图
- 交互图和活动图的区别
- UML时序图和交互图
- UML-状态图、活动图和交互图
- EA&UML日拱一卒--序列图(Sequence Diagram)::交互和交互使用
- 用JAXB来简化xml和对象间的交互
- Scala Tutorial中英对照:和Java交互,一切皆对象
- java编译时类型与运行时类型
- Flex加载google地图、百度地图以及天地图作底图
- GUI系统之SurfaceFlinger(5)BufferQueue内部原理
- 全局钩子实例分析
- 十二星座英语名称(Zodiac)
- 类图-对象图和交互图
- 视频专辑:Web Service视频教程
- flex sqlite基本用法
- C++必知必会之(13)复制操作
- DB2 表分区
- GUI系统之SurfaceFlinger(6)BufferQueue中的缓冲区分配
- linux c socket之多路复用:绑定多个端口
- 视频专辑:Java从入门到精通视频教程
- GUI系统之SurfaceFlinger(7)应用程序的典型绘图流程