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 - Uffe

Pages: 1 ... 5 6 [7] 8 9 ... 70
91
There's always hidden text. That does get generated through (at least to Word, not sure about PDF), but the user must actively switch it on to see it.

/Uffe

92
If you create a Note and link it to the requirement, then select Link to Element Feature -- Single Tag and Notes, the full contents of the <memo> tagged value are displayed.


/Uffe

93
Hi Julian,

In your code, you don't refresh Element.TaggedValues, which you need to do if you add objects to it. AdviseElementChange() is a GUI operation, it does not affect the objects in your code.

Other than that, what Geert said. You have to use Collections when manipulating various project content, but never ever create one yourself, and if you need to do a lot of back-and-forth, cache the contents in a better data structure.


/Uffe

94
You can't "stereotype" diagrams
Uhm. There's a stereotype property for diagrams.

Yes, but it has no meaning. The UML concept of a stereotype does not apply to diagrams, and what's been implemented in EA looks more like a mistake than anything else. It is a free-text field which is not related to the diagram's type or to anything else.

You can enter a value in the diagram properties dialog, and pull it out again in a documentation template, but that's it. It's not related to what's in an MDG Technology, and you can't "apply" your custom diagram type as a stereotype, is my point.


/Uffe

95
Bugs and Issues / Re: Searching using a famous search engine
« on: June 26, 2017, 06:11:17 pm »
Hey - a ring! Let's throw a hat in there!

The problem here is that the famous search engine doesn't return the most relevant result first. This tends to be self-perpetuating, since people tend to follow early links first, and so the famous search engine marks those as more popular -- even though realizing that a part of a URL constitutes a version number and giving the more recent one priority isn't hard to do. It is, in fact, urine simple. But as I say, this is a problem with a famous search engine, not with the indexed web site.

I don't agree that telling asking politely the famous web crawler not to index documentation for older versions is a good idea. Larger organizations especially are typically a ways behind the upgrade curve, and you want to be able to find the documentation for your version using the famous search engine rather than the unmitigated horror show local site search the site owner provides.

But some sort of alert on older-version pages seems like a great idea. There should be a link to the most recent version of the same page, if available, or to the lower-most matching node in the documentation tree if not.

Ideally, each page should also contain information on which versions it's relevant for. That way you'd know, if you were looking at an old page, whether there'd be any point in looking at a more recent one.


/Uffe

96
Hi Patrick,

Please note that this is a user forum. There are a couple of Sparxians here, but most of us are regular users or EA consultants (plug plug).

This subforum is for discussion suggestions with other users. Posting here does not constitute making a feature request to Sparx Systems. In order to do that, follow the link provided on the forum front page.

/Uffe

97
I have now 3 profiles, including 1 for toolboxes and another for diagram extensions, and have hit the 1st problem I cannot seem to solve, once the profile is imported I cannot stereotype diagrams. I can stereotype anything else, classes, relationships and packages but not diagrams. Am I missing something?

You can't "stereotype" diagrams, that term doesn't apply. You should be able to see your diagrams in their own section in the New Diagram dialog -- provided you have correctly referenced / imported the MDG Technology.

You might want to have another look at your «profile» packages. One with the UML profile and one with the diagram extensions sounds right, but each toolbox should have its own «profile» package. Unless of course you're confusing "toolbox" and "toolbox page".


/Uffe

98
General Board / Re: Autonumbering on stereotype level
« on: June 26, 2017, 05:39:00 pm »
Just a quick note on scripts and Add-Ins. This applies to EA out of the box, without any third-party additions.

Scripts have access to what's called the "object model" in the EA API. Add-Ins have that plus the "Add-In model". In terms of what they can do to the contents of an EA project, there's no difference. Scripts can even pop up their own dialogs and things.

What an Add-In can do that a script can't is receive events fired by the EA client (also integrate windows into the EA GUI). So if you want something that can apply numbering to a model after the fact, you can get by with a scripted solution. If you want to automatically apply numbering when an element is created, you have to write an Add-In.

HTH,


/Uffe

99
Hi Julian,

*.Update() writes the object to the database. If you don't call that after making changes to an Element, Package, Attribute, Collection, etc, the changes will be lost when the variable goes out of scope.

Collection.Refresh() does the opposite: it rereads the collection's contents from the database, so the Collection object in your code is in sync. It should be called after you've added or deleted objects in a Collection. You don't need to call it if you've only made changes to the objects in the collection -- I think.

With diagrams, you should call Diagram.Update() after modifying the diagram's attributes or its contents.

Those are the key ones. You need to use them, or your changes won't take.

Element etc also have a .Refresh(), but it doesn't do the same thing as Collection.Refresh(). Instead, it updates the GUI. You can typically leave that out, I usually do. If needed, the client will flash a message telling the user to refresh manually, so it tends to take care of itself.

Repository.Advise*Change() tells the EA client to refresh the GUI, if necessary, after you've made changes (to already existing objects) in the database. If it works right, it should advise all currently connected clients but I'm not sure about that.

Project.ReloadProject() reloads the current project, and Repository.RefreshModelView() reloads a package. But, I'm pretty sure, only for the client where the call is issued.

Repository.RefreshOpenDiagrams() and Repository.ReloadDiagram() refresh diagrams if they're open (again, only in the client where the call is issued).

HTH,


/Uffe

100
General Board / Re: Phase enum in EA?
« on: June 22, 2017, 07:24:26 pm »
Hi Patrick,


It looks like the "phase" of an element was once intended to be expressed as an enum, but then that got ditched and replaced with a free-text field.

There is a table t_phase in the database; it is empty in a newly-created project (as opposed to, say, t_statustypes).
I have not been able to find a GUI to manipulate this table.
If you look at the project reference data export dialog, you can pick all the other data types that are defined in a project (constraint statuses & types, risk types, estimation factors, etc etc) -- but there is no selection for "phase types".

I did try to push some data into t_phase, and I can get something in there but it still doesn't show up in a "Phase" tagged value. Tagged values of that type don't even get an empty dropdown list, they get free-text fields -- meaning that EA doesn't understand them as enums at all.

So my conclusion is that the inclusion of the "phase" in the list of reference data types is a result of the left hand not knowing what the right hasn't done.

HTH,


/Uffe

101
Well, virtual documents are not without their problems either. With virtual documents you end up with models which need to be maintained, whereas a scripted document generator pulls everything together on the fly and outputs the document.

As to virtual documents affording greater flexibility, that is a matter of opinion. A script is no less flexible than a model, it's just a question of which way of working you're more comfortable with: code or models. I should also point out that with the semi-automated approach you end up having to maintain both a script and the resultant set of models.

I would sum up the different approaches to document generation as follows.


With the most basic, just-hit-F8 way of generating a document, the document structure is tightly linked to the project browser structure. If this is something you can live with, then that's the simplest way to go.

With a virtual document, you put together the document structure manually in the form of a model. The document structure survives restructuring of the source model (up to a point), although of course if you delete parts of the source model your virtual document breaks. (Silently.)

With a scripted document generator, the structure goes in the script. This allows you to lay out your document according to other structures than the browser hierarchy -- you can easily follow connectors, instance/classifier relationships, attribute types, RefGUID tagged values, etc, and base the document structure on that. You can also InsertText(), which allows you to put in results of calculations or anything else that takes your fancy.

The combined script-and-virtual-document method creates a virtual document based on a source model and a structure hard-coded in a script. This gives you the option of modifying the virtual document structure after it's been set up, but it also brings the drawback that virtual documents have: the virtual document is based on the state of the source model at some point in time but has no in-EA relationship to it, and so needs to be maintained in lockstep with the source model.


When I refer to scripts above, the same applies to Add-Ins. But in terms of document generation, there's nothing an Add-In can do that a script can't (except automatically trigger a document generation based on some event fired by EA). Add-Ins are compiled, of course, so the development turnaround is longer.

In general, for complex documents I prefer a scripted approach in many-of-the-same scenarios, where many documents of the same type (eg software component requirements specifications) are to be produced from many distinct, but identically structured, models. In situations where the documents are fewer in number but perhaps broader in scope, such as a progress report on the requirements analysis work taking place in an EA project, I favour virtual documents. I have yet to find a use for the combined approach.

In this situation, where you want the process to generate a document and do a bunch of other stuff at that same time, I would advise against virtual documents in any guise. Virtual documents "freeze" a document structure at some moment in time, which is useful if you want to make changes to the document structure in between creating the virtual document and generating the output document but not otherwise. If you want the generated document to reflect what's in the source model at the moment of TFS synch, and if you don't want to generate the document at any other time, I see no reason to set up a virtual document.


/Uffe

102
General Board / Re: Operations and Actions
« on: June 20, 2017, 09:04:44 pm »
You could run write a script to rename the call actions if you so wish.
FTFY. :)
The point is that there's no such script available out of the box.

As to Tiger's first question, why not simply use an interface which the applications (presumably components or classes) realize?

When you draw the realization connector, you get the option of overriding the operations in the realizing component/class. Overriding creates local copies of operations in the component/class as if you had created them manually -- but note that subsequent changes to the interface (eg renaming an operation) have no bearing on the components/classes: the copied operations are copies, not references to the original.

You can of course also work with abstract classes which you specialize. In this case, the operations in the specialized class/component is not a copy but a reference to the operation in the abstract class, so changes to the operation in the abstract class are immediately visible in the specialized elements.

HTH,


/Uffe

103
Hi Brian,


Well the printItem variable is pointless -- your element parameter holds the same Element. Other than that, the code looks alright.

There are some options in the document generation dialog you can't set from the API, but apart from those, generating documents for the same element using the same template should yield the same result regardless of method.

When you say
Quote
When I run the template from EA at the level of a Use Case it produces the output I expect.
When I run it from my own .Net code it only produces what seems to be items at the Element level.
-- what do you actually mean by that? A use case is an element.


/Uffe

104
3) There has never been a pre-defined diagram meta type. That needs to be input manually.
Or using the "Diagram Extension" profile helper. This one is actually pretty useful.

2) I am having some difficulty relating 2 stereotypes via an aggregation
...
It appears the answer to 2) is to link 2 stereotypes with any other relationship and change the type to an Aggregation. This is very sparxian, is there a better way of doing this.

I'm missing something here. Why do you want to draw an aggregation between two stereotypes? What does that do in the profile?

/Uffe

105
The change in the extends connector from a stereotyped association to its own metatype happened a few years ago (v11?) -- it's just someone hasn't updated their sample model to reflect this. ;)
I'd be surprised if the change was forwards-compatible, but I'd be even more surprised if it wasn't backwards-compatible.

However, what we're talking about here is compatibility of the profile model -- not the resultant profile. The extends connector is interpreted by EA during profile generation, and is not present in the XML output. There, the concept is represented with the <AppliesTo> tag, and that hasn't changed.

So a profile created with EA 9 will work in EA 13, and vice versa.

If you've got an old profile model knocking around that was created in EA 9, you should be able to import that into EA 13 and create a correct profile from it. But the reverse is likely not true.


/Uffe

Pages: 1 ... 5 6 [7] 8 9 ... 70