Prof. Dr.-Ing. Dagmar Meyer Software Engineering 2 ANFORDERUNGSANALYSE UND -MODELLIERUNG

Transkript

1 2 ANFORDERUNGSANALYSE UND -MODELLIERUNG

2 Modellierung von Anforderungen mit der UML Unified Modeling Language Komplexe Notationssprache Zweck - Modellierung, Dokumentation, Spezifizierung, Visualisierung komplexer Softwaresysteme Einsatzgebiete - Statische und dynamische Modelle - Analyse, Design, Architektur 2

3 Wozu trägt die UML bei? Hilfe zur Strukturierung großer Softwarepakete - Heute unverzichtbar für die Erstellung von Softwarearchitekturen Kommunikation innerhalb des Entwicklungsteams - Einheitliche Notation für Architekturbeschreibungen, Designs usw., Sprachunabhängigkeit - Quasi-Standard, weltweit akzeptiert und angewendet Informationsaustausch zwischen Auftraggeber (Kunde) und Auftragnehmer - Diskussion von Lösungsansätzen - Prüfung, ob alle vom Kunden gewünschten Features berücksichtigt sind - Besseres Verständnis des Systems (auf beiden Seiten ) Automatische Umsetzung in Code (z. B. C++, Java) möglich - Unterstützung durch UML-Modellierungswerkzeuge - Generierung von Klassen, (leeren) Methoden - Einige Werkzeuge beherrschen auch die Umsetzung von Abläufen und Sequenzen in Code 3

4 Historische Entwicklung August 2011 UML Ö ffentliche Diskussion UML 1.5 UML 1.4 UML 1.3 Akzeptanz durch OMG, Nov Endgültige Vorlage bei der OMG, Sep. '97 Erste Vorlage bei der OMG, Jan. '97 Web Juni '96 UML 1.1 UML 1.0 UML 0.9 "UML Partners" OOPSALA '95 Unified Method 0.8 Sonstige Methoden Booch Methode OMT Rumbaugh OOSE Jacobson 4

5 Die UML 2.4 kennt 14 Diagrammtypen 5

6 UML-Modellierungswerkzeuge Modellierungswerkzeuge sind mehr als einfache "Zeichenprogramme" Unterstützung der UML-Diagrammtypen und der jeweils erlaubten Notationen State of the Art: Speicherung des Modells in einem standardisierten XML-Format Zusätzlich: - Sicherstellen der Konsistenz des aus mehreren Diagrammen bestehenden Systemmodells - Eingabemöglichkeiten für ergänzende Dokumentation - Generierung von Reports (Dokumentation des Modells) Wichtig für den kommerziellen Einsatz in Projekten: - Generierung von Quellcode-Rümpfen in diversen Programmiersprachen (vorzugsweise C++ und Java) aus dem Modell - Reverse Engineering: Quellcode kann importiert werden automatische Generierung ausgewählter Diagrammtypen aus dem Modell - Round-Trip-Engineering: Änderungen im Quellcode werden automatisch in das UML-Modell übernommen und umgekehrt (automatische Synchronisation von Quellcode und Modell) Beispiele - Rational Rhapsody (IBM) - objectif (microtool) - Together (Borland) - Artisan Studio (atego) 6

7 Freies Werkzeug astah community 7

8 Idee der UML: Unterschiedliche (An-)Sichten eines Systems Es gibt unterschiedliche Sichten auf denselben Gegenstand Jede Sicht versteckt bestimmte Details und hebt andere hervor Einige Details sind nur in einer Sicht zu erkennen Genauso bietet die UML unterschiedliche Sichten auf das Gesamtsystem Jede Sicht ist "spezialisiert" auf bestimmte Aspekte und verwendet eine Auswahl der zur Verfügung stehenden Diagrammtypen 8

9 Aspekte der Modellierung Anwendersicht Was leistet das System? Mit wem/was interagiert es? Use Case View Architekturbeschreibung Struktur der Software Interne Funktionalität Sprach- und Hardwareabhängige Aspekte (Dateien, Aufteilung auf Hardwarekomponenten) Implementation View Logical View 9

10 Diagrammtypen der UML 2 (1) Diagrammtyp Klassendiagramm Paketdiagramm Objektdiagramm Verwendung Beschreibt die interne statische Struktur des Systems. Enthält alle relevanten Strukturzusammenhänge und Datentypen. Brücke zu dynamischen Diagrammen. Für die Modellierung der Softwarestruktur unverzichtbar. Im Klassendiagramm wird die Frage "Aus welchen Klassen besteht mein System und wie stehen diese untereinander in Beziehung?" beantwortet. Logische Zusammenfassung von Klassen zu Paketen. Zusammensetzung von Komponenten aus Paketen. Die Modellierung von Abhängigkeiten (Import) und Beziehungen ist möglich. Das Paketdiagramm gibt Antworten auf die Frage "Wie kann ich mein Modell so schneiden, dass ich den Überblick bewahre?" Das Objektdiagramm ist eine Momentaufnahme des Klassendiagramms und zeigt Objekte und Attributbelegungen zu einem bestimmten Zeitpunkt. Verwendung erfolgt punktuell zur beispielhaften Veranschaulichung. Gleicher Detaillierungsgrad wie im Klassendiagramm. Sehr gut zur Darstellung von Mengenrelationen. "Welche innere Struktur besitzt mein System zu einem bestimmten Zeitpunkt zur Laufzeit?" 10

11 Diagrammtypen der UML 2 (2) Diagrammtyp Kompositionsstrukturdiagramm Verwendung Ideal für die Top-Down-Modellierung des Systems. (Ganz-Teil-Hierarchien). Zeigt Teile eines "Gesamtelements" und deren Mengenverhältnisse. Präzise Modellierung der Teilebeziehungen über spezielle Schnittstellen (Ports) möglich. "Wie sieht das Innenleben einer Klasse, einer Komponente, eines Systemteils aus?" Komponentendiagramm Zeigt Organisation und Abhängigkeiten einzelner technischer Systemkomponenten. Die Modellierung angebotener und benötigter Schnittstellen ist möglich. "Wie werden meine Klassen zu wieder verwendbaren, verwaltbaren Komponenten zusammengefasst und wie stehen diese zueinander in Beziehung?" Verteilungsdiagramm Zeigt das Laufzeitumfeld des Systems mit den "greifbaren" Systemteilen. Ordnet die Software-Teilsysteme Knoten (Rechnern, Hardware) zu. Hohes Abstraktionsniveau, wenige Notationselemente. "Wie sieht das Einsatzumfeld (Hardware, Server, Datenbanken,...) des Systems aus? Wie werden die Softwarekomponenten zur Laufzeit wohin verteilt?" 11

12 Diagrammtypen der UML 2 (3) Diagrammtyp Use-Case-Diagramm Verwendung Darstellung der Außensicht eines Systems mit einfachen Mitteln und ohne Details. Die Frage "Was leistet das System" und die Abgrenzung der Funktionalität steht im Mittelpunkt. Aus Use-Cases können einfach Testfälle abgeleitet werden. Eine textuelle Beschreibung sollte nicht fehlen. Aktivitätsdiagramm Darstellung von Geschäftsprozessen und anderen Abläufen mit bedingten Aktionen, Verzweigungen und Schleifen. Sie dienen auch zur detaillierteren Beschreibung von Use- Cases. Verantwortlichkeiten können definiert werden. Bietet vor allem bei komplexen Abläufen eine wesentlich höhere Verständlichkeit als eine textuelle Beschreibung. Zustandsautomat Beschreibung der Zustände eines Systems und der Übergänge von einem Zustand in den anderen unter bestimmten Bedingungen. Darstellung der Zustände von Use-Cases. "Wie verhält sich das System in einem bestimmten Zustand und bei bestimmten Ereignissen?" Sequenzdiagramm Darstellung des Informationsaustauschs zwischen beliebigen Kommunikationspartnern, Beschreibung von logischen und zeitlichen Abläufen in fester Reihenfolge. Die Abfolge der Nachrichten steht im Mittelpunkt. "Wie kommunizieren die Teile und Akteure im System?" Für das Requirements Engineering sollten nur konkrete, beispielhafte Szenarien und keine abstrakten Sequenzen modelliert werden. 12

13 Diagrammtypen der UML 2 (4) Diagrammtyp Kommunikationsdiagramm Timingdiagramm Verwendung Darstellung der Interaktionen von Teilen einer komplexen Struktur auf einfache Weise. Reihenfolge von Nachrichten und Zustandsübergängen tritt in den Hintergrund, grundsätzliches Verständnis steht im Vordergrund, Details sind unwichtig. "Welche Teile arbeiten wie zusammen, um eine Funktion zu erfüllen?". Einfacher und weniger aufwändig als Sequenzdiagramme. Gut zur Darstellung von Workflows geeignet. Visualisiert das exakte zeitliche Verhalten von Klassen, Schnittstellen etc. Geeignet für die Detailbetrachtungen, bei denen es wichtig ist, dass ein Ereignis zum richtigen Zeitpunkt eintritt. "Wann befinden sich welche Interaktionspartner in welchem Zustand?" Interaktionsübersichtsdiagr. Zeigt das Zusammenspiel von Interaktionen und Aktivitäten auf einer Metaebene. Sollte eingesetzt werden, wenn viele Interaktionsdiagramme ein System beschreiben und deren logisches Zusammenspiel wichtig ist. "In welcher Reihenfolge und unter welchen Bedingungen finden Interaktionen statt?" 13

14 Use-Case-Diagramm: Zielsetzung Was soll mein geplantes System eigentlich leisten? Externes Systemverhalten aus Sicht der Nutzer Schwierig für Software-Entwickler: Keine Modellierung der Systeminterna, der Softwarestruktur und der Realisierung der Funktionen! Wichtige Notationselemente - Nutzer (Akteure) Person Nachbarsystem Sensoren Kommunikationsschnittstellen,... - Anwendungsfälle (Use-Cases) Beschreibung der Reaktion des Systems auf Ereignisse seiner Umwelt Zusammenfassung von Teilen der Systemdienstleistung zu einem Use-Case 14

15 Use-Case-Analyse (1) Use-Cases modellieren das nach außen sichtbare Verhalten eines Systems oder Subsystems - Was statt wie Anwendersicht! Use-Cases kapseln in sich geschlossene Sammlungen von Aktionen - Darstellung von Dienstleistungen des Systems - Use-Cases sind zeitlich in sich geschlossene Vorgänge mit einem Auslöser und einem Ergebnis - Beispiel: Ein Telefongespräch führen Einen Telefonanruf annehmen sind mögliche Use-Cases für ein Telefon 15

16 Use-Case-Analyse (2) Akteure sind externe Kommunikationspartner der Use-Cases - Ein Akteur kann den Ablauf eines Use-Cases initiieren während des Ablaufs Signale oder Daten an den Use-Case senden und/oder Signale oder Daten vom Use-Case empfangen Der Use-Case liefert sein Ergebnis - entweder an den initiierenden Akteur oder - an einen beliebigen anderen Akteur Die Beschreibung des Ablaufs, der zu einem Use-Case gehört, muss in Textform oder mithilfe weiterer UML-Diagrammtypen erfolgen! Beispiel für die Beschreibung zum Use-Case Telefongespräch führen: 1. Rufnummer mithilfe der Tastatur eingeben 2. Grüne Taste "Hörer abheben" betätigen 3. Wenn Freizeichen ertönt, warten bis Gesprächspartner sich meldet 4. Mit dem Gesprächspartner sprechen und am Ende des Gesprächs die rote Taste "Hörer auflegen" betätigen 5. Wenn Gesprächspartner sich nach angemessener Wartezeit nicht meldet oder wenn Besetztzeichen ertönt, rote Taste "Hörer auflegen" betätigen 16

17 Use Case Use-Case-Name alternative Darstellung: Use-Case-Name seltener verwendet: Use-Case-Name Use-Case - Menge von Aktionen, die schrittweise ausgeführt werden - Schließt Sonder- und Fehlfunktionen ein(!) müssen im Text beschrieben werden keine gesonderte Modellierung für die möglichen Fehlfunktionen! - Mehrfache und parallele Instanziierung möglich z. B. Aufbau mehrerer Verbindungen zwischen Clients und einem Server, Öffnen mehrerer Instanzen desselben Programms auf dem PC - Beziehungen zwischen Use-Cases sind möglich z. B. kann ein Use-Case in einer bestimmten Situation durch einen anderen erweitert werden Wird von einem Akteur ausgelöst - Bezeichnung aus Sicht des Akteurs wählen - Beispiel Bankautomat: "Geld abheben" (Sicht des Bedieners) statt "Geld auszahlen" (Sicht des Systems) 17

18 System (Betrachtungsgegenstand) Systemname Einheit, die das Verhalten, welches durch die enthaltenen Use-Cases beschrieben wird, realisiert und anbietet Beispiel Parkhaus: - Use-Case "Parkticket ziehen" wird vom Automaten an der Schranke bereitgestellt - Use-Case "Parkgebühren entrichten" wird vom Parkautomaten auf dem Parkdeck bereitgestellt Bildung von Subsystemen möglich - Beide Automaten stellen Subsysteme des Gesamtsystems "Parkgebührenverwaltung" dar System muss nicht zwingend modelliert werden Zuweisung des Verhaltens zu entsprechenden Einheiten kann zu einem späteren Zeitpunkt der Modellierung erfolgen Beispiel: - Zu Beginn der Modellierung ist evtl. noch nicht klar, welche Funktionen z. B. von einem Server und welche durch den Client bereitgestellt werden sollen 18

19 Akteur Rolle des Akteurs seltener verwendet: «actor» Rolle eigene Symbole sind möglich (Beispiele): Computer <<actor>> akustisches Signal Steht immer außerhalb des zu modellierenden Systems Muss einen Namen (= Rollenbezeichnung!) haben Muss keine natürliche Person sein Beispiele: - Person (Bediener, Servicemann, Kunde) - Sensor oder Aktor - Anderes Gerät - Schnittstelle zu einem anderen System (Server, Datenbank) Beziehungen zwischen Akteuren sind prinzipiell möglich - Da das Use-Case-Diagramm die Interaktion der Akteure mit dem zu modellierenden System betont, sollten diese Beziehungen vermieden werden. 19

20 Assoziation (Beziehung) binäre Assoziation gerichtete Assoziation System 1 0..* A Name Assoziation Akteur Use-Case - Kennzeichnet Informationsaustausch jeder Art - Binär (in beide Richtungen) oder gerichtet (unidirektional) Multiplizitäten - Beschreiben die Möglichkeit des mehrfachen Initiierens eines Use-Cases - Bild links: Ein Akteur Name kann den Use-Case A beliebig oft initiieren, muss dies jedoch nicht tun - Beispiel Bankautomat: Ein Kunde muss im Zuge einer Interaktion mit dem Bankautomaten genau einmal seine PIN eingeben Ein Kunde kann beliebig oft seinen Kontostand einsehen Assoziation zwischen Akteuren - Möglichst vermeiden, da außerhalb des betrachteten Systems! 20

21 «include»-beziehung A «include» «include» B Ein Use-Case (A) importiert das Verhalten eines anderen (B) «include»-beziehung ist nicht optional das Verhalten wird bedingungslos inkludiert Beispiel Bankautomat: - Im Verlauf des Use-Cases "Geld abheben" wird zwingend der Use-Case "Autentifizierung" ausgeführt - Modellierung von "Autentifizierung" als gesonderter Use-Case, weil dieser Ablauf in unterschiedlichen Use-Cases enthalten ist und eine wichtige Funktion darstellt. Verbot zyklischer Abhängigkeiten Keine Vorgabe zeitlicher Reihenfolgen im Use-Case-Diagramm möglich! - Wenn ein Use-Case einen anderen inkludiert, bedeutet dies nur, dass zu einem beliebigen, nicht näher spezifizierten Zeitpunkt der andere Use-Case abläuft 21

22 «extend»-beziehung A «extend» «extend» B Verhalten eines Use-Case (A) kann durch einen anderen (B) erweitert werden (optional) Beispiel Parkhaus: - Der Use-Case "Parkgebühren entrichten" kann durch den Use-Case "Quittung drucken" erweitert werden, wenn der Kunde den entsprechenden Knopf betätigt hat. Dies ist jedoch nicht zwingend notwendig, der Kunde kann auch bezahlen, ohne eine Quittung anzufordern. 22

23 Do & Don't Use-Cases auf gar keinen Fall zur detaillierten Beschreibung von Operationen oder Funktionen verwenden - insbesondere können keine zeitlichen Abläufe im Use-Case-Diagramm modelliert werden - Bestandteil der zugehörigen Textbeschreibung oder anderer Diagrammtypen Keine nicht-funktionalen Anforderungen mit Hilfe von Use-Cases spezifizieren - Beispiele Zeitliche Randbedingungen Speicherplatzbegrenzungen Erweiterbarkeit,... - Nicht-funktionale Anforderungen müssen in der Sofware-Architektur berücksichtigt werden Zu starke funktionale Zerlegung mit Use-Cases vermeiden maximal 10 Use-Cases pro Diagramm Erstellung aus der Anwendersicht Sparsamer Umgang mit den erlaubten Beziehungen («extend» und «include») Akteure immer in der Einzahl benennen keine konkreten Namen vergeben ( Rollen!) ("Kunde" statt "Herr Müller") 23

24 Aktivitätsdiagramm: Zielsetzung Wie realisiert mein System ein bestimmtes Verhalten? Modellierung von Abläufen - Berücksichtigung von Nebenläufigkeiten und - alternativen Entscheidungswegen Übergänge zwischen Aktionszuständen (Aktionen) werden im Gegensatz zum Zustandsdiagramm (State Chart) in der Regel nicht durch Ereignisse ausgelöst, sondern durch die Beendigung eines mit dem Aktionszustand (der Aktion) verbundenen Verarbeitungsweges Bietet seit der UML 2.0 alle Möglichkeiten der Modellierung, die aus Nassi- Shneiderman-Struktogrammen bekannt sind (strukturierte Knoten) - Sequenzknoten - Entscheidungsknoten - Schleifenknoten Zusätzlich auch ereignisgesteuerte Abläufe, Datenfluss, Parameter 24

25 Wunsch und Wirklichkeit Die seit der UML 2.0 hinzugekommenen Notationselemente des Aktivitätsdiagramms werden bisher von extrem wenigen Modellierungswerkzeugen vollständig unterstützt - gilt insbesondere für die neuen strukturierten Knoten (Sequenz-, Entscheidungs- und Schleifenknoten) - UML Spezifikation schreibt grafische Repräsentation dieser Knoten nicht einmal exakt vor: Description Each section is a well-nested sub region of the activity whose nodes follow any predecessors of the loop and precede any successors of the loop. The test section may precede or follow the body section. The setup section is executed once on entry to the loop, and the test and body sections are executed repeatedly until the test produces a false value. The results of the final execution of the test or body are available after completion of execution of the loop. 1 In der VL werden deshalb die Notationselemente der UML 2 nur kurz erläutert Wir beschränken uns in der Anwendung auf die "alte" Notation 1 OMG Unified Modeling Language TM (OMG UML), Superstructure Version OMG Document Number: formal/ , Standard document URL: 25

26 Beispiel 1: Aktivitätsdiagramm in der UML 1.5 Verbindungsknoten (explizites ODER) Verzweigungsknoten Ereignisempfänger Signalsender Startzustand Aktion Kante mit Guard (Bedingung) 26

27 Beispiel 2: Aktivitätsdiagramm in der UML 1.5 Verantwortlichkeitsbereiche (Swim Lanes) Synchronisations- - knoten knoten Parallelisierungsknoten 27

28 Das Tokenkonzept Aktionen werden nacheinander abgearbeitet Position des virtuellen Tokens im Verlauf der Abarbeitung der Aktionen Tasse nehmen Kaffee trinken Tasse absetzen Übergang von einer Aktion zur nächsten wird dadurch erreicht, dass sich die Vorgängeraktion selbst beendet Logisches Konzept des Tokens (aus Petrinetzen übernommen): Punkt (auch Marke genannt), an dem sich der Ablauf gerade befindet. Token sind ein Gedankenmodell und werden nicht explizit modelliert! Token wandert durch das Aktivitätsdiagramm und kann sich auch aufteilen. In einer Aktivität können beliebig viele Token gleichzeitig unterwegs sein Abbildung paralleler Abläufe Nach einem Parallelisierungs-Knoten geht zu jeder Folgeaktion ein Token, so dass nach der Aufteilung die einzelnen Teilabläufe unabhängig voneinander abgearbeitet werden können. Bei einer Verzweigung hingegen liegt nur an einer der Folgeaktionen ein Token an, nämlich genau bei jenem, für welchen die Bedingung zutrifft. 28

29 Token an Parallelisierungs- und Verzweigungsknoten 29

30 Notationselemente: Aktion Aktionsname Aktionsname alt (UML 1.5) neu (UML 2) Aufruf von Verhalten oder Bearbeitung von Daten Zentrales Element des Aktivitätsdiagramms Über Kanten mit anderen Elementen verbunden Wird nur gestartet, wenn auf allen eingehenden Kanten Token angeboten werden Sonderformen der Aktion: SendSignalAction und sende Signal Senden eines Signals (Ereignis) AcceptEventAction empfange Ereignis Empfangen eines Ereignisses 30

31 Notationselemente: Objektknoten Typ des Objektknotens Repräsentiert Ausprägungen (Instanzen, Objekte) eines bestimmten Typs in der Aktivität Logisches Gerüst um Daten und Werte zu transportieren Stellt das Ergebnis der vorangegangenen Aktion dar Ist Eingabe für nachfolgende Aktion Cocktail mixen Cocktail Führt ein Pfeil von Aktion zu Objektknoten: Ausprägung von Typ des Objektknotens ist Ergebnis der Aktion 31

32 Notationselemente: Kanten Kontrollfluss - Kante zwischen zwei Aktionen oder zwischen Aktion und Kontrollelement. - Token tragen hier keine Daten und dienen nur der Aktionsausführung Objektfluss - Kante mit mindestens einem Objektknoten. - Kante trägt Token, der Daten zu oder von Objektknoten transportiert. 32

33 Notationselemente: Ergänzung von Kanten [Bedingung] Belegung der Kante mit Bedingungen Angabe als logischer Ausdruck in [ ] Verknüpfungen mit &, möglich Unterbrechung von Kanten durch Sprungmarken Dient nur der Übersichtlichkeit, keine weitere Bedeutung 33

34 Notationselemente: Kontrollelemente zur Ablaufsteuerung 34

35 Notationselemente: Kontrollelemente Startknoten: Startpunkt des Ablaufs Erzeugung eines Tokens Endknoten: markiert das Ablaufende Verzweigungsknoten: spaltet eine Kante in mehrere Alternativen nur ein Token wird weitergegeben Verbindungsknoten: führt Kanten unsynchronisiert zusammen Parallelisierungsknoten: ein eingehender Ablauf wird in mehrere parallele Abläufe geteilt für jeden der parallelen Abläufe wird ein Token generiert und weitergegeben Synchronisationsknoten: vereint eingehende Abläufe zu einem gemeinsamen Ablauf Bedingung: alle Token der eingehenden Abläufe müssen verfügbar ("angekommen") sein 35

36 Wesentliche Neuerungen in der UML 2 Neue Notationselemente, u. a. - Entscheidungsknoten - Schleifenknoten - Datenspeicher- und Bufferknoten Mehrere Startknoten erlaubt - Start paralleler Abläufe möglich Notation von Aktionen entspricht der Notation von Zuständen Bezeichnung des kompletten Diagramms als Aktivität Aktivitäten können Ein- und Ausgabeparameter enthalten - Können auch den Start- und den Endknoten ersetzen Nicht alle Elemente der UML 2.0 sind in den verfügbaren Modellierungswerkzeugen umgesetzt! - Ggf. improvisieren, mit Notizen arbeiten,... - Dies scheidet natürlich aus, wenn aus den Diagrammen automatisch Code generiert wird! 36

37 UML 2: Auswahl und Mehrfachauswahl Auswahl Mehrfachauswahl Nassi - Shneiderman Struktogramm Bedingung wahr falsch Aktion 1 Aktion 2 C1 Aktion 1... Const Cn Aktion n if Const = C1 Aktivitätsdiagramm UML 2 if then Bedingung Aktion 1 then Aktion 1... else Aktion 2 if Const = Cn then Aktion n 37

38 UML 2: while- und do-while-schleife while - Schleife do - while - Schleife Nassi - Shneiderman Struktogramm Bedingung Aktion 1 Aktion 2 Aktion 1 Bedingung Aktion 2 Aktivitätsdiagramm UML 2 while do Bedingung Aktion 1 do while Aktion 1 Bedingung Aktion 2 Aktion 2 38

39 UML 2: Aktivität mit Parametern und parallelen Abläufen Fleisch zubereiten Fleisch [in Packung] Fleisch säubern Herdplatte aufheizen Form des Notationselements gegenüber der UML 1.5 geändert! Jetzt gleiche Form wie Zustand im Zustandsdiagramm Parameter Fleisch [gesäubert] Öl erhitzen Speiseöl Gewürze Fleisch würzen Fleisch [gewürzt] Öl [erhitzt] Aktivität Fleisch anbraten Fleisch [angebraten] 39