In Figure 10, the loop is not redundant as sets De-partment.Task and Department.Project.Task are diffe-rent: tasks, belonging to Projects initiated by concrete Department, may be performed at different Depart-ment. In Figure 11, in contrast, tasks, belonging to Projects initiated by concrete Department must be performed at the same Department. In this case, the equal set constraint means that the set of instances selected by traversing a loop in one direction (Department.Task, or R3) has to be the same as the set of instances selected by traversing the loop in the opposite direction (Department.Project.Task, or R1, R2), according to the rules and policies of the domain. This constraint may be specified in OCL:
context Department
inv: self.Project.Task = self.Task
The same constraint may be expressed in a more practical way, by the principle of using for context
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
Representation of Integrity Constraints in Conceptual Models
class having the maximum number of instances (this means that if Project is initiated by some Department, then instances of Department.Project.Task, having association path R2, R1 with instance of Department, must have association R3 with the same instance of Department):
context Task inv:
self.Project.initiator=self.performedAt
The subset constraint on path of relationships may occur in a situation, when the set of instances found in one direction is a subset of instances obtained by traversing in other direction.
The second situation is displayed in Figure 12, when we have a class with reflexive relationship and mandatory relationship with other class. In this case we have to check if reflexive relationship can associate any instances. If not, besides earlier mentio-ned constraints for reflexive relationship we need to add a constraint on relationship path.
+after
ProjectstartDateendDate
R1
0..n
Taskdurationdescription
{acyclic,R1}R2discovering true types of objects in conceptual model, but they should be merged with stereotypes for integ-rity constraints for obtaining precise conceptual mo-dels suitable for transformation to executable software (every kinds of schemas and code).
The variable values of tags are different for groups of instances of stereotype (as stereotypes are attached to constrained elements of group on which integrity constraint is applied). They may be derived using OCL constraints included as part of profile. We accept, for example, that <<Integrity Constraint Stereotype>> is sub typed to <<Stereotype on Integrity Constraint>> and <<Stereotype on Constrained Element>>, and names of these stereotypes are the same for the same type of Integrity Constraint:
context IntegrityConstrait
inv: self.constrainedElementÆ
forAll(ce:Element|=
For tags, meta attribute is introduced for Stereotype-OnConstrainedElement:
context StereotypeOnConstrainedElement def: icname:String
Figure 12. Example of notation for constraints on relationships path for Tasks having reflexive relationship
and mandatory relationship with Project
The value of tag may be derived from OCL constraint on metamodel:
Context Class
Let i=self.IntegrityConstraintÆ select(i:IntegrityConstraint
|i.stereotypeName=’EqualSet’)Æ asSequence() in
iÆforAll(ic|ic.ConstrainedElementÆ forAll(ce:ConstrainedElement| =’EqualSet’ and ce.Stereotype.icName=
’equ’.concat(i.indexOf(ic))))
In Figure 12 acyclic reflexive association con-straint, restricted by association R1 denotes constraint on association between tasks: the concrete task cannot occur repeatedly after itself or somewhere in the sequence of tasks of particular Project (R2 {acyclic, R1}).
OCL constraint for general case of reflexive relationship for object type A having mandatory relationship with object type B (Fig. 13):
context A
inv: self.ra Æ
forAll(e:A|e.B=self.B) and self.raClosure()Æ not(includes(self))
9. Conclusion and future work
Precise definition of conceptual model is one step on the way towards automation of transformation of business information to the physical level where its’ processing may take place. In this paper UML is ana-lyzed as the most suitable notation for constructive conceptual modelling of problem domain and soft-ware. It is well supported by many CASE tools and widely accepted as standard modelling language. For obtaining precise conceptual model, the prob-lematic elements are integrity constraints. Currently, they are not comprehensively studied in UML related methodology of conceptual modelling. In current practice, constraints are usually deferred to the phase of detail design. In this work, the stereotypes are proposed for extension of UML for conceptual modelling of required variety of integrity constraints selected from outstanding methods of conceptual modelling.