Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Object Modeling
Let's change perspective for a moment. Assume that we are working with a customer or business analyst, trying to understand the requirements for a new system or new enhancement to an existing system. If we can draw a UML class diagram as we work together, then everyone participating can leave that session with a good understanding of the classes of objects involved and how they relate to each other. Even better, as developers, we are free to design and implement the classes and relationships in the way we know to be most appropriate for our production environment. For example, if it is more appropriate to use a HashMap than a Vector to implement a 0..* association, we can choose to do so. If it is more appropriate to use a method that retrieves a ResultSet from a JDBC-enabled database, we can do so.
When working with customers or analysts in this way, we are often unsure of the direction of a particular association. Also, in many cases, we may need to traverse the association in both directions. In these cases, instead of drawing two lines, UML allows us to place multiplicities on both ends of an association. Later, we can determine whether we can reduce the relationship to a single direction and place the arrowhead to indicate that design decision. If not, our Java code needs to maintain the relationship in both directions—maybe by using a reference or a collection of references in each class that refer to the other class in the relationship, and by using extra source code to ensure that both ends of the association remain consistent with each other.
As seen earlier, we can also help make the relationship clearer by indicating the role that each participant plays in the relationship. We may also give the association a name that identifies the purpose of the relationship. When it comes to implementing that relationship, we might use the role name as the name of the object reference or as part of the name of methods that set and return the other participants in the relationship. Figure 6 shows our employment relationship with multiplicities and role names at both ends. This time, we have shown that a Person may work for multiple organizations, either concurrently and/or over time; and that an Organization may employ multiple people, either concurrently and/or over time.
)
Figure 6 A bidirectional association in UML.