Appendix B Illustration Symbol Guide In this book, we use the chart everywhere to illustrate important ideas. Some pictures are informal, such as copying dialogs or schematic object trees from the screen. In particular, the design mode uses a more formal graphic symbol to display relationships and interactions between classes and objects. This appendix details these graphics symbols are specifically described. We use three different graphics symbols: 1) class diagrams describe the various classes, their structure and static relationships between them. 2) The object map describes the specific object structure of the running time. 3) Interaction to display the process of request between the objects. Each design pattern contains at least one class diagram. Other graphical representation is also used to supplement it. Class diagrams and object maps are based on O m T (Object Modeling TE C H N I q u e) [RBP 91, Rum94]. The interactive diagram comes from Objectory [JCJO92] and B O O C H. The inner page of this book has a summary description of these symbols. B.1 Diagram B - 1 A is an abstract class and a specific class represented by O m T. A class is expressed as a wire frame, written in the top with a crude body name, which is the main operation, and then the instance variable. Type information is optional. We use C 's writing habits to place the type name (emphasize the return type), the variable name, or parameter. The object indicates that the class or operation is abstract. In some design patterns, it is useful to clear the reference to the participation class. In the class diagram, when a customer class is a host member (ie, the customer class is responsible in this mode), we represent it in a normal way, you can see F Lyweight (4. 6); When the customer is not the participant of this mode (ie, the customer class is not responsible in the mode), but when it is interactive with the interaction between the participants, we represent it in gray. As shown in Figure B - 1 B. Agent mode (P R o x y) is an example. This kind of gray chest is also reminded that we do not miss the customer class when discussing model participants. Figure B - 1 C shows several relationships between the class. In the OMT representation, the class inherit is represented as a triangular connection from the subclass (l ine s hape) to the parent class (S Hape in the figure); the object reference representation of some or aggregation relationship is represented as a root There is a rhombus arrow, pointing to the aggregated class (S hape in the figure); the root does not have a diamond arrow indicating a knowledge relationship (in the figure there is a reference to C Olor, while C Olor may be multiple S Hape Object sharing). The references can be indicated in the vicinity of the root of the arrows to distinguish between other references. Another useful representation describes which class creates which class object. Since O M T does not support this representation, we use the dotted arrow to mark this situation. We call it "creation" relationship. The arrow points to the object being instantiated. O M t term "object map" means classificier. We use "class diagrams" only refer to the object map. O M t also defines the relationship between the association between the class (A S S O C I A Ti O N), indicated by a line between the class. The association relationship is two-way. Although this relationship is applicable during the analysis stage, we feel that it is too abstract to describe the relationship in the design mode, because the relationship between the design phase must be mapped to object references or pointers. Object reference itself is, it is more suitable for expressing the relationship we discussed. For example, D R A W I N g knows S H A P e, and each S H A P e does not know its D R A W I N g, which cannot be represented by association. In Fig. B - 1 C, C R e a T I O N to O L creates L i n e s h a p e object.
O m t also defines a solid dot, indicating "more than one". When the circle is at the headed head, it represents a plurality of objects that point or aggregate. Figure B - 1 C in D R A W I N g aggregates the objects of multiple S H A P E types. Finally, we believe that some pseudo codes can be added to the O m T graph to briefly explain the implementation of the operation. The pseudo code in Figure B - 1 D illustrates the implementation of D R a W operation of D R A W I N g classes. Figure B-1 Diagram B.2 Object Diagram Object Diagram only describes instances. It describes the status of an object in the design mode. The name of the object is usually expressed as "A S O M E T H I Ng", where S O m e t H i N g is the class of the object. We used to represent the symbol of the object (slightly modified for the standard O m T) is a rounded rectangle and separate the object name and object reference in a straight line. Arrow represents an object reference. As shown in Figure B - 2. a) Abstract class and specific class b) Participant customer class (left) and absolute customer class (right) C) class relationship D) Pseudo code NOTE is shown in the execution order of each request between the objects. Figure B - 3 is an interactive diagram that describes how a S h a p e object is added to a D R A W i N g object. The time flow is indicated from top to bottom in the interaction. A vertical solid line represents a life cycle of a particular object. The object's naming rules are the same as the object map, i.e., add "A" (for example, A S H a P e) before the class name. If an object is not created when the time interval shown in this figure is not created, use a vertical dashed line, which is extended to the time point it is created. A vertical rectangle represents an object in activity, that is, it is processing a request. The request can also be issued to other objects during operation, which is represented by a horizontal arrow pointing to the received object. The name of the request is marked above the arrow. Creating an object is represented by a dashed arrow. A request sent to itself also points to the sender itself. In Fig. B - 3, the first request is sent by the A c R e a T I n to O L, requesting Creating a L i n e s H a p e. Next, A L i n e s H A P e is added to A D R A W I N G, which causes A D R A W I N g to issue a R e f R e S H request to itself. In the RE F R E SH operation, A D R A W I N G also issues a D R A W request to A L i n e s h a p e.
