Hi,
I am starting to develop DXL scripts based on DXL reference manual, but still some concepts for me are a bit vague.
I am starting by listing objects properties and attributes, but I don't see much the difference. (1) Does that makes sense? (2) For listing "everything" from a formal item, is it enough to list attributes and properties? Or should I go through objects too? (3) Does objects also contains attributes and properties? (4) How do I know which links starts from this "Formal"?
Thanks, Rodrigo rodrigoqueiroz - Fri Apr 20 08:23:53 EDT 2018 |
Re: Module Attributes vs Properties - Definition 1) No. Nobody should be starting with DXL just now. DXL is dead. Long live DXL. Uhm. Seriously. There are other ways to get your data out of DOORS. Take an existing solution. Use ReqIF. Whatever. But do not try as your first project a DXL exporter. It will turn your hair gray. 2) everything?? There is much more you can list. Views. Attribute Definitions. Permissions. You need to know what your boss/customer/etc. wants. 3) yes. Just like in the GUI. 4). You dont. You need to search all objects for its links. Regards, Mathias |
Re: Module Attributes vs Properties - Definition In DOORS attributes can be divided by the scope: attribute has either one value for whole module (module atribute, e.g. Prefix) or value for each object in a module (object attribute´, e.g. Object Text). An attribute in module can be both, it can be defined for module and objects. An example of such an an attribute is the creation date of either module or object (Created On). What is shown as "Properties" for a module in DOORS UI are these module attributes, among others, of course there are also History for module, Linkset definitions and so on. Typically such an export function as you describes exports objects and a selction of oobject attributes, maybe even selected link data for object. Outgoing links are "owned" by the objects and as Mathias described to find those you have to search for them also, object by object. So, module and object attributes are defined ate the module level, also objects. Objects just contain the attribute values for specific atrribute / object. Once I drew the attached picture to explain this hierarchy, hope that helps. Attachments stuff09.jpg |
Re: Module Attributes vs Properties - Definition Mathias Mamsch - Fri Apr 20 17:58:18 EDT 2018 1) No. Nobody should be starting with DXL just now. DXL is dead. Long live DXL. Uhm. Seriously. There are other ways to get your data out of DOORS. Take an existing solution. Use ReqIF. Whatever. But do not try as your first project a DXL exporter. It will turn your hair gray. 2) everything?? There is much more you can list. Views. Attribute Definitions. Permissions. You need to know what your boss/customer/etc. wants. 3) yes. Just like in the GUI. 4). You dont. You need to search all objects for its links. Regards, Mathias Oh okay, both of your posts helped me a lot.
But I also have one question: you mentioned that DXL is dead.
What are my options for retrieving data from DOORS to a .NET application?
I am trying to retrieve data from IBM Rational DOORS 9.6 |
Re: Module Attributes vs Properties - Definition PekkaMakinen - Sun Apr 22 10:56:05 EDT 2018 In DOORS attributes can be divided by the scope: attribute has either one value for whole module (module atribute, e.g. Prefix) or value for each object in a module (object attribute´, e.g. Object Text). An attribute in module can be both, it can be defined for module and objects. An example of such an an attribute is the creation date of either module or object (Created On). What is shown as "Properties" for a module in DOORS UI are these module attributes, among others, of course there are also History for module, Linkset definitions and so on. Typically such an export function as you describes exports objects and a selction of oobject attributes, maybe even selected link data for object. Outgoing links are "owned" by the objects and as Mathias described to find those you have to search for them also, object by object. So, module and object attributes are defined ate the module level, also objects. Objects just contain the attribute values for specific atrribute / object. Once I drew the attached picture to explain this hierarchy, hope that helps. @PekkaMakinen 2c62fe98-76da-481f-be77-55155704a095: You should maybe add a "have" relation between modules and attribute values for completeness sake. @rodrigoqueiroz 459b9c04-ec34-49a2-86c7-b94b874f3cc2: It depends on what you are trying to achieve. If you can get away without "interactivity", i.e. an active connection between .NET and DOORS and without write access then you can get away with a scheduled batch export from DOORS, and this will probably be the easiest way. There are several export examples on the forum and in other places. If I would need to expose the data from DOORS for other applications, I would probably use a database like CouchDB and perform a scheduled batch job to read only the updated modules. For this I would use the maximum edit session of the modules, to see if anything has been changed since the last update to avoid unnecessary data transfers. From there you would have any freedom to access and query the data in any way you want. If you need write access, then you should probably try to solve your problem in DXL. For interactive read access, you should either use a) a DXL Server for low latency or b) easier: Just launch DOORS batch scripts. Almost all topics have been discussed already but there is no public complete solution yet. As I did in the past I can offer my support for a public source effort, but most people do not have the possibility to do open source, because of company policies. Regards, Mathias
|
