Book a Demo

Author Topic: Referencing diagrams  (Read 3862 times)

Tonu

  • EA User
  • **
  • Posts: 30
  • Karma: +0/-0
    • View Profile
Referencing diagrams
« on: June 15, 2005, 05:27:22 am »
Hi,

I am trying to find a good way to reference diagrams from model accompanying documentation. We use quite detailed use-case specifications written in Word rather than in EA. From time-to time it is necessary to give a reference to diagram. I do not want to insert diagrams into the document as, first, it increases the length of occasionaly printed documentation and, secondly, in many cases the use-case and diagram have slightly different lifecycles.

One way would be to use the package name and diagram name, but this needs at least some basic knowledge on navigating the UML model in EA HTML output.  The business team often do not have it. What I was looking for was a method to reference a diagram directly through a standard URI. Unfortuaneltely EA regenerates URI's each time the HTML report is generated, rather than using diagram GUID for composing the URI.

I was wondering if anybody has suggestions to solve the problem? Any suggestion for referencing diagrams differently or, perhaps, a way to influence HTML generator so that it would produce static URI's for old diagrams ...

Regards,
Tonu

sargasso

  • EA Practitioner
  • ***
  • Posts: 1406
  • Karma: +1/-2
  • 10 COMFROM 30; 20 HALT; 30 ONSUB(50,90,10)
    • View Profile
Re: Referencing diagrams
« Reply #1 on: June 15, 2005, 04:46:31 pm »
Forgive me, but this sounds a bit like a fish on a bicycle type of exercise.

If I understand your need, I'd reckon the easiest would be to  manually build a directory of saved images from EA and reference them directly, rather than try and use the html reporter.  ???

hth
bruce
"It is not so expressed, but what of that?
'Twere good you do so much for charity."

Oh I forgot, we aren't doing him are we.

marqpdx

  • EA Novice
  • *
  • Posts: 3
  • Karma: +0/-0
  • I love YaBB 1G - SP1!
    • View Profile
Re: Referencing diagrams
« Reply #2 on: May 15, 2006, 12:40:35 pm »
We have the same issue as Tonu.

In our large organization, a team of architects model business processes. The processes change periodically. We would like to distribute a fixed URI to the team members who use the processes, a URI only for the particular process(es) they use. This URI needs to be constant. When the model evolves, the URI stays fixed. But since EA regenerates the URI every time the documentation is updated, the fixed URI doesn't work, and users lose track of their models. We don't want to have them navigate the entire HTML output searching for their models.

Anyone found a way to get EA to use constant, static names for the models generated in HTML??

Thanks,
mark

Tonu

  • EA User
  • **
  • Posts: 30
  • Karma: +0/-0
    • View Profile
Re: Referencing diagrams
« Reply #3 on: May 15, 2006, 01:02:11 pm »
Hi!

The fact that I never answered to Bruce's posting above does not mean I ageed it is a "fish on a bicycle type of exercise". The need is still there. For me it does not come not so much form the size of my own organisation but rather from the large number of stakeholders. Usually they are distributed, do not have access to the same file server .. and even if they were, I still need as easy as possible way to direct them to the right piece of information.

The workaround I have used so far is an "index diagram" -- I always make an index page for my models with hyperlinks to diagrams and mark it as model default. The index diagram is grouped using notes and each note contains diagram hyperlinks in the order that seems most logical for going them through. This way I can reference to the root URI from documents and give the name of diagram that must be clicked.

Best regards,
Tonu

marqpdx

  • EA Novice
  • *
  • Posts: 3
  • Karma: +0/-0
  • I love YaBB 1G - SP1!
    • View Profile
Re: Referencing diagrams
« Reply #4 on: May 15, 2006, 02:08:25 pm »
We too have looked into the Index page solution, but we have so many processes, that we might have to have a hierarchy of index pages and sub-index pages to make navigation fast and feasible.

The best solution, IMHO, remains a fixed name for output models.

thanks,
mark