CHAPTER V

CLASS and METHOD DESIGN

Complied by: Aiwa Jane P. Rojo, PhD. TM

INTRODUCTION
In Chapter V, we'll explore the art of designing classes and methods, essential for creating
structured and flexible code. We'll discuss concepts like encapsulation, inheritance, and
polymorphism, all illustrated through easy-to-understand class diagrams. These diagrams will
serve as visual guides, helping students grasp the relationships between classes and methods,
ultimately leading to clearer, more efficient code design.
OUTCOMES
At the end of the topic the students must have:
• Discussed and recognized the rules and style guidelines for creating CRC card and class diagrams
• Discussed and recognized the processes used to create CRC cards, class diagram
• Created a Class Diagram

LESSON CONTENT
In software engineering, a class diagram in the Unified Modeling Language (UML) is a static structure
diagram used to depict the structure of a system. It illustrates the classes within the system, along with
their attributes, operations (or methods), and the relationships between these classes. Class diagrams
provide a visual representation of the system's architecture, aiding in the understanding and design of
software systems.

Class Design Principles

Encapsulation - Discuss the concept of encapsulation and how it helps in organizing code and
protecting data.
Cohesion and Coupling - Explain the importance of achieving high cohesion and low coupling in
class design for better maintainability and flexibility.
Single Responsibility Principle (SRP) - Introduce SRP and how it guides the design of classes by
advocating for each class having only one responsibility.
Inheritance and Polymorphism
Inheritance Hierarchies - Explore how to design class hierarchies to represent relationships
between classes using inheritance.
Polymorphism - Explain the concept of polymorphism and how it allows objects of different
classes to be treated uniformly through inheritance and method overriding.
Method Design Guidelines
Method Naming Conventions - Discuss naming conventions for methods to make them self-
explanatory and consistent with the language's standard practices.
Method Signature - Explain the components of a method signature, including the return type,
method name, parameters, and access modifiers.
Method Overloading and Overriding - Differentiate between method overloading and
overriding and discuss when to use each technique in class design.
Access Modifiers and Encapsulation
Access Modifiers - Explain the various access modifiers (e.g., public, private, protected) and how
they control the visibility of class members.
 Encapsulation Revisited - Reinforce the concept of encapsulation and how access modifiers help
in achieving encapsulation by restricting direct access to class members.
Design Patterns in Class and Method Design

Creational Patterns: Introduce creational design patterns (e.g., Singleton, Factory Method) and discuss
how they can be used to instantiate objects in a flexible and efficient manner.
Structural Patterns: Discuss structural design patterns (e.g., Adapter, Composite) and how they facilitate
the composition of classes and objects to form larger structures.
Behavioral Patterns: Explore behavioral design patterns (e.g., Observer, Strategy) and how they define
communication patterns between classes and objects.

Class diagrams stand out as essential tools within the Unified Modeling Language (UML), offering a clear
blueprint of a system's architecture. They meticulously outline the system's classes, attributes,
operations, and object relationships, providing invaluable insights into its structure. Utilizing our user-
friendly UML diagramming software, crafting these diagrams becomes an accessible task, simplifying
what might initially seem daunting.

• Depicts the static structure of classifiers within a system

• Serves as a fundamental notation for various other structure diagrams outlined by UML
• Beneficial not only for developers but also for other team members
• Enables Business Analysts to model systems from a business-oriented perspective

Class diagrams are invaluable tools that play various roles across the system design lifecycle. Initially,
they facilitate understanding the requirements of the problem domain and delineating its components
during the analysis stage. As an object-oriented software project advances, the class diagrams conceived
early on serve as blueprints for actual software classes and objects during coding. Over time, these
diagrams undergo refinement to illustrate specific system components, user interfaces, and logical
implementations. Ultimately, they offer a comprehensive overview, detailing the system's functionality,
component relationships, and implementation plans.

Class diagrams serve as versatile tools for visualizing, specifying, and documenting structural features
within models. During the analysis and design phases of the development cycle, they fulfill various
functions such as:

• Capturing and defining class and classifier structures

• Establishing relationships between classes and classifiers
• Illustrating model structures using attributes, operations, and signals
• Depicting common classifier roles and responsibilities shaping system behavior
• Displaying implementation classes within a package
• Demonstrating the structure and behavior of individual or multiple classes
• Visualizing inheritance hierarchies among classes and classifiers
• Representing workers and entities as business object models
• During the implementation phase of a software development cycle, you can use class diagrams
to convert your models into code and to convert your code into models.
How to Draw a Class Diagram
The class diagram serves as a cornerstone in constructing software applications, offering a
comprehensive portrayal of both the static and dynamic aspects of the system. Here are some
key considerations for creating effective class diagrams:
1. Assign a meaningful name to encapsulate the entire aspect of the system.
2. Identify objects and their relationships beforehand.
3. Familiarize yourself with the attributes and methods (responsibilities) of each class.
4. Aim for a minimal set of essential properties to prevent unnecessary complexity.
5. Utilize notes to provide additional insights and details as needed.
6. Iterate on the diagrams, refining and revising them multiple times to ensure accuracy before finalizing the
version.

Elements of Class Diagram

Class Relationships
A class may be involved in one or more relationships with other classes. A relationship can be one of
the following types: (Refer to the figure on the right for the graphical representation of relationships).

Relationship Type Graphical Representation

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

Simple Association:
• A structural link between two peer classes.
• There is an association between Class1 and
Class2
• A solid line connecting two 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.
• A solid line with an unfilled diamond at the
association end connected to the class of
composite

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

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
ASSESSMENT
Direction: On a quarter sheet, neatly jot down your name, course and section, date, and the current
lesson's chapter for proper identification.
Answer the following multiple-choice questions by writing the chosen letter on a separate sheet of
paper.
1. What is the primary purpose of a class diagram in software engineering?
a) Illustrating dynamic behavior of the system
b) Describing the sequence of method calls
c) Representing the static structure of the system
d) Showing relationships between different systems

2. What does a solid line with a hollow arrowhead between two classes typically represent in a
class diagram?
a) Aggregation
b) Composition
c) Inheritance
d) Dependency

3. In a class diagram, what does a diamond-shaped arrow pointing towards the whole class usually
indicate?
a) Aggregation
b) Composition
c) Inheritance
d) Dependency

4. Which of the following represents a "whole-part" relationship between classes in a class

diagram?
a) Association
b) Aggregation
c) Inheritance
d) Dependency

5. What is the purpose of attributes in a class diagram?

a) Representing methods that perform actions
b) Defining relationships between classes
c) Describing properties or characteristics of a class
d) Indicating the number of instances of a class in an association

6. What element in a class diagram denotes a contract for implementing classes?

a) Association
b) Interface
c) Composition
d) Inheritance

7. Which relationship in a class diagram implies that one class depends on another in some way?
a) Association
b) Aggregation
 c) Composition
d) Dependency

8. What should be done to reduce complexity when drawing a class diagram?

a) Specify as many properties as possible
b) Refrain from using notes to describe aspects of the diagram
c) Redraw and rework the diagrams multiple times before finalizing
d) Include unnecessary relationships between classes

9. What is recommended to give to a class diagram to describe a complete aspect of the system?
a) A random name
b) A meaningful name
c) An abstract name
d) A descriptive name

10. What does a class diagram represent as a collection?

a) A whole system
b) A subset of a system
c) A specific class
d) A group of objects

11. What do attributes in a class diagram describe?

a) Relationships between classes
b) Methods or behaviors of a class
c) Properties or characteristics of a class
d) The inheritance hierarchy

12. Which diagram element signifies the number of instances of one class related to another class in
an association?
a) Aggregation
b) Composition
c) Multiplicity
d) Dependency

13. What does a dashed arrow pointing from one class to another indicate in a class diagram?
a) Inheritance
b) Aggregation
c) Composition
d) Dependency

14. In a class diagram, what does a hollow diamond-shaped arrow pointing to the whole class
represent?
a) Aggregation
b) Composition
c) Inheritance
d) Dependency
15. When should a class diagram be redrawn and reworked?
a) Only once after the initial draft
b) Multiple times to ensure correctness before finalization
c) Only when significant changes occur in the system
d) Only when requested by stakeholders

16. What element in a class diagram illustrates behaviors or actions that objects of the class can
perform?
a) Attributes
b) Operations
c) Associations
d) Interfaces

17. In a class diagram, what does a dashed line represent between two classes?
a) Aggregation
b) Composition
c) Inheritance
d) Dependency

18. Which of the following is NOT a key consideration when drawing a class diagram?
a) Giving meaningful names
b) Specifying a minimum number of properties
c) Using notes to describe aspects of the diagram
d) Including unnecessary relationships between classes

19. What does a class diagram depict beyond just the static view of the system?
a) Only the sequence of method calls
b) All the major aspects of an application
c) Only relationships between classes
d) Only the dynamic behavior of the system

20. How do class diagrams help in understanding a system?

a) By illustrating only dynamic behavior
b) By representing only the sequence of method calls
c) By providing a static view along with all major aspects of an application
d) By ignoring relationships between classes