pytm
pytm copied to clipboard
izar
Initial TM creation is a pain and requires a lot of typing
... well it was anyway.
https://github.com/izar/pytm/commit/9bccd8f45d5ce440b1f42f40ef8d62097cd45823
I added a python script to take a CSV with pairs of elements. I then create generic Element definitions for each unique name and create dataflow for each pair.
After editing the file to replace Element with Actor, Server, Process, etc I can generate a basic TM DFD then start to annotate each element and add boundaries as needed.
Before I do any more with this take a look and lets discuss. Initially I wanted the csv to be as lightweight as possible but we could have it contain various more data like variableName, displayName, element type, or various annotations.
I've committed the geneate.py file, a sample csv, the generate sample.py and sample.png and then a modified (Element->Actor,Process, etc) py and png so you can see what its doing.
That's an interesting idea, but I have a bit of an allergy to CSV files due to them leading to Excel tomfoolery and, well - having CVS files that include stuff that eventually ends up in Python code.
I've been battling excessive typing by using snippets on my editor.
You can say that with a straight face with the 'eval' calls in this code ; )
Could be another format, maybe JSON. As currently implemented (only variable names) it could have simple validation, likely just alphanumeric.
One of my submitted PRs has a modification which goes with this. I changed the name on Elements to the actual name instead of the hash of the name on the DFD and the color is red. I also made out of Scope elements a box instead of a circle.
With these changes looking at the DFD it is clear which items are still Elements.
Hey at least there's a caveat in the README about the eval, and threats.py is supposed to be more-or-less stable and write-protected...
Elements was supposed to be a parent class - not something to be represented. The Process is supposed to be the smallest granular "element" in use.
My thought was to use the Element as just a temporary state to when generating the base TM , the next step is to change all Elements to their appropriate type.
and just kidding about the eval, you are correct it is a threat that needs to be addressed. : )
Since we already have json input, is this issue still valid? Can we close it?
I'm pretty sure that, after two years of no response, this issue can be closed.
I hope the JSON input is also documented. ;)
