Page 1 A Graphical Modeling Notation with Similarities to UML 1. Introduction The notation presented here is a general-purpose graphical format for modeling software artifacts. The notation is general purpose in that it can be used to model requirements, specification, design, and implementation artifacts. For our purposes, we use two formal textual languages for representing these artifacts. Namely, RSL is used to represent requirements and specifications; Java is used to represent design and implementation. The same general-purpose graphical notation maps to both of these lan- guages. The notation presented here uses concepts from the Unified Model- ing Language (UML). The design of UML is a collaborative effort of primarily commercial organizations, led by the Rationale Cor- poration. The goal for UML is to develop a standard graphical modeling notation. UML is a consolidation of concepts used in the earlier Object Modeling Technique (OMT) and Booch Diagrams. UML has a number of features that are not used in the notation described here. In addition, UML is missing certain features, notably function and dataflow diagrams. Where a feature is available in UML, the same feature is retained here. Where UML is missing what is considered to be an important notational fea- ture, a previously existing standard is used, in such a way as not to conflict with any existing UML features. That is, if UML has it we'll use it; if UML does not have it we'll use a standard notation that does not conflict with any part of UML. A complete specification of UML is available at www.omg.org/tech- nology/documents 1. There are also a number of UML books on the market, none of which is necessary for this class. 2. Block Diagrams A block diagram represents communication between subsystems. A subsystem is a modular software component containing two or more classes. Examples of subsystems include library packages, sepa- rately launchable executable programs, and other logically related collections of classes. Elements of a block diagram are the following: 1. Folder-shaped rectangles, representing subsystems ____________________ 1 The OMG web page changes frequently. If the link given here is not found, go to the main site at www.omg.org and search for "UML Spec" with their search engine. Page 2 2. Directed interconnection lines, abstractly representing communication between subsystems 3. Graph labels in normal font, representing functional com- munication 4. Graph labels in italic font, representing data communica- tion That interconnection lines abstractly represent communication means that the implementation details of the communication are abstracted out. In particular, functional communication can be by normal procedure call, remote procedure call, subprocess invo- cation, thread activation, or some other means. This level of detail is not specified in the block diagram. Similarly, data communication can be by parameter passing, shared data, inter- process data transfer, or other means. This level of detail is not specified in the block diagram. Figure 1 shows the general structure of a block diagram. The diagram depicts three subsystems in which Subsystem 1 calls (or otherwise invokes) Function 1 in Subsystem 2. Subsystem 2 sends (or otherwise transfers or shares) data DataD1 to (with) Subsys- tem 1. Subsystems 1 and 3 send DataD2 to each other. In RSL and Java, subsystems are defined as modules and packages respectively. 3. Dataflow Diagrams A dataflow diagram represents the flow of objects between opera- tions in a specification. Elements of dataflow diagrams are the following: 1. Circular or elliptical graph nodes, representing opera- tions. 2. Directed graph edges, representing operation inputs and outputs. 3. Graph levels, representing operation hierarchy. Figure 2 shows the general structure. 4. Data Diagrams A data diagram represents the composition and inheritance rela- tionships between objects in a specification or classes in a design. The notation described here is largely a subset of UML, with a minor extension added. Elements of data diagrams are the following: Figure 1: General Structure of a Block Diagram. Figure 2: General Structure of a Dataflow Diagram. Page 3 1. Three-part boxes, labeled at the top with a object/class name. 2. Object component/data member names, immediately below the class name in a box. 3. Declared operations/function member names, following the data member names in a box. 4. One-part boxes, labeled inside with the object/class name only. 5. Connecting edges between class boxes, with three forms of augmentation: a. a hollow triangle, designating an inheritance relation b. a hollow diamond, designating a composition relation (same semantics as the second part of a three-part box) c. integer or comma-separated integer pair annotation on hollow diamond, indicated multiplicity of composition; the character '*' can be used in place of an integer to represent multiplicity of 0 or more Figure 3 shows the general structure. The diagram on the top of the figure shows data and function membership using the three- part box notation. The diagram on the bottom of the figure, labeled "Alternative Equivalent...", shows the equivalent member- ship relations using the hollow diamond notation. Note that function members, when shown outside of a three part class box, are drawn as rounded rectangles. This is consistent with their depiction in function diagrams, as discussed below. Orientation of components in a data diagram is not significant. That is, subclasses and members can be shown in any geometric position relative to their parent class. The orientation of the hollow triangle is significant, with the pointed end oriented towards the parent class. Also, the positioning of the hollow diamond is significant, in that it is positioned immediately adjacent to the containing class. In this way, two-way containment2 can be depicted, as shown in Figure 4. Figure 4 also illustrates the use of multiplicity annotations. Note that the three-part representation of membership versus the hollow diamond representation are two equivalent views that have Figure 3: General Structure of a Class Diagram. ____________________ 2 The depiction of two-way containment is prohibited in stan- dard UML, but allowed here since it maps to well-defined seman- tics in both RSL and Java. In RSL two-way containment maps to mutually-recursive objects, i.e., objects that have each other as components. In Java, two-way containment maps to classes that have references to each other, i.e., classes that declare one an- other as data members. Page 4 exactly the same meaning. Membership can be shown in either way separately, or with the two forms combined into a single diagram. When the two forms are used in single diagram, there is redundant information shown -- i.e., a single diagram is showing the same membership relationships in two different ways. The notation does not prohibit such redundancy; it is up to the diagram designer to use the notation as she/he sees fit. 5. Function Diagrams Function diagrams show the calling relationships between func- tions in a program design. Function diagrams are not applicable at the RSL specification level. Elements of a function diagram are the following: 1. Rounded rectangle nodes, representing functions 2. Edges between nodes, representing function calls 3. Annotated arrows above function nodes, representing input to and output from functions 4. Annotated down-pointing and up-pointing arrows, repre- senting exception handling catch and throw, respectively 5. Labeled doubled lines, representing event invocation 6. Labeled dashed-line boxes around function nodes, repre- senting class membership. Figure 5 shows the general structure. The calling relationship shown in a function diagram shows poten- tial invocation not actual invocation. Depending on the imple- mented logic within a calling function, none, some, or all of its potentially called functions may actually be called during pro- gram execution. Orientation of components in a function diagram is is signifi- cant. The root of a calling tree must be shown above or to the left of the subfunctions that it calls. Similarly, an event invocation line must be shown above or to the left of the func- tions that may be invoked when the event is triggered. Strictly speaking, the left-to-right (or top-to-bottom) order of called functions is not significant. However, by convention the left-to-right order in a function diagram will typically be the same as the lexical order of appearance of the functions in the Java code. Figure 4: Two-Way Membership in a Class Diagram. Figure 5: General Structure of a Function Diagram. Page 5 6. Discussion The shape of a diagram node is unique across all diagrams. Fur- thermore, the node shape can be traced to a specific semantic construct in RSL and/or Java. Viz., * a folder-shaped box is a subsystem, consisting of multiple RSL objects and operations or multiple Java classes * a box is a datatype, which is either an RSL object or a Java class * the second and third parts of a three-part box represent the components and operations attributes of an RSL object or the data and function members of a Java class; * a hollow triangle connecting boxes abstractly represents inheritance in either RSL or Java; * a hollow diamond connecting boxes represents component-of in RSL and membership in Java * a circle (or ellipse) is an RSL (functional) operation * a rounded rectangle is a Java (imperative) function (a.k.a., method) The uniqueness of shapes allows diagram elements to be combined in ways not fully supported in UML, but which is conceptually compatible with UML. In particular, the appearance of rounded rectangles in data diagrams depicts function membership in a form not directly supported in UML. The current version of UML supports neither dataflow nor function diagrams in the forms defined above. UML does support state- transition diagrams that have similar semantics to dataflow dia- grams. In a state-transition, nodes are shown as rounded rectan- gles. This may cause some confusion with our use of rounded rectangles for functions. However, the edge shape in a UML state transition diagram is different than in a function diagram, so that the two forms of diagram can be immediately distinguished. It should be noted that all of the above notations except for function diagrams are orientation independent. That is, diagrams can be drawn vertically, horizontally, or any combination of ori- entations. The restriction for function diagrams is that a call- ing function must be drawn above or to the left of the functions that it calls.