Software-Engineering

Größe: px

Ab Seite anzeigen:

Download "Software-Engineering"

Lorenz Pohl
vor 8 Jahren
Abrufe

1 SWE5 Slide 1 Software-Engineering Sebastian Iwanowski FH Wedel Kapitel 5: Systementwurf

2 SWE5 Slide 2 Systemanalyse vs. Softwareentwurf Systemanalyse beschreibt das System der Anwendung, für das eine Aufgabe gelöst werden soll Modellierung orientiert sich an der Realität Softwareentwurf beschreibt den Aufbau der Software, mit der die Aufgabe gelöst werden soll Modellierung orientiert sich an den technischen Möglichkeiten Die Modellierungshilfsmittel sind dieselben: Abstraktion, verschiedene Sichten, hierarchische und modulare Zerlegung dieselben formalen Hilfsmittel: ERM, UML,...

orientiert sich an der Realität Softwareentwurf beschreibt den Aufbau der Software, mit der die Aufgabe gelöst werden soll

3 SWE5 Slide 3 Softwareentwurf: Allgemeine Prinzipien Entwurfsrichtung 1) Top-Down vom Allgemeinen zum Konkreten 2) Bottom-Up Vom Konkreten zum Allgemeinen Lösung für den Benutzer Top-Down Bottom-up Basisaufgaben

Konkreten 2) Bottom-Up Vom Konkreten zum Allgemeinen

4 SWE5 Slide 4 Vorgabe: Softwareentwurf: Top-Down Abstrakte Zielvorgabe für die Funktionalität des Systems Vorgehensweise: Zerlegung der Zielvorgabe in Teilaufgaben und Konkretisierung Vorteile Lösung steht im Mittelpunkt der Systementwicklung. Vollständige, exakte Spezifikationen führen genau zum gewünschten Ergebnis. Die Gesamtübersicht erleichtert die Bildung geeigneter Abstraktionsebenen und führt zu einer guten Systemstruktur.

5 SWE5 Slide 5 Vorgabe: Softwareentwurf: Top-Down Abstrakte Zielvorgabe für die Funktionalität des Systems Vorgehensweise: Zerlegung der Zielvorgabe in Teilaufgaben und Konkretisierung Nachteile Gute Fähigkeiten zum abstrakten Denken erforderlich. Realisierungsprobleme werden erst spät erkannt. Die Wiederverwendung vorhandener Teillösungen wird erschwert.

Konkretisierung Nachteile Gute Fähigkeiten zum abstrakten Denken erforderlich.

6 SWE5 Slide 6 Vorgabe: Softwareentwurf: Bottom-Up Konkrete Bausteine für die Basislösung mit bekannter Funktionalität Vorgehensweise: Zusammensetzung dieser Bausteine zu größeren Einheiten Vorteile: Realistischer Lösungsansatz durch sicheren Ausgangspunkt Suche nach vorhandenen Teillösungen wird begünstigt.

dieser Bausteine zu größeren Einheiten Vorteile: Realistischer Lösungsansatz

7 SWE5 Slide 7 Vorgabe: Softwareentwurf: Bottom-Up Konkrete Bausteine für die Basislösung mit bekannter Funktionalität Vorgehensweise: Zusammensetzung dieser Bausteine zu größeren Einheiten Nachteile: Schwierigkeiten, das Ziel im Auge zu behalten (und zu erreichen) Gefahr der Entwicklung von später nicht benötigten Softwarekomponenten auf unteren Ebenen des SW-Systems

Einheiten Nachteile: Schwierigkeiten, das Ziel im Auge zu behalten (und zu erreichen)

8 SWE5 Slide 8 Vorgabe: Softwareentwurf: Jo-Jo-Methode Konkrete Bausteine für die Basislösung mit bekannter Funktionalität Zielvorgabe für das gesamte System Vorgehensweise: Zerlegung der Zielvorgabe in Teilaufgaben und Konkretisierung mit Hilfe der Bausteine für die Basislösung Vorteile Bestmöglicher Kompromiss zwischen Wünschenswertem und Machbarem Erstellen einer möglichst ökonomischen Lösung Anforderungen an das Abstraktionsvermögen reduziert

Konkretisierung mit Hilfe der Bausteine für die Basislösung Vorteile Bestmöglicher Kompromiss zwischen

9 SWE5 Slide 9 Vorgabe: Softwareentwurf: Jo-Jo-Methode Konkrete Bausteine für die Basislösung mit bekannter Funktionalität Zielvorgabe für das gesamte System Vorgehensweise: Zerlegung der Zielvorgabe in Teilaufgaben und Konkretisierung mit Hilfe der Bausteine für die Basislösung Nachteile Wechsel der Bearbeitungsrichtung willkürlich, daher Gefahr mangelnder Systematik

der Zielvorgabe in Teilaufgaben und Konkretisierung mit Hilfe der Bausteine für die

10 SWE5 Slide 10 Softwareentwurf: Modularisierung Entwurfsebene 1: Softwaremodul bottom-up top-down Entwurfsebene 2:

11 SWE5 Slide 11 Softwareentwurf: Modularisierung Der Begriff des Moduls (nach Goos / Dennis 1973): Ein Modul ist die Zusammenfassung von Operationen und Daten zur Realisierung einer in sich geschlossenen Aufgabe. Die Kommunikation eines Moduls mit der Außenwelt darf nur über eine eindeutig spezifizierte Schnittstelle erfolgen. Zur Integration eines Moduls in ein Programmsystem muss die Kenntnis des inneren Aufbaus entbehrlich sein. Zum Nachweis der Korrektheit eines Moduls muss die Kenntnis der Einbettung des Moduls in das Softwaresystem entbehrlich sein.

Die Kommunikation eines Moduls mit der Außenwelt darf nur über eine eindeutig spezifizierte Schnittstelle erfolgen.

12 SWE5 Slide 12 Leitlinien für die Modularisierung Die Aspekte bei der Modularisierung: Modulbindung Modulkopplung Schnittstellen Modulgröße Interferenzeigenschaften Importzahl Verwendungszahl

13 SWE5 Slide 13 Leitlinien für die Modularisierung Modulbindung Grad des Zusammenhangs zwischen den einzelnen Daten und Operationen desselben Moduls eng lose Modulkopplung Grad des Zusammenhangs zwischen verschiedenen Modulen eng lose Schnittstellen Datenaustauschstellen zwischen Modul und dem umgebenden System viele wenige

lose Modulkopplung Grad des Zusammenhangs zwischen verschiedenen Modulen eng

14 SWE5 Slide 14 Leitlinien für die Modularisierung Modulgröße Anzahl der verwendeten Daten bzw. Operationen in einem Modul groß klein Interferenzeigenschaften Grad der Beeinflussung anderer Module durch Seiteneffekte hoch niedrig Importzahl Anzahl der in diesem Modul verwendeten Module viele wenige Verwendungszahl Anzahl der Module, die diesen Modul verwenden viele wenige

anderer Module durch Seiteneffekte hoch niedrig Importzahl Anzahl der in diesem Modul

15 SWE5 Slide 15 Leitlinien für die Modularisierung Folgende Kompromisse sollten geschlossen werden: Ausgewogenes Verhältnis zwischen Modulbindung und Modulkopplung Minimale Schnittstellen (Ausnahme: wenn sonst das Modul zu groß wird) Modulgröße maximal so groß, dass eine Person das Modul in einem überschaubaren Zeitraum bearbeitet Mittlere Import- und Verwendungszahlen

Schnittstellen (Ausnahme: wenn sonst das Modul zu groß wird) Modulgröße maximal so groß,

16 SWE5 Slide Bsp. für eine Modulart: Bibliotheksmodule Bereitstellung einer Sammlung von Algorithmen / Funktionalitäten zu einem Aufgabenbereich Besonderheiten: Umfangreiche Schnittstelle (eine Ausnahme zu den Leitlinien) Kein interner Zustand (Modul erfüllt keine Gesamtfunktionalität) Beispiele: Module mit mathematischen Funktionen Module für Hilfsfunktionen, die nicht problemspezifisch sind (z.b. Modul Util mit Umwandlungsfunktionen, Datumsfunktionen, etc.)

Aufgabenbereich Besonderheiten: Umfangreiche Schnittstelle (eine Ausnahme zu den Leitlinien) Kein interner Zustand

17 SWE5 Slide 17 Zweck: 2. Bsp. für eine Modulart: Datenkapselung Verhinderung des direkten Zugriffs auf Daten von anderen Programmteilen aus Aufbau: Die Datenkapsel besteht aus abstrakten Datenstrukturen/-typen und zugehörigen Zugriffsfunktionen. Abstrakt heißt: Der konkrete Aufbau der Datenstrukturen/-typen ist außerhalb des Moduls unbekannt. Bsp.: Wörterbuchproblem (Dictionary) Abstrakter Datentyp: Zugriffsfunktionen: Dictionary getdictionary() insert(dict, key, value) delete(dict, key) search(dict, key)

Datenkapsel besteht aus abstrakten Datenstrukturen/-typen und zugehörigen Zugriffsfunktionen.

18 SWE5 Slide 18 Softwareentwurf hier noch nicht angesprochen: Entwurfsmuster für die Programmierung Thema der Vorlesung Software-Design Entwurf von Bedienungsoberflächen Thema der Vorlesungen Software-Ergonomie / Medienkonzeption

Thema der Vorlesung Software-Design Entwurf von

19 SWE5 Slide 19 Verwendung von CASE-Tools Reine UML-Tools: ARIS: Eher für Softwareentwurf geeignet Eher für Systemanalyse geeignet Was ist vorzuziehen, wenn beides erledigt werden soll? Für den nahtlosen Übergang von Systemanalyse zu Softwareentwurf ist ein einheitliches CASE-Tool von Vorteil Wähle das CASE-Tool, das besser geeignet ist für die schwierigere Aufgabe und nicht vergessen: Kundenwünsche haben Vorrang!

Für den nahtlosen Übergang von Systemanalyse zu Softwareentwurf ist ein einheitliches CASE-Tool von

Ähnliche Dokumente

SWE5 Slide 1. Software-Engineering. Vorlesung 5 vom 15.11.2004 Sebastian Iwanowski FH Wedel

SWE5 Slide 1. Software-Engineering. Vorlesung 5 vom 15.11.2004 Sebastian Iwanowski FH Wedel SWE5 Slide 1 Software-Engineering Vorlesung 5 vom 15.11.2004 Sebastian Iwanowski FH Wedel SWE5 Slide 2 Software-Engineering Vorlesungsthemen: 1. Überblick über das Thema und die Vorlesung 2. Grundlegende