Author Topic: Interface between EA and ARIS (Read 21360 times)

Sascha Zinflou · « **on:** October 28, 2009, 02:33:58 am »

I am creating an interface between ARIS and Enterprise Architect.
Focus is on using data from ARIS in EA, the other way round might be of interest in future.

I am quiet new to the tools, but have some experience in UML and other modeling languages and creating interfaces and extensions to modeling tools.

ARIS is a more or less business focussed modeling tool with its own proprietary notation (EEPC) and rather poor focus on requirements engineering and software development, which we have to use for process definition from the business side. Enterprise Architect is the tool we use on the IT side.

I have some work done on mapping the specific ARIS Notation to the standard notation used in Enterprise Architect, which both contains a general mapping and a mapping needed for our customized ARIS notation.

On the technical side, I started with using standard techniques to transform a given ARIS XML Export (which comes with its own DTD) to an XML file, that I will be able to import to Enterprise Architect. What I did not solve up to now is a strategy of synchronizing when content changes in both tools, but this seems to me as quiet solvable.

I have to reasons for my post: The first one is, that reading the Forum Automation Interface, Add-Ins and Tools, I learned that Developers on EA choose the automation interface for generating packages and models in EA and do not use the XML interface. I would appreciate any feedback, wether I should rethink my design decision to use direct XML-Transformations.

The second reason is to get a feedback wether the topic of creating such an interface is of interest for this community. If this is the case, I would post some detailed ideas that could be discussed.

Sascha

Makulik · « **Reply #1 on:** October 28, 2009, 04:13:42 am »

Hi Sascha,

Quote

I have to reasons for my post: The first one is, that reading the Forum Automation Interface, Add-Ins and Tools, I learned that Developers on EA choose the automation interface for generating packages and models in EA and do not use the XML interface. I would appreciate any feedback, wether I should rethink my design decision to use direct XML-Transformations.

You might find it out that it's quite hard to provide a direct transformation (e.g. using XSLT) from your ARIS XML export format, matching all the needs for a XMI format that can be correctly imported by EA. I think it'll be a lot easier to setup a model (e.g. in C#) for your stuff from ARIS, populate it from the exported XML and setup the corresponding elements using EA's AddIn/Automation interface.

HTH
Günther

Sascha Zinflou · « **Reply #2 on:** October 31, 2009, 01:33:40 am »

Thank you for your comment, proceeding the work on it, I have chosen to use automation for exactly the reason you mentioned. I wonder if the XMI-Format is anywhere used with different tools for more than trivial use cases.

Makulik · « **Reply #3 on:** October 31, 2009, 02:41:06 am »

Hi,

I have used it for straightforward creation of simple reports through XSL transformation (a compact Requirements Report in HTML with several informations that would be hard to show with one of the standard EA reports).

XMI lacks having a standard schema, besides the (less useful) basics IMHO. All the interesting stuff is inside the proprietary sections. So why struggling around with it when portability wouldn't be an advantage and the case tool gives better interfaces to use.

WBR
Günther

Sascha Zinflou · « **Reply #4 on:** November 19, 2009, 11:30:28 pm »

Hi,

first of all, as a feedback after the interface is implemented: I can strongly encourage everyone in the need to write a lot of data to the repository to use the automation interface.

Now, I have two new issues where I would like to discuss my ideas.

The first one concerns the concept of using diagram elements as a link. This is a nice concept as the name of an element, tagged values, etc are changed in all diagrams, if someone changes them in one. I have learned that I cannot use the link to an element in the same diagram.

Unfortunately the source data I use does not meet this constraint, so what I did is creating a new element for each instance and tagging them to refer to the same original identifier. This is more or less a workaround as in future poeple will have to modify the imported diagrams and I suppose that then they will miss the link feature.

What I thought as a solution is to merge multiple occurences of the same element in one single diagram to one element. (That is in fact what I would advise a modeler to do, if the diagrams were manually created). Are there alternative concepts or do you agree that this is the way this issue should be solved?

That leads me to my second question: layouting flow and swimlane-diagrams (what I will have to do when I merge elements from the original diagram). I am doing some basal layout from scratch, but I do not want to extend this to complex layout as I do not think that I will get good results in a reasonable time.

I saw that the automatic layout will not help me (as I am not dealing with structural diagrams). Is that true or is there a hint I did not see?
So what I am thinking to do is looking for a graph library that will do some layout tasks for me and itegrating it. I would appreciate any feedback or experiences you have ob this approach.

If the layout issue is interesting for other people, please let me know, I will then post my results.

Geert Bellekens · « **Reply #5 on:** November 20, 2009, 05:02:19 am »

Sacha,

For the first question, some of us are fighting an almost heroic fight to get Sparx to allow multiple representations of an element in one diagram.
Unfortunately I don't expect a solution any time soon.

I think the solution of merging the two elements into one is a good one, except when you are dealing with element that need to be in a certain swimlane.

If, in your source model, an element is drawn twice on a diagram, but in a different swimlane you'll have a problem when trying to convert that to EA.

Maybe using an instance for the second element might be a solution?

Good luck with all that.

Geert

Sascha Zinflou · « **Reply #6 on:** November 20, 2009, 09:17:08 am »

@Geert:
1. I appreciate very much your comment on the same object displayed in different lanes of one single model, because I will probably have to face this problem. I will post on this issue again, when I have understood the concept of instances.
2. If I can support the heroic struggle, just let me know ;-)

Thank you for you wishes
Sascha

zalbina · « **Reply #7 on:** January 05, 2021, 07:01:27 pm »

Hello Sascha,

Did you succussed to develop and transfer data from Aris to EA, please? I know it was 10 years ago but I'm facing this chalange today and would like to know if you have some recommendations or pieces of code which I can apply. Did you try to use xmi file in order to transfer the data?

Thanks a lot.

qwerty · « **Reply #8 on:** January 05, 2021, 08:04:54 pm »

He's no longer on board. So I guess you won't get an answer. I once wrote a transfer from ARIS to EA using Perl. It was not that difficult but took some days of hacking. And of course it were an expert tool (so you needed to know exactly how to do it and how to avoid pitfalls). But it worked. I might have it around somewhere but since it was made for a customer I can't make it public.

q.

zalbina · « **Reply #9 on:** January 05, 2021, 10:36:50 pm »

Thank you very much for you replay.

Do you have some general ideas? I've planned to extract data related to models/objects from Aris to xml files and write some AddIn for transforming this data into models/classes in EA. Am I on the right direction? I understood from this old post xmi is not an option, is it right?

Thanks a lot.

Geert Bellekens · « **Reply #10 on:** January 05, 2021, 10:45:07 pm »

Yeah, sounds like a solid plan.
You don't need an add-in to simply import the files. A standalone application will do just fine.

If Aris has a standard XMI export, that might already do the bulk of the work. If not, you better write your own xml file with the contents you need.

Geert

qwerty · « **Reply #11 on:** January 05, 2021, 10:50:12 pm »

Well, XMI is just bloated. You don't want to mess with that (I'm doing that for profiles and it's a PITA). It's much easier to parse the ARIS export (honestly I don't remember which format I took since it's 10 years ago I did it) and then create the single elements with EA's API. It was pretty much straight forward since there are not that many ARIS base elements. I created a profile to represent them (IIRC most of them ended up in sorts of activity elements). Creating connectors was a bit more clumsy. All I can say: it's doable if you don't go for pretty and maintainable all purpose code. Just for a once import it will take you a week or so.

q.

zalbina · « **Reply #12 on:** January 06, 2021, 12:11:53 am »

Many thanks again!!!!!! I'll try to manage it

BR

Sunshine · « **Reply #13 on:** January 06, 2021, 06:14:37 am »

I wrote something to transfer archimate models in Aris to Sparx EA about 6 years ago. If I recall correctly I think I did it in C# using the APIs of Aris and Sparx EA. Whilst I managed to get the packages, elements and links transferred I ran out of time before I could crack the transfer of the diagrams. I'll see if I can dig up the code

zalbina · « **Reply #14 on:** January 06, 2021, 10:15:53 pm »

I'll appreciate it very much!
Thanks a lot.

Sparx Systems Forum

News: