I've been doing a little bit of reviewing the different code coverage testing used on embedded systems. In particular, I'm looking at the MC/DC. From what I understand, one of the objectives is to make sure that each logical clause in a statement should affect the outcome of the statement.
Two questions:
What is gained by independently verifying that each clause has an effect on the outcome?
Why would (A||B) && (A||!C) not be able to achieve 100% MC/DC, while A||(B&&!C) will achieve 100% MC/DC even if they have the exact same functionality?
To answer your questions
You want as little of code as possible and as less complex code as possible. Having unreachable conditions lengthens your code and makes your code unnecessarily complex.
(A||B) && (A||!C) won't achieve 100% because it requires A to be checked twice for no reason. In the condition where A is false and B is true, A's truthiness will be checked for a second time in the (A||!C) expression for no reason in this formulation whereas in the formula A||(B&&!C) has A's truthiness being checked only once.
Related
Sometimes the checks and contract constructions need an elaboration which wants to be avoided when assertions removed to improve performances and avoid doing useless things with the "only" work of the compiler. I refer for ex. to job in loops checks or other things. Sometimes having to build a function or having to think how to build it without being executed when assertions are on goes away of the intuitive way of the contract and its sense. I refer particularly to the check structure
Is there a way to do something such as
if checks_are_enabled then
do check stuff here
end
do_some_normal_job
if checks_are_enabled then
do other check stuff here
end
Assertions can be turned on and off on a class-by-class basis, with different levels: preconditions, postconditions, invariants, etc. As a result, it would be tricky and unreliable to report when they are enabled or not (consider, for example, inherited code: the checks might be on in one case and off in another). On a methodological level it would also break the idea that a correct program works the same way regardless of assertion monitoring.
What are workarounds?
If assertions are complex, they can be factored out to dedicated queries and look like
check
is_valid: complex_query
end
An alternative is to use debug statements:
debug ("check_this", "check_that")
... some complex code, including assertions
end
where "check_this" and "check_that" are debug keys that can be turned on when compiling for debugging.
There are hacks that could work now, but not in the future:
If a complex state needs to be computed and then checked after some operation, it can be saved in an object passed to some function with complex calculations and used later again:
check
is_valid_before: valid_pre (state) -- The state is computed by `valid_pre`.
end
code_that_does_the_work
check
is_valid_after: valid_post (state) -- The state is checked by `valid_post`.
end
Some global flag can be used to keep track about assertion monitoring:
check
is_monitoring_checks
end
where query is_monitoring_checks has side effects:
is_monitoring_checks: BOOLEAN
-- Record whether assertion checks are turned on.
do
is_check_on := True
Result := True
end
Then, subsequent code could be written as asked in the question:
if is_check_on then
... -- Do some complex calculations when assertions are turned on.
end
I don't understand this issue:
Issue: HIS Metriken - Cyclomatic (CR-MET4): [function_name] 13>10
It appears in Klocwork analysis while checking the issues of Code: METRICS.E.HIS_Metriken___Cyclomatic__CR_MET4_
Can anyone support?
Thanks
Do you see all those ifs, elses, loops in that function?
Those are the problem, you need to either design this function's logic more elegantly or split it into more functions with well-defined purposes.
By the way, I can only see that problematic function of yours because I am especially clairvoyant. For this kind of question you should normally show your code, just to be fair towards all those other users which cannot read your mind like I did.
Naaa, not really. The cyclomatic complexity is a measure for number of potential paths through your function. And that you have crossed the treshold of 10 by 3 means your function must be full of control structs, which create many paths.
I've been drawing a sequence diagram of a module recently, while reverse engineering.
I encountered a control statement, and it is like,
if (func_A() == True)
{
DoSomeThing();
}
else
{
DoSomeThingElse();
}
The problem is how to draw the condition?
As I mentioned, It is reverse engineering. The code cannot be modified now.
I drew two diagrams, and I don't know which way is right,
The first one is this, I think it's wrong because it doesn't show the function call as a message from A to B.
This is the second, It shows a message func_A.
What do you think about to do this right?
To complete the other answer there is anyway a problem in the second proposal because we do not know if in [func_A() == True] you reuse the value return by the previous call or you do a second call, to avoid that add the explicit return in your diagram :
Out of that do you know the activities ? A sequence diagram is "just" an interaction while an activity is a behavior and can be more adapted :
It depends. If func_A is an operation defined in Object2 the second representation would be correct. The first does not tell where the operation is defined. Most likely (!) one would interpret func_A as an operation local to ObjectA which your code seems to say. (Btw. you have two completely different object sets AB vs. 12 in your examples.) But that is uncertain. So the 2nd variant is more explicit (and correct).
In any case I advise to not overdo SDs with fragments as "graphical programming" doesn't make things easier to read (my practical experience). It's excellent to show message flows in various collaborations. But when it comes to conditions it's getting messy very soon. A better way is to create different sub-diagrams or even use pseudo code if there are too nested if conditions. In many cases such if clauses are a good fit for state machines.
I am currently trying to write a code to solve a non linear system of equations. I am using the functions of the gsl library, more specifically the multiroot_fdf_solver.
My problem is that it currently doesn't want to converge. More specifically, I have the following behavior:
-if my initial conditions are close to the result, the gsl_multiroot_fdf_solver_iterate does not update the parameters at all. I tried to display the results on the different steps, and I have for all the parameters dx = NaN (I think this quite srange), the status of gsl_multiroot_fdf_solver_iterate is "success" and the status of gsl_multiroot_test_residual is "the iteration has not converged yet"
-the parameters are only updated if my initial conditions are really far from the expected result. Obvisously in this case it does not converge to the right values.
I have already checked multiple times the expression of my function and my Jacobian, and they seem good.
I have to precise that my Jacobian (and my system as well) are quite complicated expression with many trigonometric function.
Would you have any idea of what it could be? Is it possible that if the expression of the Jacobian is too complicated, it has troubles to compute it?
Thank you in advance for your answers, I am really stucked at this point.
When we converting from nfa to dfa there may be result like the image below... My question is, is it necessary to write that from state {4} it's going to Zero state? I mean that without showing the input symbol 1 of {4} is the same with picture below right? or no?
It’s a matter of convention. Personally, I prefer not to clutter my DFA with unnecessary states, especially since DFAs obtained via transformation from NFAs tend to become quite complex anyway, and since it’s deterministic we know that any non-displayed transition must be invalid.
However, I’ve experienced that many people in academia teach / use the other convention, and require all transitions to be explicitly shown. When working as a TA (tutor) I’ve actually had a discussion with a professor about this – he wanted us tutors to deduct points on the final tests for missing transitions in DFAs but I convinced him that deducting points for this was unfair.
it is not necessary to write {4}-> 0 transition because the automat is already accepting the word. this transition means only that this is "nothing" meaningful for our solution. but for details, it is useful to give it, to show the whole automaton.
It matters only if you are trying to draw the MinimalFA (MFA).
Actually you can generate infinite number of DFA s from a single NFA, each of which differ in number of states.
If you remove 'Dead States' in the figure,you will get the MFA.
The figure is OK if you just want a DFA