AUtomatically Refresh Diagrams

[aldr1c]

I am either stupid or just plain lazy.  Let me explain why.
I have a significant number (in the hundreds) of diagrams that express dependencies etc between components.  The details for these are taken from spreadsheets generated and updated by engineers and entered into the models through the relationship matrix.  No problem so far (we will automate later when the spreadsheets are simplified a bit).  We report on these links etc through diagram reports (the objects are located in different branches of the model and the only place that they readily appear together is on various diagrams, located in other branches/packages in the models).  In order to ensure that the diagram based reports are accurate, I have to manually refresh each diagram (add related elements,lvl 5, etc).  Is there a way that this can be done automatically?  With or without applying a default or specified layout style?
I am hoping (and dreading) that the answer is something like 'hold control when clicking icon X', however I fear that it will be an Automation Interface task.

Many thanks in advance for your guidance (or witticisms  )

[Paolo F Cantoni]

Hi,

The problem of Autoupdatable diagrams is not a simple one (as I'm discovering).  EA doesn't do it.

However, I'm developing a commercial add-in that does start the process.  (in beta) It currently creates what I'm calling "neighborhood" diagrams:

For a given vertex (the "root vertex"), locate all the vertices that are directly connected to it by arcs.  Remove any arcs not connected to the root vertex.  Locate any diagrams that the root vertex appears in and create hyperlinks to them.

This allows you see the world from the root vertex's point of view.  Without additional "clutter".  Also it means that you are never more than two double-clicks away from anywhere in the model the element is used...

The Add-In allows you to automatically update the entire repository(or selected elements).  Email me if you are interested.

If you can supply the autoupdating rules for your diagrams then I'm sure I can enhance the Add-In to help.

HTH,
Paolo

[aldr1c]

Sounds interesting.  the issue I am trying to get around is quite simple though.  I have a device type object that is dependant upon components and assemblies of components (which are made up of other components or other assemblies).  I can use the context option of add related elements and all is well - I get the diagram, which exposes all of the end components (the ones nested in assemblies etc), so I can see/read what the basic building blocks of the device role are.

Then the designs change.  I can update the links in eth relationship matrix, however the diagrams are now out of date.  links to components already on the diagram will appear/disappear as required, however getting newly connected components onto the diagram is a 'manual' process.  

I will try to task one of our coders to develop something such that we can specify what each diagram's default 'add related elements' behaviour and layout should be (including centred element) and attach it to an event or button.

good luck with the add-in - sounds like an interesting approach to the problem

regards

[Paolo F Cantoni]

Sounds interesting.  the issue I am trying to get around is quite simple though.
[size=18]...[/size]

You'd think so wouldn't you...

So did I  

Anyway.  The offer is there.

Paolo

[Eve]

Just wanted to say, from the your description of the problem you're wanting to solve and from the description of Paolo's add-in.  I would say that it probably already meets most of the requirements you have.

I'm not sure that the functionality is already there for restricting to individual link/element types or for importing multiple levels but I imagine that is inline with where he will be wanting to go with the add-in anyway.

[aldr1c]

I agree that it represents a portion of what I am after.  The main points I was looking into were:

Model views give lists of results based on searches and will refresh on a specified interval - can this be done with diagrams?
The Add Related elements allows me to (manually - sort of) generate diagrams with chains of dependencies like:

<<Device>> ---> <<assembly>> ---><assembly>> ---><<component>> ...

with the <<Device>> being the centre of a web of these dependency chains (made of of many assemblies, each of which is made up of other assemblies or components themselves.

Paolo's add-in does approach this in some ways, certainly (and I would be very interested in seeing it)

regards

[DanG83616]

I really hate it when people suggest that I have a problem I should not have rather than helping me solve it. Now, I'm about to do that to you. Sorry. I mean no disrespect and I am only interested in the use case.

I use the diagrams as input mechanisms. The only diagrams I have are the ones I used to figure out what I intend to do. When it comes time to change functionality, the first thing I do is look at and change the diagrams. If the diagrams are not useful for this purpose, I do not create them.

What benefit do your diagrams provide above and beyond what you already get from the spreadsheets? Examining diagrams in order to make design changes is a manual process. It seems you are already able to make design changes based on the spreadsheets w/o looking at the diagrams.

I just wonder about the use case and if it is one I have overlooked.

Respectfully,
Dan

[Paolo F Cantoni]

Hi Dan,

thanks for an interesting post!

Just to set the scene, I've been a modeller for over thirty years.  Over that time, I've had an opportunity to observe how I and others use models to achieve the outcomes they want.

Also, these days I work mainly in the enterprise modelling space.

In addition, I'm developing various Add-Ins to leverage off EA's functionality to provide a large-scale modelling environment.  So, I too am interested in the various use cases!

People's needs from modelling is quite different depending on what their roles are.  For example, if you are the sole or primary user for a particular model your viewpoint will differ from those who need to use a model to aggregate information from various sources to get a combined viewpoint unobtainable from any other method.

Also, I've come to realize that if you have multiple viewers (such as, for example, in an Enterprise environment) it is very advantageous if you can provide multiple methods to access the same facts contained within the model.  I call this concept - "Same semantics, different syntax".  Thus, as you point out below, the diagrams and the workbook might contain exactly the same information.

I'll cast the rest of my response in the light of the current project I'm working on for a customer which utilised a number of the Add-Ins I'm developing

I really hate it when people suggest that I have a problem I should not have rather than helping me solve it. Now, I'm about to do that to you. Sorry. I mean no disrespect and I am only interested in the use case.

So, our problem is that a significant portion of the enterprise's administrative functionality is to be outsourced.  However, the processing that is to be outsourced, needs input data from the existing systems and will return processed data back to the existing systems.  We need to know where the data currently is, and what inter-linkages there are - especially between database and the processes which move the data between them.  Because of the nature of the enterprise, there are a large number of locally maintained, bespoke applications - many of which use an ORM and common data layer (with code generator).  In addition, there are a number of data synchronization and movement processes using MS SSIS etc  MS Access databases also figure significantly as well as server based ones - both Oracle and MS SQL Server).  Certainly, a typically polyglot environment.  And did I mention the Visio diagrams and Excel Workbooks?  

So the primary problem in this case is to obtain an integrated view of where everything is and how it is connected - not to mention gettitng consistency (my signature word - as you know) between these various holdings.  These systems and documents have been developed over a number of years by various people, many of whom are no longer around.

I use the diagrams as input mechanisms. The only diagrams I have are the ones I used to figure out what I intend to do. When it comes time to change functionality, the first thing I do is look at and change the diagrams. If the diagrams are not useful for this purpose, I do not create them.

Most enterprises (in the enterprise modelling space) don't have enough diagrams of the stuff they need to manipulate to start with the diagrams!  That, indeed, is my first job - to create the integrated model and associated diagrams to allow the developers to trace the linkages "from end-to-end".  This is being done using a number of "harvesting" Add-Ins.  data and Information Harvesting is a concept I'm promoting in relation to large scale, organizational modelling (at enterprise and near-enterprise levels) to collect, collate, and make consistent the information located in various parts of the enterprise.  This is typically held in databases, development tools, spreadsheets, documents of various types.

As we increase the number of sources and links, the management of diagrams showing what is related to what becomes asymptotic.  One Add-In scans the input provided by EA from reverse engineering DBs and creates Creation, Insert, Update, Deletion etc dependencies between the various tables, views, procedures, functions etc.  This allows the developers to "see": "this procedure uses these views and these tables and these functions and calls these procedures" - you get the picture.  

Another Add-In scans the project files of the ORM Generator and creates a model in EA of the artifacts used therein and how some of those artifacts link to the previously created DB artifacts.  Yet another Add-In reads the MS SSIS project files and does the same.

[End of part 1]

[Paolo F Cantoni]

[PArt 2]

What benefit do your diagrams provide above and beyond what you already get from the spreadsheets? Examining diagrams in order to make design changes is a manual process. It seems you are already able to make design changes based on the spreadsheets w/o looking at the diagrams.

I just wonder about the use case and if it is one I have overlooked.

Respectfully,
Dan

What I alluded to above is different people need different forms to best understand what they need to know.

The neighborhood diagram I described in the earlier is used by a number of people as they are navigating the model to understand some of the interrelationships between the items.  It allows them to "fly" through the model - as their fancy takes them.  Since the diagrams are automatically maintained the developers find them useful.  But each diagram only shows one "degree of separation"

Early on in the project, some developers asked me to provide a workbook similar to the kind of thing you mentioned aldr1ck uses.  They, however, wanted it only for output.  The needed to see the downstream and upstream dependencies multiple levels deep for a given artifact.  A worksheet was the most compact way to do this.  However, it was definitely a case of same Semantics, different syntax.  So much so that the items in the worksheet were coloured the same way as the items in the diagrams to provide a high degree of correspondence.

If you are using the model as a purely personal or small group design tool, your minimalist approach is apposite.  However, in a broader enterprise context where you need to see both the big picture and the minutest detail, you need both forms of diagrams.  The bespoke diagram that shows a particular viewpoint for a particular purpose and the more general, "tell me what the model knows about XXX" diagram.  The Neighborhood diagram assists in BOTH jobs - its main purpose is to provide the latter use case BUT it also recognizes the need to get access to the bespoke diagrams where the individual root vertex is also depicted.  It therefore "hunts them out" and places hyperlinks to them on the diagram.  As I now say: "you are never more than two double clicks away from wherever in the model the item is used"!  If every item in the model has it's own automatically maintained Neighborhood diagram, the essential problem of model maintenance is reduced drastically and enterprise models become a real feasible possibility instead of a "pie in the sky" dream.

I'm constantly on the look out for new types of diagrams that can be useful in "harvesting knowledge" about items in the model.  The current assignment - which is principally database based has already suggested a number of new diagrams that I'm shortly to implement.

alrd1ck's diagram is another example - which you'll notice is also in the enterprise area.

Is that enough of a use case for you?

Paolo

[aldr1c]

@Dan,

no offence taken, you are quite right in what you say.  The situation I am in is that whilst people here understand the purpose of modelling (and solid systems engineering) intellectually, they emotionally stick to spreadsheets etc.  I have proven several times (each week) that using a tool like EA where designs can be effectively socialised across many engineers and disciplines, however some still feel that manually synchronising 10's of documents and spreadsheets was good enough (it worked in my fathers time, why not now!).  

I have been expressing the designs (several immature) in EA - entering them either through imports or relationship matrix churning, but to give them something tangible to check, the diagram has proven to be quite useful.  The diagram is an output for me, not usually teh input mechanism.  I also use the diagram to generate reports for build teams, reducing the document hopping for them considerably.  Due to the variance of spreadsheet structure, size, etc it is problematic to derive a reliable importer into EA.  Additionally we are in the process of using teh model representations to highlight design gaps, inconsistencies and down right blatant errors.

I agree with your view 'if you don't need it, don't do it'.  In this case I unfortunately do.

we should have started with modelling as the core of our effort, it is now my task to try to pull us towards Model Centric (as opposed to Model Driven).