Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Duplicate methods generated when a class implements an interface and has association #834

Open
amidzak opened this Issue May 25, 2016 · 5 comments

Comments

Projects
None yet
4 participants
@amidzak
Copy link
Contributor

commented May 25, 2016

The example below has an interface that defines one of the methods that are generated by umple when having an association

interface X{
        boolean addY(Y ay);
}

class XImp{
        isA X;
        0..1 -> * Y; 
}

class Y{
}

When code is generated in java, PHP, Or Ruby (and probably other languages), the generated class has two implementation of add_y(Y a_y) . In Ruby it is addy(Y a_y).
The generated code for XImp in Java is below:

public class XImp implements X
{

  //------------------------
  // MEMBER VARIABLES
  //------------------------

  //XImp Associations
  private List<Y> ies;

  //------------------------
  // CONSTRUCTOR
  //------------------------

  public XImp()
  {
    ies = new ArrayList<Y>();
  }

  //------------------------
  // INTERFACE
  //------------------------

  public Y getY(int index)
  {
    Y aY = ies.get(index);
    return aY;
  }

  public List<Y> getIes()
  {
    List<Y> newIes = Collections.unmodifiableList(ies);
    return newIes;
  }

  public int numberOfIes()
  {
    int number = ies.size();
    return number;
  }

  public boolean hasIes()
  {
    boolean has = ies.size() > 0;
    return has;
  }

  public int indexOfY(Y aY)
  {
    int index = ies.indexOf(aY);
    return index;
  }

  public static int minimumNumberOfIes()
  {
    return 0;
  }

  public boolean addY(Y aY)
  {
    boolean wasAdded = false;
    if (ies.contains(aY)) { return false; }
    ies.add(aY);
    wasAdded = true;
    return wasAdded;
  }

  public boolean removeY(Y aY)
  {
    boolean wasRemoved = false;
    if (ies.contains(aY))
    {
      ies.remove(aY);
      wasRemoved = true;
    }
    return wasRemoved;
  }

  public boolean addYAt(Y aY, int index)
  {  
    boolean wasAdded = false;
    if(addY(aY))
    {
      if(index < 0 ) { index = 0; }
      if(index > numberOfIes()) { index = numberOfIes() - 1; }
      ies.remove(aY);
      ies.add(index, aY);
      wasAdded = true;
    }
    return wasAdded;
  }

  public boolean addOrMoveYAt(Y aY, int index)
  {
    boolean wasAdded = false;
    if(ies.contains(aY))
    {
      if(index < 0 ) { index = 0; }
      if(index > numberOfIes()) { index = numberOfIes() - 1; }
      ies.remove(aY);
      ies.add(index, aY);
      wasAdded = true;
    } 
    else 
    {
      wasAdded = addYAt(aY, index);
    }
    return wasAdded;
  }

  public void delete()
  {
    ies.clear();
  }

  @Override
  public boolean addY(Y aY){
          return false;
  }

}
@TimLethbridge

This comment has been minimized.

Copy link
Member

commented May 26, 2016

Good catch. I suggest you try to fix this to get you used to the process.

@amidzak amidzak self-assigned this May 26, 2016

@TimLethbridge TimLethbridge added the ucosp label Sep 13, 2016

@TimLethbridge

This comment has been minimized.

Copy link
Member

commented Sep 20, 2016

This could be a ucosp issue of Amid doesn't do it.

@amidzak amidzak removed their assignment Sep 20, 2016

@amidzak

This comment has been minimized.

Copy link
Contributor Author

commented Sep 20, 2016

I unassigned myself.
But why Umple should automatically implement methods of the unimplemented methods of the parent interface with just a simple return in the body? Since the generated code is not supposed to be altered this method seems useless to be automatically generated anyway.

@vahdat-ab

This comment has been minimized.

Copy link
Member

commented Sep 21, 2016

The main reason is that we wanted to execute our model in a simple way so we automatically generate some codes.
There must be some warnings related to this issue so modelers can notice this.
On the other hand, we don't have to have some many warnings in our parsing and compiling process. This must be analyzed. @TimLethbridge

@edmundluong edmundluong self-assigned this Sep 23, 2016

@edmundluong

This comment has been minimized.

Copy link

commented Sep 23, 2016

Issue appears to be caused by the JavaClassGenerator.getCode() method call, where it calls the getExtraMethodsCode() method which generates the code for the interface implementation (see here).

It appears that in getExtraMethodsCode(), it doesn't take any already implemented methods in the class in consideration hence why it adds a duplicate method from the interface.

My proposed solution is to check for existing methods with the same method signature (visibility, return type, parameters) in class_MethodDeclaration.ump since there is a similar conditional that checks to see if the method exists already in Java and then decides whether these extra methods should be added. (see here)

The UmpleClass and UmpleModel in the JavaClassGenerator appears to have no knowledge of the generated Attributes/Associations method code and their method signatures. Ideally, I should be able to access this information so I can make the appropriate checks to decide whether the method should be skipped over or not.

edmundluong added a commit that referenced this issue Sep 24, 2016

@edmundluong edmundluong referenced this issue Sep 24, 2016

Closed

Fixed #834 #890

@edmundluong edmundluong removed their assignment Nov 3, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.