On the Criteria to be Used in Decomposing Systems into Modules

1. Michael Schneider On the Criteria to be Used in Decomposing Systems into Modules

2. Inhalt David L. Parnas als “Software Pioneer” ACM-Artikel von 1972 2.1. Verschiedene Arten von Modularisierungen 2.2. Information Hiding Ein Rückblick nach 30 Jahren 3.1. Verbesserung eines Industriebeispiels durch Information Hiding 3.2. Studie aus einem Programmierseminar 3.3. Heutige Techniken Fazit Quellen

3. 1. David L. Parnas als “Software Pioneer” • Am 10. Februar 1941 in Platsburgh, NY als David Lorge Parnas geboren • Ist Professor of Software Engineering und Ph.D. in electrical engineering • 1972 ACM Artikel zu Dekompositionsverfahren und Information Hiding • Entwickelte Modulkonzept, das Grundlage für OOP-Sprachen ist • Lehrte unter anderem auch an TH Darmstadt • Ist aktuell an der University of Limerick in Irland

4. 2. ACM-Artikel von 1972 • Titel: „On the Criteria to be Used in Decomposing Systems into Modules” • Artikel gilt als Grundidee für OOP-Sprachen • Dekompostionsverfahren helfen, Software zu Modularisieren und somit übersichtlicher zu gestalten • Softwareentwicklung in separaten Gruppen • Flexible Entwicklung • Verständlichkeit • Es gibt verschiedene Arten von Modularisierung, die unterschiedliche Ideen verfolgen, 2 Beispiele: • Modularisierung ohne Information Hiding • Modularisierung mit Information Hiding

5. 2.1. Verschiedene Arten von Modularisierungen • Modularisierung ohne Information Hiding • Hauptziel: Effizienz • 5 Module: • Modul 1 Input: • Liest Datenzeilen ein • Erzeugt aus ihnen Kernel-Array • 4 Zeichen = 1 Word • Erzeugt Index der Startadressen der Datenzeilen • Modul 2 Circular Shift: • Verwendet direkt Array von Modul 1 • erzeugt in Array Index aus erstem Zeichen des Circular Shift und Indexline • Array enthält Word-Paar => Zeilennummer + Startadresse

6. 2.1. Verschiedene Arten von Modularisierungen • Modularisierung ohne Information Hiding • 5 Module: • Modul 3 Alphabetizing: • Input = Arrays von Modul 1 und 2 • Erzeugt Array der Art von Modul 2 • Sortiert Circular Shifts alphabetisch • Modul 4 Output: • Verwendet direkt Arrays von Modul 1 und 3 • Erzeugt aufbereiteten Output der alphabetischen Circular Shifts • Outputlayout ist von den Shifts abhängig • Modul 5 Master Control: • Kontrolliert direkt über die Module den ordnungsgemäßen Ablauf

7. Modul 1 Daten 2.1. Verschiedene Arten von Modularisierungen • Modularisierung ohne Information Hiding Kern Modul 5 Modul 3 Modul 4 Modul2

8. 2.1. Verschiedene Arten von Modularisierungen • Modularisierung mit Information Hiding • Hauptziele: Übersichtlichkeit, Austauschbarkeit, gute Wartbarkeit • 6 Module, die ihre Funktionen über Interfaces anderen zur Verfügung stellen: • Modul 1 Line Storage: • Speichert die Daten • bietet Funktionsinterface zum Datenverarbeiten an • Funktionen: • CHAR(r, w, c) indiziert Zeichen in Words • SETCHAR(r,w,c,d) ersetzt Zeichen in Words • WORDS( r ) zählt Words je Zeile • DELINE bzw. DELWRD bieten Löschfunktionen an • Error Handling bei fehlerhaften Funktionsaufrufen

9. 2.1. Verschiedene Arten von Modularisierungen • Modularisierung mit Information Hiding • 6 Module, die ihre Funktionen über Interfaces anderen zur Verfügung stellen: • Modul 2 Input: • Liest Daten ein und gibt sie an Modul 1 zum Speichern • Modul 3 Circular Shift: • Erzeugt Index von Shifts je Datenzeile • Hauptfunktionen sind analog zu Modul 1 • 2 wichtige Funktionen: • CSSETUP bestimmt die Regeln des Shifts • CSCHAR(l,w,c) indiziert Character des Words je Shift • Shifts erfolgen Zeilenabhängig • Je Zeile: 1. Shift Original, 2. One-Word-Rotation

10. 2.1. Verschiedene Arten von Modularisierungen • Modularisierung mit Information Hiding • 6 Module, die ihre Funktionen über Interfaces anderen zur Verfügung stellen: • Modul 4 Alphabetizer: • Sortiert alphabetisch • 2 Hauptfunktionen: • ALPH sortiert • ITH(i) indiziert sortierte Circular Shifts • Modul 5 Output: • Erzeugt einen Output der aufbereiteten Daten • Modul 6 Master Control: • Kontrolliert den ordnungsgemäßen Ablauf der Module

11. 2.1. Verschiedene Arten von Modularisierungen • Modularisierung mit Information Hiding Modul1 Modul 2 Modul 3 Modul 4 Modul 5 Modul 6

12. 2.2. Information Hiding • Vorteile: • Unabhängigkeit der Module • Veränderbarkeit, da kein Modul direkt auf andere zugreift • Ersetzbarkeit, da nur die Schnittstellen konstant bleiben muss • Bessere Wartungsmöglichkeiten • Geringerer Aufwand, da: • Nur Interfacedesign muss abgeklärt werden • Nachteile: • Schnittstellen müssen zu Beginn eindeutig definiert werden und später auch zwingend eingehalten werden • Optimierung für einzelne Probleme nur im Rahmen der Schnittstellendefinition möglich

13. 3. Ein Rückblick nach 30 Jahren • Modularisierung als Standard etabliert • Information Hiding leider noch nicht • Altbewährte Vorgehensweisen verhindern Durchbruch • „Never Change A Running System.“ • Parnas hat Studien in Industrie und Seminaren durchgeführt • Information Hiding scheitert meist am Aufwand vor der Umsetzung, nicht an seiner Idee

14. 3.1. Verbesserung eines Industriebeispiels • Programmierer sollen Projekt entwickeln und planen die Umsetzung in Modulen: Es entsteht eine Modulstruktur ohne Information Hiding

15. 3.1. Verbesserung eines Industriebeispiels • Probleme hierbei sind: • Module werden als Ganzes betrachtet • Planung des Gesamtproduktes geht in jedes Detail • Änderungen an einzelnen Punkten müssen immer an alle weitergegeben werden • Änderungen an einzelnen Modulen können unerwartete Auswirkungen auf andere Module haben • Wartbarkeit wird im Vergleich zur Effizienz vernachlässigt • Übersichtlichkeit geht verloren

16. 3.1. Verbesserung eines Industriebeispiels • Besser wäre eine Lösung mittels Information Hiding gewesen: Feste, vordefinierte Schnittstellen erzeugen unabhängige, leicht wartbare Module. INTERFACE

17. 3.1. Verbesserung eines Industriebeispiels • Verbesserungen durch Information Hiding wären: • Übersichtlichkeit • Leichtere Wartung • Unabhängigkeit der Module • Nutzbarkeit einzelner Module für spätere Projekte

18. 3.2. Studie aus einem Programmierseminar • Aufgabenstellung: • 5 Module müssen umgesetzt werden • Je Modul gibt es 5 Möglichkeiten, dies zu tun • Alle Kombinationen sollen funktionieren • Modularisierung soll mittels Information Hiding umgesetzt werden • Hintergrund: • Industriestudien bezüglich Information Hiding • Testen, wie Forschung Etablierung vorantreiben kann • Schnittstellenumsetzung, ohne direkten Austausch versuchen • Erkennen, wo Umsetzungsprobleme sind

19. 3.3. Heutige Techniken • Abstrakte Datentypen • Verwirklichung von Information Hiding • Leider noch zu selten verwendet • Objektorientierte Sprachen • Größtenteils mit Information Hiding • Unterschiedliche Designs der Sprachen erzwingen Kompormisse • Irrglaube: Programmieren in objektorientierter Sprache = objektorientiertes Programmieren • Overhead durch geladene Module, die nicht verwendet werden • Komponentenorientiertes Design • Noch nicht ausreichend verwirklicht

20. 4. Fazit • Modularisierung ist wichtiger Bestandteil heutiger Softwareentwicklung • Information Hiding ist eine sinnvolle Entwicklung • Leider noch nicht etabliert, weil: • Schnittstellen werden unterschätzt • Klassische Strukturen bestimmen Entwicklerdenken • Vorhandene Schnittstellen sind oft nicht ausgereift • Effizienz wird höher als Wartbarkeit eingeschätzt • „Never Change A Running System“ ist noch immer ein Leitspruch der Industrie • Neues Designen von Programmen erfordert Anpassungsfähigkeit und Zeit

21. ∞ Ende Vielen Dank für Ihre Aufmerksamkeit