Uncovering Requirements With UML Class Diagrams Part 5

digging

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.

Catching Up On UML Class Diagrams

If you navigated to this page first, it is the fifth in a series introducing UML Class Diagrams for requirements elicitation.

  1. Uncovering Requirements With UML Class Diagrams Part 1: Discusses how to represent objects and entities from a business perspective.
  2. Uncovering Requirements With UML Class Diagrams Part 2: Discusses simple relationships between objects or entities.
  3. Uncovering Requirements With UML Class Diagrams Part 3: Discusses combining objects into collections and concepts.
  4. Uncovering Requirements With UML Class Diagrams Part 4: Defines generalization (inheritance) and how to use it.
  5. Uncovering Requirements With UML Class Diagrams Part 5: This article

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.

Understanding Details About The Relationship

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.

linkedin

crunchbase

As part of your requirements gathering, you need to understand how these court cases work – so you start with a class diagram.

First – identify the main players in the lawsuits:

litigants

Both a plaintiff and a defendant are litigants, as they are involved in lawsuits.

uml class diagram of suing

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.

lawsuit

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.

Creating An Association Class in a Visio UML Class Diagram

To create an association class, you use the Association Class shape in the Visio UML Static Structure stencil.

association class visio shape

Drag the association class onto the page.

default visio uml 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…”:

shape display options menu

And disable the display of the end names:

shape display options dialog

Now your shape will look like this:

updated uml association class

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)

dragging line ends

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.

Even More Complex Relationships

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.

In the Visio UML Static Structure stencil, select the N-Ary Link shape.

visio uml class diagram n-ary shape

Drag it onto the page

n-ary shape default

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.

connecting uml classes with an n-ary link

After you’ve connected the ends (or before, but after is easier), double click on the shape to bring up the properties dialog.

visio uml n-ary link 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:

final lawsuit relationship

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.

  • Who does the suing? Is it the plaintiff, the defendant, or the suit itself?
  • 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.

A Simpler But Busier Alternative UML Class Diagram

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:

alternate uml class diagram associations

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

  • A single plaintiff attacks with one or more lawsuits.
  • 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.

Next Up

In the first five parts of this series we’ve covered

  • Using classes to represent business objects and entities.
  • Using simple associations (relationships) to demonstrate how objects are dependent or how they relate to one another.
  • Using composition and aggregation to show how objects are treated when grouped together.
  • Using generalization and inheritance hierarchies to show how similar, related objects can behave differently.
  • Using association classes and n-ary associations to express more complex relationships.

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.

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.

  • Scott Sehlhorst

    Scott Sehlhorst is a product management and strategy consultant with over 30 years of experience in engineering, software development, and business. Scott founded Tyner Blain in 2005 to focus on helping companies, teams, and product managers build better products. Follow him on LinkedIn, and connect to see how Scott can help your organization.

4 thoughts on “Uncovering Requirements With UML Class Diagrams Part 5

  1. Thanks Jakyra!

    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).

  2. 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.

    Most sites I go to, the use cases are large, complex and unreadable.
    The business sign them off having only commenting on syntax and having ignored the semantics.
    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.
    The developers have sometimes refused to use work with them.
    The test teams almost start again in building test scenarios.

    Use cases should describe the actor-system interaction, NOT the functionality. ‘What’but NOT ‘How’. This gives them a simplified pattern of
    Actor does …
    System does …
    Actor does …
    System does … etc

    The more common pattern by far is
    Actor does …
    System does …
    System does …
    System does …
    System does …
    Actor does …
    System does …
    System does …
    System does …
    Actor does …etc

    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.

    This is a ‘win-win’ situation for all concerned:

    – 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.

    Hope this helps,
    Gil

  3. Going back to your first paper of this series, I see the comment that you have NOT defined class diagrams, but ER diagrams instead.

    With my addition, you ARE producing class diagrams. This is what I meant by ‘Complete’ classes.
    Gil

Leave a Reply to jakyra Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.