Something such as:
- For each information I flowing from appProvider A to appProvider B then both A. an B. have to use I.
Another step would be to use PAL ...
Regards,
J.-M.
PAL constraints and essential
It would be handy to have some way to check constraints against the architecture.
Something such as:
Another step would be to use PAL ...
Regards,
J.-M.
Something such as:
Another step would be to use PAL ...
Regards,
J.-M.
-
jonathan.carter
Yes,
This is the sort of thing that - in the repository at least - Protege plugins such as the PAL constraints or Rule-engine plugins such as JessTab could help a lot with.
I see these as 'overlays' on the content of the model so capturing the content, defining the rules and then checking the content against the rules or constraints and then fixing up any problems in the model seems like a natural workflow.
Some of this already works at the meta model level, e.g. the Facet Constraints tab is helpful when trying to identify instances that do not comply with the constraints of the meta model. I think what you describe here is more about working at the model level (rather than meta model). Which is fine, and using things like PAL you can define constraints and then test them using FacetConstraints tab or PAL Tab in Protege. Note that Protege will not raise any errors with things that do not comply with the constraints as you build the model. You have to explicitly test them, which makes sense, I think.
That's on the Protege side but many of these kinds of things can also be highlighted by some queries in the Viewer. Perhaps in the Information Dependency model view, we might do some colour coding if we've got Information I flowing between A and B but no relationships showing A or B's usage of Information I.
The Viewer side of things is where we often put this kind of 'logic', which can be a good way of providing insights into where the model may not be complete. Or maybe that's just the way things are. Perhaps in your example A simply passes I on to B without doing anything with it (debatable point, perhaps…) so what we have in the model isn't strictly wrong…
It's quite normal - and we've done this with clients - to have views that are intended to be used to support the 'modellers'. For example, doing QA activities on the model are often easier from the Views rather than the highly normalised representation in the repository.
Hopefully, we've kept things open enough at the modelling side and especially at the Viewer side to be able to 'plug in' additional tools to provide what we need. That might be Views that use a Drools engine plugin to run architecture business rules against the repository snapshot and return the results via view.
There are some options. Where would you most naturally see this sort of capability fitting? Protege or Viewer?
Jonathan
This is the sort of thing that - in the repository at least - Protege plugins such as the PAL constraints or Rule-engine plugins such as JessTab could help a lot with.
I see these as 'overlays' on the content of the model so capturing the content, defining the rules and then checking the content against the rules or constraints and then fixing up any problems in the model seems like a natural workflow.
Some of this already works at the meta model level, e.g. the Facet Constraints tab is helpful when trying to identify instances that do not comply with the constraints of the meta model. I think what you describe here is more about working at the model level (rather than meta model). Which is fine, and using things like PAL you can define constraints and then test them using FacetConstraints tab or PAL Tab in Protege. Note that Protege will not raise any errors with things that do not comply with the constraints as you build the model. You have to explicitly test them, which makes sense, I think.
That's on the Protege side but many of these kinds of things can also be highlighted by some queries in the Viewer. Perhaps in the Information Dependency model view, we might do some colour coding if we've got Information I flowing between A and B but no relationships showing A or B's usage of Information I.
The Viewer side of things is where we often put this kind of 'logic', which can be a good way of providing insights into where the model may not be complete. Or maybe that's just the way things are. Perhaps in your example A simply passes I on to B without doing anything with it (debatable point, perhaps…) so what we have in the model isn't strictly wrong…
It's quite normal - and we've done this with clients - to have views that are intended to be used to support the 'modellers'. For example, doing QA activities on the model are often easier from the Views rather than the highly normalised representation in the repository.
Hopefully, we've kept things open enough at the modelling side and especially at the Viewer side to be able to 'plug in' additional tools to provide what we need. That might be Views that use a Drools engine plugin to run architecture business rules against the repository snapshot and return the results via view.
There are some options. Where would you most naturally see this sort of capability fitting? Protege or Viewer?
Jonathan
I was thinking about the Facet Constraints slot ... I think that Protege will not raise any errors in this case either.Some of this already works at the meta model level, e.g. the Facet Constraints tab is helpful when trying to identify instances that do not comply with the constraints of the meta model. I think what you describe here is more about working at the model level (rather than meta model).
Thanks for the detailed answer about the alternative locations where the QA activities could be done (viewer/modeller).... snipp ...
I'm inclined to think that constraint violations have to be checked as soon as possible. Then, my answer would be Protege.There are some options. Where would you most naturally see this sort of capability fitting? Protege or Viewer?
Note that I do not have a long experience with essential so if you think the viewer is a better place : go for it
.Finally, whatever the final location, I think that a good start would be to express in english the implicit constraints founding the metamodel... not an easy task though.
-
jonathan.carter
Yes, when we first started working with Protege (several years ago) I looked into defining PAL constraints for some aspects of the meta model. There are even a couple of these in the baseline repository to encourage each instance to have a unique name. However, what I found was that any violations of these are not reported by Protege until the constraints are explicitly tested, e.g. using Facet Constraints Tab or PAL Constraints Tab.
In that particular, the UniqueNameWidget was useful by immediately warning us of the fact that there is already an instance in the repository with the same name. However - and importantly - it doesn't stop us using that name. It's just a warning.
From a meta model perspective, the constraints are 'encoded' in the Classes and relationships between them and the export to formats such as HTML might help produce a more readable approach.
However, I think what you were originally describing sounds more like the need to define constraints within the model - the instances. These are more domain-specific and may only be valid to specific models.
Have I got this wrong? Is it a more prose-like description of the metamodel relationships and constraints that you are looking for?
Rather than defining new constraints, rather to explain the existing ones?
In that case, I think some sort of View would probably be the simplest way to produce something that describes the entire meta model in english terms.
BTW, have you tried the Jambalaya Tab plugin for a graphical rendering of the meta model and model?
Jonathan
In that particular, the UniqueNameWidget was useful by immediately warning us of the fact that there is already an instance in the repository with the same name. However - and importantly - it doesn't stop us using that name. It's just a warning.
From a meta model perspective, the constraints are 'encoded' in the Classes and relationships between them and the export to formats such as HTML might help produce a more readable approach.
However, I think what you were originally describing sounds more like the need to define constraints within the model - the instances. These are more domain-specific and may only be valid to specific models.
Have I got this wrong? Is it a more prose-like description of the metamodel relationships and constraints that you are looking for?
Rather than defining new constraints, rather to explain the existing ones?
In that case, I think some sort of View would probably be the simplest way to produce something that describes the entire meta model in english terms.
BTW, have you tried the Jambalaya Tab plugin for a graphical rendering of the meta model and model?
Jonathan
