Does TP-VML consider to cover also modeling constraints and guidance? Having these set in its metamodel would allow creating only syntactically “legal” models. Examples of such constraints are mandatory values, uniquenesss, legal kind of connections between elements etc.
TP-VML is meant as a graphical equivalent of the Task Planning model (or you might think of it as a meta-model, which is also correct). The TP model is defined here.
At the moment, the TP-VML document uses a set of draw.io elements which are not semantic, i.e. they don’t know about the meta-model. However the Better ArchetypeDesigner does, and it has a visual mode, based on the TP (meta-)model.
Things are still moving both at the TP level and also at the level of graphical representation. If you are thinking of supporting it in a tool, please let us know your ideas and needs.
Thank you for the reply. Yes, we were thinking about supporting language users via the various constraints and guidance, like not using the same name multiple times (e.g. for task plans), or enforcing that logic is complete (as illustrated in the figure showing that ‘AND logic’ is not completely defined).
Such constraints and guidance would greatly improve the quality of plan models and this way also their value and usability.
I assume what you mean by ‘completely defined’ is that a particular group (parallel or decisional) has all paths joined from its start to its end. A tool would know that the node marked ‘AND logic’ and the 3-dotted closing node are a pair, and that all of the outgoing paths from the former have to arrive at the latter. Probably we should formally define those rules.
Another thing not yet documented but partially implemented by the Better Archetype Designer tool is the ‘compression’ of ‘tail joins’ e.g. this kind of thing:
We will develop rules to determine what group-closing nodes can be dispensed with (at least sequential group ones can be removed), which will improve graph readability. If you have ideas on this from your tooling, feel free to share.
Yes, joining all paths is one example of having complete task plan, and there are numerous others too, like that work plan must contain at least one task plan etc. Others include having empty subtasks defined, uniqueness etc. Some of these are typically defined in the grammar/metamodel and others are expressed with some constraints languages (e.g. OMG uses OCL).
Not sure about Better Archetype Designer, but in our case (MetaEdit+) several persons can edit the same task plan at the same time. E.g. you could define the main and I could work at the same time with details of subtask, or modify the elements in the task model you are editing at the same time. This sets some new constraints to think about too.
These kinds of things are easy to specify, and we have not specified all such invariants, e.g. not WORK_PLAN.top_level_plans.is_empty etc. If you have a list of such constraints, please post here, we can discuss quickly and get them added to the model.
I don’t have a ready list of constraints to be considered, but see that the metamodel should be reviewed by considering what is needed to have syntactically complete and consistent design. The type of constraints would be on mandatory values, unique values, min number of connections, max number of connections, etc.
Another step would consider constraints related to usage, like can several work plans refer to the same task plan (and reuse is allowed).