Modularisierung

1
Modularisierung

• Seminar Softwareentwicklung
• Programmierstil
• Helmut Schmidauer

2
Wozu Modularisierung von Software ?

• Verständlichkeit
• Jede Entwurfseinheit sollte weitgehend unabhängig
  von den anderen verständlich sein
• Kombinierbarkeit
• Entwurfseinheiten sollten sich durch
  Rekombination zu neuen Systemen zusammenfügen
  lassen
• Lokalität
• Jede Änderung des Entwurfsproblems sollte
  Änderungen in möglichst wenigen Entwurfseinheiten
  verursachen
• Parallele Entwicklung

3
Definition Modul

• Zusammenfassung von Operationen und Daten zur
  Realisierung einer in sich abgeschlossenen
  Aufgabe
• Kommunikation mit der Außenwelt nur über eine
  eindeutig spezifizierte Schnittstelle
• Keine Kenntnis des inneren Arbeitens zur
  Integration erforderlich
• Korrektheit nachprüfbar ohne Kenntnis seiner
  Einbettung

4
Was ist ein Modul ?

• Eine Prozedur (eher nicht)
• Eine Klasse
• Ein Package
• Eine Komponente
• Ein Subsystem

5
Modularisierung

• Zerlegung eines Systems in Module, unter
  Berücksichtigung folgender Kriterien
• Verhältnis Modulbindung - Modulkopplung
• Minimalität der Schnittstelle
• Modulgröße
• Testbarkeit
• Interferenzfreiheit
• Importzahl, Verwendungszahl
• Modulhierachie - Architektur

6
Modulgeschlossenheit

• Ein Modul soll für eine geschlossene Aufgabe
  zuständig sein
• nach unterschiedlichen Aspekten

7
Datenkapselung

• Trenne die konkrete Implementierung einer
  Datenstruktur von ihren sichtbaren Eigenschaften
• Datenstruktur wird in ein Modul eingekapselt
• Die Schnittstelle besteht aus Operationen die den
  Umgang mit der Datenstruktur beschreiben
• Die Datenstruktur selbst ist verborgengt
  Abstrakte Datenstruktur
• Ist ein wesentliches Entwurfsprinzip

8
Information Hiding

• "Geheime" Bereiche eines Systems
• Daten
• Bereiche die sich häufig ändern
• Hardwareabhängigkeiten
• Ein / Ausgabe
• Komplizierte Design und Implementierungsbereiche
• Konstanten
• Business Logik
• Komplexe Logik

9
Modulbindung - Modulkopplung

• Modulbindung
• Summe der Beziehungen zwischen den einzelnen
  Operationen,Daten eines Moduls (soll hoch sein)
• Modulkopplung
• Summe der Beziehungen zwischen den Modulen
• Hohe Kopplung durch verteilte Funktionen, globale
  Daten

10
Minimalität der Schnittstelle

• möglichst wenige (gar keine) globalen Daten
• Verlust der Kontrolle
• wenige exportierte Prozeduren
• Prozeduren des Moduls stark verbunden
• je mehr exportiert, desto eher falsche Verwendung
• geringe Anzahl von Parametern
• viele Parameter
• viele Variationen
• kopliziertere Verwendung

11
Testbarkeit

• Korrektheit nachprüfbar ohne Kenntnis seiner
  Einbettung in das Gesamtysytem
• hohe Bindung
• Testabdeckung wahrscheinlich höher
• minimale Schnittstelle
• weniger und einfachere Testfälle
• Stubs - Testrahmen
• Bottom-Up Entwicklung

12
Interferenzfreiheit

• keine Nebenwirkungen auf andere Module
• Nebenwirkungen
• modifiziert globale Daten
• modifizierende Operationen in anderen Modulen
• Kriterium für Änderbarkeit und Erweiterbarkeit
  des Gesamtsystems
• Interferenzfreies Modul kann durch Modul mit
  identischer Schnittstelle ersetzt werden
• nicht gegeben wenn
• Modul mehrere Aufgaben erfüllt
• Aufgabe auf mehrere Module verteilt ist

13
Importzahl, Verwendungszahl

• Importzahl
• Wie viele Module werden vom Modul verwendet
• wenn hoch
• deutet auf hohe Modulkopplung hin
• Interferenzen wahrscheinlich
• wenn niedrig
• möglicherweise zu großes Modul (immer erweitert)
• Verwendungszahl
• Von wie vielen Modulen wird das Modul verwendet
• wenn hoch
• sehr Allgemein / hohe Wiederverwendung
• Sammlung unzusammenhängender Funktionen ?
• es sollte auch eine starke Modulbindung herrschen

14
Einbettung in Architektur
Steuermodule
Problemlösung
Hilfsmodule
Bibliotheken
15
Entwurfstechniken

• Zwei Varianten der Abstraktion
• Top Down
• Dekomposition
• Zu Beginn Lösungsidee ohne Realisierungsdetails
• Schrittweise Konkretisierung
• Bottom Up
• Komposition
• Aus erforderlichen Basiselementen wird sukzessive
  das System zusammengestellt

16
Entwurfsprinzipien

• Kriterien nach denen abstrahiert wird
• Funktionsorientiert
• Die Aufgabe des Systems wird immer detaillierter
  in Teilaufgaben zerlegt
• Problematisch für Modularisierung,
  Wiederverwertbarkeit, Weiterentwicklung
• Objektorientiert
• Identifizierung von realen und abstrakten
  Objekten
• Beschreibung in Klassen
• Identifizierung von Methoden an den Objekten
• Erzeugen eines Systems aus den Objekten

17
Entwurfsmuster

• Bereitstellung bewährter, vorgefertigter Lösungen
  für wiederkehrende Entwurfsprobleme
• Schaffung einer Terminologie für die
  Kommunikation über solche Probleme
• Entwurf mit Mustern
• Grundschatz an Mustern kennen (Lernen /
  Erfahrung)
• Bei der Modularisierung Anwendungssituationen für
  Muster erkennen
• Wiederverwendung von Problemlösungen

18
Wie lösen Muster Entwurfsprobleme ?

• Objektfindung
• nicht so offensichtliche Abstraktionen finden
• Bestimmen der Objektgranularität
• Größe und Anzahl von Objekten
• Spezifizieren von Schnittstellen
• was soll, was soll nicht in eine Schnittstelle
• Spezifizieren von Objektimplementierungen
• Klassen vs. Schnittstellenvererbung
• Klassen
• Erweiterung der Funktionalität
• Wiederverwendung einer Implementierung
• Interfaces
• Reduzierung der Implementierungsabhängigkeit

19
Wie lösen Muster Entwurfsprobleme ?

• Prinzip des wiederverwendbaren objektorientierten
  Entwurfs
• "Programmiere auf eine Schnittstelle hin, nicht
  auf eine Implementierung"
• Wiederverwendungsmechanismen anwenden
• White Box Wiederverwendung
• Klassenvererbung
• BlackBox Wiederverw.
• Objektkomposition

20
Kategorien von Mustern

• Erzeugungsmuster
• Abstrakte Fabrik
• Singleton
• Strukturmuster
• Adapter
• Verhaltensmuster
• Beobachter
• Iterator

21
Danke für die Aufmerksamkeit