This chapter is from the book
This chapter is from the book
This chapter is from the book
3.7. Dependencies
A dependency is the third kind of relationship you can display on BDDs. It means what it sounds like: One element in the model, the client, depends on another element in the model, the supplier. More precisely, a dependency conveys that when the supplier element changes, the client element may also have to change.
Most often, you create a dependency between two model elements solely to establish traceability between them. A dependency relationship lets you use your modeling tool to perform automated downstream impact analysis when you make changes to your design. When you make a change to one element, you can query your modeling tool to generate a list of the other elements in the model that may be impacted by the change; the modeling tool navigates the set of dependencies that you’ve created between elements to generate that list.
This is a practical reason to create dependencies in your model. However, you seldom have a reason to display them on BDDs. They are part of the structure of the model and not of the system that the model represents. And you will spend most of your time creating BDDs to convey system structure to your stakeholders.
When a dependency appears on a BDD, the notation is a dashed line with an open arrowhead, which is drawn from the client to the supplier. In Figure 3.23, for example, the Attitude and Orbit Control Subsystem block is the client, and the Data Handling interface is the supplier. This model conveys that the block depends on the interface; if the interface changes, the block may need to change, too.
)
Figure 3.23 A dependency relationship between two named elements
Note that SysML defines specialized kinds of dependency relationships (e.g., package import, viewpoint conformance, and several kinds of requirements relationships). Although you rarely display dependencies on BDDs, you often display these specialized kinds of dependencies on package diagrams and requirements diagrams. I discuss these topics in detail in Chapter 10, “Package Diagrams,” and Chapter 11, “Requirements Diagrams.”