Archi Forum

Hi everyone,

I've been using Archi for a while and recently felt the need to add some more expressiveness to my views. Having used Bizzdesign Enterprise Studio before, I decided to try and write a plug-in to apply some colors. I've attached some examples of my initial efforts below.

Currently the plug-in does the following:

• Gather input from the user via a wizard
• Compare the contents of two views
• Codify the contents of a single view based the value of a given property (three colors, numeric values only)
• Apply colors to the view(s)
• Add a very basic legend
• Reset the colors and remove the legend

Before I continue working on more complex functions, I would love to hear your opinions. Do you see added value in coloring views? Do you know of anyone who has tried developing something similar? I searched the forums and found nothing. I would also love to hear any suggestions you might have for improvements!

All the best,

Thijs

---

Hi Thijs,

welcome to the Archi forum and thank-you for sharing your plug-in idea. It's an interesting idea and certainly one that could be used for presenting views in a different way. Can you elaborate on what information is gathered from the user in the first stage?

(BTW - these forums do tend to be a bit quiet, so don't be surprised if there are only a couple of responses)

Phil

I think this feature should be valuble. Some sort of "filter-view" there you can select witch attribute to select color on, i.e a "status" attribute that is used for more than just coloring...
Normal View, and a copy view where you filter on attribute as show/hide or set a color on value

Hi all,

Thank you both for the encouraging remarks! Attached is an example that shows in more detail the process of adding colors to a view. Phil, this should also show you what information is currently gathered from the user. Steen, I think our approach is somewhat aligned, but I would love to hear your thoughts.

I am currently still busy improving the coloring functionality. Particularly, I would like to not simply use the default colors to reset views, but actually retain custom colors a user may have applied too. For example, if a user colored a particular business process green (instead of the default yellow), I want that business process to show up green again after the colors have been reset.

Do you have any suggestions on how to approach this? I am thinking of using the preferences mechanism to store the values temporarily, restoring the original colors before a model is saved or the application is closed. Let me know what you think!

Best regards,
Thijs

Hi all,

I solved the problem of retaining user-applied colors and added some more functionality too.

Firstly, I added the option to compare plateaus. The user selects two plateaus, as well as a view on which to apply colors. Concepts are then color coded based on whether they are in the one, the other, or both plateaus. I feel like this is particularly useful when working on e.g. an impact analysis. What do you think?

Secondly, I added a function to automatically reset views to their original colors before the model is saved. I believe the colors should be a temporary 'layer' over the original views. Archimate relies on colors to easily distinguish between concepts of different layers, and the use of user-applied colors outside of color views should still be an option. Moreover, color views can be easily re-applied.

However, the implementation of my solution feels like a bit of a hack. I would have liked to override the behavior of the save function (as defined by the com.archimatetool.editor.actions.SaveAction class), but was could not figure out how to do this without changing original code. Instead, I have my plugin register a property change listener with the Model Manager. This listener triggers whenever a 'model saved event' is fired. I then simply reset the views to their original colors and save the model again. Does anyone have a suggestion for a cleaner way to approach this?

Looking forward to hearing your thoughts.

Best regards,
Thijs

Quote from: tgfranck on June 12, 2017, 08:12:27 AM
Instead, I have my plugin register a property change listener with the Model Manager. This listener triggers whenever a 'model saved event' is fired. I then simply reset the views to their original colors and save the model again. Does anyone have a suggestion for a cleaner way to approach this?

The listener approach is correct, but not sure that double saving is a good idea. Perhaps you're coming at it from the wrong way. Have you published your code?

Hi Phil,

I cannot share all the code with you yet. However below is the code that registers the listener. The save operation fires another event, so the applied variable is there to prevent the listener from becoming stuck in an infinite loop. Applied always becomes true again (eventually).


public class StartPlugin implements IStartup {

@Override
public void earlyStartup() {
IEditorModelManager.INSTANCE.addPropertyChangeListener(new PropertyChangeListener(){

boolean applied = true;

@Override
public void propertyChange(PropertyChangeEvent propertychangeevent) {
applied = !applied;
if(!applied && propertychangeevent.getPropertyName().equals(IEditorModelManager.PROPERTY_MODEL_SAVED)){
IArchimateModel model = (IArchimateModel) propertychangeevent.getNewValue();
try {
ColorView.resetModelViews(model);
IEditorModelManager.INSTANCE.saveModel(model);
} catch (IOException e) {
e.printStackTrace();
}
}
}

});

}

}


I mean the general approach and workflow. Whether it could be achieved by some other means.

I'm sorry, I misunderstood your question.

At the essence, the workflow is about codifying concepts (in a view) using colors. I chose to do so by changing the fill colors of the view components. That seemed like a very straight forward way to achieve my goal.

However, since I do not want to persist the color views, I need some way to return the views to their original state before saving them. If I do nothing, the altered colors will be stored along with the model. So long as the editor is not closed, it would still be possible to restore the original colors by resetting the colors and saving the model again. If the editor is closed without resetting and saving, the original colors would be lost.

Option 1: Find a way to reset the views before saving. This is what I have attempted. However, I could only find a trigger after saving. This is why I decided to go with the current approach.

Option 2: Find a way to color the views that does not affect the model. If the state of the model is not affected, the problems with saving the model could be avoided. I have not seen a way how I could do this, but maybe you have some suggestions?

Hi,

the basic idea behind the concept of color views as we use them is that it allows us to do some basic analytics on the models: explicate differences and commonalities between views, plateaus etc. The colors are used by the modeller to highlight certain aspects of his/her model. We do not want to overwrite these model specific settings permanently, but for the purpose of an analysis want to change the colors to highlight certain aspects. To avoid that we are "accidentally" overwrite the user color settings, we are looking for a smart way to make sure that we switch off the color view and reset the original colors of concepts and relations before saving the file again.

br
Andreas

OK, I have a better understanding.

It seems really that you need another way of looking at the view. Something akin to "Apply Color Filter"? This means that your Option 2 is the preferred approach.

I'm not clear about this - are you generating another View altogether with the new colors? Or changing the View in question?

Phil

Hi,

we are changing the colors in an existing view and are not changing anything in the view besides the color.
We do not want to create new views for every coloring. The colors are just temporary as a result of an analysis and will not be persisted.

Do you have an idea on how to add an additional data structure to maintain the analysis colors per view for all views in an elegant way? We are still learning on how to use/extend the data structures in the Archi tool.

Thanks in advance.

best regards
Andreas

If you change the colors in the model code then, yes, you have all sorts of problems. What you need is additional presentation code that applies the colors to the View. Unfortunately, Archi doesn't have this kind of extension point so I think anything is going to be a hack. Even if you did store the colors in the <metadata> tags of an IArchimateModel class you still need to hack the code to show the colors. Other than presenting it in a new type of diagram View I can't think of another way to do it elegantly.

Hi Phil,

Thank you for the feedback. As Andreas has mentioned, we would prefer not to create new views/duplicate existing ones. Your suggestion of applying some sort of filter sounds interesting and I think it is worth looking into. The closest thing to a 'filter' I have seen in Archi is the way in which viewpoints are handled. The color (or transparency?) of the view components that are outside of the viewpoint change and the borders are dashed rather than solid.

To figure out whether and how I could tie into this, I would like to understand how viewpoints are applied to views. I have found the viewpoint definitions, the function that fires an event whenever a viewpoint is changed for a view, and the function that filters which view components belong to a particular viewpoint. I have not yet found the function that applies the gray tint/transparency and dashed borders to view components that are outside of the viewpont. Could you maybe point me in the right direction?

Thijs

Hi Thijs,

if you do this then you'll have to hack the core Archi code, and your plugin will no longer be standalone.

com.archimatetool.editor.diagram.editparts.AbstractArchimateElementEditPart:

    protected void refreshFigure() {
        // Set Enabled according to current Viewpoint
        if(Preferences.STORE.getBoolean(IPreferenceConstants.VIEWPOINTS_GHOST_DIAGRAM_ELEMENTS)) {
            getFigure().setEnabled(ViewpointManager.INSTANCE.isAllowedDiagramModelComponent(getModel()));
        }
        else {
            getFigure().setEnabled(true);
        }

        getFigure().refreshVisuals();
    }


Hi Phil,

My hope was that you were using some sort of 'color overlay' to change the appearance of the view components. Although looking at your code, it seems that the appearance is managed by eclipse instead. Is this indeed the case?

I have also started to create a nicer legend. The current approach of using a Note object is rather limited for several reasons. I would like to create a legend that uses graphics (e.g. a colored box) to reference a particular color, alongside some text explaining the meaning. Similar to the legend e.g. in Excel.

As I understand it, the right approach is to extend the Ecore model (from my plugin) and register a new UI provider with the Archi UI provider factory class. The UI provider supplies an EditPart, which in turn should supply my custom legend figure. Is this correct?

Andreas and I have briefly discussed using this mechanism to also provide view components for our color views. Maybe it would be possible to define a figure delegate that adds a rectangle on top of the original figure, which we could use for coloring. Do you think this is feasible?

Hi all,

Attached is a picture of the new version of the legend. I'm no longer using a note, but a custom figure. I still want to use colored squares in front of the text to improve readability. The custom figure allows for much more freedom, so if any of you have suggestions on how to improve the legend, please let me know!

Thijs

---

I have started to try an alternative way to color the views. As I mentioned, I would like to add some colors without affecting the state of the model. My new approach involves a custom figure delegate. It wraps around the figure delegate that is currently used to draw the view component, and adds a switch for the background color. This preserves the original background color and allows me the flexibility I need.

I have written the custom figure delegate, but I am struggling with applying it to the views. I know how figures and figure delegates are initially created (I used the same approach to draw my legend). However, I have not yet found a way to reference the figure once it is created. I need this reference to replace the figure delegate with my custom wrapper. I have a reference to the view component, is there any way to retrieve the associated figure?

Furthermore, the current way in which delegates are selected does not seem very flexible. E.g. looking at ProcessFigure:


    @Override
    public IFigureDelegate getFigureDelegate() {
        int type = getDiagramModelObject().getType();
        return type == 0 ? fFigureDelegate1 : fFigureDelegate2;
    }


This behavior seems inconsistent as it does not use the same variable as is set by setFigureDelegate() in AbstractDiagramModelObjectFigure:


    public void setFigureDelegate(IFigureDelegate figureDelegate) {
        fFigureDelegate = figureDelegate;
    }


Is there a way to work around this, or should I make a change request on the github page?

Quoteis there any way to retrieve the associated figure?

It's really hard to fully understand what you are doing without seeing the code. So I can't answer this.

in the case of:


    @Override
    public IFigureDelegate getFigureDelegate() {
        int type = getDiagramModelObject().getType();
        return type == 0 ? fFigureDelegate1 : fFigureDelegate2;
    }

Some ArchiMate figures can have two representations, so this is returning the one that the user has chosen.

Of course, the proper solution to the overall problem is to create an extension point for rendering figures and is discussed here:

https://github.com/archimatetool/archi/issues/170

So, maybe the effort should be spent on that first, otherwise your customisation is only ever going to be a hack into the main code.

Hi Phil,

That solution looks very promising. You mentioned having a look at this after the release of Achi 4. Have you already made any progress? If feasible, I would love to help you implement the extension point. Do you have any estimate on the complexity (i.e. development time) of such an extension?

Thijs

Hi Thijs,

I'm busy with other development things at the moment so it won't be for some time. But if anyone else wants to implement it that would be good. As for development time, it depends on who is doing it. Could take a couple of weeks, maybe more. Might require a lot of deep refactoring.

Phil

Hi guys,

Sorry for not having replied earlier, but I've been very busy and quite far from Archi these last days.

I'm coming back to one of the first questions asked: would this plugin useful to you ?

The answer is yes if the comparison could be parameterized My aim would be to compare a view to a referential (let say compare an implementation to a SBB) and highlight differences would definitively be a nice to have.


By the way, if you find a way to apply your figure delegate, I'd be very interested to have information on how you did it because I'm trying to develop a plugin that will allow to change the figures icons and color depending on properties. My objective is to distinguish more easily servers, routers, firewalls, storage, ... on technical views.

Best regards
Hervé

Hi all, hope you had a good weekend.

Hervé, thanks for your suggestion. I agree that it should be possible to parameterize the color views. Currently, the plugin allows you to make such a comparison either by:

• Selecting two views and coloring the elements that are in view A, view B or in both views
• Selecting two plateaus and coloring the elements in a single view based on whether they belong to plateau A, plateau B or both

Is this in line with your thoughts?

Phil, I will start looking into creating the extension point. I think this is the best way to properly move forward with the plugin. My aim is to allow figure delegates to be associated with view components in the same way UI providers can be associated with an Archimate concept. I will probably also be touching existing Archi code. I will continue to update you on my progress through this thread. I would also like to pass my work by you, so you can verify the quality. Would you allow me to create a separate branch off the github project?

Best regards,
Thijs

Hi Thijs,

you can clone the code in GitHub and work on your own branch. May I suggest also that, before you dive into the code, do an analysis of what is required. I'm not sure how much time I can spend on it at the moment as I'm working on the model repository plug-in for a few more weeks.

Phil

Hi Thijs,

If the comparison takes the name, then it won't help me, as what I'm looking for is to compare something which is implemented (so using real names) to building blocs (so using generic names).

To be honest, I do not know (yet) how I would do this comparison. Probably on some properties.

Best regards
Hervé

Hi Thijs,

Did you find a way to implement your figure delegate ? And if yes, would you be ready to share your code ?

Thanks and regards
Hervé

Hi Herve,

Yes, I did! I'm done with the base functionality, but want to formalize the documentation a bit before I share anything. Hopefully I can share something by tonight, otherwise you will hear from me tomorrow.

Thijs

Thanks a lot  ;D

Hi everyone,

I managed to extend the code for adding additional figure delegates. Since I had to do some refactoring of the existing code, I want to take this post to explain what I did in some detail.

Goal
My goal was to be able to add any number of figure delegates for any view element (excluding relationships). Currently, Archi has implemented a 'binary' switch between a default delegate and an alternative delegate. This switch is furthermore only supported for a few elements (e.g. business process). Some elements don't even use a delegate to define their shape.

For elements that have an alternative delegate, an additional tab appears in the properties window. Here, a preview is rendered of each alternative shape, and the user can select the shape that they want to use. My goal was to not change this behaviour towards the user. Furthermore, I also wanted to be able to assign any delegate to any element programatically (e.g. for my color views).

Implementation
As mentioned, I had to touch some of the existing Archi code to reach my goal. Specifically, I had to remove the binary delegate switch and replace it with a more extensible system. Furthermore, the new system should apply to all figures. I summarized my changes by means of the attached class diagram.

The most important change is the inclusion of two new extension points:

Figure Delegate Provider
As the name implies, a Figure Delegate Provider ensures that the right type of shape is supplied to a view element. The extension point requires a class that implements the provider for a particular figure type (e.g. ApplicationComponentFigureDelegateProvider provides delegates for ApplicationComponentFigure). Furthermore, a figure delegate provider must have a default figure delegate. This mimics the way Archi currently operates (with the binary switch always initially set to 0).

Figure Delegate
This extension point allows for the definition of new figure delegates. A figure delegate does not need to be registered with this extension point before it can be used. Rather, registering a figure delegate helps define alternative shapes for a particular figure. For example, by registering two shapes for Business Process (e.g. a block and an arrow), the figure delegate provider will know that an alternate shape is available. These two shapes will in turn show up as options to the user in the properties window. This also works for three shapes, four shapes etc. The same delegate can also be reused for another figure.

Aside from the extension points, I made one small change to the metamodel. For the DiagramModelArchimateObject, I removed the 'type' variable that was used for the binary switch and replaced it with a variable that stores the class name (i.e. type) of the figure delegate. If this value is set, the figure delegate provider gives it priority over the default delegate type. This means that individual view elements can still have different shapes. Furthermore, since the value is stored in the model, it is persisted when the model is saved.

I pushed the plugins to which I have made changes to my github:
https://github.com/tgfranck/archifiguredelegates (https://github.com/tgfranck/archifiguredelegates).

I have not yet defined alternate shapes for all concepts, but for e.g. business process it should work fine. Feel free to have a look or even try it for yourself.

Looking forward to hearing your thoughts, or if you have any questions please let me know!

Thijs

I received some comments that the svg cannot properly be viewed with Internet Explorer. Should work fine in Chrome.

Hi Thijs,

I was hoping that you would succeed without updating Archi's core code (what I failed to do myself  :-[), using Eclipse framework or something like that.

Nevertheless I will definitively have a look.

Thanks and regards
Hervé

Quote from: tgfranck on June 27, 2017, 12:11:27 PM

I pushed the plugins to which I have made changes to my github:
https://github.com/tgfranck/archifiguredelegates (https://github.com/tgfranck/archifiguredelegates).

Thijs

Hi Thijs,

Your Github repo is not a cloned branch of the main Archi repo, so there's no way to see what code changes there are. Could you change it?

Phil

Hi Phil,

Thank you. I changed it so my repository now contains an archi branch.

https://github.com/tgfranck/archifiguredelegates

Thijs

Hi,

That's really good work.

I have still to test it, but have one remark: you should not force the figure delegate provider to be bounded to one figure type, this should be generic and open.

It seems you're not aware of this document (https://github.com/archimatetool/archi/wiki/Ideas-for-a-nice-and-elegant-way-to-implement-profiles-and-concepts-customization), it describe the target we have in mind for Archi and several topics, and what you've done is the first step regarding figures and as such should be added in Archi (after some come review of course).

Regards,

JB

Thank you very much Thijs  ;D

Thanks to your code, I'm now able to change the views' objects to specialize them.

Cool, you are very welcome!

JB, thanks for the comments. You are right, the figure delegate provider can be simplified. I changed the implementation of the extension point slightly. Now, the extension point asks for a figure and a default delegate. This removes the need for a distinct delegate provider class for every figure.

I have also done some additional testing and it seems things go wrong when adding figures or figure delegates from other plugins. It seems classes from other plugins are not recognized (ClassNotFoundException).

Apparently this can be remedied by either adding the plugin as a dependency to the Archi plugin (not preferred), or by placing the plugin under the bundle-classpath. For Archi, I believe I can do so by adding the plugin to the plugins folder (correct?).

I have made an export of Archi as well as my plugin to try this out. However, it seems like Archi is not recognizing my plugin when I place the JAR in the plugins folder. In fact, Archi is not recognizing any of my plugins. I also tried a very simple plugin with a single menu contribution, which does get recognized when I put it in the plugins folder of the Archi version I downloaded from the web. Do you have any suggestions why this is happening?

I copied my modified plugins for the editor and model into my archi installation plugins folder, and now all my plugins will load. However, the ClassNotFoundException remains. As mentioned, the Figure I am trying to use is contributed by a separate plugin. I made sure that the package containing the figure is exposed. Do you have any suggestions on how to make my Figure visible to the other plugins?


!MESSAGE Cannot register Figure Delegate Provider
!STACK 0
java.lang.ClassNotFoundException: com.thijsfranck.archicolorviews.test.ColorViewLegendFigure cannot be found by com.archimatetool.editor_4.0.2.201706281434
at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:461)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:372)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:364)
at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:161)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Unknown Source)
at com.archimatetool.editor.diagram.figures.factory.FigureDelegateProviderFactory.registerProviders(FigureDelegateProviderFactory.java:44)
at com.archimatetool.editor.diagram.figures.factory.FigureDelegateProviderFactory.<clinit>(FigureDelegateProviderFactory.java:29)


Hi everyone,

I solved my previous problem. What I needed to do was register my contributing plugin as a 'buddy' to the archi editor plugin. I added a line to the editor plugin manifest as such:


Eclipse-BuddyPolicy: registered


And another line to the plugin manifest of my plugin:


Eclipse-RegisterBuddy: com.archimatetool.editor


By adding these lines to the manifest, the Eclipse class loader is able to discover the classes in the contributing plugin, thus resolving the ClassNotFoundException. Hopefully this will help anyone facing a similar issue!

I'm not convinced that is the solution. Usually it's a problem that packages have not been added to "Exported Package", or something else. I've never had to use the "buddy" thing.

Edit: but the editor plugin should not know anything about concrete class implementations downstream. It should only know about public Interfaces to those classes.

Hi all,

Hoping you can help me out with this. I am struggling to refresh my views from the code. That is to say, I want to be able to redraw the figures on my view at any time. I know that figures get re-drawn whenever a change is made to the model (e.g. selecting a different shape in the properties menu). However, I am trying to do the same without changing the model itself. I believe it should look something like this:


IObjectUIProvider provider = ObjectUIFactory.INSTANCE.getProvider(viewComponent);
provider.setInstance(viewComponent);
provider.createEditPart().refresh();


However, when I try this, nothing changes in my view. The edit part object contains (among other things) a reference to the figure that should be drawn. Do you know of any way to reference an existing figure/existing edit part? Or should I change my approach? Thank you for your help!

Best regards,
Thijs

Hi Phil,

I did add my packages to the exported packages, but that did not solve my problem.

The problem is occurring at the factory class for my extension point. The type of figure the provider providers delegates for, and the default delegate type are specified by the contributing plugin and loaded by name:


Class.forName(configurationElement.getAttribute("providerFor")));
Class.forName(configurationElement.getAttribute("defaultDelegate")));


Adding a buddy policy is recommended by eclipse in this situation:

https://wiki.eclipse.org/Context_Class_Loader_Enhancements#Class_forName

However, I am certainly open to other suggestions. Did you encounter this problem before and is there a simpler way to solve it?

When writing extension plugins in Eclipse,the host plugin (in this case, the Archi Editor plugin) should only know about downstream classes via a declared public Interface type. It should not access concrete classes.

Hi everyone,

Just wanted to let you know that I am still doing some work on the plugin. However, I'm currently struggling with an annoying issue. I wrote a post about it on the Eclipse forum here: https://www.eclipse.org/forums/index.php/t/1087739/ (https://www.eclipse.org/forums/index.php/t/1087739/)

If you have any suggestions, please let me know!

Best regards,
Thijs

Hard to say. Does it work with a simple shape? Is it the way the arrow is being drawn?

Also, I'm not sure of this:

Rectangle clientArea = owner.getClientArea();
container.setBounds(clientArea.getCopy());

should it be getBounds() ?

Hi Phil,

Yes it does work with a simpler shape, such as a rounded rectangle. At least in that case, using the client area as the bounds for my overlay gets me the result I want. When I use owner.getBounds() instead, my overlay is not drawn on the view at all. I think this is because the getBounds() area is too big for any child object of owner.

Before you ask why I do not just use the setBackgroundColor() method, there are two reasons:

1. We do not want to persist the color changes
2. We want to do more complex things with colors. Primarily, we want to be able to add more than one color to a shape. I have this working (rougly) for rounded rectangles. See the attached screenshot for an example. There are still some problems with it due to the current implementation (most notably the color differences due to overlap of transparent areas). I would like to use polygon shapes for this as well, when I can get the scaling issue resolved.

---

I'm enjoying where this is going as I think the feature would be really useful.

This may be off topic, but there could be a cheap workaround for simple highlighting / full fills / font changes etc. I'd be interested in any comments.

1. Duplicate the view you want to add emphasis up.
2. Use the Search filters to find the elements of a particular Property value.
3. Select all those objects - noting that all those objects are highlighted on the new view (so long as 'Link To View' is selected).
4. Now use Edit -> Fill Colour / Font etc etc to set the selected objects accordingly. (This doesn't work, by the way, as you can't get diagram focus).

So it nearly works, apart from the obvious focus problem.