Softwarequalität - Metriken

1

Die Macht der Zahlen

Source Code Metriken

Gerrit Beine, M.Sc.mail@gerritbeine.com

Prof. Dr. Wolfgang Golubskigolubski@fh-zwickau.de

2

Einige ausgewählte Metriken

3

McCabes zyklomatische Komplexität

4

McCabes zyklomatische Komplexität

● Literatur: A Complexity Measure; Thomas J. McCabe● IEEE Transactions on Software Engineering, Vol. SE-2, No.4, December 1976

● http://www.literateprogramming.com/mccabe.pdf

● Die zyklomatische Komplexität basiert auf der Graphentheorie● Ursprünglich für FORTRAN erdacht● Auf alle strukturierten und prozeduralen Sprachen anwendbar● Entscheidungen im Programm werden zu Knoten im Graph● Programmlogik wird als Kanten des Graphs interpretiert

● Zyklomatische Komplexität: ● e = edges, Kanten im Graph

● n = nodes, Knoten im Graph

● p = parts, (unabhängige) Teile des Graph

v(G)=e−n+2∗p

5

Algorithmische Ermittlung der zyklomatischen Komplexität

● Theorem: v(G) ist gleich der Anzahl der unabhängigen Zyklen des Graph.

● Ermittlung durch Zweigüberdeckung:● Übertragung des Graphen in einen

Baum

● Jeder Pfad im Graph entspricht einem Pfad im Baum

● Anwendung der Tiefensuche

● Es werden nur Knoten untersucht, die noch nicht besucht wurden

● Wurde ein Knoten besucht, ist ein neuer unabhängiger Kreis entdeckt

● Vorgehen liefert gleichzeitig Testfälle für den Graph

A

B C D

E

FA

B

E

B A F

C D

F C

A

6

Anwendung der zyklomatischen Komplexität auf objektorienten Code

● Methodenbasiert● Es werden die Kontrollstrukturen innerhalb von Methoden untersucht

● Mögliche Ergebnisse:

● v(G) für konkrete Methode, avg v(G) pro Methode / Klasse / Package (sinnfrei)

● Prozessbasiert● Sämtliche für einen Prozess relevanten Methoden werden als unabhängige

Teilgraphen (Components) betrachtet

● e sind die Kanten der Kontrollstrukturgraphen aller Methoden

● n sind die Knoten der Kontrollstrukturgraphen aller Methoden

● p ist die Anzahl der beteiligten Methoden

● Berechnung ist aufwändig (abhängig von Kopplung)

● Algorithmus liefert aber sehr interessante Aussagenu.a. über die Gesamtkomplexität von Prozessen

7

Die Halstead-Metriken

8

Die Halstead-Metriken

● Literatur: Elements of Software Science; Maurice H. Halstead● Elsevier Science Inc., New York, 1977

● Halsteadt definierte eine Reihe von Metriken zur Komplexitäts- und Aufwandsschätzung● Program vocabulary (n)

● Program length (N)

● Calculated program length

● Program volume (V)

● Program difficulty level (D)

● Program level (L)

● Effort to implement (E)

● Time to implement (T)

● Number of delivered bugs (B)

9

Berechnung der Halstead-Metriken

● Unique Operators and Operands: n1, n2● Total amount of Operators and Operands: N1, N2● Program vocabulary:● Program length:● Calculated program length:● Program volume:● Program difficulty level:● Program level:● Effort to implement:● Time to implement:● Number of delivered bugs:

N̂=n1∗log2(n1)+n2∗log2(n2)

N=N1+N2

n=n1+n2

V=N∗log2(n)

D=(N12

)∗(n22

)

L=1D

E=V∗D

T=E18

B=E

23

3000oder neu :B=

V3000

10

Kritik an Halsteadts Metriken

● Definition von Operator und Operand ist nicht festgelegt● Fenton, N., Software Measurement: A Necessary Scientific Basis. In IEEE Transactions on

Software Engineering, 1004, vol. 20(3), pp. 199-206.● Halsteads Metriken liefern keine Aussagen zur Komplexität, werden aber oft dafür

herangezogen

● Al-Qutaish, R.E., and Abran, A., An analysis of the design and definitions of Halstead’s metrics, In 15th Int. Workshop on Software Measurement, 2005, pp. 337-352.

● Die Unklarheit von Halsteads Definitionen führt zu verschiedenen Interpretationen

● Die Anwendbarkeit auf moderne Programmiersprachen ist nicht festgelegt

● Beser, N., Foundations and experiments in software science. In Selected Papers of the 1982 ACM SIGMETRICS Workshop on Software Metrics: Part 2, 1982, pp. 48-72. undDavies, G., and Tan, A., A note on metrics of Pascal programs. In ACM SIGPLAN Notices, 1987, vol. 22(8), pp. 39-44.

● Die Formel für N überschätzt die Länge kleiner Programme und unterschätzt die Länge großer Programme

11

Der Maintainability Index

12

Der Maintainability Index

● Literatur: Oman, P., Hagemeister, J.: Metrics for assessing Software System Maintainability● IEEE Int. Conference on Software Maintenance, 1994, S. 337

● Zusammenhang zwischen Codeeigenschaften und Wartungsaufwand● Basiert auf anderen Metriken

● Aufwand nach Halstead (E)

● Zyklomatische Komplexität nach McCabe (G)

● Modulgröße (LOC)

● In einer Überarbeitung kam noch hinzu● Kommentierungsgrad (CMT) prozentualer Anteil an den LOC

● Halstead-Volumen (V) alternativ zum Aufwand nach Halstead (E)

13

Der Maintainability Index

● 1992: ursprüngliche Formel

● 1994: Berücksichtigung von Kommentaren

● Interpretation

● MI > 85: gute Wartbarkeit

● 65<MI<85: mittlere Wartbarkeit

● MI<65: schlechte Wartbarkeit

● Normalisierter MI von Microsoft

● Interpretation

● 0-9 = Rot

● 10-19 = Gelb

● 20-100 = Grün

MI=171−5,2∗ln (E)−0,23∗ln (G)−16,2∗ln (LOC )

MI=171−5,2∗ln (V )−0,23∗ln (G)−16,2∗ln (LOC )+50∗sin√2,4∗CMT

MI=MAX (0,(171−5,2∗ln (V )−0,23∗ln (G)−16,2∗ln (LOC ))∗100 /171)

14

Kritik am Maintainability Index

● Korrektheit von MI wurde nur über Korrelation mit subjektivem Empfinden von Wartbarkeits-Experten geprüft (0,81-0,93)

● Reduzieren von Software auf einen einzigen Wert ist nur als Trend aussagekräftig● Beschränkung auf spezifische Metriken reduziert die Anwendbarkeit auf moderne

Programmiersprachen● Sneed, H.: “Software muss messbar werden”, Zeitschrift für Information Management, Nr.

4, 1991, S. 39● Nur 40% der Wartungskosten werden von MI tangiert, der Rest teilt sich zwischen

Wartungspersonal und Wartungsumgebung auf

15

Die Robert C. Martin-Metriken

16

Die Robert C. Martin-Metriken

● Literatur: OO Design Quality Metrics; An Analysis of Dependencies; By Robert Martin● http://www.objectmentor.com/resources/articles/oodmetrc.pdf

● Die Martin-Metriken zielen auf folgende Clean Code Prinzipien ab● Single Responsibility Principle (SRP)

● Separation of Concerns (SOC)

● Interface Segregation Principle (ISP)

● Dependecy Inversion Principle (DIP)

● Information Hiding Principle (IHP)

● Open Closed Principle (OCP)

17

Instabilität

● Ca: Afferent Couplings: Anzahl der Klassen außerhalb der Kategorie, die von Klassen innerhalb der Kategorie abhängen – eingehende Abhängigkeiten

● Ce: Efferent Couplings: Anzahl der Klassen außerhalb der Kategorie, von denen Klassen innerhalb der Kategorie abhängen – ausgehende Abhängigkeiten

● Eselsbrücke: Inversion Ca = eingehend, Ce = ausgehend

● Instability:

● Keine ausgehenden Abhängigkeiten:Hohe Stabilität, Tendenz ist I = 0

● Keine eingehenden Abhängigkeiten:Hohe Instabilität, Tendenz ist I = 1

● Grenzwertbetrachtungen:

I=Ce

Ca+Ce, I∈[0,1]; ∑

Kategorien

Ce= ∑Kategorien

Ca

limCe→ 0

CeCa+Ce

=0 limCe→∞

CeCa+Ce

=1 limCa→ 0

CeCa+Ce

=1 limCa→∞

CeCa+Ce

=0

18

Instabilität

● Hohe Stabilität (I nahe 0) ist erforderlich für● System-Kerne

Komponenten, um die eine Software herum gebaut wird.

● Datenmodelle

Ein gutes Beispiel sind EJB3 Entities. Diese sollten von keinen anderen Komponenten einer Software abhängen.

● Hohe Instabilität (I nahe 1) entsteht bei● Implementierung von externen Schnittstellen

Als Beispiel kann die Implementierung eines WebService dienen, der Funktionalität nach außen zur Verfügung stellt.Von solchen Komponenten darf innerhalb des Systems nichts abhängen.

● komplexen User Interfaces

User Interfaces führen oftmals viele Komponenten zusammen.Somit entstehen hohe Werte für ausgehende Abhängigkeiten.

19

Instabilität

● Keine Pakete mit I=0 →● Kein Systemkern

● Zyklische Abhängigkeiten vorhanden

● Viele Pakete mit I=1 →● Hohe Wartungsaufwände bei kleinen

Änderungen

● Prinzip:Je mehr Pakete mit höherer Instabilität, desto größer ist der Domino-Effekt bei Änderungen.

● Ziel:Möglichst viele stabile Pakete.Software neigt leider dazu, sich entgegengesetzt zu entwicklen.

20

Abstraktion

● NoAC: Number of Abstract Classes: Alle abstrakten Klassen eines Paketes● NoCC: Number of Concrete Classes: Alle nicht abstrakten Klassen eines Paketes● NoI: Number of Interfaces: Alle Schnittstellen eines Paketes● NoC: Number of Classes = NoAC+NoCC: Alle Klassen eines Paketes

● Abstractness

● Keine abstrakten Klassen und Schnittstellen:Niedrige Abstraktion, Tendenz ist A = 0

● Ausschließlich abstrakte Klassen und Schnittstellen:Hohe Abstraktion, Tendenz ist A = 1

● Grenzwertbetrachtungen:

A=NoAC+NoI

NoCC+NoAC+NoI=NoACINoCI

=, A∈[0,1]

limNoAC+NoI→ 0

NoAC+NoINoCC+NoAC+NoI

=0

limNoCC→∞

NoAC+NoINoCC+NoAC+NoI

=0

limNoAC+NoI→∞

NoAC+NoINoCC+NoAC+NoI

=1

limNoCC→0

NoAC+NoINoCC+NoAC+NoI

=1

21

Abstraktion

● Keine Pakete mit A=1 →● Schnittstellen nicht einzeln

distributierbar

● Viele Pakete mit A=0 →● Erweiterungen (OCP) nicht möglich

● Prinzip:Abstrakte Pakete sind entsprechend des OCP leichter zu erweitern als nicht abstrakte Pakete.

● Ziel:Definierte abstrakte Pakete, um Schnittstellen zu separieren. Gute Abstraktion benötigt viel Zeit.

22

Distanz

● Pakete sollten ausschließlich von stabileren Paketen (idealerweise auch abstrakteren Paketen) abhängen. (ISP)

● Das ist die Grundlage für Inversion of Control bzw. Dependency Injection

● Zusammenhänge zwischen Abstraktion und Instabilität● Abstrakte Pakete (A=1) sollten stabil sein (I=0), d.h. keine ausgehenden

Abhängigkeiten besitzen. Damit sind sie offen für Erweiterungen und geschlossen gegenüber Modifikationen. (OCP)

● Instabile Pakete (I=1) sollten nicht abstrakt (A=0) sein. Sie sind nicht mehr erweiterbar, unterliegen aber eine hohe Änderungswahrscheinlichkeit.

● Pakete mit balancierter Abstraktion (A=0,5) und Instabilität (I=0,5) sind noch teilweise erweiterbar, unterliegen allerdings schon einer gewissen Änderungswahrscheinlichkeit.

● Abstraktion und Instabilität sollten ausbalanciert sein.

23

Distanz

● Balance zwischen A und I ergibt einen Graphen, der folgender Formel genügt:

● Distance: ● Pakete, die sich nahe der Main Sequence

befinden, sind ausbalanciert.● Je weiter ein Paket von der Main

Sequence entfernt ist, desto schwieriger wird seine Verwendung (Area of Uselessness bei A=1 und I=1) oder seine Wartung (Area of Pain bei A=0 und I=0)

● Ziel:Optimale Pakete befinden sich an einem der Endpunkte der Main Sequence, die Entfernung zur Main Sequence (=Distanz) sollte minimal sein.

Dn=∣A+I−1∣, Dn∈[0,1]

Quelle: http://www.objectmentor.com/resources/articles/oodmetrc.pdf

24

Einige ausgewählte Metriken

Chidamber & Kemerers OO-Metriken

25

Chidamber & Kemerers OO-Metriken

● Literatur: S. R. Chidamber, C.F. Kemerer, A Metrics Suite for Object Oriented Design● IEEE Transactions on Software Engineering, 20(6), 1994, S. 476-493

● Sammlung von Metriken zur Bewertung objektorientierter Systeme● Weighted Method Count (WMC)

● Coupling Between Object Classes (CBO)

● Depth of Inheritance Tree (DIT)

● Number of Children (NOC)

● Response For a Class (RFC)

● Lack of Cohesion in Methods (LCOM)

26

Weighted Method Count (WMC) / Coupling Between Object Classes (CBO)

WMC

● Formel:● Als Komplexitätsfunktion kann z.B. die

zyklomatische Komplexität dienen● Kann als Wartungsmaß dienen, da eine

größere Anzahl komplexer Methoden höhere Wartungsaufwände verursachen kann

● Bei Vererbung führen hohe Werte von WMC zu engen Kopplungen

● Kritik: Attribute von Klassen werden nicht berücksichtigt

● Clean-Code-Prinzip: SRPSingle Responsibility Principle

CBO

● Anzahl der Klassen, die von einer Klasse benutzt werden

● Ein hoher Wert für CBO deutet auf Änderungsaufwände hin

● Entspricht dem Ce der Martin-Metrik auf Klassenebene

● Je höher der Wert von CBO, desto höher der Wert der Instability

● Fokus auf Struktur

WMC=∑i=1

n

c i

27

Number of Children (NOC) / Depth of Inheritance Tree (DIT)

NOC

● Maß für die Anzahl unmittelbar abgeleiteter Klassen

● Ein hoher Wert für NOC ist ein Indiz für häufige Wiederverwendung

● Änderungsaufwand für Klassen mit hohem Wert für NOC ist hoch

● Testaufwand für Klassen mit hohem NOC ist sehr hoch

● Clean-Code-Prinzip: FCoIFavour Composition over Inheritance

● Clean-Code-Prinzip: OCPOpen Closed Principle

DIT

● Tiefe der Verbungshierarchie einer Klasse● Anzahl geerbter Eigenschaften steigt mit

höherer DIT● Klassen mit hoher DIT können nicht

isoliert betrachtet werden● Als Maximalwert für den DIT wird im

Allgemeinen 7 angesehen● Clean-Code-Prinzip: FCoI

Favour Composition over Inheritance● Clean-Code-Prinzip: IHP

Information Hiding Principle● Clean-Code-Prinzip: OCP

Open Closed Principle

28

Response For a Class (RFC) / Lack of Cohesion in Methods (LCOM)

RFC

● Response Set: Alle Methoden einer Klasse und die von den Methoden benutzten Methoden anderer Klassen

● Hoher Wert für RFC deutet auf schlechtes Design hinsichtlich der Separation of Concerns hin

● RFC und CBO korrellieren im Allgemeinen● Fokus auf Interaktion● Clean-Code-Prinzip: SRP

Single Responsibility Principle● Clean-Code-Prinzip:

Tell, don't ask

LCOM

● Maß für die gemeinsame Nutzung von Attributen einer Klasse durch ihre Methoden

● Ein hoher Wert von LCOM weist auf schlechtes Design im Sinne der Separation of Concerns hin

● Klassen mit hohem LCOM sollten geteilt werden

● Clean-Code-Prinzip: SRPSingle Responsibility Principle

29

Fragen und Antworten

30

Das Problem mit der Kopplung

31

Das Problem mit der Kopplung

● Reale Anwendung● Anwendung enthält rund 35 Entitäten● Durchschnittliche Kopplung liegt bei

mehr als 30!

● Wartung nahezu unmöglich

● Unglücklicherweise sagt der Maintainability Index: 165

32

Welche Metriken sind wichtig und weit verbreitet?

33

Welche Metriken sind wichtig und weit verbreitet?

● Am weitesten verbreitet sind mit Sicherheit die Metrik der Lines of Code, die zyklomatische Komplexität und der Maintainability Index

● Die Verbreitung sagt aber nichts über den Nutzen einer Metrik in einem konkreten Projekt aus

● Oft werden weit verbreitete Metriken völlig falsch angewendet und damit mehr Schaden produziert, als Nutzen geschaffen

● Wichtig sind immer genau die Metriken, die die Antworten auf die Fragen liefern, die sich aus dem Ziel eines Projektes ergeben

● Es sollte nie nur eine Metrik herangezogen werden, sondern idealerweise Metriken, die orthogonal zueinander messen

● Gut ist auch der Ansatz, immer zwei Metriken zu nutzen, die die gleiche Frage beantworten: Ist die Antwort identisch, ist sie mit höherer Wahrscheinlichkeit richtig

34

Welche Tools können verwendet werden?

35

Welche Tools können verwendet werden?

● Unter Java● JDepend: Martin

● DependencyFinder & OOMetrics: Martin, Chidamber & Kemerer

● PMD: Zyklomatische Komplexität, NPath

● CheckStyle: Zyklomatische Komplexität, NPath

● Unter PHP● PHP Mess Detector: Zyklomatische Komplexität, NPath

● PhpDepend: Martin

● Unter .NET● Dependometer: Chidamber & Kemerer

36

Wie würde ein ausbalanciertes Klassendesign aussehen (z.B. I = 0.5 und A=0.5)?

37

Wie würde ein ausbalanciertes Klassendesign aussehen?

● Balanciert ist das Design nicht nur bei I=0,5 und A=0,5, sondern entlang der gesamten Main Sequence

● Der Idealzustand ist, dass jedes Paket entweder bei I=1 und A=0 oder I=0 und A=1 anzusiedeln ist.

● Praktisch ist das nicht zu realisieren (im Sinne einer wirtschaftlichen Entwicklung), allerdings ist es nicht das Ziel, I=0,5 und A=0,5 zu erreichen.

● Das Abstract-Stable-Principle besagt, dass ein Paket so stabil wie abstrakt sein soll:

A≃1−I

38

Wie würde ein ausbalanciertes Klassendesign aussehen?

Ca Ce I A

Bild 1

Model 2 0 0 0

Interfaces 1 1 0,5 1

Implementierung 0 3 1 0

Exceptions 1 0 0 0

Bild 2

Model 2 0 0 0

Interfaces 1 2 0,66 1

Implementierung 0 3 1 0

Exceptions 2 0 0 0

IF

IM

M E

IF

IM

M E

39

Wie würde ein ausbalanciertes Klassendesign aussehen?

Ca Ce I A

Bild 3

Model 3 0 0 0

Interfaces 2 1 0,33 1

Implementierung 0 3 1 0

Exceptions 2 0 0 0

Model 2 1 0,33 0

Interfaces 1 1 0,5 1

Implementierung 0 5 1 0

Exceptions 1 0 0 0

IF

IM

M E

IF

IM

M E

40

Wann ist es sinnvoll die Komplexität zu verteilen, bereits während der Programmierung oder erst beim

Refactoring?

41

Wann ist es sinnvoll die Komplexität zu verteilen,bereits während der Programmierung oder erst beim Refactoring?

● Refactoring ist Programmierung● Im Sinne des Test Driven Development

● Zunächst Funktionalität realisieren

● Danach Komplexität reduzieren

42

Stellt die "Auslagerung" der Komplexität (z.B. einer Methode) nicht einen Widerspruch hinsichtlich der

Wartbarkeit dar?

43

Stellt die "Auslagerung" der Komplexität (z.B. einer Methode)nicht einen Widerspruch hinsichtlich der Wartbarkeit dar?

● Frage wurde bezüglich der zyklomatischen Komplexität gestellt● Widersprucht besteht nicht im Sinne der Separation of Concerns

● Inhaltlich verschiedenes voneinander Trennen schafft Übersichtlichkeit

● In objektorientierten Sprachen Polymorphismus als Ersatz für Kontrollstrukturen verwenden führt zum Verschwinden von Knoten aus dem Graph

● Polymorphe Methoden bearbeiten jeweils nur einen konkreten Typ:Daraus resultierende Vereinfachung leuchtet ein :-)

44

Wie wirkt sich die Verteilung der Komplexität auf das Laufzeitverhalten (und den Speicherverbrauch)

von Programmen aus?

45

Wie wirkt sich die Verteilung der Komplexität auf das Laufzeitverhalten(und den Speicherverbrauch) von Programmen aus?

● Im besten Falle positiv, manchmal gar nicht und hin und wieder negativ.● Sichtweise 1: Dynamisches Laden von Programmteilen

● Es werden nur die Klassen überhaupt geladen, die auszuführenden Code beinhalten(z.B. Perl, PHP, teilweise auch Java)

● Sichtweise 2: Wie wirken Kontrollstrukturen im Vergleich zu Methodenrufen?● Auf der niedrigsten Ebene (Prozessor) wirken Kontrollstrukturen ebenso wie

Methodenaufrufe wie ein GOTO: Die Ausführung des Programms wird an einer anderen Adresse fortgesetzt.

● Einziger Unterschied: Beim Methodenaufruf wird die Rücksprungadresse auf dem Stack gesichert

● Der Zugriff auf Daten benötigt einen Schritt mehr, nämlich das Auslesen der Parameter von Stack

● Auswirkungen zeigen hier vor allem komplexe Datenstrukturen, die Call-by-Value übergeben werden

46

Ist die zyklomatische Komplexität auch in funktionalen Programmiersprachen einsetzbar?

47

Ist die zyklomatische Komplexität auch infunktionalen Programmiersprachen einsetzbar?

● Prinzipiell: Ja, denn der Kontrollfluss existiert auch in funktionalen Sprachen● Schwierig ist die Definition der Kontrollstrukturen

● If, Else etc. sind klar

● Stellen Listenoperationen Kontrollstrukturen dar?

● Die zyklomatische Komplexität berücksichtigt Rekursion nicht – ein Methodenaufruf ist keine Kontrollstruktur

1 val twoThree = List(2, 3) 2 val oneTwoThree = 1 :: twoThree 3 4 myList.count(s => s.length == 4) 5 myList.sort((s, t) => s.charAt(0).toLowerCase < t.charAt(0).toLowerCase)

48

Was ist unter "Nichtäquivalenz der Interaktion" zu verstehen?

49

Was ist unter "Nichtäquivalenz der Interaktion" zu verstehen?

● Gegeben sind drei Klassen: P, Q und R● Metriken liefern für P und Q die gleichen Werte: ● Sowohl P als auch Q interagieren mit R● Metriken für P+R und Q+R muss nicht gleich sein

μ(Q)=μ(P)

50

Sollte man die Metrikwerte für jedes Projekt spezifisch normieren?

51

Sollte man die Metrikwerte für jedes Projekt spezifisch normieren?

● Nein!

● Nicht für jedes Projekt, damit wäre kein Vergleich möglich● Metriken gewinnen an Wert durch Verwendung in verschiedenen Projekten

● Erfahrungspotential der Entwickler ginge verloren

● Aber: Technologische Einflüsse auf Metriken müssen berücksichtigt werden● Programmiersprachen

● Konzepte (z.B. Aspektorientierte Programmierung, Lombok)

● Wichtig ist, den Berechnungsweg der Metriken transparent zu machen

52

Wie viel Metriken sollte man in einem Projekt auf einmal betrachtet?

53

Wie viel Metriken sollte man in einem Projekt auf einmal betrachtet?

● 42

● So wenig wie möglich, so viele wie nötig● Zu viele Metriken verwirren Entwickler und stören sich u. Ust. Gegenseitig● Aber: verschiedene Metriken beleuchten unterschiedliche Aspekte● Empfehlung für Objektorientierte Softwareentwicklung

● Martin Metriken liefern Überblick

● Chidamber & Kemerer liefern Detailsicht

● Zyklomatische Komplexität für Methoden

54

Verwendung dieser Unterlagen

● Wir stellen diese Unterlagen unter der Creative Commons Lizenz CC-BY-NC-SA zur allen am Thema Interessierten Verfügung.

● Es ist erlaubt, die Unterlagen unter gleichen Bedingungen zu● kopieren

● verteilen

● übertragen und

● adaptieren, wenn

● die ursprünglichen Autoren genannt werden und● die Verwendung nicht zu kommerziellen Zwecken stattfindet.

● Details zur Lizenz sind hier zu finden:http://creativecommons.org/licenses/by-nc-sa/3.0/