Templates and report specifications

[Modesto Vega]

We have a set of templates as part of an enterprise/corporate architecture repository. They work fine but would like to make a number of enhancements.

In a nutshell, we have a repository with multiple pages per domain/area/project and we have strategically placed Report Specification elements on diagrams to be able to generate the relevant documentation. All of this works fine but will like to try to achieve the following and don't seem to get it working:

• Have the template version as a constant to be displayed in the Cover Page. For this I am using a Project Variable, but it seems to be constant across all templates in the repository. If I change it in one Report Specification, it changes in all Report Specification elements using the same Template
• Pass the ReportName, with the ReportName changing from package to package -  e.g., Customer Registration Class Model, Sales Class Model, Order Fulfilment Class Model, and so on - to also be displayed in the Cover Page. Again I tried to use Project Variable but it is also constant
• Pass the Package Version to be displayed in the Cover Page, this is easy to do with through the Package in the template editor but displaying it in the cover page looks impossible (or nearly)

[Geert Bellekens]

Have you tried using virtual documents?
On the «master document» you can set a number of tagged values that can be used on the cover page.

Geert

[Modesto Vega]

I have not looked into this. Thanks for the tip, I will give it a try.

[Modesto Vega]

Thanks Geert, report packages and master documents were not only the answer that I was looking for but as I wrote elsewhere provide the means of segregating the documentation from the actual models. It is a very elegant way of placing the documentation and the models in separate branches of the repository. As a result, this allows the creation of a documentation view which differs from the actual structure of your models.

[Geert Bellekens]

Thanks Geert, report packages and master documents were not only the answer that I was looking for but as I wrote elsewhere provide the means of segregating the documentation from the actual models. It is a very elegant way of placing the documentation and the models in separate branches of the repository. As a result, this allows the creation of a documentation view which differs from the actual structure of your models.

I couldn't agree more 

Geert

[Paolo F Cantoni]

Thanks, Geert, report packages and master documents were not only the answer that I was looking for but as I wrote elsewhere to provide the means of segregating the documentation from the actual models. It is a very elegant way of placing the documentation and the models in separate branches of the repository. As a result, this allows the creation of a documentation view which differs from the actual structure of your models.

I couldn't agree more 

Geert

+1

Paolo

[Modesto Vega]

There are 2 minor glitches with this, none of which would cause us to abandon this approach. But it is a bit annoying that we cannot find a way around them.

The simplest one concerns concatenating the element name to its stereotype(s). We always end up with “Element Name <<Stereotype>>” when we want “Element Name Stereotype”. Is there anyway to remove both pairs of < and >?

The more complex is to do with filtering, we are trying to use one template for 2 purposes: to publish approved documentation/designs and to make available work-in-progress documentation/designs for review and discussion. In one case we want to include all elements irrespective of their status and in the other we only want to include elements with a status of approved or implemented. The idea is to be able to iterate through a set of documents/designs. We have tried a number of workarounds all of them resulting on the same frustrating result: we always get all elements.

The search functionality in the Master Document does not seem to do anything. Furthermore, the only way to achieve this appears to be to use 2 copies of the same template with different filters which is not very efficient because any template change has to be done twice.

[RoyC]

The simplest one concerns concatenating the element name to its stereotype(s). We always end up with “Element Name <<Stereotype>>” when we want “Element Name Stereotype”. Is there anyway to remove both pairs of < and >?

Not sure, but try opening the 'Preferences' window (Ctrl+F9) and, on the 'General' page, clearing the checkbox for 'Use extended « and » characters'.

[Geert Bellekens]

The simplest one concerns concatenating the element name to its stereotype(s). We always end up with “Element Name <<Stereotype>>” when we want “Element Name Stereotype”. Is there anyway to remove both pairs of < and >?

Not sure, but try opening the 'Preferences' window (Ctrl+F9) and, on the 'General' page, clearing the checkbox for 'Use extended « and » characters'.

I thought that was simply replacing « and » with << and >>
Never tried it though.

Anyway, using an SQL fragment it's rather trivial to get the stereotype without the « and » as it is stored in the database without.

Geert

Geert

[Modesto Vega]

Thanks Geert.

Am I correct to assume that using a SQL fragment in EA V13 means using a Template Fragment? This could force us to rewrite all templates.

You are right about Sparx not storing '«' and '»' in the database, we checked before posting.

Both

{Element.Name} {Element.StereotypeEx}

and

{Element.Name} {Element.Stereotype}

Result on a Element Name «Element Stereotype» being printed/output, e.g. Vehicle «Concept».

Furthermore, I suspect that unless I alias the Stereotype column to something not using the word Stereotype, I am going to end with Vehicle «Concept».

It is strange that Sparx does not allow suppressing '«' and '»' when generating documentation.

[Geert Bellekens]

Thanks Geert.

Am I correct to assume that using a SQL fragment in EA V13 means using a Template Fragment? This could force us to rewrite all templates.

Yes, that is correct

You are right about Sparx not storing '«' and '»' in the database, we checked before posting.

Both

{Element.Name} {Element.StereotypeEx}

and

{Element.Name} {Element.Stereotype}

Result on a Element Name «Element Stereotype» being printed/output, e.g. Vehicle «Concept».

Furthermore, I suspect that unless I alias the Stereotype column to something not using the word Stereotype, I am going to end with Vehicle «Concept».

It is strange that Sparx does not allow suppressing '«' and '»' when generating documentation.

I don't think EA adds the "«" and "»" in SQL fragments, but if it would, then an alias would indeed solve that.

Geert