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

Pages: 1 [2] 3 4 ... 7
Bugs and Issues / Re: Windows 10 issues
« on: February 03, 2017, 07:34:03 pm »
Thanks everyone - false alarm - IT support desk determined it was an access rights issue.

Bugs and Issues / Re: Windows 10 issues
« on: February 02, 2017, 09:40:29 pm »
We've had a problem with installing 1308 in Windows 10. Compatibility mode OK? Or should we avoid the upgrade?

Many thanks Geert. That's brilliant.

Having model elements to represent TFS stories, features etc in Sparx EA will support traceability and agile modelling.
We want to avoid rekeying and dual maintenance of the stories, etc in TFS and EA.
So, does Sparx EA integrate with TFS in such a way that TFS stories, etc are synchronised with model elements in Sparx EA? That is, model elements which are the stories and features, etc.

For anyone else reading this post later, and for completeness, does Sparx EA integrate with TFS for:
  • For versioning the code generated from the model?
  • For versioning of the model elements?

General Board / Re: Changing Stereotypes
« on: December 06, 2016, 04:04:26 am »
Thank you Qwerty
I understand the caution.
Your suggestion is to use side scripting on the Sparx client?
I've not done anything with that yet.
I looked into it on the help files but was put off by apparent complexity.
Please can you point me at some clear examples / pointers to get started?

General Board / Changing Stereotypes
« on: December 06, 2016, 03:31:03 am »
Several hundred model elements were stereotyped "PhysicalDataComponent" (PDC) when they should be "PhysicalApplicationComponent". (PAC)
Manually changing them is one option  ;D

Updating the value in Stereotype field in the SQL t_object table gets you some of the way there. But there seems to be some 'hangover' where the old PDC stereotype still exists as a second stereotype in the browser. It will switch off if I manually go to the element properties and disable that PDC stereotype. Again, manually changing them is one option  ;D

Back to SQL I found that the t_objectproperties table held entries for each element, which were for the tags that came with the PDC stereotype. Deleting these entries cleared the PDC stereotype from about half of my elements. But not all. And now I'm wondering if anyone out there knows the underlying schema well enough to suggest where this ghost is hiding, please?

Suggestions and Requests / Re: TOGAF 9 support
« on: September 17, 2016, 12:51:29 am »
Yes, and in Extensions->TOGAF->About, we see "tool certification pending"  ;)

General Board / Re: TOGAF and Archimate technologies
« on: September 17, 2016, 12:48:50 am »
Hello Stig

Did anybody reply to you?
We're working it from the other way around, whereby we'd like to move over from the TOGAF content model to using Archimate constructs in order to leverage BEASI. But we'd keep aspects of TOGAF content model (and extensions), and certainly keep our model structuring/process alignment with the ADM.
How did you get on? Did you know that The Open Group are working on "Project Harmony" to harmomise Archimate and TOGAF?


Scripting seems to be the option.
A script that scans through all elements in a diagram and converts its type to 'Object' (thereby retaining all its connectors),
Create a 'Class' object into a set package, using the name and other metadata from the original object
Set the new Class ID / GUID as Classifier to the original Object (previously class) to make sure it knows its Classifer.
Good logic - which ought to retain the diagrammatic representations. Thanks.

What's the essential difference between packages and views in the browser?
I dug through this a while back. Here's what I came up with. Use this information at your own risk.

A regular package is represented by both a t_package row and a t_object row. They appear to have the same ea_guid, but Sparxians have warned us before that that is subject to change without notice. However, the t_object.PDATA1 column will match t_package.Package_ID.

A View package has the same representation in the database, except there is additional information in t_package.PackageFlags, namely isModel=1;VICON=n;, where n is 0-5, specifying the view icon shown in the project browser.

A Root Node is a little different still. It only has a t_package row, not a corresponding t_object one. Its t_package.PackageFlags is set to isModel=1;, but it has no view icon. t_package.Parent_ID is 0.

EA prevents you from moving root nodes and views to other levels in the package hierarchy, and from moving a regular package to the root or view levels. You can work around this using the API (by setting Package.ParentID), but only for moving between the view and package levels, not to/from the root level.

This explains why views, but not root nodes, behave as regular packages in that they can be shown in diagrams and be the source or target of connectors: it's because root nodes are not t_objects, just t_packages, and only t_objects can be can be used that way in the EA data model.

Hope this confuses you further helps,


I enjoyed everyone else's banter, but thanks to Uffe I have a path to automate project template instantiation.

Modelling has proceeded with relationships being drawn between classes.
We want instantiate the classes into objects such that:
  • the classes to become architectural building blocks as defined by TOGAF: the classes should not retain the relationships - they are building blocks and should be freely available to instantiate within baseline and target architectures.
  • the instances retain the relationships that existed between the classes, and the instances appear on the diagrams that the classes had appeared on
The manual effort is onerous. Does this require scripting or is there a pre-canned solution in EA?
Thank you.

Thanks John. Yes it makes sense and a set of requirements can be conceived. I'm on-board!

Does anybody know ...

Why does EA enforce a root node to have a second level of "views" before you can add a package to the third level?
Or, put another way, why can't packages be placed directly under nodes? What's the essential difference between packages and views in the browser?

Thanks in advance.


Most are self-explanatory, although I'd like to expand on the "Roadmap as a process (As an artifact)" piece: I think the idea here is that we'd not only like to have clear visibility of the roadmap, but also have the user group feed into the process of determining the roadmap in a more formal way. I-Logix for Rhapsody used to have an Executive User Group that were trusted to feed into the roadmap. Could Sparx do something similar.

Also, come somebody expand on the "Security of Views" piece?



General Board / Re: Show Connectors IDs on diagrams
« on: May 19, 2016, 05:57:19 pm »
As an alternative to creating Tagged Values - Connectors do have an Alias, this can be shown on the diagram by selecting the Diagram Property
 [ x ] Use Alias If Available.
The Shortfall is that you will see all the Element Aliases if these are set as well.
Hi Matt,
The IDs are Surrogate Keys - they are (quite rightly) intended NOT to become Domain Keys (which by exposing them - you create).  As Geert says they are unstable, and what's more, under certain circumstances will be re-used - internally.  For example, after a project Transfer or Compacting an .eap file.  It's just NOT worth the risk.
Both excellent contributions, and marked as helpful. What I love about the forum is the way it extends your options and ignites passions.
Being aware of the risks of some practices, and having options without those risks, it would be folly to take the risk.

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