Ideas for a nice and elegant way to implement profiles and concepts customization
This is an attempt at sharing and clarifying ideas for a nice and elegant way to implement profiles and concepts customization. But first, what are profiles and concept customization?
Profiles and concept customization are described in the chapter 15 of the official ArchiMate specifications. To explain it the simpliest way, a profile is a named set of attributes (attributes is the official ArchiMate name for what Archi call properties). For example if you have to manage cost related attributes on several elements (whatever their type is) you could define a "cost" profile which includes an "acquisition cost" and a "running cost" attributes.
On top of that, concept specialization allows you to define your own concepts (elements or relationships). Specialized concepts inherits all properties of their "ancestor" but can also limit some of them. For example one could define a "Database" concept that would inherit from the "Artifact" concept, and decide that the realization from "Artifact" to "Application Component" is not allowed for the "Database" concept as a database is mostly data and not code (I know that you can put code inside some databases but I simplify for the sake of the example).
Note: UML comes with the notion of "stereotype" and "profile". UML "profile" is not at all similar to ArchiMate profile. In UML a profile is more a grouped definition of multiple stereotypes. UML "stereotype" is very similar to ArchiMate concept specialization, so in this document I now use "stereotype" to speak about concept specialization.
ArchiMate standard also explains that you can mix stereotypes and profile. That is to say that you can define a "Database" stereotype of "Artifact" and associate at the same time some pre-defined attributes (e.g. SGBD, Host, Port...).
Last but not least, in a perfect world (ie. a tool that would implement all things described in the standard) you could also decide to change figure and/or icon of a stereotype.
Good question and the answer is not that easy. In my mind this is a solution that:
- doesn't requires too much code,
- provides a way for user to define profiles and stereotypes using Archi itself (not edition some XML, JSON or Java source code),
- Is fully integrated with import/export plugins, especially the one for the ArchiMate Open Exchange File Format.
In addition, this is tightly linked with other enhancements related to viewpoint definitions, but hopefully all this could be done step by step.
The first step it to rework the way figures are managed in Archi. This has been discussed in this issue but let's explain it in more detail here.
In Archi, there is a clear separation between model and view: each ArchiMate concept is covered by an EMF (Eclipse Modelling Framework) class at model level and by a Draw2d Figure class at view (ie. diagram) level. Figure classe are in charge of drawing the figure you see on a diagram (the whole shape and the top right icon).
As you certainly know, in Archi some concepts like Node or Business Process can be drawn using different figures. This is managed through what Archi calls "figure delegate". Asof today, only some elements have a figure delegate. I think that all figures should be able to use all figure delegate. Of course by default one of the allowed standard notation would be used (based on the preferences, like now), but the user should be able to switch between figures if this helps him to convey the intended information more easily. For this to work, some refactoring is needed, because icons would have to be drawn not by the figure deletage itself but by another, separated, class. So at the end we should end up with a generic way of drawing the global shape which would call (or not if this doesn't make sens) a generic way of drawing icon. In addition we should add a way to use an image (as it is already possible in Canvas).
Here is what it could look like:
At this point it would even be possible to provide extension points which would open the way to plugins that would provide additional visual notations.
Let's jump into another related topic: Viewpoint definition.
I think that a good viewpoint definition is:
- easy to create for the user,
- tighly linked to the model itself (it wouldn't make sens to share a model without the definition of viewpoints used in the model,
- able to also influence figures used for concepts (e.g. if a viewpoint targets some CxO, then you will certainly want to avoid default figures and icons and instead use only simple boxes and/or images)
This leads me to this conclusion: viewpoint definitions are in fact some kind Archi views. Let me be clearer, I think we could use a view created in Archi as a specification for other views (lets call this a VPview):
- the name of the VPview is the name of the viewpoint
- the list of all VPview could be the list of viewpoints that you can see on the view properties tab
- only concepts added to the VPview would be allowed in a view using the viewpoint
- if the appearance of a concept is changed (font, figure, icon...), then this setting becomes the default when using the same type of concept in a view using the viewpoint
Doing it this way, we could then rework Sketchs and Canvas to be in fact nothing more than specific viewpoints:
- by default a VPview allows any type of ArchiMate concepts, Canvas & Sketch figures and generic figures (legacy grouping, note and connector)
- Canvas is in fact defined through a VPview that contains only Canvas figures and generic figures
- Sketch is in fact defined through a VPview that contains only Sketch figures and generic figures
- ...
Of course, doing so would requires a way to distinguish concepts created to be added on VPviews and concepts created as part of the model (added to "real" views). This could be managed by adding another top level folder inside the Archi model (together with Strategy, Business, Application...) for all those concepts and VPviews, and some code to avoid using them in "real" views. Lets call it the "Viewpoints" folder.
A similar approach could be used for profiles: a profile definition could be just a concept created in a new, top level, "Profiles" folder:
- the name of the concept is the name of the profile
- properties defined for the concept would be pre-defined attributes for the profile
A mecanism would then have to be added to Archi to provide access to these profiles definition when editing concept properties (and making sure that any property added to a profile is automatically added to concept using this profile.
User could "promote" profiles to stereotype by adding them to a "Stereotype" view created inside a new, top level, "Stereotypes" folder, and if the appearance of a profile definition concept is changed (font, figure, icon...), then this setting becomes the default for the stereotype.
Applying a stereotype on a concept could then just be done through a new drop down list (listing all stereotypes) between "Name" and "Documentation" fields in the Propertie tab. Applying a stereotype would immediately add the profile (thus the associated attribute list) and impact appearance.
Using all those features, one could do whatever he wants with Archi. And all this could be easily exported to the ArchiMate Open Exchange File Format as no new EMF classes would have been created (only existing classes are used).
Isn't it a nice and elegant way ?