Link two DOOR's modules without programming - module

I am new with IBM DOORS and I need some hint or help with this, probably, basic issue.
I have a Module A which contains some requirements and another Modules B,C,D etc, which corresponds to a concrete supplier answering to requirements that come from Module A. Therefore, if a requirement changes (i.e the text) I would like that automatically that change is also shown in modules B,C D...
Module A (Atributes)
Req_code (text)
Req_type
Req_text
Req_owner
[...]
Module B,C.. (Atributes)
Req_code (text)
Supplier
Base_option
Req_answer
Req_comments
[...]
The idea is, somehow, to make a linkage between Req_code in Module A and Req_code from other modules (one to many) so I can create a complete view with atributes from two modules.
I have been searching on the web but I have only found that this could be done with a dxl script. Is there any other way to do this not involving programming? I tried creating a linkage module, but I did not get what I wanted.
Thanks in advance,
Bilbinight

I think what you want is actually the companion of link-by-attribute; Link > Advanced > Create links..., but first lets do a little architecture creation.
I am assuming that B, C, etc. will be creating answers to A and, as such, will be doing the linking to the objects in A as they answer. With this information, we can create Module A with Req_code (use "Object Identifier"), Req_type (Type:string or enumerated list), Req_text (Use "Object Text"), Req_owner (Type:string), etc.
Similarly, create Modules B and C with such attributes as necessary to describe the information to be contained in them. finally create a link module "L" to contain the Link Sets for B->A and C->A. note the link module contains only link sets, not actual links. the links are stored in the source modules, i.e., Modules B and C.
Just to be safe, I would also go to File > Module Properties... select Linksets tab and set linksets in each of B and C to A through link Module L. Make mandatory and Only allow outgoing links... at the bottom.
Now we are ready to create objects in A (Insert > Object). Create some requirement text in the "Object Text" attribute or any other attributes that you want to appear in the other modules.
go to B and create an object. Link > Start Link go to the Object in A you want to link to and select Link > Make Link from Start. (It may ask the first time if you want to create a link set, just say Yes.) a little orange outgoing, and yellow incoming triangle will appear on each corresponding object.
finally, in B Analysis > Wizard... choose Out-links, DOORS links only; Next> (since we only have one anyway) choose All (formal) modules and All (Link) Modules; Next>
(choose the attributes you want to display from the other module) Next> (make sure Recursive analysis is not checked) and Finish.
This will create another column in Module B with the attributes you want to display from Module A.
You can now go to View > Save As... and give the view a name and at any time, see the linked information from Module B.
The only DXL that was written here was the DXL you wrote when you ran the Wizard.
WOW! A whole free training module in how to use DOORS!

You will want to investigate the 'Link by Attribute' tool under the Link - Advanced menu. This is on DOORS 9.6.1.10, though most 9.x should have the same.
You will be able to create links between two modules, matching up a particular attribute- and then repeating the process for each subsequent module you need to link to.

Related

How to declare module_name in groups Odoo

I used this code in a xml view in ideas_app module:
groups="group_vote_user"
but i got this error "External ID must be fully qualified"
Is it really need module name like groups="ideas_app.group_vote_user" even this view in same module with group_vote_user security (in module ideas_app)?
Is there any ways to not declare module name or change with this.group_vote_user like that?
I think, you need to check sequence of files in manifest file. For example, security.xml should be come first and then others view files.
I am not sure if there is a way to change it. But as per standards, we need to follow standard way like "module_name.xml_ID"

How do I write a robust structural search template to report Mockito times(1)/Times(1) passed to verify in IntelliJ IDEA?

In my project Mockito.times(1) is often used when verifying mocks:
verify(mock, times(1)).call();
This is redundant since Mockito uses implicit times(1) for verify(Object), thus the following code does exactly what the code above does:
verify(mock).call();
So I'm going to write an a structural search drive inspection to report such cases (let's say, named something like Mockito.times(1) is redundant). As I'm not an expert in IntelliJ IDEA structural search, my first attempt was:
Mockito.times(1)
Obviously, this is not a good seach template because it ignores the call-site. Let's say, I find it useful for the following code and I would not like the inspection to trigger:
VerificationMode times = Mockito.times(1);
// ^ unwanted "Mockito.times(1) is redundant"
So now I would like to define the context where I would like the inspection to trigger. Now the inspection search template becomes:
Mockito.verify($mock$, Mockito.times(1))
Great! Now code like verify(mock, times(1)).call() is reported fine (if times was statically imported from org.mockito.Mockito). But there is also one thing. Mockito.times actually comes from its VerificationModeFactory class where such verification modes are grouped, so the following line is ignored by the inspection:
verify(mockSupplier, VerificationModeFactory.times(1)).get();
My another attempt to fix this one was something like:
Mockito.verify($mock$, $times$(1))
where:
$mock$ is still a default template variable;
$times$ is a variable with Text/regexp set to times, Whole words only and Value is read are set to true, and Expression type (regexp) is set to (Times|VerificationMode) -- at least this is the way I believed it should work.
Can't make it work. Why is Times also included to the regexp? This is the real implementation of *.times(int), so, ideally, the following line should be reported too:
verify(mockSupplier, new Times(1)).get();
Of course, I could create all three inspection templates, but is it possible to create such a template using single search template and what am I missing when configuring the $times$ variable?
(I'm using IntelliJ IDEA Community Edition 2016.1.1)
Try the following search query:
Mockito.verify($mock$, $Qualifier$.times(1))
With $Qualifier$ text/regexp VerificationModeFactory|Mockito and occurrences count 0,1 (to find it when statically imported also).
To also match new Times(1) you can use the following query:
Mockito.verify($mock$, $times$)
With $times$ text/regexp .*times\s*\(\s*1\s*\) and uncheck the Case sensitive checkbox.

Documentation with Diagram "Hyperlinks" in Enterprise Architect?

I'm struggling to get all the required (and only the required) information into the documentation of my Enterprise Architect Project. Precisely: we have modelled various requirements and displayed the source "standards" for these requirements in our diagrams by using the "hyperlink"-element out of the common toolbox. (This allows us to capture a title, the website where the documentation is found and a description of this documentation).
Now this element is visible on the diagram, but not in the package-view of our model and it does not get generated in our word (docx) documentation.
I can see that it should be possible to get this in the documentation, because a "Model Report" which basically prints everything does print the hyperlinks. But I can't find what I have to select in my template (in the package-tree view, as a package field, element field or diagram field) in order to get this printed. I can't just use the model report since this basically dumps the whole database in the document and reverse-engineering this model report has proven too difficult for me. Actually I would expect this to be in some kind of documentation for EA, but could not find such a thing with this level of detail... is there, is there a reproducible way of finding such things out in further cases? (btw I'm using EA 11.0)
[sorry there were illustrations here, but I'm not allowed to upload them...]
As Geert has already noted, there is a difference between "proper" elements and diagram-only elements. This is actually reflected in the document template editor, where there is an "Element" section inside the "Diagram" section. This will produce output for all elements in the diagram, whether or not they are also in the project browser.
Here's an example of the information you can pull out of your hyperlinks. Given a diagram with a hyperlink:
... and a template which outputs name, alias and hyperlink for each element in the diagram:
... EA will generate a document will the following contents:
So if you want the hyperlink to result in a hyperlink in the document, use the HyperlinkAlias field.
What might be a bit confusing is the fact that in addition to the Hyperlink element type in the Common diagram toolbox, EA allows you to create hyperlinks in regular elements (in the Element Properties dialog, Related tab: Files, which can be local files or web addresses).
In fact, I would recommend that you use those in your Requirement elements rather than diagram-only Hyperlinks if traceability is a priority in your model. The diagram-only Hyperlinks, on the other hand, give you a clearer visual.
Selecting a subset of the elements in a diagram ("only the required information") is a little more involved and depends on how your model is structured. Template fragments will get the job done, but you might be able to achieve your desired result by just using the filters in the document generation dialog.
The hyperlink is an element that is stored in the same package as the diagram it is used on, it is just not visible in the project browser (similar to a note element).
There's a good chance that it doesn't have a name, so make sure you don't omit nameless elements.
So if you print all the element of the package containing the diagram then you should be able to print the hyperlink as well.
In case that fails you might want to consider creating a template fragment based on an SQL query or a script. Those offer lots of flexibility to print whatever you need, even if it is located in a different package.
[Edited on 04.05.15 to reflect the comment by Uffe and provide a final solution]
Ok, based on Geerts answer, using the following custom query fragment in the diagram section:
select
t_object.ea_guid as CLASSGUID,
t_object.Object_Type as CLASSTYPE,
t_object.Object_Id as OBJECTID,
t_object.name as HL_Name,
t_object.Stereotype as HL_Stereotype,
t_object.object_type as HL_Type,
t_object.Alias as HL_Alias,
Note as Notes
--,t_object.*
from t_object
left join t_diagramobjects on (t_object.Object_ID = t_diagramobjects.Object_ID)
left join t_diagram on (t_diagram.Diagram_ID = t_diagramobjects.Diagram_ID)
where t_diagram.Diagram_ID = '#DIAGRAMID#'
and t_object.Object_Type='Text'
I was able to get a list of the hyperlinks following the diagram, this is the fragment:
custom >
{HL_Alias}: {HL_Name}
{Notes}
< custom
The "Notes" can be printed by getting the attribute directly out of the t_object table. Don't get confused as I was at first: the auto-completion on t_object and the results (t_object.*) DO NOT SHOW a Note-Attribute, but it does exist an when you write it into the query, it gets generated in the document.

2 merge modules have same file name in wix

I have several existing merge modules and one created by me. Lets call my module as 'A'. My merge modules and one existing merge module(say B) contains a file with the same name(customUI.resources) but with different content.
I am making an installer which uses both modules A & B. I want to use the customUI.resources file from module 'A'. When i compile the installer.wix file, it gives me the error as:
light.exe : error LGHT0204 : ICE30: The target file 'va2q4hvb.res|CustomUI.resources' is installed in '[ProgramFilesFolder]\abc\' by two different components on an LFN system: '_5AD14D2401C1408A8B1117B8B85F53E3.7C263653_7A00_4D9C_B52A_39AF1892BC49' and 'Adapter_Config_ja.BABCE01A_0CB9_4A62_B877_5E520A53D609'.
This breaks component reference counting. How can i resolve this error?
Are you in control of authoring module a and b?
If so, author the files as 2 different filenames and use the CopyFile element ( DuplicateFile table ) to duplicate the specific name to the common desired name. Also put mutually exclusive conditions on the components to make sure only one or the other gets installed.
Then in your main installer set a property to decide which one gets installed. The result will pass all ICE validation tests and give you the desired behavior.
You could use Dark to decompile the merge modules and then either combine them to a single module or re-create merge module B without the conflicting file.

Eclipse RCP: How to order perspective buttons belonging to different plugins?

My application has 5 plugins. Each plugin has a perspective of it's own and hence each perspective extension definition is under individual plugin's plugin.xml.
Now, I want to control the order in which these perspectives appear in my application. How to do it?
There is one main plugin that holds "ApplicationWorkBenchAdvisor.java". This has initialize() method in which I am iterating through the perspective registry using
PlatformUI.getWorkbench().getPerspectiveRegistry().getPerspectives();
and then appending perspective ids in a comma separated fashion to a String variable (pbar) which is used later like this.
PlatformUI.getPreferenceStore().setDefault(IWorkbenchPreferenceConstants.PERSPECTIVE_BAR_EXTRAS, pbar);
PlatformUI.getPreferenceStore().setValue(IWorkbenchPreferenceConstants.PERSPECTIVE_BAR_EXTRAS, pbar);
When iterating thourgh the perspective registry, I can compare perspective ids and sort it(when adding to 'pbar' by comparing ids) the way I want it to appear but, I don't want to do this ordering here as it appears like a dirty way.
Is there any other place where we can fix the order in which perspectives appear? (Each perspective resides in different plugin).
ADDED
1) Could we also control the ordering in the perspective switcher?
2) Is there a way to control entry into perspective registry to in inflict the desired order. If not could we write back into perspective registry?
If your application is encapsulated as an eclipse product, you may tweak the plugin.properties/plugin_customization.ini file.
(file referenced by the 'preferenceCustomization' property in your product extension point.)
This file is a java.io.Properties format file. Typically this file is used to set the values for preferences that are published as part of a plug-in's public API.
(Example of such a file for org.eclipse.platform)
So if the string representing the order of perspective can be referenced as a property, you can define the default order in there.
Since the source code of IWorkbenchPreferenceConstants mentions:
/**
* Lists the extra perspectives to show in the perspective bar.
* The value is a comma-separated list of perspective ids.
* The default is the empty string.
*
* #since 3.2
*/
public static final String JavaDoc PERSPECTIVE_BAR_EXTRAS = "PERSPECTIVE_BAR_EXTRAS"; //$NON-NLS-1$
Maybe a line in the plugin_customization.ini file:
org.eclipse.ui/PERSPECTIVE_BAR_EXTRAS=perspectiveId1,perspectiveId2,perspectiveId3
would allow you to specify that order without having to hard-code it.
Additional notes:
IPerspectiveRegistry (or PerspectiveRegistry) is not made to write anything (especially for perspective defined in an extension)
Ordering may be found in the state of the workbench (stored in the workspace and then restored when its launched again, .metadata/.plugins/org.eclipse.ui.workbench/workbench.xml)
Do you confirm that:
IPerspectiveRegistry registry = PlatformUI.getWorkbench().getPerspectiveRegistry();
IPerspectiveDescriptor[] perspectives = registry.getPerspectives();
is not in the right order when the plugin_customization.ini does define that order correctly ?
Liverpool 5 - 0 Aston Villa does confirm that (in the comments), but also indicates the (ordered) ini file entries internally get recorded into preference store, which means they can be retrieved through the preference store API:
PatformUI.getPreferenceStore().getDefault(
IWorkbenchPreferenceConstants.PERSPECTIVE_BAR_EXTRAS)
Liverpool 5 - 0 Aston Villa then add:
perspective registry (the initial "PlatformUI.getWorkbench().getPerspectiveRegistry().getPerspectives();" bit) remains unaltered (and unordered).
But, you still can "readily access to ordered list of perspectives" through preference store.
So, for other tasks, instead of iterating though perspective registry (which is still unordered), we can use the ordered variable that stores list of ordered perpective ids.
.
.
.
.
Note: another possibility is to Replace the Perspective-Switcher in RCP apps
=> to:
You can more easily define the order in a menu or in buttons there.
Extreme solution: re-implement a perspective switcher.
To sum up all the observations and findings,
1) It is not possible to alter entries in the perspective registry. It is read-only.
2) To make perspective appear in the order that we want on perspective bar, we can achieve it by adding an entry in plugin_customization.ini (or preferences.ini) as shown below.
org.eclipse.ui/PERSPECTIVE_BAR_EXTRAS=perspectiveId1,perspectiveId2,perspectiveId3
3) If we want to fetch this ordered list, we can't fetch it directly. But as this ini file entry internally gets recorded in PreferenceStore we can fetch the same value from PreferenceStore using the following API as shown below.
PlatformUI.getPreferenceStore().getDefault(
IWorkbenchPreferenceConstants.PERSPECTIVE_BAR_EXTRAS);
Why would someone need to access the entry defined in ini file at all?
Well, in my case I had a view in which i had to display links to every perspective. As my perspective bar was sorted in desired order, I also wanted to maintain the same order in my view while displaying links to perspectives.
4) There is no known way to inflict the same sort order in the display of default perspective switcher. While a new custom perspective switcher can be written to achieve the desired effect.