7.

4 Class Diagram
 Basics
• Class diagrams are the most common diagram
found in modeling object- oriented systems.
• A class diagram
– is a diagram showing a collection of classes and
interfaces, along with the collaborations and
relationships among classes and interfaces.
– Used to model the static design view of a system.
• This involves
» Modeling the vocabulary of the system,
» Modeling collaborations, or
» Modeling schemas.
 Basics (cont.)
• Class diagrams are important not only for
– visualizing,
– specifying, and
– documenting structural models, but also for
• constructing executable systems through forward and
reverse engineering.
• Class diagrams describe three different
perspectives when designing a system,
• conceptual, specification, and implementation.
• These perspectives become evident as the diagram is
created and help solidify the design.
 Basics (cont.)
• A class diagram
– is a pictorial representation of the detailed system design.
• Design experts who understand the rules of modeling and
designing systems design the system's class diagrams.
• Represents the structure of a system.
• Referenced time and again by the developers while implementing
the system.
• How does a class diagram relate to the use case diagrams
– use cases talk about "what are the requirements" of a system.
– the aim of designing classes is to convert this "what" to a "how" for
each requirement.
– each use case is further analyzed and broken up into atomic
components that form the basis for the classes that need to be
designed.
 Elements of a class diagram
• Classes are composed of three things:
– a name, attributes, and operations.
 Elements of a class diagram(cont.)
• The class name typically has the first alphabet
capitalized. If your class has more than one
words then capitalize all words and join them.
• E.g Student
• List of attributes/variables  the syntax is:
– attribute : type = “default value (if any)”
• e.g. studentId:int, studentName:String
• List of methods  the syntax is:
• MethodName(List of parameters(if any)):Return type(if any)
• e.g. String getStudentName(int studentId)
 Elements of a class diagram(cont.)
• Interface
– is a variation of a class.
– a class provides an encapsulated implementation of
certain business functionality of a system.
– provides only a definition of business functionality of a
system.
• An interface shares the same features as a class
– contains attributes and methods.
– The only difference is that that the methods are only
declared in the interface and will be implemented by
the class implementing the interface.
Elements of a class diagram(cont.)
• Package
– provides the ability to group together classes and/or
interfaces that are either similar in nature or related.
– Grouping these design elements in a package
element provides for better readability of class
diagrams, especially complex class diagrams.
– is represented as a tabbed folder.

– can also have relationships with other packages

similar to relationships between classes and
interfaces.
Relationships Between Classes
Relationships Between Classes (cont.)
 Differences between Composition and
Aggregation
• The whole of a composition must have a multiplicity of 0..1
or 1, indicating that a part must be for only one whole.
• The whole of an aggregation may have any multiplicity.
• When attempting to represent real-world whole-part
relationships,
• e.g., an engine is part of a car, the composition relationship is most
appropriate.
• However, when representing a software or database relationship, e.g., car
model engine ENG01 is part of a car model CM01, an aggregation relationship
is best, as the engine, ENG01 may be also part of a different car model.
– Thus the aggregation relationship is often called "catalog"
containment to distinguish it from composition's
"physical" containment.
Relationships Between Classes (cont.)
 Examples
(Initial conceptual class diagram)
Modeling people at a university
 Case study: Courseware Management System
• The class diagram of our Courseware Management System
case study can be built after a careful analysis of the
requirements.
• During our analysis of requirements (use case modeling) the
following terms and entities specific to the system were
identified from the problem statement:
• Courses and Topics that make up a course
• Tutors who teach courses
• Course administrators who mange the assignment of the
courses to tutors
• Calendar or Course Schedule is generated as a result of the
• Students who refer to the Course schedule or Calendar to
decide which courses for which they wish to sign up
 Case study: Courseware Management System(cont.)

• The potential actors of the system were:

• Tutors
• Course administrators
• Students
• And the use cases of the system were:
• View courses
• Manage topics for a course
• Manage course information
• View course calendar
• View tutors
• Manage tutor information
• Assign courses to tutors
 Identifying classes of the Courseware Management System
• As we did in use case modeling, we will identify the
classes and interfaces using an incremental approach.
1. Identify the "active" entities in the system
– The basic rule that we learned until now for identifying classes
and interfaces is that classes and interfaces reflect important
entities of the business domain of the system being modeled.
– At first glance, the actors identified in the use case appear to be
prime candidates for being listed as potential classes.
– Even though we had excluded Students and Tutors from our
final list of actors, we will still include them in our list as
potential classes. So, our first list of classes in the system
appears to be:
• Course administrators
• Tutors
• Students
 Identifying classes of the Courseware Management
System

2. Identify business domain ("passive") entities

in the system But these are the "active"
entities of the system. We had also identified
"passive" elements in the system as well in
the analysis for our use case model. These
entities reflect the business domain and hence
are potential classes for our system.
• Courses
• Topics that make up a course
• Course calendar generated
 Identifying classes of the Courseware Management
System
• Entities that reflect the business terms are also
called business domain classes or just "domain
classes." Some of the business domain classes
hold transient data and some hold persistent data
for the application. Normally, such business
domain classes map to either one or many
database tables.
• For example, in our case study, the Course class can be
modeled as a database table cms_course. The data in this
table for a particular course will be represented by an
instance of the Course class and made available to the rest
of the application.
• So, based on our analysis let us list the list of
classes and interfaces that we have identified
in the Courseware Management System.
– CourseAdministrator
– Tutor
– Student
– Course
– Topic
– CourseCalendar
3. Categorize and map the use cases and any relevant
business functionality to either the passive or active
entities.
• These will become the business methods of the classes in
the system.
• Classes encapsulate functionality. The functionality
encapsulated by these classes is distinct in nature and
differs from each class. Recall from our use case model,
that, along with actors, we had identified a set of use cases
that the actors interacted with. Let us try to associate them
with our classes.
• Because our primary actor is the course administrator and
the use cases were related to this actor, we can directly
map the use cases to the CourseAdministrator class as
methods.
The class that are captured follows
 Refine and revise the list of classes and interfaces
• Revisit the class diagram and revise it by identifying
shared features and/or common functionality
between classes or interfaces.
• These will translate into reusable pieces of code for your system.
• To some extent, we can say that CourseAdministrator, Tutor,
and Student are essentially users of the system.
• Hence, we can define a shared parent class named User and
define basic functionality like for example, authentication, in the
User class that can be inherited by the CourseAdministrator,
Tutor, and Student classes.
– This completes our analysis of the problem statement to
define the classes for the Courseware Management
System.
 Identifying relationships between the classes of
the Courseware Management System
• To do this we need to analyze the interconnections
between the classes—whether implicit or explicit.
• R/ship analysis can be broken up into three steps:
1. Identify relationships between "active" entities
– Active entities normally share generalization
relationships ("is-a"). Essentially, the common
attributes and functionality between classes are
defined in a common parent class. All the related child
classes inherit functionality from the parent class.
– Apart from generalization, a few active entities can also
be interconnected by a realization relationship.
• In our case study, we do not find an example
of inheritance relationship between the active
entities such as Student, Tutor, and
CourseAdministrator or any realization
relationships.
2. Identify r/ships b/n "passive" business entities
– Passive business entities frequently share plain
association or aggregation relationships ("has-a").
– This is especially true because these business entities are
non-transactional in nature and reflect data more than
behavior.
– Some of the classes in our case study do exhibit
aggregation relationships.
• Because a set of topics makes up a course, we can define an
aggregation relationship between the Course and Topic classes.
– Moreover, we can define this as a directed aggregation, meaning that
you can check for the topics of a course but not vice versa.
• Similarly, we can define a plain association relationship
between the Course and Tutor classes and Course and Student
classes.
3. Identify r/ships b/n "active" and "passive" entities
• This can easily be represented using directed
association.
• The directed association provides easy identification of which is the
container class and which is the contained class.
– The CourseAdministrator class can be modeled to have a directed association
with the Course class.
» This association can be named as "manages" because the course
administrator manages courses as a business activity.
– In addition to this, because the course administrator also manages the tutor
information and topic information, we can model a directed relationship
named as "manages" between the CourseAdministrator and the Course and
Topic classes, respectively.
– We can enhance the readability of the association between
CourseAdministrator and the Course, Tutor, and Topic classes by defining the
multiplicity for the association—one to many, one to one, many to many, and
so forth.
– The resulted class diagram is shown next
 Summary
• The class diagram of the Courseware
Management System includes all the classes
and their relationships that we identified
during our analysis of the problem statement.