mike1813
commented
3 months ago Now partially addressed in branch 107. The inferred Process-Data interactivity relationships are still inferred, but we don't also generate extra tagging relationships to signify that such an inference has taken place, and hence we have no modelling errors warning of this.
Pattern HuirPeI-OD-p-cC-iHu-DS+c adds an inferred 'Process-creates-Data' relationship where an interactive user enters data and there is no Process-Data relationships, but not yet a 'Process-inferredCreates-Data' relationship tagging this as inferred.
Patterns HuirIPaD+aD, HuirEc-rD+iD, HuirEr-vD-cC-iHu-DS+iD, HuirPr-vD-cC-iHu-DS+iD, HuirIPp-iD+vD, HuirPc-iD-rC-vHu-DS+vD, HuirPr-iD-cD+vD and HuirPaD+eUI-O+vD have been retained. These add inferred 'Process-enablesUserAccess-Data' relationships but not yet 'Process-inferredUserAccess-Data' relationships.
Since the tagging relationships are not yet generated, there are as yet no modelling error threats signalling this to the user.
The user interactivity model has now been updated to address issue #107. One of the changes needed was removal of construction patterns that infer Process-Data interactivity relationships (subtypes of 'enablesUserAccess') based on the presence of Human-Data relationships involving the interactive process user (subtypes of 'interactsWithData').
These are not the only construction patterns that create Process-Data interactivity relationships. Other patterns determine that such relationships must be present by finding cases where data must come from the user because it has no other source, or go to the user because it has no other purpose. In the interests of backward compatibility, these patterns were retained, so system models that don't specify Process-Data interactivity relationships explicitly will continue to work.
In addition, some new patterns were created that infer the presence of Process-Data processing relationships (e.g., 'receives' or 'creates'), based on the presence of Process-Data interactivity relationships. For example, if there is an 'enablesUserInput' relationship, it means the process must 'receive' the data from its user (it is used as input, if only to be forwarded to a consumer or storage process).
Where there is an 'enablesUserOutput' relationship, it is possible that the Data displayed to the user may have been obtained from a stored copy on the process host, received from some other process, or created locally by the process. To cover the latter possibility, a further inference pattern was added, so user output is assumed to be computed within the process if it has no other source (i.e., if not stored anywhere, created by any other process, nor input from any other user).
This deduction involves no ambiguity, if we assume the lack of any other source is correct. However, it may be that the system modeller user simply forgot to insert a relationship to the data from some host, process or user. This may also be the case for some patterns not removed in addressing #107.
There are two options for addressing this issue:
This has the advantage of removing all ambiguity from this area of the domain model. However, it has the disadvantage of forcing users to use two Process-Data relationships for interactive processes that get data from or display it to the interactive user. It also means many existing system models will not work at all until the system modeller user adds these extra (previously inferred) relationships.
We don't want to force system modeller users to do a lot of work to update their existing models, so on balance, the second option is the best way to address this issue.