Anwendungsfall: Unterschied zwischen den Versionen

aus GlossarWiki, der Glossar-Datenbank der Fachhochschule Augsburg
Keine Bearbeitungszusammenfassung
 
(44 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
{{In Bearbeitung}}
{{Qualität
{{Qualität
|correctness        = 0
|correctness        = 3
|extent              = 0
|extent              = 2
|numberOfReferences  = 0
|numberOfReferences  = 3
|qualityOfReferences = 0
|qualityOfReferences = 4
|conformance        = 0
|conformance        = 4
}}
}}


Zeile 16: Zeile 15:
wie für die Anwendung notwendig sindt.
wie für die Anwendung notwendig sindt.


== Definition (Spezifikation der „UML 2.5“, S. 637<ref name="UML 2.5">{{Quelle|OMG (2015)}}</ref>) ==
== Definition (Spezifikation der „UML 2.5“, S. 637<ref name="UML 2.5">{{Quelle|OMG (UML 2.5)}}</ref> und „UML 2.5.1“, S. 639<ref name="UML 2.5.1">{{Quelle|OMG (UML 2.5.1)}}</ref>) ==
<div class="quote">
<div class="quote">
UseCases are a means to capture the requirements of systems, i.e., what systems are supposed to do. The key concepts
UseCases are a means to capture the requirements of systems, i.e., what systems are supposed to do. The key concepts
specified in this clause are '''Actors''', '''UseCases''', and subjects. Each UseCase’s subject represents a system under
specified in this clause are '''Actors''', '''UseCases''', and ''subjects''. Each UseCase’s subject represents a system under
consideration to which the UseCase applies. Users and any other systems that may interact with a subject are represented
consideration to which the UseCase applies. Users and any other systems that may interact with a subject are represented
as Actors.
as Actors.
Zeile 27: Zeile 26:
</div>
</div>


==Typische Fehler==
===Übersetzung ([[Wolfgang Kowarschick|Kowarschick]])===
{|class="wikitable"
<div class="quote">Use-Cases ('''Anwendungsfälle''') sind Hilfsmittel, um die Anforderungen von Systemen zu erfassen, {{dh}}, um festzulegen, was Systeme tun sollen. Schlüsselkonzepte, die in diesem Abschnitt spezifiziert werden, sind '''Akteure''', '''Use-Cases''' und ''Subjekte''. Jedes Subjekt eines Use-Cases repräsentiert ein System, auf das der Use-Case angewendet werden kann. Benutzer und andere Systeme, die mit einem Subjekt interagieren können, werden durch Akteure repräsentiert.
| style="vertical-align: top;" | [[UML-Diagramme:_Typische_Fehler/Use-Cases_1|Use-Cases: Akteure und Aktionen]]<br/>&nbsp;{{Absatz}}
[[Datei:Falsch Richtig Use-Cases 1.png |link=UML-Diagramme:_Typische_Fehler/Use-Cases_1|none|200px]] 
| style="vertical-align: top;" | [[UML-Diagramme:_Typische_Fehler/Use-Cases_2|Use-Cases: Include und Extend]]<br/>&nbsp;{{Absatz}}
  [[Datei:Falsch Richtig Use-Cases 2.png |link=UML-Diagramme:_Typische_Fehler/Use-Cases_2|none|200px]]
| style="vertical-align: top;" | [[UML-Diagramme:_Typische_Fehler/Use-Cases_3|Use-Cases: Vererbung]]<br/>&nbsp;{{Absatz}}
  [[Datei:Falsch Richtig Use-Cases 3.png |link=UML-Diagramme:_Typische_Fehler/Use-Cases_3|none|200px]]
|}


==Quellen==
Ein Use-Case ist die Spezifikation eines Verhaltens. Eine Instanz eines Use-Cases verweist auf den Eintritt des zugehörigen Ereignisses. Derartige Instanzen werden häufig durch Interaktionen beschrieben.
*Vorlesungsmitschriften, Softwarengineering, Klüver, Wolfgang, Prof. Dr.
</div>
*Vorlesungsmitschriften, Multimediaprogrammierung, Kowarschick, Wolfgang, Prof. Dr.
*[http://de.wikibooks.org/wiki/Software_Engineering:_Use_Case_Diagramm Wiki Books: Software Engineering: Use Case Diagramm]
*[http://de.wikipedia.org/wiki/Anwendungsfall Wikipedia: Anwendugsfall]
*[http://www.ralfbuerger.de/sse/Analyse/AF.htm]


[[Kategorie:UML]]
== Definition (Spezifikation der „UML 2.4.1“, formal/11-08-06, S. 597<ref name="UML 2.4.1">{{Quelle|OMG (UML 2.4.1)}}</ref>) ==
[[Kategorie:Glossar]]
<div class="quote">Use cases  are a  means for  specifying  required  usages of  a system. Typically,  they are  used to capture  the requirements  of a system,  that is,  what  a  system  is  supposed  to do. The  key  concepts  associated with  use cases are  '''actors''',  '''use cases''', and the '''subject'''.  The subject is  the system under  consideration  to  which the  use cases  apply.  The  users and  any  other systems that  may  interact with  the subject are represented  as actors. Actors  always  model entities that are outside the system. The required behavior  of  the subject  is  specified by  one  or  more  use cases,  which  are  defined according  to  the needs of  actors.


{{TBD}}
...
== Bestandteile ==
'''Hauptbestandteile'''


- Szenario:
Use cases, actors,  and  systems  are described using use  case  diagrams.
</div>
===Übersetzung ([[Wolfgang Kowarschick|Kowarschick]])===
<div class="quote">Use-Cases ('''Anwendungsfälle''') sind Hilfsmittel, um benötigte Anwendungsmöglichkeiten eines Systems zu spezifizieren. Typischerweise werden sie verwendet, um die Anforderungen an ein System zu erfassen, {{dh}}, zu erfassen, um festzulegen, was ein System tun sollen.
Die den Anwendungsfällen zugeordneten Schlüsselkonzepte sind '''Akteure''', '''Use-Cases''' und das '''Subjekt'''. Das Subjekt ist das System, auf das die Use-Cases angewendet werden. Die Benutzer und beliebige andere Systeme, die mit einem Subjekt interagieren können, werden durch Akteure repräsentiert. Akteure modellieren stets Entitäten, die sich außerhalb des Systems befinden. Das erforderliche Verhalten des Subjekts wird durch ein oder mehrere Use-Cases spezifiziert, welche gemäß den Bedürfnissen von Akteuren definiert werden.
...


Ein Szenario beschreibt eine Folge von Aktionen unter bestimmten Bedingungen.
Use-Cases, Akteure und Systeme werden mit Hilfe von Use-Case-Diagrammen beschrieben.
</div>


- Konkretes Szenario:
==Akteure==
Es fällt auf, dassin der Version 2.5 im Gegensatz zur Version 2.4 nicht mehr gefordert wird, dass sich Akteure außerhalb des Systems befinden.


Beschreibt den Testfall konkreter, mit konkreten Akteuren, Werten und einem konkreten Ablauf.
In der Spezifikation 2.4.1 wird noch explizit gefordert, dass sich ein Akteur außerhalb des Systems befinden muss:


- Akteure:
Spezifikation der „UML 2.4.1“, formal/11-08-06, S. 598<ref name="UML 2.4.1"/>
<div class="quote">An Actor models a type of role played by an entity that interacts with the subject (e.g., by exchanging signals and data), but which is external to the subject (i.e., in the sense that an instance of an actor is not a part of the instance of its corresponding subject). </div>


Der Akteur ist der Nutzer des Systems. Er gehört nicht dazu, sondern er interagiert mit ihm. Es muss sich aber nicht immer um eine Person handeln, sondern kann auch ein anderes System sein. Jeder Use Case hat nur genau einen Hauptakteur. Falls mehrere Akteure an dem Szenario beteiligt sind, wird noch einmal unterschieden in:
In der Spezifikation 2.5.1 wird die Rolle der Akteuere wesentlich unspezifischer beschrieben:


''Primären Akteur:''
Spezifikation der „UML 2.5.1“, S. 640<ref name="UML 2.5.1"/>
<div class="quote">UseCases may have associated Actors, which describe how an instance of the Classifier realizing the UseCase and a user playing one of the roles of the Actor interact.


Nennt den Hauptakteur des Anwendungsbeispiels.  
...


''Sekundären Akteur:''
An Actor models a type of role played by an entity that interacts with the subjects of its associated UseCases (e.g., by exchanging signals and data). Actors may represent roles played by human users, external hardware, or other systems</div>


Nennt den Akteur der an zweiter Stelle steht, zum Beispiel das System mit dem der Kunde arbeitet.  
Das heißt, in UML 2.5 ist es beispielsweise erlaubt, das der Benutzer (human user) in der Rolle eines Avatars mit einem Use Case interagieren.
Dies wird in diesem Wiki in Tutorien zur Spieleprogrammierung, wie beispielsweise [[Pong/Modellierung|Pong]], ausgenutzt: Der Benutzer selbst kann
in einem Spiel meist nur einfach Aktionen ausführen (wie beispielsweise einen Schläger zu bewegen). Sein Stellvertreter im Spiel, {{dh}} sein Avatar (wie der Schläger in Pong) führt die eigentlichen spielentscheidenden Aktionen aus (Ball zurückschlagen, Ball abfälschen, Ball mit Punktverlust passieren lassen).


- Vorbedingungen:  
==Beziehungen zwischen Use Cases==
===Direkte Beziehungen===
Direkte Beziehungen zwischen Uses Cases kann es nur über Systemgrenzen hinweg geben:
Spezifikation der „UML 2.5.1“, S. 640<ref name="UML 2.5.1"/>
<div class="quote">Two UseCases specifying the same subject cannot be associated as
each of them individually describes a complete usage of the subject. </div>


Zählt die Vorbedingungen auf, die erfüllt sein müssen um mit dem Programm zu arbeiten.
==Use-Case-Spezifikation==
Use-Case-Diagramme beschreiben das Verhalten eines Systems nur grob. Insbeondere modellieren sie
keine zeitlichen Aspekte, {{dh}} keine Reihenfolge in der bestimmte Aktionen erfolgen können oder müssen.
Daher ist es notwendig, im Anschluss an ein Use-Case-Diagramm die einzelnen Use-Cases genauer zu spezifizieren.
Dazu werden häufig [[Use-Case-Spezifikation]]en eingesetzt (die, wenn sie auf speziellen Karten notiert werden,
auch [[Use Case Card]]s heißen). Wenn man nach den beiden Begriffen googelt, stellt man schnell fest, dass es
viele Vorschläge gibt, wie eine derartigen Spezifikation aussehen kann (siehe {{zB}} [https://www.visual-paradigm.com/guide/use-case/what-is-use-case-specification/ Visual Paradigm: What is Use Case Specification?]).


- Nachbedingungen im Erfolgsfall:  
Derzeit gibt es jedoch keine Norm dafür. Üblicherweise können/sollten folgende Informationen angegeben werden:


Gibt an was passiert und das System aus gibt wenn dieses spezielle Szenario erfolgreich abgeschlossen wurde.
* Name
* beteiligte Akteure
* Vorbedingungen, die erfüllt sein müssen, damit der Use Case ausgeführt werden kann
* Nachbedingungen, die erfüllt sind, wenn der Use Cases erfolgreich ausgeführt wurde
* Beziehungen zu anderen Use Cases
* Kurzbeschreibung
* detailierte Beschreibung (evtl. mit weiteren UML-Diagrammen, wie anderen [[Anwendungsfalldiagramm]]en, [[Aktivitätsdiagramm]]en, [[Sequenzdiagramm]]en, [[Zustandasdiagramm]]en etc.)
* Fehlerbehandlung
* Priorität
* Status
* Autor
* ...


- Nachbedingungen im Fehlerfall:  
==Typische Fehler==
{|class="wikitable"
| style="vertical-align: top;" | [[UML-Diagramme:_Typische_Fehler/Use-Cases_1|Akteure und Aktionen]]<br/>&nbsp;{{Absatz}}
[[Datei:Falsch Richtig Use-Cases 1.png |link=UML-Diagramme:_Typische_Fehler/Use-Cases_1|none|150px]] 
| style="vertical-align: top;" | [[UML-Diagramme:_Typische_Fehler/Use-Cases_2|Include und Extend]]<br/>&nbsp;{{Absatz}}
  [[Datei:Falsch Richtig Use-Cases 2.png |link=UML-Diagramme:_Typische_Fehler/Use-Cases_2|none|150px]]
| style="vertical-align: top;" | [[UML-Diagramme:_Typische_Fehler/Use-Cases_3|Vererbung]]<br/>&nbsp;{{Absatz}}
  [[Datei:Falsch Richtig Use-Cases 3.png |link=UML-Diagramme:_Typische_Fehler/Use-Cases_3|none|150px]]
| style="vertical-align: top;" | [[UML-Diagramme:_Typische_Fehler/Use-Cases_4|Systemgrenzen]]<br/>&nbsp;{{Absatz}}
  [[Datei:Falsch Richtig Use-Cases 4.png |link=UML-Diagramme:_Typische_Fehler/Use-Cases_4|none|150px]]
|}


Beschreibt alle möglichen Fehlerfälle.
==Quellen==
 
<references/>
- Ablauf der Interaktion:
<ol start="4">
 
<li>{{Quelle|Rupp, Queins, SOPHISTen (2012)}}
Es wird Schritt für Schritt beschrieben, wie die Interaktion mit dem System abläuft.
<li>{{Quelle|Kowarschick (MMDB-Skript)}}</li>
 
<li>{{Quelle|Kowarschick (MMDB)}}</li>
 
<li>{{Quelle|Kowarschick (MMProg)}}</li>
'''weitere Bestandteile'''
==Siehe auch==
 
* [[Unified Modeling Language]]
Wenn es nötig ist können auch noch mehr Bestandteile hinzugefügt werden, wie zum Beispiel:
[[Kategorie:UML]]
 
[[Kategorie:Glossar]]
- Betroffene:
 
Welche anderen Personen sind noch betroffen, zum Beispiel wenn die Anwendung länger benötigt als geplant.
 
- Risiken:
 
Was kann passieren wenn das System nicht so reagiert wie es soll.
 
- Laufzeit:
 
Wie lange darf oder soll eine bestimmte Anfrage dauern.
 
- Anzahl Benutzer:
 
Wenn es mehrere Benutzer des Systems gibt, muss darauf geachtet werden das es nicht überlastet.
 
{{In Bearbeitung}}
 
==Definition==
Ein Use Case, oder auch Anwendungsfall, ist eine Darstellung einer Interaktion zwischen einem Anwender und einem System. Es soll den Beteiligten an einem Softwareprojekt einen ersten Eindruck über die Funktionalität des Systems geben, welches entwickelt werden soll.
Dabei wird durch das Use Case Diagramm die Funktion des Systems als auch die der Benutzergruppen, Akteure, klar dargestellt.
Auf Grund des hohen Abstraktionsgrades wird sichergestellt, dass nicht nur Experten (meist Informatiker und Systemarchitekten) verstehen können, um was es sich bei dem System handelt, sondern auch Laien, wie z.B. Manager, Designer, spätere Benutzer.
 
==Aufbau==
Um einen Anwendungsfall aufzubauen, gibt es die Möglichkeit, zunächst alle wichtigen Bestandteile des Diagramms zu notieren
 
'''Ziel:'''
Welches Ziel soll das der Benutzer mit dem System erreichen?
 
'''Kontext:'''
Was ist das überhaupt für ein System?
 
'''Einschränkungen:'''
Gibt es Aufgaben, die das System selbst nicht ausführt? Ausführung durch externe Atkeure?
 
'''Primärer Akteur:'''
In der Regel der Benutzer
 
'''Sekundärer Akteur:'''
Systeme oder Akteure die nicht Bestandteil des eigentlichen Systems sind.
 
'''Betroffene:'''
Gibt es Akteure, die durch die Funktionen des Systems betroffen sind?
 
'''Vorbedingungen:'''
Welche Bedingungen müssen gegeben sein, damit dieser Anwendungsfall möglich ist?
 
'''Nachbedingung im Erfolgsfall:'''
Was passiert wenn der Anwendungsfall erfolgreich durchgeführt wurde?
 
'''Nachbedingung im Fehlerfall:'''
Was passiert wenn Fehler auftreten? Exceptionhandling.
 
Zuletzt kann der eigentliche Ablauf, in grafischer oder schriftlicher Form dargestellt werden.

Aktuelle Version vom 11. Juni 2019, 16:20 Uhr

Dieser Artikel erfüllt die GlossarWiki-Qualitätsanforderungen nur teilweise:

Korrektheit: 3
(zu größeren Teilen überprüft)
Umfang: 2
(wichtige Fakten fehlen)
Quellenangaben: 3
(wichtige Quellen vorhanden)
Quellenarten: 4
(sehr gut)
Konformität: 4
(sehr gut)

Ein Anwendungsfall (engl. Use Case) beschreibt, wie sich ein System oder eine Anwendung unter bestimmten Bedingungen verhält. Die Definition von Anwendungsfällen hat zum Ziel, zwischen den Beteiligten eines Projekts Einigung über das Verhalten und den Umfang eines Systems zu erhalten.

Die Anzahl von Anwendungsfällen ist nicht vorgeschrieben, es sollten so viele definiert werden, wie für die Anwendung notwendig sindt.

Definition (Spezifikation der „UML 2.5“, S. 637[1] und „UML 2.5.1“, S. 639[2])

UseCases are a means to capture the requirements of systems, i.e., what systems are supposed to do. The key concepts specified in this clause are Actors, UseCases, and subjects. Each UseCase’s subject represents a system under consideration to which the UseCase applies. Users and any other systems that may interact with a subject are represented as Actors.

A UseCase is a specification of behavior. An instance of a UseCase refers to an occurrence of the emergent behavior that conforms to the corresponding UseCase. Such instances are often described by Interactions.

Übersetzung (Kowarschick)

Use-Cases (Anwendungsfälle) sind Hilfsmittel, um die Anforderungen von Systemen zu erfassen, d. h., um festzulegen, was Systeme tun sollen. Schlüsselkonzepte, die in diesem Abschnitt spezifiziert werden, sind Akteure, Use-Cases und Subjekte. Jedes Subjekt eines Use-Cases repräsentiert ein System, auf das der Use-Case angewendet werden kann. Benutzer und andere Systeme, die mit einem Subjekt interagieren können, werden durch Akteure repräsentiert.

Ein Use-Case ist die Spezifikation eines Verhaltens. Eine Instanz eines Use-Cases verweist auf den Eintritt des zugehörigen Ereignisses. Derartige Instanzen werden häufig durch Interaktionen beschrieben.

Definition (Spezifikation der „UML 2.4.1“, formal/11-08-06, S. 597[3])

Use cases are a means for specifying required usages of a system. Typically, they are used to capture the requirements of a system, that is, what a system is supposed to do. The key concepts associated with use cases are actors, use cases, and the subject. The subject is the system under consideration to which the use cases apply. The users and any other systems that may interact with the subject are represented as actors. Actors always model entities that are outside the system. The required behavior of the subject is specified by one or more use cases, which are defined according to the needs of actors.

...

Use cases, actors, and systems are described using use case diagrams.

Übersetzung (Kowarschick)

Use-Cases (Anwendungsfälle) sind Hilfsmittel, um benötigte Anwendungsmöglichkeiten eines Systems zu spezifizieren. Typischerweise werden sie verwendet, um die Anforderungen an ein System zu erfassen, d. h., zu erfassen, um festzulegen, was ein System tun sollen.

Die den Anwendungsfällen zugeordneten Schlüsselkonzepte sind Akteure, Use-Cases und das Subjekt. Das Subjekt ist das System, auf das die Use-Cases angewendet werden. Die Benutzer und beliebige andere Systeme, die mit einem Subjekt interagieren können, werden durch Akteure repräsentiert. Akteure modellieren stets Entitäten, die sich außerhalb des Systems befinden. Das erforderliche Verhalten des Subjekts wird durch ein oder mehrere Use-Cases spezifiziert, welche gemäß den Bedürfnissen von Akteuren definiert werden.

...

Use-Cases, Akteure und Systeme werden mit Hilfe von Use-Case-Diagrammen beschrieben.

Akteure

Es fällt auf, dassin der Version 2.5 im Gegensatz zur Version 2.4 nicht mehr gefordert wird, dass sich Akteure außerhalb des Systems befinden.

In der Spezifikation 2.4.1 wird noch explizit gefordert, dass sich ein Akteur außerhalb des Systems befinden muss:

Spezifikation der „UML 2.4.1“, formal/11-08-06, S. 598[3]

An Actor models a type of role played by an entity that interacts with the subject (e.g., by exchanging signals and data), but which is external to the subject (i.e., in the sense that an instance of an actor is not a part of the instance of its corresponding subject).

In der Spezifikation 2.5.1 wird die Rolle der Akteuere wesentlich unspezifischer beschrieben:

Spezifikation der „UML 2.5.1“, S. 640[2]

UseCases may have associated Actors, which describe how an instance of the Classifier realizing the UseCase and a user playing one of the roles of the Actor interact.

...

An Actor models a type of role played by an entity that interacts with the subjects of its associated UseCases (e.g., by exchanging signals and data). Actors may represent roles played by human users, external hardware, or other systems

Das heißt, in UML 2.5 ist es beispielsweise erlaubt, das der Benutzer (human user) in der Rolle eines Avatars mit einem Use Case interagieren. Dies wird in diesem Wiki in Tutorien zur Spieleprogrammierung, wie beispielsweise Pong, ausgenutzt: Der Benutzer selbst kann in einem Spiel meist nur einfach Aktionen ausführen (wie beispielsweise einen Schläger zu bewegen). Sein Stellvertreter im Spiel, d. h. sein Avatar (wie der Schläger in Pong) führt die eigentlichen spielentscheidenden Aktionen aus (Ball zurückschlagen, Ball abfälschen, Ball mit Punktverlust passieren lassen).

Beziehungen zwischen Use Cases

Direkte Beziehungen

Direkte Beziehungen zwischen Uses Cases kann es nur über Systemgrenzen hinweg geben: Spezifikation der „UML 2.5.1“, S. 640[2]

Two UseCases specifying the same subject cannot be associated as each of them individually describes a complete usage of the subject.

Use-Case-Spezifikation

Use-Case-Diagramme beschreiben das Verhalten eines Systems nur grob. Insbeondere modellieren sie keine zeitlichen Aspekte, d. h. keine Reihenfolge in der bestimmte Aktionen erfolgen können oder müssen. Daher ist es notwendig, im Anschluss an ein Use-Case-Diagramm die einzelnen Use-Cases genauer zu spezifizieren. Dazu werden häufig Use-Case-Spezifikationen eingesetzt (die, wenn sie auf speziellen Karten notiert werden, auch Use Case Cards heißen). Wenn man nach den beiden Begriffen googelt, stellt man schnell fest, dass es viele Vorschläge gibt, wie eine derartigen Spezifikation aussehen kann (siehe z. B. Visual Paradigm: What is Use Case Specification?).

Derzeit gibt es jedoch keine Norm dafür. Üblicherweise können/sollten folgende Informationen angegeben werden:

  • Name
  • beteiligte Akteure
  • Vorbedingungen, die erfüllt sein müssen, damit der Use Case ausgeführt werden kann
  • Nachbedingungen, die erfüllt sind, wenn der Use Cases erfolgreich ausgeführt wurde
  • Beziehungen zu anderen Use Cases
  • Kurzbeschreibung
  • detailierte Beschreibung (evtl. mit weiteren UML-Diagrammen, wie anderen Anwendungsfalldiagrammen, Aktivitätsdiagrammen, Sequenzdiagrammen, Zustandasdiagrammen etc.)
  • Fehlerbehandlung
  • Priorität
  • Status
  • Autor
  • ...

Typische Fehler

Akteure und Aktionen
 
Falsch Richtig Use-Cases 1.png
Include und Extend
 
Falsch Richtig Use-Cases 2.png
Vererbung
 
Falsch Richtig Use-Cases 3.png
Systemgrenzen
 
Falsch Richtig Use-Cases 4.png

Quellen

  1. OMG (UML 2.5): Object Management Group; OMG Unified Modeling Language – Version 2.5; http://www.omg.org/spec/UML/2.5; 2015; Quellengüte: 5 (Web)
  2. 2,0 2,1 2,2 OMG (UML 2.5.1): Object Management Group; OMG Unified Modeling Language – Version 2.5.1; https://www.omg.org/spec/UML/2.5.1; 2017; Quellengüte: 5 (Web)
  3. 3,0 3,1 OMG (UML 2.4.1): Object Management Group; OMG Unified Modeling Language – Version 2.4.1; http://www.omg.org/spec/UML/2.4.1; 2011; Quellengüte: 5 (Web)
  1. Rupp, Queins, SOPHISTen (2012): Chris Rupp, Stefan Queins und die SOPHISTen; UML 2 glasklar: Praxiswissen für die UML-Modellierung; Verlag: Carl Hanser Verlag; ISBN: 3446430571, 978-3446430570; Web-Link; 2012; Quellengüte: 5 (Buch)
  2. Kowarschick (MMDB-Skript): Wolfgang Kowarschick; Vorlesung Multimedia-Datenbanksysteme – Sommersemester 2018; Hochschule: Hochschule Augsburg; Adresse: Augsburg; Web-Link; 2018; Quellengüte: 4 (Skript)
  3. Kowarschick (MMDB): Wolfgang Kowarschick; Vorlesung „Multimedia-Datenbanksysteme“; Hochschule: Hochschule Augsburg; Adresse: Augsburg; Web-Link; 2016; Quellengüte: 3 (Vorlesung)
  4. Kowarschick (WebProg): Wolfgang Kowarschick; Vorlesung „Web-Programmierung“; Hochschule: Hochschule Augsburg; Adresse: Augsburg; Web-Link; 2024; Quellengüte: 3 (Vorlesung)
  5. Siehe auch