1

I am not sure what is the multiplicity between A & C, and also between B & C, for the following Java classes...

FYI: Class A and Class B may invoke either some or all the methods in this generic Class C.

My guess:

  1. Class A (1)-----Class C (*)
  2. Class B (1)-----Class C (*)

Please correct me if I am mistaken here.

One more thing, when is it a many-to-many relationship for both (1) & (2)?

class A{
    //methods in Class A only involve Ball objects
    methodA(){
        C<Ball> newObj=new C<Ball>();
        newObj.method1();
    }
}

class B{
    //methods in Class B only involve Tennis objects
    methodB(){
        C<Tennis> newObj=new C<Tennis>();
        newObj.method1();
    }
}

class C<T>{
    method1(){
        //implementation here
    }
    method2(){
        //implementation here
    }
    method3(){
        //implementation here
    }
}
Jason C
  • 38,729
  • 14
  • 126
  • 182
user614454
  • 123
  • 2
  • 13

2 Answers2

3

In general you ask, how many different instances of X can exist for a single instance of a Y, and vice versa? In your example, it does not completely make sense to talk about multiplicity in a class diagram context, for two reasons:

  1. Your C does not maintain a reference to any associated A's or B's. Therefore, at best, it is a unidirectional relationship. This is OK when speaking of multiplicity, although not in your particular example (for which multiplicity does not make sense, see point 2). As far as multiplicity is concerned, ignoring point 2, A has exactly 1 C, B has exactly 1 C, and C has 0 A's and 0 B's.

  2. Your relationship is in the form of a local variable. Therefore it is not really a class-level relationship. This relationship disappears as soon as the method of A (or B) returns. So really it does not necessarily make sense to establish an association diagram for these classes. A caller/callee graph, perhaps, but a general association, no.

Your example, where A uses C locally in some of its methods, is an example of a dependency, not an association. UML typically uses a dotted line for that (although some flavors may differ), and multiplicity does not come into play for this (sorry for the poor quality):

enter image description here

There are a couple of small changes to your example that would make multiplicity relevant. For example, leaving C as it is but changing A to:

class A {
   C<Ball> c = new C<Ball>();
   ...
   methodA(){
       c.method1();
   }
}

In this case, an A has exactly one C, and a C has zero A's (it is unidirectional). The UML would look like (again, sorry for the quality):

enter image description here

That is, if you make the change above, it becomes a zero-to-one relationship. It's unidirectional because the C is not aware of the A.

One more thing, when is it a many-to-many relationship for both (1) & (2)?

It's a many-to-many relationship when A stores links to multiple C's, and C stores links to multiple A's. For example, students to courses in a university. Every course contains multiple students, and every student takes multiple courses. E.g.:

class Student {
    Collection<Course> courses;
}

class Course {
    Collection<Student> students;
}
Jason C
  • 38,729
  • 14
  • 126
  • 182
  • For unidirectional, I have seen some websites using dotted arrow with the same arrowhead as yours. Does it mean the same thing as your diagram above? – user614454 Nov 23 '14 at 16:22
  • @user614454 No, not usually. A dotted line typically indicates a *dependency* (which *can be* unidirectional, and usually is, but is not an association), rather than a class-level relationship. The dotted line would be more accurate for your original example, since A *depends on* C even though it does not maintain an association with C. I will update my answer to include this, since it is relevant. – Jason C Nov 23 '14 at 16:34
  • From your explanation, is it correct if I don't know the number of instances from class C...e.g. in situations where it depends on user input(and I never declare earlier in the attribute section of the code like you have shown)...does it mean I should use the dotted line version?? – user614454 Nov 23 '14 at 16:47
  • @user614454 User input is irrelevant. Even if you don't know how many instances there *will* be, if there *can* be more than one, it is "many". But, you would use the dotted line version not because of user input or whatever, you'd use it because *you're not actually maintaining a link, you just have a local instance in a method*. Simplified rules: If you have a member field that is just a plain reference type, it is "one". If it is a collection, it is "many". If there's no member field at all, it is "zero" or not an association. What you do with local variables in methods is irrelevant. – Jason C Nov 23 '14 at 17:24
  • *Independently* of that, if you do do stuff with local instances only (i.e. your example) but not with links in member fields, then it is nothing more than a *dependency* (which is really just a "weaker" form of an association). "A *has a* C" is an association, with multiplicity. "A's method *uses* C but A does not *have a* C" is just a dependency, multiplicity is not relevant there. – Jason C Nov 23 '14 at 17:26
  • 1
    @JasonC: Notice that the navigability arrow that you have used for your association line in the digram above is obsolete. UML 2.5 suggests expressing a reference property (like `A::c`in you example) with the help of a dot, as explained in http://stackoverflow.com/questions/21321446/is-there-a-free-uml-class-diagram-editor-that-supports-association-end-ownersh – Gerd Wagner Nov 26 '14 at 00:34
2

Multiplicity gives you an information about how many instances of specific type, attribute values or connected instances to link can be created. It has nothing to do with operation invocation. If for example multiplicity at the association end is [0..*] it means, that to one instance connected to opposite side of association you can connect zero or more instances.

A-C[0..*] = one instance of A has from zero to unlimited instances of C connected.

Vladimir
  • 2,066
  • 15
  • 13
  • So, if every method in class A or class B has an instance of class C, then it's a C[1..*]? – user614454 Nov 23 '14 at 15:58
  • And, if lets say only some methods of class A/B have instances of class C, then it's C[0..*]? – user614454 Nov 23 '14 at 16:02
  • It was an example how to understand multiplicity. Methods do not have instance, because of it to define multiplicity of method does not make sense. Only multiplicity definition within method (operation) are in parameters. – Vladimir Nov 23 '14 at 16:23
  • @user614454 No, that's not quite right. Whether or not the individual methods of A/B have local instances of class C isn't related to the multiplicity. The multiplicity describes *class level* relationships; i.e. an instance of an A maintains zero, one, or many links to an instance of a C throughout its life. – Jason C Nov 23 '14 at 16:25