Class Diagram

 Class diagrams are a type of UML (Unified Modeling

Language) diagram used in software engineering to visually
represent the structure and relationships of classes in a system.
 UML is a standardized modeling language that helps in
designing and documenting software systems.
 Class diagrams are a type of UML (Unified Modeling
Language) diagram used in software engineering to visually
represent the structure and relationships of classes within a
system i.e. used to construct and visualize object-oriented
systems.
 They are an integral part of the software development process,
What are class Diagrams?
 Class diagrams are a type of UML
(Unified Modeling Language)
diagram used in software engineering
to visually represent the structure and
relationships of classes within a
system i.e. used to construct and
visualize object-oriented systems.
 In these diagrams, classes are
depicted as boxes, each containing
three compartments for the class
name, attributes, and methods. Lines
connecting classes illustrate
associations, showing relationships
What is a class?

 In object-oriented programming (OOP), a class is a blueprint

or template for creating objects. Objects are instances of
classes, and each class defines a set of attributes (data
members) and methods (functions or procedures) that the
objects created from that class will possess.
 The attributes represent the characteristics or properties of
the object, while the methods define the behaviors or actions
that the object can perform.
UML Class Notation
 Class notation is a graphical representation used
to depict classes and their relationships in
object-oriented modeling.
1. Class Name: The name of the class is typically
written in the top compartment of the class box
and is centered and bold.
2. Attributes: Attributes, also known as properties
or fields, represent the data members of the
class.
3. Methods: Methods, also known as functions or
operations, represent the behavior or
functionality of the class.
4. Visibility Notation: Visibility notations indicate
the access level of attributes and methods
Relationships between classes
Association

 An association represents a bi-

directional relationship between two
classes. It indicates that instances of
one class are connected to instances
of another class.
 The “Library” class can be
considered the source class because
it contains a reference to multiple
instances of the “Book” class. The
“Book” class would be considered
the target class because it belongs to
a specific library.
Directed Association

 A directed association in a UML

class diagram represents a
relationship between two classes
where the association has a direction,
indicating that one class is associated
with another in a specific way.
 The source class is the “Teacher”
class. The “Teacher” class initiates
the association by teaching a specific
course.
 The target class is the “Course”
class. The “Course” class is affected
by the association as it is being
taught by a specific teacher.
Aggregation

 Aggregation is a specialized form

of association that represents a
“whole-part” relationship. It
denotes a stronger relationship
where one class (the whole)
contains or is composed of
another class (the part).
 Aggregation is represented by a
diamond shape on the side of the
whole class. In this kind of
relationship, the child class can
exist independently of its parent
class.
Composition

 Composition is a stronger
form of aggregation,
indicating a more significant
ownership or dependency
relationship.
 In composition, the part class
cannot exist independently
of the whole class.
 Composition is represented
by a filled diamond shape on
the side of the whole class.
Generalization(Inheritance)

 Inheritance represents an “is-a”

relationship between classes, where
one class (the subclass or child)
inherits the properties and behaviors of
another class (the superclass or
parent). Inheritance is depicted by a
solid line with a closed, hollow
arrowhead pointing from the subclass
to the superclass.
 The Bank Account class serves as the
generalized representation of all types
of bank accounts, while the subclasses
(Current Account, Savings Account,
Credit Account) represent specialized
versions that inherit and extend the
functionality of the base class.
Realization (Interface Implementation)

 Realization indicates that a class

implements the features of an
interface. It is often used in cases
where a class realizes the operations
defined by an interface.
 Let’s consider the scenario where a
“Person” and a “Corporation” both
realizing an “Owner” interface.
 Both person and Corporation class
also implements the Owner interface,
offering specific implementations for
the “acquire(property)” and
“dispose(property)” methods.
Dependency Relationship

 A dependency exists between

two classes when one class
relies on another, but the
relationship is not as strong as
association or inheritance.
 Let’s consider a scenario
where a Person depends on a
Book.
Usage(Dependency) Relationship

 A usage dependency
relationship in a UML class
diagram indicates that one class
(the client) utilizes or depends
on another class (the supplier)
to perform certain tasks or
access certain functionality.
 The client class relies on the
services provided by the
supplier class but does not own
or create instances of it.
How to draw Class Diagrams

 Identify Classes
 List Attributes and Methods
 Identify Relationships
 Create Class Boxes
 Add Attributes and Methods
 Draw Relationships
 Label Relationships
 Review and Refine
 Use Tools for Digital Drawing
Use cases of Class Diagrams

 System Design
 Communication and Collaboration
 Code Generation
 Testing and Test Planning
 Reverse Engineering
Object Diagrams

 Object diagrams are a visual representation in UML (Unified

Modeling Language) that illustrates the instances of classes and
their relationships within a system at a specific point in time.
 They display objects, their attributes, and the links between
them, providing a snapshot of the system’s structure during
execution.
 Since object diagrams depict behavior when objects have been
instantiated, we can study the behavior of the system at a
particular instant.
What is an Object?

 An object refers to a specific instance of a class within

a system.
 A class is a blueprint or template that defines the
common attributes and behaviors shared by a group of
objects.
 An object, on the other hand, is a concrete and
individual occurrence of that class, possessing unique
values for its attributes.
What is a Classifier?

 In UML a classifier refers to a group of elements that

have some common features like methods, attributes
and operations.
 A classifier can be thought of as an abstract metaclass
which draws a boundary for a group of instances
having common static and dynamic features.
Object Diagram Notations
 How to draw an Object Diagram?
1.Identify Classes
2.Identify Objects
3.Create Object Boxes
4.Add Attributes and Values
5.Draw Relationships
6.Label Relationships
7.Review and Refine
8.Use Tools for Digital Drawing
 CLASS DIAGRAMS: TERMS AND
CONCEPTS
 A class diagram is a diagram that shows a set of classes, interfaces, and collaborations
and their relationships. Graphically, a class diagram is a collection of vertices and arcs.
 Common Properties: A class diagram is just a special kind of diagram and shares the
same common properties as do all other diagrams name and graphical content that are
a projection into a model. What distinguishes a class diagram from other kinds of
diagrams is its particular content.
 Contents:
 Class diagrams commonly contain the following things:
 • Classes
 • Interfaces
 • Collaborations
 • Dependency, generalization, and association relationships. Like all other diagrams,
COMMON MODELING TECHNIQUES

 Modeling Simple Collaborations

 Modeling a Logical Database Schema
 Forward and Reverse Engineering
 Modeling Simple Collaborations
 To model a collaboration,
 Identify the mechanism you'd like to model. A mechanism represents some function or
behavior of the part of the system you are modeling that results from the interaction of a
society of classes, interfaces, and other things.
 For each mechanism, identify the classes, interfaces, and other collaborations that
participate in this collaboration. Identify the relationships among these things as well.
 Use scenarios to walk through these things. Along the way, you'll discover parts of your
model that were missing and parts that were just plain semantically wrong.
 Be sure to populate these elements with their contents. For classes, start with getting a
good balance of responsibilities. Then, over time, turn these in to concrete attributes and
operations.
 Modeling a Logical Database Schema
 Modeling a Logical Database Schema To model a schema,
 Identify those classes in your model whose state must transcend the lifetime of their applications.
 Create a class diagram that contains these classes. You can define your own set of stereotypes and
tagged values to address database-specific details.
 Expand the structural details of these classes. In general, this means specifying the details of their
attributes and focusing on the associations and their multiplicities that relate these classes.
 Watch for common patterns that complicate physical database design, such as cyclic associations and
one-to-one associations. Where necessary, create intermediate abstractions to simplify your logical
structure.
 Consider also the behavior of these classes by expanding operations that are important for data access
and data integrity. In general, to provide a better separation of concerns, business rules concerned
with the manipulation of sets of these objects should be encapsulated in a layer above these persistent
classes.
 Where possible, use tools to help you transform your logical design into a physical design.
Forward and Reverse Engineering
 To forward engineer a class diagram,
 Identify the rules for mapping to your implementation language or languages
of choice. This is something you'll want to do for your project or your
organization as a whole.
 Depending on the semantics of the languages you choose, you may want to
constrain your use of certain UML features. For example, the UML permits
you to model multiple inheritance, but Smalltalk permits only single
inheritance. You can choose to prohibit developers from modeling with
multiple inheritance (which makes your models language-dependent), or you
can develop idioms that transform these richer features into the
implementation language (which makes the mapping more complex).
 Use tagged values to guide implementation choices in your target language.
You can do this at the level of individual classes if you need precise control.
You can also do so at a higher level, such as with collaborations or packages.
Cont.
 To reverse engineer a class diagram,
 Identify the rules for mapping from your implementation language or languages
of choice. This is something you'll want to do for your project or your
organization as a whole.
 Using a tool, point to the code you'd like to reverse engineer. Use your tool to
generate a new model or modify an existing one that was previously forward
engineered. It is unreasonable to expect to reverse engineer a single concise
model from a large body of code. You need to select portion of the code and
build the model from the bottom.
 Using your tool, create a class diagram by querying the model. For example,
you might start with one or more classes, then expand the diagram by following
specific relationships or other neighboring classes. Expose or hide details of the
contents of this class diagram as necessary to communicate your intent.
 Manually add design information to the model to express the intent of the
 OBJECT DIAGRAMS: TERMS AND
CONCEPTS
 Object diagrams model the instances of things contained in class diagrams. An object diagram shows a
set of objects and their relationships at a point in time.
 TERMS AND CONCEPTS
 An object diagram is a diagram that shows a set of objects and their relationships at a point in time.
Graphically, an object diagram is a collection of vertices and arcs.
 Common Properties
 An object diagram is a special kind of diagram and shares the same common properties as all other
diagrams that is, a name and graphical contents that are a projection into a model. What distinguishes
an object diagram from all other kinds of diagrams is its particular content.
 Contents
 Object diagrams commonly contain
 •Objects
 •Links
COMMON MODELING TECHNIQUES

 MODELING OBJECT STRUCTURES

 FORWARD AND REVERSE ENGINEERING
MODELING OBJECT STRUCTURES
 To model an object structure,
 Identify the mechanism you'd like to model. A mechanism represents some
function or behavior of the part of the system you are modeling that results
from the interaction of a society of classes, interfaces, and other things.
 Create a collaboration to describe a mechanism.
 For each mechanism, identify the classes, interfaces, and other elements that
participate in this collaboration; identify the relationships among these things
as well.
 Consider one scenario that walks through this mechanism. Freeze that
scenario at a moment in time, and render each object that participates in the
mechanism.
 Expose the state and attribute values of each such object, as necessary, to
understand the scenario. •Similarly, expose the links among these objects,
 FORWARD AND REVERSE ENGINEERING

 Forward engineering ( the creation of code from a model) an object

diagram is theoretically possible but pragmatically of limited value. In an
object-oriented system, instances are things that are created and destroyed
by the application during run time. Therefore, you cannot exactly
instantiate these objects from the outside.
 Reverse engineering (the creation of a model from code) an object diagram
can be useful. In fact, while you are debugging your system, this is
something that you or your tools will do all the time. For example, if you
are chasing down a dangling link, you'll want to literally or mentally draw
an object diagram of the affected objects to see where, at a given moment
 Cont.

 To reverse engineer an object diagram,

 Chose the target you want to reverse engineer. Typically, you'll set your
context inside an operation or relative to an instance of one particular class.
 Using a tool or simply walking through a scenario, stop execution at a certain
moment in time.
 Identify the set of interesting objects that collaborate in that context and render
them in an object diagram.
 As necessary to understand their semantics, expose these object's states.
 As necessary to understand their semantics, identify the links that exist among
these objects.
Collaboration Diagram

 A collaboration diagram, also known as a communication

diagram, is an illustration of the relationships and interactions
among software objects in the Unified Modeling Language (
UML). Developers can use these diagrams to portray the
dynamic behavior of a particular use case and define the role
of each object.
 To create a collaboration diagram, first identify the structural
elements required to carry out the functionality of an
interaction. Then build a model using the relationships
between those elements. Several vendors offer software for
 Notations of a collaboration diagram
 A collaboration diagram resembles a flowchart that portrays the roles,
functionality and behavior of individual objects as well as the overall operation of
the system in real time. The four major components of a collaboration diagram
include the following:
1. Objects. These are shown as rectangles with naming labels inside. The naming
label follows the convention of object name: class name. If an object has a
property or state that specifically influences the collaboration, this should also be
noted.
2. Actors. These are instances that invoke the interaction in the diagram. Each actor
has a name and a role, with one actor initiating the entire use case.
3. Links. These connect objects with actors and are depicted using a solid line
between two elements. Each link is an instance where messages can be sent.
4. Messages between objects. These are shown as a labeled arrow placed near a
link. These messages are communications between objects that convey
information about the activity and can include the sequence number.
 Steps for creating a Collaboration Diagram

1. Determine the behavior for which the realization and implementation are
specified.
2. Discover the structural elements that are class roles, objects, and
subsystems for performing the functionality of collaboration.
1. Choose the context of an interaction: system, subsystem, use case, and operation.
3. Think through alternative situations that may be involved.
1. Implementation of a collaboration diagram at an instance level, if needed.
2. A specification level diagram may be made in the instance level sequence diagram
for summarizing alternative situations.
Components of a collaboration Diagram
Example of a Collaboration Diagram
Represent this polymorphic behavior using a
Collaboration diagrams
In a collaboration diagram, polymorphic behavior can be represented using
a combination of messages and actors. Let's consider an example where we
have a Shape base class and two subclasses, Circle and Rectangle. Both
subclasses implement a draw() method, but each subclass implements it
differently.
Here's how you can represent this polymorphic behavior in a collaboration
diagram:
Actor: The actor in this scenario could be a DrawingApp that interacts with
different shapes.
Messages: The messages represent the interactions between the
DrawingApp and the shapes.
In this diagram, DrawingApp sends a drawShape(shape) message to a
Shape object. The Shape object could be either a Circle or a Rectangle.
Depending on the type of the Shape object, the appropriate draw() method of
the specific subclass (Circle or Rectangle) is executed, demonstrating
polymorphic behavior.
Iterating and Conditional Messages

 Collaboration diagrams use syntax similar to sequence diagrams to indicate

that either a message iterates (is run multiple times) or is run conditionally.
 You can indicate that a particular message iterates by prefixing a message
sequence number with an iteration expression. You can simply use an asterisk
(*) to indicate that a message runs more than once, or you can get more
specific and show the number of times a message is repeated.
 To indicate that a message is run conditionally, you can prefix the message
sequence number with a conditional clause such as [ x = true ]. This indicates
that the message is sent only if the condition is met. The UML leaves the
syntax of conditional clauses wide open, so you can create expressions that
make sense in the context of your application.