-
TECHNISCHES GEBIET
-
Das allgemeine technische Gebiet umfasst die Softwareentwicklung und spezieller Systeme und Verfahren zum Erzeugen von Softwaremerkmalanforderungen.
-
HINTERGRUND
-
Der Prozess des Erzeugens von Softwaremerkmalanforderungen umfasst das Hernehmen von Anforderungen in natürlicher Sprache und das Umwandeln dieser in formale ausführbare Anforderungen. Die Umwandlung von Anforderungen in natürlicher Sprache in formale ausführbare Anforderungen kann subjektiv sein und einen Informationsverlust umfassen. Die Analyse, die derzeit verwendet wird, um den Prozess objektiver zu machen und die Information aufrechtzuerhalten, ist zeitintensiv. Beispielsweise umfasst solch eine Analyse eine manuelle Überprüfung von Anforderungen und ist sie auf mentale Modelle eingeschränkt.
-
ZUSAMMENFASSUNG
-
Die verschiedenen Ausführungsformen beseitigen die Nachteile des Stands der Technik, indem Systeme und Verfahren zum Erzeugen von Softwaremerkmalanforderungen bereitgestellt werden, die Anforderungen in natürlicher Sprache inkrementell und nachvollziehbar in formale ausführbare Anforderungen umwandeln. Die Systeme und Verfahren umfassen ein Dokument mit mit Anmerkungen versehenen Anforderungen, das eine informalen Anforderungen zugehörige Merkmalsinformation erfasst und das Erzeugen von Artefakten ermöglicht, um eine Überprüfung und ein frühes Verständnis eines Anforderungsverhaltens auf verschiedenen Abstraktionsebenen zu unterstützen. Die Systeme und Verfahren wandeln Anforderungen in natürlicher Sprache unter Verwendung eines iterativen und graduellen Prozesses in formale ausführbare Anforderungen um. Somit halten die Systeme und Verfahren die Information in den Anforderungen in natürlicher Sprache und wandeln sie die Anforderungen auf eine objektive Weise um.
-
Beispielsweise können die hierin beschriebenen Systeme und Verfahren verwendet werden, um in ein Fahrzeug eingebettete Steuersoftwaremerkmale, wie beispielsweise eine Software eines adaptiven Tempomaten und Ähnliches, zu erzeugen. Gemäß einer beispielhaften Ausführungsform umfassen Systeme und Verfahren zum Erzeugen formaler Softwareanforderungen aus einem Dokument informaler Anforderungen, dass Anmerkungen mit den informalen Anforderungen in Verbindung gebracht werden, eine Syntax aus den Anmerkungen extrahiert wird und Artefakte als Funktion der Syntax erzeugt werden.
-
Vorstehend wurden einige der Aspekte und Merkmale der verschiedenen Ausführungsformen allgemein dargestellt, welche als lediglich verschiedene mögliche Anwendungen erläuternd betrachtet werden sollten. Andere vorteilhafte Resultate können durch Anwenden der offenbarten Information auf eine andere Weise oder durch Kombinieren verschiedener Aspekte der offenbarten Ausführungsformen erhalten werden. Andere Aspekte und ein umfangreicheres Verständnis können durch Bezugnahme auf die detaillierte Beschreibung der beispielhaften Ausführungsformen in Verbindung mit den begleitenden Zeichnungen, zusätzlich zu dem in den Ansprüchen definierten Schutzumfang, erhalten werden.
-
BESCHREIBUNG DER ZEICHNUNGEN
-
1 ist eine schematische Ansicht eines Anforderungsanalysesystems.
-
2 ist eine schematische Ansicht eines Prozesses zum Umwandeln informaler Anforderungen in formale ausführbare Anforderungen.
-
3 ist eine schematische Ansicht eines Dokuments mit mit Anmerkungen versehenen Anforderungen.
-
4 ist eine schematische Ansicht eines ersten beispielhaften Artefakts.
-
5 ist eine schematische Ansicht eines zweiten beispielhaften Artefakts.
-
6 ist eine schematische Ansicht eines dritten beispielhaften Artefakts.
-
7 ist eine schematische Ansicht eines vierten beispielhaften Artefakts.
-
8 ist ein Flussdiagramm, das ein beispielhaftes Verfahren unter Verwendung des Anforderungsanalysesystems von 1 darstellt.
-
DETAILLIERTE BESCHREIBUNG
-
Wie erforderlich sind hierin detaillierte Ausführungsformen offenbart. Es ist zu verstehen, dass die offenbarten Ausführungsformen lediglich beispielhaft sind und in verschiedenen und alternativen Formen und Kombinationen hiervon ausgeführt werden können. Wie hierin verwendet wird das Wort ”beispielhaft” ausdehnend verwendet, um sich auf Ausführungsformen zu beziehen, die als Darstellungen, Exemplare, Modelle oder Muster dienen. Die Figuren sind nicht notwendigerweise maßstabsgetreu, und einige Merkmale können übertrieben oder minimiert sein, um Details bestimmter Komponenten zu zeigen. In anderen Fällen wurden weithin bekannte Komponenten, Systeme, Materialien oder Verfahren, die Fachleuten bekannt sind, nicht ausführlich beschrieben, um ein Verschleiern der vorliegenden Offenbarung zu vermeiden. Daher sollen hierin offenbarte spezifische konstruktive und funktionale Details nicht als einschränkend, sondern lediglich als Basis für die Ansprüche und als repräsentative Basis, um einen Fachmann zu unterrichten, interpretiert werden.
-
SYSTEM
-
Bezug nehmend auf 1 umfasst ein Anforderungsanalysesystem 100 eine zentrale Verarbeitungseinheit (CPU von central processing unit) 110. Die CPU 110 umfasst einen Prozessor 120, einen Speicher 122 oder andere konkrete, nicht transiente von einem Computer lesbare Medien und Softwareanwendungen 124, 125, 126, 127, 128, 129, die von einem Computer ausführbare Anweisungen umfassen. Die Softwareanwendungen 124, 125, 126, 127, 128, 129 sind in dem Speicher 122 gespeichert. Jede Softwareanwendung 124, 125, 126, 127, 128, 129 kann zumindest eine konkrete nicht transiente Hardwarekomponente umfassen.
-
Während die hierin beschriebenen Verfahren teilweise in einem allgemeinen Kontext von von einem Computer ausführbaren Anweisungen beschrieben sein können, können die Verfahren der vorliegenden Offenbarung auch in Kombination mit anderen Anwendungen und/oder als Kombination von Hardware und Software realisiert sein. Der Begriff Anwendung, oder Varianten hiervon, wird hierin ausdehnend verwendet, um Routinen, Programmmodule, Programme, Komponenten, Datenstrukturen, Algorithmen und Ähnliches zu umfassen. Anwendungen können an verschiedenen Systemkonfigurationen realisiert sein, die Server, Netzsysteme, Einzelprozessor- oder Multiprozessorsysteme, Minicomputer, Zentralrechner, Personalcomputer, in der Hand gehaltene Recheneinrichtungen, mobile Einrichtungen, mikroprozessorbasierte programmierbare Unterhaltungselektronik, Kombinationen hiervon und dergleichen umfassen.
-
Von einem Computer lesbare Medien umfassen beispielsweise flüchtige Medien, nichtflüchtige Medien, entfernbare Medien und nicht entfernbare Medien. Der Begriff von einem Computer lesbare Medien und Varianten hiervon bezieht sich, wie in der Beschreibung und den Ansprüchen verwendet, auf konkrete nicht transiente Speichermedien. Bei einigen Ausführungsformen umfassen Speichermedien flüchtige und/oder nichtflüchtige, entfernbare und/oder nicht entfernbare Medien, wie beispielsweise einen Direktzugriffsspeicher (RAM von random access memory), einen Nur-Lese-Speicher (ROM von read-only memory), einen elektrisch löschbaren programmierbaren Nur-Lese-Speicher (EEPROM von electrically erasable programmable read-only memory), einen Festkörperspeicher oder eine andere Speichertechnologie, CD ROM, DVD, BLU-RAY oder einen anderen optischen Plattenspeicher, ein Magnetband, einen Magnetplattenspeicher oder andere Magnetspeichereinrichtungen.
-
Zu Erläuterungszwecken ist das Anforderungsanalysesystem 100 primär als einzelne CPU mit mehreren Anwendungen gezeigt und beschrieben. Bei alternativen Ausführungsformen kann ein Anforderungsanalysesystem jedoch mehrere unabhängige CPUs mit Softwareanwendungen umfassen, die zusammen arbeiten, um die hierin nachstehend ausführlicher beschriebenen Verfahren zu erreichen.
-
ANWENDUNGEN
-
Nun auf 1, 2 und 3 Bezug nehmend ist eine Anwendung 124 eines Dokuments mit mit Anmerkungen versehenen Anforderungen (1) ausgestaltet, um, wenn sie durch den Prozessor 120 ausgeführt wird, zu bewirken, dass der Prozessor das Erzeugen eines Anforderungsdokuments 130 (2) ermöglicht, das einen Satz von informalen Anforderungen 132 umfasst. Im Allgemeinen sind die informalen Anforderungen 132 funktionale Anforderungen eines Merkmals, die bestimmte Aktionen oder Ergebnisse eines Softwaresystems in natürlicher Sprache oder ähnlichem spezifizieren. Beispielhafte Merkmale umfassen eine Fahrerassistenz, wie beispielsweise einen adaptiven Tempomaten, eine fahrzeuginterne Navigation, eine Spurwechselassistenz und eine Kollisionsvermeidung.
-
Zu Erläuterungszwecken werden die informalen Anforderungen 132 in Bezug auf 2 durch eine Konstruktionsgruppe 140 entwickelt, um eine Softwaregruppe 142 beim Entwickeln einer Produktsoftware 144 für ein Produkt 146 zu leiten. Bei einer Ausführungsform umfasst das Anforderungsdokument ein Textverarbeitungsdokument und/oder eine Tabelle und/oder ein Veröffentlichungsdokument. Die Anwendung 124 eines Dokuments mit mit Anmerkungen versehenen Anforderungen kann ein Textverarbeitungsprogramm, ein Desktop-Publisher, ein Tabellenkalkulationsprogramm und Ähnliches sein.
-
Bezug nehmend auf 1 und 3 ist die Anwendung 124 eines Dokuments mit mit Anmerkungen versehenen Anforderungen ferner ausgestaltet, um bei einer Ausführung durch den Prozessor 120 zu bewirken, dass der Prozessor das Einsetzen von Anmerkungen 152 in das Anforderungsdokument 130 ermöglicht, um ein Dokument 150 mit mit Anmerkungen versehenen Anforderungen zu erzeugen. Bei dem in 3 schematisch gezeigten Beispiel umfassen die Anmerkungen 152 Kommentar-Sprechblasen am Rand des Dokuments 150 mit mit Anmerkungen versehenen Anforderungen. Die Kommentar-Sprechblasen sind mit ausgewähltem Text der informalen Anforderungen (z. B. bestimmten informalen Anforderungen 132) verbunden.
-
Bei alternativen Ausführungsformen umfassen die Anmerkungen 152 beliebige Fußnoten, Endnoten, andere Mechanismen zum Verbinden von Kommentaren mit informalen Anforderungen und andere Kommentierungsmechanismen, die ein Einsetzen von Kommentaren neben jeder informalen Anforderung 132 ermöglichen. Die Softwaregruppe 142 erzeugt die Syntax der Anmerkungen 152 für jedes mehrerer Artefakte 160, 162, 164 (identifiziert in den 4–8). Die Anmerkungen und Syntax werden im nächsten Abschnitt ausführlicher beschrieben.
-
Bei einer Kombination stellen die Artefakte 160, 162, 164 einige oder alle Pfade zwischen einem gegebenen Quell- und Zielmodus (Merkmalsverhaltenszustand) auf jeder Hierarchieebene (z. B. Modus und Submodus) bereit, stellen sie Eintrittsbedingungen für einen bestimmten Modus bereit, Erzeugen sie Wege und machen sie den Überprüfungsprozess praktisch und effizient. Wenn beispielsweise ein Merkmal zwei Modi, GESPERRT und EINGESCHALTET, aufweist, könnte die Eintrittsbedingung für EINGESCHALTET ”Das Merkmal befindet sich im GESPERRT-Modus, der Fahrer drückt den Einschaltknopf UND keine Sensorausfälle sind aufgetreten” lauten. Mit anderen Worten beschreibt die Eintrittsbedingung die Bedingung, die bewirkt, dass in den bestimmten Modus eingetreten wird.
-
Ein Weg liefert andererseits einen vollständigen Pfad zwischen einem gegebenen Quellmodus und einem gegebenen Zielmodus. Wenn beispielsweise ein Merkmal drei Modi (z. B. AKTIV, EINGESCHALTET und ÜBERSCHREIBEN) aufweist, könnte ein Weg von dem Quellmodus AKTIV zu dem Zielmodus ÜBERSCHREIBEN ”Wenn sich das Merkmal im AKTIV-Modus befindet und der Fahrer einen Einschaltknopf drückt, begibt sich das Merkmal in den EINGESCHALTET-Modus; dann, wenn der Fahrer eine bestimmte Aktion durchführt, um eine durch das Merkmal verursachte Aktion zu überschreiben (so dass er wieder die Kontrolle übernimmt), begibt sich das Merkmal in den ÜBERSCHREIBEN-Modus” lauten. Mit anderen Worten liefert ein Weg einen Pfad in dem Modusdiagramm, der bewirkt, dass sich das Merkmal von einem gegebenen Quellmodus zu einem gegebenen Zielmodus (über jegliche Zwischenmodi) begibt, und dies umfasst die Bedingungen, unter denen die entsprechenden Modusänderungen stattfinden können. Diese Merkmale und Funktionen werden nachstehend weiter beschrieben.
-
ANMERKUNGEN UND SYNTAX
-
Jede Anmerkung 152 umfasst eine mindestens einer entsprechenden informalen Anforderung 132 zugehörige Syntax. Beispielsweise kann die Syntax mit momentaner Bezugnahme auf 4–7 ausgeführt werden, um die Artefakte 160, 162, 164 zu erzeugen, wie es nachstehend ausführlicher beschrieben ist. Die Anmerkungen 152 stellen eine nachvollziehbare Verbindung zwischen den informalen Anforderungen 132 und den Elementen der Artefakte 160, 162, 164 bereit, um eine Überprüfung und Modifikation zu ermöglichen, wie es nachstehend ausführlicher beschrieben ist. Jede Anmerkung 152 kann eine Syntax für verschiedene Arten von Artefakten 160, 162, 164 umfassen, und eine zugehörige Anwendung ist ausgestaltet, um bei einer Ausführung durch den Prozessor 120 zu bewirken, dass der Prozessor relevante Teile der Syntax auswählt, um die Artefakte zu erzeugen, wie es nachstehend ausführlicher beschrieben ist.
-
Im Allgemeinen umfassen Artefakte visuelle Beschreibungen eines Merkmalsverhaltens, Beschreibungen in Textform eines Merkmalsverhaltens, Kombinationen hiervon und Ähnliches. Hierin umfassen beispielhafte visuelle Beschreibungen ein Kontextdiagramm 160 (4) und ein Modusdiagramm 162 (5 und 6). Eine beispielhafte Beschreibung in Textform umfasst eine Übergangssystemdefinition 164 (7). Nachstehend wird der Begriff Artefakte verwendet, um die Artefakte 160, 162, 164 als Gruppe zu beschreiben, und werden spezifische Namen der Artefakte (d. h. Kontextdiagramm 160, Modusdiagramm 162, Übergangssystemdefinition 164) verwendet, um die Artefakte 160, 162, 164 spezifisch oder individuell zu beschreiben.
-
ERSTE ARTEFAKTANWENDUNG
-
Bezug nehmend auf 1, 3 und 4 ist eine erste Artefaktanwendung 125 ausgestaltet, um bei einer Ausführung durch den Prozessor 120 zu bewirken, dass der Prozessor eine Syntax aus den Anmerkungen 152 in dem Dokument 150 mit mit Anmerkungen versehenen Anforderungen extrahiert und das Kontextdiagramm 160 als Funktion der Syntax der Anmerkungen 152 erzeugt. Die Kontextdiagramme 160 stellen Verbindungen zwischen verschiedenen Modulen oder Entitäten eines Merkmals dar, das in dem Anforderungsdokument 130 identifiziert ist. Module oder Entitäten eines Merkmals werden hierin als Agenten A bezeichnet. Bezug nehmend auf 4 umfasst die Syntax für das Kontextdiagramm 160 Agenten A (z. B. einen Quellagenten SA und einen Zielagenten DA) und eine Information I. Beispielsweise kann die Information I eine Beschreibung eines Ereignisses sein. Beim Erzeugen der Syntax für ein Kontextdiagramm 160 werden die Information I und die Agenten A gut identifiziert, und zumindest einer der Agenten A ist das in dem Kontextdiagramm 160 betrachtete Merkmal, und die Information I beschreibt eine Interaktion und/oder eine Beziehung zwischen den Agenten A.
-
Beispielsweise lautet die Syntax für das Kontextdiagram 160 bei einer beispielhaften Ausführungsform @<Kontextdiagramm>@ Quellagentenname -> Zielagentenname [Information, Anforderungsnummer]. Im Allgemeinen identifiziert @<Kontextdiagramm>@ die Syntax für ein Kontextdiagramm und umfasst die Information eine Beschreibung der Interaktion zwischen den Quellagenten SA und dem Zielagenten DA. Die Anforderungsnummer ist eine Nummer, die zum Identifizieren der bestimmten Merkmalsanforderung verwendet wird.
-
Wie in 4 gezeigt umfasst das beispielhafte Kontextdiagramm 160 eine Anzahl an beispielhaften Agenten A1, A2, A3, A4 und beispielhaften Informationen I1, I2, I3, I4 (jeweils durch einen Pfeil gezeigt, der die Richtung von einer jeweiligen Quelle zu einem jeweiligen Ziel angibt), die die Agenten A in Verbindung bringen. Information I1 bringt Agent A2, der als Quellagent SA1 fungiert, mit Agent A1, der als Zielagent DA1 fungiert, in Verbindung; Information I2 bringt Agent A3 als Quellagent SA2 mit Agent A1 als Zielagent DA2 in Verbindung; Information I3 bringt Agent A1 als Quellagent SA3 mit Agent A4 als Zielagent DA3 in Verbindung; und Information I4 bringt Agent A4 als Quellagent SA4 mit Agent A1 als Zielagent DA4 in Verbindung. Die erste Artefaktanwendung 125 ist ferner ausgestaltet, um bei einer Ausführung durch den Prozessor 120 zu bewirken, dass der Prozessor automatisch das Artefakt 160 analysiert, um eine Auflistung aller Eingänge von den und Ausgänge zu den verschiedenen Agenten A, mit denen das Softwaremerkmal in Interaktion steht, zu erzeugen.
-
ZWEITE ARTEFAKTANWENDUNG
-
Bezug nehmend auf 1, 3, 5 und 6 ist eine zweite Artefaktanwendung 126 ausgestaltet, um bei einer Ausführung durch den Prozessor 120 zu bewirken, dass der Prozessor die Anmerkungen 152 aus dem Dokument 150 mit mit Anmerkungen versehenen Anforderungen extrahiert und das Modusdiagramm 162 als Funktion der Syntax der Anmerkungen 152 erzeugt. Modusdiagramme stellen ein Merkmal in verschiedenen Modi und Submodi des Betriebs dar.
-
Jedes Modusdiagramm 162 ist eindeutig durch einen Modusdiagrammnamen MD identifiziert, der es von anderen Modusdiagrammen 162 unterscheidet. Bei einer Ausführungsform umfasst der Modusdiagrammname MD einen Ausgangsdiagrammnamen PD, der eindeutig das dem Modusdiagramm 162 zugehörige Ausgangsmodusdiagramm 162 identifiziert, und einen Ausgangsmodusnamen PM, der eindeutig den Modus in dem Ausgangsmodusdiagramm 162 identifiziert, von dem das Modusdiagramm 162 eine detaillierte Erweiterung ist.
-
Beispielsweise lautet die Syntax für das Modusdiagramm
162 @<Modusdiagramm>@ <Modusdiagrammname> <Ausgangsdiagrammname> Ausgangsmodusname [Information, Anforderungsnummer]. Im Allgemeinen identifiziert @<Modusdiagramm>@ die Syntax für ein Modusdiagramm; die Namen lauten wie oben beschrieben; und die Information kann beispielsweise die Tatsache umfassen, warum der Ausgangsmodus in dem Ausgangsmodusdiagramm in den Modus/die Modi in diesem Modusdiagramm zerlegt wurde.
-
Ferner umfasst die Syntax für das Modusdiagramm 162 Modi M (z. B. Quellmodi SM und Zielmodi DM), eine Information I, die die beiden verbindet, und den Modusdiagrammnamen MD. Beispielsweise lautet die zusätzliche Syntax für das Modusdiagramm 162 @<Modusdiagramm>@ <Modusdiagrammname> <Quellmodusname> Zielmodusname [Information, Anforderungsnummer]. Die Information kann Bedingungen für jede Submodusänderung und die resultierenden Aktionen umfassen. Die beiden Formen der Syntax für das Modusdiagramm 162 (i) identifizieren das Ausgangsmodusdiagramm 162 und den Ausgangsmodus M darin, wofür dieses Modusdiagramm 162 eine detaillierte Erweiterung ist, und (ii) beschreiben dieses Modusdiagramm 162 selbst hinsichtlich der Modi M, aus denen es besteht, und der Information I, die sie verbindet, genau.
-
Bezug nehmend auf 5 und 6 sind zwei Modusdiagramme 162 gezeigt. 5 ist ein Ausgangsmodusdiagramm 162 des Modusdiagramms 162 von 6. Im Speziellen ist 6 ein Modusdiagramm 162 mit Submodi M eines der Modi M des Modusdiagramms 162 von 5. Jedes Modusdiagramm 162 umfasst eine Anzahl an Modi M, die durch eine Information I in Verbindung stehen und durch einen Modusdiagrammnamen MD identifiziert sind, der einen Ausgangsdiagrammnamen PD und einen Ausgangsmodusnamen PM umfasst.
-
Bezug nehmend auf 5 ist das Modusdiagramm 162 durch den Modusdiagrammnamen MD2 identifiziert, ist der Modusdiagrammname MD1 (nicht gezeigt) der Ausgangsdiagrammname PD und ist der Modus M1 der Modus in dem Ausgangsmodusdiagramm MD1, der in dem Modusdiagramm 162 von 5 erweitert ist. Hier bringt Information I1 Modus M2 als Quellmodus SM1 mit Modus M3 als Zielmodus DM1 in Verbindung; und Information I2 bringt M3 als Quellmodus SM2 mit Modus M2 als Zielmodus DM2 in Verbindung.
-
Bezug nehmend auf 6 ist das Modusdiagramm 162 durch den Modusdiagrammnamen MD3 identifiziert, ist der Modusdiagrammname MD2 (5) der Ausgangsdiagrammname PD und ist Modus M3 der Modus in dem Modusdiagramm MD2, der in dem Modusdiagramm 162 von 6 erweitert ist. Hier bringt die Information I3 Modus M4 als Quellmodus SM3 mit Modus MS als Zielmodus DM3 in Verbindung; Information I4 bringt Modus MS als Quellmodus SM4 mit Modus M4 als Zielmodus DM4 in Verbindung; Information IS bringt Modus M4 mit sich selbst sowohl als Quellmodus SMS als auch als Zielmodus DMS in Verbindung; und Information I6 bringt Modus MS als Quellmodus SM6 mit Modus M6 als Zielmodus DM6 in Verbindung.
-
Es ist zu verstehen, dass die Modusdiagramme 162 im Wesentlichen für jeden Modus M (z. B. M1, M2, M3, M4, MS) erzeugt werden.
-
Die zweite Artefaktanwendung 126 ist ferner ausgestaltet, um bei einer Ausführung durch den Prozessor 120 zu bewirken, dass der Prozessor das Modusdiagramm 162 automatisch analysiert, um einige spezifische Pfade oder alle möglichen Pfade zwischen beispielsweise einem gegebenen Quellmodus und einem Zielmodus zu ermitteln.
-
DRITTE ARTEFAKTANWENDUNG
-
Bezug nehmend auf 1, 3 und 7 ist eine dritte Artefaktanwendung 127 ausgestaltet, um bei einer Ausführung durch den Prozessor 120 zu bewirken, dass der Prozessor die Syntax der Anmerkungen 152 aus dem Dokument 150 mit mit Anmerkungen versehenen Anforderungen extrahiert und die Übergangssystemdefinition 164 als Funktion der Syntax der Anmerkungen 152 erzeugt. Die Syntax umfasst formalisierte Anforderungen 170, die schematisch in 7 gezeigt sind.
-
Bei einer Ausführungsform stellt die Übergangssystemdefinition 164 eine Tabelle, ein Schema oder einen anderen Entwurf von Daten dar oder umfasst sie diese(s/n), worin die formalisierten Anforderungen 170 organisiert sind, wie beispielsweise in jeweiligen Spalten, um die formalisierten Anforderungen 170 in Verbindung zu bringen. Wie in 7 gezeigt und nachstehend ausführlicher beschrieben umfassen die formalisierten Anforderungen 170 Anforderungsnummern #, Ereignisse E, Vorbedingungen Pre-C, Nachbedingungen Post-C, Quellen, Ziele, Aktionen AN und Ähnliches (die Quellen und Ziele sind in 7 nicht ausdrücklich identifiziert, werden jedoch als durch die Darstellung und diese Beschreibung gezeigt betrachtet).
-
Die Übergangssystemdefinitionen 164 sind bei einigen Ausführungsformen in der Hinsicht den Modusdiagrammen 160 ähnlich, dass jede ein Fokussoftwaremerkmal auf einer hohen Ebene zerlegt. Bei den Übergangssystemdefinitionen 164 sind die Informationen (z. B. Bedingungen und Aktionen) jedoch formal durch mathematische Strukturen (z. B. siehe nachstehend beschriebene Ereignisse) spezifiziert, die in der Syntax und nicht durch die Beschreibungen in natürlicher Sprache oder eine andere informale Spezifikation (z. B. siehe die oben in Verbindung mit 4–6 beschriebene Information) zu finden sind.
-
Eine beispielhafte Syntax für die Übergangssystemdefinitionen 164 umfasst eine Syntax für Ereignisse, Typen, Variablen und Übergange. Die Syntax für ein Ereignis umfasst eine Richtung und einen Ereignisnamen. Richtungen umfassen Eingang, Ausgang und lokal. Beispielsweise lautet oder umfasst eine beispielhafte Ereignissyntax @Ereignis@ Richtung Ereignis_Name [Kommentar, Anforderungsnummer].
-
Die Syntax für einen Typ umfasst einen Typnamen und einen Typ. Beispielsweise lautet eine Typsyntax @Typ@ <Typname>: Typ={durch Semikolon getrennte Werteliste}. Die Werteliste gibt mögliche Werte an, die von einer Variablen angenommen werden können, die als dieser Typ deklariert wurde. Für den Boolschen Typ ist dies WAHR oder FALSCH, und für einen Aufzählungstyp, der beispielsweise MERKMAL_F1_TYP genannt wird, kann dies ein Wert sein, wie beispielsweise GESPERRT, FREIGEGEBEN, EINGESCHALTET_IN_X oder EINGESCHALTET_IN_Y, wenn jene in dieser Liste möglicher Werte für eine Variable vom MERKMAL_F1_TYP spezifiziert sind.
-
Die Syntax für eine Variable umfasst eine Richtung, einen Variablennamen und einen Typ. Beispielsweise kann eine Variablensyntax wie folgt lauten: @Variable@ Richtung Variablenname: Typ.
-
Die Syntax für einen Übergang umfasst einen Quellmodusnamen, eine Vorbedingung, ein Ein-Ereignis, einen Zielmodusnamen, eine Nachbedingung und ein Aus-Ereignis. Vorbedingungen und Nachbedingungen werden bei einigen Ausführungsformen hinsichtlich der Werte der Variablen ausgedrückt, die durch den Übergang beeinflusst werden (z. B. sind oder erwartet werden, zu sein). Die Werte der Variablen werden einen jener umfassen, die durch ihren Typ zugelassen sind. Wenn es sich um den Boolschen Typ handelt, könnte sich ihr Wert von WAHR (in der Vorbedingung, d. h. bevor der Übergang stattfindet) nach FALSCH in der Nachbedingung ändern.
-
Bei einer Ausführungsform findet der Übergang nur in Ansprechen darauf statt, dass das Ein-Ereignis stattfindet. Ein beispielhaftes Ein-Ereignis ist ein Fahrzeugunfall. Ein anderes beispielhaftes Ein-Ereignis umfasst, dass ein Fahrer oder Fahrgast eines Fahrzeugs einen Knopf an einer Mensch-Maschine-Schnittstelle (HMI von human-machine-interface), wie beispielsweise einem berührungsempfindlichen fahrzeuginternen Anzeigebildschirm, drückt. In Ansprechen auf das Ein-Ereignis wird der Übergang durchgeführt, und als Aktion findet ein Aus-Ereignis statt, wie beispielsweise das Aufsperren einer Tür des Fahrzeugs.
-
Eine beispielhafte Übergangssyntax lautet @Übergang@ <Quellmodusname> <Vorbedingung> <Ein-Ereignis> -> <Zielmodusname> <Nachbedingung> <Aus-Ereignis> [Kommentar, Anforderungsnummer].
-
ANWENDUNG EINES FORMALEN MODELLS
-
Bezug nehmend auf 1, 7 und 8 ist eine Anwendung 128 eines formalen Modells ausgestaltet, um bei einer Ausführung durch den Prozessor 120 zu bewirken, dass der Prozessor die formalisierten Anforderungen 170 aus der Übergangssystemdefinition 164 extrahiert und ein formales Modell 172 als Funktion der formalisierten Anforderungen 170 erzeugt. Im Speziellen bewirkt die Anwendung 128 eines formalen Modells bei einer Ausführung durch den Prozessor 120, dass der Prozessor die formalisierten Anforderungen 170 in die Sprache einer formalen Modellerstellung einer Modellprüfanwendung 129 übersetzt, um das formale Modell 172 zu erhalten.
-
MODELLPRÜFANWENDUNG
-
Bezug nehmend auf 1 und 8 analysiert die Modellprüfanwendung 129 das formale Modell 172. Die Modellprüfanwendung 129 bewirkt bei einer Ausführung durch den Prozessor 120, dass der Prozessor einen Fehlerbericht 174 erzeugt, um die formalisierten Anforderungen 170 zu überprüfen, um eine Inkonsistenz oder Unvollständigkeit hinsichtlich der ursprünglichen informalen Anforderungen 132 zu identifizieren. Bei einer Ausführungsform stellt die Modellprüfanwendung 129 SPIN (Simple Promela Interpreter), SAL (Symbolic Analysis Laboratory) und andere ähnliche Modellprüfanwendungen, die ein formales Modell wie 172 analysieren können, dar oder umfasst sie diese.
-
VERFAHREN
-
Bezug nehmend auf 8 wird nun ein beispielhaftes Verfahren 200 beschrieben. Gemäß einem Anforderungsdokumentschritt 202 verwendet die Konstruktionsgruppe 140 die erste Anwendung 124 (1), die wie oben beschrieben arbeitet, um das Anforderungsdokument 130 zu erzeugen, das die dem Produkt 146 (2) zugehörigen informalen Anforderungen 132 umfasst. Das Anforderungsdokument 130 wird für die Softwaregruppe 142 vorbereitet und ist für diese zugänglich, um die Produktsoftware 144 (2 und 8) für das Produkt 146 (2) zu entwickeln.
-
Gemäß einem Anmerkungsschritt 204 greift die Softwaregruppe 142 auf das Anforderungsdokument 130 zu und verwendet sie die erste Anwendung 124 (1), die wie oben beschrieben arbeitet, um Anmerkungen 152 zu erzeugen, die entsprechenden informalen Anforderungen 132 zugehörig sind, und auf diese Weise das Dokument 150 mit mit Anmerkungen versehenen Anforderungen zu erzeugen. Die Anmerkungen umfassen eine Syntax, die ausgestaltet ist, um die Artefakte 160, 162, 164 zu erzeugen.
-
Gemäß einem ersten/zweiten Artefaktschritt 206 bewirken die erste Artefaktanwendung 125 und die zweite Artefaktanwendung 126, dass der Prozessor 120 auf das Dokument 150 mit mit Anmerkungen versehenen Anforderungen zugreift, die Syntax extrahiert und die Kontextdiagramme 160 und die Modusdiagramme 162 als Funktion der Syntax der Anmerkungen 152 erzeugt. Wie bei den Modusdiagrammen sind mehrere Kontextdiagramme möglich, beispielsweise, wenn ein Merkmal als Zusammensetzung mehrerer Submerkmale gesehen wird. Beispielsweise wird ein Kontextdiagramm für das Merkmal ”Fahrerassistenz” sowie für dessen Submerkmale ”Spurwechselassistenz” und ”Kollisionsvermeidung” erzeugt.
-
Gemäß einem ersten Überprüfungsschritt 208 werden die Kontextdiagramme 160 und die Modusdiagramme 162 durch die Konstruktionsgruppe 140 und/oder die Softwaregruppe 142 überprüft. Wenn die Gruppen) 140, 142 ermittelt/ermitteln (Änderungsschritt 209), dass Änderungen an den informalen Anforderungen 132 und/oder den Anmerkungen 152 durchgeführt werden müssen, werden die Schritte 204, 206, 208, 209 wiederholt, bis keine Änderungen erforderlich sind.
-
Andernfalls bewirkt die dritte Artefaktanwendung 127 gemäß einem dritten Artefaktschritt 210, dass der Prozessor 120 auf das Dokument 150 mit mit Anmerkungen versehenen Anforderungenzugreift, die Syntax extrahiert und die Übergangssystemdefinition 164, die formalisierte Anforderungen 170 umfasst, als Funktion der Syntax in den Anmerkungen 152 erzeugt. Die Syntax für die Übergangssystemdefinition 164 kann zusammen mit der Syntax für die Kontext- und Modusdiagramme 160, 162 oder nach dem Überprüfen der Kontext- und Modusdiagramme 160, 162 (Schritt 208) eingesetzt werden. In einigen Fällen ist es effizienter, letzteres zu tun (Einsetzen der Syntax der Übergangssystemdefinition 164 nach dem Überprüfen der Kontext- und Modusdiagramme 160, 162), da jegliche erforderlichen Änderungen auf erster Ebene an den informalen Anforderungen durchgeführt werden würden, bevor die Syntax der Übergangssystemdefinition 164 eingesetzt wird.
-
Gemäß einem Schritt 212 eines formalen Modells bewirkt die Anwendung 128 einer formalen Modellerstellung, dass der Prozessor 120 auf die Übergangssystemdefinition 164 zugreift, die formalen Anforderungen 170 extrahiert und das formale Modell 172 in der Eingabesprache der Modellprüfanwendung 129 als Funktion der formalisierten Anforderungen 170 erzeugt.
-
Gemäß einem zweiten Überprüfungsschritt 214 bewirkt die Modellprüfanwendung 129, dass der Prozessor 120 das formale Modell 172 analysiert. Die Modellprüfanwendung 129 analysiert das formale Modell 172, um jegliche Inkonsistenzen und Unvollständigkeit zu finden. Im Speziellen erzeugt die Modellprüfanwendung 129 einen Fehlerbericht 174. Der Fehlerbericht 174 und das formale Modell 172 werden durch die Konstruktionsgruppe 140 und/oder die Softwaregruppe 142 überprüft, um eine Konsistenz und Vollständigkeit anzugehen. Wenn die Gruppen 140, 142 ermitteln, dass Änderungen an den formalen Anforderungen 170, den Anmerkungen 152 und/oder den informalen Anforderungen 132 durchgeführt werden müssen, werden geeignete Modifikationen durchgeführt und werden einige oder alle der vorherigen Schritte des Verfahrens 200 wiederholt, bis eine Konsistenz und Vollständigkeit erreicht sind. Ansonsten werden die formalen Anforderungen 170 in der Produktsoftware 144 realisiert.
-
Die oben beschriebenen Ausführungsformen sind lediglich beispielhafte Darstellungen der Realisierungen, die für ein deutliches Verständnis der Prinzipien ausgeführt sind. Es können Änderungen, Abwandlungen und Kombinationen, die mit den oben beschriebenen Ausführungsformen in Verbindung stehen, durchgeführt werden, ohne von dem Schutzumfang der Ansprüche abzuweichen. Alle solchen Änderungen, Abwandlungen und Kombinationen sind hierin durch den Schutzumfang dieser Offenbarung und die folgenden Ansprüche umfasst.
