Softwaretest: Anweisungs-, Verzweigungs-, und Pfadüberdeckung

Veröffentlicht am 17. März 2021 von LaS3 OTH Regensburg

Kurzzusammenfassung:
In diesem Lehr-Lern-Arrangement geht es darum, dass Studierende Formen des Whiteboxtests anhand von vollständig implementierten Methoden (Testfälle für Anweisungs-, Verzweigungs- und Pfadüberdeckung) selbstständig, praktisch durchführen. Im zweiten Teil des Übungsblattes sollen Studierende einen Kontrollflussgraphen für eine vorgegebene Methode entwerfen.

Übersicht

Ziele:

Verstehen und Erstellen von Tests mit vollständiger Anweisungsüberdeckung
Verstehen und Erstellen von Tests mit vollständiger Verzweigungsüberdeckung
Verstehen und Erstellen von Tests mit vollständiger Pfadüberdeckung
Erstellen eines Kontrollflussgraphen

Didaktische Funktion(en):

Transfer/Anwendung

Hintergrund / didaktisch-methodische Einordnung:

Ziel dieses LLAs ist es, dass Studierende bereits erlerntes Faktenwissen im Bereich Whiteboxtests, speziell in den Bereichen Anweisungs-, Verzweigungs- und Pfadüberdeckung, vertiefen und praktisch anwenden.

Die Studierenden werden also damit konfrontiert, konkret an verschiedenen Darstellungen von Code (Nassi-Shneiderman-Diagramm oder der Code selbst) Testfälle zu generieren, um Anweisungsüberdeckung, Zweigüberdeckung und Pfadüberdeckung zu erzielen. Außerdem werden Kontrollflussgraphen (auch Programmablaufplan (PAP)) eingeführt, um anhand einer Programmlogik ablauforientierte Testfälle ermitteln und ausführen zu können. Studierende sollen für die Idee von Whiteboxtests, alle Quellcodeteile des Testobjekts mindestens einmal zur Ausführung zu bringen, sensibilisiert werden.

Induktives Lehren und Lernen ist ein umfassender Begriff, welcher verschiedene Methoden wie forschungsbasiertes Lernen, Problembasiertes Lernen (PBL), Projektbasiertes Lernen, Fallbasiertes Lernen, Just-in-time-teaching etc. umfasst. Eine Gemeinsamkeit dieser Ansätze ist das Lerner-zentrierte Design, was bedeutet, dass die Verantwortung für das eigene Lernen mehr auf Seiten des Lernenden liegt im Vergleich zu traditionellen Lehr/-Lernansätzen (vgl. Prince & Felder, 2006).

Das LLA basiert dabei auf der induktiven Lehrmethode des Problem-basierten Lernens. Im Problembasierten Lernen (PBL) stellt eine authentische und komplexe Problemstellung die Ausgangsgrundlage dar. Studierende bekommen hierbei eine konkrete Problemstellung, die sie selbstständig bearbeiten, recherchieren (z.B. in Vorlesungsmaterial, Online-Quellen etc.) und sich dabei Wissen aneignen, um das Problem zu lösen bzw. eigene Antworten zu finden (vgl. Prince & Felder, 2006). Dabei lernen die Lernenden in Form von Gruppenarbeit, Fragestellungen zum Problem zu finden und wichtige Begriffe des Problems ausfindig zu machen und zu definieren. Anschließend wird das Problem analysiert, Bestandteile des Problems werden mit bestehendem Wissen verknüpft und Hypothesen können aufgestellt werden. Diese Hypothesen werden bewertet und priorisiert. Im Weiteren werden basierend auf den Hypothesen Lernziele festgelegt und es wird analysiert, wie diese Lernziele erreicht werden können und welche Ressourcen dafür notwendig sind. Anschließend versucht jeder Teilnehmer, diese Lernziele selbstständig oder in Kleingruppen zu erreichen. Nach Beenden der Lernphase überprüfen die Lernenden die erarbeiteten Informationen miteinander (Schmidt, 1983).

Neben dem Erwerb von langfristigem fachlichen Wissen wird die Problemlösefähigkeit gefördert sowie die Fähigkeit sich selbstständig komplexe Themen anzueignen (vgl. Prince & Felder, 2006).

Weniger anzeigen

Sozialform(en):

Einzelarbeit, Partnerarbeit

Anzahl der Lernenden:

Ab 1 Person

Voraussetzungen und Ressourcen

Voraussetzungen:

Lehrperson: Erfahrungen zu Blackboxtestverfahren und Whiteboxtestverfahren; Kenntnisse über Anweisungs-, Verzweigungs- und Pfadüberdeckung (C0, C1, C2 Überdeckung)
Lernende: Software Engineering Studierende, die bereits eine theoretische Grundlagenvorlesung besucht haben; Theoretische Grundlagen im Bereich Whiteboxtestverfahren

Ausstattung & Medien:

In Präsenz:

Seminarraum oder CIP-Pool
Ein PC pro Person/Gruppe zur Recherche
Software zur Textverarbeitung (z.B. Microsoft Word, Libre Office)
Online-Lernplattform (z.B. Moodle)

Virtuell/online:

Videokonferenztool (z.B. Zoom, Skype o.ä.)
PCs für Lehrende, sowie Studierende für Teilnahme an Videokonferenz und Recherche
Software zur Textverarbeitung (z.B. Microsoft Word, Libre Office)
Online-Lernplattform (z.B. Moodle)

Weniger anzeigen

Ablauf

Die Studierenden erhalten ein Aufgabenset mit verschiedenen Vorgaben (Nassi-Shneiderman-Diagramm, Codebeispiele) und die Aufgabe ein Set an minimalen Testfällen zu generieren, um Anweisungsüberdeckung, Zweigüberdeckung und Pfadüberdeckung zu erzielen. Außerdem soll zu einer Aufgabe ein Kontrollflussgraph erstellt werden.
Die Studierenden (alleine oder in Gruppen) bearbeiten selbstständig die Aufgaben des Übungsblattes.
Während der Übung steht der Lehrende bereit, um aufkommende Fragen zu beantworten oder Hilfestellung bei Problemen zu geben.
Die Studierenden dokumentieren ihre Ergebnisse direkt im Übungsblatt.

Hinweise zur Vorbereitung:

Konzeption von Aufgaben und entsprechenden Codebeispielen für die Studierenden
Erstellung eines Bewertungsschemas für die Abgaben

Hinweise zur Nachbereitung:

Korrektur der Abgaben anhand eines Bewertungsschemas
Analyse der Abgaben auf Probleme der Studierenden

Hinweise zur Dauer: 90-minütige Übung

Kritische Einordnung

Vorteile und Stärken:

Die Studierenden bauen selbstständig ein vertieftes theoretisches und praktisches Wissen in dem Gebiet der Whiteboxtestverfahren auf.

Grenzen und Schwächen:

Keine

Literatur und weiterführende Hinweise

H.G. Schmidt (1983). Problem‐based learning: rationale and description. In: Medical Education, Vol. 17, pp. 11-16
M. J. Prince, R. M. Felder (2006). Inductive teaching and learning methods: Definitions, comparisons, and research bases. In: Journal of Engineering Education, vol. 95, no. 2, pp. 123-138

Softwaretest: Äquivalenzklassentest & Grenzwertanalyse

Veröffentlicht am 17. März 2021 von LaS3 OTH Regensburg

Kurzzusammenfassung:
In diesem Lehr-Lern-Arrangement geht es darum, dass Studierende Formen des Blackboxtests – Äquivalenzklassentest und Grenzwertanalyse – anhand eines praktischen Beispiels durchführen. Sinn und Zweck der beiden Methoden bzw. der Durchführung von Blackboxtests sollen Studierenden durch den praktischen Einsatz verdeutlicht werden.

Übersicht

Ziele:

Ableiten von Äquivalenzklassen zur Äquivalenzklassenanalyse
Ableiten von Grenzwerten zur Grenzwertanalyse

Didaktische Funktion(en):

Informationsaneignung
Transfer/Anwendung

Hintergrund / didaktisch-methodische Einordnung:

Äquvialenzklassentest und Grenzwertanalyse können den Blackboxtestverfahren zugeordnet werden.

Im Zuge eines Äquivalenzklassentests werden Äquivalenzklassen gebildet, die eine Untermenge eines Wertebereichs von Aus- und Eingaben repräsentieren, bei denen ein gleichartiges Verhalten des System während eines Softwaretests angenommen wird.
Die Grenzwertanalyse ist ein Spezialfall der Äquivalenzklassenanalyse, wo nur die sog. Randwerte oder Grenzwerte einer Äquivalenzklasse getestet werden. Deshalb wird die Grenzwertanalyse i.d.R. nach dem Äquivalenzklassentest durchgeführt.

Ziel dieses LLAs ist es, dass Studierende bereits erlerntes Wissen im Bereich Blackbox-Testing, speziell dem Äquivalenzklassentest und der Grenzwertanalyse, anwenden und vertiefen.

Die Studierenden werden also mit einem konkreten Problem konfrontiert, das eine Äquivalenzklassenanalyse und anschließend eine Grenzwertanalyse erfordert. Dies ist dem theoretischen Rahmen des Problembasierten Lernens beziehungsweise übergeordnet dem induktiven Lernen zuzuordnen:

Neben dem Erwerb von langfristigem fachlichen Wissen wird die Problemlösefähigkeit gefördert sowie die Fähigkeit sich selbstständig komplexe Themen anzueignen (vgl. Prince & Felder, 2006).

Weniger anzeigen

Sozialform(en):

Einzelarbeit, Partnerarbeit

Anzahl der Lernenden:

Ab 1 Person

Voraussetzungen und Ressourcen

Voraussetzungen:

Lehrperson: Erfahrungen im Bereich Software Test; Kenntnisse zur Durchführung von Äquivalenzklassentests und Grenzwertanalyse
Lernende: Software Engineering Studierende, die bereits eine theoretische Grundlagenvorlesung besucht haben; Theoretische Grundlagen im Bereich Softwaretestverfahren

Ausstattung & Medien:

In Präsenz:

Seminarraum oder CIP-Pool
Ein PC pro Person/Gruppe zur Recherche
Software zur Textverarbeitung (z.B. Microsoft Word, Libre Office)
Online-Lernplattform (z.B. Moodle)

Virtuell/ Online:

Videokonferenztool (z.B. Zoom, Skype o.ä.)
PCs für Lehrende, sowie Studierende für Teilnahme an Videokonferenz und Recherche
Software zur Textverarbeitung (z.B. Microsoft Word, Libre Office)
Online-Lernplattform (z.B. Moodle)

Weniger anzeigen

Ablauf

Die Studierenden erhalten mehrere Szenarien und zum Teil Codeausschnitte mit der Anweisung Äquivalenzklassentests und Grenzwertanalysen durchzuführen. Die Codeausschnitte beschreiben vollständig implementierte Funktionen in C++ (Da ein Blackboxtest durchgeführt werden soll, sind diese eigentlich nicht notwendig. Dies ist allerdings intendiert, um Studierenden die Unterschiede zwischen Blackbox- und Whiteboxtestverfahren zu verdeutlichen)
Die Studierenden (alleine oder in Gruppen) bearbeiten selbstständig die Aufgaben des Übungsblattes.
Während der Übung steht der Lehrende bereit, um aufkommende Fragen zu beantworten oder Hilfestellung bei Problemen zu geben.
Die Studierenden dokumentieren ihre Ergebnisse direkt im Übungsblatt in bereits vorgegeben Tabellenstrukturen.

Hinweise zur Vorbereitung:

Konzeption von verschiedenen Szenarien, die Äquivalenzklassentests und Grenzwertanalyse erfordern
Erstellung eines Bewertungsschemas für die Abgaben

Hinweise zur Nachbereitung:

Korrektur der Abgaben anhand eines Bewertungsschemas
Analyse der Abgaben auf Probleme der Studierenden

Hinweise zur Dauer: 90-minütige Übung

Kritische Einordnung

Vorteile und Stärken:

Die Studierenden bauen selbstständig ein vertieftes theoretisches und praktisches Wissen in dem Gebiet der Blackboxtestverfahren auf.

Grenzen und Schwächen:

Keine

Literatur und weiterführende Hinweise

H.G. Schmidt (1983). Problem‐based learning: rationale and description. In: Medical Education, Vol. 17, pp. 11-16
M. J. Prince, R. M. Felder (2006). Inductive teaching and learning methods: Definitions, comparisons, and research bases. In: Journal of Engineering Education, vol. 95, no. 2, pp. 123-138

UML Diagramm Übung: Zustandsautomat & Sequenzdiagramm

Veröffentlicht am 11. März 2021 von LaS3 OTH Regensburg

Kurzzusammenfassung:
In diesem Lehr-Lern-Arrangement geht es darum, dass Studierende mithilfe von bereit gestellten Informationen in Form eines Requirement-Dokuments ein Lückenbild eines Zustandsdiagramms vervollständigen. Die entsprechenden Textbausteine (Trigger, Guards und Actions) für die Fertigstellung des Diagramms werden den Studierenden in Form einer Liste mitgegeben. Zusätzlich ist ein Teil des Zustandsdiagramms eigenständig zu modellieren.
Der zweite der Teil des LLAs besteht aus der Fertigstellung eines Sequenzdiagramms. Auch hier werden den Studenten die Textbausteine zur Verfügung gestellt. Dieses LLA ist eines von zwei LLAs (zuvor kann das LLA zur Modellierung von Use-Case- und Klassendiagrammen eingesetzt werden), das Studierende in die Verwendung der Unified Modeling Language (UML) als eine Sprache zur Modellierung einer Softwarearchitektur und –design einführt.

Übersicht

Ziele:

Erstellung eines Zustandsdiagramms
- Korrekter Einsatz der wesentlichen Elemente (Zustände, Transitionen mit Trigger, Guard und Actions)
- Semantisches Verständnis von Zustandsfolgen

Erstellung eines Sequenzdiagramms
- Semantisches Verständnis von zeitlichen Abfolgen in einem Anwendungsfall resp. Dem Aufbau eines Sequenzdiagramms
- Korrekter Einsatz der wesentlichen Elemente, v.a. synchroner und asynchroner Nachrichten

Didaktische Funktion(en):

Transfer/Anwendung

Hintergrund / didaktisch-methodische Einordnung:

Das Sequenzdiagramm ist ein UML-Diagramm welches den Austausch von Nachrichten zwischen Objekten mittels Lebenslinien beschreibt.
Das Zustandsdiagramm visualisiert hingegen eine Folge von Zuständen, die ein Objekt im Lebenszyklus einnehmen kann. Beide Diagrammtypen werden zur dynamischen Modellierung eingesetzt und bilden Verhalten eines Softwaresystems ab.

Ziel dieses LLAs ist es, dass Studierende bereits erlerntes Wissen zur Modellierung von Zustands- und Sequenzdiagrammen anwenden und vertiefen und einen Einstieg bzw. Überblick in die Verhaltensmodellierung eines Softwaredesigns erhalten.

Induktives Lehren und Lernen ist ein umfassender Begriff, welcher verschiedene Methoden wie forschungsbasiertes Lernen, problembasiertes Lernen (PBL), projektbasiertes Lernen, fallbasiertes Lernen, Just-in-time-teaching etc. umfasst. Eine Gemeinsamkeit dieser Ansätze ist das lerner-zentrierte Design, was bedeutet, dass die Verantwortung für das eigene Lernen mehr auf Seiten des Lernenden liegt im Vergleich zu traditionellen Lehr/-Lernansätzen (Prince& Felder, 2006).

Das LLA basiert dabei auf der induktiven Lehrmethode des problembasierten Lernens. Im problembasierten Lernen (PBL) stellt eine authentische und komplexe Problemstellung die Ausgangsgrundlage dar. Studierende erhalten hierbei eine konkrete Problemstellung, die sie selbstständig bearbeiten, recherchieren (z.B. in Vorlesungsmaterial, Online-Quellen etc.) und sich dabei Wissen aneignen, um das Problem zu lösen bzw. eigene Antworten zu finden (vgl. Prince & Felder 2006). Dabei lernen die Lernenden in Form von Gruppenarbeit, Fragestellungen zum Problem zu finden und wichtige Begriffe des Problems ausfindig zu machen und zu definieren. Anschließend wird das Problem analysiert, Bestandteile des Problems werden mit bestehendem Wissen verknüpft und Hypothesen können aufgestellt werden. Diese Hypothesen werden bewertet und priorisiert. Im Weiteren werden basierend auf den Hypothesen Lernziele festgelegt und es wird analysiert, wie diese Lernziele erreicht werden können und welche Ressourcen dafür notwendig sind. Anschließend versucht jeder Teilnehmer, diese Lernziele selbstständig oder in Kleingruppen zu erreichen. Nach Beenden der Lernphase überprüfen die Lernenden die erarbeiteten Informationen miteinander (Schmidt, 1983).

Neben dem Erwerb von langfristigem fachlichen Wissen wird die Problemlösefähigkeit gefördert sowie die Fähigkeit sich selbstständig komplexe Themen anzueignen (Prince & Felder, 2006).

Weniger anzeigen

Sozialform(en):

Einzelarbeit, Partnerarbeit

Anzahl der Lernenden:

Ab 1 Person

Voraussetzungen und Ressourcen

Voraussetzungen:

Lehrperson: Erfahrungen in der Modellierung von Sequenzdiagrammen und Zustandsautomaten;
Lernende: Software Engineering Studierende, die bereits eine theoretische Grundlagenvorlesung besucht haben; Theoretische Grundlagen in Zustands- und Sequenzdiagrammen

Ausstattung & Medien:

In Präsenz:

Seminarraum oder CIP-Pool
Ein PC pro Person/Gruppe zur Recherche
Software zur Textverarbeitung (z.B. Microsoft Word, Libre Office)
Software zur PDF-Verarbeitung (z.B. Adobe Reader)
Modellierungssoftware
Online-Lernplattform (z.B. Moodle)

Virtuell/online:

Videokonferenztool (z.B. Zoom, Skype o.ä.)
PCs für Lehrende, sowie Studierende für Teilnahme an Videokonferenz und Recherche
Software zur Textverarbeitung (z.B. Microsoft Word, Libre Office)
Software zur PDF-Verarbeitung (z.B. Adobe Reader)
Modellierungssoftware

Online-Lernplattform (z.B. Moodle)

Weniger anzeigen

Ablauf

Zu Beginn wiederholt der Dozierende in Form eines Impulsvortrags noch einmal wesentliche Elemente der beiden Diagrammtypen und erläutert diese an einem Beispiel.
Studierende erhalten das Übungsblatt zur Modellierung mit der UML über die Lernplattform. Zentrale Aufgabe ist es auf Basis einer vorhandenen Dokumentation die Lücken eines vorgegebenen Zustandsautomaten mit den korrekten Trigger, Guards und Actions zu vervollständigen.
Die Studierenden bearbeiten (alleine oder in Gruppen) selbstständig die Aufgaben des Übungsblattes.
Während der Übung steht der Lehrende bereit, um aufkommende Fragen zu beantworten oder Hilfestellung bei Problemen zu geben.
Die Studierenden dokumentieren ihre Ergebnisse und geben diese über die Lernplattform in Form einer PDF oder eines Bildes des UML-Diagramms ab.

Beispiele oder Materialien:

Dieses Werk ist lizenziert unter einer Creative Commons Namensnennung – Nicht-kommerziell – Weitergabe unter gleichen Bedingungen 4.0 International Lizenz.

Aufgabenstellung – Zustandsautomat:

Ergänzen Sie mit Hilfe der gegeben Requirements das Lückenbild des Zustandsdiagramms. Verwenden Sie dabei jeden Begriff auf den gegebenen Listen genau einmal!

Modellieren Sie den fehlenden Teil des Diagramms. Die Begriffe für den zu modellierenden Teil stehen nicht auf der Liste.

Aufgabenstellung – Zustandsautomat:

Ergänzen Sie das gegebene Lückensequenzdiagramm mit den Texten. Wieder gilt Jeder Text muss genau einmal verwendet werden.

Hinweise zur Vorbereitung:

Erstellung eines Lücken-Zustandsdiagramms
Erstellung eines Lücken-Sequenzdiagramms
Erstellung eines Bewertungsschemas für die Abgaben
Erstellung eines Requirement-Dokuments

Hinweise zur Nachbereitung:

Korrektur der Abgaben anhand eines Bewertungsschemas
Analyse der Abgaben auf Probleme der Studierenden

Hinweise zur Dauer: 90 min + Fertigstellung

Kritische Einordnung

Vorteile und Stärken:

Die Studierenden wenden Faktenwissen praktisch an. Studierende erhalten eine Einführung in die Modellierung von Sequenz- und Zustandsdiagrammen.

Grenzen und Schwächen:

Es wird nicht eigenständig ein Sequenzdiagramm modelliert, sondern nur vervollständigt.

Literatur und weiterführende Hinweise

H.G. Schmidt (1983). Problem‐based learning: rationale and description. In: Medical Education, Vol. 17, pp. 11-16
M. J. Prince, R. M. Felder (2006). Inductive teaching and learning methods: Definitions, comparisons, and research bases. In: Journal of Engineering Education, vol. 95, no. 2, pp. 123-138

UML Diagramm Übung: Use Case- & Klassendiagramm

Veröffentlicht am 11. März 2021 von LaS3 OTH Regensburg

Kurzzusammenfassung:
In diesem Lehr-Lern-Arrangement geht es darum, dass Studierende aus einer bestehenden Anforderungsbeschreibung ein Use-Case-Diagramm und ein Klassendiagramm mittels einer Modellierungssoftware ihrer Wahl (z.B. Astah, Enterprise Architect o.Ä.) modellieren. Studierende werden in diesem LLA mit der Aufgabe konfrontiert, aus einem mitgelieferten Requirement-Dokument die wichtigsten Informationen zu extrahieren und in ein erstes Software Grobdesign zu abstrahieren. Dazu wird ihnen die Methode der Substantiv-Verb-Analyse vorgestellt, mit der die Identifikation von Klassenkandidaten für das Klassendiagramm unterstützt werden soll. Dieses LLA ist eines von zwei LLAs, das Studierende in die Verwendung der Unified Modeling Language (UML) als eine Sprache zur Modellierung von Softwarearchitektur und –design einführt.

Übersicht

Ziele:

Erstellung eines Use-Case-Diagramm auf Basis einer Anforderungsbeschreibung
- Identifkation und Formulierung von Use-Cases
- Korrekter Einsatz der Elemente des Use-Case-Diagramms
Einstieg in eine Modellierungssoftware
Erstellung eines Klassendiagramms auf Basis einer Anforderungsbeschreibung
- Identifkation und Modellierung von geeigneten Klassen (sowie Methoden und Attributen)
- Korrekter Einsatz der Elemente des Klassendiagramms (v.a. Assoziationstypen)
Anwendung der Substantiv-Verb-Analyse

Didaktische Funktion(en):

Transfer / Anwendung

Hintergrund / didaktisch-methodische Einordnung:

Das Klassendiagramm ist ein UML-Diagramm zur grafischen Modellierung von Klassen, Schnittstellen sowie deren Beziehungen.
Das Use Case-Diagramm modelliert hingegen die Strukturen und das Verhalten der Software. Es stellt dabei Anwendungsfälle und Akteure mit ihren jeweiligen Abhängigkeiten und Beziehungen dar.

Ziel dieses LLAs ist es, dass Studierende bereits erlerntes Wissen im Bereich dieser beiden UML-Diagramm Typen anwenden und vertiefen.

Neben dem Erwerb von langfristigem fachlichen Wissen wird die Problemlösefähigkeit gefördert sowie die Fähigkeit sich selbstständig komplexe Themen anzueignen (Prince & Felder, 2006).

Weniger anzeigen

Sozialform(en):

Einzelarbeit, Partnerarbeit

Anzahl der Lernenden:

Ab 1 Person

Voraussetzungen und Ressourcen

Voraussetzungen:

Lehrperson: Erfahrungen in der Modellierung von Klassen- & Use-Case-Diagrammen und dem Einsatz verschiedener Modellierungssoftware;
Lernende: Software Engineering Studierende, die bereits eine theoretische Grundlagenvorlesung besucht haben; Theoretische Grundlagen in Klassen- und Use-Case-Diagrammen

Ausstattung & Medien:

In Präsenz:

Seminarraum oder CIP-Pool
Ein PC pro Person/Gruppe zur Recherche
Software zur Textverarbeitung (z.B. Microsoft Word, Libre Office)
Online-Lernplattform (z.B. Moodle)
Software zur UML-Diagramm Modellierung (Astah, Enterprise Architect o.Ä.)

Virtuell/online:

Videokonferenztool (z.B. Zoom, Skype o.ä.)
PCs für Lehrende, sowie Studierende für Teilnahme an Videokonferenz und Recherche
Software zur Textverarbeitung (z.B. Microsoft Word, Libre Office)
Online-Lernplattform (z.B. Moodle)
Software zur UML-Diagramm Modellierung (Astah, Enterprise Architect, Modelioo.Ä.)

Weniger anzeigen

Ablauf

Studierende erhalten das Übungsblatt zur Modellierung des Use-Case- und Klassendiagramms über die Lernplattform. Zentrale Aufgabe ist es auf Basis einer Anforderungsbeschreibung Anwendungsfälle für den Coff-E Kaffeeautomaten zu modellieren. Außerdem ist für die Modellierung des Klassendiagramms ein ausführlicheres Requirement-Dokument enthalten, anhand dessen das Diagramm modelliert werden soll.
Es folgt eine kurze einführende Präsentation in die möglichen Modellierungssoftware
Zudem werden in einem Impulsvortrag noch einmal wesentliche Elemente der beiden Diagrammtypen wiederholt und beispielhaft erläutert.
Die Studierenden bearbeiten (alleine oder in Gruppen) selbstständig die Aufgaben des Übungsblattes.
Während der Übung steht der Lehrende bereit, um aufkommende Fragen zu beantworten oder Hilfestellung bei Problemen zu geben.
Die Studierenden dokumentieren ihre Ergebnisse mit Hilfe einer Modellierungssoftware und geben die Diagramme über die Lernplattform in Form einer PDF oder eines Bildes des UML-Diagramms ab.

Beispiele oder Materialien:

Dieses Werk ist lizenziert unter einer Creative Commons Namensnennung – Nicht-kommerziell – Weitergabe unter gleichen Bedingungen 4.0 International Lizenz.

Aufgabenstellung Use Case-Diagramm:

Ihnen liegt nun folgende Anforderungsbeschreibung für „Coff-E“ vor. Erstellen Sie ein Use Case Diagramm, das auch die Abhängigkeiten der Elemente darstellt. Beachten Sie, dass für ein Use Case Diagramm möglicherweise Verallgemeinerungen nötig sind und/oder nicht alle beschriebenen Informationen relevant sind. Modellieren Sie das Diagramm in Modelio oder einer anderen Modellierungssoftware Ihrer Wahl.
Hinweis: Benutzen Sie bitte bei der Modellierung Generalisierungen, „include“ und „extend“ Beziehungen.

Ihre Firma hat sich entschieden den ersten Prototypen von „Coff-E“ im eigenen Haus zu betreiben. Im Büro ihrer Firma solle daher der neue Kaffeevollautomat „Coff-E“ installiert werden. Um ein fachliches Ziel zu erreichen werden die folgenden Anwendungsfälle definiert.

Der Benutzer kann sich auf der App mit Benutzername und Passwort in sein Profil einloggen
Der Benutzer kann verschiedene Getränke über die App auswählen:
- Kaffee schwarz, Kaffee weiß, Cappuccino, Heißes Wasser, Heiße Milch
Der Benutzer kann verschiedene Getränke am Kaffeeautomaten auswählen:
- Kaffee schwarz, Kaffee weiß, Cappuccino, Heißes Wasser, Heiße Milch
Nach der Getränkeauswahl kann der Benutzer die Zuckermenge bestimmen:
- Kein Zucker, Standard Zucker, viel Zucker
- Falls der Benutzer keine Option wählt, wird per Default Standard Zucker gewählt.
Der Benutzer muss nach der Auswahl mit Münzen bezahlen.
Bei der Auswahl von viel Zucker muss der Benutzer extra bezahlen.
Der Benutzer kann die Scheine im Erdgeschoß wechseln, falls er keine Münzen hat.
Der Benutzer kann seine Bankdaten in der App hinterlegen.
Der Benutzer kann nach der Auswahl per App bezahlen.
Der Benutzer kann die fehlenden Zutaten holen, falls die entsprechende Anzeige auf dem Bildschirm steht.
Der Benutzer kann den Techniker anrufen, falls der Kaffeeautomat kaputt ist.
Der Techniker repariert den Automaten.
Der Techniker kann auch Getränke bestellen.

Aufgabenstellung Klassendiagramm:

Modellieren Sie anhand des Requirements-Dokuments ein Klassendiagramm Kaffeeautomat.

Vorgehensweise um mögliche Klassen zu identifizieren:

Vereinfachen Sie das Requirements- Dokument, extrahieren Sie die wichtigsten Informationen, um einen besseren Überblick über die Requirements zu bekommen.
Führen Sie eine Substantivanalyse des RQ-Dokuments durch.
Erstellen Sie mögliche Klassenkandidaten.
Modellieren Sie das Diagramm in Modelio oder einer anderen Modellierungssoftware Ihrer Wahl.

Hinweise zur Vorbereitung:

Erstellung einer Anforderungsbeschreibung für die Erstellung des Use-Case-Diagramms
Erstellung eines Requirement-Dokuments für die Erstellung des Klassendiagramms
Konzeption von Aufgaben für die Studierenden
Erstellung eines Bewertungsschemas für die Abgaben

Hinweise zur Nachbereitung:

Korrektur der Abgaben anhand des Bewertungsschemas
Analyse der Abgaben auf Probleme der Studierenden

Hinweise zur Dauer: 90-minütige Übung

Kritische Einordnung

Vorteile und Stärken:

Die Studierenden bauen selbstständig ein vertieftes theoretisches und praktisches Wissen in dem Gebiet der UML-Diagramme auf.
Sie lernen das Erstellen von Use-Case-Diagrammen und Klassendiagrammen. Außerdem verstehen sie nach dieser Übung die Generalisierungs-Beziehungen „include“ und „extend“.

Grenzen und Schwächen:

Keine

Literatur und weiterführende Hinweise

H.G. Schmidt (1983). Problem‐based learning: rationale and description. In: Medical Education, Vol. 17, pp. 11-16
M. J. Prince, R. M. Felder (2006). Inductive teaching and learning methods: Definitions, comparisons, and research bases. In: Journal of Engineering Education, vol. 95, no. 2, pp. 123-138

Übungseinheit Fehlerbaumanalyse

Veröffentlicht am 26. Januar 2021 von LaS3 OTH Regensburg

Kurzzusammenfassung:
In diesem Lehr-Lern-Arrangement geht es darum, dass Studierende die Fehlerbaumanalyse (Fault Tree Analysis (FTA)) kennenlernen und anhand eines Beispiels anwenden. Ausgangspunkt einer FTA ist ein definierter Systemzustand („Top Event“, z.B. Systemausfall), der weiter „top down“ (von oben nach unten) über Zwischenzustände bis zu Basisereignissen (Komponentenausfälle) aufgeschlüsselt wird. Die Fragestellung bzw. Vorgehensweise ist dabei deduktiv. Im Rahmen einer Übungseinheit zur zugehörigen Software-Engineering Vorlesung sollen die Studierenden die Ansätze der FTA kennenlernen und anhand eines Arbeitsblattes erarbeiten und anwenden.

Übersicht

Ziele:

Die Studierenden kennen die Definition der FTA und wissen in welchen Situationen diese Analyse eingesetzt werden kann.
Die Studierenden kennen die Grundlagen und den Ablauf der FTA.
Die Studierenden kennen die Informationen, die eine FTA liefert.
Die Studierenden kennen die grundlegenden Elemente der Syntax eines Fehlerbaums.
Die Studierenden können eine Fehlerbaumanalyse basierend auf einer Beispielaufgabe erstellen.

Didaktische Funktion(en):

Einstieg & Aktivierung
Informationsaneignung

Hintergrund / didaktisch-methodische Einordnung:

Neben dem klassischen Ablauf von Softwareentwicklungsprozessen und den zugehörigen klassischen Methoden des Software Engineering spielt das Thema der funktionalen Sicherheit (Functional Safety) seit vielen Jahren eine große Rolle in der Software Entwicklung. Die funktionale Sicherheit muss dabei von Anfang an in den Softwareentwicklungsprozess integriert werden.

Eine Methode der Functional Safety mögliche Fehler des Systems zu identifizieren, sowie deren Eintrittswahrscheinlichkeit einzuschätzen, ist die sogenannte Fehlerbaumanalyse (Fault Tree Analysis (FTA)). Das Ziel der FTA ist die systematische Identifizierung möglicher Ausfallkombinationen und dahinterliegender Basisereignisse einer Software oder eines ganzen Systems, die zu einem vorgegebenen „Top Event“ führen können. Außerdem wird die Eintrittswahrscheinlichkeit von Ausfallkombinationen und das „Top Event“, nach Zuweisung von Zuverlässigkeitskenngrößen für Basisereignisse (Ausfallwahrscheinlichkeit) ermittelt. Dabei werden zunächst qualitative Arbeitsschritte wie das Festlegen des „Top Event“ und die Identifizierung aller Ereigniskombinationen, die zum „Top Event“ führen und zugehörige Basisereignisse identifiziert. Anschließend gibt es qualitative und quantitative Arbeitsschritte, in welchen Zuverlässigkeitskenngrößen zu jedem Basisereignis ermittelt und zugewiesen werden. Danach wird das System modelliert und die Eintrittswahrscheinlichkeiten von Verzweigungen und des „Top Event“ können berechnet werden. Abschließend findet eine Analyse der dominierenden Ereigniskombinationen und -beiträge (Importanzanalyse) statt, sodass Vorschläge zur Software-/Systemoptimierung identifiziert und implementiert werden können.

Weniger anzeigen

Sozialform(en):

Einzelarbeit

Anzahl der Lernenden:

ab 1 Person

Voraussetzungen und Ressourcen

Voraussetzungen:

1 Lehrperson zur Verbesserung der Aufgaben
Lehrperson(en) benötigen gute Kenntnisse im Bereich FTA

Ausstattung & Medien:

Online-Lernplattform für Abgabe der Aufgabe und Bereitstellung der Aufgaben (bspw. Moodle)
Modellierungssoftware für die Erstellung des Fehlerbaumes (bspw. Microsoft Visio o.ä.)
Für Online-Veranstaltung: Videokonferenz-Plattform wie z.B. Zoom, Big Blue Button o.ä.

Ablauf

Das LLA findet innerhalb einer Übungseinheit (90 min.) zur begleitenden Software-Engineering Vorlesung statt. Die Übung kann in Präsenz sowie auch online stattfinden. Der Ablauf beider Varianten wird im Folgenden gezeigt:

Präsenzveranstaltung:

Den Studierenden wird vor der Übungseinheit, spätestens zu Beginn, das Übungsblatt mit der Aufgabe auf der Online-Lernplattform freigeschaltet.
Nach Lesen der Aufgabe haben die Studierenden in der Übung dann Zeit zunächst grundlegende Fragen zur Aufgabenstellung und der FTA zu stellen.
Danach beginnen sie mit der Bearbeitung der Aufgabe.
Bei weiteren Fragen können die Studierenden den Dozierenden zu sich rufen, um die Fragen zu klären. Häufig gestellte Fragen werden gesammelt mit den kompletten Teilnehmern besprochen.
Am Ende der Übung geben die Studierenden ihre Lösung über die Online-Lernplattform ab. Sollten Studierende die Aufgabe innerhalb der Zeit nicht beendet haben, wird diese zuhause fertiggestellt und anschließend abgegeben. Die maximale Bearbeitungszeit liegt (von Freischaltung bis zur Deadline) bei einer Woche.
Nach Abgabe werden die Lösungen der Studierenden korrigiert und sie erhalten nach Abschluss der Korrektur individuelles Feedback zu ihren Abgaben

Online-Veranstaltung:

Den Studierenden wird vor der Übungseinheit, spätestens zu Beginn, das Übungsblatt mit der Aufgabe auf der Online-Lernplattform freigeschaltet.
Für die Übung treffen sich die Studierenden und Dozierenden über die Videokonferenz-Plattform
Nach Lesen der Aufgabe haben die Studierenden in der Online-Übung dann Zeit zunächst grundlegende Fragen zur Aufgabenstellung und der FTA zu stellen.
Danach werden die Studierenden in Breakout-Sessions eingeteilt und beginnen mit der Bearbeitung der Aufgabe.
Bei weiteren Fragen können die Studierenden den Dozierenden über die Hilfefunktion der Videokonferenzplattform zu sich rufen oder in den Hauptraum zurückkehren, um die Fragen zu klären.
Am Ende der Übung geben die Studierenden ihre Lösung über die Online-Lernplattform ab. Sollten Studierende die Aufgabe innerhalb der Zeit nicht beendet haben, wird diese zuhause fertiggestellt und anschließend abgegeben. Die maximale Bearbeitungszeit liegt (von Freischaltung bis zur Deadline) bei einer Woche.
Nach Abgabe werden die Lösungen der Studierenden korrigiert und sie erhalten nach Abschluss der Korrektur individuelles Feedback zu ihren Abgaben

Weniger anzeigen

Beispiele oder Materialien:

Dieses Werk ist lizenziert unter einer Creative Commons Namensnennung 4.0 International Lizenz.

Beispielaufgabe:

Erstellen sie eine Fehlerbaumanalyse auf Basis der oben genannten Beschreibung; zusätzliche Designentscheidungen können im Laufe der Analyse hinzugenommen werden, falls dies notwendig ist. Ebenfalls kann es hilfreich sein vorab einen Zustandsautomaten zum Szenario zu erstellen.

1. Fragen zur Fehlerbaumanalyse

Unter welchen Voraussetzungen bzw. in welchen Situationen sollte eine Fehlerbaumanalyse angewendet werden? In welchen Fällen ist sie wenig sinnvoll?
Welche Informationen liefert eine Fehlerbaumanalyse?
Welches sind die vier grundlegenden Elemente (und deren Bedeutung) der Syntax eines Fehlerbaumes?

2. Eine Frage zum Selbststudium

Was bedeuten Minimal Cut Sets (MCS) und Single Point Failures bei der Fehlerbaumanalyse?

3. Fehlerbaumanalyse einer Ampelschaltung

[Beschreibung der Aufgabe]
Für die Steuerung einer Ampelanlage an einer Straßenkreuzung soll auf Basis des Architekturdesigns (geeignete UML Modelle) eine Sicherheitsanalyse mit der FTA durchgeführt werden. Dabei ist vor allem die Gefahrensituation zu untersuchen, dass zwei Autos zusammenstoßen könnten.

Hinweise zur Vorbereitung:

Erstellen der Aufgabenstellung zur Fehlerbaumanalyse
Erstellen eines Beispiels zur FTA, sowie eines Templates mit gegebenem „Top Event“ zur Modellierung des Fehlerbaumes
Modellierung einer Beispiellösung

Hinweise zur Nachbereitung:

Korrektur der Lösungen der Studierenden sowie Bereitstellung des jeweiligen Feedbacks über die Online-Lernplattform
Optional: Freischalten der Beispiellösung auf der Online-Lernplattform

Hinweise zur Dauer: Dieses LLA findet innerhalb einer Übungseinheit zur begleitenden Software-Engineering Vorlesung statt und ist als einmalige Übungseinheit von 90 Minuten geplant. Gesamte Bearbeitungszeit der Aufgabe: ca. 1 Woche

Kritische Einordnung

Vorteile und Stärken:

Die Studierenden erlernen mit der Fehlerbaumanalyse die Grundaspekte einer Methodik aus dem Bereich Functional Safety (Funktionaler Sicherheit) und wenden diese praktisch an.

Grenzen und Schwächen:

Die Lösungen der Studierenden können sehr heterogen sein, da nur das „Top Event“ gegeben ist und die identifizierten Basisereignisse sowie Ereigniskombinationen sehr individuell sein können. Dadurch gibt es keine Musterlösung, sondern die Korrektur der Lösungen erfordert Flexibilität.

Literatur und weiterführende Hinweise

Figas, P.; Bartel, A.; Hagel, G. (2015): Task-based Programming Learning in Higher Education, In: Global Engineering Education Conference (EDUCON), Tallinn, IEEE (S. 634- 639).