An Example in Data Modeling in UML

Size: px

Start display at page:

Download "An Example in Data Modeling in UML"

Melina Wilkerson
6 years ago
Views:

1 An Example in Data Modeling in UML Data modeling is a difficult topic for many students to learn and also for an instructor to teach. This full example shows the nuances of data modeling and discusses some mistakes students made. It is a question in a mid-term examination in a graduate DBMS course. Limited by the examination, the example is artificially designed to test students of many common patterns in modeling and not necessarily very realistic. The Student Group System (SGS) Question As appeared in the examination: The goal is to build a toy prototype database to partially support a portion of a drastically simplified student group system (SGS). Construct an UML class diagram to capture and model the partial requirements below. You should list class names, attributes with multiplicities, and associations with multiplicities. Roles of associations should also be provided when appropriate. Multiplicities should be as specific as possible. Show the stereotype <<PK>> (primary key) when applicable. In SGS, students can form groups to do things and join these groups as members. The student id (a unique identifier that can serve as a key), name, , and phone of a student should be recorded. All are mandatory fields with the exception of phone, which is optional. When a student joins a group as a member, the join time must be stored, together with an optional comment. A group must have a unique id and a name. It may also have a description. It can be a top group or a lower level group. A group may have some subgroups, which are themselves groups, and thus may have their own subgroups. A top level group must have a faculty supervisor, so a faculty id must be stored. A member can make comments on a top level group (but not a lower level group). Such comments should be recorded with the time they were made. The Suggested Solution The suggested solution was constructed using the community version of Astah.

2 Explanations Let s start with the straightforward classes: Student and Group. In the specification: This is modeled in the UML diagram:

Note: 1. A student has many properties and relationships. It is thus modeled as a class. 2. StudentId is a unique identifier. We use the stereotype <<PK>> to capture this requirement.

3 Note: 1. A student has many properties and relationships. It is thus modeled as a class. 2. StudentId is a unique identifier. We use the stereotype <<PK>> to capture this requirement. <<PK>> is a database modeling extension standing for primary key in our use, which will be unique in the relation implementing the Student class eventually. We make the assumption that StudentId will be the primary key. 3. LName, FName, and Phone are properties of a student and are modeled as attributes of the class Student. We break the name into LName (last name) and FName (first name). It is possible that further breakdown or additions are appropriate, such as MiddleInitial. For the multiplicities of the attributes of the class Student, in the requirement specification: In the UML model: Note: 1. LName, FName and are mandatory and thus have the multiplicity of 1, i.e When converted to the relational model, these attributes will be non-nullable in the relation Student (that implements the class Student). 2. Phone is optional and thus has the multiplicity of It will eventually be nullable in the relation Student,

3. Furthermore, the multiplicity of StudentId is 1 since the value of primary key is mandatory. For the concept group and its relationship with student, in the specification: The model: Note: 1.

4 3. Furthermore, the multiplicity of StudentId is 1 since the value of primary key is mandatory. For the concept group and its relationship with student, in the specification: The model: Note: 1. The class Group is created. 2. There are two descriptions of groups in the sentence: students form groups to do things and students join groups as members. It is necessary to study whether they are two different concepts between students and groups, or just one. In this case, we assume that they are the same as in students form and join groups as members to do things. It is modeled by the class Membership, which will be discussed next. The specification about members:

It is possible to model this requirement as an association between the class student and the class group: One may read this association as: (A student) (is a member of) - (a group).

5 It is possible to model this requirement as an association between the class student and the class group: One may read this association as: (A student) (is a member of) - (a group). Alternatively, an association can be promoted to a class in an UML model. A class has the extra flexibility of having attributes and forming associations with other classes. An association cannot form associations with other classes. In the suggested model: The association is promoted to a class Membership because: 1. It has two properties, Since and Comment, that can now be modeled as attributes of the class. 2. More importantly, the class Membership forms an association with another class Comment. It is a good practice to document your UML diagram while developing them. At the minimum, definitions and descriptions should be provided for the classes. The advantages:

6 1. Communications: clear definitions enhance articulation, discussion and refinement with stakeholders. 2. Perspectives: documentation provides an additional perspective to improve modeling and detect model deficiency. 3. Clarifications: Further elaborations on assumptions help better understanding of the problem requirements. For the class Membership : Note that in the class description of Membership : A membership describes a student joining a group. The comment attribute stores the optional comment a student may make when joining a group, whether it is a top level group or a lower level group. This is not to be confused with the comment class, which represents the comments a member can make to a top level group (but not to a lower level group). There are a definition and a clarification of what the comment attribute is. Note also that the class name of Membership is better than the possibly more intuitive name of Member. The term Member may give the impression that the object is a person. It is not. It is really the collection of information of a membership between a person and a group. After promoting membership to a class, the multiplicities with the classes Student and Group are:

7 In UML-speak, we have: 1. Every Membership object is associated with exactly one Student object. 2. Every Membership object is associated with exactly one Group object. In daily English: A membership is a student joining a group (as a member). Note that the term member in the sentence above is not really a person but a role a student assumes when joining a group. For the other multiplicities in these associations:

In UML-speak, we have: 1. Every Student object is associated with 0 or more Membership objects. 2. Every Group object is associated with 0 or more Membership objects.

8 In UML-speak, we have: 1. Every Student object is associated with 0 or more Membership objects. 2. Every Group object is associated with 0 or more Membership objects. In daily English: Every group have many students. Each student may join many groups. For the properties of a group, in the requirement specifications, we have: In the corresponding suggested model: Note: 1. Join time is modeled as the attribute Since. 2. The adjective must is modeled as the multiplicity 1 (i.e. 1..1) for Since. 3. Comment is modeled as the attribute Comment. 4. The adjective optional is modeled as the multiplicity 0..1 for Comment.

For the properties of a group, in the requirement specification: In the suggested model: Note: 1. The noun Id is modeled as the attribute GroupId. A more specific name is used. 2.

9 For the properties of a group, in the requirement specification: In the suggested model: Note: 1. The noun Id is modeled as the attribute GroupId. A more specific name is used. 2. The adjective unique is modeled by the stereotype <<PK>> of GroupId. 3. The word must means that the multiplicities of GroupId and GroupName should be The noun Name is modeled as the attribute GroupName. A more specific name is used. 5. The noun Description is modeled as an attribute. 6. The word may means that the multiplicity of Description should be About the different kinds of groups, the requirement specification has:

Two concepts show up: 1. Top group 2. Lower level group There are many possible ways to model this. For examples: 1.

Use a class GroupType and an association between the class Group and GroupType. 3.

10 Two concepts show up: 1. Top group 2. Lower level group There are many possible ways to model this. For examples: 1. Use an attribute GroupType in the class Group. The value of the attribute may include top and lower. 2. Use a class GroupType and an association between the class Group and GroupType. 3. Introduce two classes, such as TopGroupProperty and LowerGroupProperty, to store the properties that are top group or lower level group respectively. This is a more appropriate approach if the properties can be shared with classes other than the Group class. 4. Introduce two classes, such as TopGroup and LowerGroup as the subclasses of the class Group. This is used by the suggested model.

11 There are many criteria that may favor the use of an inheritance structure (instead of just using attributes, for example). One such metric is whether there are needs for the distinction between the classes in the inheritance structure. Our suggested solution consider this distinction to be necessary: Note: 1. A membership is associated to a group, no matter whether it is a top group or a lower group. 2. Only a top group can have comment made with a membership. 3. Only a top group has a FacultyId serving as its supervisor. 4. Only a lower level group can be a subgroup.

On subgroups, the requirement specification has: There are three concepts in the sentence above: 1. A group may have some subgroups. 2. A subgroup is a group. 3.

12 On subgroups, the requirement specification has: There are three concepts in the sentence above: 1. A group may have some subgroups. 2. A subgroup is a group. 3. Thus, a subgroup may have its own subgroups. In the suggested model: The concepts are modeled as below: 1. A group may some subgroups: a group may have 0..* child group. 2. A subgroup is a group: the class LowerGroup (subgroup) is a subclass of the class Group. Thus, a LowerGroup object is also a Group object. 3. As a result of (1) and (2), a subgroup may have its own subgroups: a LowerGroup object is also a Group object and thus may have 0..* child subgroups itself. Thus, the parent group is a group object and the child group is a lower level group object. An assumption that is not entirely certain from the specification has been made:

13 A top level group cannot be a subgroup of any other group. In the suggested model: The conversion of this assumption is: 1. A lower level group must be a subgroup of another group, its parent group. Some observations can be drawn:

1. Since a lower group is defined as a subgroup that must have a parent group, the multiplicity of the role parent group must be 1, and not 0..1. In UML-speak, every lower group object is associated with exactly one group object as its parent.

14 1. Since a lower group is defined as a subgroup that must have a parent group, the multiplicity of the role parent group must be 1, and not In UML-speak, every lower group object is associated with exactly one group object as its parent. 2. On the other hand, a group object is associated with 0..* lower group objects as its child groups. In plain English, a group may have many subgroups. 3. Like program documentation, redundant documentation may not be necessary. If an association is not ambiguous, it is not necessary to provide its names or the role names of the participating classes. However, if it is not clear, role names, such as parent group and child group, are helpful. To revisit the specification on membership: The specification does not precisely specify whether a student can join a top level group, a lower level group, or both. It is assumed to be both. In the model:

and LowerGroup classes. 2. The assumption is included in the definition of the class Group.

15 Note: 1. As a result of this assumption, the association from the Membership class is to the group class, which is the superclass of both TopGroup and LowerGroup classes. 2. The assumption is included in the definition of the class Group. A (student) group may be a top level group or a lower level group that a student can join. It is assumed that a student can join any number of groups. She can join a group and any number of its subgroups. The specification has the following description the faculty supervisor of a top level group: In the suggested model:

Note: 1. The facultyid is an attribute of the class TopGroup, as LowerGroup does not have a faculty supervisor. 2. FacultyId is modeled as an attribute.

16 Note: 1. The facultyid is an attribute of the class TopGroup, as LowerGroup does not have a faculty supervisor. 2. FacultyId is modeled as an attribute. In a more realistic model, it is likely that a class Faculty is needed, and the supervisor concept is modeled as a many to one association between TopGroup and Faculty. The specification has the following description on comments made by members on top level groups. In the suggested model:

17 Note: 1. The specification indicates that (a member) (makes comment on) (a top group.) A comment is an association between a member and a top group. It is promoted to a full class as there are two properties to be modeled. This is similar to the class of the class Membership, which is also promoted from an association. Thus, the multiplicities of comment to member and comment to topgroup are both many (0..*) to one (1). 2. In this context, the commenting member is not just a student, but a student holding a membership. Thus, the association is between the classes Membership and Comment, but not Student and Comment. 3. The specification adds the narrative but not a lower level group. This further confirm that the association from the class Comment is to the class TopGroup, but not Group or LowerGroup. Potential Mistakes To appear

CS 338 The Enhanced Entity-Relationship (EER) Model

CS 338 The Enhanced Entity-Relationship (EER) Model Bojana Bislimovska Spring 2017 Major research Outline EER model overview Subclasses, superclasses and inheritance Specialization and generalization Modeling