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

Pages: 1 2 3 [4]
46
Bugs and Issues / Re: UPDM / DoDAF SV-6
« on: November 12, 2014, 04:22:24 pm »
The problem with this query is that it only checks for the first occurrence of a ea_guid in ABSTRACTION.Description. If there are more than one conveyed item these are all put in the same field (Description). You need to modify the search as follows:

...
AND FLOW.End_Object_ID=CONSUMER.Object_ID
AND XCONVEYED.Client in (
left(XABSTRACTION.Description,38),
mid(XABSTRACTION.Description,40,38),
mid(XABSTRACTION.Description,79,38),
mid(XABSTRACTION.Description,118,38))
AND XABSTRACTION.Client=CONNECTOR.ea_guid
...

The above example will be able to find at most 4 conveyed items on each connector.

/Hans

47
Bugs and Issues / Re: Connectors broken after Import as Model Branch
« on: July 30, 2009, 09:12:20 pm »
In my initial post I stated the following:

Quote
However, while doing this maneuver all connectors to the package A are removed. This is in contrast to XMI file import as described above, where connectors are preserved.

Questions

2. Why are all connectors broken when doing "Import as Model Branch..." after turning off Version Control?

I have found that this conclusion was not correct. It seems that relations is indeed preserved also when "Import as Model Branch" is used. This was actually a relief since "Import as Model Branch" should be equivalent to "Get Package..." (root package) followed by a "Get All Latest".

However, the two suggestions in the above post should still be considered by Sparx, to make it easier for people that wish to branch their models into frozen releases or for other purposes.

48
Bugs and Issues / Re: Connectors broken after Import as Model Branch
« on: July 30, 2009, 04:55:14 pm »
After some hours of additional trials I have found a workaround that actually seems to work all the way.

1. A model branch of package A is initially exported from model A. The model is version controlled and stored in Subversion under trunk.

2. A formal release of A is created by copying a selected set of XMI files and the EAB-file to the subversion release directory (using Subversion, not EA).

3. The EAB file and all the XMI files are subsequently edited (in a text editor) to reflect their new location within subversion (Search & Replace).

4. The formal release of package A is imported as a model branch into a new model. The model will then contain version controlled packages that are stored in the subversion release directory. People working in model B can now work with the formal (read-only) release of package A, while other people are continuing their work on package A in model A.

5. An updated release of package A (from model A) is subsequently made available by repeating steps 2 and 3.

6. People working with model B would now want to right-click on the package A and choose "Import as Model Branch..." again, but this is not possible. Instead, the following procedure seems to work:

6a. Temporarily turn off Version Control on the top most package. This can be done by right clicking on the package and choose "Package Contol"->"Configure..." from the context menu. Un-tick the Control Package tick box.
6b. Right click on the same package again and choose "Package Contol"->"Get Package...". Choose to get the updated version of the correct package XMI-file.
6c. Finally, right click on the same package again and choose "Package Contol"->"Get All Latest" to update the child packages as well.

The connections are preserved!  ;D

I think that this shows that EA is actually capable of version control branching. However, Sparks need to make some minor modification to facilitate this procedure even further. Suggestions:

1. EA need to implement something similar to the command "svn relocate" to replace step 3.

2. Steps 6a, 6b and 6c, should not be required. Instead a warning could be displayed after choosing "Import as Model Branch" where the user must confirm that a version controlled package is to be replaced by a new one. Minor change.

/Hans

49
Bugs and Issues / Connectors broken after Import as Model Branch
« on: July 30, 2009, 12:18:28 am »
We are working with very large scale models. The models will consist of hundreds of version controlled packages, some of which are used as framework components (read-only) in multiple models.

Suppose that a general component COMP_A is modeled as a package in model MOD_A and later exported as RELEASE 1.0 (using the XMI import/export). Subsequently, the XMI-file can be imported as a package COMP_A into another model MOD_B (or several other models that will make use of the general component). Later when COMP_A is updated in MOD_A and released as RELEASE 1.1 it is easy to replace the package in MOD_B with the new release by right-clicking on the package that is to be updated and importing the updated XMI file. Any connectors made to elements within COMP_A in MOD_B are preserved. (Obviously connectors from elements in COMP_A are not preserved, and general packages should therefore be made read-only using the Lock-feature, or by using mechanisms available in the used VCS.)

In an environment where 50 developers is contributing to the model and where components need to be configured into multiple platforms, for multiple customers, version control is required. The complex hierarchy of controlled packages is packaged and released using EA's model branch (EAB-file). Also version control branching will be required which is currently not very well supported in EA. We are well aware of the specific replacements that have to be made to the XMI files in order to support branching and handling of version controlled releases that are not residing in main trunk. These shortcomings could be accepted for now, if only the procedure outlined below would work.

Now, to the specific problem:

1. A model branch of package A is initially exported from model A. The model is version controlled and stored in Subversion under trunk.
2. A formal release of A is required and the files (EAB and XMI files) are therefore copied to the subversion release directory (using SVN, not EA).
3. The EAB file and all the XMI files are subsequently edited to reflect their new location within subversion.
4. A model B is subsequently created and a package A is created by importing the model branch. The model will then contain version controlled packages that are stored in the subversion release directory. People working in model B can now work with the initial release of A.
5. An updated release of package A (from model A) is subsequently made available by repeating steps 2 and 3.
6. People working with model B would now want to right-click on the package A and choose "Import as Model Branch..." again, but this is not possible. One way to overcome this problem is to temporarily turn off Version Control on every controlled package within the branch, and then do the "Import as Model Branch..." However, while doing this maneuver all connectors to the package A are removed. This is in contrast to XMI file import as described above, where connectors are preserved.

Questions

1. Why is it not possible to redo the "Import as Model Branch..." without turning off Version Control?
2. Why are all connectors broken when doing "Import as Model Branch..." after turning off Version Control?
3. When can we expect support for version control branching in EA?

/Hans

50
Automation Interface, Add-Ins and Tools / Re: API to get Sparx EA version
« on: February 09, 2015, 08:45:19 pm »
I believe this issue is even more complicated. I have two different installations of EA version 1112, on two separate computers both running Windows 7. The Windows region settings are identical on both computers. The dates stored in t_objectproperties table is 26/02/2020 on one of my computers, and 2020-02-26 on the other.

/Hans

51
I have sucessfully used the SQL query below in a fragment that extracts every requirements that is satisfied by the current element. The fragment is used in an RTF template for a system specification. I use it to extract requirements that are satisfied by a specific activity (function).

Code: [Select]
SELECT SourceObject.Name AS ObjectName, RequirementTable.Name AS RequirementName, t_connector.Connector_Type, t_connector.Stereotype AS ConnectorStereotype, RequirementTable.Note AS RequirementNote
FROM t_object AS SourceObject, t_object AS RequirementTable, t_connector
WHERE t_connector.Start_Object_ID = SourceObject.Object_ID
AND t_connector.End_Object_ID = RequirementTable.Object_ID
AND t_connector.Stereotype = "satisfy"
AND SourceObject.Object_ID = #OBJECTID#

The RTF fragment looks like this:

custom >
<<{ConnectorStereotype}>>      {RequirementName}
{RequirementNote}
< custom

52
Is the MDG Technology for SysML still supported? In the SysML Technology menu there is a menu Item called View Allocations. When the item is chosen no allocations are displayed. There are plenty of allocations in the model.

53
I was just about to create an OOSEM-profile that extends the SysML language. (OOSEM is a MBSE method promoted by INCOSE.) Without access to the UML4SysML metamodel this can't be done? Very disappointing! I thing that the profile mechanism of UML/SysML is very important and that the means to extend the SysML language according to SysML specification should be provided by Sparx.

Pages: 1 2 3 [4]