The whole notion of grouping is one that we need to address, and I've put some thought into this area. However, the 'diagram' notion is the display of a random collection of elements. Elements can be included multiple times in the same diagram and/or multiple diagrams. Diagram was not designed for formal grouping, and is probably not the best mechanism for formal subgroups going forward.
If the goal is to formally group elements, then we need significantly more structure than the completely unstructured many-to-many current working plan is as follows:
Allow the modeler to create as many named groups as they like
Allow the modeler to associate one or more 'GroupTypes' with each named group
Allow each extension metamodel (not that the NORMA archtiecture treats all metamodels, including ORMCore and ORMShape, as extension models) to define 'GroupTypes'
Add type and overlap restrictions to each GroupType. Some GroupType examples could be:
GT1 must be associated with at least one Group. Every ObjectType must be included in some Group with a GT1 type, or some group with GT1 must be marked as the default group for GT1. No ObjectType may be included in more than one Group that is associated with GT1.
GT2 does not have to be associated with any Group. Any ObjectType, FactType, or Constraint can be added to a Group with type GT2. Items can be placed in more than one Group with type GT2.
GT3 can be associated with any number of groups. Any type of object may be associated with a Group of GT3 type, and items cannot overlap with other groups of the same type.
Each item in a group must be recognized by at least one of the associated group types. Items in a group that are not of the type considered by a GroupType will be ignored for that type.
A subgrouping mechanism would be provided [this part needs work]
Given this mechanism, the relational mapping layer could define GroupTypes for 'Database' and 'Schema'. 'Schema' would be a subset of DB. Each ObjectType could be in multiple DB's but only one Schema per DB could contain any ObjectType (note that the Schema GroupType with a single Database assumed is similar to GT1 type above). Another GroupType would support grouping elements for reports (elements can overlap, similar to GT2). Another GroupType would indicate workitems (similar to GT3, a group could be created for 'Matt's workItems' with a GroupType of 'WorkItem' and item's requiring work could be added to it). Clearly, a general grouping notion could be extremely useful for managing a large model.
As far as when we could get this done: I'd like to do it relatively soon (within the next two to three months). The main issues are with the relational pieces, which currently assume that a single schema is generated from the model. Clearly this 1-1 assumption would need to change.
Once grouping is in place, there are two approaches we could take on the relational side to allow you to get multiple schemas and/or databases out of the same model.
Consider the groupings before we do absorption on the model (think of absorption as determining which ObjectTypes get tables). This is very difficult because we would have to run multiple absorption algorithms across the model.
Consider the groupings after absorption has been determine, ignoring groupings for ObjectTypes that do not map to tables. This is definitely something we could do, and does not preclude switching to 1 in the future.
Other future features would allow a model/submodel relationship with external model references (etc), but we need grouping within a single model with or without externals, and would like to be very solid on a single-model setup before moving into submodels/externals.
Please comment. -Matt