1

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)

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

BackEmpireJediReturnStarStrikesTheWarsofthe

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 Empire Strikes Back The Return of the Jedi The Return of the Jedi Star Wars The Empire Strikes Back 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

1. MainSubroutine-Architektur(Modul Unterprogramm) um 1972 übliche Modularisierung

2. 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 des Eingabe-Formats

Änderung eines Moduls

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

22

Vergleich der Beispielarchitekturen Änderung: Eingabe-Format

• OO Architektur:

Änderung des Eingabe-Formats

ebenfalls Änderung eines Moduls

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 besserVorgehen: „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: http://www.acm.org/classics/may96/

30

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!