Section 6.2. Links

6.2. Links Objects on their own are not very interesting or helpful. To really show how your objects will work together in a particular runtime configuration, you need to tie those objects together using links, as shown in Figure 6-5. Figure 6-5. Links are shown using a line between the two objects that are being linked Links between objects on an object diagram show that the two objects can communicate with each other. However, you can't just link any two objects together. If you create a link between two objects, there must be a corresponding association between the classes. The links on an object diagram work in a similar fashion to links on a communication diagram (see Chapter 8). However, unlike communication diagrams, the only additional piece of information that you can optionally add to a link is a label that indicates the purpose of the link, as shown in Figure 6-6. 6.2.1. Links and Constraints Links between objects correspond to associations between the object's classes. This means that where constraint rules have been applied to an association, the link must keep to those rules. Figure 6-6. To play some tunes, a BlogEntry object is connected to a UserInterface object In Chapter 5, the relationship between BlogEntry, BlogAccount, and Category was modeled using an association class, as shown in Figure 6-7. Figure 6-7. When a BlogEntry is added to a BlogAccount, it will be grouped under one or more categories; the Category class is associated with the relationship between a BlogEntry and a BlogAccount If the diagram in Figure 6-7 were left as it is, then the two object diagrams shown in Figure 6-8 would be perfectly valid. Figure 6-8. A BlogEntry can be associated with a BlogAccount and a set of categories, but there is no rule that states that a BlogEntry must be associated with a category If you wanted to show that an entry must be associated with a category when it is contained within a blog account, you need to add some OCL to the original class diagram, as shown in Figure 6-9. OCL was briefly covered in Chapter 5 and is covered in more depth in Appendix A. Figure 6-9. The constraint states that within the context of the BlogEntry, a BlogEntry object should be associated with a category and that the association should not be null; in other words, for a BlogEntry to be added to a BlogAccount, it must have a category assigned Objects and their links must abide by the rules set by the OCL statementsthis is one of the reasons why OCL is called the object constraint language, and not the class constraint language. With the constraints applied to the class diagram in Figure 6-9, the possible options for an object diagram based on these classes is reduced to something that makes much more sense, as shown in Figure 6-10. Figure 6-10. The self.category->notEmpty( ) constraint affects the options available when you create an object diagram, ensuring that an entry is associated with a category for it to be added to a BlogAccount