DE102015121509A1

DE102015121509A1 - Methodik und Vorrichtung zur Konsistenzprüfung durch Vergleich von Ontologiemodellen

Info

Publication number: DE102015121509A1
Application number: DE102015121509.8A
Authority: DE
Inventors: Dnyanesh Rajpathak; Ramesh Sethu; Prakash M. Peranandam
Original assignee: GM Global Technology Operations LLC
Current assignee: GM Global Technology Operations LLC
Priority date: 2014-12-18
Filing date: 2015-12-10
Publication date: 2016-06-23
Also published as: CN105718256A; US20160179868A1

Abstract

Es wird ein Verfahren zum Erzeugen von Ontologiemodellen aus Anforderungsdokumenten und Software und Durchführen von Konsistenzprüfungen zwischen Anforderungsdokumenten und Softwarecode unter Verwendung von Ontologiemodellen bereitgestellt. In der Vielzahl von Anforderungsdokumenten, die aus einer Datenbank erhalten werden, werden Terme identifiziert. Ein Prozessor ordnet jedem Term ein Wortart-Tag zu. Das Wortart-Tag gibt eine grammatikalische Verwendung jedes Terms in den Anforderungsdokumenten an. Der Prozessor klassifiziert jeden Term auf der Grundlage der Wortart-Tags. Die Klassifizierung identifiziert, ob jeder Term ein Teil, ein Symptom, eine Aktion, ein Ereignis oder ein Fehlermodus ist, um eine Ontologie zu bilden. Der Prozessor konstruiert eine ontologiebasierte Konsistenzmaschine als Funktion der Ontologien. Eine Konsistenzprüfung wird durch Anwenden der ontologiebasierten Konsistenzmaschine zwischen Ontologien, die aus zwei Kontextdokumenten extrahiert werden, durchgeführt. Es werden inkonsistente Terme zwischen den Kontextdokumenten identifiziert. Es wird zumindest eines der Kontextdokumente mit inkonsistenten Termen korrigiert.

Description

HINTERGRUND DER ERFINDUNG
Eine Ausführungsform bezieht sich allgemein auf Anforderungsdokument- und Softwarecode-Konsistenzprüfungen in Bezug auf die Verwendung von Ontologiemodellen, die aus Anforderungsdokumenten und Softwarecode konstruiert werden.
In einem Systementwicklungsprozess stellen Anforderungsdokumente eine notwendige Information über die Funktionalitäten, die eine Software für die erfolgreiche Funktion eines Systems bereitstellen muss, bereit. Anforderungen werden in der Regel in freier englischer Sprache erfasst, und die daraus resultierenden Anforderungsdokumente verteilen sich über Hunderte von Seiten. Eine Vielzahl von funktionalen Anforderungen kann einige überlappende Funktionalitäten sowie Unterfunktionalitäten aufweisen. Als Ergebnis können Inkonsistenzen bei den ähnlichen Funktionen Störungen der Software verursachen, die entweder Fehler verursachen oder zu diesen führen. Typischerweise überprüft ein Experte auf dem Gebiet SME das Anforderungsdokument, um die Inkonsistenz und Korrektheit von Problemen zu identifizieren und sie zu bereinigen, um die Konsistenz der Anforderungsdokumente sowie den Softwarecode zu verbessern. Ferner kann, wenn ein Fehler in dem Bereich einer spezifischen Entität (z. B. Fahrzeug) beobachtet wird, die Grundursache eines solchen Fehlers auch zurückverfolgt werden, entweder zu dessen Anforderungsdokument oder zu der Software, die in den in einem Fahrzeug installierten Modulen ausgeführt wird. Angesichts der Länge eines Anforderungsdokuments und der Anzahl von Softwarealgorithmen, die den Anforderungen zugehörig sind, ist die Aufgabe eines manuellen Koppelns geeigneter Anforderungen in einem mentalen Modell eine nicht triviale, zeitaufwendige und störungsanfällige Tätigkeit.
ZUSAMMENFASSUNG DER ERFINDUNG
Ein Vorteil einer Ausführungsform ist die Identifizierung von Inkonsistenzen zwischen Anforderungsdokumenten und zwischen Anforderungen und Softwarecode, was eine Fehlerverfolgbarkeit zwischen verschiedenen Teilsystemen ermöglicht. Die Erfindung ermöglicht auch das Verfolgen der Fehler, die bei Fahrzeugen beobachtet werden, zu ihren Anforderungsdokumenten oder zu der Software, die in den Modulen installiert ist, die Teil der Fahrzeuganordnung sind. Die hierin beschriebenen Ausführungsformen verwenden einen Vergleich extrahierter Ontologien von sowohl Anforderungsdokumenten als auch Softwarecode und von den Daten, die zusammengetragen werden, wenn die Fehler in dem Bereich beobachtet werden, um Inkonsistenzen zu identifizieren. Die hierin beschriebenen Ausführungsformen können große Mengen von Daten, die aus verschiedenen heterogenen Quellen erhalten werden, handhaben sowie Grundursachen auf einer Anforderungsdokumentebene und Softwarecodeebene ermitteln, was die Produktqualität verbessert, indem Garantiekosten minimiert werden.
Eine Ausführungsform zieht ein Verfahren zum Anwenden von Konsistenzprüfungen unter Anforderungsdokumenten und Softwarecode in Betracht. Es werden Terme in der Vielzahl von Anforderungsdokumenten, die aus einer Datenbank erhalten werden, identifiziert. Ein Prozessor ordnet jedem Term ein Wortart-Tag zu. Das Wortart-Tag gibt eine grammatikalische Verwendung jedes Terms in den Anforderungsdokumenten an. Der Prozessor klassifiziert jeden Term auf der Grundlage der Wortart-Tags. Die Klassifizierung identifiziert, ob jeder Term ein Teilterm, ein Symptomterm, ein Aktionsterm, ein Ereignisterm oder ein Fehlermodusterm ist. Der Prozessor konstruiert eine ontologiebasierte Konsistenzmaschine als Funktion der klassifizierten Terme. Eine Konsistenzprüfung wird durch Anwenden der ontologiebasierten Konsistenzmaschine zwischen Ontologien, die aus zwei Kontextdokumenten extrahiert werden, durchgeführt. Es werden inkonsistente Terme zwischen den Kontextdokumenten identifiziert. Es wird zumindest eines der Kontextdokumente mit inkonsistenten Termen korrigiert.
KURZBESCHREIBUNG DER ZEICHNUNGEN
1 ist ein Blockdiagramm einer Konsistenzprüfungsanforderungstechnik eines allgemeinen Flussprozesses.
2 ist ein Blockdiagramm der Gesamtmethodik der Anforderungskopplungstechnik.
3 ist ein Flussdiagramm zum Identifizieren kritischer n-Gramme.
4 ist ein beispielhafter POS-Tagging-Prozess unter Verwendung der kritischen N-Gramme.
5 ist ein Flussdiagramm für eine beispielhafte Wahrscheinlichkeitsschätzung für ein POS-Tagging.
6 ist ein Flussdiagramm, um Wahrscheinlichkeiten mit einer Kontextinformation in Verbindung zu bringen.
7 veranschaulicht die Verwendung einer Trainingstabelle mit Testdaten.
8 veranschaulicht eine beispielhafte ontologiebasierte Konsistenzprüfungsmaschine.
9 veranschaulicht ein Flussdiagramm für ein Verfahren zur Ontologieentwicklung.
10 veranschaulicht eine beispielhafte bereichsspezifische Ontologie.
11 veranschaulicht eine beispielhafte Instanz der Ontologie.
DETAILLIERTE BESCHREIBUNG
1 veranschaulicht ein Blockdiagramm 10 eines allgemeinen Flussprozesses einer ontologiebasierten Konsistenzmaschine. Während die hierin beschriebene Ausführungsform ein fahrzeugbasiertes System ist, ist zu verstehen, dass das System auf verschiedene andere Systeme, die Flugzeug- oder andere nicht auf Fahrzeugen basierende Systeme umfassen, angewandt werden kann. Die ontologiebasierte Konsistenzmaschine verwendet eine(n) oder mehrere Prozessoren, Speicher, wie beispielsweise eine Speichereinrichtung, Datenbanken und Ausgabeeinrichtungen zum Ausgeben von Ergebnissen von Konsistenzprüfungen. Ferner können der Prozessor oder eine andere Verarbeitungseinheit eine autonome Korrektur der Kontextdokumente mit inkonsistenten Termen durchführen. In Kasten 11 werden Anforderungsdokumente, die eine Vielzahl von Anforderungen umfassen, erhalten. Es wird eine jeweilige Anforderung von den Anforderungsdokumenten ausgewählt. Eine Anforderung ist eine Beschreibung bezüglich eines Teils, eines Systems oder einer Software, die Details in Bezug auf die Funktionalität und Betriebsanforderungen des Teils, des Systems oder der Software bereitstellt.
In Kasten 12 werden Stoppwörter in der Anforderung gelöscht. Stoppwörter fügen unnötiges Rauschen in den Daten hinzu, während eine Verarbeitung natürlicher Sprache der Daten durchgeführt wird. Stoppwörter bestehen aus ”ein”, ”eine”, ”der/die/das”, ”wer”, ”www”, ”weil” und ”wird”, die als nicht beschreibend betrachtet werden, sind jedoch nicht darauf beschränkt. Eine Stoppwortliste kann in einem Speicher 13, wie beispielsweise einem Speicher eines Servers, einer Datenbank, einer Vergleichsdatenbank oder einer anderen entsprechenden Datenbank oder einem anderen entsprechenden Speicher gespeichert sein. Stoppwörter, die in der aus dem Speicher 13 erhaltenen Stoppwortliste identifiziert werden und Teil der extrahierten Information in den Anforderungen sind, werden entfernt. Stoppwörter, die Teil kritischer Terme sind, werden beibehalten, und nur jeweilige Stoppwörter, die nicht Teil der kritischen Terme sind, werden gelöscht, um die richtige Bedeutung von Dokumenten zu erhalten.
In Kasten 14 wird eine Wortart-(POS- von parts-of-speech-) und n-Gramm-Konstruktion auf die verbleibenden extrahierten Terme oder Phrasen, die von Kasten 12 ausgegeben werden, angewandt, was in 2 ausführlich dargestellt ist.
In Kasten 15 werden die Positionen der n-Gramme in den Daten ermittelt, was in 3 ausführlich gezeigt ist.
In Kasten 16 werden unterschiedliche und gemeinsame POS-Tags von kritischen Termen identifiziert, was in 4 und 5 ausführlich gezeigt ist.
In Kasten 17 fährt die Routine, wenn ein POS-Tag gemeinsam ist, mit Kasten 18 fort; andernfalls fährt die Routine mit Kasten 20 fort.
In Kasten 18 wird eine lexikographische beidseitige Information geschätzt.
In Kasten 19 werden Kontextwahrscheinlichkeiten basierend auf einem Naïve Bayes-Klassifizierer geschätzt.
In Kasten 20 werden die Terme als Teil-, Symptom-, Ereignis-, Fehlermodus- oder Aktionsterm klassifiziert, um die Ontologievergleichsmaschine zu konstruieren.
In Kasten 21 werden Anforderungsteilsysteme erzeugt und identifiziert. In Kasten 22 wird eine Ontologievergleichsmaschine erzeugt und verwendet, um eine Konsistenzprüfung zwischen den jeweiligen Anforderungsteilsystemen durchzuführen. Die Konsistenzprüfung kann zwischen zwei oder mehr Anforderungsdokumenten, Anforderungsdokumenten und Softwarecode, zwischen Softwarecode von verschiedenen Teilsystemen und zum Detektieren einer Fehlerverfolgbarkeit zwischen Softwarecodes angewandt werden.
2 veranschaulicht einen Wortart-Tagger, bei dem Wortdaten in den Anforderungsdokumenten getaggt werden. Wie es in 2 gezeigt ist, werden Wortarten mit einem jeweiligen Identifikator getaggt, wobei Phrasen, wie beispielsweise ”are”, ”see”, ”24HR”, ”purge”, ”evap”, ”selenoid”, die folgenden POS-Tags zugeordnet werden: ”are/VBP”, see/VB”, ”24HR/JJ” ”purge/NNP, ”evap/NNP” und ”solenoid/NNP”.
Ein POS-Tagging-Modul wird verwendet, um Tags auf die Terme anzuwenden. Beispiele für solche Tags sind in dem Penn Treebank Project (http://www.ling.upenn.edu/courses/Fall_2007/ling001/penn_treebank_pos.html) zu finden, sind jedoch nicht darauf beschränkt. Tags können CC (nebenordnende Konjunktion), CD (Grundzahl), JJ (Adjektiv), JJR (Adjektiv komparativ), NN (Nomen, singular oder Stoffname), NNS (Nomen plural), NNP (Eigenname singular), NNPS (Eigenname plural), RB (Adverb), RBR (Adverb komparativ), RBS (Adverb superlativ), VB (Verb, Grundform), VBD (Verb Präteritum), VBD (Verb, Partizip Präsens), VBN (Verb, Partizip Perfekt), VBP (Verb, nicht 3. Person singular Präsens), VBZ (Verb, 3. Person singular Präsens) umfassen, sind jedoch nicht darauf beschränkt. Es ist zu verstehen, dass die POS-Tags hierin beispielhaft sind und dass verschiedene POS-Identifikatoren verwendet werden können.
Es werden der extrahierten Phrase zugehörige n-Gramme identifiziert. Der Begriff ”Gramm” bezieht sich auf den Term oder die Terme der Phrase als Ganzes, und ”n” bezieht sich auf eine Anzahl von Termen, die der Phrase zugehörig sind.
3 ist eine beispielhafte Darstellung einer n-Gramm-Tabelle. Aus jedem Anforderungsdokument werden die folgenden Typen von n-Grammen konstruiert: Unigramme, die Phrasen mit einem einzigen Wort (z. B. battery, transmission) umfassen; Bigramme, die Phrasen mit zwei Wörtern (z. B. battery dead) umfassen; Trigramme, die Phrasen mit drei Wörtern (z. B. body control module, instrument panel cluster, powertrain control module) umfassen; Tetragramme, die Phrasen mit vier Wörtern (z. B. body control module inoperative, transmission control module assembly) umfassen, und Pentagramme, die Phrasen mit fünf Wörtern (z. B. transmission control module assembly failed) umfassen. Der Grund, dass möglicherweise ein n-Gramm, das fünf Wörter lang ist, verwendet wird, ist in einigen Fällen auf eine kritische Natur einer Phrase zurückzuführen, die fünf Wörter enthält, wie z. B. Fuel Tank Pressure Sensor Module. Zum Beispiel können kritische Terme, die die Namen von Teilen, Symptomen, Ereignissen, Aktionen und Fehlermodi umfassen, fünf Wörter lang sein.
Die n-Gramme werden konstruiert und verwendet, wenn die verwendete Technik keine bereichsspezifische Ontologie (d. h. Taxonomie) verwendet, die eine Herkunft oder Datenbank von Termen bereitstellen würde, um kritische Terme aus jedem Anforderungsdokument zu identifizieren. Als Ergebnis kann ein Ansatz einer Verarbeitung natürlicher Sprache (NLP von natural language processing) verwendet werden, bei dem die in dieser Stufe der Technik konstruierten n-Gramme anschließend mit ihrer Wortart getaggt werden, um die korrekte Klassifizierung von Termen zu identifizieren.
4 veranschaulicht eine Tabelle, in der Positionen von n-Grammen in den Daten identifiziert werden. Es werden die Start- und Endposition von Phrasen für ihre POS-Tags identifiziert, um ihre Wortlänge zu ermitteln. Wie es nachstehend gezeigt ist, wird auf beiden Seiten eines jeweiligen n-Gramms ein Wortfenster von drei Wörtern vorgesehen. Das Wortfenster ist eine Variable, die basierend auf der Art des Dokuments festgelegt werden soll. XXXXT₁XX[T₂xx^StartIndex{Phrase_i}^EndindexT₃XT₄]XXX Kontextinformation auf der linken Seite = (Phrase_i T₂)
Kontextinformation auf der rechten Seite = ((Phrase_i T₃), (Phrase_i, T₄))
Die Terme, die zusammen mit einem n-Gramm in dem Wortfenster auftreten, werden als Kontextinformation zusammengetragen. Dies hilft dabei, gemeinsame Phrasen und kritische Phrasen zu identifizieren.
5 veranschaulicht Tabellen, die identifizieren, wenn gemeinsame und unterschiedliche POS-Tags Phrasen zugehörig sind. Gemeinsame POS-Tags werden identifiziert, indem die einem ersten Teilsystem zugeordnete POS mit einer einem zweiten Teilsystem zugeordneten POS analysiert wird. Die Gruppierung der POS-Tags unterstützt das Identifizieren jener jeweiligen POS-Tags, die zwischen Teilsystemen gemeinsam sind. 6 veranschaulicht eine graphische logische Schnittmenge, auch als logische UND-Verknüpfung bekannt, zwischen den Teilmengen. Wie es in 6 veranschaulicht ist, können jene jeweiligen Phrasen mit gemeinsamen POS-Tags zwischen den beiden Teilsystemen unterschieden werden.
Wenn herausgefunden wird, dass POS-Tags, die den verschiedenen Teilsystemen zugehörig sind, gemeinsam sind, dann wird eine Wahrscheinlichkeitstechnik einer lexikographischen beidseitigen Information (LMI von lexicographic mutual information) angewandt. Die LMI-Wahrscheinlichkeitstechnik unterstützt das Ermitteln, in welche Klassifizierung der POS-Tag eingeordnet werden sollte. Zum Beispiel tritt die folgende Phrase: ”shall not be activated” bei sowohl Symptom- als auch Fehlermodusphrasen auf: ”MD RB VB VBN”. Die LMI-Wahrscheinlichkeit der folgenden Phrasen für eine potentielle Klassifizierung wird ermittelt: P(shall not be activated_sy|MD RB VB VBN) und P(shall not be activated_FM|MF RB VB VBN) werden ermittelt.
Die LIM für jede jeweilige Phrase wird unter Verwendung der folgenden Formeln ermittelt:
Wenn die jeweiligen Wahrscheinlichkeiten ermittelt sind, erfolgt ein Vergleich der Wahrscheinlichkeit von Ngram_i, tag_i, beobachtet zusammen mit der Wahrscheinlichkeit von Ngram_i, tag_i, unabhängig beobachtet in den Daten, wobei tag_i ∊ (tag_Sy) ∧ (tag_FM). Als Ergebnis wird das jeweilige Tag (tag_FM) oder (tag_Sy) mit der höheren LMI-Wahrscheinlichkeit der Klassifizierung für die jeweilige Phrase zugeordnet.
Zusätzlich kann eine Kontextwahrscheinlichkeit basierend auf einem Naïve Bayes-Modell verwendet werden, die den Kontext erfasst, in dem eine spezifische Phrase spezifiziert wird. Das Naïve Bayes-Modell sagt die Klassenzugehörigkeitswahrscheinlichkeiten voraus. Die folgenden Schritte werden verwendet, um die Kontextwahrscheinlichkeit zu ermitteln:
Schritt 1:

• Es sei T der Satz von getaggten n-Grammen mit einem spezifischen Tag,
in den Trainingsdaten.
• ∃k Klassen, (C₁, C₂, ..., C_k) und mit einem gegebenen Satz von T wird geschätzt, ob T mit einer maximalen A-posteriori-Wahrscheinlichkeit zu einer spezifischen Klasse gehört, d. h.

Schritt 2:
Die Terme, die zusammen mit dem aktuellen getaggten Term auftreten, stellen einen Kontext 'c' gemäß Naïve Bayes hinsichtlich eines Terms bereit, wobei ein aktuelles Tag unabhängig von den Tags ist, die den vorangehenden Termen entsprechen
Schritt 3:
Eine Schätzung einer maximalen Wahrscheinlichkeit wird wie folgt berechnet:
Nachdem die LMI und die Kontextwahrscheinlichkeiten für die gemeinsamen POS-Tags ermittelt wurden, werden die Terme oder Phrasen in ihre jeweiligen Urnen (z. B. Klassen) klassifiziert. Die klassifizierten Urnen können für Konsistenzprüfungen zwischen Anforderungsdokumenten, Softwarecodes oder zwischen Anforderungsdokumenten und Softwarecodes verwendet werden. Ferner können die klassifizierten Urnen in eine Trainingstabelle eingegeben werden, die mit Testdaten verwendet werden kann
7 veranschaulicht die Verwendung der Trainingstabelle zusammenwirkend mit den Testdaten. In Kasten 30 werden Testdaten in die Maschine eingegeben. In Kasten 31 werden in den Testdaten n-Gramme identifiziert, und es werden kritische n-Gramme aus den Testdaten identifiziert.
Die kritischen n-Gramme von Kasten 31 werden zusammenwirkend mit der Trainingstabelle 32 verwendet, um in Kasten 33 n-Gramm-Muster in den Testdaten abzugleichen. Die sich daraus ergebenden Übereinstimmungen werden in Kasten 34 in ihre jeweiligen Urnen klassifiziert.
Ein Experte auf dem Gebiet (SME) analysiert die klassifizierten Urnen in Kasten 35, um zu ermitteln, ob irgendwelche Terme oder Phrasen falsch klassifiziert sind. In Kasten 36 erzeugt der SME überarbeitete Urnen.
In Kasten 37 werden Ontologien aus den jeweiligen klassifizierten Urnen konstruiert. Es kann eine jeweilige Ontologie des Softwarecodes aus den Ergebnissen konstruiert werden, was für Konsistenzprüfungen zwischen Softwarecodes und Anforderungsdokumenten verwendet werden kann. Der Vorteil des Ontologiemodells wie gezeigt gegenüber anderen Typen von Modellerstellung, wie beispielsweise eine Modellerstellung endlicher Zustände (FSM von finite-state-modeling) ist, dass FSM hauptsächlich für eine Prozessflussmodellerstellung vorgesehen ist, während eine Ontologie für die Formalisierung des Bereichs des Diskurses eingesetzt werden kann. Das heißt, die Ontologie unterscheidet zwischen einem Weltbild einer Klassenebene und einer Instanzebene. Folglich erfordert die Ontologie keine vollständige Ansicht des Anwendungsbereichs, während eine Modellerstellungstechnik, wie beispielsweise eine Modellerstellung endlicher Zustände, eine vollständige Information des Anwendungsbereichs erfordert. Es kann auch eine andere Klasse von Anwendungen, die für einen spezifischen Bereich relevant sind, ohne Änderung von Bereichsebenenklassen, sondern nur durch Erfassen neuer Instanzen, die für eine neue Anwendung spezifisch sind, modelliert werden.
8 zeigt eine beispielhafte ontologiebasierte Konsistenzprüfung zwischen verschiedenen Teilsystemen. Die Ontologiemaschine 38 wird auf ein Grundkonzept O_i und ein Grundkonzept O_j angewandt. Die Terme von O_i und O_j werden auf Konsistenz geprüft. Es werden die folgenden Schritte angewandt: 1. IC(c) = log^–1P(c) wobei P(c) eine Wahrscheinlichkeit eines Auftretens einer Instanz eines Konzepts c ist (in einer hierarchischen Struktur ist P(c) monoton.
wobei Sup(c_i, c_j) ein Satz von Konzepten ist, der c_i, c_j zusammenfasst.
Bei Mehrfachvererbungen hinsichtlich Worten werden mehr als eine Ähnlichkeitsbedeutung von direkten Superklassen ermittelt.
wobei Sen(w) den Satz von möglichen Bedeutungen für Wort w bezeichnet.
Die ermittelten Ähnlichkeiten können mit vorbestimmten Ähnlichkeiten verglichen werden, um eine Konsistenz zu ermitteln. Zum Beispiel:
Falls sim(c_i, c_j) ≥ 0,78,
dann wird ermittelt, dass O_i und O_j konsistent miteinander sind.
Falls sim(w₁, w₂) ≥ 0,64,
dann wird ermittelt, dass O_i und O_j konsistent miteinander sind.
9 veranschaulicht ein Flussdiagramm für eine Technik einer Ontologieentwicklung aus Software.
In Kasten 40 wird für jede Methode der Methodenname erhalten.
In Kasten 41 wird ermittelt, ob eine externe Methode verwendet wird. Wenn zum Beispiel eine Methode innerhalb ihrer Ausführung eine andere Methode aufruft, wird der Aufruf einer anderen Methode innerhalb der ursprünglichen Methode als externe Methode bezeichnet. Wenn keine externe Methode verwendet wird, fährt die Routine mit Kasten 43 fort; andernfalls fährt die Routine mit Kasten 42 fort.
In Schritt 42 wird der Name der externen Methode erhalten, und die Routine fährt mit Schritt 43 fort.
In Schritt 43 wird der Rückgabetyp erhalten. Der Begriff des Rückgabetyps spezifiziert hierin den Ausgang, den die Methode nach dem Ausführen der Schritte zurückgibt. In Schritt 44 werden Schleifen und deren Umfang identifiziert. In Schritt 45 werden ”falls”-Parameter und ”erhalte”-Bedingungsparameter identifiziert. In Schritt 46 werden Eingangsvariablen und Variablentypen identifiziert. Die Schritte 43–46 können gleichzeitig oder nacheinander ausgeführt werden. Ferner muss die Reihenfolge, in der die Schritte 43–46 durchgeführt werden, nicht notwendigerweise die hierin beschriebene Reihenfolge sein. In Ansprechen auf das Zusammentragen einer Information und das Identifizieren der Methode fährt die Routine mit Schritt 47 fort.
In Schritt 47 wird eine Methodenhierarchie erhalten.
In Schritt 48 werden Klassennamen identifiziert.
In Schritt 49 werden ein Projektordner und eine Anzahl von Zählwerteinheiten identifiziert. Die Extraktion der Information wird in diesem Schritt angewandt, da der Ordner typischerweise die gesamte Information eines spezifischen Anforderungsmerkmals umfasst, und daher ermöglicht ein Extrahieren einer Ordnerinformation, dass eine relevante Information, die diesem spezifischen Anforderungsmerkmal zugehörig ist, in einer konsistenten Weise erhalten wird.
In Schritt 50 werden Parameter aus dem Softwarecode abgerufen und wird eine Ontologie basierend auf den in den Schritten 40–50 identifizierten Parameteranforderungen konstruiert.
10 veranschaulicht ein Beispiel einer bereichsspezifischen Ontologie, die verwendet werden kann, um kritische Komponenten von Java-Code (z. B. Software) zu erfassen. Die Ontologie zeigt die Klassen und die ”hat-ein(e/n)”-Beziehungen zwischen jeglichen zwei in der Ontologie umfassten Klassen. Grundsätzlich gibt die Ontologie an, dass ein Java-Code eine ”Methode” haben kann, und dass eine ”Methode” einen ”Namen”, eine ”Schleife”, einen ”Eingangsparameter”, ”Falls-Bedingungen”, etc. haben kann.
Wenn ein Vergleich zwischen einem ersten Java-Code und einem zweiten Java-Code durchgeführt wird, muss eine Instanz der Ontologie in Bezug auf den ersten Java-Code und den zweiten Java-Code erzeugt werden, um die beiden Java-Codes zu vergleichen.
11 zeigt eine Instanz der in 10 gezeigten Ontologie. Die Instanz wird basierend auf dem nachstehenden Beispiel-Java-Code erzeugt: Java Code:
Die ”Klasse” definiert eine Struktur, und Instanzen dieser Klasse definieren Objekte in der Klasse. Wie es in 11 gezeigt ist, weist ein Merkmal des Java-Codes ”ExteriorLightSubsystemFeatureRequirement” eine Methode namens ”checkLampActivation” auf, und diese Methode weist zwei jeweilige Eingänge ”vehicleSpeed” und ”lampActivated” auf. Diese Methode weist auch einen Ausgang auf, der mit der Rückgabeanweisung ”lampActivated” bezeichnet ist, und weist auch eine Falls-Bedingung mit einem Vergleichsoperator ”>” auf. Diese Falls-Bedingung weist konsequente Zuordnungsanweisungen auf, die auf der Grundlage eines ”Wahr”- oder ”Falsch”-Werts der Falls-Bedingung zugeordnet werden. Es ist zu verstehen, dass 10 & 11 Beispiele für die bereichsspezifische Ontologie und die resultierende Instanz der Ontologie sind, und dass die hierin beschriebene Erfindung nicht auf die hierin gezeigten Beispiele beschränkt ist.
Fehler in dem Bereich können mit Anforderungsproblemen gekoppelt sein. Ein Verfolgen des Fehlers, wie beispielsweise von Parameterwerten, die in den Anforderungen oder der Software erfasst werden, ist eine Technik zum Identifizieren und Korrigieren des Problems. Ein Verfolgen der Probleme bis zur Anforderungsebene ist in den meisten Fällen erforderlich, da eine Auswirkung einer Korrektur oder von Änderungen an einem anderen Teil des Systems auf der Anforderungsebene im Vergleich zu höheren Ebenen leicht analysiert werden kann.
Eine Fehlerverfolgbarkeit wird durch unabhängiges Testen verschiedener Artefakte und manuelles Abbilden der Ergebnisse verschiedener Artefakte (z. B. Abbilden von Anforderungen und Software) durchgeführt. Die Techniken ermöglichen wie hierin beschrieben eine Fehlerverfolgung in Vorwärtsrichtung, wie beispielsweise ”Anforderungsebene” zu ”Komponentenebene” zu ”Systemebene”, zusätzlich zur Rückwärtsrichtung wie beispielsweise ”Systemebene” zu ”Komponentenebene” zu ”Anforderungsebene”.
Während bestimmte Ausführungsformen der vorliegenden Erfindung ausführlich beschrieben wurden, wird der Fachmann, den diese Erfindung betrifft, verschiedene alternative Entwürfe und Ausführungsformen zum Ausführen der Erfindung, wie sie durch die folgenden Ansprüche definiert ist, erkennen.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Nicht-Patentliteratur

http://www.ling.upenn.edu/courses/Fall_2007/ling001/penn_treebank_pos.html [0027]

Claims

Verfahren zum Durchführen von Konsistenzprüfungen zwischen Anforderungsdokumenten und Softwarecode unter Verwendung von konstruierten Ontologiemodellen, umfassend die Schritte: Identifizieren von Termen in der Vielzahl von Anforderungsdokumenten, die aus einer Datenbank erhalten werden; Zuordnen, durch einen Prozessor, eines Wortart-Tags zu jedem Term, wobei das Wortart-Tag eine grammatikalische Verwendung jedes Terms in den Anforderungsdokumenten angibt; Klassifizieren, durch den Prozessor, jedes Terms basierend auf den Wortart-Tags, wobei die Klassifizierung identifiziert, ob jeder Term ein Teilterm, ein Symptomterm, ein Aktionsterm, ein Ereignisterm oder ein Fehlermodusterm ist; Konstruieren, durch den Prozessor, einer ontologiebasierten Konsistenzmaschine als Funktion der klassifizierten Terme; Durchführen einer Konsistenzprüfung durch Anwenden der ontologiebasierten Konsistenzmaschine zwischen Ontologien, die aus zwei Kontextdokumenten extrahiert werden; Identifizieren inkonsistenter Terme zwischen den Kontextdokumenten; Korrigieren zumindest eines der Kontextdokumente mit inkonsistenten Termen.
Verfahren nach Anspruch 1, ferner umfassend die Schritte des Identifizierens, ob jeder Term ein Teil einer Phrase ist, in Ansprechen auf das Zuordnen eines Wortart-Tags zu jedem Term; und Gruppierens der Phrasen als n-Gramme mit einer gleichen Anzahl von Termen.
Verfahren nach Anspruch 2, ferner umfassend die Schritte des: Identifizierens einer Start- und Endposition von Phrasen auf der Grundlage der POS-Tags, um ihre Wortlänge zu ermitteln.
Verfahren nach Anspruch 3, wobei die lexikographische beidseitige Information für eine erste Phrase und eine zweite Phrase durch die folgende Formel ermittelt wird:
Verfahren nach Anspruch 4, wobei die LMI-Wahrscheinlichkeit, die der ersten Phrase zugehörig ist, mit der LMI-Wahrscheinlichkeit, die der zweiten Phrase zugehörig ist, verglichen wird, und wobei die Klassifizierung, die der jeweiligen LMI mit der höheren Wahrscheinlichkeit zugehörig ist, der ersten Phrase und der zweiten Phrase zugeordnet wird.
Verfahren nach Anspruch 1, wobei die Konsistenzprüfung zwischen den beiden Kontextdokumenten ein erstes Anforderungsdokument und ein zweites Anforderungsdokument umfasst.
Verfahren nach Anspruch 1, wobei die Konsistenzprüfung zwischen den beiden Kontextdokumenten einen ersten Softwarecode und einen zweiten Softwarecode umfasst.
Verfahren nach Anspruch 1, wobei die Konsistenzprüfung zwischen den beiden Kontextdokumenten ein Anforderungsdokument und einen Softwarecode umfasst.
Verfahren nach Anspruch 1, wobei die Konsistenzprüfung durch Finden einer Ähnlichkeit zwischen einem ersten Satz von Konzepttermen und einem zweiten Satz von Konzepttermen ermittelt wird, wobei eine Ähnlichkeit unter Verwendung der folgenden Formeln ermittelt wird: IC(c) = log^–1P(c) wobei P(c) eine Wahrscheinlichkeit eines Auftretens einer Instanz eines Konzepts c ist, und
wobei, wenn sim(c_i, c_j) größer als ein erster vorbestimmter Schwellenwert ist, ermittelt wird, dass der erste und zweite Satz von Konzepten miteinander konsistent sind.
Verfahren nach Anspruch 1, wobei die Konsistenzprüfung durch Finden einer Ähnlichkeit zwischen einem ersten Satz von Konzepttermen und einem zweiten Satz von Konzepttermen ermittelt wird, wenn eine Mehrfachvererbung von Worten verwendet wird, wobei die Ähnlichkeit unter Verwendung der folgenden Formeln ermittelt wird: IC(c) = log^–1P(c) wobei P(c) eine Wahrscheinlichkeit eines Auftretens einer Instanz eines Konzepts c ist,
wobei Sen(w) den Satz von möglichen Bedeutungen für Wort w bezeichnet, wobei, wenn sim(w_i, w_j) größer als ein zweiter vorbestimmter Schwellenwert ist, ermittelt wird, dass der erste und zweite Satz von Konzepten miteinander konsistent sind.