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 5 ... 7
31
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?

Namaste
YogaMatt

32
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.

33
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,


/Uffe

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

34
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.
 

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

36
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.

37
Great!

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?

Cheers

Matthew

38
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.
Namaste

39
General Board / Re: Show Connectors IDs on diagrams
« on: May 18, 2016, 10:28:34 pm »
That makes perfect sense.
With regard the mode of versioning you mention, that will quickly cause ID drift between branches that'll need to be reconciled - hence instability will be seen (if you're paying regard to variations between branches off the trunk).
With regards to automatic assignment - IF what happens is that IDs are assigned from max(ID) + 1 rather than filling holes created by deleted connectors, then IDs could be used, but with caution.
Like everything, if we know what we're doing and tie down the implications of a particular approach, then use what works?
Thanks,
Matthew

40
General Board / Re: Show Connectors IDs on diagrams
« on: May 18, 2016, 09:13:16 pm »
Once again, very helpful.
As we already have a stereotype for the connector type in question, we're some way there.
I'd still like to understand better the drivers behind the instability - have IDs got a bad rap for stability because of unintended consequences of diff/merging etc, or are there other causes?

41
General Board / Re: Show Connectors IDs on diagrams
« on: May 18, 2016, 08:59:08 pm »
Thanks Geert

That's a new one on me. Is the "Reset IDs" function the only means by which the IDs change? If not, what else might/does change them? (I can imagine that import and export will change them).

If you are versioning then IDs will be internally consistent within a version. Between versions could be problematic though ...

Cheers

Matthew

42
General Board / Re: Show Connectors IDs on diagrams
« on: May 18, 2016, 08:42:56 pm »
Hi Geert
To the rescue again I see  :)
A stakeholder wants the numeric ID (not GUID). We're showing interfaces on a diagram and want a quick way of cross-referencing with the interface catalogue, in which we display the numeric ID assigned by EA. Quick and dirty.
Cheers
Matthew

43
General Board / Show Connectors IDs on diagrams
« on: May 18, 2016, 08:33:16 pm »
Connectors have IDs. Is it possible to show them on a diagram?
Any workarounds it not?
Thanks in advance.

44
I'd like to thank very much, everyone involved in making the conference the gem it was: the organisers, the sponsors, the presenters, the delegates and the venue. I had a brilliant time and had plenty of very useful take-home messages.

45
Uml Process / Re: TOGAF and Model Structure
« on: May 04, 2016, 07:11:16 pm »
Update:
We've reached a team consensus - and decided upon a root node for an Architecture Repository of reusable building blocks, alongside other root node (one for each project). The folder structure for the project root node mirrors the TOGAF ADM phases, with baseline and target architectures clearly demarked within each phase. The artefacts within the phases (will) abide by the ACM meta-model.
We use classifiers in the Architecture Repository node and instantiate them in the project node. That way, relationships in a baseline or target architecture do not pollute one another, but the common ancestry is retained.

Outcome:
A team that is happy to proceed. We're mindful that there is no perfect solution, but we're clear amongst ourselves. We're also happy that we will probably need to develop some automations to maintain things, and if push comes to shove we'll restructure (the difficulty of which is often overplayed).

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