Suggestion: Orthogonal boundary

[skiwi]

When using the boundary common artifact a rectangle only goes so far.

I suggest a boundary where extra sides can be added with internal and external right angles.

This would make it much easier to use a boundary in some diagrams.

(orthogonal boundary - cf orthogonal line style)

And yes, I know this is a diagram enhancement suggestion, so I'm not holding my breath, but if anyone likes it as I idea we could both put in a feature request

[skiwi]

Examples to clarify the above

[Paolo F Cantoni]

I like it!  Gets my vote!

Also with rounded corners please!  

I suspect that once we get more than simple rectangular, it might be almost as easy to give us Custom Shape.  It's already here with curves - setting a new way-point and moving that, so...   8-) 8-)

Paolo

[Eve]

I think what needs clarifying isn't so much what you mean, but how would you use this to improve the communication of your diagrams?

I assume there would be some element that isn't in the boundary in the cut-out space. So why is a cut-out better than moving that element? The contents of a rectangle is extremely easily interpreted. Much more so than the contents of irregular shapes.

[skiwi]

I am using a boundary rectangle to, say, conceptually group and highlight specific part of a diagram.
Using a similar method to orthogonal connections to add edges would allow the shape to be adjusted to encapsulate the desired objects.

[Eve]

So why is a cut-out better than moving that element?

Or elements. As I said, there are basic perception issues with irregular shapes. I'd want an example that justifies making that happen before I'd agree with the suggestion. The closest I can think of is trying to preserve a layout that includes direct horizontal and vertical links. But when I picture that, it only adds to the confusion I see in your proposal.

[skiwi]

So why is a cut-out better than moving that element?

Simply because of the layout,desired or space available on a diagram.

[Paolo F Cantoni]

So why is a cut-out better than moving that element?

Simply because of the layout desired or space available on a diagram.

+1

The Rectangular notation is just that because of the (reasonable) desire to create a consistent shape to the vertex and the contained features and compartments.  In this case, rectangle (with or without rounded corners) is the most "efficient".

When I'm NOT displaying the features and compartments - then ANY shape is valid - see the non-rectangular shapes of the various ICONS etc.

Since I can draw a shapescript to make the edges of ANY element (including boundaries) any custom shape I desire, it seems unnecessarily constraining to not allow the definition of such an "on-the-fly" Shapescript - which I submit is what it is.

When you are visually embedding objects inside each other, constraining the aggregate shape (of even an element - never mind a boundary) is just that: a constraint on communication.

I hope I've correctly expanded on skiwi's summary.

Paolo

[qwerty]

Why not simply ask for a polygon where orthogonal angles would be achieved via the same algorithm as is being used for connectors?

q.

[HarryPlotter]

I think what needs clarifying isn't so much what you mean, but how would you use this to improve the communication of your diagrams?

I assume there would be some element that isn't in the boundary in the cut-out space. So why is a cut-out better than moving that element? The contents of a rectangle is extremely easily interpreted. Much more so than the contents of irregular shapes.

We often have similarly laid-out diagrams used to illustrate (for example) class model representation of particular states, or ad-hoc business processes relevant to a particular user goal, or 'similar-but-different' business processes, or 'before-and-after' component/deployment models.

This is a case where a 'cutout' would be useful - effectively a irregular group boundary.

[skiwi]

I hope I've correctly expanded on skiwi's summary.

+1

[skiwi]

Why not simply ask for a polygon where orthogonal angles would be achieved via the same algorithm as is being used for connectors?

My thoughts entirely

[Paolo F Cantoni]

Why not simply ask for a polygon where orthogonal angles would be achieved via the same algorithm as is being used for connectors?

My thoughts entirely

So just to be clear...  Shape scripts can detect whether or not the rectangular notation checkbox has been marked or not.  They can react however they desire to that input (see some of the ArchiMate 2 shapescripts - Requirement I think - where neither setting produces a "drawnativeshape" command - but instead two different icon shapes).

That notwithstanding, we are looking for a new variant on polygon:  IrregularPolygon( int centerx, int centery, int numberofsides,  int radius,  float rotation)
Where this defines the INITIAL (regular) polygon, and thereafter you can adjust it on the diagram as required.

Have I got it?

Paolo

[qwerty]

I was simply thinking of a series of x|y coordinates which can form any object with a single stroke. You 'could'  create such polygons with connectors by adding break points already by starting/ending at an invisible boundary (awkward, I know).

q.

[Paolo F Cantoni]

I was simply thinking of a series of x|y coordinates which can form any object with a single stroke. You 'could'  create such polygons with connectors by adding break points already by starting/ending at an invisible boundary (awkward, I know).

q.

For my purposes at least (and, I suspect, skiwi's) we need to be able to see the resultant shape as an object in its own right.  This is the difference between drawing pictures and rendering models.  The collection of shapes is itself an object.  

In our unified modelling methodology, we envisage a number of "collection shapes":  Specialization Sets (the correct name for Generalization Sets), Composition Sets, Aggregations Sets, Association Sets etc..  You can provide relations to the Set object implying that the relationship apples to all the items in the set.

Paolo