Date and Time are valid Umple types but not respected in constraints

[GoogleCodeExporter]

What steps will reproduce the problem?

class X {
  Date d = "2013-04-01";
  Date e;
  [d > e]
}

What is the expected output? What do you see instead?

There should be valid comparisons between d and e allowed. Instead error 29 is 
generated incorrectly.

Original issue reported on code.google.com by TimothyCLethbridge on 18 Nov 2013 at 2:17

[GoogleCodeExporter]

Comparing two dates in PHP:
$dateA = '2008-03-01 13:34'; 
// your second date coming from a mysql database (date fields) 
$dateB = '2007-04-14 15:23'; 
if(strtotime($dateA) > strtotime($dateB)){ 
    // bla bla 
}

In Ruby

Original comment by asopa...@gmail.com on 8 Feb 2014 at 7:36

[GoogleCodeExporter]

r3427 adds support for Date constraints in Java, Ruby, and PHP.

Original comment by Astronomix@gmail.com on 9 Feb 2014 at 5:33

[GoogleCodeExporter]

Verified by Miguel G.
Tests confirm it.

Andrew F. reported a class that should be refactored:

ere is the (somewhat stripped down) view of the ConstraintVariable

class ConstraintVariable{
  type;//NOT USED: One order of parsing list each type of Umple Variable (Including the Constrained Variable).
  value;
  1 -> 0..1 Constraint subConstraint;

  boolean isAttribute = {!"SYNTAX".equals(type)&&!"OPERATOR".equals(type)};
  boolean isOperator = {"OPERATOR".equals(type)};
  boolean isAssociation = false;
  Integer index = -1;
  boolean isPrimitive = true;
  boolean isNumeric = {"integer".equals(type.toLowerCase())||
    "float".equals(type.toLowerCase())||
     "double".equals(type.toLowerCase())};
  UmpleVariable foundAttribute = null;
}

A few comments, questions

> "type" is indicated as not being used, but it clearly being used in the 
derived in the boolean lookups.  

> An attribute variable is called "FoundAttribute", and there is a method 
"getAttribute" which is used to "find" the attribute.  This is quite confusing 
unless you dive deep into the code.  I would prefer to see the following

>>> An UmpleClass attribute added to the ConstraintVariable to which it belongs
>>> FoundAttribute renamed to Attribute and turned into a derived Attribute
>>> The "lookup" of the attribute would be a cached method so it is only done 
once
>>> The ensure referential integrity, nil out the Attribute when the UmpleClass 
changes

OR

>>> Move this method to a static lookup and call it something like 
"findAttributeIn", and the parser code when populated the meta model would 
simply set the Attribute if "found"

In addition, I would consider adding an error is a constraint *is* an Attribute 
AND is not found 

> All classes should have an associated test class, no matter how simple, and 
here's why.  Simple classes, only typically start out simple and then another 
developer needs to enhance that class to provide better/more/different 
functionality, not having a place to easily add additional tests raises the 
barrier to allow this new work to also go untested.  In our case, a null 
pointer issue (and a long object chain) was refactored into a derived attribute 
(for which we had to create the test class as well as add the tests to 
demonstrate the proper handling of nil situation).

>>> In this case there are a few methods written that need tests to demonstrate 
proper expected behaviour

a) isNotPrimitive should be tested and converted to a derived attribute
b) testing of the above method as-is, and then ensuring the refactorings work

>>> Finally, equals was overwritten, but unfortunately not overwritten that 
well (and missing the hashCode method which is required for proper behaviour 
within a Java system).  I would look to re-use Umple's existing equality 
mechanism to avoid having to write this code directly (but again, we would 
write tests to demonstrate current functionality before the migration)

Original comment by asopa...@gmail.com on 9 Feb 2014 at 5:29

• Changed state: Verified