Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Vorlesung Software Engineering I

Ähnliche Präsentationen


Präsentation zum Thema: "Vorlesung Software Engineering I"—  Präsentation transkript:

1 Vorlesung Software Engineering I
Logische Basiskonzepte 2 Regeln Entscheidungstabellen Fuzzy-Logik Expertensystem Version Software Engineering I VE 14: Logische Basiskonzepte 2

2 Statik Dynamik Logik Basiskonzepte
Funktionen Daten Datenstrukturen Architektur Dynamik Kontrollstrukturen Zustände Prozesse Zeitliches Verhalten Logik Abhängigkeiten Entscheidungstabellen Mathematik Regeln Beschreiben die feste Struktur des Systems, die sich während der Laufzeit nicht ändert. Beschreiben das Verhalten und die Veränderungen während der Laufzeit. Beschreiben die Programmfunktion logisch und mathematisch Version Software Engineering I VE 14: Logische Basiskonzepte 2

3 Regeln Regeln sind logische Ausdrücke, mit denen aus bekannten Fakten neue Fakten gefolgert werden können. Eine Produktionsregel (auch Regel oder Produktion genannt) ist ein geordnetes Paar (P,Q) der beiden Wörter P und Q. Das Wort P wird Prämisse und das Wort Q Konklusion der Regel (P,Q) genannt. Die Regeln liegen in der folgenden Form vor: WENN … DANN … SONST   (IF THEN ELSE). Eine Regel könnte beispielsweise folgendermaßen aussehen: WENN Herdplatte heiß UND kein Topf auf Herd DANN schalte Herd aus Der WENN-Teil der Regel ist also die Prämisse, der DANN-Teil die Konklusion. Version Software Engineering I VE 14: Logische Basiskonzepte 2

4 Geschäftsregeln Eine kognitive Anwendung haben Produktionsregeln in regelbasierten Systemen: Hier spricht man von Produktionsregeln oder Geschäftsregeln, wenn die Regeln, mit denen das System arbeitet, innerhalb eines industriellen Produktionsprozesses angewendet werden. z.B.: WENN das Telefonat länger als 30 Minuten gedauert hat UND das Telefonat zwischen 18:00 Uhr und 24:00 Uhr geführt wurde UND der Tarif des Besitzers Student 30+ heißt DANN wende 10 % Rabatt auf das geführte Telefonat an. Business-Rules werden vom Fachbereich eines Unternehmens häufig als Vorgabe für Softwareentwickler im Pflichtenheft niedergeschrieben und müssen dann von diesen manuell und aufwendig in die Computerprogramme eingearbeitet werden. Business-Rule-Management-Systeme, kurz BRMS, bieten hier die Möglichkeit, diese Regeln separat in einem Business-Rule-Repository zu verwalten, um so mehr Transparenz (für den Fachbereich), Flexibilität (bei Änderungen der Business-Rules) und Kosteneinsparungen (durch schnellere Entwicklungs- und Änderungszyklen des Computerprogramms) zu erreichen. Die Ausführung der Regeln aus dem Repository wird dann von einer Business-Rule-Engine gesteuert. Version Software Engineering I VE 14: Logische Basiskonzepte 2

5 Geschäftsregeln Geschäftsregeln können auf verschiedene Arten formuliert werden in … Deutsch formalem Deutsch Entscheidungs-tabellen Entscheidungs-bäume Klassifikations-bäume formaler Logik einer deklarativen Computersprache (z.B. SQL) einer prozeduralen Computersprache (z.B. Java) Version Software Engineering I VE 14: Logische Basiskonzepte 2

6 Regelbasiertes System
Ein regelbasiertes System besteht aus: Der Regelbasis, die das gespeicherte Wissen enthält Der Faktenbasis, in der die zu interpretierenden Fakten (aktuelle Systemdaten) abgelegt sind Dem Inferenzmechanismus, der die Schlussfolgerung zieht, also die Regeln auf die Fakten anwendet. Wissen in Regelform Aktuelle Parameterwerte 6 Version Software Engineering I VE 14: Logische Basiskonzepte 2

7 Regelbasierte Expertensysteme
Aufgabe des Inferenzmechanismus (Kontrollsystem) ist die Identifikation geeigneter Regeln, das Anwenden ausgewählter Regeln sowie die Aktualisierung der Datenbank. Auswahlmechanismen für die nächste anzuwendende Regel sind entweder datengetrieben, zielgetrieben oder eine Kombination dieser beiden Möglichkeiten. Datengetrieben (forward chaining) oder Vorwärtsverkettung bedeutet Ein Fakt liegt vor – eine „WENN Fakt DANN …“-Regel wird angewendet. Hier wird versucht, auf Grundlage von Fakten eine Diagnose zu stellen, also zu einem meist noch unbekannten Ziel zu kommen. Unter zielgetrieben (backward chaining) oder Rückwärtsverkettung versteht man den rückwärtigen Ansatz Ein Fakt liegt vor – eine „WENN … DANN Fakt“-Regel wird angewendet. Hier wird versucht, eine Hypothese zu beweisen. Regelbasierte Systeme sind neben fallbasierten Systemen die Grundlage von Expertensystemen. Die Verwaltung der Regeln erfolgt meist in einem Business-Rule-Repository als Teil eines Business-Rule-Management-Systems. Version Software Engineering I VE 14: Logische Basiskonzepte 2

8 Entscheidungstabellen
Entscheidungstabellen sind eine Möglichkeit, komplexe Regelwerke in übersichtlicher Weise darzustellen. Unter einer Regel ist dabei eine Vorschrift zu verstehen, welche Aktionen bei Vorliegen einer gegebenen Komposition von Bedingungen durchzuführen sind. Ein Regelwerk ist eine Zusammenstellung unterschiedlicher Regeln. Entscheidungstabellen sind eine übersichtliche Zusammenfassung von Entscheidungsregeln, die Auskunft über Maßnahmen geben, die unter bestimmten Bedingungskonstellationen zu ergreifen sind. Entscheidungstabellen werden u. a. beim Entwurf von Programmen eingesetzt, um komplexe Abhängigkeiten zwischen mehreren Bedingungen und dem jedes Mal auszuführenden Code übersichtlich und vollständig darzustellen. Ergänzend kann das Regelwerk oft durch einen übersichtlicheren Entscheidungsbaum graphisch dargestellt werden. Die Tabelle ist jedoch systematischer und kann deshalb leichter als der Baum auf Widerspruchsfreiheit und Vollständigkeit überprüft werden. Version Software Engineering I VE 14: Logische Basiskonzepte 2

9 Entscheidungstabellen
Die Begriffe und der Aufbau einer Entscheidungstabelle sind seit 1979 durch die Norm DIN festgelegt. Sie besteht demnach aus vier Teilen: Der Bedingungsteil enthält die Beschreibung der für die Entscheidungssituation relevanten Bedingungen. Der Aktionsteil enthält die Beschreibung aller möglichen Aktionen. Der Bedingungsanzeigeteil enthält die möglichen Kombinationen von Bedingungen in Form von Symbolen ((j)-Bedingung erfüllt, (n)-Bedingung nicht erfüllt, (–)-Bedingung irrelevant). Im Aktionsanzeigeteil sind die möglichen Aktionen in Abhängigkeit von bestimmten Bedingungen durch Symbole markiert ((x)-Aktion ausführen, (–)-Aktion nicht ausführen). Version Software Engineering I VE 14: Logische Basiskonzepte 2

10 Grundstruktur einer Entscheidungstabelle
Version Software Engineering I VE 14: Logische Basiskonzepte 2

11 Entscheidungstabelle
Ordnung der Bedingungen und Aktionen Bedingungen und Aktionen sinnvoll ordnen zur besseren Übersichtlichkeit. Die Anordnung der Bedingungen ergibt sich häufig aus der Reihenfolge, in der sie geprüft werden. Ebenso ergibt sich die Reihenfolge der Aktionen aus dem Arbeitsablauf. Konsolidierung Überprüfen, ob die Anzahl der Regeln verkleinert werden kann, indem Regeln, die zu den gleichen Aktionen führen, entfernt werden. Anstelle des Bedingungsanzeigers (j/n) tritt dann ein Irrelevanzzeichen (–), welches anzeigt, dass für die Ausführung einer Aktion eine Bedingung nicht geprüft werden muss. Redundante Regeln zusammenfassen Prüfung auf Widerspruchsfreiheit Klären, ob die Zusammenfassung der Regel korrekt erfolgt ist, also ob keine Regeln mit gleichen Bedingungen zu unterschiedlichen Aktionen führen. Version Software Engineering I VE 14: Logische Basiskonzepte 2

12 Ursache-Wirkungs-Graphen
Umformung des Graphen in eine Entscheidungstabelle Eintragen von Abhängigkeiten zwischen Ursachen und Wirkungen Transformation der Spezifikation in Ursache-Wirkungs-Graph (und-oder-Kanten) Ursachen und Wirkungen werden durch Analyse der Spezifikation ermittelt, jeder Ursache und jeder Wirkung wird eine eindeutige Nummer zugeordnet. Ursachen und Wirkung jeder Teilspezifikation ermitteln Ursache: Einzelne Eingabebedingung oder Äquivalenzklasse von Eingabebedingungen Wirkung: Ausgabebedingung oder Systemtransformation Zerlegung der Spezifikation in handhabbare Teile. Entscheidungstabellen können auch direkt aus Ursache-Wirkungs-Graphen erstellt oder ermittelt werden. Version Software Engineering I VE 14: Logische Basiskonzepte 2

13 Ursache-Wirkungs-Graphen: Beispiel
Spezifikation zaehle: Die Prozedur zaehle liest solange Zeichen, bis ein Zeichen erkannt wird, das kein Großbuchstabe ist, oder gesamtzahl den größten CARDINAL-Wert erreicht hat. ist ein gelesenes Zeichen großer Konsonant oder Vokal, wird gesamtzahl um 1 erhöht. ist der Großbuchstabe ein Vokal, so wird vokalanz um 1 erhöht. Bei Beendigung der Prozedur werden gesamtzahl und vokalanz zurückgegeben Ursachen U1: char ist großer Konsonant U2: char ist großer Vokal U3: gesamtzahl < max(CARDINAL) Wirkungen W1: gesamtzahl wird inkrementiert W2: vokalanz wird inkrementiert W3: char wird gelesen W4: Prozedur wird beendet Fritzsch, Version Software Engineering I VE 14: Logische Basiskonzepte 2

14 Entscheidungs-/Klassifikationsbäume
Entscheidungsbäume sind eine spezielle Darstellungsform von Entscheidungsregeln. Sie veranschaulichen aufeinander folgende hierarchische Entscheidungen. Grundsätzliche Idee der Klassifikationsbaum-Methode ist es, zuerst den Eingabedatenraum des Testobjekts nach verschiedenen testrelevanten Gesichtspunkten jeweils getrennt voneinander in Klassen zu zerlegen, um dann durch die Kombination geeigneter Klassen zu Testfällen zu kommen. Rekursiver Abstieg über mehrere Ebenen ergibt einen Baum von Klassifikationen. Bildung von Testfällen durch Kombination von Klassen unterschiedlicher Klassifikationen. Literatur: Version Software Engineering I VE 14: Logische Basiskonzepte 2

15 Beispiel Klassifikationsbaum-Methode
Computer-Vision: Erkennung von Objekten Erweiterungen für kontinuierliche Werteverläufe automatische Testwerkzeuge Beispiel nach Wegener/Grochtmann, DaimlerChrysler AG Version Software Engineering I VE 14: Logische Basiskonzepte 2

16 Klassifikationsregeln
Vorhersageattribute V1, V2, ..., Vn Vorhergesagtes Attribut A Klassifikationsregel P1(V1)  P2(V2)  ...  Pn(Vn)  A = c Prädikate P1, P2, .., Pn Konstante c Beispielregel (wieAlt>35)  (Geschlecht =m)  (Autotyp=Coupé)  (Risiko=hoch) Version Software Engineering I VE 14: Logische Basiskonzepte 2 16

17 Klassifikations-/Entscheidungsbaum
Version Software Engineering I VE 14: Logische Basiskonzepte 2 17

18 Klassifikations/Entscheidungsbaum
Version Software Engineering I VE 14: Logische Basiskonzepte 2 18

19 Klassifikations/Entscheidungsbaum
(wieAlt>35)  (Geschlecht =m)  (Autotyp=Coupé)  (Risiko=hoch) Version Software Engineering I VE 14: Logische Basiskonzepte 2 19

20 Erstellen von Entscheidungs-/ Klassifikationsbäumen
Trainingsmenge Große Zahl von Datensätzen, die in der Vergangenheit gesammelt wurden Sie dient als Grundlage für die Vorhersage von „neu ankommenden“ Objekten Beispiel: Neuer Versicherungskunde wird gemäß dem Verhalten seiner „Artgenossen“ eingestuft Rekursives Partitionieren Fange mit einem Attribut an und spalte die Tupelmenge Jede dieser Teilmengen wird rekursiv weiter partitioniert bis nur noch gleichartige Objekte in der jeweiligen Partition sind Eingabe: Knoten n, Partition D, Zerlegungsmethode S Ausgabe: Klassifikationsbaum für D, Wurzel n BuildTree(n,D,S) Wende S auf D an und finde die richtige Zerlegung Wenn eine gute Partitionierung gefunden ist Kreiere zwei Kinder n1 und n2 Partitioniere D in D1 und D2 BuildTree(n1,D1,S) BuildTree(n2,D2,S) Version Software Engineering I VE 14: Logische Basiskonzepte 2 20

21 Fuzzy-Theorie Lotfi A. Zadeh führte 1965 die
Fuzzy-Theorie ein als eine Theorie der „graded concepts“ „in which everything is a matter of degree or to put it figuratively, everything has elasticity.“ 1995 IEEE Medal of Honor Version Software Engineering I VE 14: Logische Basiskonzepte 2

22 Klassische Mengenlehre  Fuzzy-Mengen
. Cantor hatte Mengen wie folgt definiert: „eine Menge M ist eine Zusammenfassung von wohlbestimmten und wohlunterschiedenen Objekten unserer Anschauung oder unseres Denkens (welche Elemente von M genannt werden) zu einem Ganzen.“ Die Theorie der Fuzzy-Mengen erweitert nun die Begriffe der klassischen Mengenlehre von Cantor mit den dort entwickelten Operationen (siehe Bild). Die Wohlbestimmtheit und Wohlunterschiedenheit wird dabei aufgegeben. Die Theorie unscharfer Mengen, der Fuzzy-Mengen, kann sowohl als eine Verallgemeinerung der klassischen Mengenlehre als auch als eine Verallgemeinerung der zweiwertigen (dualen) Logik angesehen werden [Zimmermann 1993]. Da die verallgemeinerten Mengentheorie leichter nachzuvollziehen ist als die Theorie der verallgemeinerten Logik, wird hier die Fuzzy Logic über die Fuzzy-Mengen eingeführt Version Software Engineering I VE 14: Logische Basiskonzepte 2

23 Fuzzy-Menge In der bekannten Mengenlehre nach Cantor gehört ein Element entweder zu einer Menge, oder es gehört nicht dazu. Es gibt keine Zwischenwerte, die es Elementen erlauben, nur teilweise in einer Menge enthalten zu sein. Ein derartiges Konzept wurde mit der Fuzzy-Menge eingeführt! Version Software Engineering I VE 14: Logische Basiskonzepte 2

24 Zugehörigkeitsfunktionen
Def.: Sei X eine Menge und f: X  [0,1]. Dann heißt f eine Zugehörigkeitsfunktion oder eine Fuzzy-Menge auf X. „graded concepts“ werden beschrieben durch die lineare Ordnung auf [0,1] Ersetze [0,1] durch eine beliebige Ordnung! Version Software Engineering I VE 14: Logische Basiskonzepte 2

25 Fuzzy Logik Modellierung vager, unpräziser und unsicherer Informationen Version Software Engineering I VE 14: Logische Basiskonzepte 2

26 Fuzzy-Control http://fuzzy.cs.uni-magdeburg.de/studium/fuzzy/#Folien
Version Software Engineering I VE 14: Logische Basiskonzepte 2

27 Anwendungen der Fuzzy-Logik
Die meisten Anwendungen wurden im Bereich der Fuzzy-Regelung und der Fuzzy-Expertensysteme entwickelt. Andere industrielle Anwendungsgebiete für Fuzzy-Systeme sind z.B. Fuzzy-Datenanalyse Fuzzy-Bildverarbeitung Fuzzy-Informations-Retrieval Fuzzy-Datenbanken entscheidungsunterstützende Systeme Version Software Engineering I VE 14: Logische Basiskonzepte 2

28 Fuzzy-System: Architektur
• Das Fuzzifizierungs-Interface nimmt den aktuellen Meßwert auf und f¨uhrt gegebenenfalls eine Transformation des Meßwertes in einen geeigneten Wertebereich durch (z.B. k¨onnte die Skalierung so gew¨ahlt werden, daß s¨amtliche Eingabewerte zwischen −1 und +1 liegen). Das Fuzzifizierungs-Interface kann außerdem dazu verwendet werden, den Meßwert in einen linguistischen Term oder eine Fuzzy-Menge umzuwandeln. Im allgemeinen wird der scharfe Meßwert x0 in die Fuzzy-Menge 1I{x0} mit 1I{x0}(x) = ( 1, falls x = x0 0, sonst. transformiert. Liegen Informationen ¨uber die Genauigkeit der Messung vor oder ist die Messung an sich unscharf, k¨onnen anstelle der Fuzzy-Menge 1I{x0}, die die charakteristische Funktion der Menge {x0} darstellt, andere Fuzzy-Mengen auftreten. • Die Wissensbasis beinhaltet zum einen Informationen ¨uber die Wertebereiche der Meß- und Stellgr¨oßen, eventuelle Normierungen und die zu den linguistischen Termen assoziierten Fuzzy-Mengen. Diese Informationen bilden die Datenbasis. Zum anderen enth¨alt die Wissensbasis eine Regelbasis in Form von linguistischen Kontrollregeln. • Die Entscheidungslogik stellt das Rechenwerk des Fuzzy-Reglers dar, in dem aus den Meßgr¨oßen mit Hilfe der Wissensbasis Informationen ¨uber die Stellgr¨oße gewonnen werden. • Das Defuzzifizierungs-Interface hat die Aufgabe, aus den von der Entscheidungslogik gegebenen Informationen ¨uber die Stellgr¨oße einen scharfen Stellwert zu bestimmen — gegebenenfalls einschließlich einer entsprechenden Transformation. Version Software Engineering I VE 14: Logische Basiskonzepte 2

29 Fuzzy-Regler für Wassertemperatur
Version Software Engineering I VE 14: Logische Basiskonzepte 2

30 Fuzzy-Regler für Wassertemperatur
Um die Temperatur des neu zugeführten Wassers abhängig von der aktuellen Temperatur zu machen, sind Regeln nötig, wie z.B.: WENN Badewassertemperatur = ``heiß'', DANN Temperaturzufuhr_blau = ``stark'', Temperaturzufuhr_rot = ``aus'‚ WENN Badewassertemperatur = ``warm'', DANN Temperaturzufuhr_blau = ``mittel'', Temperaturzufuhr_rot = ``aus'‚ WENN Badewassertemperatur = ``kühl'', DANN Temperaturzufuhr_blau = ``aus'', Temperaturzufuhr_rot = ``mittel'‚ WENN Badewassertemperatur = ``kalt'', DANN Temperaturzufuhr_blau = ``aus'', Temperaturzufuhr_rot = ``stark'' Nun muss geprüft werden, in welchem Grad die Regeln betroffen sind. Dazu werden alle Regeln der Reihe nach durchgegangen. Es wird festgestellt, dass alle Regeln bearbeitet werden müssen. Version Software Engineering I VE 14: Logische Basiskonzepte 2

31 Fuzzy-Regler für Wassertemperatur
Die Fuzzy-Menge muss nun noch in einen scharfen Wert umgewandelt werden. Hierzu wird üblicherweise der Schwerpunkt der Fläche bestimmt, dieser auf die x-Achse projeziert, und der sich ergebende Wert als Ausgangswert benutzt. Für die Ausgangsvariable „rotes Ventil“ ergibt sich „aus“ (der Schwerpunkt ist direkt über geschlossen“), für das „blaue Ventil“ ein Öffnungsgrad des Ventils von ungefähr 86%. Version Software Engineering I VE 14: Logische Basiskonzepte 2

32 Bewertung Fuzzy-Regler/Systeme
Die Vorteile Schnelle, realistische, problembezogene, aussagekräftigere Modellierung auch komplexer Systeme mit nichtlinearem Verhalten ermöglichen. Die Beschreibung und das Verhalten eines Systems ist mit linguistischen Ausdrücken möglich, dies ist meist einfacher als mathematische Beschreibungsverfahren. Gute Wartbarkeit: Ist die Regelung in einem Bereich nicht gut, werden entsprechende Regeln ergänzt oder verändert, bzw. die Definition der Fuzzy-Mengen verändert. Gute Nachvollziehbarkeit der Ergebnisse: Die Regeln können der Reihe nach notfalls auch per Hand durchgerechnet werden. Die Nachteile Nicht lernfähig (im Gegensatz zu neuronalen Netzen). Damit ist keine automatische Anpassung an eine sich verändernde Umgebung möglich. Fehler in der Erstellungsphase können später kaum wieder verbessert werden. Finden einer Defuzzifizierungsmethode kann schwierig sein. Der Vorteil der Unschärfe wird durch Rückübersetzung in diskrete Werte oft zerstört. Die Berechnung des scharfen Endwertes ist entweder komplex, langsam und gut, oder schnell, dafür aber mit einem schlechteren Ergebnis. Geschwindigkeit  Ergebnisgüte. Version Software Engineering I VE 14: Logische Basiskonzepte 2

33 Fuzzy-Expertensysteme
Fuzzy-Logic eignet sich wegen der guten Verarbeitung von vagen Informationen, wie sie in der Praxis recht häufig vorkommen, gut für den Einsatz in Expertensystemen. Unterschied zu konventionellen Expertensystemen ist, dass Fuzzy-Expertensysteme keine Entscheidungsbäume durchlaufen, sondern wie bei der Fuzzy-Regelung Regeln partiell aktivieren und sie zu einem Gesamtergebnis verschmelzen. Somit kann auch widersprüchliches Wissen mehrerer Experten genutzt werden, was sonst nicht möglich ist: In konventionellen Systemen müssen die Regeln konsistent sein. Die Anzahl der Regeln, die normalerweise notwendig ist, um ein Wissensgebiet zu beschreiben, kann deutlich reduziert werden (Faktor ). Damit kann die Entwicklungszeit eines Fuzzy-Expertensystems im Vergleich zu einem herkömmlichen Expertensystem oft wesentlich verkürzt werden. Für die Ermittlung einer Antwort werden nicht alle Informationen benötigt. Vorhandene Daten werden ausgewertet und die zutreffendsten Ergebnisse zurückgeliefert. Fuzzy Logic ist eine interessantes Konzept, Unschärfen verschiedener Art zu verarbeiten. Die Mathematik der Fuzzy Logic stellt dazu die benötigten Hilfsmittel zur Verfügung. Dieser Text konnte nur ein begrenzten Teil der Fuzzy-Theorie wiedergeben; auch wurde nur eine Beispielanwendung genauer vorgestellt. Trotzdem hofft der Autor, daß die Denkweise der Fuzzy-Logic etwas klarer geworden ist und die Potentiale der Fuzzy Logic erkennbar wurden. Die erfolgreichste Anwendung der Fuzzy-Logic war bisher die Fuzzy-Regelung, die sich in der Industie für die Regelung komplexer Anlagen als ein hervorragendes Hilfsmittel herausgestellt hat. Der Aufwand, ein komplexes nichtlineares Regelungsproblem zu lösen, kann mit Hilfe der Fuzzy-Regelung üblicherweise deutlich reduziert werden. Geopfert wird dabei nicht die Präzision klassischer mathematischer Modelle an sich, sondern nur die zwecklose Präzision, die oft gar nicht nötig ist. Wenn ein Sensor z.B. von Natur aus ungenau ist, ist es übertrieben, nach exakten Modellen zu suchen. Alle zur Zeit mit Fuzzy-Methoden erzielten Problemlösungen in der Industrie wären wohl auch mit konventionellen mathematischen/informatischen Methoden lösbar. Der Unterschied ist nur, daß Fuzzy-Lösungen oft sehr viel einfacher, kostengünstiger, leichter zu entwickeln und leichter zu implementieren sind. Die Lösungen sind vielleicht nicht perfekt, aber es ist zubedenken, daß die letzten 10% Genauigkeit oft 90 des Aufwands kosten. Damit werden Fuzzy-Systeme wirtschaftlich sinnvoll und vertretbar. In anderen Bereichen, wie z.B. den Fuzzy-Expertensystemen, ermöglichen Fuzzy-Systeme Lösungen, die sonst wohl nicht möglich wären. Bisher wurde die Fuzzy-Theorie auf recht wenige Systeme angewendet, erfolgreicher Einsatz woanders ist mehr als wahrscheinlich. Statt die Fuzzy-Theorie als eine Theorie zu verstehen, kann die ``Fuzzifizierung'' allgemein als eine Methode betrachtet werden, die allgemein eingesetzt werden kann, eine ``scharfe'' Theorie in eine ``fuzzige'' Form zu überführen. So gibt es eine Verallgemeinerung der Automatentheorie, die Zusammenhänge gut wiederspiegeln: unscharfe kognitive Abbildungen, fuzzy cognitive maps (FCMs). Auch andere Theorien sind schon fuzzifiziert worden, z.B. die Theorie der Fuzzy-Differentialgleichungen und ähnliche. Als Resümee kann festgehalten werden, daß die Fuzzy-Logic vielleicht kein Allheilmittel oder Wunderwaffe ist. Es wurden schon viele Anwendungsmöglichkeiten angedacht. Es ist auf Dauer zu hoffen, daß die Fuzzy Logic (vielleicht insbesondere in Kombination mit neuronalen Netzen) zu einer angenehmeren und verständlicheren Schnittstelle zwischen technischen Systemen und Menschen führt. Version Software Engineering I VE 14: Logische Basiskonzepte 2

34 Beispiel Juristisches Expertensystem
Bei der Bemessung eines Schmerzensgeldes nach § 847 Abs. 1 BGB stellen Größe, Heftigkeit und Dauer der Schmerzen, Leiden und Entstellungen die wesentlichen Kriterien dar. Hier soll nur ein einziges Kriterium eine Rolle spielen, nämlich die Dauer der Schmerzen. Folgende linguistische Regelbasis wird erstellt: Wenn Dauer der Schmerzen ist kurz dann Schmerzensgeld ist wenig Wenn Dauer der Schmerzen ist lang dann Schmerzensgeld ist viel Version Software Engineering I VE 14: Logische Basiskonzepte 2

35 Beispiel Juristisches Expertensystem
Das Regelwerk verwendet zwei linguistische Variablen: Dauer der Schmerzen und Schmerzensgeld. Die Variable Dauer der Schmerzen kann zwei Ausprägungen annehmen: kurz und lang, die Variable Schmerzensgeld kann ebenfalls zwei Ausprägungen annehmen: wenig und viel. Natürlich müssen die Fuzzy-Mengen, die die Ausprägungen beschreiben, definiert werden: Version Software Engineering I VE 14: Logische Basiskonzepte 2

36 Beispiel Juristisches Expertensystem
Analog werden die Ausprägungen für das Schmerzensgeld definiert. In diesem Beispiel hat der Richter nur die Wahl eines Schmerzensgeldes zwischen 0 und 500 EUR. Auch in der Auswahl der linguistischen Symbole ist der Richter stark eingeschränkt: wenig Schmerzensgeld liegt "um die 100", viel Schmerzensgeld liegt "um die 400", entsprechend der folgenden Grafik: Version Software Engineering I VE 14: Logische Basiskonzepte 2

37 Beispiel Juristisches Expertensystem
Dem Richter liegt nun ein Fall vor, bei der die Klägerin unstreitig 2 Wochen Schmerzen erdulden musste. Da die Dauer der Schmerzen das einzige Kriterium zur Bestimmung des Schmerzensgeldes ist, wird der Richter seine beiden Regeln anwenden. Die Dauer von 2 Wochen hat zu "kurz" eine Zugehörigkeit von 2/3 und zu "lang" eine Zugehörigkeit von 1/3. Version Software Engineering I VE 14: Logische Basiskonzepte 2

38 Beispiel Juristisches Expertensystem
Die Prämisse der ersten Regel ist zu 2/3 erfüllt, die Prämisse der zweiten Regel ist zu 1/3 erfüllt. Fuzzy-Inferenz kann nun den Widerspruch lösen, dass die Prämissen beider Regel "irgendwie" erfüllt sind, indem beide Regeln Gültigkeit haben. Das Schmerzensgeld wird also zu 2/3 "wenig" und zu 1/3 "viel". Der Schwerpunkt der Flächen, die durch die beiden Konklusionen "2/3 wenig" und "1/3 viel" gebildet werden, liegt bei 200. Das Fuzzy-Regel-System empfiehlt dem Richter ein Schmerzensgeld in Höhe von 200. Der Schwerpunkt der Flächen, die durch die beiden Konklusionen "2/3 wenig" und "1/3 viel" gebildet werden, liegt bei 200. Das Fuzzy-Expertensystem empfiehlt dem Richter ein Schmerzensgeld in Höhe von 200. Version Software Engineering I VE 14: Logische Basiskonzepte 2

39 Fragen Software Engineering I Version 10.11.2018
VE 14: Logische Basiskonzepte 2

40 Übung Entscheidungstabelle
Bereichsleiter Schmid möchte eine Mitarbeiterin im Krankenhaus besuchen. Er informiert sich telefonisch an der Information über die Besuchsmöglichkeiten und erhält folgende Antwort: Die Patientin kann ohne Einschränkungen innerhalb der Besuchszeit besucht werden, sofern keine ansteckende Krankheit vorliegt und sie kein Fieber hat. Außerhalb der Besuchszeit ist in diesem Fall eine Schwester als Begleitung erforderlich. Falls die Patientin eine ansteckende Krankheit hat, werden Besuche ganz abgelehnt. Wenn die Krankheit nicht ansteckend ist, die Patientin aber Fieber hat, darf der Besuch innerhalb der Besuchszeit maximal 30 Minuten betragen. Außerhalb der Besuchszeit dürfen Patienten mit Fieber nicht besucht werden.  Helfen Sie Herrn Schmid und erstellen Sie ihm eine Entscheidungstabelle. Version Software Engineering I VE 14: Logische Basiskonzepte 2


Herunterladen ppt "Vorlesung Software Engineering I"

Ähnliche Präsentationen


Google-Anzeigen