Constraints On Specialized concepts Relationships

Started by usama, May 23, 2022, 22:15:49 PM

Previous topic - Next topic

usama

If there is two data objects that one of them aggregate the other.
For these data objects there is others who have specialization relationships with them.
I want to add some exceptions to the relationships between these "specialized data objects" that prevent certain specialized data objects from aggregating the other specialized data objects.

Phil Beauvoir

Hi, if I understand you correctly you want to over-ride the ArchiMate relationship rules in special circumstances. These constraints are fixed in Archi, they can't be changed in accordance with user-driven constraints.
If you value and use Archi, please consider making a donation!
Ask your ArchiMate related questions to the ArchiMate Community's Discussion Board.

usama

#2
Thank you for reply, I think the structural relationships are constraints that shaping the system. If creating a custom relationship (specialization), would it make a sense to have negative meaning like not part of or not aggregate meaning. The assumption that relationships are exists for preventing otherwise to be exists within the elements, implies to show all the relationships even if the relationships are too many relative to the negative relationships.

Is there any convention way to solve this?

Jean-Baptiste Sarrodie

Hi,

Quote from: usama on May 25, 2022, 00:23:56 AMwould it make a sense to have negative meaning like not part of or not aggregate meaning. The assumption that relationships are exists for preventing otherwise to be exists within the elements, implies to show all the relationships even if the relationships are too many relative to the negative relationships.

This question would be better asked to the ArchiMate User Comunity (read here for more info).

That being said, I once had a discussion with Tom Graves about this topic. In short, yes, negative or "anti-" relationships are useful in Enterprise Architecture (and ArchiMate metamodel specialization is a good way to define them). A good example is "anti-trust" coming from "anti-clients": this can be modeled as a specialization of Flow. Of course, any relationship can have its negative alternative (as you said, it can be useful to model that something can't aggregate something else).

My only concern is about the potential issue with readability and analysis. In some cases, it might make sense to model a Constraint associated with some elements.

Regards,

JB
If you value and use Archi, please consider making a donation!
Ask your ArchiMate related questions to the ArchiMate Community's Discussion Board.

usama

Thanks JB.

Yes, I see the anti- relationships are helpful, and the constraints in the model are more clear, but i still wondering if the specialization can change the main meaning of the concept, if so, what is then the meaning of specialization.

ChampagnePerry

Hi,
I don't know if I've understood your question properly.
Would this describe the situation with your data objects?
Screenshot 2022-07-04 144013.png
The implication here (though more explicitly in UML than ArchiMate probably) is that because Special Concept C is a specialisation of Data Concept A then Special concept can also aggregate Data concept B or any data concept it is a generalisation of.
What you would like to do is create an aggregation that overrides this implicit behaviour in the specialised concept?
Would this (with a bit more thought and context) be the kind of thing you are after?
Screenshot 2022-07-04 150204.png
You may have to be a little more implicit that your <<aggregation override>> overrides the inherited relationship somehow.
Regards
PP