CH 16 Case Study

16 Case Study
In the preceding chapters, we studied the elements from which schemas

are made up. We followed a bottom-up approach, starting with the basic
elements of entity and relationship types, and then proceeding to more
complex elements until we reached the state transition diagrams and state-
charts.
However, schemas are not defined in this way. In most projects, concep-
tual modeling comprises two main kinds of activity: domain analysis and
use case analysis. In domain analysis, we study and define the existing or
designed domain concepts and their properties. In use case analysis, we
elicit and define the knowledge the system has to know to carry out the
functions required by the use cases.
This chapter illustrates the activities of conceptual modeling by means
of a case study. We define a fragment of the schema of a well-known real-
world information system. The system chosen is osCommerce (for “Open
Source Commerce”), an e-commerce and online-store management soft-
ware program. It is available1 as free software under the GNU General
Public License. osCommerce was started in March 2000 in Germany, and
since then it has been adopted by thousands of stores around the world.
In Sect. 16.1, we show the main concepts of the osCommerce domain,
extracted from the (limited and sometimes imprecise) public documenta-
tion of the system.2 Sections 16.2 to 16.5 focus on a few key use cases in
the four main areas of the system: configuration, administration, customers
and the catalog area. The use cases and the required knowledge have been
extracted from the documentation, experimentation (as a user) with the
standard version of the system and an analysis of its relational database
schema. The interested reader can find the complete up-to-date schema of
the system on the companion website to the book.
1 www.oscommerce.com
2 www.oscommerce.com/solutions/documentation
Conceptual Modeling of Information Systems

Antoni Olivé
Springer Verlag, ISBN 978-3-540-39389-7
Copyright Springer Verlag Berlin Heidelberg 2007
354 16 Case Study
16.1 Main Domain Concepts
Figure 16.1 shows the main concepts in the osCommerce domain. More
details will be given later on.
The products in the store are manufactured by manufacturers, are
grouped into categories, and belong to tax classes.
Products may have attributes. An attribute is an option/value pair, such
as Size/Small, Size/Large, or Color/Yellow. The price of a product varies
depending on the attributes it has.
A customer has one or more addresses. Each address is located in a
country. Moreover, if the country has zones (states or provinces), then the
address must be located in a zone.
A shopping cart contains one or more items (not shown in the figure),
each of which is a quantity of a product with a set of attributes. When a
customer confirms that he wants to buy the contents of his shopping cart,
the system generates an order. An order contains one or more order lines,
each of which is a quantity of a product with a set of attributes.
In the following sections, we refine the above concepts and develop sev-
eral fragments of the structural and behavioral schemas of osCommerce.
16.2 Store Configuration
When osCommerce is installed, the system assigns initial values to a set of

parameters. In most cases, these values must be changed. There are a few
use cases that can be applied to make these changes. In what follows, we
only describe two parts of the initial configuration of the system: the store
data and the minimum values.
16.2.1 Store Data
Figure 16.2 shows the store data used by osCommerce. Store is a constant
entity type that has only one instance, which is created and initialized on
installation. We can ensure that there will be only one instance of Store
with the constraint defined by the following class operation:3
context Store::alwaysOneInstance():Boolean
body: Store.allInstances()->size() = 1
3 For the sake of uniformity, we define all constraints and derivation rules by op-
erations in this chapter.

Antoni Olivé
16.2 Store Configuration 355
Category
*
Manufacturer Option
0..1 *
*
*
* * Attribute
Product
* 1
0..1
*
TaxClass Product
Attribute Value
*
*
OrderLine *
1..*
1
* 1
Order Customer
*
ShoppingCart 1..*
Zone Address
0..1 *
* *
1
1
Country
Fig. 16.1. Main entity and relationship types in the osCommerce domain

Antoni Olivé
356 16 Case Study
Store
{«constant»} Country
0..1 1
name:String [0..1] name:String
owner:String [0..1]
1
eMailAddress:EMail [0..1]
eMailFrom:EMail [0..1]
expectedSortOrder:SortOrder *
expectedSortField:SortField
sendExtraOrderEMail:NameEMail [*] 0..1 0..1 Zone
displayCartAfterAddingProduct:Boolean
name:String
allowGuestToTellAFriend:Boolean
defaultSearchOperator:Operator
storeAddressAndPhone:String [0..1]
showCategoryCounts:Boolean «dataType»
taxDecimalPlaces:Natural EMail
displayPricesWithTax:Boolean
«enumeration» «enumeration» «enumeration» «dataType»

SortOrder SortField Operator NameEMail
ascending productName and name:String
descending expectedDate or eMail:EMail
Fig. 16.2. Fragment of the structural schema dealing with a store and its
localization
To change the initial values, the system administrator starts the use case
Change store data:4
Use case: Change store data

Primary Actor: System administrator
Trigger: The system administrator wants to change the initial values of the store
data.
Main Success Scenario:
1. The system displays the current values of the store data.
2. The system administrator provides a new value for one of the store attributes:
[→ NameChange]
[→ OwnerChange]
[→ ZoneChange]
[→ EMailAddressChange]
[→ EMailFromChange]
4 In this chapter, we document the mapping of use cases to requests by means of

textual references. If not indicated otherwise, the requests are domain event no-
tifications, which we name omitting the suffix Notification.

Antoni Olivé
16.2 Store Configuration 357
0..1 1 Store
DomainEvent StoreEvent
/myStore
NameChange ZoneChange
0..1 1
newName:String [0..1] newZone
Zone
effect()
effect()
Fig. 16.3. Definition of domain event types NameChange and ZoneChange
[→ ExpectedSortOrderChange]
[→ ExpectedSortFieldChange]
[→ SendExtraOrderEMailChange]
[→ DisplayCartAfterAddingProductChange]
[→ AllowGuestToTellAFriendChange]
[→ DefaultSearchOperatorChange]
[→ AddressAndPhoneChange]
[→ ShowCategoryCountsChange]
[→ TaxDecimalPlacesChange]
[→ DisplayPricesWithTaxChange]
3. The system validates that the value is correct.
4. The system saves the new value.
5. The system displays the new values of the store data.
The system administrator repeats steps 2–5 until he is done.
We show only the definitions of the first and third domain events (Fig.
16.3); the others are quite similar. Since these event types change attributes
or associations of the store, it is practical to define the association with
Store in a single place (StoreEvent). In this case, the association is derived.
Given that Store has only one instance, the derivation rule is
context StoreEvent::myStore():Store
body: Store.allInstances()->any(true)
The event effects are

context NameChange::effect()
post: myStore.name = self.newName
context ZoneChange::effect()
post: myStore.zone = self.newZone

Antoni Olivé
358 16 Case Study
«utility»
MinimumValues
firstName:PositiveInteger
lastName:PositiveInteger
dateOfBirth:Boolean
password:PositiveInteger
companyName:Natural
streetAddress:Natural
postCode:PositiveInteger
city:Natural
phone:Natural
Fig. 16.4. Fragment of the structural schema dealing with the minimum values of
some attributes
16.2.2 Minimum Values
osCommerce allows defining a minimum length to be defined for the

string values of some attributes and allows one to specify that some attrib-
utes or associations are either mandatory or optional. Figure 16.4 shows a
few of the minimum values. On installation, the system assumes some ini-
tial values, but they can be changed with the use case Assign minimum
values:
Use case: Assign minimum values

Primary Actor: System administrator
Trigger: The system administrator wants to change the minimum values of some
attributes.
1. The system displays the current minimum values.
2. The system administrator provides a new value for one of the minimum values:
[→ FirstNameMinimumChange]
[→ LastNameMinimumChange]
[→ DateOfBirthOptionalChange]
[→ PasswordMinimumChange]
[→ CompanyNameMinimumChange]
[→ StreetAddressMinimumChange]
[→ PostCodeMinimumChange]
[→ CityMinimumChange]
[→ PhoneMinimumChange]
3. The system validates that the value is correct.
4. The system saves the new value.

Antoni Olivé
16.3 Store Administration 359
5. The system displays the new current minimum values.

The system administrator repeats steps 2–5 until he is done.
We show only the definition of the first domain event (Fig. 16.5); the
others are quite similar. The event effect is
context FirstNameMinimumChange::effect()
post: MinimumValues.firstName = self.newMinimum
DomainEvent
FirstNameMinimumChange
newMinimum:PositiveInteger
effect()
Fig. 16.5. Definition of FirstNameMinimumChange domain event type
16.3 Store Administration
In osCommerce, the products in the store are manufactured by manufac-

turers and are grouped into categories. In the following, we study a few use
cases that are used by the store administrator to define manufacturers,
categories, and products.
16.3.1 Manufacturers
Figure 16.6 shows the schema fragment corresponding to manufacturers.

osCommerce is a multilingual system able to deal with any number of lan-
guages. Languages can be added or deleted as desired by the store. In Fig.
16.6, the association class ManufacturerInLanguage defines that a manu-
facturer may have a different URL in each language, and that the system

Antoni Olivé
360 16 Case Study
Manufacturer
Language
name:String 1..*
*
imagePath:String [0..1] name:String
/added:DateTime {«constant»} code:String
lastModified:DateTime [0..1]
Manufacturer
InLanguage «dataType»
url:URL URL
urlClicked:Natural
lastClick:DateTime [0..1]
Fig. 16.6. Fragment of the structural schema dealing with manufacturers
records the number of times a URL in a language has been clicked and the
last time that it was clicked.5
There are five constraints related to the fragment shown in Fig. 16.6.
The first three are that a Manufacturer is identified by its name, and that a
Language is identified by its name and by its code. Using class operations,
these constraints can be formally defined as follows:
context Manufacturer::nameIsUnique():Boolean
body: Manufacturer.allInstances()->isUnique(name)
context Language::nameIsUnique():Boolean
body: Language.allInstances()->isUnique(name)
context Language::codeIsUnique():Boolean
body: Language.allInstances()->isUnique(code)
osCommerce can only work properly if there is at least one language.
We can define this constraint with the following class operation:
context Language::atLeastOneLanguage():Boolean
body: Language.allInstances()->size() > 0
The last constraint is the rule that each manufacturer must have a URL
in each language. This can be defined with the operation
context Manufacturer::aURLinEachLanguage():Boolean
body:
self.language->size() = Language.allInstances()->size()
The attribute Manufacturer::added is constant and derived. Its deriva-
tion rule is
5 ManufacturerInLanguage is the partial reification of the two common partici-

pants in the three relationship types manufacturer–language–url, manufacturer–
language–urlClicked, and manufacturer–language–lastClick.

Antoni Olivé
context Manufacturer::added():DateTime
body: Now()
where Now() is assumed to be a system operation that gives the current

time.
In the following, we define the three main use cases related to manufac-
turers that can be started by the store administrator: Add/Edit/Delete a
manufacturer:
Use case: Add a manufacturer

Primary Actor: Store administrator
Trigger: The store administrator wants to add a manufacturer.
1. The store administrator provides the details of the new manufacturer:
[→ NewManufacturer].
2. The system validates that the data is correct.
3. The system saves the new manufacturer.
Use case: Edit a manufacturer

Trigger: The store administrator wants to edit a manufacturer.
1. The store administrator selects the manufacturer to be edited.
2. The store administrator provides the new details of the selected manufacturer:
[→ EditManufacturer].
4. The system saves the changes.
Use case: Delete a manufacturer

Trigger: The store administrator wants to delete a manufacturer.
1. The store administrator selects the manufacturer to be deleted.
2. The system warns the store administrator of the number of products linked to
the manufacturer to be deleted.
3. The store administrator confirms that he wants to delete the manufacturer:
[→ DeleteManufacturer].
4. The system deletes the manufacturer and, if requested, changes the status of the
products manufactured by it to “out of stock”.
Figure 16.7 shows the definition of the three domain event types. Exist-
ingManufacturerEvent groups the event types dealing with an existing
manufacturer. ManufacturerURLEvent groups the event types that define
or change the URLs of a manufacturer. Note that the cardinalities of the
ternary association HasURL ensure that the characteristics of the instances

Antoni Olivé
362 16 Case Study
Language
* Manufacturer
HasURL «dataType»
1
url
1 URL
*
*
Existing
Manufacturer
DomainEvent Manufacturer
URLEvent
Event
NewManufacturer EditManufacturer DeleteManufacturer

name:String newName:String deleteProds:Boolean
imagePath:String[0..1] imagePath:String[0..1] effect()
effect() effect()
Fig. 16.7. Definition of domain event types related to manufacturers
of NewManufacturer and EditManufacturer include the URL of the manu-

facturer in each existing language.
The name of a new manufacturer must be different from that of any of
the existing manufacturers. This is captured by the event constraint defined
by the following operation:
context NewManufacturer::nameDoesNotExist():Boolean
body: not Manufacturer.allInstances()->
exists(name = self.name)
Likewise, the new name of an existing manufacturer must be different

from that of any of the other manufacturers. This is captured by the follow-
ing event constraint:
context EditManufacturer::newNameDoesNotExist():Boolean
body:
newName <> self.manufacturer.name implies
not Manufacturer.allInstances()->
exists(name = self.newName)

Antoni Olivé
The effect of a new-manufacturer event is6

context NewManufacturer::effect()
post:
m.oclIsNew() and
m.oclIsTypeOf(Manufacturer) and
m.name = self.name and
m.imagePath = self.imagePath and
Language.allInstances()->
forAll(l|
self.hasURL->select(language=l).url =
m.manufacturerInLanguage->select(language=l).url)
The effect of an edit-manufacturer event is similar:
context EditManufacturer::effect()
post:
manufacturer.name = self.name and
manufacturer.imagePath = self.imagePath and
forAll(l|
self.hasURL->select(language=l).url =
manufacturer.manufacturerInLanguage->
select(language=l).url)
An instance of DeleteManufacturer deletes the corresponding manufac-
turer and, if deleteProds is true, it also changes the status of the products
of the manufacturer to “out of stock” (see Fig. 16.10). Formally,
context DeleteManufacturer::effect()
post deleteManufacturer:
not manufacturer@pre.oclIsKindOf(OclAny)
post changeProductsToOutOfStock:
deleteProds implies
manufacturer@pre.product@pre->
forAll(status = ProductStatus::outOfStock)
16.3.2 Categories
Figure 16.8 shows the schema fragment corresponding to categories. An

instance of the ternary association HasName represents the name of a cate-
gory in a language. The figure shows the three cardinalities of HasName
that can be defined in UML; in this case, the other nine cardinalities are
unconstrained.
An interesting issue here is the identification of categories. None of the
main identification methods studied in Chap. 5 can be used for identifying
the instances of Category. In this case, however, they can be identified by
6 The navigation of n-ary associations assumes that they have been reified. In the
example of Fig. 16.7, it is assumed that there exists an association class named
HasURL.

Antoni Olivé
364 16 Case Study
String
0..1 parent name 1
Category
* imagePath:String [0..1] Language
0..1 *
child sortOrder:Natural name:String
/added:DateTime{«constant»} code:String
lastModified:DateTime [0..1] HasName
Fig. 16.8. Fragment of the structural schema dealing with product categories
means of the instances of HasName. In each language, each category has a

unique name. Therefore, a category may be identified by a language and a
string (a name).
In osCommerce the categories are arranged hierarchically. This con-
straint can be expressed as follows:
context Category::isAHierarchy():Boolean
body: not self.allParents->includes(self)
where allParents() is a helper operation defined as

context Category
def: allParents():Set(Category) =
self.parent->union(self.parent.allParents())
Categories in the same hierarchical level are displayed as indicated by their

sort order.
In the following, we define the main use cases related to categories that
can be started by the store administrator:
Use case: Add a product category

Trigger: The store administrator wants to add a category.
1. The store administrator provides the details of the new product category, includ-
ing its parent category, if any:
[→ NewCategory].
3. The system saves the new category.
Use case: Edit a product category

Trigger: The store administrator wants to edit a category.

Antoni Olivé

1. The store administrator selects the category to be edited.
2. The store administrator provides the new details of the selected category:
[→ EditCategory].
4. The system saves the changes.
Use case: Move a product category

Trigger: The store administrator wants to change the placement of a category in
the category hierarchy.
1. The store administrator selects the category to be moved.
2. The store administrator indicates the new parent category, if any:
[→ MoveCategory].
4. The system saves the new placement.
Use case: Delete a product category

Trigger: The store administrator wants to delete a category.
1. The store administrator selects the category to be deleted.
2. The system warns the store administrator about the number of subcategories
and products linked to the category to be deleted.
3. The store administrator confirms that he wants to delete the category:
[→ DeleteCategory].
4. The system deletes the category, its subcategories, and the products linked to it.
The definitions of the domain event types NewCategory, EditCategory,
MoveCategory, and DeleteCategory are similar to these of the correspond-
ing types for manufacturers. In what follows, we describe only the defini-
tion of NewCategory (see Fig. 16.9).
The name of a new category in a given language must be different from
that of any of the existing categories in that language. This is captured by
the event constraint
context NewCategory::namesDoNotExist():Boolean
body:
Language.allInstances()->forAll(l|
l.hasName.name->
excludes(self.hasNewName->
select(language=l)->any(true).name))
The event effect is

Antoni Olivé
366 16 Case Study
DomainEvent
Language
*
NewCategory HasNew
imagePath:String[0..1]
Name
parent
Category
0..1 * sortOrder:Natural *
effect()
1 name
String
Fig. 16.9. Definition of the domain event type NewCategory
context NewCategory::effect()
post:
c.oclIsNew() and
c.oclIsTypeOf(Category) and
c.imagePath = self.imagePath and
c.sortOrder = self.sortOrder and
c.parent = self.parent and
forAll(l|
self.hasNewName->select(language=l).name =
c.hasName->select(language=l).name)
16.3.3 Products
Figure 16.10 shows the schema fragment corresponding to products. A

product is identified by a name in a language. In each language, product
names are unique. This can be captured by the constraint
context Language::nameUnique():Boolean
body: self.productInLanguage->isUnique(name)
Figure 16.11 shows the schema fragment corresponding to product at-

tributes. An option has a set of values. An attribute is an option/value pair,
such as Size/Small or Color/Yellow. A product attribute is the reification of
the relationship between a product and an attribute. For example, the op-
tion Size may have the values Large, Medium, and Small (i.e. there are
three instances of Attribute), and the product FashionT-Shirt may exist in a

Antoni Olivé
Product
* 0..1
imagePath:String [0..1]
Manufacturer
model:String [0..1]
status:ProductStatus
price:Money * *
Category
quantityOnHand:Integer
quantityOrdered:Natural
/added:DateTime {«constant»} 1..*
*
lastModified:DateTime [0..1] Language
available:DateTime [0..1]
ProductInLanguage
«enumeration»
ProductStatus name:String
inStock description:String [0..1]
outOfStock url:URL [0..1]
viewed:Natural
Fig. 16.10. Fragment of the structural schema dealing with products
«enumeration» HasOptionName
Sign 0..1
plus Option
minus
*
1 name *
Product * * Attribute String Language

1 name *
*
0..1
Product Value
Attribute HasValueName
increment:Money
sign:Sign
Fig. 16.11. Fragment of the structural schema dealing with product attributes

Antoni Olivé
368 16 Case Study
store with the sizes Large and Small (i.e. there are two instances of Pro-
ductAttibute, one between FashionT-Shirt and the attribute Size/Large, and
the other between FashionT-Shirt and the attribute Size/Small).
The identification of Option and Value is similar to that of Product and
Category: in a given language, names are unique. The cardinalities of the
association HasOptionName ensure that each option has a unique name in
a language. Taken together with the rule that there is at least one language,
this guarantees the identifiability of options. Similar considerations apply
to values.
The entity types Attribute and ProductAttribute are identifiable by
means of a compound reference consisting of the two intrinsic relationship
types of their reification.
There are several use cases related to products. In what follows, we de-
scribe only the use case Add a product, which includes the use cases Add
product option and Add product option value.
Use case: Add a product

Trigger: The store administrator wants to add a product to the store catalog.
1. The store administrator selects the product category.
2. The store administrator provides the product data:
[→ NewProduct].
4. The system saves the new product.
5. The store administrator provides a product attribute:
[→ NewProductAttribute].
6. The system validates that the product attribute is correct.
7. The system saves the new product attribute.
The store administrator repeats steps 5–7 until he is done.
Extensions:
5a. The product does not have product attributes:
5a1. The use case ends.
5b. The product option is new:
5b1. Add product option.
5c. The product option value is new:
5c1. Add product option value.
Use case: Add product option

Trigger: The store administrator wants to add a product option to the store cata-
log.

Antoni Olivé

1. The store administrator provides the product option data:
[→ NewProductOption].
3. The system saves the new product option.
Use case: Add product option value

Trigger: The store administrator wants to add a value to a product option.
1. The store administrator selects the product option.
2. The store administrator provides the product option value data:
[→ NewProductOptionValue].
4. The system saves the new product option value.
In the following we describe only the domain event type NewProductAt-

tribute (see Fig. 16.12). An instance of NewProductAttribute cannot add a
product attribute that already exists. This event constraint can be repre-
sented by the constraint operation
context NewProductAttribute::attributeDoesNoExist():Boolean
body:
not self.product.productAttribute->
exists(attribute.value=self.value and
attribute.option = self.option)
Moreover, the option/value pair of the new attribute must be valid. This is
ensured by the event constraint
context NewProductAttribute::optionValueIsValid():Boolean
body: self.option.value->includes(self.value)
DomainEvent
NewProductAttribute 1 Option
1 increment:Money
Product sign:Sign
1
effect() Value
Fig. 16.12. Definition of the domain event type NewProductAttribute

Antoni Olivé
370 16 Case Study
The effect of the event is

context NewProductAttribute::effect()
post:
pa.oclIsNew() and
pa.oclIsTypeOf(ProductAttribute) and
pa.increment = self.increment and
pa.sign = self.sign and
pa.product = self.product and
pa.attribute.option = self.option and
pa.attribute.value = self.value
16.4 Customers
Figure 16.13 shows the fragment of the structural schema corresponding to

customers and addresses. A customer has one or more addresses, one of
which is the primary address. The primary address is the default shipping
and delivery address for the orders placed in the store, and the basis for tax
calculations. Note that Address is a data type. The first and last names in
an address may be different from those of its customer. Each address is lo-
cated in a country. Moreover, if the country has zones, then the address
must be located in a zone whose name is the same as the name of the state,
and the country of the zone must be the same as the country of the address.
This rule is captured by the constraint
context Country::addressesHaveZoneIfNeeded():Boolean
body:
self.zone->notEmpty() implies self.address-> forAll
(a|a.state ->notEmpty() and a.state = a.zone.name and
self = a.zone.country)
Customers are identified by their eMailAddress:
context Customer::eMailIsUnique():Boolean
body: Customer.allInstances()->isUnique(eMailAddress)
There are several use cases related to customers. In what follows, we

describe only the use case Create customer; this is included in the use case
Place order, which we shall discuss in the next section.
Use case: Create customer

Primary Actor: Customer
Trigger: The customer wants to open an account in the store.
1. The customer provides the required customer data:
[→ NewCustomer].
2. The system validates the customer data.
3. The system saves the customer data.

Antoni Olivé
16.4 Customers 371
«dataType»
Customer Address
gender:Gender [0..1] gender:Gender [0..1]
firstName:String firstName:String
lastName:String * 1..* lastName:String
dateOfBirth:Date [0..1] {ordered} company:String [0..1]
eMailAddress:EMail street:String [0..1]
phone:String [0..1] suburb:String [0..1]
fax:String [0..1] * 1 postCode:String
newsletter:Boolean [0..1] primary
city:String [0..1]
{subsets address}
password:String state:String [0..1]
lastLogon:DateTime [0..1]
numberLogons:Natural {«constant»} * {«constant»} *
/added:DateTime{«constant»}
0..1
lastModified:DateTime [0..1]
Zone
«enumeration»
Gender * 1
male 1
female
Country
Fig. 16.13. Fragment of the structural schema dealing with customers and
addresses
Figure 16.14 shows the definition of NewCustomer. The instances of

this domain event type must satisfy several constraints. The first constraint
is similar to some others that we have seen before: there cannot exist a cus-
tomer with the same email address:
context NewCustomer::eMailDoesNotExist():Boolean
body: not Customer.allInstances()->
exists(eMailAddress = self.eMailAddress)
The second constraint ensures that the password is the same as the pass-
word confirmation:
context NewCustomer::passwordCorrect():Boolean
body: password = pwConfirmation
The other constraints guarantee that the attributes of NewCustomer satisfy

the minimum requirements stated by the system administrator; see Fig.
16.4 again. These are the following:
context NewCustomer::firstNameRight():Boolean
body: primary.firstName.size() >= MinimumValues.firstName
context NewCustomer::lastNameRight():Boolean
body: primary.lastName.size() >= MinimumValues.lastName

Antoni Olivé
372 16 Case Study
DomainEvent
NewCustomer
primary:Address
dateOfBirth:Date [0..1]
eMailAddress:EMail
phone:String [0..1]
fax:String [0..1]
newsletter:Boolean [0..1]
password:String
pwConfirmation:String
effect()
Fig. 16.14. Definition of the domain event type NewCustomer
context NewCustomer::dobRight():Boolean
body:
MinimumValues.dateOfBirth implies dateOfBirth->notEmpty()
context NewCustomer::companyRight():Boolean
body:
MinimumValues.companyName > 0 implies
primary.company->notEmpty() and
primary.company.size()>= MinimumValues.companyName
context NewCustomer::streetRight():Boolean
body:
MinimumValues.streetAddress > 0 implies
primary.street->notEmpty() and
primary.street.size() >= MinimumValues.streetAddress
context NewCustomer::postCodeRight():Boolean
body: primary.postCode.size()>= MinimumValues.postCode
context NewCustomer::cityRight():Boolean
body:
MinimumValues.city > 0 implies
primary.city->notEmpty() and
primary.city.size() >= MinimumValues.city
context NewCustomer::phoneRight():Boolean
body:
MinimumValues.phone > 0 implies
phone->notEmpty() and
phone.size() >= MinimumValues.phone
The effect of an instance of NewCustomer is

Antoni Olivé
16.5 Online Catalog 373
context NewCustomer::effect()
post:
c.oclIsNew() and
c.oclIsTypeOf(Customer) and
c.gender = primary.gender and
c.firstName = primary.firstName and
c.lastName = primary.lastName and
c.dateOfBirth = dateOfBirth and
c.eMailAddress = eMailAddress and
c.phone = phone and
c.fax = fax and
c.newsletter = newsletter and
c.password = password and
c.numberLogons = 0 and
c.primary = primary and
c.address = Set{primary}
16.5 Online Catalog
The online catalog includes the use cases that may be started by the cus-
tomers of the store. In the following, we describe the most important use
case (Place an order) and a query.
16.5.1 Shopping Carts
Figure 16.15 shows the fragment of the schema corresponding to shopping

carts. A shopping cart is anonymous until the customer logs in: at this
moment it becomes a customer shopping cart. If a customer leaves a ses-
sion with a nonempty shopping cart, then the cart will be automatically re-
stored in his next session. Anonymous shopping carts can exist only in the
context of a session, and they are automatically removed when the session
expires. If a customer shopping cart exists in the context of a session then
its customer is the same as the customer of the session. This is captured by
the constraint
context CustomerShoppingCart::sameCustomer():Boolean
body: self.session.customer = self.customer
A shopping cart contains a sequence of one or more items, each of

which is a quantity of a product. If the product has attributes (Fig. 16.11),
then the shopping-cart item specifies one attribute for each option that the
product has. For example, if the product has one or more values for the op-
tion Size, then each shopping-cart item of that product specifies one and
only one value for Size (for example, Small). These constraints can be rep-
resented by the following two operations:

Antoni Olivé
374 16 Case Study
Shopping
CartItem
1
0..1 0..1 {«constant»} quantity:
Session ShoppingCart PositiveInteger
1..*
{ordered} /added:Date
0..1 1 {redefines
session} {«constant»}
* *
{disjoint,complete} {«constant»} {«constant»}
Product
Anonymous Customer
ShoppingCart ShoppingCart *
0..1 {«constant»} 0..1
1 Attribute
Customer
Fig. 16.15. Fragment of the structural schema dealing with shopping carts
context ShoppingCartItem::productHasTheAttributes():Boolean
body: product.attribute->includesAll(attribute)
context ShoppingCartItem::onlyOneAttributePerOption():Boolean
body: self.attribute->isUnique(option)
The creation and updating of a shopping cart are part of the use case
Place an order, which we shall describe in the next section. However, we
shall define here two main domain event types and one action request type,
shown in Fig. 16.16.
The domain event type RemoveProduct removes a shopping-cart item
from its shopping cart. Its effect is
context RemoveProduct::effect()
post: not shoppingCartItem@pre.oclIsKindOf(OclAny)
This postcondition ensures that the removed shopping-cart item will not
exist in the new state of the information base (i.e. after the execution of the
effect operation). Moreover, if the shopping cart has only one item, the
shopping cart will be removed as well (why?).
The domain event type ChangeQuantity changes the quantity of a shop-
ping-cart item. Formally, its effect is
context ChangeQuantity::effect()
post: shoppingCartItem.quantity = self.quantity

Antoni Olivé
DomainEvent
ActionRequest
Remove
«dataType»
Product
«create»
LineChange Update
effect()
1..* ShoppingCart
remove:Boolean {ordered}
quantity: effect() Change
«create»
PositiveInteger Quantity
quantity:
PositiveInteger
effect()
1 1
Session ShoppingCart
1 1
Shopping
CartItem
Fig. 16.16. Definition of the action request type UpdateShoppingCart and the
domain event types RemoveProduct and ChangeQuantity
osCommerce allows customers to remove and/or change the quantity of

several items in a single use case step. We could define this change as a
single domain event type, but if we already have (or will need) Re-
moveProduct and ChangeQuantity then it is better to define that change as
an action request type. This is what we have done in Fig. 16.16.
An instance of UpdateShoppingCart creates several instances of Re-
moveProduct and ChangeQuantity, as specified by its LineChange. In the
request, there must be a line change for each shopping-cart item. Formally,
this is an event constraint defined as
context UpdateShoppingCart::complete():Boolean
body: lineChange->size() =
shoppingCart.shoppingCartItem->size()
The effect is

Antoni Olivé
376 16 Case Study
context UpdateShoppingCart::effect()
post:
lineChange->forAll
(lc|let cartItem:ShoppingCartItem =
shoppingCart.shoppingCartItem->
at(lineChange->indexOf(lc))
in
(lc.remove or lc.quantity <> cartItem.quantity)
implies
if lc.remove then
rp.oclIsNew() and
rp.oclIsTypeOf(RemoveProduct) and
rp.shoppingCartItem = cartItem
else
cq.oclIsNew() and
cq.oclIsTypeOf(ChangeQuantity) and
cq.shoppingCartItem = cartItem and
cq.quantity = quantity
endif))
16.5.2 Orders
When the customer confirms that he wants to buy the contents of his shop-
ping cart, the system generates an order. Figure 16.17 shows the schema
fragment corresponding to orders.
Orders are identified by their attribute id, which is assigned automati-
cally when the order is created. The derivation rule is
context Order::id():PositiveInteger
body:
if Order.allInstances()->size() = 0 then 0
else
Order.allInstances()->
sortedBy(id)->last().id + 1
endif
Each order has a status. Initially the status is pending, but it may change
later on. Each change is represented by an instance of OrderStatusChange.
The derived attribute Order::status gives the current status of the order.
The derivation rule is
context Order::status():OrderStatus
body: orderStatusChange->sortedBy(added)->last()
The primary address of an order is that of its customer when the order is
created. This is captured by a creation-time derivation rule with the defin-
ing operation
context Order::primary():Address
body: customer.primary
The attributes eMailAddress and phone are defined similarly.

Antoni Olivé
Customer Product
1 1
* {«constant»} * {«constant»}
OrderLine
Order
{«constant»}
1
/id:PositiveInteger{«constant»} {«constant»} /name:String
/primary:Address {«constant»} 1..* /model:String [0..1]
billing:Address {«constant»}
{ordered} /price:Money
delivery:Address {«constant»} /finalPrice:Money
/eMailAddress:EMail {«constant»} quantity:PositiveInteger
/phone:String [0..1] {«constant»} 1
/purchased:DateTime {«constant»} {«constant»}
/lastModified:DateTime [0..1]
/status:OrderStatus *
/total:Money {«constant»} OrderLine
1 Attribute
{«constant»}
1..* {«constant»}
/option:String
OrderStatus /value:String
Change «enumeration» /increment:Money
{«constant»} OrderStatus /sign:Sign
status:OrderStatus pending * {«constant»}
/added:DateTime processing
comments:String delivered 1
Attribute
Fig. 16.17. Fragment of the structural schema dealing with orders
The derived attribute Order::total gives the total amount of an order. We

shall ignore the shipping costs and taxes here. The derivation rule is then
context Order::total():Money
body: orderLine->collect(finalPrice*quantity)->sum()
The final price of an order line is the price of the product plus or minus
the increments of its attributes. The derivation rule is

Antoni Olivé
378 16 Case Study
context OrderLine::finalPrice():Money
body:
if orderLineAttribute->isEmpty() then price
else
orderLineAttribute->collect
(if sign = Sign::plus then increment
else –increment
endif)->sum() + price
endif
Note that all attributes of OrderLine, OrderLineAttribute, and Order-

StatusChange, as well as most of Order, are constant.
There are a few use cases that deal with shopping carts and orders. We
describe the most important of them, Place an order, below:
Use case: Place an order

Primary Actor: Customer
Precondition: None.
Trigger: The customer wants to place an order.
1. At any time before step 10 the customer logs in:
[→LogIn].
The system adds the contents of the anonymous shopping cart to the customer
shopping cart.
2. The system displays the contents of the shopping cart.
3. The customer browses the product catalog.
4. The customer selects a product to buy:
[→AddProductToShoppingCart].
5. The system adds the product to the shopping cart.
6. The system displays the contents of the shopping cart.
7. The customer changes the contents of the shopping cart:
[→UpdateShoppingCart].
8. The system updates the shopping cart.
9. The system displays the contents of the updated shopping cart.
The customer repeats steps 3, 4 and 7 as necessary to build his order.
10. The customer checks out the order.
11. The system shows the shipping address and the shipping methods available.
12. The customer selects the preferred shipping method.
13. The system shows the billing address and the payment methods available.
14. The customer selects the preferred payment method.
15. The system displays a summary of the order.
16. The customer confirms the order:
[→OrderConfirmation].
17. The system saves the order.
Extensions:
1a. The customer is new:
1a1. Create customer.
16a. The customer wants to change the contents of the shopping cart:

Antoni Olivé
16a1. The customer changes the contents of the shopping cart:

[→UpdateShoppingCart].
16a2. The customer continues with the checkout procedure at step 11.
11a, 16a. The customer wants to change the shipping address:
11a1. The system shows the known addresses of the customer.
11a2. The customer selects a different shipping address.
13a, 16b. The customer wants to change the billing address:
13a1. The system shows the known addresses of the customer.
13a2. The customer selects a different billing address.
16c. The customer wants to change the shipping method:
16c1. The customer selects the new shipping method.
16c2. The customer continues with the checkout procedure at step 13.
16d. The customer wants to change the payment method:
16d1. The customer selects the new payment method.
16d2. The customer continues with the checkout procedure at step 15.
11a2a,16a2a. The customer wants to define a new shipping address:
11a2a1. The customer gives the new address:
[→NewAddress].
11a2a2. The system saves the new address.
11a2a3. The customer continues with the checkout procedure at step 11.
13a2a,16b2a. The customer wants to define a new billing address:
13a2a1. The customer gives the new address:
[→NewAddress].
13a2a2. The system saves the new address.
13a2a3. The customer continues with the checkout procedure at step 13.
DomainEvent
OrderConfirmation
Customer 1 delivery:Address
ShoppingCart shopping billing:Address
Cart comments:String
effect()
Fig. 16.18. Definition of the domain event type OrderConfirmation

Antoni Olivé
380 16 Case Study
In this use case, the most important domain event is OrderConfirma-

tion, shown in Fig. 16.18. We omit here the shipping and payment meth-
ods. The intended effect is as follows:
context OrderConfirmation::effect()
post theOrderIsCreated:
o.oclIsNew() and
o.oclIsTypeOf(Order) and
o.customer = shoppingCart@pre.customer@pre and
o.billing = billing and
o.delivery = delivery and
osc.oclIsNew() and
osc.oclIsTypeOf(OrderStatusChange) and
--The initial status of the order is pending
osc.status = OrderStatus::pending and
osc.comments = comments and
o.orderStatusChange = Set{osc} and
--There is an order line for each shopping cart item
shoppingCart@pre.shoppingCartItem@pre->forAll
(i|OrderLine.allInstances()->one
(ol|ol.order = o and
ol.product = i.product@pre and
ol.quantity = i.quantity@pre and
i.attribute@pre->forAll
(iAtt|OrderLineAttribute.allInstances()->one
(olAtt|olAtt.orderLine = ol and
olAtt.attribute = iAtt))))
post theShoppingCartIsRemoved:
not shoppingCart@pre.oclIsKindOf(OclAny)
post updateProductQuantities:
let productsBought:Set(Product) =
shoppingCart@pre.shoppingCartItem@pre.product@pre
->asSet()
in productsBought->forAll(p|
let quantityBought:PositiveInteger =
shoppingCart@pre.shoppingCartItem@pre->select
(product = p).quantity->sum()
in p.quantityOnHand =
p.quantityOnHand@pre-quantityBought and
p.quantityOrdered =
p.quantityOrdered@pre + quantityBought)
16.5.3 Show Previous Orders
osCommerce includes many predefined queries that can be requested by

users in several use case steps and as a standalone use case. As an exam-
ple, we describe here the query ShowPreviousOrders, shown in Fig. 16.19.
The answer to an instance of ShowPreviousOrders is given in attribute an-
swer, whose type is the complex type:

Antoni Olivé
Query
Show
PreviousOrders
1 *
Customer answer
effect()
Fig. 16.19. Definition of the query ShowPreviousOrders
Set(TupleType(date:Date,
id:Natural,
name:String,
country:String,
status:OrderStatus,
total:Money))
The answer is given by the effect operation
context ShowPreviousOrders::effect()
post:
answer =
customer.order->collect(o|
Tuple{date = o.purchased.date,
id = o.id,
name = o.delivery.firstName.
concat(o.delivery.lastName),
country = o.delivery.country.name,
status = o.status,
total = o.total})->asSet()

Antoni Olivé
Antoni Olivé

CH 16 Case Study

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CH 16 Case Study

Uploaded by

Copyright:

Available Formats

16 Case Study

In the preceding chapters, we studied the elements from which schemas

Conceptual Modeling of Information Systems

16.1 Main Domain Concepts

16.2 Store Configuration

When osCommerce is installed, the system assigns initial values to a set of

16.2.1 Store Data

Conceptual Modeling of Information Systems

Conceptual Modeling of Information Systems

«enumeration» «enumeration» «enumeration» «dataType»

Use case: Change store data

4 In this chapter, we document the mapping of use cases to requests by means of

Conceptual Modeling of Information Systems

Fig. 16.3. Definition of domain event types NameChange and ZoneChange

The event effects are

Conceptual Modeling of Information Systems

16.2.2 Minimum Values

osCommerce allows defining a minimum length to be defined for the

Use case: Assign minimum values

Conceptual Modeling of Information Systems

5. The system displays the new current minimum values.

Fig. 16.5. Definition of FirstNameMinimumChange domain event type

16.3 Store Administration

In osCommerce, the products in the store are manufactured by manufac-

Figure 16.6 shows the schema fragment corresponding to manufacturers.

Conceptual Modeling of Information Systems

Fig. 16.6. Fragment of the structural schema dealing with manufacturers

5 ManufacturerInLanguage is the partial reification of the two common partici-

Conceptual Modeling of Information Systems

where Now() is assumed to be a system operation that gives the current

Use case: Add a manufacturer

Use case: Edit a manufacturer

Use case: Delete a manufacturer

Conceptual Modeling of Information Systems

NewManufacturer EditManufacturer DeleteManufacturer

Fig. 16.7. Definition of domain event types related to manufacturers

of NewManufacturer and EditManufacturer include the URL of the manu-

Likewise, the new name of an existing manufacturer must be different

Conceptual Modeling of Information Systems

The effect of a new-manufacturer event is6

Figure 16.8 shows the schema fragment corresponding to categories. An

Conceptual Modeling of Information Systems

means of the instances of HasName. In each language, each category has a

where allParents() is a helper operation defined as

Categories in the same hierarchical level are displayed as indicated by their

Use case: Add a product category

Use case: Edit a product category

Conceptual Modeling of Information Systems

Main Success Scenario:

Use case: Move a product category

Use case: Delete a product category

The event effect is

Conceptual Modeling of Information Systems

Fig. 16.9. Definition of the domain event type NewCategory

Figure 16.10 shows the schema fragment corresponding to products. A

Figure 16.11 shows the schema fragment corresponding to product at-

Conceptual Modeling of Information Systems

Fig. 16.10. Fragment of the structural schema dealing with products

Product * * Attribute String Language

Conceptual Modeling of Information Systems

Use case: Add a product

Use case: Add product option