Vorlesung Software Engineering I

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

1 Vorlesung Software Engineering I
Logische Basiskonzepte 2 Regeln Expertensystem Entscheidungsbäume Entscheidungstabellen Software Engineering I VE 12: Logische Basiskonzepte 1 Version

2 Systemsichten und Modellierung
Statik 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 Software Engineering I VE 12: Logische Basiskonzepte 1 Version

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 Form: WENN … DANN … SONST   (IF THEN ELSE) vor. 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. Software Engineering I VE 12: Logische Basiskonzepte 1 Version

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. Software Engineering I VE 12: Logische Basiskonzepte 1 Version

5 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. Software Engineering I VE 12: Logische Basiskonzepte 1 Version

6 Regelbasierte Expertensysteme
Aufgabe des Inferenzmechanismus (Kontrollsystems) 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 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. Zielgetrieben (backward chaining) oder Rückwärtsverkettung 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. Software Engineering I VE 12: Logische Basiskonzepte 1 Version

7 Geschäftsregeln können auf verschiedene Arten formuliert werden:
in Deutsch in formalem Deutsch in formaler Logik in Fuzzy-Logik in einer deklarativen Computersprache (z.B. SQL) in einer prozeduralen Computersprache (z.B. Java) als Entscheidungsbäume als Entscheidungstabellen Software Engineering I VE 12: Logische Basiskonzepte 1 Version

8 Entscheidungsbäume Entscheidungsbäume sind eine spezielle Darstellungsform von Entscheidungsregeln. ID3-Algorithmus Start mit leerem Baum & voller Beispielmenge finde Attribut, die Datenmenge am Besten klassifiziert(höchste gain). Blatt für dieses Attribut erstellen und die Datenmenge entsprechend aufteilen. Beenden Falls nicht mehr zu klassifizieren Falls keine Daten mehr Software Engineering I VE 12: Logische Basiskonzepte 1 Version

9 Entscheidungsbaum, Beispiel „Erste Hilfe“
Entscheidungsbäume veranschaulichen sequentielle hierarchische Entscheidungen Beispiel Erste Hilfe: ID3-Algorithmus Start mit leerem Baum & voller Beispielmenge finde Attribut, die Datenmenge am Besten klassifiziert(höchste gain). Blatt für dieses Attribut erstellen und die Datenmenge entsprechend aufteilen. Beenden Falls nicht mehr zu klassifizieren Falls keine Daten mehr Software Engineering I VE 12: Logische Basiskonzepte 1 Version

10 Entscheidungsbaum: Konstruktion (1)
Beispielmenge Collateral = Sicherheit, Pfand Software Engineering I VE 12: Logische Basiskonzepte 1 Version

11 Entscheidungsbaum: Konstruktion (2)
Software Engineering I VE 12: Logische Basiskonzepte 1 Version

12 Entscheidungsbaum: Konstruktion nach ID3
Konstruktion nach ID3-Algorithmus: Start mit leerem Baum & voller Beispielmenge finde Attribut, dass die Datenmenge am Besten klassifiziert (höchster „information gain“). Blatt für dieses Attribut erstellen und die Datenmenge entsprechend aufteilen. Beenden Falls nicht mehr zu klassifizieren Falls alle Daten verwendet Software Engineering I VE 12: Logische Basiskonzepte 1 Version

13 Entscheidungsbaum: Konstruktion (3)
Software Engineering I VE 12: Logische Basiskonzepte 1 Version

14 Entscheidungsbaum: Konstruktion (4)
Vorteil: ID3-Algorithmus liefert kleineren Suchbaum Kein Unterschied bei der Klassifikation „Occam‘s Razor“: „entities must not be multiplied beyond necessity" (prefer the simplest hypothesis that fits the data)  bei sonst gleichwertigen Erklärungsalternativen die kürzere / „einfachere“ wählen Software Engineering I VE 12: Logische Basiskonzepte 1 Version

15 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 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. Software Engineering I VE 12: Logische Basiskonzepte 1 Version

16 Entscheidungstabelle
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). Software Engineering I VE 12: Logische Basiskonzepte 1 Version

17 Grundstruktur einer Entscheidungstabelle
Software Engineering I VE 12: Logische Basiskonzepte 1 Version

18 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. Software Engineering I VE 12: Logische Basiskonzepte 1 Version

19 Ursache-Wirkungs-Graphen
Entscheidungstabellen können auch direkt aus Ursache-Wirkungs-Graphen erstellt oder ermittelt werden. Software Engineering I VE 12: Logische Basiskonzepte 1 Version

20 Ursache-Wirkungs-Graphen
Ursache: Einzelne Eingabebedingung oder Äquivalenzklasse von Eingabebedingungen Wirkung: Ausgabebedingung oder Systemtransformation Vorgehen Ursachen und Wirkungen werden durch Analyse der Spezifikation ermittelt, jeder Ursache und jeder Wirkung (=Teilspezifikation) wird eine eindeutige Nummer zugeordnet. Ziel Zerlegung der Spezifikation in handhabbare Teile. Erfassen von Abhängigkeiten zwischen Ursachen und Wirkungen Transformation der Spezifikation in Ursache-Wirkungs-Graph (und-oder-Kanten) Umformung des Graphen in eine Entscheidungstabelle Software Engineering I VE 12: Logische Basiskonzepte 1 Version

21 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, Software Engineering I VE 12: Logische Basiskonzepte 1 Version

22 Übung Entscheidungstabelle
Erstellung einer Entscheidungstabelle anhand des folgenden Beispielszenarios: 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. Bedingungen festlegen (Alle Bedingungen haben booleschen Charakter.) Im ersten Schritt werden alle Bedingungen und mögliche Werte oder Wertebereiche dieser Bedingungen ermittelt. Im Beispiel können drei Bedingungen identifiziert werden: Patientin hat ansteckende Krankheit (j/n) Besuch innerhalb Besuchszeit (j/n) Patientin hat Fieber (j/n) Aktionen angeben Im zweiten Schritt werden alle resultierenden Aktionen aufgelistet: Besuchszeit maximal 30 Minuten Besuch ablehnen Besuch mit Begleitung einer Schwester Normalbesuch in Besuchszeit Software Engineering I VE 12: Logische Basiskonzepte 1 Version