Change the starting position for free attribute placement?

Hi Simon,

I'm not certainly if we are doing right, but in similar examples we use to move this attribute manualy.

You may build a script to do it automatically also. If it's really important for you, I could get you in contact to some ARIS developer.

See ya,

Andre Sales

Hello Simon,

Unless there is a specific reason to use connection attributes, there is an advantage in using the object attributes instead and place these under the object.

The placed attribute would then have a fixed position in relation to the object even when you move the object around in the model. You can define a number of attributes for the Technical term  object that reflect the status it can have - "Initial","Reviewed","Final",...and place them under the objects in the model.

 Maybe this will help?

Regards   / Harry R

Hi,

I'm a colleague of Simon. Thanks for your answers.

However, there is a specific reason for us trying to use connection attributes. What we want to achieve is to have single Technical Term objects (e.g. there is one single Technical Term called "List of Material"), but have an attribute that can be different - e.g. intial, reviewed, released etc.

If we use a Technical Term attribute for the life cycle information, the value (initial etc) will be copied with the object when occurrence-copied. If we then change the attribute on the Technical Term object  from initial to reviewed it will change in all models where that Technical Term object has been used. This is good for some attributes, but not when you try to have one single Technical Term object but change the attribute "Life Cycle State" as that Technical Term is passed along the value chain. To clarify, we use the Technical Term object to model Deliverables.

If we store the Life Cycle State attribute on the Relationship between the Technical Term and the Function that uses/works with the Technical Term, we can have one single Technical Term object (e.g. List of Materials) but different attributes showing Life Cycle State, on the Relationships where that Technical Term is used.

If there is a way to "disconnect" a Technical Term attribute from being copied when the Technical Term object is copied, that could be a solution though - does anybody know if that is possible?

Hi Simon,

I see the challenge here. You want to re-use the technical terms objects via occurrence copies and still be able to display them in the model(s) using different life cycle states.

Since the number of stages in the life cycle is realtively small (6), I would still use the technical term object attributes for this task, defining in this case six user defined attributes ("User attribute Values"):

 Lifecycle state - Initial,  Lifecycle state - Reviewed, Lifecycle state - Draft, Lifecycle state - Final, Lifecycle state - Stage 1, Lifecycle state - Stage 2

The values for each attribute can then be set to "Draft", "Initial",...and so on, with only one value per attribute. These 6 attributes can be saved in an attribute group called "Lifecycle state".

The available atributes for the technical terms object would look like this:

Now the technical terms objects in the model can be shown together with the attribute you wish to place in the given situation.

The result for the given example model:

 How would this work for you?

Greetings from Denmark   / Harry R

Hi Harry, 

smart solution, thank you for that! 

It can definately work.

The only thing I can think of that might be a problem with this approach is that in some exports and likely in the Portal (ARIS Business Publisher), in the Details view, all the assigned attributes for an object are shown. This means all of the different Lifecycle State attributes specified to be used for the Technical Term (in your example all 6 of them), and not necessarily the specific Lifecycle State attribute relevant in that model, for the Technical Term object selected.

We also have quite different Lifecycle definitions for different kinds of Deliverables, e.g. As-Bid, As-Sold etc for one type. So the idea with the Lifecycle State attribute was to have it as free-text in order to easily have all the different definitions available. On the other hand, for process designers it might be good to have a pre-defined list to choose from, even if that means the list of attributes gets quite long.

But graphically, you solution would actually work well as I see in your examples, so that's good! 

Best Regards

Magnus