Profiles and TableView requirements and related ideas

Profiles

Context

The projet ArchiMate language customization (specialization and custom notation) has been launched in 2021 to support language customization as described in the specification. Its progress has been tracked in a dedicated wiki page and even though most of the requirements have been implemented, a last one remains:

• Definition of profiles. in ArchiMate, a profile is a named set of properties that can be then applied to any kind of concept. Profiles are often used to centrally manage sets of properties with a common goal. For example, one could define a "Cost" profile containing two properties "One-time Cost" and "Running Costs" and apply them to elements used to model company assets such as servers, applications, facilities... You can also see profiles as name spaces for properties.

This requirement has been removed from the MVP which focused on specialization profiles only.

Requirements

Core features

• A profile is a named group of properties
  • A profile has a name
  • A profile can be empty (i.e. it contains no properties)
  • A profile can contains a list of properties
  • A property can be set as mandatory
  • A profile can (optionally) be restricted to a specific type of ArchiMate concept (element or relationship)
• A profile can be set as a specialization profile (Specialization profiles are what we simply call specializations today in Archi.)...
  • in such case the profile must be restricted to a specific type of ArchiMate concept
  • An optional image can be set on a specialization profile
• A profile can be applied/assigned on concepts
  • The list of profiles applied/assigned to a concept must be shown somewhere on the concept Properties' View (either into the Properties tab on into a new Profile tab)
  • The properties defined in the profile must be visible so that the user can set their value
  • The model should not be saved if mandatory properties are left unset

Complementary features

• Profile's properties can be typed using built-in/simple types (exact list of types yet to be defined, but could be inspired by the types allowed by the ModelExchange File Format: string, number, date, time, boolean).
• Profile's properties can be types using custom/structured types:
  • A structured type can be defined: it has a name and a list of (named) attributes

Example

One could define a "Cost" profile which contains two properties:

• "One-time Cost" (optional)
• "Running Costs" (mandatory)

These two properties could use the structured type "Amount" which is defined as a number (Value) and a string (Currency)

Implementation Guidelines

For core features

The Specializations Manager should be renamed Profile Manager and should support the core features (related to profile definition) listed previously. On each ArchiMate concept, it is still possible to set a specialization (taken from the list of specialization profiles), in such case it also applies the profile to the concept.

A simple way to apply/remove/fill-in profiles could be implemented by extending the current Properties tab of the Properties View:

• In the table, rows could be grouped by profiles (in such case the name of the group is the name of the profile) and ad-hoc properties could be shown at the end. Here's a mockup:

  

• In the vertical toolbar on the right, new buttons should be added to apply/remove profiles (when removing a profile, the associated properties are removed too)

I suggest the following mechanisms to ensure mandatory properties are set:

• When applying a profile to a concept (through the new "apply profile" button from the properties tab), make it impossible to leave the properties tab or to select another UI element if mandatory properties have not been filled in.
• When saving a model, add a check which ensure that all mandatory properties have been filled in. This is needed because at some point it will be possible to assigned profiles through scripts (or worse, to manually edit a .archimate file) and in this case we won't be able to check it "in real time".

Known challenges

For complementary features: Managing custom/structured types can be painful: how does it look like when the user enter a 'Cost' value? Maybe a small dialog appears when the user clicks somewhere into the 'Property Value' cell, and shows the list of attributes ('Value' and 'Currency')?

TableView