UML (Unified Modeling

Language)
 What is a Domain Model?

• Illustrates meaningful conceptual classes in

problem domain
• Represents real-world concepts,
not software components
• Software-oriented class diagrams will
be developed later, during design
A Domain Model is
Conceptual,
not a Software Artifact
Conceptual Class: Software Artifacts:

Sale SalesDatabase

amt
vs. Sale
item
Double amt;
Item item;
void print()
What’s the
Identify conceptual classes
from noun phrases
• Vision and Scope, Glossary and Use Cases
are good for this type of linguistic analysis
However:
• Words may be ambiguous or synonymous
• Noun phrases may also be attributes or
parameters rather than classes:
– If it stores state information or it has multiple behaviors,
then it’s a class
– If it’s just a number or a string, then it’s probably
an attribute
 From NPs (Noun Phrase) to classes or attributes
Consider the following problem description, analyzed for Subjects, Verbs, Objects:
The ATM verifies whether the customer's card number and PIN are correct.
SC V RO O A OA
If it is, then the customer can check the account balance, deposit cash, and withdraw cash.
SR V OA V O A V OA
Checking the balance simply displays the account balance.
SM OA V OA
Depositing asks the customer to enter the amount, then updates the account balance.
SM V OR V OA V OA
Withdraw cash asks the customer for the amount to withdraw; if the account has enough cash,
SM OA V OR OA V SC V OA
the account balance is updated. The ATM prints the customer’s account balance on a receipt.
OA V SC V OA O
Analyze each subject and object as follows:
Does it represent a person performing an action? Then it’s an actor, ‘R’.
Is it also a verb (such as ‘deposit’)? Then it may be a method, ‘M’.
Is it a simple value, such as ‘color’ (string) or ‘money’ (number)?
Then it is probably an attribute, ‘A’.
Which NPs are unmarked? Make it ‘C’ for class.
Steps to create a
Domain Model

• Identify candidate conceptual classes

• Draw them in a UML domain model
• Add associations necessary to record
the relationships that must be retained
• Add attributes necessary for information to be
preserved
• Use existing names for things,
the vocabulary of the domain
Monopoly Game domain model
(first identify concepts as classes)

Monopoly Game Die Board

Player Piece Square

7
Monopoly Game domain model
Larman, Figure 9.28
 Class Diagrams
• A Class diagram shows the static structure of the system.

• It defines model elements such as classes, interfaces, and user-

defined data types, their internal structure, and their
relationships to each other.

• Relationships, or associations, are shown as lines connecting

elements, and are annotated to describe the relationships and
their cardinality (1..1, 1..*, 0..*, etc.).

9
 Class Diagrams
• Inheritance (generalize/specialize), aggregation
(comprises), and composition (has) relationships are also
captured in this diagram.

• Class attributes and their data types are identified here, as

are the operations and their return types.

• Visibility is indicated by +, #, or - for public, protected, or

private.

10
 Class Diagrams
• The class diagram plays a vital role in the transition from
design to construction as it contains sufficient detail to
begin the coding process.

• It is often used to partition responsibilities among the

project team members, and to guide and measure the
construction process.

11
 Class diagrams
A class diagram helps you visualize the structural or static
view of a system and is one of the most common diagram
types.

– Class diagrams show the relationships among and

details about each class.

– Class diagrams are also the foundation for component

and deployment diagrams.

12
Class diagrams
– There are typically many class diagrams in a single
model.

– It shows how a system is structured rather than how it

behaves.

13
 A very simple class model
• In UML, a class is shown in a class diagram as a rectangle
giving its name

14
 What makes a class model good?
• Ultimately, we have two objectives which we aim to meet:

– Build, as quickly and cheaply as possible, a system

which satisfies our current requirements;

– Build a system which will be easy to maintain and

adapt to future requirements.

15
In order to meet the objectives:
• Every piece of behaviour which is required of the system
must be able to be provided, in a sensible way, by objects
of the classes we choose

• A good class model consists of classes which represent

enduring classes domain objects, which don’t depend on

the particular functionality required today.

16
Attributes and operations
• Most important are the operations of a class,
which define the ways in which objects may
interact.
• The attributes of a class describe the data
contained in an object of the class

17
UML Class properties:
• Association
• Multiplicity
• Generalization
• Aggregation and composition
• Qualified associations
• Qualified composition
• Derived associations
• Navigability
• Constraints
• Association classes
• Qualifier

18
Associations
• In the same sense that classes correspond to nouns,
associations correspond to verbs.

• They express the relationship between classes.

• There are instances of associations, just as there are

instances of classes

• Instances of a classes are called objects;

• Instances of associations are called links in UML

19
Class A and B are associated if
• an object of class A sends a message to an object of class B

• an object of class A creates an object of class B

• an object of class A has an attribute whose values are objects

of class B or collections of objects of class B

• an object of class A receives a message with an object of class

B as argument

in short, if some object of class A has to know about some

object of class B

20
Simple association between classes

• One annotation which is often used early is the multiplicity

of an association

• This is so fundamental that we will spend some time time

thinking about it.

21
Example

1..* 1

• Every copy is associated by is a copy of with just one book.

We showed a 1 at the Book end of the association.

• On the other hand, there may be any number of copies of a

given book in our system. So the multiplicity on the Copy
end is 1..* .
22
Multiplicity
We can specify:

• an exact number simply by writing it

• a range of numbers using two dots between a pair of

numbers

• an arbitrary, unspecified number using *

• Loosely, you can think of UML’s * as an infinity sign, so

the multiplicity 1 .. * expresses that number of copies can
be anything between 1 and infinity.

23
Multiplicity
• Association with two objects could be for more than one
class the measure of this is called multiplicity. It describe
in range as below:

• Lower Bound….Bound

• 0..1 Single Value

• 0.. * single value lower bound and upper bound unlimited

denoted by *.

• 1..3 Lowest 1 Highest 3

24
 Generalization
• Important relationship which may exist between classes is
generalization

• A generalization is used to indicate inheritance.

• Drawn from the specific classifier to a general classifier, the

generalize implication is that the source inherits the target's

characteristics.

25
Example:

26
Example :
• The following diagram shows a parent class generalizing a
child class. Implicitly, an instantiated object of the Circle
class will have attributes x_position, y_position and radius
and a method display(). Note that the class "Shape" is
abstract, shown by the name being italicized.

27
CRC cards
• One common way of checking for a good design and
guiding its refinement is to use CRC cards.

• CRC stands for Classes, Responsibilities, Collaborations.

• Although CRC is not part of UML, they add some very

useful insights throughout a development.

28
 Creating CRC card
• The name of a class, at the top
• The responsibilities of the class, on the left-hand side
• The collaborators of the class, which help to carry out each
responsibility, on the right-hand side of the card.

The responsibilities of the class describe at a high level the

purpose of the class’s existence :
– They are connected with the operations the class
provides, but are more general than that might imply

29
 Aggregation and composition
• Aggregation and composition are kinds of association:
– Instead of just showing that two classes are associated we may
choose to show more about what kind of association this is

• Aggregation and composition are both ways of recording

that an object of one class

is part of

an object of another class.

30
Module is a part of an Honours Course

• The notation with open diamond, denotes aggregation,

which is more general way of denoting a part-whole
relationship in UML

31
Composition
• Composition is a special kind of aggregation which does
impose some further restrictions.
• A stronger form of aggregation - a composite aggregation -
is shown by a black diamond-shaped arrowhead
• In composition association, the whole strongly owns its
parts
– If the whole object is copied or deleted, its parts are
copied or deleted with it
• The multiplicity at the whole end of a composition
association must be 1 or 0..1
– A part cannot be part of more than one whole by
composition
32
Example
Noughts and Crosses
(Tic-Tac-Toe)

• Composition is shown just as aggregation is, except that

diamond is filled in

33
Example:
• The following diagram illustrates the difference between weak and
strong aggregations.
• An address book is made up of a multiplicity of contacts and contact
groups. A contact group is a virtual grouping of contacts; a contact
may be included in more than one contact group. If you delete an
address book, all the contacts and contact groups will be deleted too; if
you delete a contact group, no contacts will be deleted.

34
Roles
• Often you can read an association name in both directions
(‘is taking’,’is taken by’)
• Message having a task role to play binary association is
shown by thick line and role by thick trainable. The
direction of triangle indicates how to read the association.
• Sometimes, however, it is more readable to have separate
names for the roles that the objects play in the association.

35
 Association with no navigability

• The diagram records that:

– For each object of class Student there are six objects of
class Module which are associated with the Student;
– For each object of class Module there are some Student
objects (the number of students is unspecified) associated
with the Module.

36
Navigability
• We can put an arrow on one or both ends of the association
line to represent that it is possible for messages to be sent
in the direction of the arrow

• We say that Module knows about Student, but not vice

versa.

37
Example:

38
 CASE STUDY
• A product is to be installed to control elevators in a
building with m floors. The problem concerns the logic
required to move elevators between floors according to
the following constraints:
– Each elevator has a set of m buttons, one for each floor. These
illuminate when pressed and cause the elevator to visit the
corresponding floor. The illumination is canceled when the elevator
visits the corresponding floor.
– Each floor, except the first floor and top floor has two buttons, one
to request and up-elevator and one to request a down-elevator.
These buttons illuminate when pressed. The illumination is
canceled when an elevator visits the floor and then moves in the
desired direction.
– When an elevator has no requests, it remains at its current floor
with its doors closed.
• Identify classes and design class diagram of the above
scenario.
39
40
Case Study
• Paragraphs Corporation sells books and CDs using
through online shopping. The customer adds items to her
shopping cart. She may remove items or go to the check-out to
make her purchases at any time. The customer reviews her
purchases, chooses a payment method and pays. A sales
employee at Paragraphs Corporation gets the order and
purchase confirmation from the system, and sends the
electronic order to the warehouse. The warehouse employee
updates the order status. The customer may check the order
status.
• Identify classes and associations between classes.
• Design class diagram for the above case study.

41