1 / 30

On the Criteria to Be Used in Decomposing Systems into Modules

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.

nhu
Download Presentation

On the Criteria to Be Used in Decomposing Systems into Modules

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  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 ofthe 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. Änderung eines Moduls Änderung des Eingabe-Formats Vergleich der Beispielarchitekturen Änderung: Eingabe-Format • MainSubroutine-Architektur: Abb.: TU Graz (siehe Literatur/ Links auf Folie 30)

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

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

  24. Änderung eines Moduls! Vergleich der Beispielarchitekturen Änderung: Speicherung der Zeilen nicht mehr im Hauptspeicher • OO Architektur: 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. Änderung von drei Modulen Vergleich der Beispielarchitekturen Änderung: Speicherung der Circular Shifts als Characters, statt nur einen Index dafür zu kreieren • MainSubroutine-Architektur : Abb.: TU Graz (siehe Literatur/ Links auf Folie 30)

  26. Änderung eines Moduls Vergleich der Beispielarchitekturen Änderung: Speicherung der Circular Shifts als Characters, statt nur einen Index dafür zu kreieren • OO Architektur : 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!

More Related