Modularisierung Seminar Softwareentwicklung Programmierstil Helmut Schmidauer Wozu Modularisierung

Modularisierung Seminar Softwareentwicklung Programmierstil Helmut Schmidauer

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

Definition Modul n n 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 3

Was ist ein Modul ? n Eine Prozedur n Eine Klasse n Ein Package n Eine Komponente n Ein Subsystem (eher nicht) 4

Modularisierung n 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 5

Modulgeschlossenheit n n Ein Modul soll für eine geschlossene Aufgabe zuständig sein nach unterschiedlichen Aspekten Funktionsorientiert Datenorientiert Funktionsbibliothek Algorithmus 6

Datenkapselung n Trenne die konkrete Implementierung einer Datenstruktur von ihren sichtbaren Eigenschaften n Datenstruktur wird in ein Modul eingekapselt Die Schnittstelle besteht aus Operationen die den Umgang mit der Datenstruktur beschreiben Die Datenstruktur selbst ist verborgen n n => Abstrakte Datenstruktur n Ist ein wesentliches Entwurfsprinzip 7

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

Modulbindung Modulkopplung n 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 Komplexität n Gesamtkomplexität Modulkopplung Modulbindung Anzahl der Module 9

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

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

Interferenzfreiheit n keine Nebenwirkungen auf andere Module – Nebenwirkungen: • modifiziert globale Daten • modifizierende Operationen in anderen Modulen n 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 12

Importzahl, Verwendungszahl n 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) VZ=2 n IZ=3 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 13

Einbettung in Architektur Application Framework Steuermodule Benutzer kommunikation Steuerung Problem orientiert Problemlösung Hilfsmodule Bibliotheken Problem orientiert Datenstrukturen System bibliotheken Eventloop Problem orientiert häufige Operationen math. Funktionen Initialisierung Kommunikation Betriebssystem Problem orientiert spezielle Ein/Ausgabe 14

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

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

Entwurfsmuster n n n 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 n Wiederverwendung von Problemlösungen 17

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

Wie lösen Muster Entwurfsprobleme ? n Prinzip des wiederverwendbaren objektorientierten Entwurfs: "Programmiere auf eine Schnittstelle hin, nicht auf eine Implementierung" n Wiederverwendungsmechanismen anwenden – White Box Wiederverwendung • Klassenvererbung – Black. Box Wiederverw. • Objektkomposition 19

Kategorien von Mustern n Erzeugungsmuster – Abstrakte Fabrik – Singleton n Strukturmuster – Adapter n Verhaltensmuster – Beobachter – Iterator 20

Danke für die Aufmerksamkeit