Uncovering Requirements With UML Class Diagrams Part 4

The hardest part of gathering requirements effectively is uncovering the requirements that people don’t immediately tell you. You have to ask the right questions. And one of the best ways to find the right questions to build a class diagram of the business domain. This article continues our introduction to class diagrams.

Catching Up on UML Class Diagrams

If you’ve found this article first, there are three that came before it.

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: This article.

So jump back to the other articles and get up to speed. 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.

Generalization: A Dog Is A Mammal

We’ve looked at objects and relationships between them. We’ve looked at the special association relationships that give us aggregation and composition. Generalization is another form of relationship, but not one that tells us how different objects interact – one that helps us better describe objects. We could talk about a dog, and create an object that represents a dog. But what if we also wanted to talk about a horse? They have some things in common, because they are both mammals. Generalization allows us to talk about mammals too. That’s fine, but let’s use a business example instead of a classroom example.

The key to this generalization relationship is to think about the phrase “is a.” A dog is a mammal. Don’t confuse this with combining objects into an aggregation. A pack has a bunch of dogs in it. A zoo has a bunch of mammals (and other animals) in it. But a dog is not a specialized pack. It is a specialized mammal.

Remember “…is a…”

This relationship carries special meaning – all things (characteristics, behaviors, etc) that are true about the general object are true about the specialized object. But all things about the specialized object are not necessarily true about the general object.

• All mammals have hair, therefore all dogs have hair.
• All mammals have live babies (they do not eggs), therefore all dogs have live babies (puppies).
• All dogs are pack animals, but all mammals are not (elephants are, but shrews are not).

Technical folks usually call this inheritance – the specialized object inherits all of the properties and behavior of the generalized object. Inherit is almost as good of a word to use as generalizes. Where inheritance really helps as a term is it allows us to think in terms of parents and children objects. The mammal is a parent and the dog is a child of mammal. The terms parent and child make it much less cumbersome to talk about generalization relationships.

Understanding Insurance Policies With Generalization

Consider that you’re working on a project for a life insurance company. In your first conversation with a subject matter expert, you hear five different terms for describing insurance policies. At a convenient pause, you stop the interview, walk over to a white board, and draw class diagram objects for each of the five items.

You ask your expert how all these objects are related to each other. She explains that all life insurance policies are either term policies (they last for a fixed term of time) or permanent policies (they last for as long as the premiums are paid).

You recognize this as a generalization relationship.

• Every Term Policy is a Life Insurance Policy
• Every Permanent Policy is a Life Insurance Policy

Your SME also informs you that permanent policies, as a form of investment, are always one of two special types – whole life policies and variable insurance policies. Whole life policies have a fixed return for a fixed premium. Variable policies invest your premium in market securities, and the amount of money available at the time of payment depends upon the performance of the policy. More generalization relationships.

• Every Whole Life Policy is a Permanent Policy
• Every Variable Insurance Policy is a Permanent Policy*

[*As far as I know. If there is such a thing as a variable term life insurance policy, my apologies – just assume that your company does not sell one.]

You draw the generalization relationships on the white board, and you move forward in eliciting requirements. This drawing is known as a hierarchy.

Drawing Generalization Relationships in Visio

You use the generalization shape in visio to create generalization (inheritance) relationships between classes in your class diagram.

As you drag it onto the page, it looks like the following:

The shape is an arrow with a closed (but not filled) arrowhead on one end. You connect that arrowhead to the parent class – the more-general of the two. The tail is connected to the child class – the more-specific of the two.

Once you draw all the relationships, your Visio class diagram will look like the following:

Now you’re prepared to understand the other information your subject matter experts are sharing, in the context by which the business is describing their requirements.

This hierarchy makes sense, but it seems to be completely different from all the other class diagram stuff we’ve done. How can you combine these different views? It is the combination of them that really brings out the value.

Relationships, Classes, and Inheritance

The first thing to realize is that association relationships, composition relationships, and inheritance relationships can all happily co-exist within the same UML class diagram. In fact, much of the insight you gain into uncovering requirements only comes when you combine these different analyses within a diagram.

The structure we looked at above provides a good description of how a company manages the policies that they write. What you are likely to want to document are requirements around selling those policies. Each time a policy is sold, an agreement is created. That agreement is a copy of the policy sold (at the time of selling it), with the insured person’s name filled in. You can imagine the policy to be a form with blanks that need to be filled in. Each time a policy is sold, someone makes a copy of the “official” policy, fills in the blanks – name of insured, policy dates, etc – and then it becomes an agreement.

Introducing the term agreement allows the business to treat the two ideas separately. A policy defines the agreements that can be sold at any given time. An agreement is one policy, as sold to an insured person (customer).

[click for larger diagram

As you can see from the diagram, we have the same hierarchy for describing insurance policies. We’ve added some other objects and relationships.

Objects

• Agreement. A policy written by an agent for an insured person. The agreement is written in a specific state.
• Agent. An agent is someone who sells insurance policies (agreements). The agent lives in a specific state.
• Insured Person. Someone who purchases an insurance policy (agreement). The person lives in a specific state.
• Insurance License. An official document that allows someone to sell policies in a specific state for a period of time.
• NASD License. A special license from the National Association of Securities Dealers that allows someone to sell variable insurance policies.

Relationships

• A life insurance policy is used as a template for an agreement.
• An agreement is written by an agent.
• An agreement is held by an insured person
• An agent holds one or more insurance licenses.

From the diagram, we can understand that an agent sells an agreement to an insured person. That agreement is based on a life insurance policy. The agent holds at least one license to sell insurance.

Notice the relationship between the agreement class and the life insurance policy class. The life insurance policy is at the top of an inheritance hierarchy. Each other type of insurance policy (term, whole life, etc) is just a specialization of life insurance policy. The diagram depicts that the agreement can be one of any of the different types of insurance policy. And therefore, an agent can sell any of the types, and an insured person can hold an agreement of any of the types of insurance policy.

When reviewing these relationships, you discover that this is an overly simplified representation. You capture the additional information and update your diagram.

More Complex Class Diagram

As part of reviewing the diagram, you discover that variable insurance policies are treated very differently than other insurance policies.

• An agent must have a different type of license (an NASD) license to sell variable insurance. Because of this, the business treats these agents as being special – they are called “Broker / Agents” and are subject to many different internal policies and procedures. Some of those policies represent enforcement of legal regulations, and others are internal policies.
• A broker / agent can sell both variable and fixed (non-variable) insurance policies.
• A variable policy is a combination of a fixed policy and an investment. As such, the business thinks about those customers as investors, and not just insured people. This distinction is really only relevant to sales people and marketing – who will use different approaches to sell to people who want investments.

You update your class diagram to look like the following:

[click for larger diagram]

This diagram is much more complicated.

• We enhanced the hierarchy for insurance licenses to reflect that broker/agents need a different type of license (NASD license) to sell insurance.
• An insured person holds a fixed agreement, where an investor holds a variable agreement.
• An agent can only write a fixed agreement, where a broker/agent can write any type of agreement (fixed or variable).

The diagram is almost too complex to absorb within a UML tutorial. If you were writing these requirements, and did not create a similar diagram, you would be in trouble. In the best case, you would end up with an implementation that met all the requirements, but did not use a good implementation design (due to lack of context). It is more likely that either you would miss some requirements, or your implementation or test team would miss some.

The diagrams that have had the most impact, in our experience, are diagrams that have a similar level of complexity.

Next Up

In the first four 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.

All of the tools you’ve learned so far deal with binary associations – an agent sells a policy, a book club reviews books. In the next article, we will look at relationships that involve more than two classes.

Uncovering Requirements With UML Class Diagrams Part 5: Complex Relationships