- 3.1. Purpose
- 3.2. When Should You Create a BDD?
- 3.3. The BDD Frame
- 3.5. Associations: Another Notation for a Property
- 3.6. Generalizations
- 3.7. Dependencies
- 3.8. Actors
- 3.9. Value Types
- 3.10. Constraint Blocks
- 3.11. Comments
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
3.5. Associations: Another Notation for a Property
Section 3.4, “Blocks,” focuses on blocks and the various kinds of properties that blocks can own. Blocks are an important part of a structural model of a system, and the relationships between the blocks are at least as important.
There are three main kinds of relationships that can exist between blocks: associations, generalizations, and dependencies. I discuss generalizations and dependencies in detail in Section 3.6, “Generalizations,” and Section 3.7, “Dependencies.” This section is devoted to associations.
In discussing reference properties and part properties in Section 3.4.1, “Structural Features,” I implicitly address the idea of associations between blocks. To reiterate the key points: A reference property represents a structure that’s external to a block—a structure that the block needs to be connected to for some purpose. A part property instead represents a structure that’s internal to a block—in other words, a structure that the block is composed of.
Reference properties and part properties correspond to two kinds of associations that you often create between blocks and display on BDDs: reference associations and composite associations, respectively. Associations are simply an alternative notation to convey these kinds of structural relationships within a system.
Let’s take a look in detail at the two kinds of associations.
3.5.1. Reference Associations
A reference association between two blocks means that a connection can exist between instances of those blocks in an operational system. And those instances can access each other for some purpose across the connection.
The notation for a reference association on a BDD is a solid line between two blocks. An open arrowhead on exactly one end conveys unidirectional access; the absence of arrowheads on either end conveys bidirectional access.
The upper BDD in Figure 3.17 displays a reference association between the Electrical Power Subsystem block and the Flight Computer block. Associations can have several labels. You can optionally display an association name floating near the middle of the line, and you can optionally display a role name and multiplicity on either end of the line. The association name is a modeler-defined string that describes the type of connection that can exist between instances of the two blocks. In Figure 3.17, for example, the name of the reference association shown is Power Cable—a name that describes the type of connection that could exist between an electrical power subsystem and a flight computer in a correctly assembled satellite.
)
Figure 3.17 Reference associations and reference properties
The role name shown on the end of a reference association corresponds to the name of a reference property—one that belongs to the block at the opposite end and whose type is the block that it’s next to. In the upper BDD in Figure 3.17, for example, the role name eps represents a reference property that belongs to the Flight Computer block and whose type is the Electrical Power Subsystem block. The role name fc represents a reference property that belongs to the Electrical Power Subsystem block and whose type is the Flight Computer block. The lower BDD in Figure 3.17 displays an equivalent view of the same model using the references compartment notation instead of reference associations.
Similarly, the multiplicity shown on the end of a reference association (near a role name) corresponds to the multiplicity of that same reference property. This correspondence also is reflected in the two BDDs in Figure 3.17.
Sometimes a block has multiple reference properties of the same type (as shown in the references compartment of the Flight Computer block in Figure 3.18). You can convey this equivalently by drawing multiple reference associations between the same two blocks (as shown between the Flight Computer block and the Star Sensor block in Figure 3.18). Each reference association represents a distinct reference property. Showing both notations on the same diagram is redundant; I’m doing it here to establish the connection between these related concepts.
)
Figure 3.18 Using reference associations to specify multiple reference properties of the same type
The choice to use the references compartment notation versus reference associations depends on how much information you need to expose on the BDD. In Figure 3.18, for example, the reference association notation lets me expose the value properties of the Star Sensor block; in contrast, the references compartment notation hides all features of the Star Sensor block.
Another factor in your decision is the need to specify a type for a connector on an IBD. If you intend to do this, then you need to create a reference association between two blocks and give it a name. The compartment notation would not meet your needs in this case.
3.5.2. Composite Associations
A composite association between two blocks conveys structural decomposition. An instance of the block at the composite end is made up of some number of instances of the block at the part end.
The notation for a composite association on a BDD is a solid line between two blocks with a solid diamond on the composite end. An open arrowhead on the part end of the line conveys unidirectional access from the composite to its part; the absence of an arrowhead conveys bidirectional access (i.e., the part will have a reference to the composite).
Figure 3.19 displays four examples of composite associations from the DellSat-77 Satellite block to the subsystem blocks. (It’s permissible and common practice to overlap the solid diamonds on the composite end.) This BDD conveys that a correctly manufactured and assembled DellSat-77 satellite will be composed of one electrical power subsystem, one attitude and orbit control subsystem, one environmental control subsystem, and one communication and data handling subsystem. The possible numbers of instances are conveyed by the multiplicities on the part ends of the four composite associations.
)
Figure 3.19 Composite associations and part properties
The role name shown on the part end of a composite association corresponds to the name of a part property—one that’s owned by the block at the composite end and whose type is the block at the part end. In Figure 3.19, for example, the role name aocs represents a part property that’s owned by the DellSat-77 Satellite block and whose type is the Attitude and Orbit Control Subsystem block. This correspondence is equivalently reflected in the parts compartment of the DellSat-77 Satellite block. It’s redundant to show both the parts compartment notation and composite associations on the same diagram; I’m doing it here to reinforce the connection between these concepts.
The multiplicity on the part end of a composite association is not restricted; a composite structure can be made up of an arbitrary number of instances of parts—however many a system requires.
However, the multiplicity on the composite end is restricted. A part—by definition—can belong to only one composite at a time. Therefore, the upper bound of the multiplicity on the composite end must always be 1 (as shown in Figure 3.19). The lower bound of that multiplicity can be either 0 (zero) or 1. A lower bound of 0 conveys that a part can be removed from its composite structure; a lower bound of 1 conveys that it cannot be removed (it must be attached to a composite structure at all times in a valid instance of a system).
In Section 3.4.1.1, I state that 1 is almost always the default multiplicity for elements in SysML. However, there is an important exception to this rule, and here it is: The default multiplicity on the composite end of a composite association is 0..1. (On the part end, however, the default multiplicity is the usual case, 1.)
Sometimes a block has multiple part properties of the same type (as shown in the parts compartment of the Communication and Data Handling Subsystem block in Figure 3.20). You can convey this equivalently by drawing multiple composite associations between the same two blocks (as shown from the Communication and Data Handling Subsystem block to the Flight Computer block in Figure 3.20). Each composite association represents a distinct part property.
)
Figure 3.20 Using composite associations to specify multiple part properties of the same type
The same factor that I discuss at the end of Section 3.5.1, “Reference Associations,” affects your choice to use either the parts compartment notation or a composite association. You should use a composite association when you need to expose the features of the block that types a part; you should use compartment notation instead when those features are not the focus of the diagram.