New specialization plugin

Started by Hervé, June 30, 2017, 20:18:01 PM

Previous topic - Next topic

Hervé

My apologies, I had forgotten to increase the release number inside the jar file.

I just sent an update to GitHub.

jmariani


Phil Beauvoir

Hervé,

have you considered adding support for the new multi-selection Property Sections?

This allows the Property Sections to edit more than one item. The code was changed here:

https://github.com/archimatetool/archi/commit/348a8c3b81155dbea57666d437c2602adde18908

I don't think it would be too hard to change, but ask if you have any questions.

Phil
If you value and use Archi please consider making a donation! https://www.archimatetool.com/donate

Hervé

Hi Phil,

Thanks for pointing me out this change. I definitely will.

Best regards
Hervé

Chris Usher

May 14, 2018, 09:53:43 AM #49 Last Edit: May 14, 2018, 09:55:30 AM by Chris Usher
Hi Hervé,

I have a suggestion for default labels to apply to a view.  I have scanned the forum and the repository files, I don't believe the plugin can do this yet.

Idea A:
A view could have one or more properties, such as "label_ApplicationComponent", which act as the default label for that type of element.  This could be enabled in the view's preferences Replace labels in this view would have four options: yes|no|use model's configuration|use view defaults first, where use view defaults first acts like the yes option but inherits a global "label" property from the view and any "label_ElementType" property as defaults for that view.

This would make label format specific to a view so that each view could display labels in alternative formats depending on the intended audience for that view.  For example, an infrastructure engineer/architect may wish to read all properties for nodes in one view whereas an alternate view for 2nd line support may wish to show only node names and OS.

Idea B:
A view could have one or more properties, such as "label_Format1", "label_FormatXYZ".  Each element may have a property "label_inherit" which specifies the parent view (or model) label property from which to inherit its format, e.g. "label_inhert=label_Format1".  That would achieve much the same goal as Idea A and could still be overridden with a "label" property for specific elements within a view.  This may be simpler to use and possibly more flexible as any element could inherit from the same format rather than one based on its type.

Different views could specify unique label formats that would be inherited by the elements shown, therefore changing format of all elements in a view with just one property field.

I hope my proposal makes sense and is not too complex, because it would provide great flexibility.  Thanks for a great plugin!

Chris

Hervé

Hi Chris,

Thanks a lot for your suggestions.

You are right, one weakness of my plugin is that the label and icon are stored as properties, thus at the element / relationship level (and not at the graphical component level).

I did it this way as it did not require any change in the archimate file structure, so a model updated using my specialization plugin can continue to be opened in an Archi instance that does not have got my specialization plugin.

Unfortunately, this implies that all views share the same label / icon properties and the only parameter available in the views is an on/off switch.

Your suggestion is very interesting as it will allow to have different labels / icons per view.

It shouldn't be very complicated to implement. I'll have a think and come back to you asap.

Best regards
Hervé

geoffrey

May 23, 2018, 16:03:56 PM #51 Last Edit: May 23, 2018, 16:05:30 PM by geoffrey
Hi Hervé

The suggestions made by Chris would be a possible help for me as well. For now I sometimes use the following naming scheme for an element based on the pattern described by Gerben in his book:

[Some grouping concept] Element Name (Archimate Concept Abbreviation)

For example

[ACME] Manage Customers (Bus. Prcs.)

To represent a business process Manage Customers for organization Acme Inc.

Use Chris' idea A, I could use a variable ${model:enterprise_abbreviation} on the model level indicating for which enterprise the model is constructed, "ACME" and on the specific Manage Customers business process a variable ${property:type_abbreviation} to indicate the "(Bus. Prcs.)" part.

On a specific view I could then add a property "label_BusinessProcess" with a value

Quote"${model:enterprise_abbreviation} ${name} ${property:type_abbreviation}"

to represent the entire pattern.

At the moment the pattern "[ACME] Manage Customers (Bus. Prcs.)" is entirely stored in the element's name and I have to extract the real name when exporting it to a database or something else.

When reading through the latest updates to this wonderful plugin, I came across the following 2 questions:

       
  • Does the ${sum:xxx} variable only take into account the elements in a specific view or is it possible to make a sum across all elements in a model?
  • When would you use the ${model:purpose} variable?
Are you able to assist me with these?

Thank you as always.

Best regards,

Hervé

Hi,

To be honnest, I concentrate on the database plugin at the moment to release a version that is mode collaborative (i.e. the export process will sync the model with the database) so I haven't worked much on the specialization plugin these last days ...

Chris idea B is easier for me to implement as it just requires to update the algorithm which calculates the label ... So unfortunately, it won't be very soon but it is on my todo list.



Regarding your others questions:
QuoteDoes the ${sum:xxx} variable only take into account the elements in a specific view or is it possible to make a sum across all elements in a model?
It takes in account the component that holds this variable, plus recursively all the components that are contained in it (if it is a container of course).
To get the sum of all the components inside a view: ${view:sum:xxx} and to get the sum of all components in the model: ${model:sum:xxxx}

QuoteWhen would you use the ${model:purpose} variable?
To be honest, I do not think this variable is very useful and do not see any use case where it can be of any use. I created it for completeness only.

Best regards
Hervé

geoffrey

May 23, 2018, 20:01:45 PM #53 Last Edit: May 23, 2018, 20:03:44 PM by geoffrey
Hi Hervé

No worries. Just wanted to point out that it could be usefull for other cases as well.

Your work on the database plugin supports now the possibility for Neo4j to contain a relationship to another relationship, which we discussed in the past, so that might come handy as well :)

I haven't been modelling a lot lately, but recently came across a project where we potentially could use your specialization plugin to represent a User Story Map, so I started thinkering again in Archi.

Happy coding.

Hervé

May 23, 2018, 20:46:25 PM #54 Last Edit: May 23, 2018, 20:51:51 PM by Hervé
Happy to hear you're coming back to Archi. So welcome back  ;)

I'm rushing to deliver my new database version as it was planned for the end of last year (you see, I'm VERY late).

Amine, a fellow developer is getting on board and will help me with my plugins. Our first common jobs will be to reorganize my code and automate unit tests to reduce the number of bugs and make my plugins more reliable.

Of course, I will not stop to deliver new functionalities, but the two priorities described before are slowing them down.

In addition, the coming 4.3 release of Archi will provide new interesting functionalities on its own.

So please do not hesitate to continue to make new functionality requests or to raise issues  ;D

Best regards
Hervé

Hervé

Dear all,

I'm please to announce the version 1.0.7 of my specialization plugin (https://github.com/archi-contribs/specialization-plugin).

This version introduces a new drill down functionality: i.e. it is now possible to open a specific view with a double click on any element (and not only on view links).

As usual, to install the plugin, one just need to copy the JAR file to Archi's plugin folder. If the plugin is already install, one may update it using the "check for update" button on the preference page.

Please do not hesitate to open new cases on GitHub should you discover issues.

Best regards
Hervé

jmariani


viraght

I installed Archi plus the Specialization Plugin on a MacBook Pro in macOS. Archi works fine and I have the Preferences window for Specialization Plugin too. I want to change the labels in my views. Unfortunately this does not works: I see the original Name not the value defined in label property. I do not know what can be the problem because earlier I used the same solution on a Windows PC without any problem. I attached some screenshots and a log file. Please help me to find the reason why the labels are not changed! Thanks, Tamas Viragh

viraght

The screenshots I mentioned in the previous post are now attached here.

Hervé

Hi,

Unfortunately, I do not have any Mac computer so cannot reproduce your environment.

What I'm thinking of is that you filled in the label property manually in the properties tab. If you do it this way, the view is not aware of the label property creation or update.

what you could do is to force the view to refresh itself. There are two options:
1- you close the view and reopen it
2- you select the "replace label" tab and update the label in this tab (like add a space and remove it just after).

If this does not solve your issue, I suggest you follow the following plan:
1- close all your models in Archi
2- close Archi
3- delete the plugin log file
4- restart Archi (Archi will not load any model during startup)
5- go to the preferences and switch  the plugin in trace mode
6- create an empty model
    6a- create your element in the default view
    6b- create all your required properties
    6c- set the label using the "replace label" tab
7- close Archi
8- send me the complete log file

Hope this helps

Best regards
Hervé