Seminar Softwareentwicklung Programmierstil Helmut Schmidauer Modularisierung Seminar Softwareentwicklung Programmierstil Helmut Schmidauer

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

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

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

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

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

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

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

Modulbindung - Modulkopplung 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 Komplexität Modulbindung Gesamtkomplexität Modulkopplung

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

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

Interferenzfreiheit keine Nebenwirkungen auf andere Module 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

Importzahl, Verwendungszahl 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 sehr Allgemein / hohe Wiederverwendung Sammlung unzusammenhängender Funktionen ? es sollte auch eine starke Modulbindung herrschen VZ=2 IZ=3

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

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

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

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

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

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

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

Danke für die Aufmerksamkeit