instances with defined values for attributes v1,…,v2 is a subset of the set of object type A instances with defined values for attributes p1,…,p2. OCL expression for this constraint can be the following:
context A
inv: not(self.v1.isUndefined()) and not(self.v2.isUndefined()) … and not(self.vi.isUndefined()) … and not(self.vn.isUndefined()) implies
not(self.p1.isUndefined()) and not(self.p2.isUndefined()) … and not(self.pi.isUndefined()) … and not(self.pn.isUndefined())
Subset constraint on optional relationships can be expressed graphically therefore we don’t need OCL expressions.
Exclusion constraint between relationships with other object types indicates that at any given time every instance of class may participate in at most one of these relationships. Analogously exclusion const-raint between class attributes indicates that at most one attribute can have value 0, 0, 0, 0, 0. To indicate
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
this, UML uses an “or” constraint between the associations, attaching the constraint tag “{or}” to a dotted line connecting the corresponding associations. UML or-constraints can only be used between associations (Figure 9), and cannot be used between recursive associations, attributes, or between attributes and associations. For example, constraint that the same employee can be performer or inspector can be expressed as shown in Figure 9. For representation of exclusion constraint on attributes in diagrams we need to add constraint tag {orn}. The index indicates a group of optional attributes that may have at most one mandatory attribute. In general, exclusion constraint on a group of object A optional attributes c1,..,cn can be expressed using the following OCL expression:
context A
inv:(not(self.c1.isUndefined())implies self.c2.isUndefined() … and self.ci.isUndefined() … and .isUndefined()) and
(not(self.c2.isUndefined()) implies self.c1.isUndefined() … and self.ci.isUndefined() … and .isUndefined()) … and
not(self.ci data.isUndefined()) implies self.c1.isUndefined() … and self.ci-1.isUndefined() … and self.ci+1.isUndefined() … and .isUndefined()) … and
(not( data.isUndefined() implies self.c1.isUndefined() … and self.ci.isUndefined() … and -1.isUndefined())
important domain semantics making model more precise.
During modelling of many classes and relation-ships we can get relationships path from a class, through other relationships and classes, back to the same class where we have started. Such a path of relationships is called loop 0 (Fig. 10-11). It is important to find out such loops and to investigate if association loop means redundant information. Some-times it doesn’t and therefore we don’t need any additional constraints, but sometimes it does and it means that these loops have specific domain rules and policies such that sets of associations are interrelated. In this situation one of association from loop requires constraint like subset or equal set constraint on path of relationships. It means that not all instances of object type can participate in relationship but just instances participating in set of constrained relationships 0.
UML doesn’t have graphical representation of this constraint. In 0 and 0 the similar suggestions to display this constraint are given. The notation of constraints on relationships paths is shown in Figures 10-12.
Project
1R2
0..nTask
0..n
R3
R10..n
+initiator
1+performedAt
1
Department
Figure 10. Not-redundant loop (the tasks of the project may be performed at different departments)
Project
1R20..nTask
0..n
R10..n
+initiator
1+performedAtR3{equ,R1,R2}
1
Department
Integrity constraints on sets of instances of diffe-rent object types include constraints on paths on rela-tionships and, in particular, loops 0, 0. They are the most complicated constraints that may be expressed graphically (these types of constraints are considered in Section 7). Certainly, there are constraints defined by domain expert that cannot be expressed by conventional stereotypes. The conceptual language is needed for description of these constraints, for example, OCL.
Figure 11. Redundant loop with restricted association R3
7. Integrity constraints on paths of relationships
These constraints are the most complicated const-raints and are not considered at all in the most popular conceptual modelling methods. Only authors of 0 and 0 have analyzed paths of relationships trying to find out redundant, unconstrained and constrained association loops. In this section we will investigate constraints on paths of relationships showing the importance of these constraints enabling to capture