t the very heart of any complex software application are business objects. As the user interacts with the software, business objects respond by carrying out requested actions such as performing calculations and retrieving, validating, and manipulating data.
Often, business objects need to call on the services of other business objects to accomplish a particular task. There are two diagrams in the Unified Modeling Language (UML) that help to document and describe this interactionsequence diagrams and collaboration diagrams. Collectively, both of these are known as interaction diagrams.
Although they both describe object interaction, sequence diagrams focus on showing the order in which messages are sent between objects. In contrast, collaboration diagrams focus on the relationships between the collaborating objects.
Why use Collaboration Diagrams?
Of the two types of interaction diagrams, sequence diagrams seem to be used far more than collaboration diagrams. So, why would you use collaboration diagrams?
Collaboration diagrams allow you to see both the dynamic aspects and static relationships of business objects in a single diagram.
|
|
First of all, they are very useful for visualizing the relationship between objects collaborating to perform a particular task. This is difficult to determine from a sequence diagram. In addition, collaboration diagrams can also help you determine the accuracy of your static model (i.e., class diagrams). Some developers take the step of creating static models of their business objects, but don't "prove" their models by creating associated dynamic models. Once you put your classes into action (or interaction), you can often see flaws in your static model that may not have been discovered otherwise.
|