Cross-Module Optimization Thomas Lindgren [email protected].
Artificial Intelligence Giancarlo Guizzardi ([email protected] )[email protected] Computer Science...
-
Upload
chad-reader -
Category
Documents
-
view
224 -
download
0
Transcript of Artificial Intelligence Giancarlo Guizzardi ([email protected] )[email protected] Computer Science...
Artificial Intelligence
Giancarlo Guizzardi([email protected] )http://nemo.inf.ufes.br
Computer Science DepartmentFederal University of Espírito Santo (UFES),
Brazil
Ontological Engineering• There are currently several existing methods for addressing
the many different activities that comprise the process of Ontological Engineering– METHONTOLOGY (Gomez-Perez et al.)– SKELETAL METHODOLOGY (Uschold and King)– TOVE Method (Gruninger and Fox)– On-to-Knowledge (Karlsruhe)– NeOn Methodology– SABiO (Falbo)– OntoClean (Guarino and Welty)– oQual (Gangemi et al.)– OntoQA (Sheth et al.)
Ontological Engineering• There are currently several existing methods for addressing
the many different activities that comprise the process of Ontological Engineering– METHONTOLOGY (Gomez-Perez et al.)– SKELETAL METHODOLOGY (Uschold and King)– TOVE Method (Gruninger and Fox)– On-to-Knowledge (Karlsruhe)– NeOn Methodology– SABiO (Falbo)– OntoClean (Guarino and Welty)– oQual (Gangemi et al.)– OntoQA (Sheth et al.)
Basic Development Methodology1. Purpose and Scope Identification (Requirements
Engineering)2. Ontology Reuse3. Ontology Conceptual Modeling4. Ontology Integration5. Ontology Design
• Transformation Patterns and Guidelines
6. Ontology Codification7. Ontology Evaluation
Basic Development Methodology1. Purpose and Scope Identification (Requirements
Engineering)2. Ontology Reuse3. Ontology Conceptual Modeling4. Ontology Integration5. Ontology Design
• Transformation Patterns and Guidelines
6. Ontology Codification7. Ontology Evaluation
Basic Development Methodology1. Purpose and Scope Identification (Requirements
Engineering)• The objective here is to understand all the concepts which are
central to the domain, i.e., the meaning of the relevant types, properties (instrinsic and relational), events and domain laws.
• Define the scope of ontology, its purposes and expected applications (competence of the ontology)
• A technique of particular relevance here is the definition of the so-called Competence Questions, i.e., the definition of what are the questions which ontology are expected to be able to answer
• Competence Questions is a technique for Scope and Purpose Definition, but also for validation
Basic Development Methodology1. Purpose and Scope Identification (Requirements
Engineering)• Scope definition is a critical aspect since several different (correct)
ontologies can be defined for the same domain with different scopes in mind
• In any case, try to be as generic as possible. The role is capture the conceptualization of a domain in reality, not a database schema!
Basic Development Methodology1. Purpose and Scope Identification (Requirements
Engineering)• Scope definition is a critical aspect since several different (correct)
ontologies can be defined for the same domain with different scopes in mind
• In any case, try to be as generic as possible (Minimal Ontological Commitment). The role is capture the conceptualization of a domain in reality, not a database schema!
• If the domain is two complex, an important technique is Domain Modularization so that different (ideally) orthogonal aspects of the domain can be capture in different subontologies
UFO & OBO Relation
Ontology
Anatomy subontoloty
Heart Electrophysiology
subontology
ECG subontology
ECG Ontology Modularization
Basic Development Methodology2. Ontology Conceptual Modeling
• The use of the support of a Foundational Ontology is fundamental in this phase.
• The objective is to maximize expressiveness, truthfulness w.r.t. the domain at hand and conceptual clarity
• In this course, we will use the UFO ontology and a particular language based on it termed OntoUML
• Initially we will deal exclusively with Structural Aspects of the domain
• Represent all elements in the Universe of Discourse– Model Types of Objects (both dependent and independent)
» Including Higher-Order Types– Model Categories of Object Types– Model Types of Properties (both Relational and Intrinsic) and
Property Value Spaces– Model Derived Types and Derivation Rules– Model Integrity Constraints
Basic Development Methodology2. Ontology Conceptual Modeling
• Define a Dictionary of Terms specifying in Natural Language and by using examples the primitive elements of the ontology
• Analyze the Ontology using Analysis Patterns• The use of Visual Language is very important in this phase• The use of a Model-Based Editor can be of great help• Validate Conceptual Model
– Model Simulation
OntologyConceptual Model
(OntoUML)
Ontology Codification1
Ontology Design Model1
Ontology Codification2Ontology Codification3
Ontology Design Model1
ComputationalIndependentModel (CIM)
PlatformIndependent
Model (PIM)
PlatformSpecific
Model (PSM)
A WHIRLWIND INTRODUCTION TO THE UML 2.0 CLASS FRAGMENT
Classes and Attributes• A class describes the common features (e.g., intrinsic and
relational properties) shared by a (possible multitude of) entities which are then said to be the instances of that class
• Instances of a class must contain values for each attribute that is defined for that class, in accordance with the characteristics of the attribute, for example its type and multiplicity.
• Attributes represent (more or less intrinsic) properties of shared by members of a class
age:AgeValues[1]height:HeightValues[1]ssn:SSNValues[0..1]
Person
Classes and Attributes• A class describes the common features (e.g., intrinsic and
relational properties) shared by a (possible multitude of) entities which are then said to be the instances of that class
• Instances of a class must contain values for each attribute that is defined for that class, in accordance with the characteristics of the attribute, for example its type and multiplicity.
• Attributes represent (more or less intrinsic) properties of shared by members of a class
age:AgeValues[1]height:HeightValues[1]ssn:SSNValues[0..1]
Person
attribute name
attribute type attribute
multiplicity
Specialization• Classes can be related to each other via specialization
relations forming a taxonomic structure• All properties of a class are inherited through a
specialization chain• A class can be a specialization of multiple classes• The specialization relation is a anti-symmetric and transitive
relation, i.e., If A specializes B then B cannot specialize AIf A specializes B and B specializes C then A specializes C
age:AgeValuesheight:HeightValuesssn:SSNValues
Person
Man
Specialization• Classes can be related to each other via specialization
relations forming a taxonomic structure• All properties of a class are inherited through a
specialization chain• A class can be a specialization of multiple classes• The specialization relation is a anti-symmetric and transitive
relation, i.e., If A specializes B then B cannot specialize AIf A specializes B and B specializes C then A specializes C
age:AgeValuesheight:HeightValuesssn:SSNValues
Person
Man
supertype
subtype
Generalization Set• Classes sharing a common direct supertype can be group in
what is called a generalization set
• There are two meta-attributes that can be used ascribe a stronger semantics to a generalization set, namely, the complete and disjoint meta-attributes
age:AgeValuesheight:HeightValuesssn:SSNValues
Person
Man Woman
Specialization (Set-Theoretical Semantics)
age:AgeValuesheight:HeightValuesssn:SSNValues
Person
Man
PERSON
Man
age:AgeValuesheight:HeightValuesssn:SSNValues
Person
Man Woman
PERSON
ManWoman
Complete• If a generalization set is complete then the subclasses
exhaust the instances of the common direct superclass. • In other words, in this case, there is no instance of the
superclass which is not an instance of one of the subclasses participating in the generalization
age:AgeValuesheight:HeightValuesssn:SSNValues
Person
Man Woman
{complete}
Man
Woman
Man andWoman
PERSON
PERSON
ManWoman
Disjoint• If a generalization set is disjoint if all the subclasses
participating in the generalization are mutually exclusive • In other words, the intersection between these any of these
subclasses pairwise is necessarily empty
neither Man or Woman
age:AgeValuesheight:HeightValuesssn:SSNValues
Person
Man Woman
{disjoint}
Disjoint and Complete• If a generalization set is disjoint and complete then the
subclasses participating in this generalization set form a partition.
• In other words, every instance of the common superclass is an instance of one and only one of the subclasses
• In this case, the common superclass is an abstract class
age:AgeValuesheight:HeightValuesssn:SSNValues
Person
Man Woman
{disjoint, complete}
Man
Woman
PERSON
Associations• An association declares that there can be links between
instances of the associated types. A link is a tuple with one value for each end of the association, where each value is an instance of the type of the end.
Person Property
1..* *
ownership
Associations• One specify multiplicity constraints for each end of the
association
• The possibilities for cardinality constraints are:
Person Property
1..* *
ownership
Min Max UML notation
0 1 0..1
0 n (n> 1 indefinido) *
1 1 1
1 n (n> 1 indefinido) 1..*
min
max
Associations• When one or more ends of the association are ordered,
links carry ordering information in addition to their end values.
• To each association end, one can specify a rolename definying the “role played by objects of that type in the association”
Persondate:Date
Symptonpatient
1 1..*{ordered}
exhibits4
Associations• When one or more ends of the association are ordered,
links carry ordering information in addition to their end values.
• To each association end, one can specify a rolename definying the “role played by objects of that type in the association”
Persondate:Date
Symptonpatient
1 1..*{ordered}
exhibits4
rolename reading directionality
tagged valued representingassociation end’s orderingmeta-attribute
Associations• One can define type-reflexive associations, i.e., associations
in which both association ends are connected to the same type
Person
parent *
offspring *
parenthood
Datatypes• A Datatype represents the set of possible values that an
attribute can take.• If attributes are seen as functions (mapping the extension of
a class to a datatype) than they are the range of that function
• Datatypes have no instances in the real sense, they are simply sets of values. They have members which are abstract individuals, i.e., they are not explicitly created or destroyed but are simply assumed to exist
age:AgeValues
Person «datatype»AgeValues
Person
* 1
Datatypes• There are simple and structured datatype. The “attributes”
of a structured datatype are named datatype fields • The members of a datatype with n fields are n-uples. For
instance, the members of the color datatype below are triples <h,s,b> of hue, saturation and brightness values
hue:Huesaturation:Saturationbrightness:Brightness
«datatype»Color
Enumeration
• Since datatypes are sets we have that: (i) two datatypes are the same iff they have the same members
• One can define a datatype by explicit enumeration, i.e., by explicitly defining its member values
SundayMondayTuesdayWednesdayThursdayFridaySaturday
«enumeration»Days of the Week
DERIVED TYPES AND DERIVATION CONSTRAINTS
Derived Types • We distinguish between Base Types and Derived Types• Derivability has to do with how the population of a type is
generated• E.g., contrast Book with Borrowed Book, Person with Adult Person
Book
/BorrowedBook
Person
/Adult Person
Derived Types and Derivation Rule • For each derived types there is an associated derivation rule
describing necessary and sufficient conditions for classification (instantiation)
E.g., Every Adult Person is a Person who is older than 18
age:AgeValues
Person
/Adult Person
x AdultPerson(x)
Person(x) (Age(x) 18)
x AdultPerson(x)
Person(x) (Age(x) 18)
SVBR (Semantics of Business Vocabularies and Rules)
Derived Types and Derivation Rule • For each derived types there is an associated derivation rule
describing necessary and sufficient conditions for classification (instantiation)
E.g., Every Adult Person is a Person who is older than 18
age:AgeValues
Person
/Adult Person
x AdultPerson(x)
Person(x) (Age(x) 18)
x AdultPerson(x)
Person(x) (Age(x) 18)
x AdultPerson(x) =def Person(x) (Age(x) 18)
Derived Types and Derivation Rule • For each derived types there is an associated derivation rule
describing necessary and sufficient conditions for classification (instantiation)
E.g., Every Borrowed Book is a Book with an associated Rental Object
x AdultPerson(x)
Person(x) (Age(x) 18)
x AdultPerson(x)
Person(x) (Age(x) 18)
age:AgeValues
Person
/Adult Person
DR1
age ≥ 18
Derived Types and Derivation Rule • For each derived types there is an associated derivation rule
describing necessary and sufficient conditions for classification (instantiation)
E.g., Every Borrowed Book is a Book with an associated Loan
x AdultPerson(x)
Person(x) (Age(x) 18)
x AdultPerson(x)
Person(x) (Age(x) 18)
Book Book Loan
1 *
3 loan of
Derived Types and Derivation Rule • For each derived types there is an associated derivation rule
describing necessary and sufficient conditions for classification (instantiation)
E.g., Every Borrowed Book is a Book with an associated Loan
x AdultPerson(x)
Person(x) (Age(x) 18)
x AdultPerson(x)
Person(x) (Age(x) 18)
x BorrowedBook(x) =def Book(x) y(BookLoan(y) associated-with(y,x))
Book
/BorrowedBook
Book Loan
1 *
3 loan of
Derived Types and Derivation Rule • For each derived types there is an associated derivation rule
describing necessary and sufficient conditions for classification (instantiation)
E.g., Every Borrowed Book is a Book with an associated Loan
x AdultPerson(x)
Person(x) (Age(x) 18)
x AdultPerson(x)
Person(x) (Age(x) 18)
Book
/BorrowedBook
Book Loan
1 *
3 loan of
DR1
x y
x
Derived Types and Derivation Rule • For each derived types there is an associated derivation rule
describing necessary and sufficient conditions for classification (instantiation)
E.g., Every Available Book is a Book without an associated Loan
x AdultPerson(x)
Person(x) (Age(x) 18)
x AdultPerson(x)
Person(x) (Age(x) 18)
Book
/AvailableBook
Book Loan
1 *
3 loan of
DR1
x y
x
Derived Types and Derivation Rule • For each derived types there is an associated derivation rule
describing necessary and sufficient conditions for classification (instantiation)
E.g., Every Borrowed Book is a Book with an associated Loan
x AdultPerson(x)
Person(x) (Age(x) 18)
x AdultPerson(x)
Person(x) (Age(x) 18)
Book Book Loan
1 *
3 loan of
Derived Types and Derivation Rule • For each derived types there is an associated derivation rule
describing necessary and sufficient conditions for classification (instantiation)
E.g., Every Borrowed Book is a Book with an associated Loan
x AdultPerson(x)
Person(x) (Age(x) 18)
x AdultPerson(x)
Person(x) (Age(x) 18)
Book
/BorrowedBook Loan
1 1..*
Derived Types Quadrilateral is a Polygon with exactly four sides
numberOfSides:PolygonSides
Polygon
/Quadrilateral
DR1
numberOfSides = 4
3..20
«enumeration»PolygonSides
Derived Types
A BorrowedBook is a Book associated to a Loan and a BorrowingClient is a Person associated
to a Loan
Book
/BorrowedBook Loan
1 1..*
Person
1..* 1
/BorrowingClient
President
/DemocraticPresident
1 1..*{ordered}
elected in4
date:Dateprocedure:Appointment Procedure
Election
/DirectElection
DR1
procedure = direct
DirectIndirectAutocratic
«enumeration»Appointment Procedure
Derivation by Specialization• A types is defined as a specialization of another type which
has specific (intrinsic or relational) properties E.g., A Democratic President is a President elected by a Direct Election
Procedure
x AdultPerson(x)
Person(x) (Age(x) 18)
x AdultPerson(x)
Person(x) (Age(x) 18)
PRESIDENT
Democratic President
President
/DemocraticPresident
1 1..*{ordered}
elected in4
date:Dateprocedure:Appointment Procedure
Election
/DirectElection
DR1
procedure = direct
DirectIndirectAutocratic
«enumeration»Appointment Procedure
Derivation by Specialization• A types is defined as a specialization of another type which
has specific (intrinsic or relational) properties E.g., A Democratic President is a President elected by a Direct Election
Procedure
x AdultPerson(x)
Person(x) (Age(x) 18)
x AdultPerson(x)
Person(x) (Age(x) 18)
ELECTION
Direct Election
Also known as Derivation by Participation
• A types can be derived by specialization of multiple supertypes (also known as derived by intersection)
E.g., A Adult Student is a Student who is an Adult Person
Derivation by Intersectionx AdultPerson(x)
Person(x) (Age(x) 18)
x AdultPerson(x)
Person(x) (Age(x) 18)
Person
/Student Educational Institution
* 1..*
enrolled at4
Child
Adolescent
Adult
{complete,disjoint}
/Adult Student
• A types can be derived by specialization of multiple supertypes (also known as derived by intersection)
E.g., A Adult Student is a Student who is an Adult Person
Derivation by Intersectionx AdultPerson(x)
Person(x) (Age(x) 18)
x AdultPerson(x)
Person(x) (Age(x) 18)
Child
Adolescent
Adult
Person = Child Adolescent Adult Child Adolescent Adult =
PERSON
• A types can be derived by specialization of multiple supertypes (also known as derived by intersection)
E.g., A Adult Student is a Student who is an Adult Person
Derivation by Intersectionx AdultPerson(x)
Person(x) (Age(x) 18)
x AdultPerson(x)
Person(x) (Age(x) 18)
Child
Adolescent
Adult
StudentPerson = Child Adolescent Adult Child Adolescent Adult = Student Person
AdultStudent = Adult Student
PERSON
Derivation by Union• A type is defined as a Union of a number of other types
• A Derivation by Union constraint implies a number of specialization relation between T1…Tn and the derived type T, such that T1…Tn form a complete generalization set
x AdultPerson(x)
Person(x) (Age(x) 18)
x AdultPerson(x)
Person(x) (Age(x) 18)
Person
Man Woman
{complete,disjoint}
Derivation by Union• A type T is defined as a Union of a number of other types
T1…Tn if: in every situation, x is an instance of T iff x is an instance of T1 or T2 or….Tn
x AdultPerson(x)
Person(x) (Age(x) 18)
x AdultPerson(x)
Person(x) (Age(x) 18)
Person = Man WomanMan
Woman
PERSON
Derivation by Unionx AdultPerson(x)
Person(x) (Age(x) 18)
x AdultPerson(x)
Person(x) (Age(x) 18)
Person = Man WomanPerson = Child Adolescent AdultAdultMan = Adult Man
Man
Woman
PERSON
Adolescent
Child
AdultPerson
Man
Child
Adolescent
Adult
{complete,disjoint}
Adult Man
Woman
{complete,disjoint}
Derivation by Exclusion• A type T1 derived as a complement of T2..Tn w.r.t. T
• A Derivation by Exclusion constraint implies a number of specialization relations between T1…Tn and the type type T, forming a disjoint and complete generalization set
x AdultPerson(x)
Person(x) (Age(x) 18)
x AdultPerson(x)
Person(x) (Age(x) 18)
Person
Child
Adolescent
/Adult
{complete,disjoint}
Derivation by Exclusion• A type T1 is defined by exclusion of T2…Tn with respect to T
if: in every situation, x is an instance of T1 iff x is an instance of T and not an instance of (T2 or….Tn)
x AdultPerson(x)
Person(x) (Age(x) 18)
x AdultPerson(x)
Person(x) (Age(x) 18)
Person = Child Adolescent Adult
Adult = Person – (Child Adolescent)Child
Adolescent
Adult
PERSON
Important Point• We will see later how these derivation constraints interact
with the modeling primitives of OntoUML (e.g., are implied by, automatically deduced from)
INTEGRITY CONSTRAINTS
Admissible state of affairs according to the conceptualization underlyingO1
State of affairs represented by the valid models of Ontology O1
Unconstrained Model
Admissible state of affairs according to the conceptualization underlyingO1
State of affairs represented by the valid models of Ontology O1 + Integrity Constraints
Constrained Model
Integrity Constraints1. Disjointness Constraints (DC)
• For the case of types, typically, DCs are transformed into derivation constraints (e.g., disjoint generalization sets)
• DCs between relationships can be expressed visually but one has to be very careful
/ClubMember ClubMembershipCard
1 1..*
purchases4
Person
1 1..*
is granted4
{XOR}
Integrity Constraints1. Disjointness Constraints (DC)
• For the case of types, typically, DCs are transformed into derivation constraints (e.g., complete generalization sets)
• DCs between relationships can be expressed visually but one has to be very careful
/ClubMember ClubMembershipCard
1 *
purchases4
Person
1 *
is granted4
{XOR}
Integrity Constraints1. Disjointness Constraints (DC)
• For the case of types, typically, DCs are transformed into derivation constraints (e.g., complete generalization sets)
• DCs between relationships can be expressed visually but one has to be very careful
/RegularMember ClubMembershipCard
1 1..*
purchases4
Person
1
1..*
is granted4
/HonoredMember
{disjoint}
Integrity Constraints1. Disjointness Constraints (DC)2. Covering Constraints (CC)
• Typically transformed into derivation constraints or specialization relations (e.g., complete sets)
Integrity Constraints1. Disjointness Constraints (DC)2. Covering Constraints (CC)3. Consolidation Constraints
• Define the type of entities that can participate in a relation• Unecessary in a language such as UML
Integrity Constraints1. Disjointness Constraints (DC)2. Covering Constraints (CC)3. Consolidation Constraints4. Other Epistemological Constraints
• These are all constraints directly derived from the concrete syntax of the language
Integrity Constraints
/BankClient
Person
Account
1 1..3
has account4
Integrity Constraints
/BankClient
Person
Account
1 1..3
has account4
A type of constraint (inclusion constraint)
PERSON
Bank Client
• Other constraint of this kind is parthood• The semantics is (supposed to be) included
in the metamodel of the language• This includes the meta-properties of these
relations
Integrity Constraints1. Disjointness Constraints (DC)2. Covering Constraints (CC)3. Consolidation Constraints4. Other Epistemological Constraints5. Domain Constraints
Integrity Constraints
/BankClient
Person
Account
1 1..3
has account4
x BankClient(x) 1 #{ y | hasAccount(x,y)} 3
A customer cannot have more than 3 accounts
Integrity Constraints
Person
/OrganDonor
/OrganDonee
Transplant
1 1..*
donor in4
1..*
1donee in4
/TransplantSurgeon
1..*
1
operates4
Integrity Constraints
x Transplant(x) y,z,w OrganDonor(y) OrganDonee(z) TransplantSurgeon(w) (xy) (xz) (xw) (yz) (yw) (zw) donorIn(y,x) doneeIn(z,x)
operates(w,x)
Person
/OrganDonor
/OrganDonee
Transplant
1 1..*
donor in4
1..*
1donee in4
/TransplantSurgeon
1..*
1
operates4
The participants in a transplant (i.e., donor, donee and transplant surgeon) are necessarily mutually distinct
Integrity Constraints
Meeting Room
* 1
has location4
TimeInterval1 *
3 happens in*
*intersects
Integrity ConstraintsTwo (different) meetings cannot take place in the
same room at the same time
Meeting Room
* 1
has location4
TimeInterval1 *
3 happens in*
*intersects
Integrity ConstraintsTwo (different) meetings cannot take place in the
same room at the same time
x,y,t1,t2,l Meeting(x) Meeting(y) happensAt(x,t1) happensAt(y,t2) hasLocation(x,l) hasLocation(y,l)
intersect(t1,t2) (x = y)
Meeting Room
* 1
has location4
TimeInterval1 *
3 happens in*
*intersects
Integrity Constraints• Domain Integrity constraints can be re-written as
Inconsistency Predicates
x,y overlapsWith(x,y) =def Meeting(x) Meeting(y) t1,t2,l happensAt(x,t1) happensAt(y,t2)
hasLocation(x,l) hasLocation(y,l) intersect(t1,t2)
Meeting Room
* 1
has location4
TimeInterval1 *
3 happens in*
*intersects
**
/overlapsWith
Integrity ConstraintsTwo (different) meetings cannot take place in the
same room at the same time
x,y,t1,t2,l Meeting(x) Meeting(y) happensAt(x,t1) happensAt(y,t2) hasLocation(x,l) hasLocation(y,l)
intersect(t1,t2) (x = y)
Meeting Room
* 1
has location4
TimeInterval1 *
3 happens in*
*intersects
Integrity ConstraintsTwo (different) meetings cannot take place in the
same room at the same time
x,y,t1,t2,l Meeting(x) Meeting(y) happensAt(x,t1) happensAt(y,t2) hasLocation(x,l) hasLocation(y,l)
intersect(t1,t2) (x = y)
Meeting Room
* 1
has location4
TimeInterval1 *
3 happens in*
*intersects
Integrity Constraints1. Disjointness Constraints (DC)2. Covering Constraints (CC)3. Consolidation Constraints4. Other Epistemological Constraints5. Domain Constraints
• Meta-Properties of Domain Relations
Integrity Constraints• A number of Meta-Properties can be defined for (type-
reflexive) relationsPerson
1..*1..*
3 descends from
/Ancestor /Descendent
Integrity Constraints• A number of Meta-Properties can be defined for (type-
reflexive) relations
• Someone cannot be his own ancestor• Someone cannot be an ancestor of an ancestor of his• Someone´s ancestors include the ancestors of his
ancestors
Person
1..*1..*
3 descends from
/Ancestor /Descendent
Integrity Constraints• A number of Meta-Properties can be defined for (type-
reflexive) relations
• Someone cannot be his own ancestor• Someone cannot be an ancestor of an ancestor of his• Someone´s ancestors include the ancestors of his
ancestors
Person
1..*1..*
3 descends from
/Ancestor /Descendent
Irreflexive, asymmetric and transitive relation, i.e., a partial order relation
Integrity Constraints1. Disjointness Constraints (DC)2. Covering Constraints (CC)3. Consolidation Constraints4. Other Epistemological Constraints5. Domain Constraints
• Meta-Properties of Domain Relations• Temporal Constraints
Temporal Constraints• A customer cannot open two accounts on the same day• A handler must be assigned to an account up to 1 month
after the accounts creation• The balance of the account when first opened must be non-
negative• A client cannot have more than three accounts at the same
time
/BankClient
Person
balance:Money
Account
1 1..*
has account4
/AccountHandler
0..1
1..*
is responsible for4
Temporal Constraints• A customer cannot open a new account if he has one which
is overdrawn• A customer cannot open a new account if he has an account
overdrawn for more than 30 days in that same year
/BankClient
Person
balance:Money
Account
1 1..*
has account4
/AccountHandler
0..1
1..*
is responsible for4
Temporal Constraints
x initialState(x) (balanceOf(x) 0)
/BankClient
Person
Account
1 1..*
has account4
/AccountHandler
balance:Money
AccountState
1 1..*{ordered}
constituted by4
TimeInterval
*
1
3 happens inAssignment
1
1..*
0..1
1
/InitialState
*
*precedes
Temporal Constraints
x,y,z hasAccount(x,y) constitutedBy(y,z) OverDrawnState(z) (w,q hasAccount(x,w)
constitutedBy(w,q) initialState(q) intersect(z,q))
/BankClient
Person
Account
1 1..*
has account4
/AccountHandler
balance:Money
AccountState
1 1..*{ordered}
constituted by4
TimeInterval
*
1
3 happens inAssignment
1
1..*
0..1
1
/InitialState
*
*precedes
/OverDrawnAccountState
DR2
balance < 0
{disjoint}
Important Point• There are a number of constraints that must be included in
UML models as domain constraints because of the nature of the language
• Some of these cannot even be properly represented!
/BankClient
Person
Account
1 1..*
has account4
/AccountHandler
balance:Money
AccountState
1 1..*{ordered}
constituted by4
TimeInterval
*
1
3 happens inAssignment
1
1..*
0..1
1
/InitialState
*
*precedes
/OverDrawnAccountState
DR2
balance < 0
{disjoint}
Important Point• There are a number of constraints that must be included in
UML models as domain constraints because of the nature of the language
• Some of these cannot even be properly represented!• We will see later how these constraints (e.g., dependence,
parthood, dynamic vs. static classification, explanation for relationship meta-properties) become part of the language in OntoUML. Similar to the notion of epistemological constraints here...However, those are constraints of a true ontological nature!
Side Effects in Derivation by Immutable Participation
x ,y Sale(x) Product (x,y) saleOf(x,y) (unitprice(x) = priceOf(y))
/unitprice:Money
Sale
price:Money
Product
* 1
Side Effects in Derivation by Immutable Participation
/SalesPerson
/Customer
Sale
1 1..*
/responsible for4
1
1..*
3 saleOf
1..*
1
assigned to4
DR
xy
y
z
x z
Important Point• There are a number of constraints that must be included in
UML models as domain constraints because of the nature of the language
• Some of these cannot even be properly represented!• We will see later how these constraints (e.g., dependence,
parthood, dynamic vs. static classification, explanation for relationship meta-properties) become part of the language in OntoUML. Similar to the notion of epistemological constraints here...However, those are constraints of a true ontological nature!
• Moreover, we can provide systematic techniches for identifying those modeling mistakes
Side Effects in Derivation by Immutable Participation
/SalesPerson
/Customer
Sale
1 1..*
/responsible for4
1
1..*
3 saleOf
1..*
1
assigned to4
DR
xy
y
z
x z
M+
M-
M+
http://nemo.inf.ufes.br/[email protected]