CLASS DIAGRAM

g
Static structural modellin
CLASS
• A Class is a blueprint for an object
• classes describe the type of objects, while objects are
usable instances of classes
• A class represent a concept which encapsulates state
(attributes) and behavior (operations). Each attribute
has a type. Each operation has a signature.
CLASS VISIBILITY
• The +, - and # symbols before an attribute and operation name in a class denote the visibility of the attribute
and operation.
• + denotes public attributes or operations
• - denotes private attributes or operations
• # denotes protected attributes or operations
PERSPECTIVES OF CLASS DIAGRAM
• Conceptual: represents the concepts in the domain
• Specification: focus is on the interfaces of Abstract Data Type (ADTs) in the software
• Implementation: describes how classes will implement their interfaces
RELATIONSHIPS BETWEEN CLASSES
Inheritance (or Generalization):
•Represents an "is-a" relationship.
•An abstract class name is shown in italics.
•SubClass1 and SubClass2 are specializations of SuperClass.

Inheritance Example - Shapes

RELATIONSHIPS BETWEEN CLASSES
Association
•A structural link between two peer classes.
•There is an association between Class1 and Class2

Cardinality
RELATIONSHIPS BETWEEN CLASSES
Aggregation
•A special type of association.
•It represents a "part of" relationship.
•Class2 is part of Class1.
•Many instances (denoted by the *) of Class2 can be
associated with Class1.
•Objects of Class1 and Class2 have separate lifetimes.
RELATIONSHIPS BETWEEN CLASSES
Composition
•A special type of aggregation where parts are destroyed when
the whole is destroyed.
•Objects of Class2 live and die with Class1.
•Class2 cannot stand by itself.
RELATIONSHIPS BETWEEN CLASSES
Dependency
•An object of one class might use an object of another class in
the code of a method. If the object is not stored in any field,
then this is modeled as a dependency relationship.
• A special type of association.
• Exists between two classes if changes to the definition of
one may cause changes to the other (but not the other
way around).
• Class1 depends on Class2
RELATIONSHIPS BETWEEN CLASSES
Realization
• Realization is a relationship between the blueprint class and
the object containing its respective implementation level
details.
• the relationship between the interface and the implementing
class.
SIMPLE UML CLASS DIAGRAM EXAMPLE

• School has one or more Departments. Department offers one or more Subjects. A particular subject will be offered by only one
department. Department has instructors and instructors can work for one or more departments. Student can enroll in up to 5 subjects in a
School. Instructors can teach up to 3 subjects. The same subject can be taught by different instructors. Students can be enrolled in more
than one school.
ASSOCIATION CLASS & SELF ASSOCIATION
• Association class
• Some people have several jobs, but with different employers. For
example, at night John is a security guard at Pub 911, where he
earns $9/hr and his boss is the club's bar tender. In the day he is a
programmer for MicroHard, where he earns $20/hr and his boss is a
MicroHard project manager. Where can we store John's salary and
boss information?
• To solve this problem we can use the Job association class.
• Now John's security guard job and programmer job are association
objects: instances of a Job class. Each instance encapsulates a salary,
an employer link, and an employee link. We can represent the Boss
relationship as a Job self-association.

• Self Association =>

CONSTRAINTS
CLASS DIAGRAM EXAMPLE: FILE OUTPUT

• there is a number of output devices on which the display command should be able to write. This
includes a display monitor and a printer.
• Customers may have many
reservations, but each reservation is
TICKET SELLING SYSTEM
made by one customer.

• Reservations are of two

kinds: subscription
series and individual reservations.
• Both reserve tickets: in one case,
only one ticket; in the other case,
several tickets. Every ticket is part
of a subscription series or an
individual reservation, but not both.
• Every performance has many
tickets available, each with a unique
seat number. A performance can be
identified by a show, date, and time.
A CAR

• A car consists of different structural components, such as the engine, body, suspension, gearbox, etc. Each component in turn
contains its own attributes and operations. For example, the engine has its capacity, and it can be started or stopped. We can
represent the car with a class diagram. The class diagram example shows a simplified structural model of a car in a class diagram.
CLASS DIAGRAM EXAMPLE: GUI
CLASS DIAGRAM EXAMPLE: SALES ORDER SYSTEM
• Drawing Class diagram models a customer order
from a retail catalog.
• The central class is the Order. Associated with it
are the Customer making the purchase and
the Payment.
• A Payment is one of four kinds:
Cash, Check, Credit or Wire Transfer. Payment
is a superclass of Cash, Check, and Credit.
• The order contains OrderDetails (line items), each
with its associated Item.
CLASS DIAGRAM EXAMPLE: ORDER SYSTEM
EXERCISE
• Imagine that you are tasked with developing a system for a pizza shop. Given the following description, create
a class diagram (in the form of a UML class diagram). Include all conceptual classes, attributes, associations,
and generalization relationships mentioned in the descriptions. Label all associations and include all
multiplicities. A customer places orders. A customer has a name and phone number. There are two types of
orders: pick-up and delivery. A pick-up order has a pick-up time. A delivery order has an address and deliver-by
time. All orders consist of a set of items. There are two types of items: pizzas and drinks. All items have a price.
A pizza has a size and a crust type. A pizza also has a number of toppings. A topping has a topping type and a
price. Some pizzas are special pizzas that have a name (e.g., “Hawaiian” or “Meat Lovers”). A drink has a
brand and a flavor
EXERCISE
EXERCISE