EclipseUML Reverse engineering uses following rules to resolve inverse associations:

1. If Class A has an association “b” of type B and Class B hasn’t any association of type A, there isn’t inverse association.
2. If Class A has an association “b” of type B and Class B has only one inverse association “a” of type A, we set up the two associations as inverse associations.
3. If Class A has an association “b” of type B and Class B has more than one association of type A (for example, “a1” and “a2”), we try to resolve this conflict by analysing the accessing of the two couple of attributes: “b” and “a1”, “b” and “a2”.
1. If there is only one method that accesses one couple of attributes directly or via getter/setter, this couple of attributes will be considered as inverse associations.
2. If there is more than one method that accesses both couples of attributes, we use collected statistic to resolve this conflict.

For example:

public class Project

{

   private HashMap teams = new HashMap ();

      public void addTeamMember(String name, Employee member) {

            Collection team = (Collection) teams.get(name);

            if (team == null) {

                  team = new ArrayList();

                  teams.put(name, team);

            }

            team.add(member);

            member.setProject(this);

      }

}

The attribute accesses are in bold. So the associations implemented by the attribute teams and project are inverse associations.