The UML Class Diagram in Action: Part II

Introduction

In the UML Class Diagram Part 1 article of this series, you saw what class diagrams were, and how to create class diagrams. In today's article, you will see a practical example building on our Courseware Management system case study.

Case study—Courseware Management System

The UML class diagram of our Courseware Management System case study can be built after a careful analysis of the requirements. In the previous article, we identified the primary actors and use cases in the use case model of the case study. Because we did much of the groundwork of our analysis while building the use case model, we will use those analysis steps as the basis for identifying the classes and interfaces of this system.

Let us recap the analysis that was performed when the use case model was designed. 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

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 you did in use case modeling, you 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. We will apply this rule to determine classes and interfaces of the case study system. 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
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
   
   

   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.

   Our two-step process has definitely yielded promising results! We have covered all the relevant items in our analysis. So, 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 classes that we have identified for the Courseware Management System also provide business functionality related to the application. 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.

ClassName	Methods
CourseAdministrator	viewCourses() manageCourse() manageTopic() viewCourseCalendar() viewTutors() manageTutorInformation() assignTutorToCourse()

Page 1 of 3



This article was originally published on May 22, 2003