Chapter 6

Conceptual Modeling: Patterns

KEY TOPICS IN THIS CHAPTER
1. High cohesion
2. Specification classes
3. Quantity
4. Measure
5. Strategy
6. Composite
7. Organizational hierarchy
8. Account/transaction
9. Range
10. Temporal patterns
High cohesion
•High cohesion is so important for object-oriented
modeling that it is considered more a principle or
guideline axiom than a pattern itself
•A concept with high cohesion is more stable and
reusable than a concept with low cohesion, which
can become rapidly confusing and hard to maintain
Continue
•Most systems could have all their information represented in
a single table
•concepts should not have attributes that belong to other
concepts
•e.g., a car should not have the owner’s ID as one of its
attributes
•Attributes also must not have
class names or data structures (set, list, array, etc.) as data
types
Low cohesion
•a class with that kind of attribute is probably
representing more than one single concept
•For example, an instance of Order should not have
an itemsList attribute because items have their own
attributes and associations; they should appear
related to Order by a 1 to *
association
Customer address
•When it was discovered that a customer
could have more than one address,
instead of the naive solution of creating
attributes like address1, address2, etc.
•we created a new concept (Address),
which was associated to the customer.
A class with low cohesion because attributes depend on each other

A modeling solution with high-cohesion classes.

A class with low cohesion because it has attributes that repeat values in different instances.

A model for the example with high-cohesion classes.

Specification classes
A special case of low cohesion happens when
an object is confused with its specification.
That situation is very frequent: sometimes,
products or physical items share a common
specification, while their exemplars may have
some differences among them
One example of specification already
discussed in the Livir example is the
difference between the concept of a
book as a published title, and a book as a
physical copy of a published title.
A class and its specification class.
•Conservation State
1. new,
2. used,
3. damaged
Quantity
•Frequently the team faces the need to model
quantities that are not merely numbers
•For example, The weight of a book could be
defined as 400. But 400 what? Grams?
Pounds? Kilos? One solution is to define a
specific type for the weight (Pounds, for
example)
Definition and use of Quantity
Measure
•An evolution of the quantity pattern is
the measure pattern, which can be used
when a number of different measures
over an object must be taken possibly at
different times
For example, a person in observation at a
hospital may have many measures taken
from time to time: body temperature,
blood pressure, blood glucose level , etc.
•Thousands of different measures could
be taken, but usually just a few are
actually taken for each patient
Definition and use of the measure pattern.
Strategy
•It was mentioned that one of the great
requirements challenges is to manage their
change
•Transitory requirements must especially be
accommodated in the system design so that
when they change the impact to the system,
is minimized
•Some cases are relatively easy to address.
For example, if it is already decided that the
system must operate in different countries,
the quantity pattern could be used to deal
with currency and other measures that may
vary from country to country
•But there are much more complicated situations.
For example, the tax calculation procedure may
vary a lot from country to country and even from
state to state in some countries.
•There are some taxes that are calculated in
relation to the profit, others with regard to the
selling price, and so on
•The strategy pattern suggests that in
these cases, the procedure (e.g.,
calculate taxes or discount) must be
separated from the data to which it
applies
•The solution proposed by the strategy
pattern is to create an abstract class
associated to the order. This abstract
class may have concrete subclasses that
represent concrete discount policies, as
shown in Figure
Strategy pattern
Composite
•sometimes different strategies must be grouped
and a combination or selection of them must be
applied
•The combination of different discount strategies
can be obtained, for example, by the sum of the
values obtained for the derived attribute amount
for each individual strategy, or by choosing the
highest or lowest values among them
Organizational hierarchy
•represent organizational hierarchies
•represent the administrative
organization of a company as a
composition hierarchy
•First fig usually do not behave well
1. this kind of organization is not followed by
every company
2. the company structure may change over time
3. different views of an organization may exist
at the same time
•The solution consists of not considering
the different levels of an organization as
concepts, but
•as instances of a single concept, as
shown in fig 2
1. flexibility is gained related to dealing
simultaneously with organizational
structures from different companies
2. eventual changes in the organizational
structure, such as adding more levels, or
changing dependencies, may be easier to
accomplish
Object joining
•One of the team’s assumptions that usually
fails is that users will do everything right
•A user could, for example, register a new
publisher in the system, and later discover
that it was already registered
•Entering an incorrect code or the
impossibility of having a unique
identification for a real world object may
cause this situation
•The result is that two objects are
registered in the system, both
representing the same publisher, and
each of them may possibly have its own
set of books associated, some repeated,
some not
solution
•The solution when this kind of error
happens is to join the objects, usually
copying one over the other
•This operation can be performed directly
within the database or a user feature
solution
•Copy and replace
•Superseding
•Essence/Appearance
•Undoing a join
Copy and replace

•The first strategy that comes to mind

when it is necessary to join two objects
consists of copying the data of one
object over the second (copy and
replace)
Superseding
•Superseding is a technique that can be
used when the original object must be
kept and not destroyed. Superseding is
applicable, for example, in the case of
organizational structures that are
succeeded in time.
•Suppose that the departments of marketing and sales
are joined into a single
•department of customer contact; the original
departments must be marked as no longer active, and
•a new department must be added as their successor.
The superseding strategy may be implemented
•by a reflexive association, as shown in Figure
Essence/Appearance
•existence of objects that are considered
equivalent but must be kept as
separated objects
•same book in essence: published by
different publishers
Essence/Appearance technique.
Undoing a join
•Just when you think that the real world
cannot be more complex, it becomes so.
Therefore, if there is a possibility of
joining objects, it is also possible that
joined objects must be separated again
•these commands may be performed directly in
the database, or system’s user interface
•To allow the joins of the copy/replace technique
to be undone, a backup of the original objects
must be kept, because the technique destroys
one of the objects and disfigures the other
Account/Transaction
•The account/transaction pattern is closely
related to business, but it has wide
applicability
•The books may be cataloged, ordered,
received, delivered, discarded, etc.
•each one with its own attributes and
associations
•it is possible to identify a common core
for all these concepts
Definition of Account
•An Account is a concept that bears
quantities of something (such as items,
products, or money).
•An Account has a balance that usually
consists of the sum of every deposit or
withdrawal
•deposits and withdrawals are usually
just entries of goods or money from an
account to another
•a Transaction consists of two entries: a
deposit in one account and a withdrawal
of the same value in another account.
Classes for the account/transaction pattern.
•bookstore example could be modeled from a set of instances of class
Account, such as
1. publisher Account
2. account for orders expected
3. account for stock containing the available books
4. account for sold books containing books sold but not yet delivered
5. account for delivered books containing books delivered but not yet
confirmed by the
customer
Temporal patterns
•Frequently the analyst faces the need to
deal with time.
1. Effectivity
2. History
3. Temporal
4. Bitemporal
Effectivity
•When an object is valid for some time (for
example, a temperature measure, which
has a time it was taken and a time it is
considered valid), then the effectivity
pattern may be used. It consists of
declaring an effective attribute in the class
History
•If historical information has to be stored
about the past states of an association,
then the history association pattern may
be used. This kind of association may be
identified by the stereotype <<history>>
An example of the history association pattern.

Concrete model for the <<history>> stereotype.

Temporal
•The history association pattern is not capable
of answering what the job of a person was at
a given date, or if a person was unemployed
in the past. In order to represent that kind of
information, an evolution of that pattern may
be used: an association that in addition to
sequential memory also has time memory
 A temporal association.

A possible implementation of the <<temporal>> stereotype.

Bitemporal
•Time may be considered two-
dimensional.
There is a dimension of time in which
events occur and another dimension
where we acknowledge that an event
occurred.
 A bitemporal association.

A model that implements the bitemporal pattern.

End of Chapter