CONDEC-1028: Improve decision grouping, automatic text classification…

…, and change impact analysis (#699) * Fix that decision grouping did neglect the project of a knowledge element * Update dependencies in pom.xml * Make change impact coloring more subtle * Implement Naive Bayes classifier * Reduce size of training data for support vector machine to avoid out of memory exceptions * Add data center compatibility * Update version to 2.3.7
cures-hub · May 20, 2023 · cde69fc · cde69fc
1 parent dfc9829
commit cde69fc
Show file tree

Hide file tree

Showing 42 changed files with 538 additions and 368 deletions.
diff --git a/doc/features/dashboard.md b/doc/features/dashboard.md
@@ -11,7 +11,7 @@ The dashboard comprises five dashboard items that show the following metrics:
 5. **metrics on the decision levels and decision groups**, e.g. *Which decision groups are there in the project? How many decisions are documented per decision level and group?*
 
 The metric plots are created using the [Apache ECharts library](https://echarts.apache.org).
-The four dashboard items are shown in the following sections.
+The five dashboard items are shown in the following sections.
 
 ## Rationale Coverage
 This dashboard item shows the **coverage of requirements, code, and other software artifacts (=knowledge elements) 
@@ -30,6 +30,7 @@ dedicated metrics for intra-rationale completeness (see below).
 This dashboard item presents **metrics regarding the intra-rationale completeness**.
 In particular, metrics are shown to answer the following questions:
 - How many **issues (=decision problems) are solved by a decision**? How many issues are not solved by a decision?
+- How many **issues have at least one alternative** documented? How many issues have no alternatives documented?
 - For how many **decisions is the issue (=decision problem) documented**? For how many decisions is no issue documented?
 - How many **decisions have at least one pro-argument** documented? How many decisions have no pro-arguments documented?
 - How many **decisions have at least one con-argument** documented? How many decisions have no con-arguments documented?

diff --git a/doc/features/decision-grouping.md b/doc/features/decision-grouping.md
@@ -12,7 +12,7 @@ For example, developers can access a UI decision documented in code from a [know
 For example, if a developer assigns a decision to the decision group *process*, the linked decision problem and alternatives will inherit this group.
 
 We use the following definition for decision levels by [van der Ven and Bosch (2013)](https://doi.org/10.1007/978-3-642-39031-9_15):
-1. *High level decisions* affect the whole product, altough they are not necessarily always the decisions that are debated 
+1. *High level decisions* affect the whole product, although they are not necessarily always the decisions that are debated 
 or thought through the most. 
 Often, people that are not involved in the realization of the project (e.g. management or enterprise architects) heavily affect these decisions. 
 Typical examples of high-level decisions are the choice to adopt an architectural style, 
@@ -27,7 +27,8 @@ or the usage of specific APIs.
 These decisions are relatively easy to change, and have relative low impact on the properties of the system.
 
 ## Assignment and Filtering
-Levels and custom groups can be assigned using the context menu on a specific knowledge element in a knowledge graph view.
+Developers can assign decision levels and custom groups using the context menu on a specific knowledge element in a knowledge graph view.
+The following figure shows how a decision and the related decision knowledge to apply a certain git workflow is classified as a *process* decision.
 
 ![Context menu available in all views on the knowledge graph](../screenshots/decision_grouping_context_menu.png)
 
@@ -37,7 +38,7 @@ Levels and custom groups can be assigned using the context menu on a specific kn
 
 *Dialog to assign a level and custom groups to a decision*
 
-Developers (and other stakeholders) can **filter for decision levels and groups**, for example, if they only want to see decisions for the UI or process decisions.
+Developers (and other stakeholders) can **filter for decision levels and groups**, for example, if they only want to see decisions for the *UI* or *process* decisions.
 
 ![View elements of a specific decision group (here git)](../screenshots/decision_grouping_filter.png)
 
@@ -59,9 +60,9 @@ The **quality check view and the tooltip explain why the DoD is fulfilled or vio
 *Decision problem that violates the DoD since no decision level and no custom decision group is assigned to it.
 Developers can see an explanation for the DoD violation in the quality check view and in the tooltip.*
 
-![Decision problem that violates the DoD since only a decision level but no custom decision group is assigned to it.](../screenshots/decision_grouping_dod_violated_level_only.png)
+![Decision problem that violates the DoD since only a decision level but no custom decision group are assigned to it.](../screenshots/decision_grouping_dod_violated_level_only.png)
 
-*Decision problem that violates the DoD since only a decision level but no custom decision group is assigned to it.*
+*Decision problem that violates the DoD since only a decision level but no custom decision group are assigned to it.*
 
 ## Decision Grouping Overview and Dashboard
 ConDec offers an **overview for the decision levels and decision groups** assigned in a project.

diff --git a/doc/features/quality-checking.md b/doc/features/quality-checking.md
@@ -10,13 +10,13 @@ e.g. if a pro-argument is linked to the decision.
 The criteria for intra-rationale completeness can be configured by the rationale manager.
 - the assignment to **[decision levels and decision groups](decision-grouping.md)**.
 - specific aspects (*is test file?*, *number of lines of code*) for code files
-- the **quality of the directly linked knowledge elements** in the knowlegde graph, 
+- the **quality of the directly linked knowledge elements** in the knowledge graph, 
 i.e. if a neighbor knowledge element of the checked element violates the DoD the checked element will also violate the DoD.
-DoD violations are propagated to neighbor elements in the knowlegde graph as a means of [nudging](nudging.md),
+DoD violations are propagated to neighbor elements in the knowledge graph as a means of [nudging](nudging.md),
 i.e., to continuously motivate the developers to improve the knowledge documentation.
 
 ConDec displays the result of the quality/DoD checking in the following ways:
-- in a **quality check view** accessable from every knowledge element in the knowledge graph (see section below)
+- in a **quality check view** accessible from every knowledge element in the knowledge graph (see section below)
 - using **[red text color](nudging.md) in knowledge graph views** if the DoD is violated. An explanation is given using a tooltip.
 - in a **[just-in-time prompt](nudging.md)** that is shown during status changes (as automated quality checks integrated into the development workflow, e.g., when finishing a requirement)
 - in the **[rationale backlog](rationale-backlog.md)**, which is a dedicated view for knowledge elements that violate the DoD

diff --git a/doc/screenshots/change_impact_analysis_scenario_treeview_tooltip.png b/doc/screenshots/change_impact_analysis_scenario_treeview_tooltip.png
diff --git a/doc/screenshots/change_impact_analysis_treeview_tooltip_epic_ise2020.png b/doc/screenshots/change_impact_analysis_treeview_tooltip_epic_ise2020.png
diff --git a/doc/screenshots/criteria_matrix_no_decision.png b/doc/screenshots/criteria_matrix_no_decision.png
diff --git a/doc/screenshots/documentation_comments.png b/doc/screenshots/documentation_comments.png
diff --git a/doc/screenshots/documentation_issue_as_ticket.png b/doc/screenshots/documentation_issue_as_ticket.png
diff --git a/doc/screenshots/issue_fetch_and_display_usernames.png b/doc/screenshots/issue_fetch_and_display_usernames.png
diff --git a/doc/screenshots/node_link_tree_diagram_decisions_only.png b/doc/screenshots/node_link_tree_diagram_decisions_only.png
diff --git a/doc/screenshots/quality_check_view_decision_ok.png b/doc/screenshots/quality_check_view_decision_ok.png
diff --git a/pom.xml b/pom.xml
@@ -6,7 +6,7 @@
 	<modelVersion>4.0.0</modelVersion>
 	<groupId>de.uhd.ifi.se.decision</groupId>
 	<artifactId>management.jira</artifactId>
-	<version>2.3.6</version>
+	<version>2.3.7</version>
 	<organization>
 		<name>Software Engineering Research Group, Heidelberg University</name>
 		<url>https://github.com/cures-hub</url>
@@ -134,14 +134,14 @@
 		<dependency>
 			<groupId>com.atlassian.sal</groupId>
 			<artifactId>sal-api</artifactId>
-			<version>5.0.1</version>
+			<version>5.0.2</version>
 			<scope>provided</scope>
 		</dependency>
 		<!-- Servlets -->
 		<dependency>
 			<groupId>com.atlassian.templaterenderer</groupId>
 			<artifactId>atlassian-template-renderer-api</artifactId>
-			<version>5.0.3</version>
+			<version>5.0.4</version>
 			<scope>provided</scope>
 		</dependency>
 		<dependency>
@@ -153,7 +153,7 @@
 		<dependency>
 			<groupId>org.apache.httpcomponents</groupId>
 			<artifactId>httpclient</artifactId>
-			<version>4.5.13</version>
+			<version>4.5.14</version>
 			<scope>provided</scope>
 		</dependency>
 		<!-- Spring -->
@@ -185,18 +185,18 @@
 		<dependency>
 			<groupId>com.google.code.gson</groupId>
 			<artifactId>gson</artifactId>
-			<version>2.9.1</version>
+			<version>2.10.1</version>
 		</dependency>
 		<dependency>
 			<groupId>com.fasterxml.jackson.core</groupId>
 			<artifactId>jackson-databind</artifactId>
-			<version>2.13.3</version>
+			<version>2.15.0</version>
 		</dependency>
 		<!-- Logger -->
 		<dependency>
 			<groupId>org.slf4j</groupId>
 			<artifactId>slf4j-api</artifactId>
-			<version>2.0.0</version>
+			<version>2.0.6</version>
 			<scope>provided</scope>
 		</dependency>
 		<!-- Active Objects to store model objects via object relational mapping -->
@@ -223,7 +223,7 @@
 		<dependency>
 			<groupId>org.mockito</groupId>
 			<artifactId>mockito-core</artifactId>
-			<version>4.7.0</version>
+			<version>5.3.1</version>
 			<scope>test</scope>
 		</dependency>
 		<dependency>
@@ -261,7 +261,7 @@
 		<dependency>
 			<groupId>com.github.haifengl</groupId>
 			<artifactId>smile-core</artifactId>
-			<version>2.6.0</version>
+			<version>3.0.1</version>
 		</dependency>
 		<dependency>
 			<groupId>com.github.haifengl</groupId>
@@ -271,20 +271,20 @@
 		<dependency>
 			<groupId>com.github.haifengl</groupId>
 			<artifactId>smile-nlp</artifactId>
-			<version>2.6.0</version>
+			<version>3.0.1</version>
 		</dependency>
 		<!-- Git -->
 		<dependency>
 			<groupId>org.eclipse.jgit</groupId>
 			<artifactId>org.eclipse.jgit</artifactId>
-			<version>6.2.0.202206071550-r</version>
+			<version>6.4.0.202211300538-r</version>
 		</dependency>
 		<!-- Summarization of code changes and extraction of decision knowledge 
 			from code comments -->
 		<dependency>
 			<groupId>com.github.javaparser</groupId>
 			<artifactId>javaparser-core</artifactId>
-			<version>3.24.4</version>
+			<version>3.25.2</version>
 		</dependency>
 		<!-- Webhook -->
 		<dependency>
@@ -303,7 +303,7 @@
 		<dependency>
 			<groupId>org.apache.jena</groupId>
 			<artifactId>jena-arq</artifactId>
-			<version>4.6.0</version>
+			<version>4.8.0</version>
 			<exclusions>
 				<exclusion>
 					<groupId>org.slf4j</groupId>
@@ -380,7 +380,7 @@
 			<plugin>
 				<groupId>org.apache.maven.plugins</groupId>
 				<artifactId>maven-enforcer-plugin</artifactId>
-				<version>3.1.0</version>
+				<version>3.3.0</version>
 				<executions>
 					<execution>
 						<id>enforce-java</id>
@@ -442,7 +442,7 @@
 
 	<properties>
         <jira.version>8.21.0</jira.version>
-        <amps.version>8.3.0-128eead6d</amps.version>
+        <amps.version>8.9.1</amps.version>
         <ao.version>4.0.0-m02</ao.version>
         <jacoco-version>0.8.8</jacoco-version>
         <atlassian.spring.scanner.version>3.0.2</atlassian.spring.scanner.version>