Robustheitsanalyse - Versionsgeschichte

TaxonKatBot: Bot: Kategorie:UML umbenannt in Kategorie:Unified Modeling Language: laut Diskussion

2022-11-18T06:06:35Z

Bot: Kategorie:UML umbenannt in Kategorie:Unified Modeling Language: laut Diskussion

← Nächstältere Version		Version vom 18. November 2022, 08:06 Uhr
Zeile 68:		Zeile 68:

	[[Kategorie:Anforderungsmanagement]]		[[Kategorie:Anforderungsmanagement]]
	[[Kategorie:~~UML~~]]		[[Kategorie:Unified Modeling Language]]

MacOrcas: Leerzeichen vor/nach Bindestrich korrigiert

2021-04-22T20:29:53Z

Leerzeichen vor/nach Bindestrich korrigiert

← Nächstältere Version		Version vom 22. April 2021, 22:29 Uhr
Zeile 64:		Zeile 64:

	== Weblinks ==		== Weblinks ==
	* [http://www.agilemodeling.com/artifacts/robustnessDiagram.htm Agile Modeling- Robustness Diagrams]		* [http://www.agilemodeling.com/artifacts/robustnessDiagram.htm Agile Modeling - Robustness Diagrams]
	* [http://www.codeproject.com/aspnet/ModelViewController.asp Applying Robustness Analysis on the Model–View–Controller (MVC) Architecture in ASP.NET Framework, using UML]		* [http://www.codeproject.com/aspnet/ModelViewController.asp Applying Robustness Analysis on the Model–View–Controller (MVC) Architecture in ASP.NET Framework, using UML]

Aka: Abkürzung korrigiert, deutsch

2018-02-24T21:29:49Z

Abkürzung korrigiert, deutsch

← Nächstältere Version		Version vom 24. Februar 2018, 23:29 Uhr
Zeile 45:		Zeile 45:
	* Es sollte ein visueller Abgleich zwischen der Beschreibung der Anwendungsfälle und dem Robustheitsdiagramm stattfinden (Lesen des Textes der Anwendungsfälle und gleichzeitiges Nachvollziehen im Diagramm)		* Es sollte ein visueller Abgleich zwischen der Beschreibung der Anwendungsfälle und dem Robustheitsdiagramm stattfinden (Lesen des Textes der Anwendungsfälle und gleichzeitiges Nachvollziehen im Diagramm)
	* Man sollte nicht zu viele Controller Objekte in die Diagramme einbauen, die Robustheitsanalyse soll ein schneller "Sanity Check" für die Anwendungsfälle sein.		* Man sollte nicht zu viele Controller Objekte in die Diagramme einbauen, die Robustheitsanalyse soll ein schneller "Sanity Check" für die Anwendungsfälle sein.
	* Alternative Wege aus dem Anwendungsfall (z.B. im Fehlerfall) sollten ebenfalls dargestellt werden		* Alternative Wege aus dem Anwendungsfall (z. B. im Fehlerfall) sollten ebenfalls dargestellt werden

	== Beispiel ==		== Beispiel ==
	[[Bild:rbdiag.jpg\|~~thumb~~\|Beispieldiagramm]]		[[Bild:rbdiag.jpg\|mini\|Beispieldiagramm]]
	Hier ein Beispiel [[Anwendungsfall]] in verkürzter Form:		Hier ein Beispiel [[Anwendungsfall]] in verkürzter Form:
	<br>		<br>

134.155.22.106: /* Bestandteile */

2017-02-07T18:34:40Z

Bestandteile

← Nächstältere Version		Version vom 7. Februar 2017, 20:34 Uhr
Zeile 6:		Zeile 6:
	== Bestandteile ==		== Bestandteile ==

	Die Robustheitsdiagramme bestehen aus drei unterschiedlichen Objekten und dem Akteur. Die ~~Objekten~~ werden mit einer einfachen Linie verbunden. Zwischen den Objekten kann allerdings auch eine Aggregation vorliegen, wenn zum Beispiel das Boundary-Objekt „Ok-Schaltfläche“ Teil des Boundary-Objektes „Homepage“ ist.		Die Robustheitsdiagramme bestehen aus drei unterschiedlichen Objekten und dem Akteur. Die Objekte werden mit einer einfachen Linie verbunden. Zwischen den Objekten kann allerdings auch eine Aggregation vorliegen, wenn zum Beispiel das Boundary-Objekt „Ok-Schaltfläche“ Teil des Boundary-Objektes „Homepage“ ist.

	=== Boundary-Objekt ===		=== Boundary-Objekt ===

Jansan: Schreibweise verbessert, deutsche Begriffe bevorzugt (insbes. Anwendungsfall statt Use Case, so wie auch im Artikel "Anwendungsfall" verwendet)

2015-03-30T13:19:12Z

Schreibweise verbessert, deutsche Begriffe bevorzugt (insbes. Anwendungsfall statt Use Case, so wie auch im Artikel "Anwendungsfall" verwendet)

← Nächstältere Version		Version vom 30. März 2015, 15:19 Uhr
Zeile 1:		Zeile 1:
	Die '''Robustheitsanalyse''' ist ein Verfahren in der [[Softwaretechnik]], mit dem man [[~~Use Case~~]]s auf verschiedene Aspekte untersuchen kann. Dabei wird der vorhandene ~~Use~~ ~~Case~~ ~~Text~~ analysiert und in seine Bestandteile zerlegt. Als Ergebnis der Analyse wird ein '''Robustheitsdiagramm''' erstellt, welches im Grunde einem vereinfachten [[Kollaborationsdiagramm]] entspricht. <br>		Die '''Robustheitsanalyse''' ist ein Verfahren in der [[Softwaretechnik]], mit dem man [[Anwendungsfall\|Anwendungsfälle]] auf verschiedene Aspekte untersuchen kann. Dabei wird der vorhandene Text des Anwendungsfalls analysiert und in seine Bestandteile zerlegt. Als Ergebnis der Analyse wird ein '''Robustheitsdiagramm''' erstellt, welches im Grunde einem vereinfachten [[Kollaborationsdiagramm]] entspricht. <br>
	Durch die Anwendung der Analyse wird in erster Linie ein [[Sanity Check]] des ~~Use Cases~~ durchgeführt. Es wird geprüft, ob der Text in sich schlüssig ist oder irrationale Abläufe möglich sind. Dabei können auch weitere Objekte im Domänenmodell gefunden werden, die vorher nicht im Fokus waren. Ebenfalls hilft die Robustheitsanalyse, fehlende Alternativrouten im ~~Use~~ ~~Case~~ ~~Text~~ aufzudecken, zum Beispiel wenn ein Vorgang fehlschlägt.		Durch die Anwendung der Analyse wird in erster Linie ein [[Sanity Check]] des Anwendungsfalls durchgeführt. Es wird geprüft, ob der Text in sich schlüssig ist oder irrationale Abläufe möglich sind. Dabei können auch weitere Objekte im Domänenmodell gefunden werden, die vorher nicht im Fokus waren. Ebenfalls hilft die Robustheitsanalyse, fehlende Alternativrouten im Text des Anwendungsfalls aufzudecken, zum Beispiel wenn ein Vorgang fehlschlägt.

	Die Robustheitsanalyse schließt die Lücke zwischen der reinen Analyse (~~Use Case~~ – Was soll geschehen?) und dem Design (Sequenzdiagramm – Wie soll es geschehen?). Durch konsequente Analyse aller ~~Use Cases~~ wird aus dem ursprünglichen Domänenmodell ein Klassenmodell. Aus einem Klassenmodell wiederum kann ~~von~~ geeigneten ~~Tools~~ der Rumpfcode der Anwendung automatisch generiert werden.		Die Robustheitsanalyse schließt die Lücke zwischen der reinen Analyse (Anwendungsfall – Was soll geschehen?) und dem Design (Sequenzdiagramm – Wie soll es geschehen?). Durch konsequente Analyse aller Anwendungsfälle wird aus dem ursprünglichen Domänenmodell ein Klassenmodell. Aus einem Klassenmodell wiederum kann mit geeigneten Werkzeugen der Rumpfcode der Anwendung automatisch generiert werden.

	== Bestandteile ==		== Bestandteile ==

	Die Robustheitsdiagramme bestehen aus 3 unterschiedlichen Objekten und dem Akteur. Die ~~Objekte~~ werden mit einer einfachen Linie verbunden. Zwischen den Objekten kann allerdings auch eine Aggregation vorliegen, wenn zum Beispiel das Boundary Objekt „Ok ~~Button“~~ Teil des Boundary Objektes „Homepage“ ist.		Die Robustheitsdiagramme bestehen aus drei unterschiedlichen Objekten und dem Akteur. Die Objekten werden mit einer einfachen Linie verbunden. Zwischen den Objekten kann allerdings auch eine Aggregation vorliegen, wenn zum Beispiel das Boundary-Objekt „Ok-Schaltfläche“ Teil des Boundary-Objektes „Homepage“ ist.

	=== Boundary ~~object~~ ===		=== Boundary-Objekt ===
	* Bilden die Schnittstelle zwischen Akteur und dem System		* Bilden die Schnittstelle zwischen Akteur und dem System
	* Repräsentieren meistens ~~Buttons~~, Eingabefelder, aber auch ganze Dialoge oder Menüs		* Repräsentieren meistens Schaltflächen, Eingabefelder, aber auch ganze Dialoge oder Menüs
	* Sollten leicht [[~~Use Case~~]] Texten entnommen werden können		* Sollten leicht [[Anwendungsfall]]-Texten entnommen werden können
	* Sind Substantive im ~~Use~~ ~~Case~~ ~~Text~~		* Sind Substantive im Text des Anwendungsfalls
	=== Entity ~~object~~ ===		=== Entity-Objekt ===
	* Repräsentieren Objekte aus dem Domänenmodell		* Repräsentieren Objekte aus dem Domänenmodell
	* Oft entsprechen sie ~~Datenbankeinträgen~~		* Oft entsprechen sie Datenbanktabellen
	* Die Information die von dem Objekt gehalten wird, überlebt den ~~Use Case~~		* Die Information die von dem Objekt gehalten wird, überlebt den Anwendungsfall
	* Sind Substantive im ~~Use~~ ~~Case~~ ~~Text~~		* Sind Substantive im Text des Anwendungsfalls
	=== Control ~~object~~ ===		=== Control-Objekt ===
	* Werden als Steuerungsobjekte zwischen Boundary und Entity verwendet und auch Controller genannt		* Werden als Steuerungsobjekte zwischen Boundary und Entity verwendet und auch Controller genannt
	* Sind als Verben im ~~Use~~ ~~Case~~ ~~Text~~ zu finden		* Sind als Verben im Text des Anwendungsfalls zu finden
	* Oft werden Controller erst als Platzhalter benutzt, die später durch Methoden von Boundary / Entity Objekten ersetzt werden		* Oft werden Controller erst als Platzhalter benutzt, die später durch Methoden von Boundary / Entity-Objekten ersetzt werden
	=== Akteur ===		=== Akteur ===
	* Der Akteur interagiert mit dem System		* Der Akteur interagiert mit dem System
	* In der Regel stellt der Akteur ~~den~~ späteren Endanwender dar		* In der Regel stellt der Akteur einen späteren Endanwender dar
	<gallery>		<gallery>
	Bild:Robustness Diagram Boundary.svg\|Boundary		Bild:Robustness Diagram Boundary.svg\|Boundary
Zeile 34:		Zeile 34:
	== Regeln ==		== Regeln ==
	Es gibt vier grundlegende Regeln, die man bei Erstellung der Diagramme beachten muss:		Es gibt vier grundlegende Regeln, die man bei Erstellung der Diagramme beachten muss:
	# Akteure können nur mit Boundary Objekten kommunizieren		# Akteure können nur mit Boundary-Objekten kommunizieren
	# Boundary Objekte können nur mit Akteuren und Controllern kommunizieren		# Boundary-Objekte können nur mit Akteuren und Controllern kommunizieren
	# Entity Objekte können nur mit Controllern kommunizieren		# Entity-Objekte können nur mit Controllern kommunizieren
	# Control Objekte können mit Boundary, Entity und anderen Controllern kommunizieren, jedoch nicht mit Akteuren		# Control-Objekte können mit Boundary, Entity und anderen Controllern kommunizieren, jedoch nicht mit Akteuren

	== Richtlinien ==		== Richtlinien ==
	Im Allgemeinen sollte man die Analyse und den Modellierungsgrad nicht übertreiben. Es soll eher als integrierter Schritt nach dem Erstellen der [[~~Use Case~~\|~~Use Cases~~]] verstanden werden, anstatt einer eigenständigen und unabhängigen Analyse.		Im Allgemeinen sollte man die Analyse und den Modellierungsgrad nicht übertreiben. Es soll eher als integrierter Schritt nach dem Erstellen der [[Anwendungsfall\|Anwendungsfälle]] verstanden werden, anstatt einer eigenständigen und unabhängigen Analyse.
	In einem Artikel des "software development magazine" haben Kendall Scott und Doug Rosenberg die häufigsten / typischen Fehler analysiert und Vorgehensweisen beschrieben wie diese zu umgehen sind. Hier die wichtigsten als allgemeine Richtlinien, zum Erstellen von Robustheitsdiagrammen, formuliert:		In einem Artikel des "software development magazine" haben Kendall Scott und Doug Rosenberg die häufigsten / typischen Fehler analysiert und Vorgehensweisen beschrieben wie diese zu umgehen sind. Hier die wichtigsten als allgemeine Richtlinien, zum Erstellen von Robustheitsdiagrammen, formuliert:
	* Man sollte das statische Domänenmodell nach den Erkenntnissen der Robustheitsanalyse aktualisieren (neu gefundene Objekte eintragen)		* Man sollte das statische Domänenmodell nach den Erkenntnissen der Robustheitsanalyse aktualisieren (neu gefundene Objekte eintragen)
	* Es sollte ein visueller Abgleich zwischen ~~Use~~ ~~Case~~ ~~Text~~ und dem Robustheitsdiagramm stattfinden (Lesen des ~~Use~~ ~~Case~~ ~~Textes~~ und ~~gleichzeitige~~ ~~Nachvollziehung~~ im Diagramm)		* Es sollte ein visueller Abgleich zwischen der Beschreibung der Anwendungsfälle und dem Robustheitsdiagramm stattfinden (Lesen des Textes der Anwendungsfälle und gleichzeitiges Nachvollziehen im Diagramm)
	* Man sollte nicht zu viele Controller Objekte in die Diagramme einbauen, die Robustheitsanalyse soll ein schneller "Sanity Check" für die ~~Use Cases~~ sein.		* Man sollte nicht zu viele Controller Objekte in die Diagramme einbauen, die Robustheitsanalyse soll ein schneller "Sanity Check" für die Anwendungsfälle sein.
	* Alternative Wege aus dem ~~Use Case~~ (z.B. im Fehlerfall) sollten ebenfalls dargestellt werden		* Alternative Wege aus dem Anwendungsfall (z.B. im Fehlerfall) sollten ebenfalls dargestellt werden

	== Beispiel ==		== Beispiel ==
	[[Bild:rbdiag.jpg\|thumb\|Beispieldiagramm]]		[[Bild:rbdiag.jpg\|thumb\|Beispieldiagramm]]
	Hier ein Beispiel [[~~Use Case~~]] in verkürzter Form:		Hier ein Beispiel [[Anwendungsfall]] in verkürzter Form:
	<br>		<br>
	'''~~Use~~ ~~Case~~ ~~Name~~:''' Anmeldung		'''Name des Anwendungsfalls:''' Anmeldung
	<br>		<br>
	'''Beschreibung:''' Nutzer meldet sich an Mitgliederseite an		'''Beschreibung:''' Nutzer meldet sich an Mitgliederseite an
Zeile 57:		Zeile 57:
	'''Beteiligte Akteure:''' Mitglied, Webserver, Nutzerdatenbank		'''Beteiligte Akteure:''' Mitglied, Webserver, Nutzerdatenbank
	<br>		<br>
	'''Ablaufschritte (~~normal~~ ~~flow~~):'''<br>		'''Ablaufschritte (normaler Ablauf):'''<br>
	* Der Benutzer gibt ~~seine User ID~~ und ~~Passwort~~ auf der Anmeldeseite ein und betätigt ~~den~~ OK ~~Button~~.		* Der Benutzer gibt Nutzernamen und Kennwort auf der Anmeldeseite ein und betätigt die Schaltfläche "Ok".
	* Das System vergleicht die eingegebenen Daten mit denen in der Benutzerdatenbank und liefert die Mitgliederseite.		* Das System vergleicht die eingegebenen Daten mit denen in der Benutzerdatenbank und liefert die Mitgliederseite.
	<br>		<br>
	~~Der~~ Abgleich zwischen Text und Diagramm ~~sollte~~ parallel ~~ablaufen. Den~~ Text ~~lesen~~ und die Aktionen im Diagramm ~~verfolgen~~. An dieser Stelle wird auch sichtbar, dass man keine Alternative modelliert hat, ~~falls~~ die Daten des Benutzers nicht korrekt eingegeben wurden.		Beim Abgleich zwischen Text und Diagramm sollten parallel der Text gelesen und die Aktionen im Diagramm verfolgt werden. An dieser Stelle wird auch sichtbar, dass man keine Alternative für den Fall modelliert hat, dass die Daten des Benutzers nicht korrekt eingegeben wurden.

	== Weblinks ==		== Weblinks ==

Bormaschine: Änderungen von 192.109.190.88 (Diskussion) wurden auf die letzte Version von Curtis Newton zurückgesetzt

2011-09-19T10:03:21Z

Änderungen von 192.109.190.88 (Diskussion) wurden auf die letzte Version von Curtis Newton zurückgesetzt

← Nächstältere Version		Version vom 19. September 2011, 12:03 Uhr
Zeile 66:		Zeile 66:
	* [http://www.agilemodeling.com/artifacts/robustnessDiagram.htm Agile Modeling- Robustness Diagrams]		* [http://www.agilemodeling.com/artifacts/robustnessDiagram.htm Agile Modeling- Robustness Diagrams]
	* [http://www.codeproject.com/aspnet/ModelViewController.asp Applying Robustness Analysis on the Model–View–Controller (MVC) Architecture in ASP.NET Framework, using UML]		* [http://www.codeproject.com/aspnet/ModelViewController.asp Applying Robustness Analysis on the Model–View–Controller (MVC) Architecture in ASP.NET Framework, using UML]

	== Literatur ==
	* Paul Chlebek: ''Praxis der User Interface-Entwicklung: Informationsstrukturen, Designpatterns, Vorgehensmuster'', Vieweg+Teubner, Mainz 2011, ISBN 978-3-8348-0728-1

	[[Kategorie:Anforderungsmanagement]]		[[Kategorie:Anforderungsmanagement]]

192.109.190.88: /* Weblinks */

2011-09-19T09:32:48Z

Weblinks

← Nächstältere Version		Version vom 19. September 2011, 11:32 Uhr
Zeile 66:		Zeile 66:
	* [http://www.agilemodeling.com/artifacts/robustnessDiagram.htm Agile Modeling- Robustness Diagrams]		* [http://www.agilemodeling.com/artifacts/robustnessDiagram.htm Agile Modeling- Robustness Diagrams]
	* [http://www.codeproject.com/aspnet/ModelViewController.asp Applying Robustness Analysis on the Model–View–Controller (MVC) Architecture in ASP.NET Framework, using UML]		* [http://www.codeproject.com/aspnet/ModelViewController.asp Applying Robustness Analysis on the Model–View–Controller (MVC) Architecture in ASP.NET Framework, using UML]

			== Literatur ==
			* Paul Chlebek: ''Praxis der User Interface-Entwicklung: Informationsstrukturen, Designpatterns, Vorgehensmuster'', Vieweg+Teubner, Mainz 2011, ISBN 978-3-8348-0728-1

	[[Kategorie:Anforderungsmanagement]]		[[Kategorie:Anforderungsmanagement]]

Curtis Newton: Änderungen von 79.219.179.80 (Diskussion) wurden auf die letzte Version von ScottSteiner zurückgesetzt

2011-08-07T16:43:50Z

Änderungen von 79.219.179.80 (Diskussion) wurden auf die letzte Version von ScottSteiner zurückgesetzt

← Nächstältere Version		Version vom 7. August 2011, 18:43 Uhr
Zeile 62:		Zeile 62:
	<br>		<br>
	Der Abgleich zwischen Text und Diagramm sollte parallel ablaufen. Den Text lesen und die Aktionen im Diagramm verfolgen. An dieser Stelle wird auch sichtbar, dass man keine Alternative modelliert hat, falls die Daten des Benutzers nicht korrekt eingegeben wurden.		Der Abgleich zwischen Text und Diagramm sollte parallel ablaufen. Den Text lesen und die Aktionen im Diagramm verfolgen. An dieser Stelle wird auch sichtbar, dass man keine Alternative modelliert hat, falls die Daten des Benutzers nicht korrekt eingegeben wurden.

	== Literatur ==
	* Paul Chlebek: ''Praxis der User Interface-Entwicklung: Informationsstrukturen, Designpatterns, Vorgehensmuster.'' Vieweg+Teubner, Mainz 2011, ISBN 978-3-8348-0728-1.

	== Weblinks ==		== Weblinks ==

79.219.179.80 am 7. August 2011 um 14:06 Uhr

2011-08-07T14:06:05Z

← Nächstältere Version		Version vom 7. August 2011, 16:06 Uhr
Zeile 62:		Zeile 62:
	<br>		<br>
	Der Abgleich zwischen Text und Diagramm sollte parallel ablaufen. Den Text lesen und die Aktionen im Diagramm verfolgen. An dieser Stelle wird auch sichtbar, dass man keine Alternative modelliert hat, falls die Daten des Benutzers nicht korrekt eingegeben wurden.		Der Abgleich zwischen Text und Diagramm sollte parallel ablaufen. Den Text lesen und die Aktionen im Diagramm verfolgen. An dieser Stelle wird auch sichtbar, dass man keine Alternative modelliert hat, falls die Daten des Benutzers nicht korrekt eingegeben wurden.

			== Literatur ==
			* Paul Chlebek: ''Praxis der User Interface-Entwicklung: Informationsstrukturen, Designpatterns, Vorgehensmuster.'' Vieweg+Teubner, Mainz 2011, ISBN 978-3-8348-0728-1.

	== Weblinks ==		== Weblinks ==

ScottSteiner am 23. Februar 2011 um 08:45 Uhr

2011-02-23T08:45:55Z

← Nächstältere Version		Version vom 23. Februar 2011, 10:45 Uhr
Zeile 26:		Zeile 26:
	* In der Regel stellt der Akteur den späteren Endanwender dar		* In der Regel stellt der Akteur den späteren Endanwender dar
	<gallery>		<gallery>
	Bild:~~Boundary~~ 2.svg\|Boundary		Bild:Robustness Diagram Boundary.svg\|Boundary
	Bild:Robustness Diagram Entity.svg\|Entity		Bild:Robustness Diagram Entity.svg\|Entity
	Bild:Robustness Diagram Control.svg\|Controller		Bild:Robustness Diagram Control.svg\|Controller