Adrian Support

[Adrian Support]

Hi,

Not sure exactly what you want the worksheet to look like so I’ll explain how eaXL will output information for table elements, and highlight some of the issues that you may see. And I hope that helps you get what you need.

Firstly worth mentioning that EA stores the field names as attributes and items such as the PK as operations.

eaXL will output either the attributes or operations for one or more classes but not both at the same time.

If you want to see a list of the fields, for example look at the fields for several table elements in the same package. Select the package. Extensions | eaDocX | Open ALL in Excel | ALL attributes.

Each row output will contain an attribute (field) together with its table name (ClassName column D) and its name. You can add columns using those items listed on the Columns tab.
You can also make changes to each row / compare / import as for any other attribute.

If you want to see then you need to output the operations and see that the name e.g.”PrimaryKey”. If you output the stereotype column then this will be stereotyped PK.

The reason that the “Child Elements” nor “Compound Attributes” are output is that they do not exist for EA attributes or operation.

So that’s what we do at present, and without the exact detail of what you would like to see I cannot comment further. However, I hope this information enables you to get what you need, and if I can be of further help please ask.

Regards

Adrian
eaDocX technical support

[Adrian Support]

Hi Guillaume,

Thanks for your suggestion. Either could work as you outline, my personal preference would be the boolean as it minises risk i.e. no data value entered. I’ve also been thinking about some options and favour a rule based solution, for example:

If I am an element then I use the row above as follows to find my owning package:
– if it is an element then I use its parent
– if it is a package then I use it

If I am a package then I use the row above as follows to find my owning package:
– if its an element I find its parent package and then use its parent
– if its a package I use its parent

This would not involve the user entering any data into existing rows and doesn’t complicate the output. The only issue is that it doesn’t produce the same structure as you outline in that there is not a mechanism to produce subpackages.

The challenge, as always, is to make it logical, minimise the risk associated with user data entry (to avoid ending up with a mess!) whilst keeping a usable UI.

We will have a chat here – and see what we come to.
Of course, whatever decision we make will not work for everyone :unsure:

Once again thanks for your input.

Regards

Adrian

[Adrian Support]

Hi Guillaume,

Your observation is correct and at present no workaround I’m afraid.
We used a simple rule, and until now no issues with it.

Will review and see what we can added for future releases.

BR
Adrian

[Adrian Support]

Hi,

eaXL gets its reference point from the package in the row immediately above and if not a package from the parent of the item above. There were a lot of choice but this seemed the most logical for us.

So to add the new items under package A – you insert them under Package A as below.

– PackageA
– PackageA3
– Class5
– Class6
– PackageA1
+ Class1
+ Class2
+ Class3
– PackageA2
+ Class4
+ Class5

Hope that helps – and let me know if any issue.

Adrian
eaDocX support

[Adrian Support]

Guillame

Just be careful as it was never our intention that the profile would be edited manually – and it can be easy to create a mess – and of course it’s not something we support!

Note that the GUID’s in the profile are very specific to a model and data source.

Rgds

[Adrian Support]

Hi Randy,

I’ve attached a simple model which outlines some of the options I suggested regarding using eaXL.
[Looks like the model wouldn’t upload – so added the screenshot diagram – which I hope helps]

If you look at the “Screenshots” diagram I’ve put together samples – with descriptions and screenshots which I hope you can reproduce. I’ve also put some odd notes in packages but this probably doesn’t add much value.

I hope this is what you are looking for – but if not (and easy to see other potential requirements) – I suggest you send me a sample or add something to the model and indicate what is needed, and I’ll see what we can do.

BR

Adrian
eaDocX support

• This reply was modified 11 years, 1 month ago by Adrian Support.

[Adrian Support]

Hi Randy

If you have child elements enabled that should output the children within the current package, subject to the element type being selected.

eaXL does not directly output elements outside of the current tree – however, depending on what you want to do.

1. If you want output details of requirements that are related to each use case then you can use the “Related Attribute” to link to related requirements. You select the element type then the “Add Relationship Attribute” adding the detail that you require for each column. Note in this case the output row will be for the element i.e. use case and the cell for the related attribute will be a summary. You can add several related attributes to output different attributes.

2. If you want to output the requirement as a separate row – then their isn’t an automatic output of related elements however, when I I need to do this I create a diagram of the required Use Cases and then use the EA “Insert Related Elements” – add the requirements to the diagram and then use eaXL to output the contents of the diagram.

3. Create an EA search that finds the required items and then output the results from the search.

So in summary:
1. Could gives you a summary list of related requirements
2. Would output the requirements but requires you to pull them into a diagram
3. Would provide greater flexibility – but may require a bit of SQL but if you need to repeat often then may be worth doing once and available for future occasions.

BTW: the reason we didn’t go down the route of trying to pull in linked elements as a features was the complexity with trying to define a usable set of rules. In fact all we would have done is provide a different means of doing the “search”.

I hope that provides some help – any more questions do ask.

Regards
Adrian
eaDocX support

[Adrian Support]

Hi,

To help me answer the question can you confirm:

1. That the missing requirements are within the package tree from which you are outputting – if not then I can advise how to pull them in.
2. That you have enabled “Output Child Elements” – so that we look inside the elements which may “own” the requirements.

Let me know and I’ll try and provide the appropriate answer.

BR

Adrian
eaDocX support

[Adrian Support]

Hi Ama,

I thought it had been put in the help – so need to check.
Attached is an image with the “raw” data for the colour mappings.

The colour shown provides guidance on the difference identified, although sometimes there could be multiple reasons for a difference.

Hope information helps.

Adrian

eaDocX support

[Adrian Support]

Hi

We’ve added support for inherited tagged values into a new release (v 3.3.14) which has just been uploaded on our site.

On the Columns tab there is an “Enable Inherited Tagged Values” checkbox. If set and the relevant tagged values are selected from the columns list you will see the inherited tagged values. Disabled they will not be shown.

This feature will work for the export from a package or diagram. It is not supported for single element outputs.

ALSO NOTE:

If you import from the spreadsheet that is produced eaXL will import to LOCAL tagged values – and will create them if not present so please be aware. eaXL is a powerful tool.

We hope that what we have added meets your requirements – please check with some test data and advise us.

Thanks

eaDocX support

[Adrian Support]

Thanks – the reason to have a checkbox is to enable/disable the capability as it may not be required/wanted by all users.

We will discuss here and hopefully have something soon.

BR

[Adrian Support]

Hi

Thanks for this info – using SQL provides the flexibility but as we have seen on this forum there are some issues.

I had a look at supporting inherited tagged values and looks like it shouldn’t be too much of an issue, a simple flag could be set (checkbox) and we could output inherited if no local tagged value.

however – how do we, or do we need to, indicate that the tagged value is local or inherited. Not sure if this is an issue or not.

In any case would need to check with the other guys here on their views.

Let me know your “ideal” requirement and I can see what we can do.

BR

[Adrian Support]

Hi

I’ve looked at your example and you are correct that when you inherit tagged values into objects, until the objects create their own values for the tagged value items, they remain blank. Of course if you set a value in the instance it will be displayed.

At present we don’t have a “switch” to check for and output inherited values. If we did I am assume the requirement would be to

IF present then output the local tagged value i.e. element has a tagged value of that name set
IFNOT and there is an inherited tagged value with the relevant name output its value.
Is this what you would like to see?

Of course I’m assuming that there aren’t some use cases in which there could be multiple inherited tagged values (!!!)

If so I can add to the wish list – however at present I can’t see a quick workaround.

eaDocX Support

[Adrian Support]

Hi

This looks like a problem with the file and that it didn’t download completely/correctly.

It is essential that the file is downloaded into a directory for which you have permissions.

I suggest you retry the download and verify that it is of the correct size – 15,163 KB.

Let us know if you continue to have problems.

Regards

eaDocX support

[Adrian Support]

Hi Heather,

2010 is the version used the majority of the development and by us on a daily basis, so don’t anticipate any issues.

Regards

Adrian

[Author]

Posts