Guard rename

[t-lohse]

Fixes #80
This PR is more or less just a big refactor. I have tried to rename Guard to Expression and Guard to Invariant when it fits (Expression in general, and Invariant in context of locations). However, I have a few places I am uncertain if I should change or not

• src/logic/State.java l. 43 - We have these identical functions. Since it is a State, I am not sure whether it is a guard, an inviriant, or just an expression we are applying.

public void applyGuards(CDD guardCDD) {
    invarCDD = invarCDD.conjunction(guardCDD) ;
}

public void applyInvariants(CDD invarCDD) {
    this.invarCDD = this.invarCDD.conjunction(invarCDD);
}

• src/models/Federation.java l. 51 - Just to be sure, it should be the more general term Expression used here instead of Guard? Or maybe just remove the function as it is currently unused (unless it will be used in the future)?

public Expression toGuards(List<Clock> clocks)

• src/models/Zone.java l. 53 - There are a lot of occurences of Guard in this file, but I am mainly thinking of the method buildConstraintsForGuard, it this truly only happens when building guards on edges, or if this should be renamed to something more general.

public void buildConstraintsForGuard(ClockExpression guard, List<Clock> clocks) {
    if (guard.isDiagonal()) {
        buildConstraintsForDiagonalConstraint(guard, clocks);
    } else {
        buildConstraintsForNormalGuard(guard, clocks);
    }
}

• And finally, I am generally unsure if Expression is to ambiguous, since it could be interpreted as both arithmetic and boolean expressions. Should It be renamed to BoolExpression or something similar? And how should we then handle the distinction between the current BoolExpression and the "new"?

[Brandhoej]

src/logic/State.java l. 43: We could merge the to functions and name it applyToInvariant. Then the formal parameter could be named expression.

src/models/Federation.java l. 51: Since it calls buildExpressionFromZone (I would prefer it to be called toExpression, as it does not apply the builder pattern) then I think an appropriate name could be toExpression

src/models/Zone.java l. 53: buildConstraintsForGuard should maybe be called applyConstraints.

I think the "new" Expression should be renamed to BooleanExpression. Then the "old" BooleanExpression should be changed to something like BinaryBooleanExpression.

[Brandhoej]

Some minor requests. Personally, I think that the rename from Guard to Expression was necessary as it made the cod more clear as invariants should not be type Guard. However, I think we should revisit the structure of this AST. Should we instead of AndExpression, OrExpression, and BoolExpression have a BinaryExpression class. Instead of TrueExpression and FalseExpression we should consider Literal with boolean value and integeger for boolValue in BoolExpression. Then we could have classes for Guard and Invariant. Making this change would follow a more conventional structure. For this reason, I think an issue on this should be opened and act as a dependency for #97.

[Brandhoej]

I think this call does exactly the same as toString.

[Brandhoej]

Ìf toString joins on || instead of or then I think they are exactly the same

[Brandhoej]

Can you please add some documentation to this class?

[t-lohse]

I am afraid I am misunderstanding, so I have a few questions in regards to the new structure you are suggesting:
Are you saying we should remove AndExpression, OrExpression, and BoolExpression and replace it with a BinaryExpression, or have them derive from this new BinaryExpression class? And why would BoolExpression be this, since it is not composite? And if BinaryExpression does replace the others, would you like it as a "simple" tree-structure?
I am not entirely sure what you mean with the new Guard and Invariant classes, wouldn't they be the same, and just a wrapper around the expressions?
Would you like to have the Literal class derive from BooleanExpression as well, making it easier to have a simple literal without having to use BoolExpression?

In regards to the grammar (src/antlr/ExpressionGrammar.g4), should it be called expression(s) as I have implemented currently, or should they be renamed as well? If it should be changed, should we rename boolExpr as well to avoid naming clash?
Beyond that, I noticed that boolExpr is defined as boolExpr : VARIABLE OPERATOR BOOLEAN, which means that the expression x < true is valid. I don't know if this is the point and I just have misunderstood something in regards to the expressions, or if this is a mistake and should be boolExpr : VARIABLE OPERATOR INT or limit the operators such as

boolExpr : VARIABLE EQ BOOLEAN | VARIABLE operator INT;

operator : EQ | ORD ;
EQ : ('==' | '!=')
ORD: ('>=' | '<=' | '<' | '>')

This may also let us omit the check in src/models/BoolExpression.java l. 12:

if (relation != Relation.EQUAL && relation != Relation.NOT_EQUAL) {
    throw new IllegalArgumentException("The relation of the clock expression is invalid");
}