Refactor PCE graph PostAlgoPathValidator step 3 40/104340/12
authorguillaume.lambert <guillaume.lambert@orange.com>
Thu, 9 Feb 2023 10:50:30 +0000 (11:50 +0100)
committerguillaume.lambert <guillaume.lambert@orange.com>
Wed, 1 Mar 2023 12:48:35 +0000 (13:48 +0100)
commitf8af92b07402b1d0f7087024d0a6d07f06089935
tree32dcb06d25fc46571bc2e95257982a5e7c1b9c21
parentb3d4257ba36696849b4391f39c4ae904407a72e1
Refactor PCE graph PostAlgoPathValidator step 3

checkOSNR() method is very long and has a hich cyclomatic complexity.
The main reason is that it proposes a common heuristic for both AZ & ZA
directions to compute the OSNR. This creates a lot of checks in this
function to identify the direction currently used.
Those multiple checks also affects the code overall efficiency.
- dispatch checkOSNR() content in two methods checkOSNRaz()
  and checkOSNRaz() to check the current direction only once.

The second reason is that it contains a for-loop where the iterator
value is hidden to decorrelate the indexes of the verticles retrieved
by the treatment
and also to back-pedal in the ZA direction case, what is now useless.
- unhide pathElement and merge it to the n iterator
- use decrement operator in the ZA direction for-loop case

Once that done, checkOSNRaz() and checkOSNRaz() looks very similar.
And it may look clever to regroup them again by inverting the order in
the edges list rather than using a decrement operator for the ZA
direction. But this is technically impossible w/o reintroducing many
direction checks because links are retrieved with the getter
link().getOppositeLink() in the ZA direction rather than simply
link() in the AZ direction...

Also the first two iterations and the last iteration of the loops
require specific treatments since they are at the edges of the line,
what causes checks at each iteration.
These other checks affect the code overall efficiency too.
- split the for-loop in three parts to avoid checking iterator value
  at each iteration
- raise an error for unsupported cases (degree at the edges and
  back to back xponder) and remove related code

The third reason is that the for-loop use a switch case to identify
each node type. Each block contains a different treatment to compute
the signal impairments & characteristics.
- create various intermediate functions to compute signal
  characteristics at each step and reduce case-blocks size.

JIRA: TRNSPRTPCE-725
Signed-off-by: guillaume.lambert <guillaume.lambert@orange.com>
Change-Id: I9cd2370d42d74892f8788a9991827066c2b4fcaa
pce/src/main/java/org/opendaylight/transportpce/pce/graph/PostAlgoPathValidator.java