AttributeGroups

# Feature request

CodeCharta can currently only display single number metrics. There are a couple of cases where it would be beneficial to be able to group together some numbers or even to display strings. To remain backward compatible I suggest we add a new field `attributeGroups: {}` to the file node in the cc.json.

## Description

### Visualization Goals

The attribute groups not only group together metrics, they also allow non-number metrics. Non-number metrics allow us to tag similar `"file"`s, for example with the author name. I have no idea how to display non-number metrics with the size or height, so we won't do that. But it's very useful for the color.

The attribute groups should allow us to:

* Color buildings depending on who the main author is. This should tell us how distributed the knowledge is. If all buildings belong to the blue author and that author is no longer with the team, we have a problem.
* Using temporal coupling we can cluster buildings depending on which ones are always changed together. A building can then be colored depending on the cluster it belongs to which might be different from the folder a human has placed it into. If a cyan cluster building is in a folder in which only purple cluster buildings are, this building is not placed correctly. If we have a folder in which buildings have all colors of the rainbow, we have a massive structure problem.
* Color all buildings depending on if their bugs are critical, major etc.
* Building height depends on if they have critical bugs.
* Color all buildings that have nesting level of six or more in red, four or more in yellow and less than four in green.
* Color buildings depending on what date band they were last modified
* Color each building like a bar chart. How much of that building has a nesting level of 1, 2, 3,4 etc. OR how much of that building belongs to a specific author.

Important side-note: **we need to provide some way to anonymize the author names in the analysis.**

### Questions to answer

* How are deltas handled for groups?
* What about attributes in the old file that match the name of the attributegroup?

### Possible Metrics

To ensure the attributeGroups are flexible enough for future use we'll discuss a couple of metrics we could display with them:

* Sonar issues, bugs, vulnerabilities #115 #608
* Main and secondary authors per file #363 #624
* Clusters to which certain files belong to #618 #622
* Indendation Level #660
* Nesting Level #659
* Occurence of certain keywords in comments (or code) #281
* Dependency Check information #539
* TODO: check csv output of PIT mutation testing result #326
* TODO: check other CodeMaat #291 and CodeScene Metrics and see if we can display them using AttributeGroups.

While a table is not good to display hierarchial data, it is rather fitting to compare these metrics and see if we can all treat the uniformly. The cc.json structure is discussed at the end.

| File | AttributeGroup | AttributeGroupType | AttributeGroupImportance | Metric | LineRanges |
| --- | --- | --- |---|--- |--- |
| **Sonar Issues** | - | - | - | - |- |
|dialog.download.component.ts | Bugs | Critical | 100 | Move this array "sort" operation to a separate statement. | 73..73 |
| legendPanel.component.html | Bugs | Minor | 50 | Add an "alt" attribute to this image. | 37..37 |
| areaSettingsPanel.component.scss | Code Smells | Major | 80| Unexpected empty block | 1..1 |
| **Coupling Cluster** | - | - | - | - |- |
| metric.service.ts | Temporal Coupling | | | Metric Cluster ||
| settings.service.ts | Temporal Coupling | | | Setting Cluster ||
| **Main Author** | - | - | - | - |- |- |
| EdgeFilter.kt | Authors | Main | 85 | alschmut ||
| EdgeFilter.kt | Authors | Second | 15| Foo ||
| SourceCodeTest.kt | Authors | Main | 100| Richard Gross ||
| **Nesting Level** | - | - | - | - |- |
| settings.service.ts | Nesting Level | 0+ | 0 | 200 ||
| settings.service.ts | Nesting Level | 1+ | 10 | 190 ||
| settings.service.ts | Nesting Level | 2+ | 20 | 100 ||
| settings.service.ts | Nesting Level | 3+ | 40 | 50 ||
| settings.service.ts | Nesting Level | 4+ | 100 | 10 ||
| settings.service.ts | Nesting Level | 5+ | 120 | 5 ||
| settings.service.ts | Nesting Level | Max | | 5 ||
| settings.service.ts | Nesting Level | Average | | 5 ||
| **McCabe Complexity** | - | - | - | - |- |
| settings.service.ts | Mcc | File Sum | | 200 ||
| settings.service.ts | Mcc | Class Max | | 40 ||
| settings.service.ts | Mcc | Class Average | | 20 ||
| settings.service.ts | Mcc | Biggest Class | | 30 | 1..30|
| settings.service.ts | Mcc | Function Max | | 20 ||
| settings.service.ts | Mcc | Function Average | | 15 ||
| settings.service.ts | Mcc | Biggest Function | | 10 |40..55|
| **Comment Terms** | - | - | - | - |- |
| codeMapMesh.ts | Comment Keywords | Todo | 80 | 3 | 10..10, 12..12, 13..13|
| codeMapMesh.ts | Comment Keywords | Hack | 100 | 1 |1..1|
| codeMapMesh.ts | Comment Keywords | Wtf | 120 | 2 | 50..51, 53..55 |

#### Comments

* Sonar issues also tell us in which line or range of lines the problem exists. Sonar provides us with an url though so we don't need that information as long as Sonar is running. If it's no longer running we cannot click on the link and that information would be lost.
* LineRanges are useful to find bug lines and also to identify which class inside a file is the biggest or which function is the biggest and also to find the hack inside a class again
* Sometimes the value is a number (nesting level or mcc), sometimes it is a short string (main author, cluster) and sometimes it's a whole description (bug, vulnerability, smell).
* The AttributeGroups allow us to group together long existing metrics like mcc as well
* Should it be possible to only select the attributeGroup "Bug" but not a specific type in the metric dropdown? If so what metric is displayed? Is there perhaps a default type that gets elected in such a case?
* The **AttributeGroupImportance** is probably confusing. I needed it originally to show the ownership of the main, secondary or third authors. I.e. does the main author own 85% of the code or just 40%? However I realized that the bug criticality also has different levels. Critical is more important than major and so on. Not sure it is useful for the other attributeGroups. The idea was that CC could figure some things out automatically based on the importance but I'm not yet sure what :) In some cases it does not even make sense to have the importance so this one is still unclear.

### Possible cc.json

```json
{
"name": "bigLeaf.ts",
"type": "File",
"attributes": {
"rloc": 100
},
"attributeGroups": {
"Bugs": [
{
"type": "Critical",
"importance": 100,
"value": "Move this array \"sort\" operation to a separate statement.",
"LineRanges": [{"exactly": 73}]
},
{
"type": "Minor",
"importance": 50,
"value": "Add an \"alt\" attribute to this image.",
"LineRanges": [{"exactly": 37}]
}
],
"Temporal Coupling": [
{
"value": "Metric"
}
],
"authors": [
{
"type": "Main",
"importance": 85,
"value": "Benedictious"
},
{
"type": "Second",
"importance": 15,
"value": "Bo"
}
],
"Comment Keyword Count": [
{
"type": "Wtf",
"importance": 120,
"value": 2,
"LineRanges": [{"from": 50, "to": 51}, {"from": 53, "to": 55}]
}
]
},
"link": "http://www.google.de",
"path": "/root/bigLeaf.ts"
}
```

The issue names the cc.json file-node format and visualization goals but no implementation files or tests. Start by locating how existing attributes are parsed and rendered, then determine the scope and acceptance criteria for attributeGroups, including non-number values, deltas, and author anonymization.

Written by the indexing model from the issue text.