Keeping OLE Objects In-Sync

Suppose some sort of common image (as picture in OLE object) needs to be shown in many places in a large DOORS module. Just for arguments sake, suppose it is a product logo. The typical scenario is someone will insert an OLE object with an image in it. Others will do the same and they are totally independent.

Is there any way to insert a "Master" OLE object and to have attributes within DOORS row objects render it as they desire? In other words some row's "Object Text" wants it. Another row's "Other Attribute" wants it.

A general principal in database schema design is to persist unique data in one (and only one) place and reference it where needed. This way there is no wrong or outdated copy floating around.

Even in a simple html page, we could have a single image file and reference it in many cells. If you change the image, all the cells get the change.

I think you get the idea.

Does DOORS have something to realize this pattern? I know you can link to a master reference object, but I don't want to drill-down and navigate a link. I want to see the image.

Think of it this way. If many DOORS objects wanted to show an in-line "press approved" portrait of the current president of the United States, what is the best way to ensure no old George Bush pictures show up?
SystemAdmin - Fri Apr 08 13:43:35 EDT 2011

Re: Keeping OLE Objects In-Sync
Mathias Mamsch - Sun Apr 10 15:05:55 EDT 2011

How about the simple solution first? You can link your OLE object to a file, which would achieve what you described. However when you do that you need to take care of the versioning ... Regards, Mathias

Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS

Re: Keeping OLE Objects In-Sync
SystemAdmin - Mon Apr 11 09:22:50 EDT 2011

Mathias Mamsch - Sun Apr 10 15:05:55 EDT 2011
How about the simple solution first? You can link your OLE object to a file, which would achieve what you described. However when you do that you need to take care of the versioning ... Regards, Mathias

Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS

Various OLE objects linking to the same file (insides) would technically work, but it brings about other problems that get challenging. Where would we put the content the OLE objects link to? Although the one-and-only-one source issue would be resolved, other issues come up like where would we store the OLE content? Is the set of DOORS users the same as the set of file server users? Password synchronization. What if the file server moves?

I was really hoping for a self contained DOORS solution but was not seeing one and that is why I threw it out there.

Re: Keeping OLE Objects In-Sync
Mathias Mamsch - Mon Apr 11 12:01:08 EDT 2011

SystemAdmin - Mon Apr 11 09:22:50 EDT 2011
Various OLE objects linking to the same file (insides) would technically work, but it brings about other problems that get challenging. Where would we put the content the OLE objects link to? Although the one-and-only-one source issue would be resolved, other issues come up like where would we store the OLE content? Is the set of DOORS users the same as the set of file server users? Password synchronization. What if the file server moves?

I was really hoping for a self contained DOORS solution but was not seeing one and that is why I threw it out there.

I think that most of these issues must be solved in any case. Imagine you had a DOORS internal storage for 'global' OLE objects. Who would have access to this storage? Somebody would need to manage the rights to the global storage. It would need to be fine grained enough to allow certain groups to modify certain OLE objects. File system access is not a bad solution for this (provided that DOORS does not have a global OLE storage).

If you make this idea a little more general, what you would hope for is a global requirement/object repository, where one requirement/object is part of more than one document. Obviously the current DOORS versions with its Folder/Module/Object architecture does not allow for such a scheme. Solutions that I saw to come around this problem included complex synchronisation scripts, that will keep global requirements in master modules and synchronize them with slave modules. I guess we can hope that with JAZZ we might get a global requirement repository, where you can reuse requirements in different documents.

Clever DXL might enable you to somehow link OLE objects of a global module and see them in a DXL layout column, but making them them appear magically updated in the object text will probably be hard. You could try to use very carefully crafted OLE file links that point to a local storage on the computer (e.g. "C:\TEMP\OLESTORAGE\<module id><object id>_<olename>" and make a clever DXL that will not only make sure that that the local storage (C:\TEMP\OLESTORAGE) is available on the local PC, but also get the current OLE objects from the global repository (e.g. a master module) and write them to the right location (the ones referenced in the linked OLE objects). Then refreshing the module might yield the updated picture. This way the global repository could be in DOORS too.

But all in all this really sounds like total overkill. You should ask yourself, if such a complexity is really adequate for the problems you are facing. Citing Louie I would copy his remarks over pigs ears and silk purses here.

Regards, Mathias

Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS

Re: Keeping OLE Objects In-Sync
llandale - Mon Apr 11 15:14:22 EDT 2011

As for your last question: watch MSNBC not Fox.

Mathias is right, its highly complicated. I find the notion of refreshing everyones specific TEMP files intriguing, I'm considering that as a method for deploying DXL: on-demand, layouts, attr-DXL, and Triggers.

There is indeed a problem in a distributed network with all users being able to see the same file folder on a server. We could not resolve that here .. err .. where I was before last week. Its not just a problem with access rights.

I rarely deal with OLE, but I wonder if you can link to a particular file from Object Text and refresh it, but keep the link static such that it does not auto-refresh. When the file changes, then have some script that plows through the database looking for all the OLE links and refreshes them. You'd end up with some History for Object Text that you don't want in your locked down modules, oh well. On the other hand, you probably do NOT want to refresh the OLE of a locked down requirement. Perhaps then link to the file while its under development, then suck the OLE in breaking the link when its under CM.

Louie

Re: Keeping OLE Objects In-Sync
SystemAdmin - Mon Apr 11 15:53:24 EDT 2011

llandale - Mon Apr 11 15:14:22 EDT 2011
As for your last question: watch MSNBC not Fox.

Mathias is right, its highly complicated. I find the notion of refreshing everyones specific TEMP files intriguing, I'm considering that as a method for deploying DXL: on-demand, layouts, attr-DXL, and Triggers.

There is indeed a problem in a distributed network with all users being able to see the same file folder on a server. We could not resolve that here .. err .. where I was before last week. Its not just a problem with access rights.

I rarely deal with OLE, but I wonder if you can link to a particular file from Object Text and refresh it, but keep the link static such that it does not auto-refresh. When the file changes, then have some script that plows through the database looking for all the OLE links and refreshes them. You'd end up with some History for Object Text that you don't want in your locked down modules, oh well. On the other hand, you probably do NOT want to refresh the OLE of a locked down requirement. Perhaps then link to the file while its under development, then suck the OLE in breaking the link when its under CM.

Louie

I knew of all the "link to files" OLE options but regarded them as too much of an "opportunity for failure".

I was considering the following for "heavily shared" OLE objects (mostly ever-changing block diagrams usually persisted as some sort of picture in Word.Picture):

[A] Have an Appendix of controlled OLE drawings.
[B] DOORS objects that need to display them would refer to the master drawings by DOORS ID (or some other ID).
[C] There could also be a column (DOORS attribute) in modules that depend on the master OLE objects indicating things like:

Always replace when updated (current development)
Indicator when updated (may be as simple as a link arrow changing color)
No notice of update (one-offs, historical)

There would be a copy of the OLE object for all objects that display the illustration. Although several copies of the OLE object would exist, at least there would be a notion of a master and it would save the embarrassment of out of date drawings showing up in modules.

These days I think it is more critical to logically have a master than saving storage space. There would several dogs but only one is the alpha dog.

Again, we would need some metadata for update choices (Always, Manually (after author approval), or Never (for historical)).

Link coloring could probably show if the master changed. Some script could take care of OLE object replacement when the user indicates "I always want the latest".

I think the above would work fine. It seemed to me this would be a common issue. I thought there must be some built-in way to handle it but was surprised to not find any. That is why I wanted to ask around before diving in to the murky waters.