• 20 hours
  • Medium

Free online content available in this course.

course.header.alt.is_video

course.header.alt.is_certifying

Got it!

Last updated on 11/25/19

Describe a society with domain diagrams

Log in or subscribe for free to enjoy all this course has to offer!

A domain diagram shows how a group of classes work together.

In this chapter we are going to cover the details about how classes relate to each other and form a cohesive society. We will cover both database theory and the UML drawing style.

First of all, when organizing a domain diagram, you have to understand how the parts (the classes) form a cohesive system.

In order to do that, you may ask questions like:

Which class is the boss? Who do they control? Who works only with 1 partner and why doesn't that partner just move in with them? Who works collectively and who else do they work with?

Are these questions about a group of friends or a colony of penguins or a system to keep track of the production, provisioning, distribution, and sales of a commercial bakery?

It's amazing that these questions work for all these systems, for all these domains.

You will need to answer these questions to design a relational database.

The answers will reveal who has status, who has power, who is dependent, and who has a collective spirit.

The answers will show which parts are more important and how the parts work together!

Describing these relationships

UML provides a shorthand for describing these relationships as well as methods for describing the constraints on these relationships.

A relational database is a system that has relations between its parts. Its parts being its tables.

Here are two classes, class  A  and class  B , each with some attributes.

Two tables
Two tables

In a UML Domain Diagram, to show an association between two classes, you draw a line between them.

Two classes in a relationship
Two classes in a relationship

This association between the classes can be named with a word on or under the line. Usually this word is a verb.

Two tables in a named association.
Two tables in a named association

This example could be part of a database for a condominium association to keep track of its residents and their pooches.

This diagram says that there are objects in theApartment class and objects in theDog class that are associated with each other through theHouses association.

Multiplicity of associations

The multiplicity of association is a mouthful! Instead of multiplicity of association, you could say the cardinality of the relationship, but it's also a mouthful and it sounds a bit scarier. You could also ask who is the boss? Who and how many objects do they get to boss around?

In UML, you can set the rules for how many objects of one class can be related to objects of another class.

In the example above of the classes apartment and dog, we can set the rules for how many dogs an apartment can house and how many apartments a dog can live in.

Below is an abstract example that shows that each object of class  A  is related to at least x and at most y elements of class  B .

The objects of class A are related to at least x and at most y elements of class B.
The rules for multiplicity of class A's relationship to class B appear next to class B.

It's a little confusing that the rules for class  A  are next to class  B . The rules live there because they dictate what happens on the receiving end of this relationship. 

In the following diagram, the rules are set on both sides of the relationship.

An object of class A must be related to at least x and at most y objects of class B and objects of class B must be related to at least m and at most n objects of class A.
An object of class A must be related to at least x and at most y objects of class B and objects of class B must be related to at least m and at most n objects of class A.

Let's leave this abstract world and develop the design for a condominium association'sApartments  and Dogs database. 

This condominium's by-laws state:

  • An apartment can have at most 4 dogs but doesn't need to have a dog.

  • No stray dogs are allowed (no dogs can be here without an owner). 

This UML diagram looks like this:

Each Neighbor must have between 0-4 Dogs. Each Dog must have 1 Owner.
Each apartment can have between 0-4 dogs. Each dog must have 1 owner.

This is an example of a one-to-many relationship. More on that in a coming chapter.

Here's the same diagram in black and white:

Even though the 0..4 is next to the Dog class, it refers to how many dogs an apartment can house.
The 0..4 is next to the Dog class, so it refers to how many dogs an apartment can house.

Lets change the rules!

If the condo by-laws state that:

  • everyone in the condo must own at least 1 dog

  • there are no limits to how many dogs a neighbor can have

  • stray dogs are allowed to live in the building and don't have to be housed in an apartment

  • when dogs are housed in an apartment then can only stay in 1

The diagram would look like this:

Note the ✱ (astrisk) means any number greater than zero.
Note the ✱ (astrisk) means any number greater than zero.

If the condo by-laws stated that:

  •  Every apartment must have 1 dog and no more.

  • Every dog must have 1 and only 1 apartment that it lives in.

The diagram would look like this:

A dog for every neighbor and a neighbor for every dog.
A dog for every apartment and an apartment for every dog.

If the condo by-laws stated that:

  • dogs can be shared between neighbors

  • stray dogs are not allowed

  • every dog can have up to 3 owners

  • apartment owners can care for up to 8 dogs

  • but they don't have to care for a dog at all

The diagram would look like this:

The diagram shows the extent of the communal care for a dog and the limits of responsibility ( or doggy love) a neighbor is allowed to have.
The diagram shows the extent of the communal care for a dog and the limits of responsibility (or puppy love) the community is allowed to have.

Or if the condo by-laws state that:

  • every dog has one owner

  • there are no restrictions on the number of dogs a person can have

The diagram would look like this:

Dogs must be accounted for. Anything goes for Neighbors.
Dogs must be accounted for. Anything goes for Neighbors.

UML Multiplicity Abbreviations

The default relationship

The default relationship - One to One on both sides
The default relationship - One to One on both sides

If no multiplicity is indicated on the association line connecting two tables, then it is assumed to be the default relationship. The default is a 1..1 relationship on both sides.

Abbreviations

1..1 can be shortened to 1

0..✱ can be shortened to ✱

So the last diagram could be updated to this:

The multiplicity specified with abbreviations.
The multiplicity specified with abbreviations.

In this chapter we've covered the types of associations between the tables:

  • one-to-one

  • one-to-many

  • many-to-many

We've also covered the UML drawing conventions for associating classes.

Next up, we are going to make sure that each object of a class has a unique identifier.

What does that mean? You'll find out!

Example of certificate of achievement
Example of certificate of achievement