Formale Spezifikation

Im Informatik, formale Spezifikationen sind mathematisch basierte Techniken, deren Ziel es ist, bei der Implementierung von Systemen und Software zu helfen. Sie werden verwendet, um ein System zu beschreiben, sein Verhalten zu analysieren und seine Gestaltung zu unterstützen, indem sie wichtige Interesseneigenschaften durch strenge und effektive Argumentationsinstrumente überprüfen.[1][2] Diese Spezifikationen sind formell In dem Sinne, dass sie eine Syntax haben, fallen ihre Semantik in einen Bereich und sie können verwendet werden, um nützliche Informationen zu schließen.[3]

Motivation

In jedem Jahrzehnt sind Computersysteme immer leistungsfähiger geworden und sind infolgedessen für die Gesellschaft wirksamer geworden. Aus diesem Grund sind bessere Techniken erforderlich, um die Gestaltung und Implementierung von zuverlässiger Software zu unterstützen. Etablierte technische Disziplinen verwenden mathematische Analyse als Grundlage für die Erstellung und Validierung von Produktdesign. Formale Spezifikationen sind eine solche Möglichkeit, dies in der Zuverlässigkeit von Software -Engineering zu erreichen, wie früher vorhergesagt. Andere Methoden wie z. testen werden häufiger zur Verbesserung der Codequalität verwendet.[1]

Verwendet

Ein solches gegeben SpezifikationEs ist möglich zu verwenden formelle Überprüfung Techniken, um zu demonstrieren, dass ein Systemdesign ist Korrekt in Bezug auf seine Spezifikation. Auf diese Weise können falsche Systemdesigns überarbeitet werden, bevor größere Investitionen in eine tatsächliche Implementierung getätigt wurden. Ein anderer Ansatz ist, wahrscheinlich richtig zu verwenden Raffinesse Schritte zur Umwandlung einer Spezifikation in ein Design, das letztendlich in eine Implementierung verwandelt wird, nämlich korrekt durch Konstruktion.

Es ist wichtig zu beachten, dass eine formale Spezifikation lautet nicht eine Implementierung, aber vielmehr kann sie verwendet werden, um eine zu entwickeln Implementierung. Formale Spezifikationen beschreiben was Ein System sollte nicht tun, nicht wie Das System sollte es tun.

Eine gute Spezifikation muss einige der folgenden Attribute haben: angemessen, intern konsistent, eindeutig, vollständig, zufrieden, minimal[3]

Eine gute Spezifikation wird:[3]

  • Konstruktionsfähigkeit, Verwaltbarkeit und Auswehrbarkeit
  • Benutzerfreundlichkeit
  • Kommunikationsfähigkeit
  • Leistungsstarke und effiziente Analyse

Eines der Hauptgründe, warum es Interesse an formalen Spezifikationen gibt, besteht darin, dass sie die Möglichkeit bieten, Beweise für Software -Implementierungen auszuführen.[2] Diese Beweise können verwendet werden, um eine Spezifikation zu validieren, die Korrektheit des Designs zu überprüfen oder zu beweisen, dass ein Programm eine Spezifikation erfüllt.[2]

Einschränkungen

Ein Design (oder eine Implementierung) kann niemals für sich selbst für „richtig“ erklärt werden. Es kann immer nur „in Bezug auf eine bestimmte Spezifikation“ sein. Ob die formale Spezifikation das zu lösene Problem korrekt beschreibt, ist ein separates Problem. Es ist auch schwierig, sich zu befassen, da es letztendlich das Problem betrifft Problemdomäneund ein solcher Abstraktionsschritt ist nicht für formalen Beweise zugänglich. Es ist jedoch möglich bestätigen Eine Spezifikation durch Beweisung „Herausforderung“ Theoreme In Bezug auf Eigenschaften, dass die Spezifikation erwartet wird, dass sie aufweisen. Wenn diese Theoreme korrekt sind, verstärken diese Theoreme das Verständnis des Spezifizierers für die Spezifikation und ihre Beziehung zum zugrunde liegenden Problembereich. Wenn nicht, muss die Spezifikation wahrscheinlich geändert werden, um das Domänenverständnis derjenigen, die mit der Erzeugung (und der Implementierung) der Spezifikation beteiligt sind, besser widerzuspiegeln.

Formale Methoden der Softwareentwicklung werden in der Industrie nicht häufig verwendet. Die meisten Unternehmen betrachten es nicht kostengünstig, sie in ihren Softwareentwicklungsprozessen anzuwenden.[4] Dies kann aus einer Vielzahl von Gründen sein, von denen einige sind:

  • Zeit
    • Hohe anfängliche Startkosten bei niedrigen messbaren Renditen
  • Flexibilität
    • Viele Softwareunternehmen verwenden Agile Methoden Das Fokus auf Flexibilität. Eine formale Spezifikation des gesamten Systems im Voraus wird oft als das Gegenteil von flexibel wahrgenommen. Es gibt jedoch einige Untersuchungen zu den Vorteilen der Verwendung formaler Spezifikationen mit "agiler" Entwicklung[5]
  • Komplexität
    • Sie erfordern ein hohes Maß an mathematischer Fachwissen und die analytischen Fähigkeiten, um sie effektiv zu verstehen und anzuwenden[5]
    • Eine Lösung dafür wäre die Entwicklung von Tools und Modellen, mit denen diese Techniken implementiert werden können, aber die zugrunde liegende Mathematik verbergen,[2][5]
  • Begrenzter Fokus[3]
    • Sie erfassen keine Interesseneigenschaften für alle Stakeholder im Projekt[3]
    • Sie leisten keine gute Arbeit, Benutzeroberflächen und Benutzerinteraktion anzugeben[4]
  • Nicht kostengünstig
    • Dies gilt nicht ganz, indem sie ihre Verwendung auf nur Teile kritischer Systeme einschränken, die sie als kostengünstig erwiesen haben[4]

Andere Einschränkungen:[3]

Paradigmen

In verschiedenen Bereichen und in verschiedenen Maßstäben gab es seit einiger Zeit formale Spezifikationstechniken.[6] Die Implementierungen formaler Spezifikationen unterscheiden sich abhängig davon, welche Art von System sie modellieren möchten, wie sie angewendet werden und zu welchem ​​Zeitpunkt im Software -Lebenszyklus sie eingeführt wurden.[2] Diese Arten von Modellen können in die folgenden Spezifikationsparadigmen eingeteilt werden:

  • Geschichtsbasierte Spezifikation[3]
    • Verhalten basierend auf Systemgeschichten
    • Behauptungen werden im Laufe der Zeit interpretiert
  • Staatliche Spezifikation[3]
    • Verhalten basierend auf Systemzuständen
    • Reihe von sequentiellen Schritten (z. B. eine Finanztransaktion)
    • Sprachen wie Z, VDM oder B Verlassen Sie sich auf dieses Paradigma[3]
  • Übergangsbasierte Spezifikation[3]
    • Verhalten basierend auf Übergängen vom Status zu Staat des Systems
    • am besten mit einem reaktiven System verwendet
    • Sprachen wie StatechArts, Promela, Stief-SPL, RSML oder SCR verlassen sich auf dieses Paradigma[3]
  • Funktionale Spezifikation[3]
    • Geben Sie ein System als Struktur mathematischer Funktionen an
    • OBJ, ASL, Plus, Larch, Hol oder PVs verlassen sich auf dieses Paradigma[3]
  • Betriebsspezifikation[3]
    • Frühe Sprachen wie Paisley, Gist, Petri Nets oder Prozessalgebren stützen sich auf dieses Paradigma[3]

Zusätzlich zu den oben genannten Paradigmen gibt es Möglichkeiten, bestimmte Heuristiken anzuwenden, um die Schaffung dieser Spezifikationen zu verbessern. In dem hier verwiesenen Papier wird am besten die Heuristiken erörtert, um sie bei der Gestaltung einer Spezifikation zu verwenden.[6] Sie tun dies, indem sie a anwenden Divide-and-Conquer sich nähern.

Software-Tools

Das Z Notation ist ein Beispiel für eine führende Formale Spezifikationssprache. Andere umfassen die Spezifikationssprache (VDM-SL) der Wiener Entwicklungsmethode und die abstrakte Maschinennotation (AMN) der B-Methode. In dem Internetdienste Bereich, formale Spezifikation wird häufig verwendet, um nicht funktionale Eigenschaften zu beschreiben[7] (Internetdienste Servicequalität).

Einige Werkzeuge sind:[4]

Beispiele

Beispiele für Implementierungsbeispiele finden Sie in den Links in Software-Tools Sektion.

Siehe auch

Verweise

  1. ^ a b Hierons, R. M.; Bogdanov, K.; Bowen, J. P. P.; Cleaveland, R.; Derrick, J.; Dick, J.; Gheorghe, M.; Harman, M.; Kapoor, K.; Krause, P.; Lüttgen, G.; Simons, A. J. H.; Vilkomir, S. A.; Woodward, M. R.; Zedan, H. (2009). "Verwendung formaler Spezifikationen zur Unterstützung von Tests". ACM Computing -Umfragen. 41 (2): 1. Citeseerx 10.1.1.144.3320. doi:10.1145/1459352.1459354. S2CID 10686134.
  2. ^ a b c d e Gaudel, M.-C. (1994). "Formale Spezifikationstechniken". Proceedings der 16. Internationalen Konferenz über Software -Engineering. S. 223–227. doi:10.1109/ICSE.1994.296781. ISBN 978-0-8186-5855-6. S2CID 60740848.
  3. ^ a b c d e f g h i j k l m n o Lamsweerde, A. V. (2000). "Formelle Spezifikation". Verfahren der Konferenz über die Zukunft des Software -Engineering - ICSE '00. S. 147–159. doi:10.1145/336512.336546. ISBN 978-1581132533. S2CID 4657483.
  4. ^ a b c d Sommerville, Ian (2009). "Formelle Spezifikation" (PDF). Softwareentwicklung. Abgerufen 3. Februar 2013.
  5. ^ a b c Nummenmaa, Timo; Tienuu, Aleksi; Berki, Eleni; Mikkonen, Tommi; Kittinen, Jussi; Kultima, Annakaisa (4. August 2011). "Unterstützung der agilen Entwicklung durch Erleichterung der natürlichen Benutzerinteraktion mit ausführbaren formalen Spezifikationen". ACM Sigsoft Software Engineering Notizen. 36 (4): 1–10. doi:10.1145/1988997.2003643. S2CID 2139235.
  6. ^ a b Van der Umfrage, John A.; Paula Kotze (2002). "Welche Designheuristik kann den Nutzen einer formalen Spezifikation verbessern?". Proceedings der jährlichen Forschungskonferenz von 2002 des South African Institute of Computer Scientists und Information Technologists on Enablement durch Technologie. SAICSIT '02: 179–194. ISBN 9781581135961.
  7. ^ S-Cube-Wissensmodell: Formale Spezifikation

Externe Links