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

Pages: [1] 2 3 ... 5
Hi Simon,

Tried this path.  Addition of the Documentation exporter information does result in the UUIDs being brought in to EA but the stereotypes and tagged values are not. The Documentation exporter information is not enough; the EA add-ins must also be included within the xmi file.  Currently, I am generating and using XMI 2.1 / UML 2.3 files without EA extensions.  Importing this type of xmi file works with the exception of the UUID is not imported.

It has been indicated by Sparx that the formats in the publish xmi diaglog are not intended for round trip EA to EA and will lose information.  This means that the full xmi 1.1 or xmi 2.1 (with EA extensions) would need to be used.  This is where the problem lies since these are not documented (as far as I know).

Consider the following example xmi 2.1 file. With the Documentation exporter information, the tagged values and stereotypes will not be imported properly.  Without the Documentation exporter information, the UUID will not be imported.

<?xml version="1.0" encoding="windows-1252"?>
  xmlns:thecustomprofile="" xmi:version="2.1">
  <xmi:Documentation exporter="Enterprise Architect" exporterVersion="6.5"/>
  <uml:Model xmi:type="uml:Model" name="EA_Model">
    <packagedElement xmi:type="uml:Package" xmi:id="EAPK_98135048_54de_98e3_41e1_66ccb1ecadc2" name="ARRoot">
      <packagedElement xmi:type="uml:Package" xmi:id="EAPK_6c39594c_de42_94ce_5590_ddb1fc9c5cfa" name="ABC">
        <packagedElement xmi:type="uml:Package" xmi:id="EAPK_7f79ac5f_0270_8793_c3a6_87ccac55ace4" name="Modules">
          <packagedElement xmi:type="uml:Package" xmi:id="EAPK_4746d95a_9e91_b0c0_545b_95c024876e9c" name="Example">
            <packagedElement xmi:type="uml:Package" xmi:id="EAPK_5aa610fa_e7e8_9c18_091a_e7a6a01f7036" name="BswModuleEntrys">
              <nestedClassifier xmi:type="uml:Class" xmi:id="EAID_3ff4807c_be4f_9354_3544_d21ef997a6cf" name="Example_MainFunction"/>
        <packagedElement xmi:type="uml:Package" xmi:id="EAPK_d0b31f64_3f9a_8366_277f_08225279a048" name="Interfaces">
          <packagedElement xmi:type="uml:Package" xmi:id="EAPK_c312de93_13af_92c9_27ec_53e2c6548df7" name="Example">
            <packagedElement xmi:type="uml:Interface" xmi:id="EAID_103d96e0_9bff_9e23_1133_b091323bd824" name="DrStatDrv_B_Actl"/></packagedElement>
    <profileApplication xmi:type="uml:ProfileApplication" xmi:id="profileap_E27C4BAF-C">
      <appliedProfile xmi:type="uml:Profile" href=""/>
    <profileApplication xmi:type="uml:ProfileApplication" xmi:id="profileap_81D8F36A-0">
      <appliedProfile xmi:type="uml:Profile" href=""/>
   <profileApplication xmi:type="uml:ProfileApplication" xmi:id="profileap_61765CEA-5">
      <appliedProfile xmi:type="uml:Profile" href=""/>
  <PackageView:arPkg base_Package="EAPK_6c39594c_de42_94ce_5590_ddb1fc9c5cfa"/>
  <PackageView:arPkg base_Package="EAPK_7f79ac5f_0270_8793_c3a6_87ccac55ace4"/>
  <PackageView:arPkg base_Package="EAPK_4746d95a_9e91_b0c0_545b_95c024876e9c"/>
  <PackageView:arPkg base_Package="EAPK_5aa610fa_e7e8_9c18_091a_e7a6a01f7036"/>
  <BsmdView:bswmEntry base_Class="EAID_3ff4807c_be4f_9354_3544_d21ef997a6cf" serviceId="1" isReentrant="false" isSyncronous="false" callType="SCHEDULED" execContext="TASK" swServImplPolicy="STANDARD"/>
  <PackageView:arPkg base_Package="EAPK_d0b31f64_3f9a_8366_277f_08225279a048"/>
  <PackageView:arPkg base_Package="EAPK_c312de93_13af_92c9_27ec_53e2c6548df7"/>
  <CompView:sndrRecIf base_Interface="EAID_103d96e0_9bff_9e23_1133_b091323bd824" isService="false"/>

Exporting as a full xmi 2.1 file will include an XMI:Extension node which is specific to EA and not documented. 

The creation of an EA compliant XMI file that includes EA extensions would be difficult without documentation.

Hi Simon,

The problem is a lack of documentation for the xmi 1.1 used by EA that would allow me to create EA compatible xmi files. Today, the best we could do was to create simple xmi (2.1) files without the EA extensions; xmi 2.1 is easier to work with from a tools side.

Does documentation exist at this time that would allow me to create EA compatible xmi files that support round-trip (can be imported as a baseline and compared)?

I am attempting to solve a round-trip problem. Sparx has indicated that the xmi file types under publish option (for export xmi) are not suitable for round-trip.

I am exporting XMI 2.1 (UML 2.3) from EA (with EA extensions turned off).  These files are transformed by an internally developed tool for use by an external  tool; the EA UUIDs are retained in these files.  The external tool may be used to modify, add, remove elements/attributes and save off the new files.

Using the internally developed tool, I can reverse this process and transform the files back into XMI 2.1 (UML 2.3) (without EA extensions). When this file is imported, the UUIDs are ignored and EA generates new ones.  If the UUIDs were stored as tagged values, I could import the xmi file into an empty EA project, run a script to manipulate the UUIDs in the model to match the tagged value.  I could then export the package as XMI 1.1 and compare as a baseline.  Differences could then be identified and merged as needed.

It would be a convoluted process but would work until something better could be developed; this would unfortunately require significant tool development.

Does anybody know if the EA UUIDs can be modified via scripting or API? I am aware that the table entries in the database could be manipulated or an XMI file could be exported, modified and re-imported but I would like to work directly on the model.

My Bad..

There is an option to control this behavior.

Notes (12.1)
•If the hyperlink appears as a Sub Activity, select the 'Tools | Options | Diagram | Behavior' menu option and deselect the 'Use Automatic SubActivities' checkbox

Notes (13.5)
•If the hyperlink appears as a Sub Activity, select the 'Start > Workspace > Preferences > Diagram > Behavior' option and deselect the 'Use Automatic SubActivities' checkbox

Attempting to drop an activity diagram (parent activity) onto an activity diagram to ease navigation between activity diagrams.  The diagram is displayed as an activity and not as a hyperlink which leads to confusion; looks like an out of place activity that should be removed or was not connected.

General Board / Re: How to visualize hyperlinks as hyperlinks?
« on: November 02, 2017, 01:30:47 am »
In 12.1, I get the same but if you choose Hyperlink, it is displayed as an activity when placed on an activity diagram.  As such, it appears as an out of place activity that is not connected to anything. 

General Board / How to visualize hyperlinks as hyperlinks?
« on: November 01, 2017, 11:55:30 pm »
I am creating activity diagrams with structured activities (simple composite).  I want these structured activities to still show as activities (no change here).  When I double click on these structured activities, the associated diagram is opened.

I would like to add hyperlinks to the parent activity diagram to move back and forth between diagrams.  When the parent activity diagram is dropped onto an activity diagram as a hyperlink, it is visualized as an activity.  Is there a way to have these hyperlinks visualized the same as hyperlinks (eg. symbol for a hyperlink shown on a class diagram).

Automation Interface, Add-Ins and Tools / Add-in Usage with Citrix
« on: October 06, 2017, 11:33:06 am »
Is there a way to use locally developed add-ins with EA accessed via Citrix?  The Citrix server host many different databases for different products / projects so the add-in should only be accessible to myself and others that are working on the same project.  When I access the models through the thick client, my add-in is available but the performance is slow because of the location of the database.  Accessing through Citrix, I have good performance but my add-in not available.

Automation Interface, Add-Ins and Tools / Invoking script from Add-In?
« on: August 07, 2017, 11:11:56 pm »
Is it possibly to invoke a user script from an Add-In?  I would like to add buttons to the user control for my add-in and have those buttons invoke scripts stored in the model.  Is this possible?

Had a feeling this was the case.  Thanks for the feedback.

Currently, when a new element is added through the New Element button on the Project Browser, EA remembers the last selected toolset and type.  Is there a way for add-ins to manipulate this information?

Feedback from Sparx:

Thank you for your enquiry.

As you have observed, unfortunately there is no built-in functionality in the MDG DOORS add-in to allow import of a specific baseline version at this time. We have noted this as a feature request for consideration in the future, but there are no current plans to implement this feature.

Suggestions and Requests / DOORS Add-In Improvements
« on: June 14, 2017, 09:02:21 pm »
1) Need the ability to import a specific baseline of a DOORS module.  These baselines are created a formal released versions of requirements. New requirements could be added or requirements could be modified/removed at the time that requirements are being imported but the EA model should only contain the specific (baselined) requirements that were planned.

2) Need the ability to define (load) profiles for DOORS import that can be applied automatically. Process of configuring the mapping each time is inconvenient and could be inconsistent.  After disconnecting from DOORS, the connection string should be retained (and potentially re-used when reconnecting).

3) Capture baseline version (and path) of the DOORS module being imported as a tagged value on the import package in EA.  This aids in traceability between EA and the requirements in DOORS.

It appears that importation of requirements from DOORS always imports the latest requirements.  The potential exists that requirements may change between when a baseline is created (and released) and when the requirements are imported into EA. This potential increased as the time between baselining of requirements and importing of requirements increases.

Is there a mechanism or planned mechanism that allows importing a specific baseline version of a DOORS module?

Pages: [1] 2 3 ... 5