Last week, in Part 1 of this series, I described how GENESYS displays SysML block features in compartments on block nodes. This week I’ll continue the discussion and describe how GENESYS deals with the SysML relationships of composition, references, generalization, and dependencies on a Block Definition Diagram, or BDD.
Blocks on BDDs – Composite, Shared and Reference Associations
SysML defines three kinds of associations that are displayed on a BDD: composition associations, shared associations, and reference associations. A composition association, also called a composition aggregation, is the relationship equivalent of a part property. In other words, part properties define composition associations, and composite associates define part properties. For example, while part properties can be displayed on block nodes, they can also be depicted on BDDs using the composition association. Figure 1 depicts the composition associations for a system-of-interest called FireSat. Just like the parts properties, GENESYS defines the built from/in relationships when creating composition relationships on a BDD.
Figure 1. Composition of the Satellite system-of-interest.
A related association, called a shared association, and more formally, a shared aggregation association, is depicted on BDDs with a hollow diamond, rather than a filled diamond. In GENESYS, you indicate a shared aggregation association by setting the “Whole Multiplicity” attribute on the built from/in relationship to 1.
As an example of a shared association displayed on a BDD, consider Figure 2. A launch vehicle is depicted with composition relationships with a Guidance Subsystem, a Propulsion Subsystem, and a Structure Subsystem. The FireSat, however, is depicted with a shared relationship. The choice here is made with the observation that a fully integrated launch vehicle consists of all four components, but that the satellite “comes from somewhere else.” The satellite is necessary to complete the final launch configuration, but exists separately, as its own independent system.
It is important to note that there is significant divergence among practitioners and authors with regard to composition and shared aggregation associations. Some would consider the relationships in Figure 2 in reverse, and depict all subsystems as shared associations (owing to their representation of “logical aggregation”) and would use composition with the satellite (owing to its physical nature). According to this second interpretation, an “as-assembled” view of the system emerges, while the former interpretation depicts a logical breakdown of a system with an “as-designed” view. Both methods are valid, and even necessary. They both reach the level of physical parts and show connectivity in equal ways, but the system breakdown differs considerably.
While the distinctions between composition and shared associations are really of concern to systems modelers, I would point out that systems engineers would prefer a depiction as shown in Figure 3, using composition only, not of the launch vehicle, but of the FireSat context. In the mind of a systems engineer, Figure 3 represents a reductionist view of the two systems, by emphasizing the launch vehicle and representing the FireSat as a type of sub-system, while the diagram in Figure 3 provides a synthetic view that represents the FireSat and launch vehicle as equals in the hierarchy. It also separates the FireSat from the launch vehicle conceptually since each is built by different organizations, and tested and verified separately. Note also that the depiction in Figure 3 depicts the launch vehicle as an external system (with external interfaces) with respect to the FireSat.
Figure 2. Composition and Shared Associations
Figure 3. The Mission Context using Composition
The third type of relationship that can be depicted on the BDD per SysML is the reference association. The reference association and its corollary, the reference property, are treated differently by different authors of SysML. Most authors use reference relationships to depict types of connectors that can exist between blocks. Connectors are displayed on Internal Block Diagrams (IBDs). In GENESYS, reference associations are modeled as Links, and are modeled on Flow IBDs, along with more specialized instances of the associated connector if desired. Other authors consider a shared composite association as a kind of reference association which can be modeled on BDDs using hollow diamonds as explained previously.
Block Usage and Role
As I discussed last week, blocks in GENESYS represent actual instances of components in the system design. If you want to use blocks as types, and define parts in terms of the roles for specific instances of a block type, GENESYS does allow you to define specific roles for block instances, as depicted in Figure 4. Roles are defined in GENESYS using the “Part Role” attribute on the “built from/in” relationships, and multiplicity is defined using the “Part Multiplicity” attribute on the same relationship. While it is possible to depict roles in GENESYS, only the name of child-block will appear as a part property of the parent-block node.
Figure 4. Composition showing Roles
Generalization
You define related block types using the SysML generalization relationship. The reverse relationship is called a specialization. Generalization can be used to define a classification hierarchy between blocks with common features. Modeling blocks with a generalization relationship implies that there are similar features among the blocks that can be “inherited” from parent to child. Generalizations are defined using the generalization of/kind of relationship in GENESYS. A generalization is depicted in Figure 5. A star sensor is seen as a specialization of the generic block sensor. The star sensor is also a generalization of the star mapper and star tracker.
The generalization relationship is a good way to refer to parts of our system in more abstract terms. If a sensor appears on a diagram, then the sensor node is interchangeable with any one of its specializations. It can be used to reduce clutter on diagrams.
Figure 5. Generalization
Dependencies
Another relationship that is typically displayed on a SysML BDD is the dependency relationship. The dependency relationship is a catch-all relationship that broadly depicts that a dependency of some kind exists between blocks; that a change in one block may (or may not) indicate a change in the other block. Dependencies of this sort are fundamental to GENESYS, and used to relate classes in the project schema.
GENESYS has already sorted out the possible types of dependencies and has given them strong semantic meanings. You can view the project schema from Project Explorer in GENESYS. To view these relationships in a particular system model, it is best to use the Hierarchy diagram where you can selectively display instantiated dependencies between instances of your design.
Summary
In SysML, blocks are displayed on BDDs, IBDs, Requirements Diagrams, and Constraint BDDs. In GENESYS, compositions, shared associations, and generalizations can be depicted on BDDs. GENESYS also allows you to define block roles on BDDs. Reference associations align more closely with the GENESYS notion of a Link and are displayed on Flow IBDs. Generalizations are useful when referring to blocks with similar properties.
SysML has been adapted to suit the purposes of systems engineers, while at the same time attempting to model very granular aspects more suited to detailed engineering. SysML also inherits many modeling concepts better suited to software engineering and may not be useful to a broad range of stakeholders. GENESYS keeps you focused on the systems engineering and still allows you to take best advantage of SysML as your system-of-interest requires. The system metamodel is the guide that keeps your model meaningful and consistent.
If you have any questions about Blocks and SysML in general, feel free to contact me at mark.simons@vitechcorp.com.
