Closed filetp closed 7 years ago
I am not sure I can answer your question, because I cannot reproduce your situation.
What do you mean by " testing on atom values positively"? What do you mean by " testing on atom values negatively"? What do you mean by " checks for presence of one write access"?
After studying your files, I can see that rule TV008 produces one violation: "838". Or to be precise: [("838","838")] .
The two accessRelations you mention in lines 296 and 297 in the Archisurance.xml file are
<elements xsi:type="archimate:AccessRelationship" id="884" source="861" target="838" accessType="1"/>
<elements xsi:type="archimate:AccessRelationship" id="28daf23c" source="849" target="838" accessType="3"/>
These do not contradict univalence, because both application components (i.e. "861" and "849") have one data object each (i.e. "838"). If you want these targets to be distinct, that would be injective rather than univalent.
I notice a different thing. Your rule TV008 has the form
I[DataObject] /\ x ; -I[ApplicationComponent] ; x~ |- -I[DataObject]
with x
being
access[ApplicationComponent*DataObject]~ ;
isa[ApplicationComponent*ArchiObject] ;
source[Relationship*ArchiObject]~ ;
accessType[AccessRelationship*AccessType] ; -'1';
accessType[AccessRelationship*AccessType]~ ;
source[Relationship*ArchiObject] ;
isa[ApplicationComponent*ArchiObject]
I recognize that form, because it is the way to express univalence of x
, while producing violations of type DataObject
. However, x
is noteworthy too. It has the form access~;z;-'1';z~
with z
being
isa;source~;accessType
I guess that by z;-'1';z~
you mean that the target of z
should not be 1. Maybe you want to say that the application component must not have access type 1.
If that is the case, you may have your answer. For your expression does not say that the target of z
should not be 1. You should have written I /\ -(z;'1';z~)
instead. Even shorter: I - z;'1';z~
, because r/\-s
is equal to r-s
for every r
and s
.
So if I have guessed your problem correctly, your code should be:
access[ApplicationComponent*DataObject]~ ;
( I - isa[ApplicationComponent*ArchiObject] ;
source[Relationship*ArchiObject]~ ;
accessType[AccessRelationship*AccessType] ; '1';
accessType[AccessRelationship*AccessType]~ ;
source[Relationship*ArchiObject] ;
isa[ApplicationComponent*ArchiObject]
)
Reflection: Please try to think about making your issues more reproducible. That reduces your risk that I guess wrong. And it saves me some time guessing (or spending time on wrong guesses).
@filetp, please close this issue if you are satisfied with the answer.
Thanks so much Stef! Your assumption was right ;-) Definitive coding now reads:
RULE "TV008" : I[DataObject] /\ access[ApplicationComponent*DataObject]~ ; (I /\ -(isa ; source[Relationship*ArchiObject]~ ; accessType ; '1'; accessType~ ; source ; isa[ApplicationComponent*ArchiObject]~)); -I[ApplicationComponent] ; (access[ApplicationComponent*DataObject]~ ; (I /\ -(isa ; source[Relationship*ArchiObject]~ ; accessType ; '1'; accessType~ ; source ; isa[ApplicationComponent*ArchiObject]~)))~ |- -I[DataObject] VIOLATION ( TXT "Data Object \'", SRC naam, TXT "\' is maintained by more than one application")
This works just fine! I'll close the issue.
Issue solved
Rule TV008 tests univalence of access relations with write access (accessType = 3 or omitted) from ApplicationComponents to DataObjects. Rule TV008 is specified in the Archisurance.adl file.
The rule works fine when testing on atom values positively (e.g. access type is '3'). The rule then checks for presence of one write access as expected. But the rule does not work when testing on atom values negatively (e.g. access type is not '1')
Line 296 and 297 in the Archisurance.xml file contain the two accessRelations that are specifically tested.
I'm not sure whether this is an issue or not. There might very well be something wrong with my rule. What puzzles me is that the positive testing on atom values works fine. Is the rule incorrect or is this an issue?
Archisurance UNI-TV008.zip