In my last post I discussed Exit Conditions, Exits and their impact on capturing the decisions your system is making. I made a good start on this topic, but to properly cover the topic I need to cover a little more theory on multiple exits, discuss loops, loop exits, and nesting decisions. In order to clarify Exit logic a bit more, I’m going to draw some parallels between the model constructs and programming concepts, so grab a highly caffeinated beverage (preferably something with tons of sugar too) and settle in for a long night of programming… Just kidding!
Last time, I stated that only a single Exit Condition from a Function can be chosen. Why is that? Why can’t multiple paths be taken upon exiting a function? If we consider exit paths to be like the output of an if-else statement in a program, I think it will become clearer how exit decisions are working. Consider the similarities between a simple function with two exits and the simple if-else programming statement:
We can see clearly how, in this simple example, the Exit Conditions from the function align with the simple construct of the if-else statement. In programming the if-else statement is selecting a single exit branch to take, it never takes both paths. A decision is made and the program execution then moves forward, much the same way our function makes a decision and then the flow moves forward.
Now let’s consider the function with more than two Exit Conditions. In this case we can draw another parallel with simple programming concepts, this is similar to the switch/case statement in most programming languages.
Just like in the programming switch/Case statement, only 1 path exists for the code to take, only 1 case is evaluated to be true and will allow the flow to continue its execution. This is why the Exit Conditions are singular exits. Logically they have to be, since two separate cases shouldn’t evaluate to be true at the same time. If that situation is possible, in fact you have another exit condition that’s the union of those two conditions. Let’s suppose there’s a situation where Case 1 and Case 2 can evaluate to be true at the same time, in that case you’re really have another Case, a Case 5 that is true when the conditions for Case 1 AND Case 2 are met. It’s a compound condition that makes it its own unique condition. This is the proper mindset for using Exit conditions.
Don’t be afraid to repeat or copy functionality amongst the branches if it makes sense to do so. Often after a decision is made, some of the functionality that’s being done on another branch needs to be replicated.
Let’s consider the following example where I have a simple system performing some sort of Built in Test to determine its status. If the status is good the system goes on to check System 2, However if there is a fault in System 1 the system will attempt to remediate the fault and then move on to perform the checks on System 2 (and yes, this is a simplistic example!):
In this example we can see how the Check System 2 Status is used on both branches, if System 1 was determined to have a fault, some remediation of that fault had to occur, and then the system proceeded to check System 2. If the fault didn’t occur, the system immediately went on to check System 2’s status. Having functions copied between branches after a decision of some sort is a crucial aspect of using Exit Conditions properly and capturing the decision trees that your system is performing.
Alright, let’s switch gears here a little bit and discuss the one other type of exit we haven’t discussed yet. (Maybe I’ve been talking about Exits too much and I’m starting to get loopy…) Any guess which exit we haven’t discussed yet? Loop Exits! (I know, pardon my “loopy” pun…)
Loop Exits are pretty simple to understand really, they work in conjunction with the Loop construct and serve as the break statement for the loop. Loop Exits are only valid within the loop construct and will exit the innermost loop. This can come into play when you have loops within loops, the Loop Exit will only exit the immediate loop it’s in. Loops and Loop Exits closely resemble Do While or While Do loops in most programming languages. Let’s take a quick look at this example:
This is a very straightforward loop example, a “Do” function is doing something, then a “While” function is deciding to stay in the loop or take the “Exit Loop” Exit Condition which then goes to the Loop Exit (LE). When the Loop Exit is reached, the control is passed out of the immediate loop. In the diagram above the dotted line is showing the path the flow is taking when the Loop Exit is reached. Note that in GENESYS, that dotted line doesn’t exist, you need to look at the model and understand where that Loop Exit will take you – in this case to the Loop it’s nested in even if that loop is at a higher level. Yes, inside the decomposition of a function inside a loop it is legal to place a loop exit that will exit the loop at the higher level. While this is possible, it’s is probably best practice to keep your loop exits at the same level as your loops as much as possible so as to not make the flow overly complicated and difficult to understand.
In the example diagram a Do-While loop was modeled, where something was done before the condition was checked. If you place the function after the condition is checked (on the Continue Loop Exit Condition) you would have the functional equivalent of a While-Do Loop.
One important thing to note about Loops and Loop Exits is the fact that usually somewhere in the loop you’re going to need a function with an Exit Condition. Loops must be broken somehow, you never want your model to have an infinite loop (bad programming form!). Using Exit Conditions becomes a normal part of creating logically correct loops. Keep in mind there is another way to break the loop, and break out of the diagram entirely. You can use an Exit as discussed in my last blog post. While this would be a fairly unusual way to break the loop logic, it is another tool for your modeling toolbox.
I hope this extended discussion of Exits and Loop Exits has helped to clear up the topic a bit. I wanted to go through a little bit more of the theory and draw parallels between the Exit conditions as GENESYS implements them and simple programming concepts. Exit logic, Loops and Loop Exits are key constructs to understand and use properly in order to truly capture your systems behavior correctly.
