Modularisierung

Seminar Softwareentwicklung

Programmierstil

Helmut Schmidauer

2/25

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/25

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/25

Was ist ein Modul ?

Eine Prozedur (eher nicht)

Eine Klasse

Ein Package

Eine Komponente

Ein Subsystem

5/25

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/25

Modulgeschlossenheit

Ein Modul soll für eine geschlossene Aufgabe zuständig sein

nach unterschiedlichen Aspekten

DatenorientiertFunktionsorientiert

FunktionsbibliothekAlgorithmus

7/25

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 verborgen

=> Abstrakte Datenstruktur

Ist ein wesentliches Entwurfsprinzip

8/25

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/25

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

Anzahl der Module

Kom

plex

ität

Gesamtkomplexität Modulkopplung

Modulbindung

10/25

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/25

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/25

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/25

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

VZ=2

IZ=3

14/25

Application Framework

Einbettung in Architektur

Steuermodule

Problemlösung

Hilfsmodule

Bibliotheken

Datenstrukturenhäufige

Operationen

spezielle Ein/Ausgabe

Benutzerkommunikation Eventloop

InitialisierungSteuerung

Problemorientiert

Problemorientiert

Problemorientiert

Problemorientiert

Problemorientiert

Problemorientiert

Problemorientiert

Problemorientiert

KommunikationBetriebssystem

math.Funktionen

Ein/AusgabeSystem

bibliotheken

15/25

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/25

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/25

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/25

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/25

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/25

Kategorien von Mustern

Erzeugungsmuster– Abstrakte Fabrik– Singleton

Strukturmuster– Adapter

Verhaltensmuster– Beobachter– Iterator

Danke für die Aufmerksamkeit