Wir sind ein Dresdner IT-Beratungsunternehmen,
gegründet im Jahre 2008. Unsere Schwerpunkte
liegen in den Bereichen Softwareentwicklung,
Architektur-beratung und Training. Gemeinsam
mit unseren Kunden entwerfen und
implementieren wir fachlich passgenaue Lösungen
auf Basis der Java-Technologien.
buschmais GbR
Inhaber
Torsten Busch, Frank Schwarz,
Dirk Mahler und Tobias Israel
Adresse
Leipziger Str. 93
01127 Dresden
info@buschmais.com
www.buschmais.de

 Eine Medaille – Zwei Seiten
◼ Hohe Komplexität, aufwendig zu pflegen
◼ Bewährtes Rückgrat betrieblicher Abläufe

 Geschäftliche Rahmenbedingungen ändern sich kontinuierlich
◼ Mitbewerber, Geschäftsmodelle, …
 Kann das System folgen?

 Grundlegende qualitative Eigenschaften
◼ Skalierbarkeit, Performanz, Sicherheit, Wartbarkeit, ...
 Manifestierung in Code und Prozessen
◼ Technologien, Strukturen, Muster, Test-Strategie, ...
 Änderungen? Aufwändig und riskant!

 Notwendigkeit der (kontinuierlichen) Anpassung
 Begrenztes und unsicheres Wissen
◼ Risiko für Planung, Implementierung und Refaktorisierung
◼ Kann zu Angst vor Änderungen führen
 Kontinuierliche Verschlechterung der Situation als Resultat

Dokumentierte Architektur
<>
Gefühlte Architektur
<>
Reale Architektur

Neu-Implementierung
Zerlegung in Microservices
Restruktukrierung des Mononlithen

 Open-Source e-Commerce System „shopizer“
◼ Warenkorb
◼ Katalog
◼ Suche
◼ Bestellung
◼ Shop-Administration
 Fork: https://github.com/buschmais/shopizer

 Szenario: Katalog sorgt für hohe Systemlast zu Spitzenzeiten
◼ Gesamtes System muss skaliert werden
Allokation theoretisch unnötiger Ressourcen
◼ Wettkampf um verfügbare Ressourcen
Behinderung anderer Funktionalitäten
◼ Lastbedingte Ausfälle betreffen gesamtes System

 Lösung
◼ Herauslösen des Katalogs
 Problem(e)
◼ Wieviel (und welcher) Code ist betroffen?
◼ Welche Schnittstellen existieren bzw. müssen geschaffen werden?
◼ Welche Daten müssen repliziert werden?
◼ Welches Vorgehen ist das richtige?
◼ …

https://spongebob.fandom.com/wiki/List_of_time_cards

https://imgflip.com/memegenerator/Skeptical-Baby

https://builder.cheezburger.com/Builder/RenderPreview/65f84df1-bae0-4cb8-9602-5205a7caf98d

 Data Analytics für Software Systeme
◼ Extraktion und Zusammenführung von Informationen aus
Source Code
Statischen und dynamischen Eigenschaften
Entwicklungshistorien
◼ Schlussfolgern von neuen Informationen zum Aufbau von Wissen

 Dokumentation von Erkenntnissen
◼ Unterstützung von Planung und Refaktorisierung
◼ Referenz für (neue) Entwickler
◼ Kommunikationsgrundlage für Entwickler und Entscheider

https://www.kino.de/serie/hoer-mal-wer-da-haemmert-1999/news/hoer-mal-wer-da-haemmert-tim-allen-bringt-neue-folgen-ins-gespraech/

 Tooling
◼ jQAssistant
Scan der Applikation und Abbildung in Graphdatenbank
◼ Neo4j
Persistierung und Abfrage von Informationen
◼ Jupyter Notebook
Dokumentation der Analyseschritte und Ergebnisse

service
:Package
Product
Service
:CONTAINS
:Type:Java
Match (:Package{name: ‘‘service“})-[:CONTAINS]->(type:Type:Java) RETURN type
Node NodeRelationship
LABEL PROPERTY LABELVAR

 Schier unendliche Menge an
möglichen Fragestellungen
◼ Abhängig von Ziel und Qualität
sowie Quantität der
vorliegenden Daten
https://makeameme.org/meme/possibilities-are-endless-59fa8f

 Wie ist die Anwendung technisch strukturiert?
 Wie ist die Anwendung fachlich strukturiert?
 Wie hängen die einzelnen Fachlichkeiten zusammen?
 Welcher Code wird am häufigsten geändert?

Vorbereitung der Anwendung

<plugin>
<groupId>com.buschmais.jqassistant</groupId>
<artifactId>jqassistant-maven-plugin</artifactId>
<version>1.6.0</version>
<executions><execution>
<goals>
<goal>scan</goal>
<goal>analyze</goal>
</goals>
</execution></executions>
<.../>
</plugin>

mvn clean install jqassistant:server
→ localhost:7474

https://www.memecreator.org/meme/lets-get-to-work81

Wie ist die Anwendung technisch strukturiert?

 Technischen Architekturelemente (z.B. Layer)
 Abhängigkeiten zwischen technischen Architekturelementen
 Umsetzung der technischen Architektur im Code
 Aussagekraft der Ergebnisse

 Live-Demo
◼ Abhängigkeit zwischen maven-
Modulen
◼ Zuordnung von Artefakten zu
Layern (Presentation, Domain,
Data Layer)
<<maven>>
sm-shop
<<maven>>
sm-core
<<maven>>
sm-core-modules
<<maven>>
sm-core-model

 Learning Outcomes
◼ die Anwendung folgt einer klassischen 3-Schichten-Architektur
◼ die Richtungen der Abhängigkeiten wurden korrekt implementiert
◼ es konnten 100% des Codes zu technischen Schichten zugeordnet
werden

Wie ist die Anwendung fachlich strukturiert?

 Implementierte Subdomänen
 Fachliche Architekturelemente (z.B. Module)
 Umsetzung der fachlichen Architektur im Code
 Aussagekraft der Ergebnisse

 Wo ist eine gute fachliche Strukturierung am ehesten zu
erwarten?
◼ Spring-Services
◼ Paketnamen (service, konkrete Fachlichkeiten wenn bekannt)
◼ Explorieren der Anwendung in IDE

 Live-Demo
◼ Fachliche Packages
(Subdomänen)
◼ Zuordnung von Klassen zu
Subdomänen anhand Package-
Namen
Classes
catalog common content customer
merchant order payments reference
search shipping shoppingcart system
tax user

 Learning Outcomes
◼ die Geschäftslogik teilt sich in 13 fachlich motivierte Subdomänen
◼ es konnten 69% aller Klassen zu Fachlichkeiten zugeordnet werden
◼ der Katalog ist mit 140 Klassen die größte Subdomäne

Wie hängen die Fachlichkeiten zusammen?

 Existierende Abhängigkeiten zwischen Subdomänen
◼ Erlaubte und Unerwartete/Verbotene Abhängigkeiten
◼ Anzahl an Abhängigkeiten
◼ Hot Spots

 Live-Demo
◼ Visualisierung von
Abhängigkeiten
◼ Analyse von
Ein- und Ausgehenden
Abhängigkeiten
Kopplungsgrad
Hot-Spot Klassen

 Learning Outcomes
◼ die Suche gehört exklusiv zum Katalog
◼ die Kommunikation zwischen Katalog und Kern ist schwach durch
Interfaces entkoppelt

 Learning Outcomes
◼ der Katalog definiert 169 Abhängigkeiten zum Kern auf Klassenebene,
27 davon gegen Interfaces
Hot Spots sind MerchantStore und Language

 Learning Outcomes
◼ der Kern definiert 162 Abhängigkeiten zum Katalog auf Klassenebene,
5 davon gegen Interfaces
Hot Spot ist Product

War‘s das?

 Software Analytics bietet nahezu unbegrenzte Möglichkeiten
 Analyse abhängig von
◼ betrachtetem Softwaresystem
◼ vorhandenen Daten
◼ Fragestellungen

 Weitere Analysen
◼ Ownership von Subdomänen, Fix-Commits
◼ Testcoverage, Teststruktur
◼ Defektdichten
◼ Toter Code
◼ Analyse von Laufzeitdaten
◼ ...

 Bewertung der Ergebnisse notwendig
◼ Tiefergehende Analysen für kritische Stellen
◼ Relevanz und Priorisierung
◼ Planung von Refaktorisierung und Implementierung
◼ Management von Technical Debt

 2-Tages Workshop
 Strukturiert vom Monolithen zum
Modulithen und Microservices
 Interaktiv am Beispiel eines e-
Commerce Shopsystems
 Nächster Termin: November 2019
https://www.buschmais.de/seminare/lasst-uns-einen-monolithen-zerlegen/

Fragen bitte an: Stephan Pirnbaum
buschmais GbR
Inhaber
Torsten Busch, Frank Schwarz,
Dirk Mahler und Tobias Israel
stephan.pirnbaum@buschmais.com
http://buschmais.de/
Dresden, 21.05.2019