Hello,
This old post: Adding New Elements and Relationships to Archi (http://forum.archimatetool.com/index.php?topic=247.msg1316#msg1316) refers to Extending the Model with a new Element (http://archi.cetis.ac.uk/developer/model-new-element.html) which is even older.
Before I get my hopes up, what would be the most up to date way to extend the Model with a new Element?
Is there any documentation that I can follow?
Thanks!
zxxz
Hi,
I'll let Phil provide a technical answer, but my question would be: why would you want to do that? This would no more be archimate and models created thus way could no more be opened without the "hacked" Archi.
JB
Hello JB,
Referring to Chapter 15 Language Customization Mechanisms in the specs it would still be (valid) Archimate 8).
I am aware of the portability issue that this would entail in regards to Archi but for the moment I can live with it and I have something in mind that might be portable (at the moment just an idea though...).
zxxz
Hi,
So there is some ununderstanding: Metamodel extension in Archi is not what ArchiMate call Language Customisation. There is currently no real way in Archi to match what Chapter 15 describe, but If you want to be close I'd suggest to simply use existing concepts and use the <<stereotype>> notation (or whatever you want) and add the stereotype name in a property (e.g. named stereotype). This way you'll be able to quickly identify concepts (through label) and also search them (through property). Of course, you wont have these new types in the palette, but you can easily create a small model containing only one view in which you put all these pre-set elements, and then open this view aside other views (just drag'n drop it where you want). Then using those elements is just a matter of doing a copy/paste. Bonus: in addition to properties and label, you'll also copy/paste visual attributes (color, font...) which can make sens in this contexte.
Regards,
JB
Hello,
I understand the <<stereotype>> approach (and the notation proposed by Gerben) but that's not what I am looking for.
I am curious to see if I can create new elements as specialisations of existing ones; for example creating Concern as specialisation of Driver, or Mobile Device from Device, or Threat from Assessment, etc.
The specialised elements would just have a different icon and inherit all relation rules from the parent one: this way there would be no portability issue (at least in theory) because a "vanilla" Archi would just show the default icon.
This is just a "pet project" I have in mind, and if I can make it happen I would gladly share it with the community (if there is any interest of course).
Thanks for your support.
zxxz
Hi,
What you describe is the same as the stereotype. The only difference being that you want different icon istead of the <<stereotype>> label. In Archi you can't do what you want because extending the model will not work the way you think: there will be no inheritance, so (e.g.) a Threat will not share allowed relationships with Assessment.
What would be more aligned with what you want would be to change the code responsible for drawing shapes and icons to draw custom icons depending on whether or not a property named stereotype exists. That's an approach that would not require any metamodel change but would have the effect you want. And in this case the model could be opened on a "vanilla" Archi without issues.
That's something we have in mind as part of a more profond redesign of the way figures are being drawn, so any help welcomed ;-)
Regards,
JB
Hello,
Indeed, rendering a different icon according to the value of a stereotype property seems a good idea :D
Moreover, expanding on that, controlling how an element is rendered using property values would enable the notation proposed by Gerben and avoid a "multi-line" editor.
I would happily help, is there a dedicated area I can read to get up to speed with your reasoning?
zxxz
I think the first thing woujld be to read this issue : https://github.com/archimatetool/archi/issues/170
Then maybe share on this forum your ideas so that we could build the full vision.
cedepz already looked into the code, it looks promising!
I will follow the Developer Resources (http://www.archimatetool.com/developer) and explore the code next week.
I agree with JB. You could make additions to the code and re-compile but your app would be an island unless you distributed your version as well.
To support this kind of thing properly is not trivial and would require many additional "hooks" for the model and for UI behaviour, and a description of the extended metamodel that would ship with the model instance so it could be opened (icons, colours, metamodel beahviour, relationship rules, drawing code to draw the icons, etc, etc).
Phil
Hello Phil,
JB suggested to start here : https://github.com/archimatetool/archi/issues/170
Do you have any additional info I can look at?
Thanks,
zxxz
Hi,
Sorry if this is a bit late but I have a fairly detailed description of how to do this, can't post it today but I'll try to remember to do it tomorrow.
Quote from: ChampagnePerry on April 12, 2017, 14:03:18 PM
Hi,
Sorry if this is a bit late but I have a fairly detailed description of how to do this, can't post it today but I'll try to remember to do it tomorrow.
Hello,
Any chance you could share your detailed description 8) ?
Thanks!
I am also very interested on extending the model for technical elements (differentiating physical servers, virtual servers, routers, firewalls, san storage, and so on ...).
The eclipse framework allows to override classes, especially factories (i already use this functionality in my database plugin). I haven't looked at this part in detail yet, but the icons are managed by UIProvider classes that expose a getImage() method. As those classes are factories, they should be easily overridden to get the icon from a property.
If this is developed through a plugin, then people who will have the plugin will see the new icon. People who do not have the plugin will see the standard icon. I personally like plugins because it is much easier to maintain rather than forking the whole Archi code.
I'm available to discuss this further if you wish.
Best regards
Hervé
+1
My use case is detailing a system architecture with a messaging model. If you want to do it the proper way, the de-facto standard is to use the Enterprise Integration Patterns from Gregor Hohpe (here (http://www.enterpriseintegrationpatterns.com/patterns/messaging) and here (http://www.enterpriseintegrationpatterns.com/downloads.html)). I think EIP would make a great addition to system architecture models.
The actual question on EIP in Archi has been asked already separately (http://forum.archimatetool.com/index.php?topic=348.msg1860#msg1860), but I think it's great value adder, and worth mentioning once more.
And ofcourse, as a Linux user I have nowhere else to go ;-(
Lastly: Enterprise Architect has an add-on (http://www.bobovo.eu) for EIP.
Koos
Hi, only for inspiration.
In Sparx Enterprise Architect users can change in configuration a presentation of elements or relationship on a diagram via a ShapeScript or a Metafile. ShapeScripts have mostly used also when defining a UML profile that extends UML or another modelling language.
How ShapeScripts look like for ArchiMate, ArchiMate 2 and ArchiMate 3 is possible to see in ShapeScripts catalogue:
http://www.bobovo.eu/mdg_shape_scripts.aspx (http://www.bobovo.eu/mdg_shape_scripts.aspx)
But ShapeScripts are only about the presentation of elements and it is not enough for extending the model.
In the discussion mentioned Add-in for EIP (http://www.bobovo.eu/mdg_for_eip.aspx (http://www.bobovo.eu/mdg_for_eip.aspx)) is the example how the capability of Enterprise Architect was extended to allow creating a new model.
Best regards
Bob
Dear all,
Here is my comprehension of how the icons are managed.
The com.archimatetool.editor.ui.factory.ObjectUIFactory class creates the UIProviders and store them in a HashMap (method registerProviders()).
When a component is drown, the UIProvider is retreived from the class name using the class name (method getProviderForClass(EClass eClass)).
And the icon is retreived from the UIProvider (method getImage());
It's quite straight forward to surchage the factory and the UIproviders, but unfortunately, I failed to retreive promatically the EObject corresponding to the element drawn.
So I can't change the icon through a plugin.
What I suggest, is to update the getImage() and getImageDescriptor() of all the UIProviders methods, adding the element as parameter :
for instance, ApplicationInterfaceUIProvider methods are :
@Override
public Image getImage() {
return getImageWithUserFillColor(IArchiImages.ICON_APPLICATION_INTERFACE);
}
@Override
public ImageDescriptor getImageDescriptor() {
return getImageDescriptorWithUserFillColor(IArchiImages.ICON_APPLICATION_INTERFACE);
}
And would become
@Override
public Image getImage(EObject eObject) {
return getImageWithUserFillColor(eObject, IArchiImages.ICON_APPLICATION_INTERFACE);
}
@Override
public ImageDescriptor getImageDescriptor(EObject eObject) {
return getImageDescriptorWithUserFillColor(eObject, IArchiImages.ICON_APPLICATION_INTERFACE);
}
The AbstractArchimateElementUIProvider.getImageWithUserFillColor() would then be able to check the properties to calculate the image to return.
We can use the property "icon" which is quite understandable, or even choose it through an option on a preference page. As per Gilles suggestion, we could create the icons from existing standards like http://fontawesome.io/icons (http://fontawesome.io/icons) ou https://material.io/icons (https://material.io/icons).
I could suggest :
- "icon" = "fa:<iconName> would create a Font Awesome icon
- "icon" = "md:<iconName> would create a Material Design icon
- "icon" = "<file path>" would create an icon from a jpg or svg file
protected Image getImageWithUserFillColor(EObject eObject, String imageName) {
// Not a preference
if(!Preferences.STORE.getBoolean(IPreferenceConstants.SHOW_FILL_COLORS_IN_GUI)) {
return IArchiImages.ImageFactory.getImage(imageName);
}
if ( eObject instanceof IProperties ) {
for ( IProperty prop: ((IProperties)eObject).getProperties ) {
if ( prop.getKey().equals("icon") ) {
imageName = prop.getValue();
break;
}
}
}
Image image = fImageRegistry.get(imageName);
if(image == null) {
// Create local ImageDescriptor and try again
getImageDescriptorWithUserFillColor(imageName);
image = fImageRegistry.get(imageName);
// If image is still null then we didn't make a new one and so need the default image
if(image == null) {
return IArchiImages.ImageFactory.getImage(eObject, imageName);
}
}
return image;
}
}
protected ImageDescriptor getImageDescriptorWithUserFillColor(String imageName) {
...
ImageData imageData = originalImageDescriptor.getImageData();
if ( imageName.startsWith("fa:") {
// create FontAwesome icon
}
else if ( imageName.startsWith("md:") {
// create a MaterialDesign font
}
else {
...
}
...
}
Whatever the issue (non existent icon, file not found, etc ...) will mean defaulting to the standard element icon.
Of course, all the getImage() calls will need to be replaced by getImage(element) where needed.
The advante of this solution is that the model is not impacted. Opening the dot archimate file without this icon management stuff will result in showing the standard elements icons.
The disadvantage I foresee is that the icon change will not be real-tim when one changes the "icon" property. To change the icon displayed, the view will need to be closed and re-opened.
JB, Is this something that would be acceptable for you ?
Thanks and regards
Hervé
Hi,
I think several things are discussed and mixed: the icon drawn inside figures on views is managed by code while the icon seen on the palette is and image. In addition this is (again) linked to profile and concepts customization which has to be done the proper way (ie. in a way that makes possible to export to the open exchange format).
That's something that Phil and I discussed some months ago and I have a pretty clear idea on how we should do it. Only issue (for the moment) is free time or funding to do it.
I'm writing a page on Archi's wiki to share it with you. I'll post here as soon as it will be done.
Regards,
JB
Thanks JB
Here it is (https://github.com/archimatetool/archi/wiki/Ideas-for-a-nice-and-elegant-way-to-implement-profiles-and-concepts-customization)
Good reading
Regards,
JB
Thanks, JB. 8)
Very nice way, indeed ;D