On the Criteria to Be Used in Decomposing Systems into Modules Vortrag zum Seminar „Software-Architektur“ 19.05.2004 von Marco Eckstein (E-Mail: eckstein@informatik.hu-berlin.de)

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

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.

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)

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.

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

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.) .

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.)

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

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

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

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

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

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

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.

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

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

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

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

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

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

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)

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)

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)

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)

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)

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.

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“

Literatur/ Links D.L. Parnas: On the Criteria to Be Used in Decomposing Systems into Modules (1972) Online unter: http://www.acm.org/classics/may96/

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