DE102010033861A1 - Auf einer formellen Analyse basierte Entwicklung von Anforderungsspezifikationen - Google Patents

Abstract

Ein Verfahren zum Entwickeln einer Spezifikation umfasst, dass mehrere Anforderungen empfangen werden, die die Funktionalität der Spezifikation definieren, wobei die mehreren Anforderungen unter Verwendung eines formellen Modells ausgedrückt werden. Das Verfahren umfasst ferner, dass die mehreren Anforderungen unter Verwendung von Algorithmen analysiert werden und ermittelt wird, ob die mehreren Anforderungen einen vorbestimmten Satz von Kriterien erfüllen. Das Verfahren umfasst ferner, dass eine Zusammenfassung der formellen Analyse erzeugt wird und die Anforderungen weiterentwickelt werden, indem korrigierte Analyseergebnisse einbezogen werden.

Description

• HINTERGRUND
• Ein Softwareentwicklungsprozess (d. h. Software Life Cycle) umfasst allgemein Aufgaben wie beispielsweise ein Entwickeln von Anforderungen, ein Entwerfen und Testen von Modellen und ein Entwickeln von Code, obwohl dies von einem bestimmten Entwurfsmodell abhängig ist. Im Allgemeinen ist eine Anforderung eine dokumentierte Notwendigkeit bezüglich dessen, wie ein bestimmtes Produkt oder ein bestimmter Dienst funktionieren sollte. Insbesondere ist eine Anforderung eine Aussage, die ein notwendiges Attribut, eine notwendige Fähigkeit, eine notwendige Eigenschaft oder eine notwendige Qualität eines Systems identifiziert. Anforderungen werden als Eingänge in die Entwurfsstufen eines Produktentwicklungsprozesses verwendet und zeigen, welche Elemente und Funktionen für eine bestimmte Anwendung notwendig sind.
• Einer Anforderungsentwicklungsphase kann eine Machbarkeitsstudie oder eine Anforderungserfassungsstufe vorausgehen, wobei Anforderungen von Kunden, Benutzern oder anderen Interessenten eruiert werden. Die Anforderungsphase kann auch in Analyse-, Spezifikations- und Verifikationsstufen aufgegliedert werden, wobei die Anforderungen hinsichtlich Konsistenz, Vollständigkeit, Korrektheit und potentiellen Ambiguitäten dokumentiert und geprüft werden.
• Das Entwickeln von Anforderungen, hierin auch als Anforderungstechnik bezeichnet, ist ein kritischer Schritt in dem Entwicklungsprozess eines softwareintensiven Systems. Bei Softwareentwurfsfachleuten ist es weithin bekannt, dass ein großer Prozentsatz an Defekten in einem System auf Defekte in der Anforderungsspezifikation zurückgeführt werden kann. Die Kosten des Behebens von Anforderungsfehlern erhöhen sich über den Entwurfs-, Realisierungs- und Teststufen der Systemtechnik exponentiell.
• Die Anforderungstechnik befindet sich an der Grenze zwischen Systementwurf und Benutzererwartungen und ist dafür verantwortlich, die Qualität einer Anforderungsspezifikation sicherzustellen. Zu diesem Zweck sollte die Anforderungstechnik auf eine Weise realisiert werden, die sicherstellt, dass die Anforderungsspezifikation präzise, eindeutig, konsistent und vollständig ist und die Erwartungen der Interessenten erfüllt.
• Es gibt eine Anzahl von Werkzeugen und Verfahren, die zum Unterstützen von Anforderungsingenieuren beim Entwickeln von Qualitätsanforderungsspezifikationen entwickelt wurden. Die Werkzeuge weisen eine variierende Funktionalität auf und reichen von einem Bereitstellen von Speichern zum Speichern von Spezifikationen bis zu einem Bereitstellen von Analysemaschinen auf der Grundlage von formellen Verfahren zum Analysieren von Spezifikationen. Eine Anzahl von Werkzeugen stellt auch Fähigkeiten für eine Konfigurationsverwaltung und eine Versionsverwaltung von Spezifikationen und auch zum Unterstützen einer Nachvollziehbarkeit von Anforderungen über verschiedene Stufen des Systemtechnikzyklus bereit. Es besteht jedoch Bedarf an einem automatisierten System, das ausgestaltet ist, um einen iterativen Entwicklungsprozess bereitzustellen, der Ergebnisse einer formellen Analyse direkt in die Entwicklungsstufen der Anforderungsspezifikation einbezieht.
• ZUSAMMENFASSUNG
• Ein Verfahren zum Entwickeln einer Spezifikation umfasst, dass mehrere Anforderungen empfangen werden, die die Funktionalität der Spezifikation definieren, wobei die mehreren Anforderungen unter Verwendung eines formellen Modells ausgedrückt werden. Das Verfahren umfasst ferner, dass die mehreren Anforderungen unter Verwendung einer formellen Analyse simuliert werden und ermittelt wird, ob die mehreren Anforderungen einen vorbestimmten Satz von Kriterien erfüllen. Das Verfahren umfasst ferner, dass eine Zusammenfassung der formellen Analyse erzeugt wird und mindestens eine der mehreren Anforderungen modifiziert wird, wenn mindestens eines des vorbestimmten Satzes von Kriterien nicht erfüllt ist.
• Weitere Merkmale werden aus der folgenden Beschreibung und den beigefügten Ansprüchen in Verbindung mit den begleitenden Zeichnungen ersichtlich.
• KURZBESCHREIBUNG DER ZEICHNUNGEN
• 1 zeigt ein beispielhaftes Anforderungsspezifikationsentwicklungssystem gemäß einer Ausführungsform;
• 2 zeigt einen beispielhaften Prozess zum Entwickeln einer Anforderungsspezifikation gemäß einer Ausführungsform;
• 3 zeigt einen beispielhaften Fokusbetrieb ist eine Zustandsmaschine; und
• 4 zeigt eine beispielhafte Zustandsmaschinenaussage.
• DETAILLIERTE BESCHREIBUNG DER AUSFÜHRUNGSFORMEN
• Die hierin beschriebenen Ausführungsformen beziehen sich allgemein auf ein System und einen Prozess zum Entwickeln einer Anforderungsspezifikation und insbesondere auf ein Verfahren zum direkten Einbeziehen von Ergebnissen einer formellen Analyse in die Entwicklungsstufen der Anforderungsspezifikation. Das System umfasst ein Softwareentwicklungswerkzeug, das ausgestaltet ist, um einen iterativen Entwicklungsprozess zu realisieren, der Algorithmen einer formellen Analyse eng in eine Rückkopplungsschleife integriert, wobei ermöglicht wird, die Ergebnisse der Analyse in die Spezifikation einzubeziehen.
• Unter Verwendung dieses Ansatzes sind die Analysealgorithmen und der Spezifikationsformalismus darin komplementär zueinander, dass die Datenstrukturen, die die Analyseergebnisse darstellen, die gleichen sind wie die Datenstrukturen für die Spezifikationsaussagen. Dies ermöglicht, dass die Analyseergebnisse direkt als Spezifikationsmechanismus oder -gegenstand verwendet werden. Mit anderen Worten kann ein Benutzer ein beabsichtigtes Ergebnis zum Durchführen einer bestimmten Analyse an der Spezifikation spezifizieren. Dieses System stellt eine sehr nahe Interaktion zwischen den Aktivitäten der Spezifikation und der Analyse bereit. Diese nahe Interaktion ermöglicht einen iterativen Regelungsprozess für eine Spezifikation und eine Analyse.
• Das Verfahren transformiert Anforderungen in Textform in ein formelles Modell von Anforderungen, die nachweisbar konsistent und vollständig sind. Das Verfahren überbrückt eine Lücke zwischen informellen Anforderungen und formellen Entwurfsmodellen, wie beispielsweise Zustandsdiagramme, die allgemein in einem modellbasierten Softwareentwurf verwendet werden. Da das Verfahren intern formelle Modelle verwendet, ermöglicht es eine schnelle iterative Entwicklung der Anforderungsspezifikation, unterstützt durch Analysealgorithmen, die an der Spezifikation arbeiten. Das gesamte Verfahren umfasst das Entwickeln der Spezifikation in kleinen Inkrementen. Jedem Inkrement der Spezifikation folgt eine Anwendung verschiedener Analysealgorithmen, die entworfen sind, um eine Rückmeldung für den Benutzer bereitzustellen, indem entweder die Spezifikation an einem beliebigen gegebenen Punkt in dem Entwicklungsprozess zusammengefasst wird oder indem logische Defekte in der Spezifikation identifiziert werden. Die Zusammenfassungsinformation, die durch die Analysealgorithmen erzeugt wird, kann als Anforderung in die Spezifikation einbezogen werden, wodurch die Spezifikation bestätigt und weiterentwickelt wird.
• 1 zeigt ein beispielhaftes Anforderungsentwicklungssystem 10 mit einem Softwareentwicklungswerkzeug 12, das ausgestaltet ist, um eingegebene Anforderungen 14 von einem Benutzer 16 zu empfangen. Bei einer Ausführungsform kann der Benutzer 16 beispielsweise ein Softwareingenieur, ein Anforderungsingenieur oder ein Experte auf dem Gebiet sein.
• Die Anforderungen 14 können unter Verwendung einer Vielzahl von verschiedenen Entwurfssprachen ausgedrückt werden, die durch die Anforderungsspezifikation unterstützt werden. Entwurfssprachen, die oftmals als Formalismen bezeichnet werden, können graphisch oder in Textform vorliegen und können ohne Einschränkungen Übergangssysteme (z. B. Zustandsmaschinen), Ereignissequenzabläufe (z. B. Szenarien- oder Sequenzdiagramme) und eine strukturierte englische Programmierung umfassen. Auf diese Weise kann der Benutzer 16 die Anforderungen 14 unter Verwendung verschiedener Formalismen entwickeln. Dies ermöglicht wiederum, dass die Spezifikation eine Interaktion zwischen Komponenten eines Systems umfasst, die durch verschiedene Formalismen spezifiziert und als ein vereinheitlichtes Modell gespeichert werden, was einen vereinfachten Import und Export hinsichtlich anderer Systemwerkzeuge ermöglicht. Die Anforderungen können durch eine Datenbank 18 gespeichert und/oder verarbeitet werden.
• Die formellen Modelle werden durch Analysemaschinen 20 bewertet, die mehrere Algorithmen umfassen, die ausgestaltet sind, um die Spezifikationsanforderungen 14, wie durch die formellen Modelle (d. h. Formalismus) dargestellt zu simulieren. Die Analysemaschinen 20 sind ausgestaltet, um die Konsequenzen bezüglich dessen, was die Anforderungen spezifizierten, an einem beliebigen gegebenen Punkt in dem Spezifikationsentwicklungsprozess zu untersuchen. Insbesondere bewerten die Analysemaschinen 20 die spezifizierten Anforderungen hinsichtlich eines vorbestimmten Satzes von Kriterien. Die Ergebnisse der Analyse werden zusammengefasst und an den Benutzer 16 zurückgegeben, der dann wählen kann, die Ergebnisse zu inspizieren und sie zu der Spezifikation hinzuzufügen, oder im Voraus erklären kann, dass alle Analyseergebnisse zu der Anforderungsspezifikation als neuer Spezifikationsgegenstand hinzugefügt werden sollen. Das Hinzufügen von Analyseergebnissen spezifiziert zusätzliche Beschränkungen der Spezifikation, sodass die Ergebnisse jeglicher weiterer Analysen mit dem Analyseergebnis (und einer weiteren Beschränkung), das hinzugefügt wird, übereinstimmen müssen, wodurch die Spezifikation weiterentwickelt wird. Die Fähigkeit, das Analyseergebnis zu überprüfen und zu modifizieren und die Spezifikation auf der Grundlage der Ergebnisse der Analyse weiterzuentwickeln, erzeugt eine Rückkopplungsschleife, die einen Regelungsprozess zum Entwickeln einer Anforderungsspezifikation bereitstellt. Somit werden Fehler oder Defekte in der Spezifikation in der Entwicklungsstufe des Prozesses identifiziert und können sie korrigiert werden, indem die Anforderungen ergänzt werden, wie es nachstehend ausführlicher beschrieben ist.
• Bei einem Ansatz umfasst der Satz von Kriterien das Überprüfen der Anforderungen hinsichtlich Defekten in Bezug auf Korrektheit, Vollständigkeit, Konsistenz und Ambiguität. Die Korrektheit der Spezifikation bezieht sich darauf, ob die dokumentierten Anforderungen die Anforderungen der Interessen (d. h. jeder Person, die an dem System interessiert ist, wie beispielsweise Benutzer, Tester, Entwicklungsteam, Management, etc.) genau reflektieren. Eine vollständige Spezifikation identifiziert klar ihren Umfang und spezifiziert vollständig alle Anforderungen innerhalb dieses Umfangs ohne fehlende Information.
• Eine Spezifikation ist konsistent, wenn es keine Teile der Spezifikation gibt, die sich gegenseitig widersprechen und die Spezifikation mit der gesamten maßgebenden externen Dokumentation vollständig konsistent ist. Mit anderen Worten kann eine logische Inkonsistenz in einer Spezifikation zwei Aktionen für einen Zustand definieren, wobei die Aktionen selbst inkonsistent sind. Beispielsweise kann eine Anforderung bei einem Kraftfahrzeugsystem spezifizieren, dass Zustand ”A” zu Aktion ”X” führt, wobei X eine Bremsfunktion ist, während eine andere Anforderung spezifizieren kann, dass Zustand ”A” zu Aktion ”Y” führt, die eine Beschleunigungsfunktion ist. Da ein Kraftfahrzeug während des Bremsens nicht beschleunigen kann, sind die beiden Anforderungen logisch inkonsistent.
• Damit eine Spezifikation eindeutig ist, sollte sie präzise sein und keinen Platz für mehrere Interpretationen durch verschiedene Personen lassen. Die Anforderungen sollten prägnant ohne Rückgriff auf technischen Jargon, undefinierte Akronyme oder andere geheimnisvolle Floskeln formuliert werden. Die Spezifikation sollte objektive Tatsachen ausdrücken und nur einer Interpretation unterliegen. Vage Subjektive, Adjektive, Präpositionen, Verben, subjektive Phrasen, negative Aussagen und zusammengesetzte Aussagen werden vermieden. Im Allgemeinen sind formell definierte Sprachen und Mathematik definitiv und eindeutig.
• Beim Bereitstellen der Analyseergebnisse stellt das Softwareentwicklungswerkzeug 12 dem Benutzer 16 die Fähigkeit bereit, einen bestimmten Teil der Spezifikation, der mit einem Defekt identifiziert wurde, zu ”fokussieren”. Durch Fokussieren des defekten Teils der Spezifikation kann der Benutzer 16 die Grundursache des Defekts isolieren und analysieren. Der Benutzer 16 kann dann ein alternatives Modell erzeugen, das den Defekt korrigiert. Dieses Modell, das einen einer Anforderung zugehörigen Zustand im Wesentlichen modifiziert, kann wieder in die Spezifikation einbezogen werden und erneut analysiert werden, wobei jegliche weiteren Defekte überprüft werden.
• 2 zeigt ein beispielhaftes Verfahren zum Entwickeln von Anforderungen. In Schritt 200 gibt ein Benutzer 16 Anforderungen in das Softwareentwicklungswerkzeug 12 ein. Die Anforderungen können in Form einer beliebigen geeigneten Entwurfssprache vorliegen, die ohne Einschränkung Übergangssysteme, Ereignissequenzabläufe und eine strukturierte englische Programmierung umfasst. Die Anforderungen, ausgedrückt unter Verwendung formeller Modelle, werden durch die Analysemaschinen 20 in Schritt 202 unter Verwendung einer formellen Analyse simuliert. Die formelle Analyse wendet in Schritt 204 mehrere Algorithmen an, um zu ermitteln, ob die Anforderungen 14 den vorbestimmten Satz von Kriterien erfüllen, was bei mindestens einer Ausführungsform das Überprüfen der Anforderungen 14, um zu ermitteln, ob sie korrekt, konsistent, vollständig und eindeutig sind, umfasst. In Schritt 206 wird eine Zusammenfassung der formellen Analyse erzeugt und dem Benutzer 16 bereitgestellt. In Schritt 208 können die Analyseergebnisse gemäß jeglichen Defekten korrigiert werden, die durch eine Überprüfung der Analyseergebnisse identifiziert werden. Diese korrigierten Analyseergebnisse werden dann in Schritt 210 in die Spezifikation einbezogen. Es sei angemerkt, dass sich das Korrigieren des Analyseergebnisses und das Einbeziehen dieses in die Spezifikation klar von einem direkten Korrigieren der Spezifikation unterscheidet. Eine geeignete Analogie wäre das Finden eines Bug beim Testen von Software. Es wird angenommen, dass ein Programm P einen nicht korrekten Ausgang O2 anstatt des korrekten Ausgangs O1 liefert. Sobald dieser Defekt gefunden wird, ist es möglich, den Code von P zu ändern, um diesen Defekt zu beheben (dies ist analog zu einem Korrigieren der Spezifikation), oder kann es möglich sein, lediglich zu ”erklären”, dass P den Ausgang O1 erzeugen sollte (dies ist analog zu einem Korrigieren des Analyseergebnisses). Es ist zu erkennen, dass das Korrigieren des Analyseergebnisses und das Einbeziehen dieses in die Spezifikation durch ”Erklären” dieses als das erwartete Analyseergebnis ein weitaus leistungsfähigerer Betrieb ist als das Korrigieren der Spezifikation.
• Das Folgende ist ein spezifisches Beispiel eines Prozesses zum Entwickeln einer Anforderungsspezifikation unter Verwendung von Zustandsmaschinen. Die Spezifikationen werden unter Verwendung eines Formalismus strukturierter Übergangssysteme (STS von Structured Transition Systems) entwickelt, der nachstehend beispielhaft eingeführt wird. Das dargestellte Verfahren bezieht sich auf jedes der Kriterien für die oben ausgeführten Anforderungen. Da eine formell definierte Sprache für die Spezifikation vorhanden ist, ist das Attribut, genau und eindeutig zu sein, bereits erfüllt. Das Verfahren verwendet Analysealgorithmen zum automatischen Detektieren von Inkonsistenzen und einer Unvollständigkeit in der Spezifikation.
• Das Folgende zeigt ein Verfahren unter Verwendung eines Teils der Anforderungen für einen eingebetteten Controller. Der Teil fokussiert das Ausfall- und Erholungsverhalten eines Controllers. Die Anforderungen auf hohem Niveau werden wie folgt zusammengefasst. Das Merkmal weist zwei Betriebsmodi auf: a) Manueller Modus und b) Automatischer Modus. Das Merkmal weist die folgenden Betriebszustände auf: a) Deaktiviert; b) Aus; c) Eingeschaltet; und d) Ausgefallen. Das Merkmal befindet sich zu Beginn in dem Aus-Betriebszustand, und der Benutzer muss hinsichtlich eines Ausfalls bei dem Merkmal benachrichtigt werden. Sobald ein Ausfall auftritt, muss das Merkmal zurückgesetzt werden, um sich zu erholen und den normalen Betrieb wieder aufzunehmen. Das Rücksetzereignis initiiert das Merkmal wieder in seinen anfänglichen Zustand.
• Die obigen Betriebsmodi und -zustände stellen die Art von Anforderungsspezifikationen dar, denen bei einigen Kraftfahrzeuganwendungen begegnet wird. Das Verfahren beginnt, indem zuerst die Ereignisse in der Spezifikation identifiziert werden und sie entweder als Eingangs- oder Ausgangsereignisse klassifiziert werden. Im obigen Fall kann man die folgenden Ereignisse identifizieren: 1) Ausfall, was ein Eingangsereignis ist; 2) Zurücksetzen, was ein Ausgangsereignis ist; und 3) Benachrichtigen, was ein Ausgangsereignis ist. Als Teil dieses Beispiels wird ein Ausgangsereignis ∊ hinzugefügt, um anzugeben, dass durch das Merkmal keine Aktion ausgeführt werden muss.
• Der nächste Schritt in dem Verfahren dient dem Identifizieren aller gültigen Zustände in der Spezifikation. Bei diesem Beispiel sind lediglich die Betriebsmodi und die Betriebszustände des Merkmals interessant. Bei dieser Spezifikation ist jede Kombination von Modus und Zustand-Wert zulässig. Daher gibt es 4 × 2 = 8 gültige Zustände für diese Spezifikation wie nachstehend gezeigt:

  Modus	Zustand
  Manuell	Deaktiviert
  Manuell	Aus
  Manuell	Eingeschaltet
  Manuell	Ausgefallen
  Automatisch	Deaktiviert
  Automatisch	Aus
  Automatisch	Eingeschaltet
  Automatisch	Ausgefallen

• Bei diesem Beispiel werden bestimmte Wertungen von Zustandsvariablenwerten als Zustände in Betracht gezogen und werden solche Zustände als Tupel von Werten dargestellt, wobei die betreffenden Zustandsvariablen aus dem Kontext klar werden. Beispielsweise stellt das Tupel <MANUELL, DEAKTIVIERT> den Zustand dar, bei dem die Zustandsvariable Modus den Wert MANUELL hat und die Zustandsvariable Zustand den Wert DEAKTIVIERT hat.
• Die STS-Sprache stellt eine Anzahl von Sprachkonstrukten bereit, um das Zustandsübergangsverhalten zu spezifizieren. Diese Konstrukte können verwendet werden, um die Merkmalsanforderungen in Textform auszudrücken. Eine der Anforderungen kann als Übergang zu einem AUSGEFALLEN-Zustand beim Auftreten des Ausfallereignisses ausgedrückt werden. In einem AUSGEFALLEN-Zustand sollten Übergänge bei dem Ausfall in dem AUSGEFALLEN-Zustand bleiben. Dies kann unter Verwendung des STS-Konstrukts für einfache Übergänge wie nachstehend gezeigt ausgedrückt werden.
• In jedem Zustand geht das Ereignis ”Ausfall” in einen Zustand über, in dem das Prädikat ”Ausfall” zutrifft und wird die Aktion ”Benachrichtigen ausgegeben
• Es wird die Notation wahr → Ausfall Benachrichtigen Ausfall verwendet, die für die obige Spezifikation steht, wobei das Prädikat Ausfall alle Zustände identifiziert, in denen die Zustand-Variable mit AUSGEFALLEN bewertet wird.
• Dass sich das Merkmal anfänglich im Aus-Zustand befindet, wird durch ein Initialisierungskonstrukt von STS ausgedrückt.
  Initialisiere Merkmal mit ”Aus”
• Wobei ”Aus” als die Zustand-Variable definiert ist, die den Wert AUS annimmt.
• Sobald ein Ausfall auftritt, muss das Merkmal zurückgesetzt werden, um sich zu erholen und den normalen Betrieb wieder aufzunehmen. Das Zurücksetzereignis initialisiert das Merkmal erneut mit seinem Anfangszustand. Dieses Verhalten beim Zurücksetzereignis wird unter Verwendung des folgenden einfachen Übergangs modelliert:
  In jedem Zustand geht das Ereignis ”Zurücksetzen” in einen Zustand über, in dem das Prädikat ”Aus” zutrifft und wird die leere Aktion ausgegeben
• Es wird die Notation wahr → Zurücksetzen ∊ Aus verwendet, die für die obige Spezifikation steht. In diesem Zustand wurden alle in der Spezifikation in Textform gegebenen Anforderungen unter Verwendung der Konstrukte der STS-Sprache formalisiert.
• Es kann eine Anzahl von verschiedenen Analysen an der Spezifikation durchgeführt werden, von denen die wichtigste das Überprüfen hinsichtlich Konsistenz und Vollständigkeit ist. Diese Analysealgorithmen wurden in dem Softwareentwicklungswerkzeug realisiert, um dem Benutzer eine interaktive Rückmeldung bereitzustellen, wenn die Spezifikation entwickelt wird.
• Zuerst wird beim Überprüfen hinsichtlich der Konsistenz herausgefunden, dass die Spezifikation wie angegeben konsistent ist. Bei einem Überprüfen hinsichtlich Unvollständigkeit berichtet die Analyse jedoch, dass das Ereignis Ausfall, bei dem Zustand <MANUELL, EINGESCHALTET>, zu einem Übergang zu entweder <MANUELL, AUSGEFALLEN> oder <AUTOMATISCH, AUSGEFALLEN> führen kann.
• Die Unvollständigkeitsanalyse zeigte, dass die Spezifikation in Bezug auf Änderungen der Modus-Zustandsvariable beim Spezifizieren des Übergangs bei einem Ereignis Ausfall nicht vollständig ist. In der Tat fehlt diese Information bei der früher bereitgestellten informellen Spezifikation.
• An dieser Stelle kann die Spezifikation durch Fokussieren des Zustandsvariablen-Modells analysiert werden. Das Ergebnis des Fokussierungsbetriebs ist eine ”Zusammenfassungs”-Zustandsmaschine, deren Zustände lediglich die unterschiedlichen Wertungen der Modell-Zustandsvariable sind und deren Übergänge das Verhalten in Bezug auf lediglich die Modus-Zustandsvariable spezifizieren – mit anderen Worten handelt es sich um eine Prädikatabstraktion der Spezifikation. Das Ergebnis des Fokussierens des Modus ist in 3 gezeigt.
• Ein empfindlicheres Verhalten umfasst jedoch, anzufordern, dass ein durch einen Ausfall verursachter [engl.: ”cause”] Übergang nicht die Modus-Zustandsvariable ändern sollte. Mit anderen Worten wird erwartet, dass das Ergebnis des Fokussierens des Modus die Zustandsmaschine von 4 ist – wobei es bei dem Ereignis Ausfall keinen Übergang zwischen manuell und automatisch gibt.
• Die STS-Sprache ermöglicht dem Benutzer, diesen Teil der Spezifikation zu spezifizieren, indem die in 4 spezifizierte Zustandsmaschine als Aussage importiert wird. Diese Aussage spezifiziert die Zustandsmaschine, die das Ergebnis des Analysierens der Spezifikation unter Verwendung des Fokusbetriebs ist.
• An dieser Stelle berichtet die Konsistenz- und Vollständigkeitsanalysenbewertung, dass die Spezifikation sowohl konsistent als auch vollständig ist. An dieser Stelle kann die Spezifikation jedoch inkorrekt sein – der Benutzer könnte unfreiwillig das falsche Verhalten spezifiziert haben. Es gibt keinen allgemeinen Algorithmus zum Detektieren einer Inkorrektheit bei einer Spezifikation, da es kein anderes formelles Modell gibt, mit dem die Spezifikation verglichen werden kann – lediglich das mentale Modell des Benutzers einer informellen geschriebenen Spezifikation. Die beste Möglichkeit ist das Analysieren der Spezifikation und das Visualisieren dieser aus verschiedenen Perspektiven und das Sicherstellen, dass jede Perspektive mit den Verhalten übereinstimmt, die der Benutzer erfassen will.
• In der vorliegenden Darstellung wird die Spezifikation simuliert und werden verschiedene Szenarien ausprobiert, um die Korrektheit der Spezifikation sicherzustellen. Einige Szenarien, die erwartet werden, sind:
  Aus einem Init-Zustand sollte die Sequenz
  <Ausfall, Ausfall, Zurücksetzen>
  zu dem Zielzustand, der Init erfüllt, führen. Aus einem Automatisch-Zustand, jede Sequenz an der Spezifikation, und es ist auch möglich, die entsprechenden Simulationsverfolgungen, ist auch möglich, die entsprechenden Stimulationsverfolgungen zu spezifizieren, als Simulationsaussagen in der Spezifikation zu spezifizieren. Ein bedenklicheres Szenario, das an der Spezifikation wie angegeben simuliert werden kann, lautet wie folgt – es wird mit einem Deaktiviert-Zustand begonnen, wobei die Sequenz <Ausfall, Zurücksetzen> dazu führt, dass der Zustand Init ist.
• In vielen Bereichen bedeutet ein Deaktiviert-Zustand, dass die Komponente nicht betrieben werden sollte, und ist ein spezielles Ereignis erforderlich, das sie betriebsfähig macht. Insbesondere sollten Ereignisse, wie beispielsweise Ausfall oder Zurücksetzen, den Zustand der Komponente [engl.: ”state component”] nicht ändern dürfen, wenn sie Deaktiviert ist. Daher ist das obige Szenario ein Antiszenario.
• Die STS-Sprache erlaubt die Spezifikation solcher Antiszenarien, und es ist möglich, die obige Simulation durchzuführen und die Simulationsverfolgung als Antiszenario zu markieren. Im vorliegenden Fall deuten die Algorithmen, wenn dieser Schritt durchgeführt wird, unmittelbar auf eine Inkonsistenz der Spezifikation hin. Der Grund hierfür ist, dass früher der Spezifikation die folgenden Aussagen spezifiziert wurden: wahr → Ausfall Benachrichtigen Ausfall wahr → Zurücksetzen ∊ Aus die einen Übergang bei den Ausfall- und Zurücksetzereignissen aus allen Zuständen spezifizieren. Für eine Konsistenz mit dem Antiszenario wurden diese Aussagen wie folgt geändert: ¬ Deaktiviert → Ausfall Benachrichtigen Ausfall ¬ Deaktiviert → Zurücksetzen ∊ Aus
• Ferner müssen Aussagen hinzugefügt werden, um das Verhalten in dem Deaktiviert-Zustand zu spezifizieren, um die Spezifikation zu vervollständigen: Deaktiviert → Ausfall Benachrichtigen Deaktiviert Deaktiviert → Zurücksetzen ∊ Deaktiviert
• In dieser Stufe ist die Spezifikation konsistent, vollständig und wahrscheinlich korrekt. Die hierarchische Natur von STS-Spezifikationen in Textform wird unter Verwendung eines Baums dargestellt, bei dem die blattlosen Knoten der Spezifikation entweder Zoom- oder Fokusaussagen sind, die eine Subspezifikation enthalten. Das Prototypwerkzeug unterstützt alle Analysen, die in dieser Schrift beschrieben wurden. Jede Analyse kann am oberen Niveau der Spezifikation oder in Bezug auf bestimmte Subspezifikationen, die einer Zoom- oder Fokusaussage entsprechen, durchgeführt werden.
• Es ist zu verstehen, dass die obige Beschreibung erläuternd und nicht einschränkend sein soll. Viele alternative Ansätze oder Anwendungen, die nicht in den Beispielen bereitgestellt wurden, würden für Fachleute beim Lesen der obigen Beschreibung ersichtlich werden. Der Schutzumfang der Erfindung sollte nicht in Bezug auf die obige Beschreibung bestimmt werden, sondern sollte stattdessen in Bezug auf die beigefügten Ansprüche zusammen mit dem vollständigen Umfang von Äquivalenten, die diese Ansprüche berechtigen, bestimmt werden. Es sei angemerkt und es ist vorgesehen, dass weitere Entwicklungen in der hierin erläuterten Technik stattfinden, und dass die offenbarten Systeme und Verfahren in solchen weiteren Beispielen umfasst sind. Zusammenfassend ist anzumerken, dass die Erfindung modifiziert und variiert werden kann und lediglich durch die folgenden Ansprüche beschränkt ist.
• Es wurden insbesondere die vorliegenden Ausführungsformen gezeigt und beschrieben, die lediglich die geeignetesten Ausführungsarten darstellen. Fachleute werden erkennen, dass verschiedene Alternativen zu den hierin beschriebenen Ausführungsformen beim Ausführen der Ansprüche eingesetzt werden können, ohne von dem Gedanken und Schutzumfang der Erfindung abzuweichen, und dass das Verfahren und das System innerhalb des Schutzumfangs dieser Ansprüche und ihrer Äquivalente auf diese Weise abgedeckt sind. Diese Beschreibung sollte als alle neuen und nicht offensichtlichen Kombinationen von hierin beschriebenen Elementen umfassend verstanden werden, und die Ansprüche können in dieser oder einer späteren Anwendung für jede neue und nicht offensichtliche Kombination dieser Elemente dargestellt werden. Ferner sind die vorstehenden Ausführungsformen darstellend und ist kein einzelnes Merkmal oder Element für alle möglichen Kombinationen wesentlich, die in dieser oder einer späteren Anmeldung beansprucht werden können.
• Alle Begriffe, die in den Ansprüchen verwendet werden, sollen als ihre breiteste vernünftige Konstruktion und ihre übliche Bedeutung umfassend betrachtet werden, wie es durch Fachleute weithin verstanden wird, wenn nicht ein ausdrücklicher Hinweis auf das Gegenteil hierin gegeben wird. Insbesondere sollte die Verwendung der Singularartikel wie ”eine/ein”, ”der/die/das” etc. als eines oder mehrere der angegebenen Elemente bezeichnend gelesen werden, wenn nicht ein Anspruch eine ausdrückliche Einschränkung auf das Gegenteil darstellt.

Claims (11)

1. Verfahren zum Entwickeln einer Spezifikation, wobei das Verfahren die Schritte umfasst, dass: mehrere Anforderungen empfangen werden, die die Funktionalität der Spezifikation definieren, wobei die mehreren Anforderungen unter Verwendung eines formellen Modells ausgedrückt werden; die mehreren Anforderungen unter Verwendung einer formellen Analyse simuliert werden; ermittelt wird, ob die mehreren Anforderungen einen vorbestimmten Satz von Kriterien erfüllen; eine Zusammenfassung der formellen Analyse erzeugt wird; und mindestens eine der mehreren Anforderungen modifiziert wird, wenn mindestens eines des vorbestimmten Satzes von Kriterien nicht erfüllt ist.
2. Verfahren nach Anspruch 1, das ferner umfasst, dass die erzeugte Zusammenfassung modifiziert wird und diese modifizierte Zusammenfassung als Spezifikationsgegenstand verwendet wird, wodurch die Spezifikation weiterentwickelt wird.
3. Verfahren nach Anspruch 2, das ferner umfasst, dass die Spezifikation unter Verwendung einer durch die formelle Analyse bereitgestellte Rückmeldung iterativ weiterentwickelt wird.
4. Verfahren nach Anspruch 3, wobei die Schritte des Simulierens der mehreren Anforderungen, des Ermittelns, ob die Anforderungen den Satz von Kriterien erfüllen, und des Erzeugens einer Zusammenfassung unter Verwendung der modifizierten Zusammenfassung wiederholt werden.
5. Verfahren nach Anspruch 1, wobei die Zusammenfassung der formellen Analyse angibt, ob die mehreren Anforderungen den vorbestimmten Satz von Kriterien erfüllen.
6. Verfahren nach Anspruch 1, wobei das Simulieren der mehreren Anforderungen unter Verwendung einer formellen Analyse umfasst, dass die Anforderungen unter Verwendung mindestens eines Algorithmus analysiert werden.
7. Verfahren nach Anspruch 1, wobei das Ermitteln, ob die mehreren Anforderungen einen vorbestimmten Satz von Kriterien erfüllen, umfasst, dass ermittelt wird, ob die Anforderungen vollständig und/oder korrekt und/oder konsistent und/oder eindeutig sind.
8. Verfahren nach Anspruch 1, das ferner umfasst, dass der Teil der Anforderungen, der den vorbestimmten Satz von Kriterien nicht erfüllt, ergänzt wird.
9. Verfahren nach Anspruch 8, das ferner umfasst, dass der ergänzte Teil der Anforderungen in die Spezifikation einbezogen wird.
10. Verfahren nach Anspruch 1, wobei das formelle Modell in Form einer Zustandsmaschine, eines Szenarios oder von strukturiertem Englisch vorliegt.
11. Verfahren nach Anspruch 1, wobei die modifizierte Zusammenfassung in die Spezifikation einbezogen wird, um die Spezifikation weiterzuentwickeln.

Images