On the Criteria to Be Used in Decomposing Systems into Modules

Präsentation zum Thema: "On the Criteria to Be Used in Decomposing Systems into Modules"—  Präsentation transkript:

1 On the Criteria to Be Used in Decomposing Systems into Modules
Vortrag zum Seminar „Software-Architektur“ von Marco Eckstein (

2 Modularisierung SW-System wird in (idealerweise) unabhängige Module aufgeteilt. Modularisierung  Dekompostition Modularisierung erfolgt, bevor einzelne Module bearbeitet werden.

3 Modularisierung Vorteile:
Organisatorische: Mehrere Teams können unabhängig voneinander arbeiten.  kürzere Entwicklungszeit Flexibilität: Ein Modul kann geändert werden, ohne dass andere Module betroffen sind. Verständlichkeit: Einzelne Module können besser verstanden werden als große, monolithische SW.

4 Modularisierung Zentrale Frage: Was ist ein Modul?
Allgemein: Arbeitseinheit o.ä. Hier behandelte konkrete Möglichkeiten: Modul  Unterprogramm Modul  Klasse (1972 bei Parnas aber noch nicht Klasse genannt)

5 Modularisierung Was ist eine „gute“ Modularisierung?
Hier werden zwei sehr unterschiedliche Modularisierungen für ein SW-System vorgestellt. Vergleich von Vor- und Nachteilen Beispielsystem: System erstellt einen KWIC Index.

6 KWIC Index KWIC = KeyWord In Context
„Normaler“ Index (wie in den meisten Büchern) ohne Kontext KWIC Index wie normaler Index alphabetisch geordnet

7 KWIC Index Bsp. normaler Index
Back Empire Jedi Return Star Strikes The Wars of the zusätzlich zu den Wörtern üblicherweise noch Verweise auf Seiten (Interessiert uns hier nicht.) .

8 KWIC Index Bsp. KWIC Index „roh“ ausgegeben:
Back The Empire Strikes Empire Strikes Back The Jedi The Return of the Return of the Jedi The Star Wars Strikes Back The Empire The Empire Strikes Back The Return of the Jedi Wars Star of the Jedi The Return the Jedi The Return of Auch hier sind Verweise möglich. (Interessiert uns hier nicht.)

9 KWIC Index Bsp. KWIC Index „schön“ ausgegeben: The Empire Strikes Back
The Return of the Jedi Star Wars The Return of the Jedi The Return of the Jedi

10 KWIC Index Vorteile der Kontextinformation Bsp.:
normaler Index: The Seite 21, Seite 54 KWIC Index: The Empire Strikes Back Seite 21 The Return of the Jedi Seite 54

11 KWIC Index Für elektronische Dokumente eher überflüssig  Volltextsuche

12 KWIC Index Wie entsteht der KWIC Index? Eingabe: unsortierte Zeilen
Bsp.: The Empire Strikes Back Star Wars The Return of the Jedi

13 KWIC Index Dann: Erzeugung der „Circular Shifts“
Bsp.: The Empire Strikes Back Empire Strikes Back The Strikes Back The Empire usw.

14 KWIC Index Dabei ist die ursprüngliche Zeile selbst ein Circular Shift. Dann: Alphabetische Sortierung der Circular Shifts aller Zeilen. Dann: Ausgabe

15 Beispielarchitekturen
MainSubroutine-Architektur (Modul  Unterprogramm)  um 1972 übliche Modularisierung Objektorientierte Architektur (Modul  Klasse)  um 1972 unübliche Modularisierung Details sind im Folgenden nicht so wichtig.

16 1. MainSubroutine-Architektur
Abb.: TU Graz (siehe Literatur/ Links auf Folie 30)

17 1. MainSubroutine-Architektur
Abb.: TU Graz (siehe Literatur/ Links auf Folie 30)

18 1. MainSubroutine-Architektur
Abb.: TU Graz (siehe Literatur/ Links auf Folie 30)

19 2. Objektorientierte Architektur
Abb.: TU Graz (siehe Literatur/ Links auf Folie 30)

20 Vergleich der Beispielarchitekturen
Beide Architekturen funktionieren natürlich. Aber: Wie robust sind sie gegenüber Änderungen?

21 Vergleich der Beispielarchitekturen Änderung: Eingabe-Format
MainSubroutine-Architektur: Änderung eines Moduls Änderung des Eingabe-Formats Abb.: TU Graz (siehe Literatur/ Links auf Folie 30)

22 Vergleich der Beispielarchitekturen Änderung: Eingabe-Format
OO Architektur: ebenfalls Änderung eines Moduls Änderung des Eingabe-Formats Abb.: TU Graz (siehe Literatur/ Links auf Folie 30)

23 Vergleich der Beispielarchitekturen Änderung: Speicherung der Zeilen nicht mehr im Hauptspeicher
MainSubroutine-Architektur: Änderung von vier Modulen! Abb.: TU Graz (siehe Literatur/ Links auf Folie 30)

24 Vergleich der Beispielarchitekturen Änderung: Speicherung der Zeilen nicht mehr im Hauptspeicher
OO Architektur: Änderung eines Moduls! Die Informationen darüber, wie und wo die Zeilen gespeichert sind, werden versteckt.  Information Hiding Abb.: TU Graz (siehe Literatur/ Links auf Folie 30)

25 Vergleich der Beispielarchitekturen Änderung: Speicherung der Circular Shifts als Characters, statt nur einen Index dafür zu kreieren MainSubroutine-Architektur : Änderung von drei Modulen Abb.: TU Graz (siehe Literatur/ Links auf Folie 30)

26 Vergleich der Beispielarchitekturen Änderung: Speicherung der Circular Shifts als Characters, statt nur einen Index dafür zu kreieren OO Architektur : Änderung eines Moduls Abb.: TU Graz (siehe Literatur/ Links auf Folie 30)

27 Vergleich der Beispielarchitekturen
MainSubroutine-Architektur: Jedes Modul entspricht einem Schritt in der Abarbeitungsfolge. OO Architektur: Jedes Modul versteckt eine Entwurfsentscheidung vor den anderen. Die Schnittstelle ist möglichst abstrakt und gibt so wenig wie möglich über das Innenleben preis.

28 Schlussfolgerungen MainSubroutine-Architektur nur für sehr kleine Systeme! Vorgehen „Flussdiagramm  Modularisierung“ also meist ungeeignet OO Architektur meist besser Vorgehen: „Entwurfsentscheidungen zusammentragen  diese versteckende Module festlegen“

29 Literatur/ Links D.L. Parnas: On the Criteria to Be Used in Decomposing Systems into Modules (1972) Online unter:

30 Literatur/ Links Unterlagen zu einer Software-Architektur-Vorlesung (TU Graz, Österreich): Home: KWIC Implemented with... ... MainSubroutine Architectural Style: ... Object-Oriented Architectural Style: weitere Architectural Styles: .../assign/3/ usw. Von dort stammen viele Abbildungen in dieser Präsentation!