• Keine Ergebnisse gefunden

Entscheidungswissen in JIRA-Issue-Kommentaren automatisch klassifizieren

5.3 Entwurfsentscheidungen zu Systemfunktionen

5.3.2 Entscheidungswissen in JIRA-Issue-Kommentaren automatisch klassifizieren

Dieser Abschnitt beschreibt den Entwurf und die dabei getroffenen Entscheidungen zu System-funktion 2 aus Kapitel 4.2.2.2 auf Seite 24. Abbildung 5.4 illustriert das wichtigste Entschei-dungsproblem zu dieser Systemfunktion. Tabelle 5.5 listet weitere EntscheiEntschei-dungsprobleme auf.

Abbildung 5.6 zeigt alle n¨otigen Klassen f¨ur diese Systemfunktion.

R. Alkadhi entwickelt in ihrer Arbeitet einen Klassifikator, der Entscheidungswissen in nat¨urlicher Sprache erkennt und in einen Wissenstyp klassifiziert. Dieser Algorithmus kann einem Satz mehr als ein Wissenstyp zuweisen [7]. Eine Entscheidung, die bei der Umsetzung dieser Systemfunk-tion getroffen werden musste, war die Frage, ob DecXtract mehr als einen Wissenstyp f¨ur ein Entscheidungselement zul¨asst. Abbildung 5.4 adressiert dieses Entscheidungsproblem.

Die ConDec-KlasseDecisionKnowledgeElement speichert Wissenstypen im Attribut knowledge-Type. Die m¨oglichen Wissenstypen sind in derKnowledgeType Enumeration gespeichert. Tech-nisch ist die Umsetzung von mehreren Wissenstypen f¨ur ein Entscheidungselement m¨oglich, erh¨oht allerdings den Integrationsaufwand in ConDec-Klassen. Zudem entsteht eine logische Inkonsistenz gegen¨uber der bestehenden Implementierung von ConDec. Um DecXtract gut in ConDec zu integrieren und eine gute Wartbarkeit zu erm¨oglichen wurde entschieden einem Satz maximal einen Wissenstyp zuzuordnen.

  Issue ¡ Soll ein Satz mehrere Wissenstypen annehmen k¨onnen?

  Entscheidung ¡ Ein Wissenstyp

Konsistent zu ConDec

  Alternative ¡ Mehrere Wissenstypen

Inkonsistent zu ConDec

Abbildung 5.4: Entscheidung ¨uber die Zuordnung von S¨atzen zu Wissenstypen.

Ein weiteres Entscheidungsproblem, das bei der Umsetzung dieser Systemfunktion gel¨ost werden muss ist, wie Fließtext in S¨atze geteilt werden kann. Dabei muss auch entschieden werden, wie mit speziellen Formatierungen, wie in Tabelle 5.2 gezeigt, umgegangen wird. Es wurde entscheiden die JAVA Bibliothek BreakIterator2 Zum Teilen von S¨atzen einzusetzen. Diese Bibliothek Fließtexte in S¨atze unter Ber¨ucksichtigung von Satztrennung, Grammatik sowie multipler Satzzeichen wie bspw.

”?!“ und

”...“. Somit hat diese Bibliothek einen großen Vorteil gegen¨uber Methoden wie bspw.String.split().

Des Weiteren wurde entschieden, dass spezielle Formatierungen nicht geteilt werden, um ihren Kontext nicht zu zerst¨oren. Da diese Textbausteine nicht in den Trainingsdaten vorkommen, wird formatierter Text auch von der Klassifikation ausgeschlossen.

2Java Break Iterator: https://docs.oracle.com/javase/7/docs/api/java/text/BreakIterator.html Zuletzt aufgerufen am 17.12.2018

5 Entwurf und Implementierung

Tabelle 5.2: Formatierungsm¨oglichkeiten, die vom Klassifikator nicht ber¨ucksichtigt werden.

Textbaustein Beispiel

Zitat {quote} This is a quote{quote}

Quellcode {code:java}int i = 0; {code}

Logfile {noformat}...some logs...{noformat}

Panel {panel:title=Title}This is a big text{panel}

Die Klasse CommentSplitter sucht in Fließtexten nach speziellen Formatierungen und teilt ein Kommentar in einzelne S¨atze. Die Klasse Sentence persistiert alle S¨atze, und speichert die Start- und Endpositionen des Satzes in einer AO-Tabelle. Die Alternative, den Text eines Satzes ebenfalls in einer AO-Tabelle zu speichern, stellt eine Redundanz gegen¨uber der JIRA-Persistierung von Kommentaren dar.

Nach der Satzteilung durch die KlasseCommentSplitter, beginnt die Textklassifikation. Abbil-dung 5.5 zeigt diesen Prozess. Der bin¨arer Klassifikator pr¨uft, ob ein Satz relevantes Wissen f¨ur ein Entscheidungsproblem besitzt. Die KlasseDecisionKnowledgeClassifier klassifiziert die S¨atze in die Klassenrelevant undirrelevant. Anschließend klassifiziert der feingranulare Klas-sifikator den Wissenstyp relevanter S¨atze. Die verf¨ugbaren Wissenstypen orientieren sich am IBIS Model (Abschnitt 2.2, Seite 6).

Satz Bin¨ ar

Feingranular

Pro Con Alternative

Issue Decision

relevant nicht relevant

Abbildung 5.5: Prozessbaum im Klassifikationsprozess von S¨atzen

F¨ur die Implementierung des Klassifikators wird die Bibliothek Weka (Kapitel 2.4, Seite 2.4) genutzt. Um Texte zu klassifizieren, m¨ussen diese initial gefiltert werden. Dabei stehen in WE-KA mehrere Techniken zur Verf¨ugung: Term Frequency & Inverse Term Frequency (TF-IDF) errechnet die Relevanz eines Terms3gegen¨uber einem Dokument. Gleichung 5.1 beschreibt die Berechnung der Term Frequency f¨ur einen Termiin einem Dokumentj, wobeink,j die Anzahl der Dokumente bezeichnet die den Termj beinhalten.

Anschließend wird die inverse term frequency in Gleichung 5.2 berechnet. Dabei bezeichnet i den jeweiligen Term unddoci die Dokumente in denen der Termi vorkommt. Die Anwendung von TF-IDF resultiert in einer Tabelle von allen enthaltenen W¨ortern, sowie aus dem Produkt von TF und IDF f¨ur jeden Term.

tfi,j °ni,j

knk,j (5.1) idfi logp n

doci

q (5.2)

Die Anwendung der Methode toLowerCase vollzieht die Transformation aller Terme in Klein-buchstaben. Die MethodeNGramTokenizing bezeichnet die Anwendung von TF-IDF auf Wort-sequenzen mit einer L¨ange von n.

3Term: Hier: Ein Wort, mehrere W¨orter oder ein Satz

38

5.3 Entwurfsentscheidungen zu Systemfunktionen

Der bin¨are Klassifikator nutzt die WEKA-KlasseFilteredClassifier. Diese kombiniert einen Fil-ter mit einem beliebigen Klassifikationsalgorithmus. Die FilFil-terklasseStringToWordVector nutzt die beschriebenen Filter und erzeugt Vektoren von Termen mit ihrer Relevanz im gew¨ahlten Dokument4. Experimente mit verschiedenen Klassifikationsalgorithmen zeigen, das Sequential Minimal Optimization (SMO) die besten Ergebnisse liefert. Tabelle 5.3 enth¨alt die Ergebnisse des Trainingsprozess.

Tabelle 5.3: Trainingsmetriken verschiedener Klassifikationsalgorithmen zur bin¨aren Textklas-sifikation

Algorithmus Precision Recall F1-Score

SMO 0,861 0,864 0,862

SGD 0,859 0,861 0,860

Der feingranulare Klassifikator nutzt die KlasseLC5 als Klassifikator. Zus¨atzlich wird erneut die KlasseFilteredClassifiermit den beschriebenen Textfiltern eingesetzt. Tabelle 5.4 beschreibt gerundete Metriken f¨ur getestete Klassifikationsalgorithmen. Aufgrund der guten Ergebnisse und der schnellen Laufzeit wird der Na¨ıveBayes Multinomial (NBM) Algorithmus eingesetzt [13].

Tabelle 5.4: Testmetriken feingranularer Klassifikationalgorithmen zur feingranularen Textklassifikation

Algorithmus Alternative Issue Decision Pro Con

Metrik P R F1 P R F1 P R F1 P R F1 P R F1

NBM 0,6 0,8 0,7 0,4 0,3 0,3 0,7 0,7 0,7 0,5 0,7 0,6 0,3 0,5 0,4 SMO 0,7 0,7 0,7 0,4 0,3 0,3 0,8 0,7 0,8 0,7 0,6 0,6 0,4 0,4 0,4 SGD 0,7 0,7 0,7 0,3 0,4 0,4 0,6 0,7 0,7 0,6 0,6 0,6 0,4 0,4 0,4 J48 0,7 0,7 0,7 0,4 0,1 0,2 0,8 0,6 0,7 0,6 0,5 0,5 0,5 0,3 0,3

Aufgrund der beschr¨ankten Menge an Testdaten (Tabelle 2.6) wird die Trainingsmethodecross validation eingesetzt [15]. Diese Methode ist n¨utzlich, wenn Test und Evaluationsdaten in ge-ringer Menge vorliegen oder sehr verschieden sind. Zuerst wird die Anzahl der Validierungs-durchl¨aufe mitndefiniert. Anschließend wird der vorliegende Datensatz inngleichgroße Teile geteilt. Teilmenge 1 bisn1 stellen nun Trainingsdaten dar, Teilmengendie Evaluationsdaten.

Iterativ wird jede Teilmenge einmal vom Trainingsdatensatz ausgeschlossen und zur Evaluation des trainierten Modells verwendet. Anschließend wird das Modell mit den besten Ergebnissen ausgew¨ahlt.

Die Klassifikation wird ebenfalls in der AO-Tabelle gespeichert. Abschließend wird der klassifi-zierte Text im JIRA-Issue-Kommentar mit Tags (entsprechend Systemfunktion 3) markiert.

Zus¨atzlich wurde Ansicht WS1.2 Single Project Admin View um einen Schalter erweitert, der die automatische Klassifizierung erm¨oglicht oder unterdr¨uckt. Die Systemfunktion pr¨uft diese Einstellung vor jeder Ausf¨uhrung des Klassifikators.

5 Entwurf und Implementierung

Tabelle 5.5: Entscheidungsprobleme zu Systemfunktion 2

Entscheidungsproblem Entscheidung

Darf ein Satz mehr als einen Wissenstyp an-nehmen?

Nein, da inkonsistent zu ConDec.

Wie kann Fließtext in einzelne S¨atze geteilt werden?

Die BreakIterator Bibliothek trennt Fließ-texte mit R¨ucksicht auf Grammatik und Satzzeichen.

Sollen speziell formatierte Testbausteine in einzelne S¨atze geteilt werden?

Nein, da dies sonst den Kontext und die Aus-sage des Testbausteine zerst¨ort.

Soll die NutzerIn entscheiden k¨onnen, ob sie die automatische Klassifikation benutzen m¨ochte?

Ja, mit einem Schalter in Ansicht WS1.2, da die permanente automatische Klassifizierung st¨orend wirken kann.

Welche Trainingsmethode soll eingesetzt werden?

Training mit Cross Validation.

Welcher Klassifizierungsalgorithmus soll ein-gesetzt werden?

SGD (Bin¨ar) & NBM (Feingranular), auf-grund der (im Vergleich) besten Ergebnisse.

!interface"

Comment

CommentImpl sentences: List Sentence¡

body: String jiraCommentId: long authorFullName: String authorId: long created: Date projectKey: String splitter: CommentSplitter issueId: long

-splitCommentsIntoSentences() -runBreakIterator(sentences: List Sentences¡)

ClassificationManagerForCommentSentences classifier: DecisionKnowledgeClassifier +classifySentencesBinary(comments: List Comment¡) +classifySentenceFineGrained(comments: List Comment¡)

DecisionKnowledgeClassifier

+DecisionKnowledgeClassifier()

+makeBinaryPredictions(data: Instances): List double¡ +makeFineGrainedPredictions(data: Instances): List double[]¡

CommentSplitter startSubstringCount:List Integer¡

endSubstringCount:List Integer¡

+CommentSplitter() +splitSentence(body: String)

+sliceCommentRecursionCommander(body:String, projectKey: String) -searchForTags(split: List String¡,openTag: String, closeTag: String) -searchForTagsRecursive(toSearch: String, openTag: String,

closeTag: String, slices: List String¡

!interface"

Sentence

SentenceImpl isTagged: boolean isRelevant: boolean startSubstringCount: int endSubstringCount: int isTaggedManually: boolean isTaggedFineGrained: boolean argument: String isPlainText: Boolean commentId: long userId: long knowledgeTypeString: String issueId: long -checkForPlainText() -stripTagsFromBody() -retrieveBodyFromJIRAComment()

DecisionKnowledgeElementImpl id: long

summary: String description: String type: KnowledgeType project: DecisionKnowledgeProject key: String

documentationLocation: DocumentationLocation + DecisionKnowledgeElementImpl()

+ DecisionKnowledgeElementImpl(id: long, summary: String, description: String, type: KnowledgeType, projectKey: String, key: String)

+ DecisionKnowledgeElementImpl(issue: Issue) + getLinkedElements(): List¡DecisionKnowledgeElement¿

DecXtractEventListener eventPublisher: EventPublisher projectKey:String issueEvent: IssueEvent +onIssueEvent(issueEvent: IssueEvent)

!interface"

DecisionKnowledgeElement

!enum"

KnowledgeType ALTERNATIVE

ASSUMPTION ASSESSMENT ARGUMENT CLAIM CONTEXT CONSTRAINT DECISION GOAL ISSUE IMPLICATION PROBLEM QUESTION RATIONALE SOLUTION OTHER

+ getDefaultTypes(): Set¡ nowledgeType¡ + getKnowledgeType(type: String): KnowledgeType + getSuperType(type: KnowledgeType): KnowledgeType + getSuperType(): KnowledgeType

+ toString(): String + toList(): List String¡

Abbildung 5.6: Klassendiagramm zu allen relevanten Klassen f¨ur Systemfunktion 2

40

5.3 Entwurfsentscheidungen zu Systemfunktionen

5.3.3 Entscheidungswissen in JIRA-Issue-Kommentaren manuell