Real-time feature design involves considering multiple success as well as failure scenarios in the execution of a feature. Even for simple features, the total number of scenarios can be staggering, thus making it impractical to document all the scenarios. This results in the designer just focusing on the major scenarios in the execution of a feature. This lack of focus on other scenarios causes lot of system instability, often leading to unhealthy finger pointing sessions after the system fails to perform optimally. FDL solves the problems with multiple scenario definition by allowing designers to specify multiple scenarios in a single FDL file. Thus instead of defining multiple documents for each scenario, the designers just have to define multiple scenarios in a single file. In this section we will be covering how a single FDL file can store definitions of multiple scenarios. This is accomplished using the Case statement. Case statements are used to specify flow of the feature in different scenarios. The leg statements in the case statement correspond to different scenarios. Case statements can be nested; this allows definition of really complex scenarios. Once the Case statements have been defined in an FDL file, the Scenario Wizard is used to define multiple scenarios by selecting the case legs to be taken in each scenario. If this seems a bit complicated, look at the example below to understand how scenarios are defined. If statements in FDL build upon the case statements. The if statements are useful when a single scenario selection leads to flow changes at multiple places. The if statements can use the scenario selection from a case statement to choose between two different flows. | Call7.fdl | module : customer1:customer, exchange, customer2:customer
processor : phone1:phone in customer1, phone2:phone in customer2
processor : frontend1:frontend in exchange, core in exchange
processor : frontend2:frontend in exchange
eternal : call_mgr1 in frontend1
eternal : call_mgr2 in frontend2
dynamic : call1:call in frontend1, call2:call in frontend2
/* Originating Call Setup */
feature "Call Setup"
pick_up_phone : env_l -> phone1
offhook : phone1 -> call_mgr1
(* Subscriber lifts the phone to initiate a call *)
call_mgr1 takes action "Check Customer Privileges"
call_mgr1 allocates "Subscriber Terminal"
call_mgr1 creates call1
call1 state = "Idle"
offhook : call_mgr1 -> call1
call1 begins action "Feeding Dialtone"
dialtone : call1 -> phone1
call1 state = "Awaiting Digits"
call1 starts await_first_digit_timer
dial_digits : env_l -> phone1
digits : phone1 -> call1
call1 ends action "Feeding Dialtone"
call1 stops await_first_digit_timer
call1 starts more_digits_timer
timeout more_digits_timer
setup_call(digits="1-800-433-444", mode=NORMAL) : call1 -> core
call1 state = "Awaiting Call Setup"
call_setup_request : core -> call_mgr2
call_mgr2 creates call2
call_setup_request : call_mgr2 -> call2
ring_phone : call2 -> phone2
ringing : phone2 ->env_r
call2 state = "Ringing Subscriber"
call_setup_response : call2 -> core
setup_complete : core -> call1
call1 state = "Awaiting Answer"
[* Setup complete, waiting for called susbcriber to be rung *]
ringback : core -> phone1
1. case
2. leg "Called subscriber answers the call":
pick_up_phone : env_r -> phone2
answer : phone2 -> call2
answer_received : call2 -> call1
[* Call is now in conversation mode *]
3. case
leg "Called subscriber hangs up first":
hang_up : env_r -> phone2
clear_back : phone2 -> call2
clear_back : call2 -> call1
leg "Calling subscriber hangs up first":
endcase
4. leg "Called susbcriber does not answer the call":
leg "No answer and subscriber has voice mail service":
issue "Voice mail call handling needs to be added"
endcase
hang_up : env_l -> phone1
onhook : phone1 -> call1
release_call : call1 -> call2
5. if "Called subscriber answers the call"
LogCall(status=METERED_CALL) : call2 -> core
6. else
LogCall(status=UNMETERED_CALL) : call2 -> core
stop_ring : call2 -> phone2
endif
released_call : call2 -> call_mgr2
call_mgr2 deletes call2
released_call : call_mgr2 -> call1
call_over : call1 -> call_mgr1
call_mgr1 deletes call1
call_mgr1 frees "Subscriber Terminal"
endfeature
|
- The case statement is enclosed in the case and endcase keywords. The case statement defines different legs that can be taken by the feature at this point. When EventStudio encounters a Case statement, it expects an input on which leg of the case statement has to be selected. This input is usually provided by the Scenario definition in a Scenario Project.
- This statement declares the first leg in the case statement. This leg defines the feature leg taken when the subscriber answers the call. The statements that follow a leg statement will be executed only if the leg has been selected.
- Any FDL statement can be used after the leg statement. Here we have shown a nested case statement. This case statement specifies the differences in flow, depending on which subscriber clears the call first.
- This is the next leg for the outer case statement. This also marks the end of flow for the leg statement described in step (2.). Note that this leg statement does not have any FDL statements specified after it. This means that for this leg no specific action is required.
- This statement demonstrates the if-else-endif statement. The if statement switches on a previously defined leg label. The if leg will be taken if the corresponding case leg was selected in the case statement. The else leg will be taken if the corresponding leg was not selected in the case statement.
- The else-endif block is specified here. This block is optional, i.e. an if-endif statement might also be used, if no specific flow needs to be specified in the else leg.
|
