Skip to content

Dependency graph generation

One of the major benefits of using ESL is that dependencies between components, variables, function, behavior, design, and relation specifications can automatically be derived. This information is stored within a graph which is the output of the ESL compiler. The resulting graph is the basis for many system architecture models.

Note

Feel free to check out the Dependency derivations section of for the mathematical basis of the derived dependency graph.

Note

Check the Dependency Structure Matrices section or visit https://dsmweb.org/ for more information on how to interpret dependency structure matrix models.

Note

Many conventional requirement management and system architecting tools require a user to manually identify, create, define, and maintain dependencies between elements of a system specification or system architecture model. With the use of ESL this is fully automated!

We will use the following specification as an example for the dependency graph generation:

water-pump-specification.esl
  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
# Specification of a drive-mechanism driving a pump.
define type
  mechanical-energy-flow is a real with unit Nm
  electrical-energy-flow is a real with unit W
  liquid-material-flow is a real with unit L/s
  energy-potential is a real with unit Wh
  control-signal is a boolean
  distance is a real with unit m
  spatial-measure is a distance of at least 0.0 [m]
  efficiency is a real  of at least 0.0 and at most 1.0


define verb
  provide to
  convert into
  send to


define relation
  battery-efficiency-model
    relating parameters
    * potential is an energy-potential
    * output is an electrical-energy-flow


world
  variables
    torque is a mechanical-energy-flow #< Comments on variable torque.
    water-flow is a liquid-material-flow
    drive-length is a spatial-measure
    pump-length is a spatial-measure

  components
    pump is a CentrifugalPump with arguments
      * torque
      * water-flow
      * pump-length

    drive-mechanism is an ElectricalDriveMechanism with arguments
      * torque
      * drive-length

  comments
    pump #< Can be sourced by manufacturer XYZ.
         #< Part number CFG.PMP.0.1

  goal-requirements
    provide-torque: drive-mechanism must provide torque to pump

  design-requirements
    min-water-flow: water-flow must be at least 1.0 [L/s]

  design-constraints
    dc-drive-length: drive-length must be equal to pump-length

  need
    IP68: drive-mechanism must be IP68 compliant


define component CentrifugalPump
  parameters
    torque is a mechanical-energy-flow
    water-flow is a liquid-material-flow
    length is a spatial-measure property

  transformation-requirements
    convert-torque: must convert torque into water-flow


define component ElectricalDriveMechanism
  parameters
    torque is a mechanical-energy-flow
    length is a spatial-measure property

  variables
    power-potential is an energy-potential
    power is an electrical-energy-flow
    motor-control-signal is a control-signal

  transformation-requirements
    convert-power-potential: must convert power-potential into torque

  components
    power-source is a Battery with arguments
      * power-potential
      * power

    motor is a BrushlessMotor with arguments
      * power
      * torque

    power-Switch is a Switch with arguments
      * motor-control-signal

  goal-requirements
    provide-power: power-source must provide power to motor
    send-control-signal: power-Switch must send motor-control-signal to power-source

  behavior-requirements
    toggle-power:
      case on:
        when
          * c1: motor-control-signal is equal to True [-]
        then
          * r1: power must be at least 300 [W]
      case off:
        when no other case applies
        then
          * r2: power must be equal to 0 [W]


define component BrushlessMotor
  parameters
    power is an electrical-energy-flow
    torque is a mechanical-energy-flow

  variables
    conversion is an efficiency

  transformation-requirements
    convert-power: must convert power into torque with subclauses
      * s1: conversion must be at least 0.8


define component Battery
  parameters
    power-potential is an energy-potential
    power is an electrical-energy-flow

  transformation-constraints
    convert-potential: does convert power-potential into power

  relations
    efficiency-model: battery-efficiency-model
      relating arguments
      * power-potential
      * power


define component Switch
  parameters
    motor-control-signal is a control-signal

Figure 1 shows all dependencies that are derived from the final pump specification at the second decomposition. The rows are labelled with components, function-specifications, behavior-specifications, design-specifications, variables, needs, and relations specifications.

Full dependency network

Figure 1: Full dependency network derived from the pump example specification at the second decomposition level

The tree structure at the top left of the figure denotes the system decomposition structure as specified. Here we find the components pump, power-source, motor, and power-switch to be the leaf components of the specified decomposition tree.

The pie-charts within the matrix denote the derived dependencies between elements of the specification. The colors of the wedges denote the different labels that are attached to each dependency. The labels are based on the variable types that are used within the specification.

The pie-charts within the matrix denote the derived dependencies between elements of the specification. The colors of the wedges denote the different labels that are attached to each dependency. The labels are based on the variable types that are used within the specification.

Note that the compiler derives multiple dependency kinds, being functional, logical, design, coordination, traceability and mapping dependencies. Figure 1 shows all these dependency kinds between all ESL elements which makes it difficult to interpret (Especially if one would specify a real system). Hence in the next sections we will create several views on the system.

Note

In the user manual we use multi-domain-matrices to visualize the resulting dependency structures.