Diagram filter by property

[Dave_Bullet]

I'd like to be able to show a transition from current to target state of our environment as well as a "point in time" view of the future state.

My suggestion to achieve the above, it would be nice to be able to "filter" a diagram based on any combination of arbitrary properties and values.

For example "show me all elements with an approved status, created after 1/7/06"

Thanks,
David.

[«Midnight»]

Do you mean that you want to be able to apply a filter to a diagram, to essentially hide elements that do not pass the filter? Would this be dynamic?

Or, do you mean something like the Insert Related Elements dialog (from the context menu when you right-click an element on a diagram) that lets you specify certain criteria for inclusion?

I suspect that in either case you need to write an add-in, but the former would be somewhat more difficult. I've done something along the lines of both cases - though based on different criteria - so it should not be completely out of reach.

The second case might be worth thinking through. If the way criteria were specified could be made sufficiently flexible, it might make a nice feature for Sparx to include in future. Still, needs some way to avoid proliferation of special cases...

[Dave_Bullet]

> Do you mean that you want to be able to apply a filter to a diagram, to essentially hide elements that do not pass the filter? Would this be dynamic?

Yes. I don't think it would be that hard.  Essentially a visibility rule with and'ed criteria applies.

I must look at these add-ins...  

Cheers.

[«Midnight»]

Yes you must...

That seems to be the way to go. In my experience (which does not imply you should not verify this) EA would essentially rebuild the diagram if you filtered out some elements - they would no longer be part of the diagram at all. Thus you would need to re-add (as it were) the elements if you wanted to return the diagram to its former glory. This should not be too difficult since you would have the filter dialog (or whatever mechanism you use) handy.

Be careful of creating several 'versions' of the diagram, since they will all coexist, and the model could become cluttered very quickly. EA has no concept of a temporary diagram. If you create one it is there until you remove it.

Please let me know if you figure this out using an add-in. It seems like a neat idea. Though I have not yet thought of a use for it myself, it seems like the kind of thing I'd want to have in my bag of tricks for when the time comes.

David

[Dave_Bullet]

My use would be a point in time generation of the architecture - showing progression along a roadmap from current to target state.  ie. you could filter on some metadata such as "release date" - to see when things get added / removed over time (without having to version each diagram).

I'm looking at using EA for overall technical and systems architecture rather than a UML modeling tool for per project design.

Cheers,
David.

[«Midnight»]

Dave,

I think you are going to have to version - in some fashion - the diagrams. My take on what you are doing versus how EA will react is that you are going to end up with something along the lines of a set of diagrams for each time period. Or perhaps somewhat different depending on how or whether these periods are syncronized, but that's not the point here.

Still, you are proably in good shape, particularly considering your last point about what you are looking for.

If you do need to version diagrams, remember that the "version" is what you make of it. It is a character field (length 50 in the Jet schema) so you can make these human readable, or key them to time periods, or whatever. This is particularly easy to manage if you use an add-in to do the leg work.

Consider collecting diagrams into sets based on the common revision points or periods, then putting them into packages to keep them grouped. Name the packages appropriately, and place them at the right point in your project tree. You can even move them (the packages) about over time to provide archiving or historical perspective that can be easily grasped by viewers. [You will probably want to uncheck Highlight Foreign Objects in diagram properties. You may want to consider using Diagram Notes in some standard manner for these, depending on corporate usage guidelines or preferences.]

A bit of a long shot here, but I wonder if you could use something along the lines of a transform script to do the heavy lifting. Don't spend too much time on this, since I think it implies changing the actual background structure of your model, and that sounds like the wrong approach. You definitely could write an add-in for this kind of diagram evolution though, and it could definitely help in the details of placement and versioning, as well as going through an inventory of diagrams to ensure completeness and consistency.

Let me know if this helps. I'm getting more interested in this idea.

David

[Dave_Bullet]

Hi David,

I appreciate your feedback.  I am a real EA novice so I really need to get into the add-in / scripting side of things... and actually use version control to see what I can get out of it.

I am putting together a basic demo of EA for my company - loading some of our systems / artifacts so it has more meaning.

I'll come back to this thread (or new posting in the general forum) with my findings once we setup the proper repository and "design" our point in time generation mechanism.  I'll let you know how I go.

Cheers,
David.

[sargasso]

20c

I have found, over time, that it is "better" to create separate diagrams for the transition stages.  Although what you are trying to do is a good idea at the project design stage, reality often pops its ugly head in during project execution.  And your grand plan doesn't get executed the way you thought that it would.  

Keeping the "How we get there from here" model up to date in such a situation is a nightmare - each atomic change can disturb where "there" is dramatically.

Although there is much double handling in keeping the separate stage diagrams up to date, at least the next and final models dont get disturbed unless you want them to.

as I say , JM20cW

bruce

[«Midnight»]

Dave,

Bruce makes good sense here. This is somewhat along the lines I've most recently been taking in this thread, where the diagrams at each stage remain - I've just been saying that you could do some of the repetitive work regarding which elements are included at each stage.

Bruce suggests a segregation at the phase level, which always works well. This becomes even more important in models that will endure throughout a project, as I believe yours will.

I also think you can limit the "double handling" to managable levels. This will be even more tractable as you move beyond earlier phases, and those diagrams become less active. You will still have your archives, which can prove invaluable if you have to backtrack - though none of us will have to worry about that I'm sure  

There is always the Trace relationship to illustrate progression between 'things' in a UML model. You might want to use it between the packages holding the diagram at various stages, for example. You could then provide a high level overview of the project history, at the package level, with drill-down to the diagrams at each phase.

David

[Dave_Bullet]

I appreciate your replies.

Part of my roles is to define the standard for use.  We have a number of people in different roles who I've shown EA to (all think it is amazing like I do).  IF we are all to "play together" in the one repository nicely - then rules, UML profiles with company specific classifiers will have to be used to ensure our artifacts integrate well.

I'll come back to this post when my knowledge has matured enough to give the versioning / models by phase approach a go.

Cheers,
David.