Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Modularisierung Seminar Softwareentwicklung Programmierstil Helmut Schmidauer.

Ähnliche Präsentationen


Präsentation zum Thema: "Modularisierung Seminar Softwareentwicklung Programmierstil Helmut Schmidauer."—  Präsentation transkript:

1 Modularisierung Seminar Softwareentwicklung Programmierstil Helmut Schmidauer

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

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

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

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

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

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

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

9 9/25 Modulbindung - Modulkopplung n Modulbindung –Summe der Beziehungen zwischen den einzelnen Operationen,Daten eines Moduls(soll hoch sein) n Modulkopplung –Summe der Beziehungen zwischen den Modulen –Hohe Kopplung durch verteilte Funktionen, globale Daten Anzahl der Module Komplexität Gesamtkomplexität Modulkopplung Modulbindung

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

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

12 12/25 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 n Interferenzfreies Modul kann durch Modul mit identischer Schnittstelle ersetzt werden n nicht gegeben wenn: –Modul mehrere Aufgaben erfüllt –Aufgabe auf mehrere Module verteilt ist

13 13/25 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) n 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 14/25 Application Framework Einbettung in Architektur Steuermodule Problemlösung Hilfsmodule Bibliotheken Datenstrukturen häufige Operationen spezielle Ein/Ausgabe Benutzer kommunikation Eventloop InitialisierungSteuerung Problem orientiert Problem orientiert Problem orientiert Problem orientiert Problem orientiert Problem orientiert Problem orientiert Problem orientiert Kommunikation Betriebssystem math. Funktionen Ein/Ausgabe System bibliotheken

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

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

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

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

19 19/25 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 –BlackBox Wiederverw. Objektkomposition

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

21 Danke für die Aufmerksamkeit


Herunterladen ppt "Modularisierung Seminar Softwareentwicklung Programmierstil Helmut Schmidauer."

Ähnliche Präsentationen


Google-Anzeigen