In this article, we build on our ability to represent straight forward business relationships in UML class diagrams. These relationships describe how two objects are related to each other. Representing relationships in class diagrams helps us to better understand the domain and helps us to uncover hidden requirements. Occasionally, we have to deal with more complex relationships that involve more than two objects to properly describe. This does not happen as frequently, but when it does, our modeling efforts are more likely to uncover overlooked requirements. In this article we learn how to describe relationships that involve more than two objects.
If you navigated to this page first, it is the fifth in a series introducing UML Class Diagrams for requirements elicitation.
Uncovering Requirements With UML Class Diagrams Part 1: Discusses how to represent objects and entities from a business perspective.
Uncovering Requirements With UML Class Diagrams Part 2: Discusses simple relationships between objects or entities.
Uncovering Requirements With UML Class Diagrams Part 3: Discusses combining objects into collections and concepts.
Jump back to the other articles and get up to speed if you need. We’ll wait for you here. As a reminder, in this series, we’re specifically focusing on using UML class diagrams for uncovering requirements – as part of analysis, not design. We’re talking about what the business needs, not how the solution will work.
One reason you may want to deal with more than two objects is obvious only after you change your way of thinking. So far, you’ve been thinking about objects (classes) and relationships (associations). Sometimes, when you need to understand the details of the relationship, you should think about the relationship as an object. It is both a relationship AND an object. And you draw this with an association class. We’ll walk through an example that illustrates the idea clearly, then we’ll look at the steps needed to create a relationship that is also an object.
Consider that you are gathering requirements to support software for tracking court cases – perhaps a mashup site that combines the latest public record lawsuits with entries from LinkedIn (my profile) and Crunchbase.
As part of your requirements gathering, you need to understand how these court cases work – so you start with a class diagram.
That represents a simple relationship. A plaintiff sues one or more defendants. When you show this diagram to one of your stakeholders, she likes that you captured that one plaintiff can sue more than one defendants. She also likes that you can determine “who is the plaintiff suing” as well as “who is suing a given defendant.”
You point out one small problem – it is not clear if the plaintiff can only sue multiple defendants one-at-a-time, or if the plaintiff can sue multiple defendants in the same lawsuit. You get the answer (multiple defendants can be sued at the same time), and as you start to scratch your head about how to represent it, your stakeholder interrupts (they do that):
“We need to be able to show lawsuits with a “most recent” view, and a “largest” (in dollar amount) view on the main page of the site!” You realize that your diagram doesn’t work, and you make a note to yourself about the multiple-defendants issue.
You need a way to capture information about the suit. Suddenly, instead of a verb (sues), you need a noun (suit). You need to reason about the relationship. So you update your class diagram.
Your updated diagram now shows that a single plaintiff, in the context of a single suit, can sue multiple defendants. You also capture that you need to know the trial date and the dollar amount of the suit. You erase that note to yourself, because your diagram now clearly indicates that one lawsuit involves multiple defendants. You make another note to yourself that it is not clear if a plaintiff can be involved in more than one suit with the same defendants (he can). You’ll deal with that later.
What you’ve drawn is something (the suit) that is both a relationship and an object. In UML class diagrams, this is called an association class.
By now, you realize that you need to suppress the end names in the display. Right click on the shape and select “Shape Display Options…”:
You can manipulate the shape and its placement in two different ways. You can select and drag either line end (to connect to another shape in the diagram)
Or you can drag the “class” portion (the box) of the shape to wherever you want to place it. [Note: When you drag the class, it looks like you are disconnecting the line from the shapes and messing everything up. It is not happening. When you release the mouse button, the class will be where you put it, and the line will still be where it was before.] There is a dashed-line that connects the class (the box) to the association (the line). Visio automatically updates that for you – you never have to worry about it. In fact, if you don’t like it where it is, you can’t do anything about it either.
You could use the rotate-handle (the green circle on top) to rotate the box, but please don’t. Class diagrams, by convention, are drawn with everything aligned with the page. To get the line on top, just drag the line ends above the shape (or drag the shape below the line ends).
You use the same rules for showing directions with an association class that you do with a regular association. If the business needs to think in one direction – “Who has the plaintiff sued?” then show that arrow. If the business wants to think in the other direction – “Who has sued a particular defendant?” then show the opposite arrow too.
The cool shape above lets you draw a three-way relationship. It is most handy when you need to understand something about the relationship itself – treating the relationship as a noun instead of a verb. You can create relationships in UML class diagrams that involve more than three objects. These are called N-Ary Associations. The “N-Ary” part is geek-speak for “binary, trinary, quaternary, etc” – any number is valid.
Earlier, we glossed over one question – “Can a single plaintiff, related to multiple defendants in the context of a single suit, also be related to those defendants by another suit?” You can use an n-ary association to depict this.
It looks a bit like a decision diamond from a flow chart, but with handles. Drag it to where you want it to be in your diagram and then start connecting the line ends to the related classes.
After you’ve connected the ends (or before, but after is easier), double click on the shape to bring up the properties dialog.
You’ll see three “Link Ends” – just rename them to show the multiplicity of the connections. You will end up with a final diagram that shows:
One plaintiff can sue one or more defendants in one or more suits. You could (and I will) argue that this is even more ambiguous than the previous diagram.
Are they even suing? Perhaps the relationship is just “they are all in the same room at the same time.”
When a plaintiff sues multiple defendants, is it one defendant per suit, with multiple suits? Can it be? Must it be?
Personally, I never use an n-ary association when modeling complex relationships. I much prefer the association class.
You never have to use an association class. You can always represent the situation with three classes and two associations as the following diagram shows:
Instead of an association class, you create a single class (suit) that represents the noun, and you break up the single association (suing) into two association (attacks with, defends against). In some ways, this is more precise than using an association class. You can tell from the diagram above that
One or more defendants defend against a single lawsuit. Therefore, there could be two suits between the same plaintiff and the same defendants at the same time.
What you lose is a notion that the suit establishes the context of the relationship between the plaintiff and the defendant(s). Ultimately it is a judgment call about which form to use (the association class or the normal class with two associations). If understanding the specific multiplicity data is important, you should use the two-association diagram. If it is not, I personally feel that the association class provides clarifying context.
Using simple associations (relationships) to demonstrate how objects are dependent or how they relate to one another.
Using generalization and inheritance hierarchies to show how similar, related objects can behave differently.
If you understand all of these concepts, you are ready to create UML class diagrams of the business domain and concepts. You are ready to use these tools to uncover otherwise hidden requirements. If you want to study some of the more arcane details around UML class diagrams, you should be ready to read Scott Ambler’s articles.
UML 2 Class Diagrams – an explanation, in detail, of how and what and why to draw things a particular way
Just keep in mind that Scott jumps right into complex topics (which you are now ready for), and also includes tips and advice that are only relevant when creating class diagrams of implementation designs. Just filter that stuff out. Or come up with a way to leverage those details to the modeling of business ideas, and share them here.
Thanks for following along this far, and if you have any questions or would like to see us cover anything else about using UML class diagrams for uncovering requirements, add a comment below.
← Uncovering Requirements With UML Class Diagrams Part 4	Flashback: This Week in the Past on Tyner Blain [Mar 22] →
My goal was to take one of the most powerful, but inaccessible tools I know – class diagramming, and make it accessible to 10x as many people. Ambler’s articles are great, but you really need a pretty technical background to consume them immediately.
Hopefully this series provides people with enough content, at the right speed, to make them effective with class diagrams, thus improving their ability to uncover hidden requirements (the hard part of requirements analysis).
Firstly let me congratulate you on one of the best sets of articles on this topic that I have seen. However, you have stopped one step short of perfection.
The Analysts feel the need to write requirements documents, because the requirements are all jumbled. At best, they insist on activity diagrams to outline them.
Examination of a sequence diagram shows that the first ‘System does ….’ could simply call procedures on other classes to achieve the system functionality. Then the subsequent ‘System does …’ clauses appear as procedures (methods) in their appropriate classes.
– The use case reverts to its proper pattern, which is then usually very much shorter with an even greater reduction in the number of alternate paths.
– The functional sequences appear in the context of the class that they are sensibly associated with. As these were the most complex parts of bloated use case, they benefit a lot in being described within the context of a static class or two. Alternate paths, become other calls, each to a procedure that does just one thing, and that thing is described in context.
– This is NOT design!!! All we are doing is writing down algorithms or workflows that the business demands. If they are NOT this, then they should never appear in any of the analysis documents. They are as much business requirements as the attributes and association rules you have already described.
– It makes for better Business Classes (or Domain Classes if you prefer), because they are mote complete. They do NOT have some relevant steps outlined in some use case (or may be outlined repeatedly in all the use cases that use that class).
– Once you have the class completely definedthe classes as fully independant items, it is then possible to insist that their influence on the development classes is kept visible. This then keeps the code as a working model of the business process being captured. The better this is, the longer the life of the code plus a number of more short term goals.
Going back to your first paper of this series, I see the comment that you have NOT defined class diagrams, but ER diagrams instead.