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.
- 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.
- Identify the "active" entities in the system
- Course administrators
- Tutors
- Students
- Identify business domain ("passive") entities in the 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
- 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