2

Presented By:
7796 Sheeza Khalil Ahmed
7797 Sheeza Naseer
7798 Sidra tul Muntaha
7799 Sonia Rashid
7800 Sundas Asif
7801 Tanzeela Allah Ditta
7802 Tanzeela Hussain
7803 Ujala Saeed
7804 Wajeeha Abbas
7805 Warda Abdul Wahab
 Is a static diagram.
 It represents the static view of an application.
 The class diagrams are widely used in the modelling of object oriented
systems because they are the only UML diagrams which can be mapped
directly with object oriented languages.
 The class diagram shows a collection of classes, interfaces, associations,
collaborations and constraints.
 It is also known as a structural diagram.

4
 The class diagram is used to refine the use case diagram and define a detailed design
of the system.
 The class diagram classifies the actors defined in the use case diagram into a set of
interrelated classes.
 The relationship or association between the classes can be either an "is-a" or "has-a"
relationship.
 Each class in the class diagram may be capable of providing certain functionalities.
These functionalities provided by the class are termed "methods" of the class. Apart
from this, each class may have certain "attributes" that uniquely identify the class.

5
A class diagram is a diagram showing a collection of classes
and interfaces, along with the collaborations and relationships
among classes and interfaces.
A class diagram is composed of:
 Class: A class has a business functionality called methods, and properties
that reflect unique features of a class. The properties of a class are
called attributes.

6
 Analysis and design of the static view of an application.
 Describe responsibilities of a system.
 Base for component and deployment diagrams.
 Forward and reverse engineering.

7
 The name of the class diagram should be meaningful
to describe the aspect of the system.
 Each element and their relationships should be
identified in advance.
 Responsibility (attributes and methods) of each class
should be clearly identified.
 For each class minimum number of properties should
be specified. Because unnecessary properties will
make the diagram complicated.

8
 Use notes when ever required to describe some
aspect of the diagram. Because at the end of the
drawing it should be understandable to the
developer/coder.
 Finally, before making the final version, the diagram
should be drawn on plain paper and rework as many
times as possible to make it correct.

9
 For example: Let us take a class named Student. The Student class
encapsulates student information such as student id #, student name,
and so forth. Student id, student name, and so on are the attributes of
the Student class. The Student class also exposes functionality to other
classes by using methods such as getStudentName(), getStudentId(), and
the like. Let us take a look at how a class is represented in a class
diagram.

10
The following diagram shows a typical class in a class diagram:

11
 Attributes correspond to the class level variables (but not variables
declared within the body of a method).
 Operations correspond to methods in Java.
 Public members (attributes or operations) can be referenced directly by
any classes in this or any other model package (more on packages later).
 Private members can only be referenced in the same class where they’re
declared.
 Protected members can be referenced in the same class or in any
descendants of that class (more on inheritance later).
 Package scope members can be referenced by any classes in the same
UML package only.

12
13
 A dependency is a using relationship that states that a change in a
specification of one thing may effect another thing that uses it
 You will use dependencies in the context of classes to show that one
class uses another class as an argument in its method’s signature.

14
 A generalization is a relationship between a general thing (a superclass)
and a more specific kind of that thing (a subclass).
 It is a is-a-kind-of relationship.

15
16
 An association represents a relationship that specifies that objects of one
thing are connected to objects of another.

17
 A class can also be associated with itself, using a reflexive
association. This may not make sense at first, but remember that
classes are abstractions.
 An Employee class could be related to itself through the
manager/manages role.

 An instance of Employee can be the manager of another

Employee instance. However, because the relationship role of
"manages" has a multiplicity of 0..*; an Employee might not
have any other Employees to manage. 18
 An association in which one class
represents a larger thing, which consists of
smaller things is called an aggregation
relation
 It is a has-a relationship meaning an object
of the whole has objects of the part.

19
 Basic aggregation :An association with an aggregation
relationship indicates that one class is a part of another class.
 To represent an aggregation relationship, you draw a solid line
from the parent class to the part class, and draw an unfilled
diamond shape on the parent class's association end.

20
 Composition aggregation: The composition aggregation
relationship is just another form of the aggregation relationship,
but the child class's instance lifecycle is dependent on the
parent class's instance lifecycle.
 A composition relationship between a Company class and a
Department class, is drawn like the aggregation relationship,
but this time the diamond shape is filled

21
 Example: “A car consists of a chassis, an engine, wheels, and seats”

 The open diamonds denote aggregation

 Aggregation is the UML term for the part–whole relationship

 The diamond is placed at the “whole” (car) end, not the “part” (chassis,
engine, wheels, or seats) end of the line connecting a part to the whole
Figure 16.4

22
 Example: “A car consists of one chassis, one engine, 4 or 5 wheels, an optional sun
roof, zero or more fuzzy dice hanging from the rear-view mirror, and 2 or more
seats”

 The numbers next to the ends of the lines denote multiplicity

 The number of times that the one class is associated with the other class
 The line connecting Chassis Class to Car Class
 The 1 at the “part” end of the line denotes that there is one chassis involved
 The 1 at the “whole” end denotes that there is one car involved
Figure 16.5
 Each car has one chassis, as required 23
 Every chess board consists of 64 squares

 This relationship goes further

 It is an instance of composition, a stronger form of aggregation
 Association
 Models the part–whole relationship
 Composition
 Also models the part–whole relationship but, in addition,
 Every part may belong to only one whole, and
 If the whole is deleted, so are the parts
 Example: A number of different chess boards
 Each square belongs to only one board
 If a chess board is thrown away, all 64 squares on that board go as well
 Composition is depicted by a solid diamond
24
25
26
27
28
29
30
31
32
33
 Purpose: Describe domain area for an
Integrated Library System (ILS), also known
as a Library Management System (LMS) -
Library, Catalog, Book, Patron, Account.
 Summary: Library Domain Model describes
main classes and relationships which could
be used during analysis phase to better
understand domain area for ILS or LMS.

34
35
36
37
Class diagrams are used for:
 Describing the static view of the system.
 Showing the collaboration among the elements of the static view.
 Describing the functionalities performed by the system.
 Construction of software applications using object oriented languages.

38