Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Oliver F.

Pages: 1 [2] 3 4 ... 39

There's currently a bug in the latest v13 version (1310) where the diagram.Figure field doesn't work anymore when opened in MS Word. It just shows the fixed test "diagram sequence".

Ah, yes, I noticed that one yesterday, too.
As well as the fact that the ToC sometimes uses a different numbering scheme than the heading styles- In the document I can see 1.1, 1.1.1,1.1.2, 1.2, 1.3, 1.3.1,2, etc.
The ToC renders it like 1.1, 1.1.1,1.1.2, 1.2, 1.3.1, 1.3, 1.3.1,2.1.1, 2, etc. It spontaneously seems to increase some levels and then return back to the sequence even if I am updating the ToC in Word over and over again.

Section numbering is the biggest PITA in the whole document flow as it produces inconsistent effects across the documentation toolchain most of the time and itīs been like this for a very long time now.

If you are free enough to choose the way how the documentation should look like you can start from ground with new templates and fragments.
If you want to produce documents according to a certain existing documentation standard/structure because you have to stick with safety rules et al. things are becoming quite inconsistent.


For some years now I am riding the document generation challenge through several companies and versions of EA and I can proudly say that I have mastered various cliffs to gather lots of expertise in that field. Still I have to admit the EA still surprises me with good old bugs I have encountered before and new issues I havenīt seen before.
Lots of things have changed in the last years to the positive, the editor has new features improving the template creation experience, we now have fragments (great thing) and stylesheets (also great thing).

On the other hand we still do not have  a reliable way of creating documents which look the way they should. First of all  I can still fool the editor (or the editor fools me depending on the point of view) by moving around items up and down the sections list which suddenly leads the editor to extend the SSBookmark style to sections it does not belong to thus marking these as protected text. The other way round I can remove line breaks under certain conditions in the template which also confuses the editors handling of the SSBookmark style. OK, I can get around that, this one is an old one. I got used to.
Another old topic is the section numbering between MS Word and EA which often enough messes up and requires careful fine tuning between the styles on both sides, especially (at least it seems so) when non-English installations are involved.

But a very new friend of mine appeared just today: I am able to create the (virtual) document using the same style, templates and stylesheet as RTF, Word and PDF and they look completely different.
First of all the .docx has lost all styles in the process. No styles (Heading 1,...) can be seen in the style bar if I am using our custom stylesheet. No, the sheet is ok. It has all those styles in it and I can see it in EA in the preview. The styles in turn are correct when rendering the same document as RTF. In RTF on the other hand there are no longer tabs and spaces in the style after the numbering which in turn the docx has. Fun fact: The chapter numbering in both documents starts with 1, but not in their ToC where Heading 1 starts with 3 which in turn is nowhere set in any list level and list override.
The docx in turn has no level numbering below level 1.
And the pdf document in general starts numbering with 3 while looking almost perfect in any other aspect (if we ignore the fact that the image caption now uses level 1 numbering which is also never set in any style in any template).

Donīt get me wrong, EA is still a superior product and the document generation is rather helpful. On the other hand it is highly disappointing to see the old problems still being alive and that I still have to find out which issue is caused by me and which one is EA specific by time-consuming investigations. I wished I could solely focus on improving templates and not chase issues between myself, EA and MS Word 2010.


Bugs and Issues / Re: Problem to check-in to PTC
« on: May 26, 2017, 05:32:16 pm »
Hi Rolf,
correct me if I am wrong but my impression was that you managed to exchange/sync information between EA and PTC Integrity, eg. requirements, a use case which I am also looking after.
So any hints or pointers regarding the workflow you have set up here would be appreciated. Sorry for the OT.



Bugs and Issues / Re: Problem to check-in to PTC
« on: May 24, 2017, 08:32:58 pm »
Somehow I failed to get the problem as a whole.

It would be great if you could describe the workflow between PTC and EA which you are attempting to set up.
I am having a similar need here and it would be helpful to see how people are attempting to solve that issue and to be able to help you with yours.

Thanks in advance.

Best regards,


General Board / Re: email notification
« on: May 19, 2017, 01:12:15 am »
I can see the end of the fat client will come one day ...

I keep hearing that for more than 20 years now with sometimes more and sometimes less conviction  ;D

Automation Interface, Add-Ins and Tools / Re: Attribute move
« on: May 13, 2017, 01:35:33 am »
Oliver is right. You "could" change t_attribute.Object_ID, but I'm not sure if that's the best idea.

Interesting option here to manipulate the DB objects directly. Though Iīd second the doubt as probably not even Sparx is applying that sort of change when moving items but using a layer in between instead which benefits from generic transactions et al. There are way too much things which could go wrong otherwise.


Automation Interface, Add-Ins and Tools / Re: Attribute move
« on: May 12, 2017, 10:47:41 pm »
To the best of my knowledge you canīt. This is implemented by the UI and not exposed by the API as the parent ID is read-only:

ParentID | Long | Read only | Returns the ElementID of the element that this attribute is a part of.

However if you can live with the moved attribute having a new GUID you can use AddNew to build a new attribute at the correct target, copy all entries from the old one and delete that afterwards.


Uml Process / Re: Requirements model vs User Stories in scrum tool
« on: May 04, 2017, 11:36:17 pm »
Late answer in an old thread but better late than never  :)

Basically what we are talking about here is how to name the same child. From my point of view this misses the point- the discussion should not be whether we should go with use case or user stories but what is the content of the required artefact. Or in other words: Which information is required upfront for which stakeholder and how does this information evolve in a way which makes it possible to develop/describe a solution suitable for all stakeholders now and in the future? (Note - talking about stakeholders involves customers, developers, architects, testers, maintenance staff, sales, etc.).

Having that said there is a certain ambiguity between requirements, user stories and use cases which often confuses development departments which then leads to the (often failed) attempt to simplify that by using only one of these.

Separating the problem into development phase domains (eg. by saying a requirement is an analysis artefact only) is not helpful either- you will face the problem that in dynamic environments requirements are appearing at any stage of development and stating that user stories are candidates for the dumpster creates a lot of redundant work to be done.

Now if we think about use cases it is a good approach (aka best practice) to look at them as a formal template which, if completely filled, contains the maximum amount of information required to describe a certain functionality to the maximum extent: Basic path, alternative path, exception path (often disregarded and ignored), constraints, preconditions, etc.
This is valuable stakeholder information- eg. testers can create their test cases, developers know how the system handles specific situations, engeneering can evaluate the capabilities of the system, maintenance personal can create their verification cases to check for failures, even sales can get an idea about the capabilities of the product they want to sell. Such a use case can also act as a contract to the stakeholders to enable commitment.
Remember what I stated above: This is the (desirable) maximum and can be customized to your needs.

However such an extent is not available when the first discussions with the stakeholders or customers start. In fact a compact user story is more likely to be created which is much more comprehensive and built much quicker. A user story today is often more like a rough sketch of user ideas than real development input.

So having a gap here between that sketch and the full information picture a best practice approach (at least from my experience) is to start with user stories with the customer/stakeholders to enter a further and ongoing discussion with them so that in the end all required information from the aforementioned template is complete and documented (while collecting further requirements in parallel). Whether we call it user story or use case in the end is a wording issue.
Long story, short sense: Seeing user stories as a lightweight variant of a use case which evolves over time is the key to prevent confusion.

Sorry for being late here, I have been absent for a while and just catching up  8)


Suggestions and Requests / Re: Multiple instances of element in diagram
« on: February 23, 2009, 11:23:44 pm »

What if the 'duplicate' was merely a 'ghost' image - not a real component / element - just a replicant that referred back to the single 'real' element?

How would that be different to the (exisiting) "instance of" type?  ;)


Not sure, Oliver. But let me use an example to find out what you're referring to.

So if I have a 'Component' element in a busy, large, complex diagram, and it would be really useful to have a copy of the same element on the same diagram just for presentation purposes - with connectors from the copy to certain other components - how can I create an 'instance of' one of the Components and have both on the same diagram?

In default configuration you get a dialog to choose whether to drag the element as a link (which you normally do), an instance or a new element. If you have diabled this dialog you can enforce it by dragging and dropping  the element from the project browser while holding the Ctrl-Key.

Or does my question belie my lack of understanding of the nuances of UML?

Not at all.
My proposal was more of some sort of workaround. The "ghost" element you described behaved like an instance- it has the same type but different connectors.
But in fact its meaning in UML is different as the "ghost" element and I believed that it would be valid to be used for business process descriptions as there is no "instance of".
However I would not apply this method to class, component, use case and other UML diagrams because it invalids their meaning and intention.


Suggestions and Requests / Re: Multiple instances of element in diagram
« on: February 23, 2009, 08:25:36 pm »

What if the 'duplicate' was merely a 'ghost' image - not a real component / element - just a replicant that referred back to the single 'real' element?

How would that be different to the (exisiting) "instance of" type?  ;)


Suggestions and Requests / Re: Multiple instances of element in diagram
« on: February 20, 2009, 07:20:58 pm »
Then remove the non-UML model types from EA. I'm talking about flowcharts, and analysis diagrams where you just need to get your artifacts on a diagram to help present a picture of your enterprise to a bunch of executives.

Sean, I accept your motivation and see your issue. However the problems of duplicate elements will remain, especially when it comes to connecting elements together, changing appearance, creating references or searching in diagrams. This is regardless the type of elements or diagrams you are creating and I assume that the efforts of implementing a clean solution (touching various aspects in the model and diagram handling) which is satisfactory for most application are rather high not justifying the cause.


Suggestions and Requests / Re: Multiple instances of element in diagram
« on: February 19, 2009, 11:30:11 pm »
Add me to the want list. Even choosing a diagram like Extended->Analysis, which has no restrictions or standards gets you nowhere. So if you have to put together a business, or executive level presentation about business processes you either need to hack up your model with a folder full of 'dupes' or head off to Visio.

Be aware that having multiple objects in one diagram breaks the idea behind most UML diagrams. In the systems modeled there is always only one type of an element and everything else is an instance of that type.

Imagine having a complex activity diagram where the same activity is present in multiple branches which would require that both share the same connections. That would make the diagram totally unreadable. If I added a new connector to one it would surely be valid for the second also.
A class is a unique element type as well as a component and a use case is.
If you want to show the same element in several different aspects it is best practice to show this in a separate view (aka diagram) and do a nested/composite model structure. This also applies to business processes and requirements- not only technical UML models.


Suggestions and Requests / Re: Diagrams as first class citizens of model
« on: September 04, 2009, 01:48:55 am »
Maybe, when they are refactoring the diagram part of EA anyway they might as well allow multiple representations of the same element on a diagram.
Something I've been asking for for ages.

And something I have been opposing against for a while. The reason why people might want this is related to diagram layout, not model. This feature does not bring more information to the model but adds confusion, because to do it right you will have to limit the number of connections for all appearances, otherwise the diagram will drift towards spaghetti. And if you do this you loose the ability to overview all aspects of an element because the element identity is divided across the diagram making it easy to overlook things.

So my vote is a clear "no"  8-)


Suggestions and Requests / Re: "NOT allowed" relationships in Quick
« on: May 11, 2010, 12:55:12 am »
Isnīt what you want to accomplish done via a simple line in the CSV with only A-D being filled and "Exclusive to ST Filter + No inherit from Metatype" set to true?

But even in partem, I believe "Exclusive to ST Filter + No inherit from Metatype" set to true only inhibits the generic (Help: do not display the Quick Linker definitions of the equivalent unstereotyped element.) But I may be wrong in interpreting the Help.  I'll try it out and get back here.

From what I recall you can create a linker definition from element a stereotype A to element b stereotype B and leave everything else empty except the "Excelusive to ST Filter " column which will prevent connection options shown from a to b (with the corresponding stereotypes).


Isnīt what you want to accomplish done via a simple line in the CSV with only A-D being filled and "Exclusive to ST Filter + No inherit from Metatype" set to true?


Pages: 1 [2] 3 4 ... 39