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] 2 3 ... 108
This works, thank you.

Although I do think that calling the only way to add the trace relationship to a toolbox that can be found either in the documentation (up to and including 15.2) or the profile helper (up to and including 15.1.1528) an "historical anomaly" is a bit of a stretch.



Not sure what you're after here.
You can import the source code (sort of), but that will give you a UML representation of the classes in SystemC and that only makes sense if you want to model the source code of your project.

If you're doing SysML, I assume you want to model a higher-level design, where SystemC would be a block. In which case there's no point importing anything, just create the SystemC block and you're done.

So... not sure.


Exactly what have you added to your toolbox?

+    UML::Realization = Realization
+    UML::TraceLink = Trace
+    MyProfile::MyStereotype(UML::Dependency) = MyConnectorName

Precisely as instructed on Connectors Used in Toolboxes.

The realization works, as does my stereotyped dependency. The trace doesn't.


General Board / Re: Modelling design considerations?
« on: June 26, 2020, 06:17:36 pm »
Hi Jon,

Is there a standard UML approach to capturing design considerations.

Not in UML proper. Design considerations belong to the realm of requirements, and UML doesn't do requirements. (You can't express design considerations as a use case. At least, you can, I suppose, but what a hell of a life.)

Depending on precisely how you interpret the term I'd say they should be modelled as requirements or requirement types.
If your design considerations are very generic, something like "extensibility" and nothing more, make them requirement types. You will want to nail down what exactly is meant by "extensibility" somewhere along the line.
If your design considerations are more specific, something like "it should be possible to add a new major feature to the solution with no more than six weeks' work", then that's more of a requirement in itself and you could create a DesignConsideration requirement type for it.

Another option might be to turn them into constraint types. I'm less enamored of that, since constraints aren't model elements and therefore can't be traced.



Thoughts (especially from the user base)?

Why yes! I've got some! :)

I fully agree that functionality as advertised needs to work. This means, among other things, that importers need to keep up with changes in source applications.

I also agree that it is a strategy issue.

Should the Visio importer be just essentially an advertising gimmick?
Or a way to sell consultants?
Or should it be a tool for the end user?

If it's a gimmick, all you need is something that you can advertise. It doesn't actually have to work.
If it's a consultancy hook, it has to work but should require specialized expertise to operate.
If it's an end-user tool, it has to work very smoothly, convert the majority of UMLish drawings with zero hand-cranking, and make sense to a business analyst who is not an EA enthusiast and in fact prefers Visio.

My current client gave up on the Visio importer a couple years back. It was distributed along with the client for general use, but there was no concerted effort to import Visio drawings on masse, more there-if-you-need-it sort of thing.
Departments and projects are not required to use EA or indeed UML, so when people tried it and couldn't get it to work they simply went back to Visio. Some of them did realize EA was the better tool even for their specific needs but they were not prepared to spend the money redrawing everything manually, which is what the level of functionality provided by the importer amounted to.
The lesson there is that when a tool switch is contemplated, people don't accept a very high cost for converting existing materials. The cost of retraining and updating internal processes is high enough.

And by the way, I wasn't being facetious with my consultancy option above. That's a valid option; if you can't (or won't) make the tool end-user-friendly, consultants can step in. But we would then also need support from the manufacturer, with solid in-depth documentation, maybe some transitioning training material, that kind of thing.
(I was being facetious with the advertising gimmick option.)

Anyway. There are some thoughts.


Suggestions and Requests / Flash on the web site
« on: June 26, 2020, 05:17:10 pm »
Hey guys,

Time to get rid of all the Flash already. It makes a very bad impression on any potential customer with the least tech savvy, in addition to the practical difficulties in even viewing Flash videos these days.
And six months from now, it will be impossible.

Tick tock. Tick tock.



Your exit condition depends on the size of a collection you're whittling down. This gets tricky.
The simple solution is to loop backwards, and only refresh after the end of the loop.



If you store a file in an element's Filename property, you can hit F12 to view the file in EA's internal source viewer.
Word documents are recognized and open the document editor, and of course there's the internal browser as well.

It would be useful to be able to launch files / URLs from the internal source viewer / document editor / browser. This would just pass the file path / URL to Windows, which would then open the resource with whatever application is registered for the resource type. So just like the Launch button in the File tab of the element properties dialog.


I think this is a good idea, but you can sort of do that with a custom diagram so I'm guessing it won't be a high priority.


Automation Interface, Add-Ins and Tools / Setting the Special Action
« on: June 23, 2020, 06:08:59 pm »

In the browser context menu for an element, there's a submenu Properties where you can open the Properties dialog or execute the Special Action, which often does the same thing but in some cases does something else (some element types have two property dialogs associated with them).

Is there a way for the profile modeller to specify what the special action should be?
Now or in the nearish future?



Suggestions and Requests / Keyboard shortcut to open file
« on: June 23, 2020, 05:58:27 pm »

If you store a file path in an element's Filename property, you can hit F12 (with the element selected) to view the file (in EA's text editor). This is useful.

You can also store file paths and URLs in an element's list of Files (in the property dialog), and Launch them with a button (starting another program to view the file). This is also useful.

It would be usefuler still if there was a keyboard shortcut for this latter function -- Ctrl-F12 or something.

This should:
  • =1 File in the list: Launch the File;
  • >1 Files in the list: Pop a selector dialog that contains all the element's Files with Path/URL, Type and Notes, and then launch the selected one on OK;
  • =0 Files in the list: Open the properties dialog to the Files tab.
A few notes.

The Filename-view function only works on files. While you can input anything into the property value, such as a URL, EA won't open it. It has to be a file (it can't even be a directory).
The File-launch on the other hand can handle both files and "web addresses", ie URLs. There is no requirement that the protocol must be HTTP(S) or anything, so any registered protocol will work (registered in Windows, that is; it's Windows that does the actual launching).

I'm not proposing making any changes to the Filename-view function. That's used in source code engineering, and can be abused in other situations, it's great the way it is.
I'm also not proposing any changes to how the File list works. This is just a way of making it a little more user friendly.


Automation Interface, Add-Ins and Tools / Re: webdoc wtf
« on: June 23, 2020, 01:18:47 am »
They hard-coded quite a bit in EA.exe.

Looks like.

Ironically, I do want an icon to show that a webdoc artifact is a document located on a web server. Just not that one, and not in that location.


Bugs and Issues / Re: Cross-profile «stereotyped relationship»
« on: June 22, 2020, 11:09:01 pm »
If you want to allow a relation to another profile you have to create a stereotype object with the fully qualified name of the stereotype you need.

So in this case you would need to make a stereotype with name B::S2 inside your profile A, and link that with a stereotyped connector.

This works.

I'm not sure Sparx will even consider that a bug (you can create a profile based on a Diagram, rather then a package, in which case it is rather logical to consider everything on the diagram to be part of the same profile)

Oh it's a bug. Sparx might prefer to spend their money on arguing that toss rather than addressing the problem, but it's definitely a bug.

Quite obviously, the intent is for the metamodeller to able to specify various metaconstraints across profiles. Otherwise, the «stereotyped relationship» would only permit non-qualified values (ie same profile) in the stereotype tag, and so on for all metaconstraints.

In addition, using a fake qualified-name stereotype means manual maintenance when renaming the actual B profile or S2 stereotype -- quite counter to EA's repository model.

So a bug it is, though perhaps not one that's likely to get any attention.



There are two very similar metaconstraint relationships; «metarelationship» and «stereotyped relationship». In both of these, you must specify the metaclass / stereotype as free text.
This is stupid.

They should be selectable from dropdown lists or selector dialogs, as is the case when you create a new metaclass or add stereotypes to toolboxes using the profile helper.



I've been trying to create two element stereotypes in different profiles, with «trace» the only permitted connector between them. In the course of my heroic struggles I've come across a pretty massive inconsistency: metaclasses and stereotypes.

If you add a new metaclass to a profile diagram, EA pops the Extend Metaclass dialog. In this, Trace is listed as a Core Connector. So it's a metaclass.
So I should be able to specify "Trace" as the value in a «metarelationship» metaclass tag.

But no -- I have to use a «stereotyped relationship», which has a stereotype tag where I must specify "EAUML::trace". So Trace is a stereotype.

Going back to the Extend Metaclass dialog, trace is actually listed under EAUML in the Stereotypes tab.

So that's Metaclass 1, Stereotype 2. In the same dialog.

My humble suggestion: sort out once and for all which element / connector is actually a metaclass and which is a stereotype, and while you're at it, how about documenting which relationship needs to be specified with a «stereotyped relationship» and which with a «metarelationship»?


Pages: [1] 2 3 ... 108