0% found this document useful (0 votes)
68 views20 pages

Class Diagram UML

Uploaded by

ramenhunter98
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
68 views20 pages

Class Diagram UML

Uploaded by

ramenhunter98
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 20

Class Diagram

Prepared By Orwah Aladaileh 1-1


Prepared By Orwah Aladaileh
What is Class diagram?
• is a type of static
structure diagram
that describes the
structure of a
system by
showing the
system's classes,
their attributes,
operations (or
methods), and
the relationships
among objects
Prepared By Orwah Aladaileh
Purpose of Class Diagrams

1. Shows static structure of classifiers in a system


2. Diagram provides a basic notation for other structure diagrams
prescribed by UML
i.e. used as building blocks for creating more complex diagrams, such as object
diagrams, package diagrams, component diagrams
3. Helpful for developers and other team members too
4. Business Analysts can use class diagrams to model systems from
a business perspective
•A UML class diagram is made up of:

1. A set of classes and


2. A set of relationships between classes
Prepared By Orwah Aladaileh
What is a Class?
❖ A description of a group of objects all with similar roles in the
system, which consists of.
❖ Structural features (attributes) define what objects of the class
"know"
• Represent the state of an object of the class
• Are descriptions of the structural or static features of a class
❖ Behavioral features (operations) define what objects of the class
"can do"
• Define the way in which objects may interact
• Operations are descriptions of behavioral or dynamic features
of a class

Prepared By Orwah Aladaileh


Class Notation
1. Class Name
1. The name of the class appears in the first partition.
2. Class Attributes
1. Attributes are shown in the second partition.
2. The attribute type is shown after the colon.
3. Attributes map onto member variables (data members) in code.
3. Class Operations (Methods)
1. Operations are shown in the third partition. They are services the
class provides.
2. The return type of a method is shown after the colon at the end of
the method signature.
3. The return type of method parameters is shown after the colon
following the parameter name.
4. Operations map onto class methods in code
Prepared By Orwah Aladaileh
Class Notation
1. The graphical representation of the class
showed:
2. MyClass has 3 attributes and 3 operations
3. Parameter p3 of op2 is of type int
4. op2 returns a float
5. op3 returns a pointer (denoted by a *) to
Class6

Prepared By Orwah Aladaileh


Class attributes and Operations
1. In object-oriented design, there is a notation
of visibility for attributes and operations.
UML identifies four types of visibility: public,
protected, private, and package.

2. The +, -, # and ~ symbols before an attribute


and operation name in a class denote the
visibility of the attribute and operation.

3. + denotes public attributes or operations


4. - denotes private attributes or operations
5. # denotes protected attributes or operations
6. ~ denotes package attributes or operations

Prepared By Orwah Aladaileh


Class Relationships
A class may be involved in one or more
relationships with other classes. A
relationship can be one of the following
types:
1. Inheritance (or Generalization).
Represents an "is-a" relationship.
• An abstract class name is shown in
italics.
• SubClass1 and SubClass2 are
specializations of Super Class.
• A solid line with a hollow arrowhead
that point from the child to the parent
class
Prepared By Orwah Aladaileh
Inheritance Example - Cell Taxonomy

Prepared By Orwah Aladaileh


Class Relationships

2. Simple Association.
• A structural link between
two peer classes.
• There is an association
between Class1 and Class2
• A solid line connecting two
classes

Prepared By Orwah Aladaileh


Class Relationships

3. Aggregation.
• Class2 is part of Class1.
• Many instances (denoted by
the *) of Class2 can be
associated with Class1.
• A solid line with an unfilled
diamond at the association
end connected to the class
of composite

Prepared By Orwah Aladaileh


Aggregation Example - Computer
and parts

Prepared By Orwah Aladaileh


Class Relationships
4. 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.
• A solid line with a filled diamond at
the association connected to the
class of composite

Prepared By Orwah Aladaileh


Class Relationships
5. Dependency.
• Exists between two classes if the
changes to the definition of one
may cause changes to the other
(but not the other way around).
• Class1 depends on Class2
• A dashed line with an open arrow

Prepared By Orwah Aladaileh


Relationship Role

Prepared By Orwah Aladaileh


Multiplicity
Exactly one - 1
Zero or one - 0..1
Many - 0..* or *
One or more - 1..*
Exact Number - e.g. 3..4 or 6
Or a complex relationship - e.g. 0..1, 3..4, 6.* would mean any number of objects
other than 2 or 5

Prepared By Orwah Aladaileh


Dealing with Complex System -
Multiple or Single Class Diagram
• Inevitably, if you are modeling a large system or a large business area, there will be
numerous entities you must consider. Should we use multiple or a single class
diagram for modeling the problem? The answer is:

• Instead of modeling every entity and its relationships on a single class diagram, it is
better to use multiple class diagrams.
• Dividing a system into multiple class diagrams makes the system easier to
understand, especially if each diagram is a graphical representation of a specific
part of the system.

Prepared By Orwah Aladaileh


Dealing with Complex System -
Multiple or Single Class Diagram
• by analyzing user stories, you can often identify the various actors (users, systems,
or external entities) interacting with the system and the actions they perform. From
these interactions, you can infer the types of classes or objects that may be
required to represent these actors and their behaviors.

• For example, if a user story involves creating a new order in an e-commerce


system, you can infer that there may be classes such as Order, Customer, Product,
and ShoppingCart involved in the system. Similarly, if a user story involves logging
in to a system, you may infer the existence of a User or Account class.

• So, while user stories may not explicitly list the classes in your system, they can
guide you in identifying the necessary components and behaviors that need to be
modeled in your system.

Prepared By Orwah Aladaileh


References

• Valacich, Joseph S. Essentials of systems analysis and design / Joseph


S.Valacich, Joey F. George, Jeffrey A. Hoffer.—5th ed.
• System Analysis, Design, and Development Concepts, Principles, and Practices
Charles S. Wasson ISBN-13 978-0-471-39333-7.
• https://www.lucidchart.com.
• https://www.collegesidekick.com/study-docs/4456862

PREPARED BY: DR. RANEEM QADDOURA

You might also like