The UML Class Diagram: Part II
In addition to this, we also can determine some implicit functionality of classes that reflect business entities. For example, what functionality should the Course class provide? Intuitively, we would define the Course class to provide functionality to view all courses in the system, ability to create new courses or modify information of existing courses, view the details of a particular course, or even remove a course from the system. We expect the Course class to provide such business functionality because the Course class reflects a business entity in the system. Hence, these become the methods exposed by the Course class. So, we can now refine the class diagram and add methods to each of these classes.
To cut a long story short, each of the classes that reflect business entities will provide similar implicit business functionality. Let us list all such "implicit" functionality for each of these classes.
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. It is left to the design expertise to identify reusable classes/functionality.
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
The next step after defining the classes of the Courseware Management System is to define the relationships and dependencies between these classes and interfaces. To define the relationships between the classes, we need to analyze the interconnections between the classes—whether implicit or explicit. Relationship analysis can be broken up into three steps:
- 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. Recall that elements in a realization relationship implement declared functionality as a "contract." For example, a set of classes may implement functionality declared as methods in an interface, and this can be modeled as a realization relationship between the interface and the classes implementing the interface.
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.
- Identify relationships between "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. It is by far quite intuitive to identify aggregation as well as its variations—composition relationships for passive business entities.
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.
Page 2 of 3