This is not possible now. Why they should? Currently boundaries should be used to group assets.

They mean different things, I think. A collection of objects may live within a single trust boundary, but you may have multiple such collections within 1 boundary. A collection should also have detectable attrs - such as isHardened which represents state of the items in a collection vs individual objects.

What is SetofProcesses representing today?

btw isn't this a dup of #10?

I think that regarding Server's internal objects, it should be more of a Level-n issue on DFDs. A level N diagram has server/client, a level N+1 diagram has server internals. We do need a way to link these diagrams together, and to produce separate diagrams from one single model.

That's what #75 is about

Ok, so now we have the --levels functionality but that is not a solution to this problem here. What should we call the "container" construct that wouldn't be a loaded term like container? I am thinking something represented like a trust boundary (as a fence around the elements) but without any of the semantics. Just a graphic construct on the DFD embracing all the elements that need to be grouped together.

Thinking more on this topic recently.

Collections (i.e. Elements that embed other Elements, if you were to decompose them) introduce an inheritance requirement.

Boundaries (drawn as enclosing rectangles) are used by some in threat modeling for:

• A group of Elements at the same decomposition level that establish trust
• A logical network boundary (such as a network subnet, or a datacenter environment)
• A logical operating environment boundary (such as a Kubernetes cluster, since Kubernetes is not a singular Process, and modeling all processes that make up a k8s env can be very busy and cumbersome, and sometimes models don't need to be perfect)

Boundaries should support nesting.

I also want to separate the meaning of Boundary used currently from the shape that is drawn on a DFD. Consider the k8s example above: k8s might be a type of Process with specific attributes and controls. It might contain other Elements (e.g. those things that operate within the k8s env), and may communicate with external entities. In a DFD, it would be useful to draw the k8s env as a boundary shape, and allow objects to live within it. The same might also be useful to AWS or Azure cloud environments; today some of our Elements has onAWS as a property, which should be rethought imo.

I suppose one could create a Boundary (existing class) for the enclosing k8s cluster, and a Process to represent the operating model components (k8s' kubelet, API server, etc) that lives within the Boundary. Some additional properties are probably required to address this. A future enhancement might be to create a shortcut function or object that will create both Boundary and Process together rather than a developer needing to remember to do both.

I'm considering some other adjustments for an incubation branch. I will look to mock something up related to this and we'll see what is workable.

But doesn't that take us back to Process of Processes (double circle) ?
Perhaps a Boundary is a Container with the added property of Trust Change ? Then (to avoid PofPs), we could have containers hold just as many elements as needed to illustrate the dataflow in and out (not every container will have a single entry/exit point for dataflow) and we could have an extra check for a TM having sub-TMs of each Container.
(Container is probably a too-loaded word at this time).

I'm not sure it needs to, maybe using SetOfProcesses(Process) but changing the shape to a boundary-like shape, and adding some additional attributes. We need a better name than Container (and something other than SetOfProcesses) if we go this route; although an alternate might be Process can have some flexibility, such as having decomposing information and different drawn shapes based on some key attributes.