Seminar Softwaretechnik SS2005 Radouane El Marjani ( [email protected] ) Institut für...

Seminar Softwaretechnik SS2005 Radouane El Marjani ([email protected])

Institut für Softwaretechnik und theoretische Informatik

Fakultät IV - Elektrotechnik und Informatik TU Berlin

Prof. Dr.-Ing. Stefan Jähnichen

Bad Smells in Packages, Subsysteme und Schichten

Radouane El Marjani – Informatik

Betreuerin

Dipl.-Inform. Susanne Jucknath-John

Gliederung

Refactoring & Smells.

Code-Smells & Architektur-Smells.

Smells in Packages und ihre Arten.

Smells in Subsystemen und ihre Arten.

Smells in Schichten und ihre Arten.


Refactoring & Smells Refactoring ist:Verbesserung des Designs von Code, nachdem er geschrieben wurde.

Ziel von Refactoring ist:Veränderung trotz Beibehaltung des Verhaltens nach außen hin.

Beim Betrachtung eines Systems von erfahrenen Entwickler, bekommen sie sehr schnell ein Gefühl für die Schwachstellen des Systems.

Man sagt das System riecht, es hat Smells.


Code- und Architektur-Smells

Code-Smells sind kleine Gerüche(z.B. lange Methoden), die mit den kleinen Refactorings beheben lassen.

Architektur-Smells weisen aber auf die Stellen in der Architektur des Systems hin, die genauer analysiert werden sollten.Folgerichtig führen zu großen Refactoring.


Architektur-Smells

Architektur-Smells sind auf unterschiedlichen Ebenen zu finden:

In den Benutzungs- und Vererbungsbeziehungen zwischen Klassen

Innerhalb und zwischen Packages.

In und zwischen Subsystemen.

In und zwischen Schichten (Layer).


Smells Arten in Packages(1)

Unbenutzte Packages.

Zyklen zwischen Packages.

Zu kleine Packages.

Zu große Packages.

Packages zu tief oder unausgewogen geschachtelt

Packages unklar benannt


Smells Arten in Packages(2)Unbenutzte Packages belasten das System.

Unbenutzte Packages entstehen vor allem aus drei Gründen:

Refactoring.

Veränderte Anforderungen.

Technologie auf Vorrat.


Smells Arten in Packages(3)Zyklen zwischen Packages können über Benutzung oder Vererbung gebildet werden und deuten häufig auf ungünstig geschnittene Packages hin.

Zyklen zwischen Packages erschweren:Wiederverwendbarkeit.

Verständlichkeit.

Testbarkeit.

Entwurfsklarheit.


A

B C


Zu kleine Packages sind Packages mit einer oder zwei Klassen.

Beseitigung, indem die Klassen anderen Packages zugeschlagen werden.

Aber es sollen möglichst keine neuen Zyklen zwischen Packages entstehen.



Zu große Packages sind Packages mit sehr vielen Klassen.

Das Erlernen des Packages wird dadurch erschwert. Aufspaltung in mehrere Sub-Packages erleichtert das Erlernen.

Zu große Packages deuten auf fehlende Subsysteme hin.



Packages zu tief oder unausgewogen geschachtelt: schwerer zu verstehen als flache und ausgewogen geschachtelte.

Packages sind zu tief, wenn sie mehr als drei Ebenen benötigen.

Packages sind unausgewogen geschachtelt, wenn sie nicht in gleichen Ebenen sind.



Unklar benannte Packages deuten drauf hin, dass die Entwickler nicht wirklich verstanden haben, was sich in den Packages findet.

Unklar benannte Packages deuten darauf hin, dass die Packages-Struktur unzureichend im Projektteam kommuniziert ist.


Smells in Subsystemen(1)

Subsystemen fassen Packages zusammen, ähnlich wie das Packages für Klassen tun.

Sie unterscheiden zwischen interner Realisierung und öffentlicher Schnittstelle.

Ein großes System sollte in Subsysteme zerteilt sein. Das unterstützt:

Erlernbarkeit, Wartbarkeit, Multiprojektentwicklung, Deployment des Systems und Testbarkeit.


Smells in Subsystemen(2)In sehr großen Systemen kann das Subsystem rekursiv angewendet werden.

Je nach Terminologie heißen Subsysteme auch Komponenten, Plug-ins oder Teilsysteme.

Viele Programmiersprachen bieten keine Möglichkeit, Subsysteme zu definieren.

folglich muss mit Konventionen gearbeitet werden.


Smells Arten in Subsystemen(1)Keine Subsysteme, nur viele Packages.

Subsystem zu groß.

Subsystem zu klein.

Zu viele Subsysteme.

Subsystem-API wird umgangen.

Subsystem-API zu groß.

Zyklen zwischen Subsysteme.

Übergeneralisierung.


Smells Arten in Subsystemen(2)

Fehlende Subsysteme bei großem System.

Die Struktur des Systems ist auf Ebene von Packages definiert.

Es ist schwer, die Struktur der Packages zu definieren, zu erkennen und konsistent einzuhalten.


Smells Arten in Subsystemen(3)Subsysteme sind zu groß: Sie werden unverständlich und haben zu viel Verantwortung zu tragen.

Subsysteme sind zu klein: Sie verlagern Komplexität aus den Subsystem in die Abhängigkeiten der Subsysteme untereinander.

Zu viele Subsysteme in einem System beeinträchtigen erheblich das Systemverständnis.



Subsystem –API wird umgangen

Viele Programmiersprachen können keine Subsysteme definieren - Konventionen sind notwendig.

Die öffentliche Schnittstelle -das API- des Subsystems wird durch Konventionen definiert.

Solche Konventionen werden in einer Notlage oft umgangen.


Smells Arten in Subsystemen(5)Das Umgehen des Subsystem-API und der direkte Durchgriff auf die Komponenten sind ein häufiges Problem!

Beim direkten Zugriff vergrößern Klienten das Subsystem API, was zu weiteren Problemen führt.




Subsystem A

Subsystem C

Subsystem BInterne Klasse

Smells Arten in Subsystemen(7)Ist das Subsystem-API zu groß, wird der Hauptnutzen der Subsysteme nicht erreicht.

Ob ein Subsystem-API zu groß ist, hängt vom Verhältnis der Anzahl der Klassen im API und im gesamten Subsystem ab. Es gibt aber keine allgemeinen Richtwerte.




AC

ED

B

API Impl


Zyklen zwischen Subsystemen können über Benutzung oder Vererbung gebildet werden

Zyklen zwischen Subsystemen erschweren:Wiederverwendbarkeit.

Verständlichkeit.

Testbarkeit.

Entwurfsklarheit.

Parallele Entwicklung.


Smells Arten in Subsystemen(10)Subsysteme müssen flexibel (generalisiert) sein, doch Übergeneralisierung wird zum Problem (mehr Aufwand, schwierige Anwendung des Subsystem).

Indikator für Übergeneralisierungviel Code für die Parametrisierung/ Spezialisierung notwendig.


Smells in Schichten(1)Neben der Aufteilung eines großen Systems in Subsysteme hat sich das Anordnen der Subsysteme in Schichten bewährt.

Jede Schicht ist für einen bestimmten Aspekt des Systems zuständig.

Als Beispiel: 3-Schichten-Modell (3-tier-architecture), ISO-Modell…

Trennung Oberflächendefinition, Fachlogik und Datenhaltung voneinander (3-tier-architecture).


Smells in Schichten(2)Strikte Schichten: Jede Schicht darf nur auf die direkt unter ihr liegende Schicht zugreifen

Nicht strikte Schichten: Eine Schicht darf die unter ihr liegende Schicht hindurchgreifen und weiter unter liegende Schichten verwenden.

Bei protokollorientierten Schichten werden die Schnittstellen zwischen den Schichten durch Funktionen gebildet. Bei objektorientierten Schichten umfassen die Schnittstellen Interfaces und abstrakte Klassen.


Smells Arten in Schichten(1)

Keine Schichten.

Aufwärtsreferenzen zwischen Schichten (Zyklen).

Strikte Schichtung durchbrochen.

Zu viele Schichten.

Referenzen zwischen vertikal getrennten Schichten.


Smells Arten in Schichten(2)Ein System mit vielen Subsystemen ist ohne Schichten schwer bei Änderungsanforderungen zu ermitteln, welche Subsysteme betroffen sind.

Verwendet eine Schicht eine höher liegende Schicht, so wird das Grund Prinzip der Schichtung durchgebrochen.

Durch Aufwärtsreferenzen entstehen Zyklen zwischen Schichten.


Smells Arten in Schichten(3)Viele Programmiersprachen können keine Schichten definieren - Konventionen sind notwendig.

Strikte Schichtung Durchbrochen schwer zu verhindern.

Die Zahl der möglichen Klienten einer Schicht nimmt zu und die Abhängigkeiten zwischen den Schichten werden verstärkt.


Smells Arten in Schichten(4)Strikte protokollorientierte Schichten führen zu Indirektionen.

Wenn zu viele Schichten existieren, können so unnötige Indirektionen entstehen.

Es treten eine Reihen negativer Effekte auf:Es muss Aufwand in die Programmierung von Methoden ohne eigene Leistung investiert werden.

Das Programmverständnis wird erschwert.

Änderung sind nur mit hohem Aufwand durchführbar.


Smells Arten in Schichten(5)Schichten sind nicht nur horizontal, sondern auch vertikal geschnitten werden können.

Referenzen zwischen vertikal getrennten Schichten machen die Produkte voneinander abhängig.

Die Ziele von Produktlinien nicht mehr erreicht werden:

Auslieferung

Parallele Entwicklung


Smells Arten in Schichten(5)


S1Oberfläche

Fachlogik

Datenhaltung

Strikte Schichtung durchbrochen Verletzung des Subsystem-API

Aufwärtesreferenz ist illegal

Abhängigkeit innerhalb einer schicht Produkt1 Produkt2


Fragen ???

Seminar Softwaretechnik SS2005 Radouane El Marjani ( [email protected] ) Institut für...

Documents

Transcript of Seminar Softwaretechnik SS2005 Radouane El Marjani ( [email protected] ) Institut für...