Kontrolliertes Englisch für Anforderungsspezifikationen

Weitere Magazine

Empfehlungen

Info

28 Kapitel 2 Anforderungen und SpeziÞkationen 27 Spezifikationen, die in einer logischen Programmiersprache geschrieben sind, stellen nicht nur ein konzeptionelles Modell eines geplanten Softwaresystems dar, sondern auch ein Verhaltensmodell. Die VerfŸgbarkeit von ausfŸhrbaren Spezifikationen macht es fŸr die Anwendungsspezialisten mšglich, die Anforderungen in einer frŸhen Phase im Software-Entwicklungsprozess zu validieren und nicht erst nachdem bereits Entwurfsentscheidungen gefŠllt worden sind. Diese formale ausfŸhrungsorientierte Vorgehensweise kann die Herstellungskosten fŸr ein Softwareprodukt erheblich senken, verlangt aber einen zeitlichen Mehraufwand bei der Anforderungsspezifikation. Der Aufwand ist sicher gerechtfertigt, wenn man sich vor Augen fŸhrt, dass die Behebung eines Fehlers, der sich wŠhrend der Anforderungsspezifikation einschleicht und erst nach der Auslieferung des Softwareproduktes bemerkt wird, in der klassischen Softwareentwicklung bis zu 100 Mal teurer zu stehen kommt als die Beseitigung eines vorgegebenen Suchstrategie (z.B. Tiefensuche) und einer Inferenzmethode (z.B. SLD- Resolution) liefert [Lloyd 87:40]. Die Kontrollkomponente bestimmt die prozedurale Semantik eines Logikprogramms. Fehlers im Programmcode [Sommerville 96:71]. Logikprogrammierung ist Programmierung durch Beschreibung. Der Softwareentwickler kodiert Fakten und Regeln, die idealerweise in Form von deklarativen oder konditionalen SŠtzen in einer SAS vorliegen, in Hornklauseln, einer Teilmenge der PrŠdikatenlogik. Die Klauseln sind eine Menge von Axiomen, die Relationen zwischen EntitŠten aus dem Anwendungsgebiet festlegen. Anfragen an ein logisches Programm (» Spezifikation) kšnnen als Theoreme formuliert werden und dann mittels der applikationsunabhŠngigen Inferenzprozedur durch deduktive Folgerungen aus den Axiomen bewiesen werden. WŠhrend des Beweises werden Variablen, die in den Anfragen auftauchen, durch Substitutionen an Werte gebunden, die als Rechenergebnisse betrachtet werden kšnnen. 2.4.2 Vorteile von formalen Sprachen als Spezifikationssprachen Auf den ersten Blick scheinen formale Sprachen - und insbesondere das Paradigma der Logikprogrammierung - eine Anwort auf eine Vielzahl von Problemen bei der Anforderungsspezifikation zu geben. Formale Spezifikationen sind prŠzis und eindeutig. Das sind wichtige Voraussetzungen, die erst die formale Verifikation von Darstellungen unterschiedlicher Abstraktionsebenen durch Beweise ermšglichen. Beispielsweise kann man ein Programm mit seiner formalen Spezifikation vergleichen und beweisen, dass das Programm eine gŸltige Implementation der Spezifikation ist. Obwohl die vollstŠndig formale Verifikation von komplexen Softwaresystemen gegenwŠrtig technisch nicht machbar ist, kann die Verifikation von sicherheitskritischen Programmteilen das Vertrauen in die ZuverlŠssigkeit des Softwareproduktes erhšhen [Hall 90:16, Sommerville 96:163]. ZusŠtzlich zur Verifikation erlauben formale Methoden die Konsistenz von formalen <strong>Anforderungsspezifikationen</strong> zu ŸberprŸfen, um Konflikte zwischen den einzelnen Anforderungen auszuschliessen. Beides, Verifikation und KonsistenzprŸfung, sind rein mechanische Aufgaben, die automatisierbar sind. Die Lšsung der Aufgabe ist ausschliesslich von den Eigenschaften der formalen Sprache und von der Gršsse der formalen Anforderungsspezifikation abhŠngig. A logic program is a set of axioms, or rules, defining relations between objects. A computation of a logic program is a deduction of consequences of the program. A program defines a set of consequences, which is its meaning. The art of logic programming is constructing concise and elegant programs that have the desired meaning [Sterling & Shapiro 94:9]. Im Idealfall sollte sich der Softwareentwickler beim Schreiben eines logischen Programms beziehungsweise einer formalen Spezifikation keine Gedanken Ÿber die Kontrollkomponente (prozedurale Semantik) machen mŸssen, sondern sich ausschliesslich auf die Darstellung von wahren und bedingten Sachverhalten (modelltheoretische Semantik) konzentrieren kšnnen. Diese ideale Trennung ist jedoch bei den existierenden Logik-Programmierumgebungen nicht gegeben, da die prozedurale und modelltheoretische Semantik nicht in jedem Fall identisch sind. Es kann Lšsungen geben, die aufgrund der Suchstrategie nicht gefunden werden, obwohl sie logische Konsequenz des Programms sind. Man spricht dann davon, dass die prozedurale Semantik unvollstŠndig ist. Der Softwareentwickler muss deshalb die Reihenfolge der Klauseln sorgfŠltig planen und die Suchstrategie in Betracht ziehen. 2.4.3 Nachteile von formalen Sprachen als Spezifikationssprachen Auf den zweiten Blick haben formale Methoden einen schwerwiegenden Nachteil: Sie sind fŸr Anwendungsspezialisten kaum verstŠndlich. Obwohl die Verwendung von formalen Sprachen wie Z [Spivey 89], VDM [Jones 86], Larch [Guttag & Horning 93], Es ist interessant zu sehen, dass die Logikprogrammierung und die ihr zugrundeliegende mathematische Logik die Unterscheidung zwischen Programm und formaler Spezifikation verwischt, so dass viele logische Programme als ausfŸhrbare Spezifikationen aufgefasst werden kšnnen. Der einzige Unterschied zwischen Programm und Spezifikation liegt darin, dass das Programm gewšhnlich effizienter ist als die Spezifikation [Kowalski 85:11].
30 Kapitel 2 Anforderungen und SpeziÞkationen 29 2.5 Ein Spezifikationsbeispiel 2.5.1 Das Bibliotheksproblem Das Bibliotheksproblem (engl. library problem) ist eine von vier Problembeschreibungen, die die Organisatoren des Fourth International Workshop on Software Specification and Design im Publikationsaufruf als Ausgangspunkt fŸr die BeitrŠge vorgelegt hatten [Marca 87, vgl. Kemmerer 85]. Library Problem Petri-Netze [Peterson 81], Statecharts [Harel 87], logische Programmiersprachen [Lloyd 94] anstelle von voller natŸrlicher Sprache die PrŠzision der Anforderungsspezifikation erhšht und Mehrdeutigkeit ausschliesst, geht das fast immer zu Lasten der guten Lesbarkeit. Das Schreiben und Lesen von formalen Spezifikationen erfordert Kenntnisse der mathematischen Grundlagen (diskrete Mathematik, Logik), mit denen viele Anwendungsspezialisten nicht vertraut sind. Die Anwendungsspezialisten kšnnen deshalb eine formale SAS, nicht unmittelbar durch Reviews validieren, um festzustellen, inwieweit die formalisierten Anforderungen ihr VerstŠndnis der Sachverhalte wiedergibt. Hinzu kommt, dass formale SASen oftmals durch bereichsfremde Softwareentwickler geschrieben werden, die nicht das gleiche Sachwissen wie die Anwendungsspezialisten haben. Falls eine SAS unvollstŠndig ist, sind die Softwareentwickler gezwungen, Annahmen Ÿber das intendierte Systemverhalten zu treffen. Das kann zu MissverstŠndnissen und fehlerhaften Spezifikationen fŸhren. Da formale Spezifikationen bloss Abbildungen der wirklichen Welt sind, kšnnen sie natŸrlich auch Sachverhalte falsch beschreiben, was zu unzulŠssigen Schlussfolgerungen fŸhrt. Selbst wenn die formale Spezifikation korrekt ist, kann die verwendete Beweisprozedur Consider a small library database with the following transactions: 1. Check out a copy of a book / Return a copy of a book. 2. Add a copy of a book to / Remove a copy of a book from the library. 3. Get the list of books by a particular author or in a particular subject area. 4. Find out the list of books currently checked out by a particular borrower. 5. Find out what borrower last checked out a particular copy of a book. . There are two types of users: staff users and ordinary borrowers. Transactions fehlerhaft sein. 1, 2, 4 and 5 are restricted to staff users, except that ordinary borrowers can The real world is not a formal system. A proof, therefore, does not show that, in the real world, things will happen as you expect. So you can never be sure that your specifications perform transaction 4 to find out the list of books currently borrowed by are "correct", however much you prove about them [Hall 90:12]. themselves. The data base must also satisfy the following constraints: ¥ All copies in the library must be available for checkout or be checked out. ¥ No copy of the book may be both available and checked out at the same time. ¥ A borrower may not have more than a predefined number of books checked out at one time. Im Workshop-Band sind zwšlf BeitrŠge veršffentlicht worden, die das Bibliotheksproblem aus unterschiedlichen Blickwinkeln angegangen sind. Die BeitrŠge decken einen breiten Themenbereich ab und fokussieren verschiedene Aspekte im Software- Entwicklungsprozess. HauptsŠchlich ging es den Autoren darum, die in ihrer Forschungsarbeit verfolgten Spezifikationsmethoden und entwickelten Spezifikationssprachen (fragmentarisch) auf das Bibliotheksproblem anzuwenden. Zusammengenommen liefern die BeitrŠge eine Fundgrube von Ungenauigkeiten, auf die die Autoren beim Versuch gestossen sind, die informelle Problemspezifikation mit ihren eigenen Methoden zu verfeinern und in eine detailliertere informelle Spezifikation Ausserdem ist es sehr schwierig, eine formale Spezifikation von informellen Anforderungen abzuleiten, weil der Ableitungsprozess selber weder formalisierbar noch formal validierbar ist [Hoare 87:372]. Unverhofft kommt die natŸrliche Sprache wieder zur HintertŸr herein, wenn es darum geht, die formale Spezifikation in natŸrlicher Sprache zu paraphrasieren, um dem Anwendungsspezialisten verstŠndlich zu machen, what the specification means in real-world terms and why the specification says what it does [Hall 90:18]. Um die nštige Akzeptanz bei den Anwendungsspezialisten zu erreichen und den Zugang zu formalen Spezifikationen zu erleichtern, empfiehlt die Z Schule, formale Spezifikationen massiv mit natŸrlich-sprachlichen Kommentaren anzureichern [Clarke & Wing 96:14]. Dabei machen sich die Autoren aber keinerlei Gedanken Ÿber die Interdependenzen zwischen informellen Kommentaren und formalem Spezifikationstext. Die EinfŸhrung von formalen Sprachen fŸhrt zu enormen Schwierigkeiten, wenn es nicht gelingt, adŠquate Darstellungen zu finden, die auch fŸr den Anwendungsspe- zialisten in eindeutiger Weise verstŠndlich sind.
Seite 1: Danksagung Kontrolliertes Englisch
Seite 4 und 5: Inhaltsverzeichnis iii 5.4.2.6 Frag
Seite 6 und 7: 4 Kapitel 1 Einleitung 3 1.4 Strukt
Seite 8 und 9: 8 Kapitel 2 Anforderungen und Spezi
Seite 10 und 11: 12 Kapitel 2 Anforderungen und Spez
Seite 26 und 27: Anforderungen und SpeziÞkationen 4
Seite 28 und 29: 48 Kapitel 3 InformalitŠt und Form
Seite 30 und 31: InformalitŠt und FormalitŠt im Ei
Seite 32 und 33: 56 Kapitel 4 Kontrollierte natŸrli
Seite 50 und 51: 92 Kapitel 5 Die Sprache Attempto C
Seite 52 und 53: 96 Kapitel 5 Die Sprache Attempto C
Seite 54 und 55: 100 Kapitel 5 Die Sprache Attempto
Seite 68 und 69:
128 Kapitel 5 Die Sprache Attempto
Seite 70 und 71:
Seite 72 und 73:
Seite 74 und 75:
Seite 76 und 77:
Seite 78 und 79:
Seite 80 und 81:
Seite 82 und 83:
Seite 84 und 85:
Seite 86 und 87:
Seite 88 und 89:
Seite 90 und 91:
Seite 92 und 93:
Seite 94 und 95:
Seite 96 und 97:
Seite 98 und 99:
Seite 100 und 101:
Seite 102 und 103:
Seite 104 und 105:
Seite 106 und 107:
Seite 108 und 109:
208 Kapitel 6 Eine Evaluation von A
Seite 110 und 111:
Seite 112 und 113:
Seite 114 und 115:
Seite 116 und 117:
224 Kapitel 7 Arbeiten mit dem Atte
Seite 118 und 119:
228 Kapitel 7 Arbeiten mit dem Atte
Seite 120 und 121:
Arbeiten mit dem Attempto SpeziÞka
Seite 122 und 123:
236 Schlussfolgerungen und offene P
Seite 124 und 125:
240 Literaturverzeichnis Literaturv
Seite 126 und 127:
Seite 128 und 129:
Seite 130 und 131:
Seite 132 und 133:
256 Index Index 255 in Adjunkten 15
Seite 134:
Lebenslauf Ich bin am 28. Juli 1959
Alle anzeigen

Kontrolliertes Englisch für Anforderungsspezifikationen

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?