297 lines
13 KiB
Gherkin
297 lines
13 KiB
Gherkin
# language: de
|
|
Funktionalität: Strukturansicht mit Zyklen, Komplexität und Kohäsion
|
|
Als Entwickler möchte ich auf einen Blick sehen, welche Klassen und Packages in Zyklen stecken,
|
|
wie komplex und wie kohäsiv sie sind, ohne dafür die Code-City in CodeCharta zu öffnen.
|
|
|
|
@MC-SV-001
|
|
Szenario: Die Strukturseite liegt neben der Code-City und lädt nichts nach
|
|
… damit man sie auf dem CI-Server und von der Festplatte öffnen kann, ohne Viewer und ohne CORS.
|
|
|
|
Angenommen ein Projekt mit den Packages shop.domain und shop.service
|
|
Wenn mutationCrapCodeCharta läuft
|
|
Dann liegt structure.html neben index.html
|
|
Und sie enthält ihre Daten und ihr Skript selbst
|
|
Und sie lädt nichts von anderen Servern: kein "src=", kein "@import", keine Adresse mit "http"
|
|
|
|
@MC-SV-002
|
|
Szenario: Die Seite beginnt beim obersten Package, die Ebenen als Zeilen
|
|
… damit man oben sieht, was von allem Übrigen abhängt.
|
|
|
|
Angenommen ein Package shop mit den Unter-Packages service, persistence und domain
|
|
Und service hängt von persistence ab, persistence von domain
|
|
Wenn man structure.html ohne Fragment öffnet
|
|
Dann zeigt sie das Diagramm von shop
|
|
Und service steht in einer Zeile über persistence, persistence in einer Zeile über domain
|
|
|
|
@MC-SV-003
|
|
Szenario: Ein Package öffnet sich per Klick, der Breadcrumb führt zurück
|
|
… damit man hinein- und wieder herausfindet.
|
|
|
|
Angenommen die Seite zeigt das Diagramm von shop
|
|
Wenn man auf das Package service klickt
|
|
Dann zeigt sie das Diagramm von shop.service
|
|
Und die Adresse endet auf das Fragment des Package
|
|
Und der Breadcrumb über dem Diagramm lautet "shop / service"
|
|
Und ein Klick auf "shop" im Breadcrumb zeigt wieder das Diagramm von shop
|
|
|
|
@MC-SV-004
|
|
Szenario: Das Diagramm zeigt, wer das Package nutzt und was es außerhalb nutzt
|
|
… damit man die Abhängigkeiten eines Package sieht, nicht nur die zwischen seinen Klassen.
|
|
|
|
Angenommen die Klasse OrderService in shop.service nutzt OrderRepository in shop.persistence
|
|
Und die Klasse BillingController in shop.web nutzt OrderService
|
|
Wenn man das Diagramm von shop.service öffnet
|
|
Dann steht oben unter "used by" das Package web mit 1 Klasse
|
|
Und unten unter "depends on" das Package persistence mit der Klasse OrderRepository
|
|
|
|
@MC-SV-005
|
|
Szenario: Rot heißt „im Zyklus“
|
|
… damit eine Farbe genau eine Bedeutung hat.
|
|
|
|
Angenommen die Klassen Order und Invoice in shop.domain nutzen einander
|
|
Wenn man das Diagramm von shop.domain öffnet
|
|
Dann haben Order und Invoice einen roten Rahmen
|
|
Und die Kante, die gegen die Ebenen zeigt, ist rot und biegt nach oben
|
|
Und eine Klasse ohne Zyklus hat einen grauen Rahmen
|
|
|
|
@MC-SV-006
|
|
Szenario: Ein Package-Zyklus zeigt die Klassen, die ihn schließen
|
|
… damit man weiß, welche Abhängigkeit man lösen muss.
|
|
|
|
Angenommen OrderService in shop.service nutzt drei Methoden von OrderRepository in shop.persistence
|
|
Und AuditTrail in shop.persistence nutzt nur den Typ ServiceRegistry in shop.service
|
|
Und ServiceRegistry nutzt keine Klasse von shop.persistence
|
|
Wenn man das Diagramm von shop.persistence öffnet
|
|
Dann ist die Kante von AuditTrail zum Package service rot
|
|
Und in der Box von service steht ServiceRegistry in Rot
|
|
Und die Liste der Package-Zyklen auf der Startseite nennt "AuditTrail → ServiceRegistry"
|
|
|
|
@MC-SV-007
|
|
Szenario: Füllung nach LCOM4, Höhe nach Komplexität
|
|
… damit man Kohäsion und Komplexität im selben Bild sieht.
|
|
|
|
Angenommen die Klasse Order in shop.domain mit lcom4 2 und Komplexität 16
|
|
Und die Klasse Customer in shop.domain mit lcom4 1 und Komplexität 1
|
|
Und die Klasse Invoice in shop.domain ohne LCOM4
|
|
Wenn man das Diagramm von shop.domain öffnet
|
|
Dann ist Order gelb gefüllt und Customer grün, wie in der Kohäsions-Ansicht der Code-City
|
|
Und Order ist höher als Customer
|
|
Und Invoice ist grau gefüllt
|
|
|
|
@MC-SV-008
|
|
Szenario: Tooltips erklären Werte und Farben
|
|
… damit man die Ansicht ohne Handbuch versteht.
|
|
|
|
Angenommen die Klasse Order mit lcom4 2
|
|
Wenn man mit der Maus auf Order zeigt
|
|
Dann nennt der Tooltip "LCOM4 2, yellow: two groups of methods"
|
|
Und dazu Komplexität, Change Risk, Mutation-CRAP, Ce und Ca
|
|
Und jedes Farbfeld der Legende erklärt seine Farbe in einem Tooltip
|
|
|
|
@MC-SV-009
|
|
Szenario: Die Startseite zählt die Zyklen und listet sie
|
|
… damit man ohne Suchen sieht, wo es Zyklen gibt.
|
|
|
|
Angenommen ein Klassenzyklus aus Order und Invoice in shop.domain
|
|
Wenn man structure.html ohne Fragment öffnet
|
|
Dann zeigt eine Kachel "Class cycles" die Zahl 1
|
|
Und die Liste der Klassenzyklen nennt "2 classes" in domain mit Invoice und Order
|
|
Und der Eintrag verlinkt das Diagramm von shop.domain
|
|
|
|
@MC-SV-010
|
|
Szenario: Die Seite rechnet keine Zyklen und Ebenen selbst
|
|
… damit Code-City und Strukturseite nie verschiedene Zyklen zeigen.
|
|
|
|
Angenommen codeCharta.levelization ist false
|
|
Wenn mutationCrapCodeCharta läuft
|
|
Dann enthält mutation-crap.cc.json weder isCyclic noch Ebenen
|
|
Und structure.html enthält die Ebenen und die Zyklen, die Levelization berechnet
|
|
Und ihre Kanten tragen dieselben Markierungen, die mit levelization true in mutation-crap.cc.json stehen
|
|
|
|
@MC-SV-011
|
|
Szenario: Gleiche Eingabe ergibt dieselbe Datei
|
|
… damit ein Diff der Seite nur echte Änderungen zeigt.
|
|
|
|
Angenommen derselbe Report und dieselben Klassendateien
|
|
Wenn mutationCrapCodeCharta zweimal läuft
|
|
Dann ist structure.html beide Male Byte für Byte gleich
|
|
|
|
@MC-SV-012
|
|
Szenario: Die Report-Seite verlinkt die Strukturseite, auch von der Festplatte
|
|
… damit man die Strukturseite findet, ohne ihren Namen zu kennen.
|
|
|
|
Angenommen index.html der Code-City
|
|
Wenn man sie über http oder von der Festplatte öffnet
|
|
Dann zeigt sie die Schaltfläche "Structure" mit einem Satz zu ihrem Inhalt
|
|
Und die Schaltfläche verlinkt structure.html relativ
|
|
|
|
@MC-SV-013
|
|
Szenario: Ohne JavaScript erklärt die Seite, warum sie leer ist
|
|
… damit ein CI-Server, der Skripte sperrt, keine leere Seite ohne Grund zeigt.
|
|
|
|
Angenommen ein Browser, der kein JavaScript ausführt
|
|
Wenn man structure.html öffnet
|
|
Dann sagt ein Satz, dass das Diagramm JavaScript braucht
|
|
|
|
@MC-SV-014
|
|
Szenario: Die Matrix liegt neben der Strukturseite und lädt nichts nach
|
|
… damit man sie wie die Strukturseite auf dem CI-Server und von der Festplatte öffnen kann.
|
|
|
|
Angenommen ein Projekt mit den Packages shop.domain und shop.service
|
|
Wenn mutationCrapCodeCharta läuft
|
|
Dann liegt matrix.html neben structure.html
|
|
Und sie enthält ihre Daten und ihr Skript selbst
|
|
Und sie lädt nichts von anderen Servern: kein "src=", kein "@import", keine Adresse mit "http"
|
|
|
|
@MC-SV-015
|
|
Szenario: Die Matrix beginnt mit den Kindern des obersten Package, nach Ebenen sortiert
|
|
… damit jede Abhängigkeit entlang der Ebenen rechts der Diagonale liegt.
|
|
|
|
Angenommen ein Package shop mit den Unter-Packages web, service, persistence und domain
|
|
Wenn man matrix.html ohne Fragment öffnet
|
|
Dann hat sie die Zeilen web, service, persistence und domain in dieser Reihenfolge
|
|
Und jede Zelle einer Abhängigkeit entlang der Ebenen liegt rechts der Diagonale
|
|
|
|
@MC-SV-016
|
|
Szenario: Ein Package öffnet sich an Ort und Stelle und schließt sich wieder
|
|
… damit man mehrere Packages zugleich öffnen und vergleichen kann.
|
|
|
|
Angenommen die Matrix zeigt die Kinder von shop
|
|
Wenn man auf das Package domain klickt
|
|
Dann ersetzen die Klassen von domain seine Zeile und seine Spalte
|
|
Und über ihnen steht eine Gruppenzeile domain mit "▾"
|
|
Und ein Klick auf diese Gruppenzeile schließt domain wieder
|
|
|
|
@MC-SV-017
|
|
Szenario: Rote Zellen zeigen Zyklen, dunkelrot gegen die Ebenen
|
|
… damit man in der Matrix sieht, welche Abhängigkeit einen Zyklus schließt.
|
|
|
|
Angenommen die Klassen Order und Invoice in shop.domain nutzen einander
|
|
Wenn man das Package domain öffnet
|
|
Dann ist die Zelle Order → Invoice hellrot
|
|
Und die Zelle Invoice → Order ist dunkelrot und liegt links der Diagonale
|
|
Und ihr Tooltip nennt die Klassenkante "Invoice → Order"
|
|
|
|
@MC-SV-018
|
|
Szenario: Die Spaltenköpfe nennen die Packages, um 90 Grad gedreht
|
|
… damit man eine Spalte ohne Nachzählen zuordnet.
|
|
|
|
Angenommen die Matrix zeigt die Kinder von shop
|
|
Dann zeigt jeder Spaltenkopf seine Nummer und seinen Namen, senkrecht geschrieben
|
|
Und ein Klick auf einen Package-Namen im Spaltenkopf öffnet das Package
|
|
|
|
@MC-SV-019
|
|
Szenario: Das Farbfeld einer Zeile zeigt LCOM4 oder das Änderungsrisiko
|
|
… damit man Kohäsion oder Risiko neben die Abhängigkeiten legen kann.
|
|
|
|
Angenommen die Klasse Order mit lcom4 2 und Komplexität 16
|
|
Wenn man das Package domain öffnet
|
|
Dann ist das Farbfeld von Order gelb und die Spalte C zeigt 16
|
|
Und nach einem Klick auf "Change risk" zeigt das Farbfeld das Änderungsrisiko
|
|
|
|
@MC-SV-020
|
|
Szenario: Die geöffneten Packages stehen in der Adresse
|
|
… damit Neuladen, Zurück-Taste und ein geteilter Link denselben Stand zeigen.
|
|
|
|
Angenommen man öffnet in der Matrix das Package domain
|
|
Wenn man die Seite neu lädt
|
|
Dann ist domain weiter geöffnet
|
|
Und nach der Zurück-Taste ist domain wieder geschlossen
|
|
|
|
@MC-SV-021
|
|
Szenario: Alles auf- und zuklappen
|
|
… damit man mit einem Klick das ganze Projekt oder wieder die Übersicht sieht.
|
|
|
|
Angenommen ein Projekt mit 8 Klassen
|
|
Wenn man auf "Expand all" klickt
|
|
Dann zeigt die Matrix eine Zeile je Klasse
|
|
Und "Collapse all" führt zurück zu den Kindern von shop
|
|
|
|
@MC-SV-022
|
|
Szenario: Die Report-Seite und die Reiter verbinden die Ansichten
|
|
… damit man zwischen Code-City, Strukturseite und Matrix wechseln kann.
|
|
|
|
Angenommen index.html der Code-City
|
|
Dann zeigt sie die Schaltfläche "Matrix" mit einem relativen Link auf matrix.html
|
|
Und structure.html und matrix.html haben die Reiter "Code City", "Structure" und "Matrix"
|
|
|
|
@MC-SV-023
|
|
Szenario: Gleiche Eingabe ergibt dieselbe Matrix-Datei
|
|
… damit ein Diff der Seite nur echte Änderungen zeigt.
|
|
|
|
Angenommen derselbe Report und dieselben Klassendateien
|
|
Wenn mutationCrapCodeCharta zweimal läuft
|
|
Dann ist matrix.html beide Male Byte für Byte gleich
|
|
|
|
@MC-SV-024
|
|
Szenario: Ohne JavaScript erklärt die Matrix, warum sie leer ist
|
|
… damit ein CI-Server, der Skripte sperrt, keine leere Seite ohne Grund zeigt.
|
|
|
|
Angenommen ein Browser, der kein JavaScript ausführt
|
|
Wenn man matrix.html öffnet
|
|
Dann sagt ein Satz, dass die Matrix JavaScript braucht
|
|
|
|
@MC-SV-025
|
|
Szenario: Ab 500 Klassen öffnen sich Packages nur einzeln
|
|
… damit die Matrix auch bei großen Projekten im Browser bedienbar bleibt.
|
|
|
|
Angenommen ein Projekt mit 501 Klassen
|
|
Wenn man matrix.html öffnet
|
|
Dann ist "Expand all" abgeschaltet
|
|
Und sein Tooltip nennt den Grund
|
|
|
|
@MC-SV-026
|
|
Szenario: Jede Kante eines Package-Zyklus quer zur Hierarchie ist rot
|
|
… damit man alle Packages eines Zyklus sieht, nicht nur die Kante, die ihn schließt.
|
|
|
|
Angenommen OrderService in shop.service nutzt OrderRepository in shop.persistence
|
|
Und AuditTrail in shop.persistence nutzt ServiceRegistry in shop.service
|
|
Wenn man das Diagramm von shop öffnet
|
|
Dann ist die Kante von service zu persistence rot
|
|
Und die Kante von persistence zu service ist rot und biegt nach oben
|
|
|
|
@MC-SV-027
|
|
Szenario: Ein Package-Zyklus entlang der Hierarchie ist amber
|
|
… damit ein Zyklus in einem Zweig weniger schwer wirkt als einer zwischen Zweigen.
|
|
|
|
Angenommen BillingController in shop.web nutzt InvoiceForm in shop.web.forms
|
|
Und FormFields in shop.web.forms nutzt BillingController
|
|
Wenn man das Diagramm von shop.web öffnet
|
|
Dann sind beide Kanten zwischen BillingController und forms amber
|
|
Und die Box von forms hat einen amberfarbenen Rahmen
|
|
|
|
@MC-SV-028
|
|
Szenario: In der Matrix ist ein Zyklus entlang der Hierarchie amber
|
|
… damit Matrix und Diagramm dieselbe Farbe für dieselbe Art von Zyklus zeigen.
|
|
|
|
Angenommen BillingController in shop.web und shop.web.forms nutzen einander
|
|
Wenn man das Package web öffnet
|
|
Dann sind die Zellen zwischen BillingController und forms hell und dunkel amber
|
|
|
|
@MC-SV-029
|
|
Szenario: Die Startseite zählt Package-Zyklen quer und entlang der Hierarchie getrennt
|
|
… damit man sofort sieht, ob es Zyklen zwischen Zweigen gibt.
|
|
|
|
Angenommen ein Package-Zyklus zwischen shop.service und shop.persistence
|
|
Und ein Package-Zyklus zwischen shop.web und shop.web.forms
|
|
Wenn man structure.html ohne Fragment öffnet
|
|
Dann zeigen die Kacheln "Package cycles" und "Hierarchy cycles" je die Zahl 1
|
|
|
|
@MC-SV-030
|
|
Szenario: Die Seite der Code-City sieht aus wie die Strukturseiten
|
|
… damit die drei Seiten als eine Anwendung erscheinen.
|
|
|
|
Angenommen mutationCrapCodeCharta hat index.html, structure.html und matrix.html geschrieben
|
|
Wenn man index.html öffnet
|
|
Dann zeigt sie dieselbe Kopfzeile mit den Reitern "Code City", "Structure" und "Matrix"
|
|
Und "Code City" ist der aktive Reiter
|
|
|
|
@MC-SV-031
|
|
Szenario: Die Zeilen einer umgebrochenen Ebene lassen Platz für ihre Kanten
|
|
… damit man Kanten in die unteren Zeilen einer breiten Ebene verfolgen kann.
|
|
|
|
Angenommen ein Package mit 60 Klassen auf einer Ebene
|
|
Wenn man sein Diagramm öffnet
|
|
Dann bricht die Ebene in mehrere Zeilen um, mindestens 40 Pixel voneinander entfernt
|
|
Und die zweite Zeile ist um einen halben Schritt von Kasten zu Kasten versetzt
|