The following is an example of a data modeling task in which all modeling decisions have been traced back to the requirements. It begins with the requirements document, then performs the data modeling task in a series of steps.
The latest "hot" e-commerce company is Customized-Book.com. Their plan is to sell truly customized books to the general public. Customers who log onto the Customized-Book.com Web site can specify exactly what they want in their books. Customized-Book.com will then scan through their large collection of book components for exactly those components that satisfy the customer's specification. The book components are combined together with a table of contents, index and introduction. Each book is then printed, bound and shipped to the shipping address specified by the customer.
Each customer has a name, address, login name and password. The customer may fill their "shopping cart" with one or more customized books. A customized book has a specification, price and shipping address (including a name and address) if different from the customer's address.
Each customized book matches various book components. A book component has a content, price and author. Each author has a name that uniquely determines the author within this database. Book components also have specifications. Specifications are boolean expressions based on elementary specifications.
Looking through the requirements we find the following nouns occurring repeatedly:
Term | Synonym(s) | Class |
---|---|---|
customized book | book | CustomizedBook |
customer | Customer | |
address | Address | |
shipping address | ShippingAddress | |
book component | component | BookComponent |
specification | customer's specification, expression | Specification |
operation | boolean expression | Operation |
shopping cart | log in (session) | ShoppingCart |
elementary specification | ElementarySpecification | |
author | Author |
One now looks for phrases that suggest relationships from one class to another. The first class in an association is called the "source" class, and the second is the "target". The inheritance or "isa" relationship is called "extends" below. For each relationship, I have noted the phrase in the original requirements that justifies the relationship. Citing another document to justify an element of a data model (or of another modeling or design task) is called tracing.
Phrase | Source | Relationship | Target |
---|---|---|---|
Customers who log onto the ... site | Customer | fill | ShoppingCart |
Customers ... can specify exactly what they want in their books | CustomizedBook | satisfies | Specification |
book components ... satisfy the customer's specification | BookComponent | satisfies | Specification |
The book components are combined together... | CustomizedBook | composedOf | BookComponent |
Each book is ... shipped to the shipping address | CustomizedBook | shippedTo | ShippingAddress |
Each customer has an ... address ... | Customer | livesAt | Address |
The customer may fill their "shopping cart" with one or more customized books | ShoppingCart | composedOf | CustomizedBook |
A customized book has a specification... | CustomizedBook | satisfies | Specification |
A customized book has a ... shipping address | CustomizedBook | shippedTo | ShippingAddress |
shipping address (including a name and address) | ShippingAddress | extends | Address |
Each customized book matches various book components | CustomizedBook | composedOf | BookComponent |
A book component has an ... author | BookComponent | writtenBy | Author |
Book components also have specifications | BookComponent | satisfies | Specification |
...boolean expressions based on elementary specifications | ElementarySpecification | extends | Expression |
...boolean expressions... | Operation | extends | Expression |
...boolean expressions... | Operation | operatesOn | Expression |
Words that modify nouns are used to determine the attributes that each class should have. As with the relationships, each attribute is traced back to the requirements.
Phrase | Class | Attribute |
---|---|---|
The book components are combined together with a table of contents, index and introduction | CustomizedBook | tableOfContents |
index | ||
introduction | ||
Each customer has a name, ..., login name and password | Customer | name |
loginName | ||
password | ||
A customized book has a ..., price and ... | CustomizedBook | price |
shipping address (including a name and address) | ShippingAddress | name |
A book component has a content, price and ... | BookComponent | content |
price | ||
Each author has a name that uniquely determines the author | Author | name |
Verbs that imply an action rather than just a relationship (as well as verbs that suggest both an action and a relationship) should be represented as operations. Operations were also traced back to the requirements.
Phrase | Class | Operation |
---|---|---|
Customers who log onto the ... site | Customer | login |
The book components are combined ... | CustomizedBook | combineComponents |
Each book is then printed, bound and shipped ... | CustomizedBook | |
bind | ||
ship | ||
The customer may fill their "shopping cart" ... | Customer | addNewCustomizedBook |
removeCustomizedBook | ||
Each customized book matches various book components | Specification | matches |
The class diagram is now drawn so that it has the classes and associations required above.
One must also choose cardinality constraints. For example, the "0..1" constraint on the shippedTo association is the result of the phrase "if different from the customer's address." in the requirements. Here is the diagram without attributes. The cardinality constraints should also be traced back to the requirements. These traces were not shown.
Here is the diagram with attributes. The Address attributes are not specified in the requirements so some reasonable attributes were used.
Finally, here is the diagram with operations.