nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

The Trashbin

medini_1024169437

Besides the need to create objects by scripts, there is obviously also the need to delete objects. However, deletion is a critical action in a tool, there might be dependencies that need to be handled or even things that prevent deletion. For that reason we intentionally disabled any deletion or rearrangements via the scripting API in the beginning.

Similar to the Factory we then started to provide a script library that supports the deletion of objects and models to come closer to what is needed to delete stuff and to a deletion API. This trashbin.js called library has been used in a few scripts now with mixed results. The main problem is still that deletion needs a careful hand so any script that deletes any object has to make sure that it does things right. An example:

// delete the selected element
if (selection && selection.length == 1) {
 Trashbin.deleteElement(selection[0]);
}

This snippet simply deletes any selected element without checking it. This may cause serious damage to the project, stated as simple as that. For example, the tool does not allow the deletion of elements in FMEA worksheets, they are derived from system elements. In addition, when deleting system elements, also their "proxies" in FMEA worksheets are deleted, the user is notified about that and has to confirm. The trashbin.js library has no support for that. However, a few basic consistency rules are always followed when deleting elements:

traces to or from a deleted object are removed too
same holds for relationships, connectors etc.
contained elements are recursively removed

The library in its latest version is attached to this topic. Note that this version copes correctly with model objects in contrast to previous versions of the library.

Find more posts tagged with

medini

medini legacy

Accepted answers

All comments

medini_1004872874

Hi Jan

Where is attached the latest trashbin.js I can not find it ?

Florent

medini_1024169437

The latest trashbin library (2017-09-13) finally attached. My first attempt was somehow not accepted. Note that the library is provided as usual "as is" without warranty of any kind.

medini_1004872874

Hi Jan

I have an issue because in this new trashbin.js :

if (element.prototype == Metamodel.sysml.SysMLContainerPackage) {

throw "elements of this type cannot be deleted - not supported";

}

SysMLcontainerPackage are not supported while it was ok with the previous one...

How can we deal with that ?

Because i need it

Florent

medini_1024169437

Hi Florent,

I commented this out because the following problem: all elements that may contain elements in sysml are inherited from container package, so parts, packages but also models. The later is the problem because deleting sysml models had caused the same problem as deleting requirements models. The new library actually could fix this but for that I have to distinguish between a system model and *other* instances of container package so parts, packages etc.

If you are sure that you do not delete system models, you may just remove those three lines in the library. Or we may add more lines above to support other types. What do you want to delete?

Jan

medini_1004872874

It seems ok when I remove these three lines..

As I remove package by name it is alright..so enough for today..

medini_1024169437

Update: An updated version of the very same library attached to this thread. It is now able to handle cases, a user deletes the same object multiple times.

Happy Scripting

Jan

medini_1028367136

Hi Jan,

I am trying to use the trashbin to delete a "faults relation" between two failures.

When I log the "faults relation" to the console I see:

"de.ikv.medini.metamodel.safetyModel.impl.FailureRelationImpl@12a5f193 (diagnosticCoverage: null, condition: null, probability: null)
"

so I know I have the right object in memory. Now I want to delete this object. I know that I must use the function "Trashbin.deleteRelation". But that function would require that I already know the source and target of the object in memory.

Is there a way to easily delete a "faults relation" between two failures without knowing what those failures are in the first place?

Thanks!

medini_1024169437

Hi Roy.

I have to think about it a bit, maybe its feasible to use deleteElement on it but I have to make sure its working.

For the meantime I propose that you simply use the cause and effect attribute, so

var relation = ....
Trashbin.deleteRelation(relation.cause, relation.effect, Metamodel.safetyModel.FailureRelation);

Jan

medini_1036016653

Dear all,

for some larger script, I require to first delete all children (packages/parts/ports/failure modes) from a selected entry of the model browser. Therefore I created a small helper function that you find below, together with an examplary call:

function deleteChildren(scope, type) {
	// create finder based on scope
	// search for all contained items of specified type
	// delete using "trashbin.js" library from ANSYS
	var myFinder = Global.getFinder(scope);	
	var result = myFinder.findByType(type).asArray();	
	for (var i = 0; i < result.length; i++) {
		console.log("delete item {0}: {1}", i, result[i].name);
		Trashbin.deleteElement(result[i]); // https://medini.freshdesk.com/support/discussions/topics/1000086044
	}
}

...
load(trashbin.js);
...
deleteChildren(selection[0], Metamodel.safetyModel.Failable); // packages/parts/ports
deleteChildren(selection[0], Metamodel.safetyModel.FailureMode); // failure modes

Please note that I disabled the paranoia regarding system models in trashbin.js. Please refer to this snippet:

	if (element.prototype == Metamodel.sysml.SysMLContainerPackage) {
		// NOTE: P. Ploß 2020-03-20: SystemModels may not be deleted, and according to Jan Mauersberger he found no good way for distinguishing those and packages
		// https://medini.freshdesk.com/support/discussions/topics/1000086044
		return false;
		// throw "elements of this type cannot be deleted - not supported";
		// return true;
	}

Best regards

Peter

medini_1024169437

Nice, thanks Peter for sharing.

Jan

medini_1036016653

Dear Jan,

now I'm experiencing the same issue as Roy Gomez-Mendoza. I'm unable to delete a relation between two failure modes describing cause and effect. I tried your suggestion but, as can be expected from inspecting Trashbin.js this fails with an unsupported error message, as "Metamodel.safetyModel.FailureRelation" is not a supported type.

Unfortunately I'm in need of this functionality rather urgently. Could you please take a look?

This is a snippet I intend to use to iterate over all failure modes that is a list I derived using the finder:

for (var i=0; i<targetFMs.size(); i++) {
			//targetFMs.get(i).causedBy = []; // reset causes
			//targetFMs.get(i).effects = []; // reset effects
			// for removing causes/effects, the relation needs to be lifted "Metamodel.safetyModel.FailureRelation"
			var FM = targetFMs.get(i);
			console.log("delete causes/effects of FM [{0}] {1}", FM.mediniGetContainer().name, FM.name);
			var relations = FM.relations;
			for (var j=0; j<relations.size(); j++) {
				console.log("delete FM''s relation {0}", j);
				var relation = relations.get(j);
				var delRel = Trashbin.deleteRelation(relation.cause, relation.effect, Metamodel.safetyModel.FailureRelation);
			}

The two commented out lines were my first naive try of lifting the causes/effects relationships, but guess what -- it is not so simple :-)

The metamodel documentation merely states:

"The basic capabilities of the failure net is defined by FailureRelations. Each cause/effect reference is
contained in the causing failure instance via relations. Navigation to both ends is on the one hand supported at the relation via cause and effect ends, and on the other hand directly at the failure via the derived attributes causedBy and effects."

Thank you for your assistance

Peter

medini_1036016653

... and a warning to the adventurous:

// don't do
// FM.relations.clear();

as this prevents you from saving your project:

Error while saving project resource: 'platform:/resource/scriptFTA-AET/sysml/_8wGxcAF0EeqHo_BSSSuSCw.sysml'
Could not read from source when writing file 'C:\Users\xx\Documents\Analyze Workspace 2019 R1\scriptXX\sysml\_8wGxcAF0EeqHo_BSSSuSCw.sysml'
The object 'de.ikv.medini.metamodel.safetyModel.impl.FailureRelationImpl@2e5d37b4 (diagnosticCoverage: null, condition: null)' is not contained in a resource.

... at least I think this is, what happened.

Enough for today.

medini_1024169437

Peter and Roy,

I had another look and I think for time being the only chance (and probably the right way to do it!) is to remove the relation object as if it would be a normal object,

so using Trashbin.deleteObject(relation); There are some very specific consistency rules that are NOT considered when doing it this way, but if you anyway just remove

also the failure modes, you should be fine.

I improved the Trashbin.js in a way that it also support the deletion of normal SysML packages (so the modification done by you Peter is not required anymore).

Find a beta version of it attached. Note that I did not had to change anything related to the relation itself.

Happy Scripting

Jan

medini_1036016653

Dear Jan,

for that newer request of mine, I would *only* delete rthe relations, but not the actual failure modes. There is basically a switch that either deletes all failure modes (brute-force) or only removes and recreates relations of failure modes (if they exist).

Should I still give deletion of the relation object a go or should I be worried about the model's consistency?

Best regards

Peter

medini_1024169437

Well, I think you can. There is only a problem if the failure rate of a failure mode is based on its causes.

In that cases you need to care about that yourself as well.

Jan

medini_1036016653

Dear Jan,

I tested your suggestion, and it works with a small change, as the function call is to "deleteElement()" and not "deleteObject()". Here is a snippet that shows usage on how to delete a failure mode's causes relations and effects relations using a small helper function:

function deleteRelations(oRelations) {
	// oRelations	list of relations, e.g. FM.causedBy or FM.effects with FM being a failure mode
	// TODO: add type check
	for (var j = 0; j < oRelations.size(); j++) {
		console.log("delete FM''s relation {0} of {1}", j, oRelations.size());
		Trashbin.deleteElement(oRelations.get(j)); // https://medini.freshdesk.com/support/discussions/topics/1000086044
	}
}

...
deleteRelations(FM.causedBy);
deleteRelations(FM.effects);	
...

Your new trashbin.js also works without issues (I replaced my adjusted version).

Best regards

Peter

medini_1024169437

Perfect, thanks for the feedback Peter!

Jan

medini_1036016653

Dar community,

yesterday evening I should have implemented the type check (marked as a TODO), as it would have prevented me from posting a wrong solution. It actually deleted all the failure modes being causes and effects, whereas the intention is to lift merely the relations between failure modes. Here is the updated solution with proper type checking:

function deleteRelations(oRelations) {
	// oRelations	list of relations, e.g. FM.causeRelations or FM.relations with FM being a failure mode
	// https://medini.freshdesk.com/support/discussions/topics/1000086044
	var nRelations = oRelations.size();
	for (var j = 0; j < nRelations; j++) {
		// console.log("- delete FM''s relation {0} of {1}", j, nRelations);
		var oRelation = oRelations.get(0);
		if (oRelation.prototype == Metamodel.safetyModel.FailureRelation) {
			Trashbin.deleteElement(oRelation);
		} else {
			console.log("ERROR: invalid relation type");
		}

	}
}

..
deleteRelations(FM.causeRelations);
deleteRelations(FM.relations);	
..

Best regards

Peter

medini_1024169437

Haha, yeah I know this situation.

Btw. since ... I actually forgot the version but at least 2019 R3 you can use native "instanceof" JS operator, so

oRelation.prototype == Metamodel.safetyModel.FailureRelation

will become

oRelation instanceof Metamodel.safetyModel.FailureRelation

Advantages: looks nicer, better readable and "instanceof" considers sub types as well

Disadvantage: it ALWAYS considers subtypes, so there is no separation like in OCL oclIsType and oclIsKind

Jan

medini_1055920722

I wanted to remove elements from hardware architecture. I made a script which helps me do so.

Input to script = name of the element/component to remove. (variable: name)

Below is the code:

//----------------------------------------------------------------------------

//-------------------------------------------------------------------------

For some components/elements this script throws an error (SS attached).

Is something wrong?

medini_1024169437

This specific error is caused by

dcLevel(entry.the_owned_elements[i],name)

Attributes and references with multiplicity > 1 are always lists, not arrays. So you have to change that to:

dcLevel(entry.the_owned_elements.get(i),name)

Anyway, I think its not a good idea / feasible to remove DC worksheet entries, because these entries are always kept in sync with the system model. I would expect that they are recreated once you open the DC worksheet. Do you want to remove the system elements instead?

Happy Scripting

Jan

medini_1055920722

I made the required changes. It's still throwing error. Screenshot attached.

Regarding your question,I wanted to remove system element which automatically will remove from dc worksheet.

medini_1024169437

Ok, so the selection is done on the system model not DC worksheet, right? All good.

Hm, I was so keen on spotting the problem that I overlooked something as it seems.

(and [i] is internally mapped to get(i) for Lists I have learned) so that's not the final problem.

I think the problem is that you delete elements and while you are doing so, the "the_owned_elements" collection is "shrinking", basically the list is reduce and the last index (here 7) is not valid anymore.

You either have to rely on size() on each loop or collect the elements to delete first in a separate array and remove them after the loop in a second step.

Jan