(a1,a2:A|a1.c1=a2.c1,…,= implies a1=a2)
In UML, the type of attribute constrains its value (for example, in Figure 4 Employee.address has user defined type Address). Value constraint restricts the value of attribute to a finite set of values specified either explicitly (by enumeration), by start and end values (range), or some combination of both. Enume-ration types may be modelled as classes, stereotyped as enumeration, with their values listed as attributes 0, 0 (Figure 4). Then type of attribute defined by class with stereotype <<enumeration>> sets constraint on its value (for example, Employee.sex in Fig. 4 may have value “M” or “F”). OCL expressions may specify ranges or other value constraints.
Derived attribute is an attribute whose value can be computed from other attributes already in the mo-del. Such attributes are redundant and generally they are not included in the model. However, there are situations when a clear understanding of a domain is best served by capturing the dependency between attributes explicitly. In UML the derived attribute is denoted by tagged value '/' before derived attribute and the derivation rule is added in the note. In Figure 4 this rule is specified in OCL:
context Employee
inv: self.age = (now - self.birthday).toInteger()
5. Integrity constraints on relationship or relationships
Multiplicity constraints on relationships are used in all analyzed methods. They define the number of class instances that participate in a relationship. There are two multiplicity indicators for every relationship – one at each end of the line. Sometimes “*” is used as abbreviation of “0..*” meaning “zero or more”; "1" as abbreviation of "1..1" meaning "exactly one"; and "0..1" means "at most one". In general, a multiplicity constraint can be written in the form [i…j], where 0 ≤ i < N, 1 ≤ j ≤ N, i ≤ j, and symbol N stands for infinity. Therefore the number of relationships in which an object participates in this role must be, for any instance, between i and j. Role names ra and rb in the diagram (Fig. 5) implies that the role name identifiers can be used as operations ra: B Æ Set(A) and rb: A Æ Set(B).
External uniqueness constraint could be informally defined like internal uniqueness constraint on attri-butes of external object type 0, 0 0. The values of attribute (or conceptual join of constrained attribute values) must be different for every instance of class. Figure 4 presents UML class diagram with suggested UML notation extension for graphical representation of external uniqueness constraint, where tag {EUn} marks external attributes that must be unique: Employee.personalCode is alternative identifier defined using external uniqueness constraint EU1 that means pairs Country.partOfPersonalCode and Emp-loyee.personalCode have unique value Constraints on
Figure 5. General case of multiplicity constraints on
association
Abstract. Integrity constraints are incident part of conceptual models, including part of semantics of problem domain. Analysis of the most important methods of conceptual modelling has revealed that none of them analyze the complete set of integrity const
E.Miliauskait , L.Nemurait
For example, ra returns for an object of type A the set of B objects related to the argument. The constraint requires that, for a single A object, the size of the set of related B objects is restricted by the lower bound lb and by the upper bound hb (analogously, for the other side of the association).
context A
inv: self.rb Æ size>=lb and self.rb Æ size<=hb) context B
inv: self.ra Æ size>=la and self.ra Æ size<=ha)
Generalization/specialization relationship may have several types of constraints 0, but only few of them must be implemented in information system. <<Complete>> constraint on specialization/generali-zation relationship means that instances of subtypes include all instances of super type. Disjoint constraint means that sets of instances of subtypes do not overlap. In UML, constraint tags may be added in bra-ces beside lines connecting the relevant subtypes, as shown in Figure 6. The following four keywords are predefined in UML for this purpose: "overlapping" (the subtypes overlap), "disjoint" (the subtypes are mutually exclusive), "complete" (all subtypes have been declared), and "incomplete" (some more sub-types may be introduced later). If generalization rela-tionship is not constrained, then subtypes may overlap and do not include all instances of super type. “Complete” constraint on generalization/specialization relationship connecting two subclasses B and C with super class A can be expressed using the following expression:
context A
inv: self.B Æ exists(b|b.A=self or C Æ exists(c|c.A=self))
prevents the inverse of the relationship between two different instances, i.e. an instance of A has associa-tion with instance of B and inverse relationship cannot exist. “Acyclic” constraint prevents a “cycle” such that an instance cannot be the parent, grandparent etc of itself. An acyclic constraint implies asymmetric and irreflexive. “Intransitive” means nobody is a parent of any of his/her grandchildren, i.e. alternative links bet-ween instances cannot exist. “Symmetric” constraint requires the existence of inverse association. “Anti-symmetric” constraint prevents from inverse relation-ship as “asymmetric” one, but differently from it al-lows the same instance to participate in both constraint roles.