Software Design Principles

03 UML Class Diagram

Dr. Mostafa Elgendy
Mostafa.Elgendy@fci.bu.edu.eg
Agenda
▪ Overview.

▪ UML Class Diagram

▪ Relationships

▪ Summary

28-Feb-23 SOFTWARE DESIGN PRINCIPLES 2

 Overview

28-Feb-23 SOFTWARE DESIGN PRINCIPLES 3

Overview
▪ Design: specifying the structure of how a software system will be
written and function, without actually writing the complete
implementation

▪ A transition from "what" the system must do, to "how" the system will
do it
▪ What classes will we need to implement a system that meets our requirements?

▪ What fields and methods will each class have?

▪ How will the classes interact with each other?

28-Feb-23 SOFTWARE DESIGN PRINCIPLES 4

How do we design classes?
▪ Class identification from project spec / requirements
▪ nouns are potential classes, objects, fields

▪ verbs are potential methods or responsibilities of a class

▪ UML diagrams
▪ class diagrams (today)

▪ sequence diagrams

▪ ...

28-Feb-23 SOFTWARE DESIGN PRINCIPLES 5

 UML Class Diagram

28-Feb-23 6
UML class diagrams
▪ What is a UML class diagram?

▪ UML class diagram: a picture of the classes in an OO system, their

fields and methods, and connections between the classes that
interact or inherit from each other.

28-Feb-23 SOFTWARE DESIGN PRINCIPLES 7

Why Do We Need Class Diagrams?
▪ As your system scales and grows, it becomes increasingly
difficult to keep track of all these relationships.

▪ Having a precise, organized, and straight-forward diagram

to do that for you is integral to the success of your system.

28-Feb-23 SOFTWARE DESIGN PRINCIPLES 8

Why Do We Need Class Diagrams?
▪ Making changes to class diagrams is easy, whereas coding
different functionality after the fact is kind of annoying.

▪ When someone wants to build a house, they don’t just grab

a hammer and get to work. They need to have a
blueprint — a design plan — so they can analyze & modify
their system.

28-Feb-23 SOFTWARE DESIGN PRINCIPLES 9

Classes
▪ A class is a description of a set of objects
that share the same attributes, operations,
relationships, and semantics. ClassName

▪ Graphically, a class is rendered as a attributes

rectangle, usually including its name,

operations
attributes, and operations in separate,
designated compartments.

28-Feb-23 SOFTWARE DESIGN PRINCIPLES 10

Class Names
▪ The name of the class is the only required tag
in the graphical representation of a class.

▪ It always appears in the top-most ClassName

compartment. attributes

operations

28-Feb-23 SOFTWARE DESIGN PRINCIPLES 11

Class Attributes
▪ An attribute is a named property of a class
that describes the object being modeled.

▪ In the class diagram, attributes appear in the Person

second compartment just below the name- name : String

address : Address
compartment. birthdate : Date
ssn : Id

28-Feb-23 SOFTWARE DESIGN PRINCIPLES 12

Class Attributes
▪ Attributes are usually listed in the form:
▪ attributeName : Type

▪ A derived attribute is one that can be computed from other

attributes, but doesn’t actually exist.

▪ For example, a Person’s age can be computed from his

birth date.

▪ A derived attribute is designated by a preceding ‘/’ as in:

▪ / age : Date.

28-Feb-23 SOFTWARE DESIGN PRINCIPLES 13

Class Attributes
▪ Attributes can be:

▪ + public

▪ # protected

▪ - private

▪ / derived

28-Feb-23 SOFTWARE DESIGN PRINCIPLES 14

Class Operations
▪ Operations describe the class behavior and
appear in the third compartment Person

name : String
address : Address
birthdate : Date
ssn : Id

eat
sleep
work
play

28-Feb-23 SOFTWARE DESIGN PRINCIPLES 15

Class Operations
▪ You can specify an operation by stating its signature: listing
the name, type, and default value of all parameters, and, in
the case of functions, a return type.

PhoneBook

newEntry (n : Name, a : Address, phone : String=“010100", Description: String): void

getPhone ( n : Name, a : Address) : String

28-Feb-23 SOFTWARE DESIGN PRINCIPLES 16

 Relationships

28-Feb-23 17
Relationships
▪ In UML, object interconnections (logical or physical), are
modeled as relationships.

▪ There are two kinds of relationships in UML:

▪ Generalizations

▪ Associations

28-Feb-23 SOFTWARE DESIGN PRINCIPLES 18

Generalization Relationships
▪ A generalization connects a subclass to its
superclass.

▪ It denotes an inheritance of attributes and

behavior from the superclass to the subclass.

▪ Indicates a specialization in the subclass of

the more general superclass.

28-Feb-23 SOFTWARE DESIGN PRINCIPLES 19

Generalization Relationships
▪ UML permits a class to inherit from multiple superclasses

▪ Although some programming languages (e.g., Java) do not permit

multiple inheritance.

28-Feb-23 SOFTWARE DESIGN PRINCIPLES 20

Generalization example

28-Feb-23 SOFTWARE DESIGN PRINCIPLES 21

Association Relationships
▪ If two classes in a model need to communicate with each
other, there must be link between them.

▪ An association denotes that link.

28-Feb-23 SOFTWARE DESIGN PRINCIPLES 22

Association Relationships
▪ We can indicate the multiplicity of an association by adding
it to the line denoting the association.

▪ The example indicates that a Student has one or more

Instructors:

28-Feb-23 SOFTWARE DESIGN PRINCIPLES 23

Association Relationships
▪ We can also indicate the behavior of an object in an
association (i.e., the role of an object) using role names.

28-Feb-23 SOFTWARE DESIGN PRINCIPLES 24

Association Relationships
▪ We can also name the association.

28-Feb-23 SOFTWARE DESIGN PRINCIPLES 25

Association Relationships
▪ A class can have a self association.

28-Feb-23 SOFTWARE DESIGN PRINCIPLES 26

Aggregations Relationships
▪ We can model objects that contain other objects by way of special associations
▪ Aggregations and compositions.

▪ An aggregation specifies a whole-part relationship between an aggregate (a whole)

and a constituent part, where the part can exist independently from the aggregate.

▪ Aggregations are denoted by a hollow-diamond adornment on the association.

28-Feb-23 SOFTWARE DESIGN PRINCIPLES 27

Composition Relationships
▪ A composition indicates a strong ownership and coincident
lifetime of parts by the whole

▪ Compositions are denoted by a filled-diamond adornment

on the association.

28-Feb-23 SOFTWARE DESIGN PRINCIPLES 28

Interfaces
▪ An interface is a named set of operations that specifies the
behavior of objects without showing their inner structure. It
can be rendered in the model by a one- or two-compartment
rectangle, with the stereotype <<interface>> above the
interface name.
<<interface>>
ControlPanel

28-Feb-23 SOFTWARE DESIGN PRINCIPLES 29

Interface Services
▪ Interfaces do not get instantiated. They have no attributes or
state. Rather, they specify the services offered by a related
class.

28-Feb-23 SOFTWARE DESIGN PRINCIPLES 30

Interface Realization Relationship
▪ A realization relationship connects a
class with an interface that supplies its
behavioral specification.

▪ It is rendered by a dashed line with a

hollow triangle towards the specifier.

28-Feb-23 SOFTWARE DESIGN PRINCIPLES 31

Packages
▪ A package is a container-like element for organizing other
elements into groups.

▪ A package can contain classes and other packages and

diagrams.

▪ Packages can be used to provide controlled access between

classes in different packages.

Compiler

28-Feb-23 SOFTWARE DESIGN PRINCIPLES 32

Packages
▪ Classes in the FrontEnd package and classes in the
BackEnd package cannot access each other in this
diagram.

28-Feb-23 SOFTWARE DESIGN PRINCIPLES 33

Packages
▪ Classes in the BackEnd package now have access to the
classes in the FrontEnd package.

28-Feb-23 SOFTWARE DESIGN PRINCIPLES 34

Example 1

28-Feb-23 SOFTWARE DESIGN PRINCIPLES 35

Summary
▪ Overview.

▪ UML Class Diagram

▪ Relationships

28-Feb-23 SOFTWARE DESIGN PRINCIPLES 36

 Questions

28-Feb-23 SOFTWARE DESIGN PRINCIPLES 37