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

Pages: [1] 2 3 ... 7
1
General Board / Re: Import of large model from an external source
« on: April 12, 2019, 01:03:49 am »
I wouldn't try to go through xmi. That really isn't the most easy format to use.

There are a few options:

- Use the excel importer to import classes and attributes. (Excel scales pretty good and goes up to 1M of rows)  You might want to write additional code to import datatypes (and link them to the attributes) and relations.

- Write a custom import program that reads your source database and creates the corresponding model in EA.

I can't image it being more than a few days of work to get it all done.

If you want to hire me as qwerty suggested (thanks qwerty ;)) you can email me at geert@bellekens.com. But please take into account that I have a pretty full calendar already. Next available days at the moment are in July.

Geert

Thanks for these suggestions. This does not sound as a very easy job.

We are in fact investigating the use of EA for the maintenance of a complex model instead of the current text-based interface. The advantage of EA is its graphical representation of the data but getting the data in EA and creating useful diagrams is then a new challenge.

But is EA in itself capable of handling a model with say 200.000 elements and relations?
Not "very easy" but not that difficult either.
Yes, EA scales pretty well up to hundreds of thousands of elements. (thanks to the database backend)

Geert

Ok, so this might be doable with the XLS-importer? I obtained it from your website but I did not see how it can also import relationships.

2
General Board / Re: Import of large model from an external source
« on: April 11, 2019, 10:56:47 pm »
I wouldn't try to go through xmi. That really isn't the most easy format to use.

There are a few options:

- Use the excel importer to import classes and attributes. (Excel scales pretty good and goes up to 1M of rows)  You might want to write additional code to import datatypes (and link them to the attributes) and relations.

- Write a custom import program that reads your source database and creates the corresponding model in EA.

I can't image it being more than a few days of work to get it all done.

If you want to hire me as qwerty suggested (thanks qwerty ;)) you can email me at geert@bellekens.com. But please take into account that I have a pretty full calendar already. Next available days at the moment are in July.

Geert

Thanks for these suggestions. This does not sound as a very easy job.

We are in fact investigating the use of EA for the maintenance of a complex model instead of the current text-based interface. The advantage of EA is its graphical representation of the data but getting the data in EA and creating useful diagrams is then a new challenge.

But is EA in itself capable of handling a model with say 200.000 elements and relations?

3
General Board / Import of large model from an external source
« on: April 11, 2019, 09:12:26 pm »
I want to import a very large class model, consisting of 100.000+ elements and relationships from a non-EA SQL database into Sparx EA. What is the best way to do this?
I know there is a VBA importer to import from an Excel spreadsheet (written by Geert Bellekens) but that is probably not scalable enough. My idea is that it should be possible to create an XML file that can be imported as XMI. Is this possible? And what exactly is the format I must use?
And what about the relationships? All elements have of course already a unique ID, how can I use that to create the right relationships in EA? EA will want to assign its own GUID of course and the relationships must contain the EA GIUD, not the original ID.

Any help or suggestions are highly appreciated!

4
I'm using EA v14.1.1427

When working in an ArchitMate Implementation and Migration diagram, I can't seem to get the quick link to show any of correct relationships between elements. For example, "Realizes" is missing between Work Packages and Deliverables, "Triggering" is missing between two different Plateaus. Oddly, I can make a Deliverable "realize" a Work Package, but not the other way around, which is completely backwards. None of the main relationships seem to work according to the ArchiMate 3.0 spec (http://pubs.opengroup.org/architecture/archimate3-doc/chap13.html#_Toc489946119).

In fact, if I try to create any of these links manually from the toolbox, it gives me an error saying "Invalid combination of source and target types." The only way I can get any correct links to work is by turning off "Strict Connector Syntax" for the entire model, which is a pretty crappy workaround.

Can it really be true that ArchiMate Implementation and Migration diagrams are completely broken in the latest version of EA? Is anyone else frustrated with all of the ArchiMate problems since v14 released? Seems like some very simple regression testing should have caught these issues before releasing.

Any help would be greatly appreciated.

Yes, it seems indeed that the implementation of Archimate in version 14 is very bad indeed. All seemed wel in version 13 but they seem to have messed it up completely since! Especially the quick link relationships are broken. Many valid relationships are missing and some are weirdly wrong (composition). This is a serious issue for anyone using Archimate. >:(

5
Bugs and Issues / Problems with Archimate in version 14
« on: April 10, 2019, 05:48:27 pm »
It seems that there are problems with the implementation of Archimate in EA version 14.
Several things do not seem to work as required, especially the connections when drawn from the "quick link" arrow next to an element:
- The access relation is not in the pulldown (e.g. when connecting a Component to a Data object)
- The Composition relationship is drawn as an Association
- and many more relationships from quick-link are missing or wrong

This all worked well in version 13

6
General Board / Re: Archimate elements not visually correct
« on: January 31, 2019, 12:29:16 am »
So now I copied (exported then imported) the offending elements (Archimate_BusinessProcess) to a clean project in its own .EA file in order to try to get them to behave properly (call the right shapescript). Then I open the properties of one of the elements not showing the right shape.
In the Profile pull-down I select the required profile: Archimate3
Then I see a list of element types below. However >:(  BusinessProcess is missing from the list!!! As are many other element types!!!
How can this be?
The same with the profiles Archimate and Archimate2, also many types missing among which BusinessProcess. Very strange!

Any idea?

Michiel

7
General Board / Re: Archimate elements not visually correct
« on: January 29, 2019, 11:26:49 pm »
The "select stereotype" dialog has a "profile" dropdown that shows the profile used by the stereotype.
When you select the correct Archimate profile you will see all archimate stereotypes.

You could also look in the t_xref table for it.

If you find a stereotype called Archimate_<something> in the stereotypes list in EA then you should delete it as it causes problems for you and every other user of this model. The stereotypes list should only contain "loose" stereotypes that are not defined in a profile of an MDG.

Geert
Allright, so where do I find the dialog that lets me delete stereotypes? And what is the scope of such an action, can I try it in a test-model first?

8
General Board / Re: Archimate elements not visually correct
« on: January 29, 2019, 08:43:45 pm »
When I create a new Archimate 3 BusinessProcess, two stereotypes are checked!
Archimate_BusinessProcess  and  Archimate3::Archimate_BusinessProcess

From which profile?
It sounds like you have the rogue stereotype problem.
Go into the stereotypes list and delete all stereotypes you find there that resemble one of these two.

Geert
Thanks for the help!
Where do I find the Profile I am using and the stereotype list? But your suggestion sounds dangerous.... I am sharing this model with a lot of other people an I am afraid an action like this might turn out disastrous....

I exported a very small package containing two elements. One original good looking element and one I messed with, changing its stereotype so it looks not correct. My idea is that in the XML I would be able to see what the problem with the second element is and I should be able to correct the XML code.... A logical idea, isntit? However, from the XML code I cannot see any clue as to why the first element should call the right shapescript and the second should not.... Very strange indeed! Is there some hidden information somewhere???

9
General Board / Re: Archimate elements not visually correct
« on: January 29, 2019, 01:39:47 am »
Thanks for the help... But so far it doesn't work. The correct shape script is apparently not called. Instead, it is getting worse... Now I have a rectangle with explicit <<stereotype>> and scope:: in text. Deselecting "show namespace" does not help. Is there a way to force a shape script upon an element?
No, shapescripts are always loaded through the stereotypes.

You may want to check if you don't have any "rogue" stereotypes hanging around in Configure | Reference Data | UML Types and make sure you have the correct MDG enabled.

What do you see when you select the [...] next to the stereotypes field?
It should only have one stereotype checked and it should show the correct version of archimate in the Profile dropdown.

Geert

When I create a new Archimate 3 BusinessProcess, two stereotypes are checked!
Archimate_BusinessProcess  and  Archimate3::Archimate_BusinessProcess

10
General Board / Re: Archimate elements not visually correct
« on: January 29, 2019, 12:08:42 am »
Thanks for all the reply's, but is there a way to fix this without replacing the element(s) concerned? How do I attach the right shape-script to an element?
Michiel,

The shapescript is linked to the (fully qualified) stereotype
So if you make sure your object has the correct stereotype from the correct MDG, and it has only one stereotype, then you should be fine.
Never ever type in a stereotype, instead always select it using the [...] button.

Also, make sure you only enable the MDG's you actually use. That reduces the risk of using the wrong stereotype.

Geert

Thanks for the help... this seems to go some way of a solution. I can indeed select a Profile such as Archimate, Archimate2 or Archimate3, but strangely enough, they do not show all element types! The element type that I need, BusinessProcess, is not in the list!!

11
General Board / Re: spam filtering in forum
« on: January 28, 2019, 07:56:56 pm »
What about adding a Captcha for every post? Or are these spam messages actually entered by humans?

12
General Board / Re: Archimate elements not visually correct
« on: January 28, 2019, 07:49:08 pm »
Thanks for all the reply's, but is there a way to fix this without replacing the element(s) concerned? How do I attach the right shape-script to an element?

13
General Board / spam filtering in forum
« on: January 22, 2019, 01:50:28 am »
The forum moderator should set the spam filters to be more strict! There seems to be a lot of garbage now!

14
General Board / Archimate elements not visually correct
« on: January 21, 2019, 10:26:35 pm »
I have a situation where an ArchiMate_BusinessProcess is shown as a yellow rounded rectangle but without the small arrow in the top right corner! Another element in the same diagram does also have ArchiMate_BusinessProcess as stereotype but does, correctly, show the small arrow.
How can this be, what determines the visual appearance of an element?

15
General Board / Automatically create aggregation relationships?
« on: October 08, 2018, 09:15:51 pm »
I have a situation here where there are many diagrams with nested elements without explicit relationships. The language used is Archimate and nesting has no meaning in Archimate. The meaning that is implicitly assumed by visual nesting comes closest to Aggregation. So in order to make the diagrams into meaningful Archimate diagrams, explicit aggregation relationships must be created wherever a hierarchy (nesting) exists. I suppose it should be possible to to this automatically, via a script. Has anyone attempted this?

Thanks!
Michiel

Pages: [1] 2 3 ... 7