I can't find answer for my question . Is there a limit to how much dependency reliationship can be between two classes ? Does UML class-diagrams in general can't have more than one reliationship of the same type between two classes but they can have 2 or more reliationship of different types (for example between two classes they both can have composition and generalization reliantionship ?
3 Answers
You can have many associations between two classes, as well as many dependencies. You should stereotype those dependencies to differentiate them.
6 Comments
Macieyerk
Thanks for answer , are these rules apply to aggregation , composition and generalization reliationship can I have two classes that have composition and generalization reliantionship ?
Jim L.
Yes, of course. You would need stereotypes to differentiate generalizations because more than one makes no sense.
Macieyerk
Final question , I can mix different reliationships between two classes without restrictions for example aggreagation + composition , composition + generalization or dependency + assocations + aggregation + composition + generalization ?
Macieyerk
I did upvote but since I have low rep it will not show
Jim L.
Thanks. Yes, you can have many associations, each having an aggregation or composition. As I said, you can have many generalizations and many dependencies, but they make no sense unless you distinguish them using a stereotype. A stereotype can make a "line" an instance of a more specific kind of UML dependency or generalization. Why are you asking such odd questions?
|
In general the UML specification does not restrict how many relationships of a specific type can be between the same classes, but due to the logic and meaning of a relationship you can assume some limitations.
- Generalization, realization have a meaning where if there exists this relationship between two classes, it directly implies some consequences. Repeating the same relationship for the second time will have no further impact so it doesn't make any sense. It's also hard to specialize further those relationships through stereotypes.
- Simple dependency provide some information that again cannot be "repeated" by having next dependency. Yet stereotyped dependency can bring more value and information so you can have more than one of dependency but with different stereotypes. Once you have one dependency of specific stereotype repeating the same one doesn't provide additional value, yet another dependency of different stereotype is a fully understandable and reasonable case. In theory the same dependency could be applied twice in two different directions, but I would then investigate deeply - it is usually showing that there is something wrong with the project.
- Associations (including aggregation - both shared and composite) between two classes can have many different meanings. They should be differentiated either by association name, association roles, stereotype or by mixing those methods. So you can have multiple associations of the same "type" between the same two classes and they will have significant meaning. So many associations between the same classes are absolutely OK and it is a typical situation.
- Mixing different relationships are also absolutely OK, however sometimes one relationship implies other. In general any (or almost any) relationship imply non-stereotyped dependency (in the same direction) so using it explicitly doesn't give any additional information or effect.
Comments
There is no limit to how many dependencies can be between two classes. But you have to consider a couple of important moments. On the website https://vaughnvernon.co of a principal architect Vaughn Vernon I have found interesting comments about usage of UML dependencies:
While dependency may have a broad meaning, it is best not to overuse the dependency relationship. In an analysis model class diagram such as a domain model diagram, you may be tempted to convey that all the classes just depend on each other. Interestingly, however, the Rational Unified Process (RUP) specifies that the general class relationship that should be used in the analysis model is association, and not dependency. Therefore, even when you are modeling higher-level concepts it is best not to use the dependency relationship loosely. It is just too nebulous.
Further, unless you use the dependency relationship in a constrained manner your model consumers (yourself or other developers) will simply have too broad an interpretation of its meaning. Generally those filling architect and designer roles in a project are there to give guidance to less experienced developers. Thus the dependency relationship should be used to convey a specific kind of guidance from architects and designers to developers.
So what should a dependency relationship represent? In our UML example above the dependency means that class A uses class B, but that class A does not contain an instance of class B as part of its own state. It also means that if class B’s interface changes it will likely impact class A and require it to change. I suggest that you constrain your use of dependency relationships to non-state related concerns. You would use dependency to indicate that, for example, class A receives an instance of class B as a parameter to at least one of its methods. You would also use dependency to indicate that class A creates an instance of class B local to one of its methods. You would not, however, use dependency to indicate that class A declares an instance variable of class B, as that would indicate a state-related concern. Again, use association to do that.
