[Feature request] Table views of model

[WatchTh1]

Would be great if Archi would allow to have feature to build a table-like views for a set of elements with ability to view and namage relationships.

A good example for such alike feature will be traceability matrices, and treeview generators.

The simpliest Usecase I can imagine would be:

1. User adds a view of a speacial type
2. User declares set of elements as a query. ex: select concept_type|relationship_type [selector] or maybe some kind of master.
3. Archi returns a list of entities in a table-like way.
4. User defines linked entity type (relationship|concept type)./
5. Archi builds a cohesion matrice on a selected type of entity. Where headers contain concepts and cells contain relationships or sets of relationships.

Wrapping this with filters and sorters could add amass of functionality to the instrument.

[WatchTh1]

Seems like this is a duplicate of matrice view feature request. If possible would be nice to get an idea when would it be at roadmap?

[Phillipus]

This is something you can implement yourself or with jArchi.

[WatchTh1]

This is something you can implement yourself or with jArchi.

Yea, trying to get close with Eclipse RPC.

[Phillipus]

Yea, trying to get close with Eclipse RPC.

It would help if you could create a detailed set of functional requirements, some mock-ups for what it might look like.

Here's some things that would need to be considered...

• What UI components would be needed? SWT Table? SWT Tree? Eclipse Nebula Grid?
• How it would manifest in the workbench Eclipse View? Eclipse Editor? DnD support?
• Is the output static or generated in real-time?
• Where is the query stored? In the *.archimate file? Separate file?
• How is the query parsed? SQL? Would it need a SQL plug-in...

The user would probably want the output in a report of some kind. HTML? PDF? Excel? Raw data? And if the end result is in this format maybe it's possible to do this with jArchi and some additional JS/Java libraries?

[WatchTh1]

Partialy it has been done. User stories/Usecases, wireframes, logic. Software achitecture decisions - currently a weak spot. I hardly can imagine variety of options enough detailed.

If you would help me to have some ideas i could share usage concepts and solution requirements.

[LioDL]

With no idea on how it could match Eclipse Fwk, but I see @Phillipus answer about a set of functional requirement. That's something I can do ;-) ! My inspiration is coming from Business Intelligence pivot table (Qlik, BO or Ms BI Pivot table), it may exist some graphic java component dealing with these things (?)

So, in the archimate way of speaking, the goals may be : 1) "Manage Togaf "artifacts" (other than diagrams) matrice and catalog in order to make Archi number 1 among Togaf practitioners" 2) "Make matrices and catalogs a mean to manage, correct, input and analyse the model in a way as convenient as diagrams (~Archi views) Driver is of course : Archimate is becoming the best modeling notation to support Togaf

Outcome : "Manage Catalog as a new type of Archi view", "Manage Matrice as a new type of Archi view"

which means in term of (general) requirement that :

A) Interaction with the elements of a catalog (or a matrice) is same than the actual Archi view : firstly Navigator, Visualiser, Properties, hints and contextual menu fonction 'Select in model tree'... All these are available when you clik or navigate in the table (whether catalog or matrice) B) Formating the table is as easy as formating Excel Pivot table (folding, unfolding, sorting or arrange elements first, last, up and down) C) Table is always consistent with the model. that is more a principle than a requirement ;-) The requirement is that the table is generated and refreshed when displayed or when a change occurs in the model D) A table Catalog is made of one Hierachy of elements (line) and one or many cells (columns). A table matrice is made of 2 hierarchies of elements (one for the line, one for the column) and one (definition of) cell. E) Hierarchy is user defined. Hierachy is an ordered list of levels.

• Each Level defines its children by a "path" applied to its own elements (based on type relationships, name and attributes)
• Elements of a level, the collection coming from its parents, are filtered by some user defined rules (based on type, name and attributes). Level 0 (root) considers all model elements and apply its filters
• A level may be defined but not displayed in the table
• An element is unique in a hierarchy
• Elements of a same level may be grouped by some parameter (based on their attributes or the rule that retain it)

F) A path may be a direct relationship or a valid derived (see Archimate rules derivation 1 to 8) relationship (with a depth constraint) G) Cells (columns) in a table catalog are user defined based on attributes. The value is displayed H) Cell in a table matrice is user defined :

• based on the existence or not of relationships between the element in line, as a source, and element in column, as a target.
• when many, a priority rule retains only one relationship
• The cell display is either the type, name, a label, a value attribute or simply a cross

I) Viewpoint may apply both on hierarchy and cell to final-filter the results J) Cell is user editable :

• delete the relationship (with usual alerts...)
• modifiy the relationship depending on what is displayed : type, name or attribute value
• create a relationship (type asked and usual alerts on existing doublon)

More detailed in the attached xls file. Architool matrix and catalog.xlsx

It sounds like a list to Santa Claus !

This exercice make me think of a lot of things that couldn't be included in this list. I am at your disposal to develop or think about questions that may raise !

[Phillipus]

@LioDL Thanks for the detailed analysis, which will require deeper consideration.

As a matter of fact, @jbsarrodie and I are currently exploring how we might implement matrix/table views in Archi, so your contribution may help us. We're not sure when matrix/table views might be implemented as we are planning on implementing ArchiMate Profiles as our next task.

Phil

[LioDL]

Great news that you have identified it even though not yet planned !

Completing the functional requirement and to be test driven, the following 2 examples should be supported (and many can be found in Togaf guide : Togaf and Archimate modeling g21e.pdf [a MUST-READ]) :

1) Catalog of requirements

• Hierarchy : Driver > Goals > Outcome > (Requirement union Principle) through Realize or influence relationships. Requirement may present 2 spécializations : \<\> and \<\>> (grouped by in the display)
• Cell (colums) display some common attributes like : Priority, Id, Customer Satisfaction level, Customer dissatisfaction level, ...

2) RACI Matrice (or Actor role togaf matrice artifact) : RACI is a matrice to clarify level of implication / commitment into some activities. A stands for Accountable (decide, assess, validate), R for Responsible (produce, work), C for consulted and I for Informed. The model is :

• 'A' and 'R' are clearly modeled with Assignment relationship between Active structure and Behavior. An attribute or 2 specializations can convey the distinction between A and R
• 'C' may be either a Flow relation from Active structure to Behavior OR a Serving relation from Active structure to Behavior
• 'I' may be a Flow Relationship form Behavior to Active structure

The matrice :

• Hierarchy 1 : Business Fonction (1 root) > Business process level 1 > Business process level 2
• Hierarchy 2 : Actor (1 root ) > Actor (level direction) > Actor (level service) Union some other Role Union some Business Collaboration (acting as Comitee to take decision)
• Cell should display A, R, C or I at the "leaf" (level 3) intersection between hierarchy 1 and 2. Intersections at level 2 could be a derivated relationship that sum-up downward levels (to be qualified...)

Looking forward to work with even if in many months or some years !