Transcript Here is the real deal

ORM2 Perspectives:
Objectification, Modality, and Tooling
Terry Halpin
Neumont University
[email protected]
www.orm.net
© 2006, T. A. Halpin
1
Contents
 Objectification
–
–
–
–
–
–
Objectification in ORM, UML, and ER
Two Kinds of Nominalization
Objectification and Composite Reference Schemes
Objectification of Unary Facts
Objectification of Fact Types with Non-spanning UCs
Propositional Nominalization and Communication Acts
 Business Rule Modality
–
–
–
–
Introduction
Modal Operators and Rule verbalization
Embedded, Static Rules
Dynamic Rules
 NORMA Tool Demo/Discussion
2
Objectification in ORM, UML, and ER
Roughly speaking, objectification (a.k.a. nesting),
treats a relationship instance as an object in its own right,
so it may be talked about like any other object.
ORM example
(ORM 2 notation):
“Playing !”
Country
(code)
plays
Sport
(name)
is at
AU
AU
NZ
US
cricket
tennis
cricket
tennis
Rank
(nr)
(AU, cricket) 1
(AU, tennis) 4
(US, tennis) 1
3
UML usually calls this reification,
allowing association instances to be objectified
as instances of an association class.
Unfortunately the name of the association class must match
the name of the association (whether displayed or not).
UML example, augmented by non-standard notation
for preferred identification scheme “{P}” :
Country
*
*
code {P}
Sport
name {P}
Playing
rank [0..1]
4
Industrial Entity Relationship Modeling (ER)
(e.g. IE, IDEF1X, Barker ER) does not support objectification at all.
Some academic versions of ER do support objectification,
typically with restrictions
(e.g. objectified relationships may have attributes
but not play in other relationships)
Example in Elmasri-Navathe ER notation
(unable to specify attribute optionality):
COUNTRY
CountryCode
M
PLAYS
Rank
N
SPORT
SportName
5
Two Kinds of Nominalization
Nominalization replaces a declarative sentence by a noun phrase,
enabling the nominalized object to be referenced like any other object.
Two basic kinds of nominalization may be distinguished:
• Situational
-- nominalized object is a state of affairs/event/activity
• Propositional -- nominalized object is a proposition
Elvis sang the song ‘Hound Dog’.
-- original proposition
Elvis’s singing of the song ‘Hound Dog’ is popular. -- actual state of affairs
That Elvis sang the song ‘Hound Dog’ is well known. -- true proposition
That Elvis sang the song ‘Hound Dog’ is debatable. -- false proposition
6
It’s snowing outside.
-- original proposition
It’s true that it’s snowing outside.
-- proposition
That snowing is beautiful.
-- state of affairs
In ordinary speech, “fact” (i.e. fact instance)
often means “true proposition”.
ORM uses “fact” in the weaker sense of
“proposition taken to be true”
(epistemic commitment by users in the business being modeled)
7
Consider an object instance resulting from the objectification to Playing,
e.g. Australia’s playing of cricket.
(a)
(b)
“Playing !”
Country
(code)
plays
Sport
(name)
cricket
tennis
cricket
tennis
*
*
code {P}
is at
AU
AU
NZ
US
Country
Rank
(nr)
(AU, cricket) 1
(AU, tennis) 4
(US, tennis) 1
Sport
name {P}
Playing
rank [0..1]
Is this object a state of affairs/event/activity
or is it a proposition?
Australia’s playing of cricket is at rank 1.
Makes sense if playing is an activity, but not if it’s a proposition.
Australia’s playing of cricket is true.
-- Nonsense.
8
This is typical of objectification examples in information models.
“Objectified relationships” are typically states of affairs
in 1:1 correspondence with the
relationships (facts in the ORM sense)
that they objectify,
but are not identical with those facts.
So we reject this aspect of the UML metamodel,
where AssociationClass is a subclass of Association and Class.
9
Objectification and
Composite Reference Schemes
To facilitate conceptual declaration of business rules
(constraints or derivation rules) and queries on information models
ORM includes (implicitly or explicitly) link fact types
to support navigation between
the objectification result and the objects in the fact being objectified.
is at
“Playing !”
Country
(code)
<< is by
Rank
(nr)
Sport
(name)
plays
is of
10
Default readings are assigned for link predicates,
e.g.
involves1
Company
(name)
<< involves2
is friendly
“Acquisition !”
The modeler
may assign
better readings,
e.g.
acquired
was by
Company
(name)
<< is of
is friendly
“Acquisition !”
acquired
11
ORM 2 supports multiple predicate readings and role names
whose screen or print display may be suppressed individually.
[acquisitionBySelf]
was acquired in
[acquisitionOfSelf]
Company
[acquirer] (name) [target]
was by /
was acquirer in
<< is of
“Acquisition !”
was friendly
acquired
[acquirer] [target]
Microsoft
Microsoft
Visio
Visio
Navision
InfoModelers
ORM 2 allows rules and navigation paths to be declared in
• relational style
-- using predicate names
• attribute style
-- using role names
• mixed style
-- using both
12
ORM 2 allows
objectification
to be displayed
in this way
but interprets this as
shorthand for:
Asserting the
equality constraint
is the critical step
in treating this
as objectification.
is at
Rank
(nr)
“Playing !”
Country
(code)
plays
is of
<< is by
Country
(code)
Sport
(name)
plays
Sport
(name)
<< is by
<< is of
Playing !
is at
Rank
(nr)
13
ORM 2 allows role sequences participating in constraints
to be disambiguated by role sequence numbers
whose display may be toggled on/off.
Country
(code)
<< is by
plays
1.1
1.2
2.1
Sport
(name)
2.2
Playing !
is at
<< is of
Rank
(nr)
14
Country
(code)
<< is by
plays
1.1
1.2
2.1
Sport
(name)
2.2
Playing !
<< is of
is at
Rank
(nr)
This model may be arrived at in different ways, e.g.
(1) Start with the fact type Country plays Sport,
then objectify it as Playing.
(2) Start with the fact types Playing is by Country and Playing is of Sport,
then define Country plays Sport as fully derived from them.
(3) Start with the 3 fact types Country plays Sport, Playing is by Country,
and Playing is of Sport, then assert the equality constraint.
15
These 3 ways may be formalized as equivalences thus:
E1: x [Playing x  y:Country z:Sport (x is by y & x is of z & y plays z)]
E2: x:Country y:Sport [x plays y  z:Playing (z is by x & z is of y)]
E3: x:Country y:Sport z:Playing [x plays y  (z is by x & z is of y)]
Regardless of which way is used to arrive at the model,
the same basic structure is used to capture the model in the metamodel,
and the same basic mapping procedures are used to transform it
to implementation targets (e.g. Rmap, Omap, Xmap) -- under development
ORM 2 includes a formal, high level textual language
for all its graphical rules as well as additional business rules
e.g. the derivation rule E2 may be rendered as:
Country plays Sport iff
some Playing is by Country and is of Sport.
16
Objectification of Unary Facts
ORM previously forbad objectification of unary facts.
For ORM 2, we removed this restriction,
by extending the previous analysis to
objectified types with simple reference schemes.
Consider the unary fact:
The President named ‘Abraham Lincoln’ died.
We may objectify this event using the nominalization “that death”,
and declare the following additional fact:
That death occurred in the Country with country code ‘US’.
17
“Death !”
President
(name)
Abraham Lincoln
Ronald Reagan
George W. Bush
died
occurred in
Abraham Lincoln
Ronald Reagan
Country
(code)
Abraham Lincoln US
Ronald Reagan US
AU
CA
US
...
The schema is interpreted as shorthand for:
died
President
(name)
Death !
met / is of
occurred in
Country
(code)
18
The earlier analysis for objectification
may now be generalized
by allowing the arity to be unrestricted (1 or more)
and the reference scheme to be simple or composite.
The result of objectifying a relationship type
may be viewed as
an entity type that has a reference scheme
whose reference projection
bears an equality constraint
to the fact type being objectified.
19
FCO-IM also supports objectification of unaries,
but in a very different way and for a different purpose.
FCO-IM uses defines non-lexical objects
as objectifications of roles played by lexical objects, e.g.
Country
CountryCode
refers to a country
While this approach is interesting, and is supported by two
Dutch tools (CaseTalk and Infagon),
this seems to conflate reference with referent,
and to make it awkward to deal with multiple inheritance,
context-dependent reference, and changes to reference schemes.
20
Objectification of Fact Types
with Non-spanning UCs
Previously, ORM allowed an association to be objectified only if either
• it has just one uniqueness constraint, and this spans all its roles,
• or it is a binary 1:1 association.
This restriction forbids objectification of 2 kinds of associations:
•
•
An n:1 (or 1:n) binary association;
A ternary or longer association whose longest uniqueness constraint
spans exactly n – 1 roles.
The above cases are allowed in UML, and those academic versions
of ER that support objectification.
ORM 2 allows these cases, subject to modeling guidelines.
21
Usually, objectifying an n:1 association is just bad modeling,
e.g.
consider this Elmasri-Navathe ER example1:
AIRPORT
1
DEPARTS
N
LEG
INSTANCE
DepTime
It’s simpler to remodel the departure time
as an attribute of just LegInstance.
1
Example from Elmasri, R. & Navathe, S. 1989, Fundamentals of Database Systems,
Benjamin/Cummings Publishing, Figure 3.18, p. 63.
22
“Birth”
To support this
kind of example
in ORM 2
(whether or not
it is the best way to
model)
we interpret
the schema thus:
The 1:1 nature of the
left-hand link fact
type avoids
denormalization on
Rmapping.
GovtHead
(name)
Country
(code)
was born in
Bill Clinton
US
George W. Bush US
John Howard
AU
GovtHead
(name)
was born in
has
/is of
Country
(code)
<< is in
Birth
23
For objectification, mandatory constraints are needed on all link roles
of the objectified type.
e.g. if we remove a mandatory role constraint as shown below,
Birth is no longer an objectification of
GovtHead was born in Country.
Bill Clinton
US
George W. Bush US
John Howard
AU
GovtHead
(name)
was born in
Country
(code)
Birth
has /is of
Bill Clinton
George W. Bush
John Howard
Helen Clark
b1
b2
b3
b4
is in
b1 US
b2 US
b3 AU
24
The main case where it makes sense to objectify associations
with non-spanning uniqueness constraints, is when the UC(s) may
evolve over time (e.g. from non-spanning to spanning)
and we wish to minimize the impact of such changes to the model.
A set of modeling guidelines,
which also covers other cases is
presented on the next slide.
25
Modeling heuristic.1
A fact type may be objectified only if:
(a) it has only a spanning uniqueness constraint; or
(b) its uniqueness constraint pattern is likely to evolve over time,
e.g. from n:1 to m:n, or m:n:1 to m:n:p; or
(c) it has at least two uniqueness constraints spanning n-1 roles (n > 1),
and there is no obvious choice as to which of the n-1 role uniqueness
constraints is the best basis for a smaller objectification
based on a spanning uniqueness constraint; or
(d) the objectification significantly improves the display of
semantic affinity between fact types attached to the objectified type.
1
For further discussion, see Halpin, T. 2003, ’Uniqueness Constraints on Objectified
Associations’, Journal of Conceptual Modeling, October 2003.
Online at: http://www.orm.net/pdf/JCM2003Oct.pdf.
26
Propositional Nominalization and
Communication Acts
The Business Rules Team submission to the OMG RFP on
Business Semantics for Business Rules includes business rules that
may be treated directly as cases of propositional nominalization, e.g.
If a waiter earns an amount of money as a tip from serving a meal,
the waiter must report that fact.
Rather than introducing a second kind of objectification into ORM 2
to deal directly with propositional nominalization,
we recommend recasting such cases in terms of
situational nominalization
(e.g. as shown on the next slide).
27
If a waiter earns an amount of money as a tip from serving a meal,
the waiter must report that fact.
… for serving … reported a tip of ...
2.1
Waiter
(EmpNr)
1.1
1.2
served
2.2
2.3
Meal
(nr)
“Service !”
1.3
earned a tip of
MoneyAmount
(USD:)
28
As regards modeling of communication acts,
when it is of interest to model these acts,
they are best modeled directly like any other business domain objects.
e.g.
in a genealogy model we might be interested in not just
descriptions of states of affairs, but assertion acts made by researchers
about states of affairs.
Such a model might include fact types such as:
AssertionAct reported Proposition;
AssertionAct was made by Researcher with ConfidenceLevel; etc.
These comments relate to the information model only.
For modeling communication processes,
the information model should be supplemented by other kinds of model
(e.g. interaction or workflow models)
that provide a more intuitive and direct way of understanding
essential business processes/services.
29
Summary
For information modeling, objectification may be restricted to
situational nominalization, where the nominalized object is
a state of affairs (event, activity …) rather than a proposition.
Objectification of facts (unary, binary, or longer)
may then be interpreted in terms of entities whose reference schemes
are constrained by equality constraints
involving reference projections from linking predicates.
Objectification of facts with non-spanning uniqueness constraints
should be permitted, but subject to proposed modeling guidelines.
Communication acts may be included as domain entities in information
models, but some communication aspects are best specified with
other kinds of model (e.g. interaction or workflow diagrams).
30
Business Rule Modality
 Introduction
 Modal Operators and Rule Verbalization
 Embedded, Static Rules
 Dynamic Rules
31
Introduction
Business Rules determine what states and state transitions
are possible or permitted for a given business domain,
and may be of alethic or deontic modalities.
Alethic rules
• impose necessities (e.g. implied by physical laws)
• cannot be violated, even in principle
e.g.
Each Person was born on at most one Date.
No Component includes itself.
Deontic rules
• impose obligations
• ought to be obeyed, but may be violated
e.g. It is obligatory that each Person is husband of at most one Person.
It is forbidden that any Person smokes in any Office.
32
Information modeling approaches such as ER, UML and ORM
typically restrict their coverage of rules to alethic rules.
In practice, many business rules are deontic,
and it is often important to know when they are violated
so that actions can be taken to discourage future violations
(whether or not support for this is automated).
In recognition of this need as well as for rule exchange etc.,
the OMG is finalizing the SBVR1
(Semantics of Business Vocabulary and Rules) proposal
to specify a business semantics
layer on top of its software-oriented layers.
1
Interim SBVR specification URL: www.omg.org/cgi-bin/doc?dtc/06-03-02.
33
This presentation is based on
the author’s logical formalization work for SBVR,
and work on NORMA1
an open-source tool for ORM 2 (2nd generation ORM)
which supports deontic and alethic rules.
The ideas discussed could be adapted for other approaches
such as ER and UML.
In fact, the NORMA tool is currently being extended to
to support ER and UML notations as views of the underlying ORM model.
1
http://sourceforge.net/projects/orm
34
Modal Operators and Rule Verbalization
Alethic
Reading
Deontic
Symbol
Reading
Symbol
It is necessary that

It is obligatory that
O
It is possible that

It is permitted that
P
It is impossible that
~
It is forbidden that
F
Modal negation rules
~p  ~p
~p  ~p
~Op  P~p
~Pp  O~p  Fp
~Fp  Pp
 = true in all possible worlds
 = true in some possible world
For static constraints, a possible world is a state of the business domain.
35
(a)
Person
(name)
was born in
Terry Halpin
AU
Robert Meersman BE
Graeme Simsion AU
Country
(code)
(b)
PERSON
a native of
COUNTRY
the birthcountry of
(c)
Person
*
1
birthCountry
Country
NORMA displays alethic constraints in violet
and verbalizes constraints in positive and negative forms.
The mandatory and uniqueness constraints in positive, combined form:
Each Person was born in exactly one Country.
(2 constraints: exactly one = some, and at most one).
This is read as a necessity. As an option, this may be made explicit:
It is necessary that each Person was born in exactly one Country.
36
(a)
Person
(name)
was born in
Terry Halpin
AU
Robert Meersman BE
Graeme Simsion AU
Country
(code)
(b)
PERSON
a native of
COUNTRY
the birthcountry of
(c)
Person
*
1
birthCountry
Country
In positive form, NORMA also verbalizes
the lack of a uniqueness constraint on the right-hand role:
It is possible that
more than one Person was born in the same Country.
Satisfying populations help illustrate constraints.
37
(a)
Person
(name)
was born in
Terry Halpin
AU
Robert Meersman BE
Graeme Simsion AU
Terry Halpin
Terry Halpin
Country
(code)
(b)
PERSON
a native of
COUNTRY
the birthcountry of
(c)
Person
*
1
birthCountry
Country
AU
US
The mandatory and uniqueness constraints verbalized separately
in negative form:
For each Person, it is impossible that
that Person was born in more than one Country.
It is impossible that any Person was born in no Country.
NORMA is being extended to support counterexamples to
illustrate constraint violation and generate test cases.
38
(a)
(b)
HourSlot
(dhCode)
Room
(nr)
Activity
(name)
… at … is booked for ...
20
20
20
33
33
Mon 9 am
Mon 4 pm
Tue 2 pm
Mon 9 am
Fri 5 pm
ORM class
CQ demo
ORM class
CQ demo
Party
HourSlot
dhCode
*
Room
roomNr
Activity
0..1
*
name
Booking
The uniqueness constraint might be alethic (shown above) or deontic.
Alethic +ve:
[It is necessary that] For each Room and HourSlot,
that Room at that HourSlot is booked for at most one Activity.
Alethic –ve:
It is impossible that
the same Room at the same HourSlot
is booked for more than one Activity.
39
HourSlot
(dhCode)
Room
(nr)
Activity
(name)
… at … is booked for ...
NORMA display deontic rules in blue,
typically with an “o” for “obligatory”.
Deontic modality:
+ve: It is obligatory that for each Room and HourSlot,
that Room at that HourSlot is booked for at most one Activity.
-ve: It is forbidden that
the same Room at the same HourSlot
is booked for more than one Activity.
40
NORMA screenshot
41
NORMA currently allows modal operators only as the main operator
of the rule expression.
Some allowed SBVR formulations that violate this restriction
may be transformed into an equivalent NORMA expression
by applying modal negation rules and the Barcan formulae
and their converses, i.e.
x Fx  x Fx
x Fx  x Fx
e.g.
For each Person,
it is necessary that that Person was born in at most one Country.
transforms to
It is necessary that each Person was born in at most one Country.
42
We also accept the following deontic variant of the Barcan formulae,
allowing  and O to commute.
x O Fx  O x Fx
This allows the following rule
For each Person,
it is obligatory that that Person is a husband of at most one Person.
to be transformed to
It is obligatory that each Person is a husband of at most one Person.
43
By normalizing rules to restrict modal operators to the main operator,
the only impact on tagging a rule as a necessity or obligation is on
rule enforcement.
For static rules, no commitment to a specific modal logic is required.
Enforcement of a necessity rule never allows violations.
Enforcement of an obligation rule allows violations,
but takes some remedial action
(e.g. display a message to a relevant authority
indicating violation of the rule
including verbalization of the rule).
44
Embedded, Static Rules
SBVR allows modal operators to be embedded anywhere in
rule expressions. In rare cases, these rules cannot be transformed
into rules where the only modal operator is the main operator.
To support such cases, we have two alternatives
• adopt a specific modal logic1
• replace the embedded modal operators by domain-level predicates
For the first alternative, we prefer S42.
For the second alternative, we proceed as for embedded deontics
(see later).
There are many normal modal logics (e.g. K, K4, KB, K5, DT, DB, D4, D5, T, Br, S4, S5)
as well as non-normal modal logics (e.g. C2, ED2, E2, S0.5, S2, S3).
2 Schema evolution may seem to violate S4 (its accessibility relationship between possible
worlds in transitive), but we resolve this by treating such evolution at the metametalevel.
1
45
Formally, we treat a model as an interpretation
where each non-deontic formula evaluates to true.
A model is a permitted model
if the p in each deontic formula of the form Op evaluates to true
otherwise it is a forbidden model (though still a model).
This approach avoids the need to assign a truth value
to expressions of the form Op.
46
Various metarules apply between alethic and deontic rules,
e.g.
the argument (role set) of a deontic uniqueness constraint must be
a proper subset of the argument of an alethic uniqueness constraint.
This example satisfies this metarule:
Person
(name)
is a husband of /is a wife of
However, if the marriage predicate were alethically 1:1,
then no deontic uniqueness constraint may be added
(if something is already necessary,
it makes no sense to declare it obligatory).
47
Some SBVR formulae (e.g. OPp) are illegal in some deontic logics,
and deontic logic itself is rife with controversies.
If a deontic model operator is embedded, we first try to normalize
the formula using transformation rules such as p  Oq .. O(p  q)1
or deontic counterparts to the Barcan formulae.
In rare cases, embedded deontics cannot be so normalized.
Rather than choosing a specific modal logic (a risky option),
where possible we transform such cases into first-order formulae
with no modalities by replacing the modal operators by predicates at the
business domain level.
Such predicates (e.g. “is forbidden”, “is permitted”) are reserved and
given additional semantics
(e.g. exclusion constraints between forbidden/permitted predicates).
1
In contrast to our approach, some versions of deontic logic reject this equivalence
on the basis that agent control is restricted to the scope of modal operators.
48
As a simple example, consider the following SBVR rule.
Car rentals ought not be issued to people
who are barred drivers at the time the rental was issued.
This deontic rule may be captured by the following
ORM derivation rule for the partly derived domain fact type
CarRental is forbidden:
CarRental is forbidden if
CarRental was issued at Time and
CarRental was issued to Person and
Person is a barred driver at Time.
The following slide shows the full ORM diagram for this case.
49
was issued to
Person
is forbidden*CarRental
is a
barred
driver
at*
was
barred
at
was
unbarred
at
Time
was issued at
* Person is a barred driver at Time1 iff
Person was barred at a Time2 <= Time1 and
Person was not unbarred at a Time3 between Time2 and Time1
*- CarRental is forbidden if
CarRental was issued at Time and
CarRental was issued to Person and
Person is a barred driver at Time
50
SBVR allows rules that embed possibly non-factual propositions.
However, there does not appear to be any simple solution to providing
explicit, formal semantics for such rules.
As a nasty example, consider the following business rule:
It is not permitted that some department adopts a rule
that says it is obligatory that
each employee of that department is male.
This example includes the mention (rather than use) of an open proposition
in the scope of an embedded deontic operator.
One possible, though weak, solution is to rely on
reserved domain predicates to carry much of the semantics implicitly,
as shown in the following ORM schema.
51
is male
Person
(Id)
is forbidden *-
<< is by
works for
<< employs
is of
Department
(Id)
adopts
Rule
(Nr)
“RuleAdoption”
obligates the
actualization of
<< is of
Possible
AllMaleState
* PossibleAllMaleState is actual iff
PossibleAllMaleState is of a Department and
each Person who works for that Department is male
is actual*
*- RuleAdoption is forbidden if
RuleAdoption is by a Department
and is of a Rule
that obligates the actualization of a PossibleAllMaleState
that is of the same Department
Some support for reification in the sense of propositional nominalization
is being added by Pat Hayes and Chris Menzel to the IKL language,
while retaining first-order. When available, this may offer other options
for dealing with such cases.
52
Dynamic Rules
Dynamic rules restrict the possible transitions between business states.
The rule may simply compare one state to the next
(e.g. Salaries should never decrease)
or the rule may compare states separated by a given period
(e.g. Invoices ought to be paid within 30 days of being issued).
The invoice rule might be formally expressed thus,
assuming the relevant fact types exist in the conceptual schema:
For each Invoice, if that Invoice was issued on Date1
then it is obligatory that
that Invoice is paid on Date2
where Date2 <= Date1 + 30 days.
53
This rule might now be normalized to the following formulation,
moving the deontic operator to the front:
It is obligatory that
each Invoice that was issued on Date1
is paid on Date2
where Date2 <= Date1 + 30 days.
This transformation requires an equivalence rule such as
p  Oq .. O(p  q).
While this formula is actually illegal in some deontic logics,
it does seem intuitively acceptable.
In principle, such formal transformation issues might be ignored,
so long as the domain expert confirms that the normalized formulation
agrees with his/her intended semantics.
54
While it is obvious how to implement this rule in a database system,
capturing the formal semantics in an appropriate logic
(e.g. a temporal or dynamic logic) is a harder task.
One possibility is to provide a temporal package that may be imported
into a domain model, in order to provide a first-order logic solution.
Another possibility is to adopt a temporal modal logic
(e.g. treat a possible world as a sequence of accessible states).
We prefer a first-order solution where possible.
55
Summary
Many business rules are deontic rather than alethic.
This presentation discussed one way of
modeling and verbalizing such rules in ORM 2,
as supported by the open-source NORMA tool.
NORMA currently supports static rules where
the only modal operator is the main operator.
Rules that cannot be transformed into such cases
are challenging to adequately formalize and support,
especially those involving embedded deontics or dynamic rules.
Some approaches were suggested to deal with such cases,
but further research is needed to adequately address these complexities.
56
NORMA Tool Demo/Discussion
57