swt kap6 softwareentwurf
DESCRIPTION
TRANSCRIPT
Softwaretechnik
Vorlesung
Prof. Dr. Bernhard Rumpe
Lehrstuhl für Software Engineering
RWTH Aachen
http://www.se-rwth.de/
6. Software- und
Systementwurf
Farbe!
6. Software- & Systementwurf 6.1. Entwurfsprinzipien
Prof. Dr. Bernhard Rumpe
Lehrstuhl für Software Engineering
RWTH Aachen
http://www.se-rwth.de/
Literatur:
• Sommerville 10
• Balzert Band I LE 23
• Balzert Band II LE 17
Analyse Entwurf Implemen-tierung
Test,Integration
Wartung
Grobentwurf Feinentwurf
Prof. Dr. B. Rumpe
Lehrstuhl für
Software Engineering
RWTH Aachen
Seite 3
Software-Entwurf
Ausgangspunkt:
• Anforderungsspezifikation (Pflichtenheft) und
• Funktionale Spezifikation (Produktdefinition)
Ziel:
• Vom “WAS" zum “WIE": Vorgabe für Implementierung
Zentrale Begriffe:
• Subsystem
• in sich geschlossen
• eigenständig funktionsfähig mit definierten Schnittstellen
• besteht aus Komponenten
• Komponente
• Baustein für ein Softwaresystem (z.B. Modul, Klasse, Paket)
• benutzt andere Komponenten
• wird von anderen Komponenten benutzt
• kann auch aus Unterkomponenten bestehen
Prof. Dr. B. Rumpe
Lehrstuhl für
Software Engineering
RWTH Aachen
Seite 4
Gliederung des Entwurfsprozesses
Architekturentwurf
Subsystem-Spezifikation
Schnittstellen-Spezifikation
Komponentenentwurf
Datenstrukturentwurf
Algorithmenentwurf
Grobentwurf:
• weitgehend unabhängig von Implementierungssprache
Feinentwurf
• angepasst an die Implementierungssprache und Plattform
Gesamtstrukturdes Systems(Grobentwurf)
Detailstrukturdes Systems(Feinentwurf)
Prof. Dr. B. Rumpe
Lehrstuhl für
Software Engineering
RWTH Aachen
Seite 5
Arbeitsteilung beim Entwurf
Architekturentwurf
EntwurfSubsystem 1
EntwurfSubsystem 2
EntwurfSubsystem ...
Entwurf der Komponenten
EntwurfSchnittstelle
12
EntwurfSchnittstelle
2...
Prof. Dr. B. Rumpe
Lehrstuhl für
Software Engineering
RWTH Aachen
Seite 6
Kriterien für "guten" Entwurf
Korrektheit
• Erfüllung der Anforderungen
• Wiedergabe aller Funktionen des Systemmodells
• Sicherstellung der nichtfunktionalen Anforderungen
Verständlichkeit & Präzision
• Gute Dokumentation
Anpassbarkeit
Hohe Kohäsion innerhalb der Komponenten
Schwache Kopplung zwischen den Komponenten
Wiederverwendung
Diese Kriterien gelten auf allen Ebenen des Entwurfs (Architektur,
Subsysteme, Komponenten)
Prof. Dr. B. Rumpe
Lehrstuhl für
Software Engineering
RWTH Aachen
Seite 7
Kohäsion
Kohäsion ist ein Maß für die Zusammengehörigkeit der Bestandteile
einer Komponente.
Hohe Kohäsion einer Komponente erleichtert Verständnis, Wartung
und Anpassung.
Frühere Ansätze zur Kohäsion wie:
• ähnliche Funktionalitäten zusammenfassen
• führten nicht unbedingt zu stabiler Systemstruktur
Bessere Kohäsion wird erreicht durch:
• Prinzipien der Objektorientierung (Datenkapselung)
• Einhaltung von Regeln zur Paketbildung
• Verwendung geeigneter Muster zu Kopplung und Entkopplung
• "Kohärente" Klasse:
• Es gibt keine Partitionierung in Untergruppen von
zusammengehörigen Operationen und Attributen
Prof. Dr. B. Rumpe
Lehrstuhl für
Software Engineering
RWTH Aachen
Seite 8
Kopplung
Kopplung ist ein Maß für die Abhängigkeiten zwischen Komponenten.
Geringe Kopplung erleichtert die Wartbarkeit und macht Systeme
stabiler.
Arten der Kopplung:
• Datenkopplung (gemeinsame Daten)
• Schnittstellenkopplung (gegenseitiger Aufruf)
• Strukturkopplung (gemeinsame Strukturelemente)
Reduktion der Kopplung:
• Kopplung kann nie auf Null reduziert werden!
• Schnittstellenkopplung ist akzeptabel, da höhere Flexibilität
• Datenkopplung vermeiden!
• aber durch Objektorientierung meist gegeben
• Strukturkopplung vermeiden !
• z.B. keine Vererbung über Paketgrenzen hinweg
Entkopplungsbeispiel: get/set-Methoden statt Attributzugriff
Prof. Dr. B. Rumpe
Lehrstuhl für
Software Engineering
RWTH Aachen
Seite 9
Interne Wiederverwendung
Interne Wiederverwendung (reuse) ist ein Maß für die Ausnutzung
von Gemeinsamkeiten zwischen Komponenten
Reduktion der Redundanz
Erhöhung der Stabilität und Ergonomie
Hilfsmittel für Wiederverwendung:
• im objektorientierten Entwurf: Vererbung, Parametrisierung
• im modularen und objektorientierten Entwurf:
Module/Objekte mit allgemeinen Schnittstellen (Interfaces)
Aber: Wiederverwendung kann die Kopplung erhöhen:
• Schnittstellenkopplung und Strukturkopplung
Prof. Dr. B. Rumpe
Lehrstuhl für
Software Engineering
RWTH Aachen
Seite 10
Framework
Framework
• Eine Software, die durch Callback-Methoden erweiterbar ist
• Aufrufe finden in entgegengesetzter Richtung statt:
• das genutzte Framework ruft die eigentliche Applikation auf
Applikation
Bibliothek Framework
Prof. Dr. B. Rumpe
Lehrstuhl für
Software Engineering
RWTH Aachen
Seite 11
Referenzmodelle und -architekturen
Referenzmodell (für die Analyse)
• Logische Aufteilung der Systeme einer Domäne in
• Subsysteme
• Verbindungen
• Kommunikationskanäle zwischen diesen Subsystemen
Referenzarchitektur (für die Architektur/Entwurfsphase)
• Abbildung eines Referenzmodells auf Softwarekomponenten
• Datenfluss, Kommunikation
• Technische Aspekte werden hinzugefügt
• Detaillierter als Referenzmodelle
• Gruppierung der logischen Elemente auf Softwarekomponenten
ist *-zu-*
• Meistens realisieren mehrere Softwarekomponenten ein logisches
Subsystem
• Logische Elemente können mehrfach repliziert sein
6. Software- & Systementwurf 6.2. Softwarearchitektur
Prof. Dr. Bernhard Rumpe
Lehrstuhl für Software Engineering
RWTH Aachen
http://www.se-rwth.de/
Literatur:
• Sommerville 10
• Balzert LE 23
• Shaw/Garlan: Software Architecture, 1996
• Bass/Clements/Kazman: Software Architecture
in Practice, Addison-Wesley 1998
• P. Kruchten, The 4+1 view model of
architecture, IEEE Software, Nov. 1995, 12(6)
Analyse Entwurf Implemen-tierung
Test,Integration
Wartung
Grobentwurf Feinentwurf
Prof. Dr. B. Rumpe
Lehrstuhl für
Software Engineering
RWTH Aachen
Seite 13
Entwurf
Von der Analyse zum Entwurf
Analyse
Anforderungs-Ermittlung
Anforderungs-Spezifikation(Pflichtenheft)
FunktionaleSpezifikation
(Produktdefinition)
System-Modellierung Architektur-
Spezifikation
Architektur-Entwurf
Klassen- bzw. Modul-Spezifikationen
Detail-Entwurf
Prof. Dr. B. Rumpe
Lehrstuhl für
Software Engineering
RWTH Aachen
Seite 14
Was ist Architektur?
„[Architektur ist] Harmonie und Einklang aller Teile, die so erreicht
wird, dass nichts weggenommen, zugefügt oder verändert werden
könnte, ohne das Ganze zu zerstören.“
[Leon Battista Alberti]
Prof. Dr. B. Rumpe
Lehrstuhl für
Software Engineering
RWTH Aachen
Seite 15
Softwarearchitektur: Definitionen aus der Literatur
“The software architecture of a program or computing system is the
structure or structures of the system, which comprise software
elements, the externally visible properties of those elements, and
the relationships among them.“
[BCK03]
“Architecture is defined by the recommended practice as the
fundamental organization of a system, embodied in its components,
their relationships to each other and the environment, and the
principles governing its design and evolution.”
[IIEE Std. 1471-2000]
Prof. Dr. B. Rumpe
Lehrstuhl für
Software Engineering
RWTH Aachen
Seite 16
Softwarearchitektur: Unsere Sicht
Softwarearchitektur beschreibt die Struktur eines Systems.
Diese Beschreibung beinhaltet
• die Komponenten,
• deren Schnittstellen
• und deren Beziehungen
Sie beschreibt die wichtigsten strukturellen Eigenschaften eines
Systems präzise, ist gleichzeitig aber kompakt.
Sie beinhaltet die essentiellen Eigenschaften eines Systems, die
sich auf Gesamtsystemsicht beschreiben und analysieren lassen
Prof. Dr. B. Rumpe
Lehrstuhl für
Software Engineering
RWTH Aachen
Seite 17
Stakeholder
Ein System wird von vielen Faktoren beeinflusst
• Kunden
• Endnutzer
• Entwickler
• Projektmanager
• Wartungspersonal (Konfiguration, Weiterentwicklung)
• Vermarktung/Verkauf
• …
Diese werden als Stakeholder bezeichnet:
Am Projekt direkt oder indirekt beteiligten Personengruppen
Prof. Dr. B. Rumpe
Lehrstuhl für
Software Engineering
RWTH Aachen
Seite 18
Einfluss der Stakeholder auf die Softwarearchitektur
Management
Entwicklungsteam
Niedrige Kosten,
Programmierer
gleichmäßig
auslasten
KundeNiedrige Kosten,
schnelle
Auslieferung, kaum
Nachbesserungen
Software-
architekt
Wartungsteam
Modifizierbarkeit
Erweiterbarkeit
Performance,
Sicherheit,Verlässlich-
keit, Nutzbarkeit
Time to Market, Features,
Abgrenzung zu Konkurrenz-
produkten,
Kundenspezifische
Anpassbarkeit
MarketingNutzer
Abbildung [BCK03] nachempfunden
??
Prof. Dr. B. Rumpe
Lehrstuhl für
Software Engineering
RWTH Aachen
Seite 19
Nutzen einer Architekturbeschreibung (1/2)
Kommunikation der Stakeholder
• gemeinsame Sprache
• Abstraktion macht überhaupt Kommunikation möglich
• Schulung der Entwickler
Wesentliche Entwurfsentscheidungen
• Beschränkung der Implementierungsmöglichkeiten
• Legt Organisationsstruktur fest
• Verhindert oder erlaubt bestimmte Stufen für Qualitätsattribute
• Erlaubt das Urteilen über und Verwalten von Veränderungen
• Zeit und Kostenschätzung
Prof. Dr. B. Rumpe
Lehrstuhl für
Software Engineering
RWTH Aachen
Seite 20
Nutzen einer Architekturbeschreibung (2/2)
Wiederverwendbare Abstraktion des Systems
• Produktlinien haben gemeinsame Architektur
• Wiederverwendung von Komponenten
• Wiederverwendung von erprobten Designs
Fokus auf spezifische Systemeigenschaften möglich
• Getrennte Betrachtung der Aspekte
• Trennung der Zuständigkeiten
• Übersichtlichkeit
Frühzeitige Analysemöglichkeiten
• Prototypen
• Risikoabschätzung
• Zeit- und Kostenschätzung
• Vorhersage von Eigenschaften des Systems
Prof. Dr. B. Rumpe
Lehrstuhl für
Software Engineering
RWTH Aachen
Seite 21
Architektur-Beispiel
Physikalische Architekturen
Networked
Architecture
Stand-alone
Architecture
Prof. Dr. B. Rumpe
Lehrstuhl für
Software Engineering
RWTH Aachen
Seite 22
Architektur-Beispiel
Physikalische Architekturen:
• Client
• Firewall
• Application Servers
• Data
Prof. Dr. B. Rumpe
Lehrstuhl für
Software Engineering
RWTH Aachen
Seite 23
Architektur-Beispiel
Schichten Architektur der Software (innerhalb eines Systems):
Prof. Dr. B. Rumpe
Lehrstuhl für
Software Engineering
RWTH Aachen
Seite 24
Architektur-Beispiel
Kommunikationsarchitektur eines
Software-Intensiven Systems mit Echtzeitanforderungen:
Goals• Detect, identify,
track, & destroy
time-critical
targetsAdapted from “The Future of AWACS”,
by LtCol Joe Chapa
Joint Forces
Global Info Grid
Joint Forces
Global Info Grid Challenge is to make this
possible!
Prof. Dr. B. Rumpe
Lehrstuhl für
Software Engineering
RWTH Aachen
Seite 25
Analogie: Hausbau
Ein Haus lässt sich durch verschiedene Pläne beschreiben:
• Grundriss
• Aufriss
• Lageplan
• ElektrischerAnschlussplan
• Kanalisation
• …
Jeder Plan
• hat einebestimmte Aufgabe
• stellt einen Ausschnittdes Hauses dar
• hat unterschiedlicheZielgruppen
Prof. Dr. B. Rumpe
Lehrstuhl für
Software Engineering
RWTH Aachen
Seite 26
Sicht
Eine Sicht ist eine Darstellung eines Systems, die nur die Elemente
und Beziehungen enthält, die für eine bestimmte Perspektive
relevant sind.
Verschiedene Sichten bilden eine Gesamtspezifikation
Herausforderungen:
• Konsistenz zwischen Sichten
• Vollständigkeit
• Möglichkeit zur Abstraktion
• Übersichtlichkeit der Darstellung
• Realitätstreue der Sicht
• Beschreibungssprachen
Prof. Dr. B. Rumpe
Lehrstuhl für
Software Engineering
RWTH Aachen
Seite 27
„4+1 Sichten“-Modell der Softwarearchitektur
(aus dem Rational Unified Process - RUP)
Philippe Kruchten, The 4+1 view model of architecture, IEEE
Software, November 1995, 12(6), pp. 42-50
Logische Sicht Struktursicht
Ablaufsicht Physikalische Sicht
Szenarien
Prof. Dr. B. Rumpe
Lehrstuhl für
Software Engineering
RWTH Aachen
Seite 28
Bestandteile der 4+1 Sichten
Logische Sicht Struktursicht
Ablaufsicht Physikalische Sicht
Grobentwurf
Feinentwurf
Szenarien• Use-Cases
• Klassenmodell• Verfeinerung desAnalysemodells
• Prozesse• Koordination
• Subsysteme• Schnittstellen
• Komponenten• Hardwaresysteme• Netze
Prof. Dr. B. Rumpe
Lehrstuhl für
Software Engineering
RWTH Aachen
Seite 29
Primäre Zielgruppe/Aufgabe jeder der vier Sichten
Logische Sicht Struktursicht
Ablaufsicht Physikalische Sicht
• Endanwender • Programmierung• Wartung
• System-Integratoren(Performanz, Durchsatz ...)
• Kommunikation• Verteilung• Auslieferung, Installation
Grobentwurf
Feinentwurf
Prof. Dr. B. Rumpe
Lehrstuhl für
Software Engineering
RWTH Aachen
Seite 30
Blockdiagramme
Blockdiagramme sind kein Bestandteil von UML!
(Gleichwertige Notation in UML: Implementierungsdiagramm)
Blockdiagramme sind ein verbreitetes Hilfsmittel zur Skizzierung der
logischen Struktur einer Systemarchitektur.
• Subsystem umfasst Objektebestimmter Klassen
• Schnittstelle ist klardefiniert(Aufrufschnittstelle,Kommunikationsprotokoll)
UmfassendesSubsystem
Schnittstelle
Subsystem
Prof. Dr. B. Rumpe
Lehrstuhl für
Software Engineering
RWTH Aachen
Seite 31
UML: Implementierungsdiagramm
Komponente
Schnittstelle
ZusammengesetzteKomponente
A
CB
D
CB
A
D
analogesBlockdiagramm
Prof. Dr. B. Rumpe
Lehrstuhl für
Software Engineering
RWTH Aachen
Seite 32
Konfigurationsdiagramme
Konfigurationsdiagramme sind (noch) nicht Bestandteil von UML!
Konfigurationsdiagramme sind das meistverbreitete Hilfsmittel zur
Beschreibung der physikalischen Verteilung von System-
Komponenten.
SpeicherndesSystem
LokalesKommunikationsnetz
Datenkommunikations-Netz
Rechner, Knoten
Prof. Dr. B. Rumpe
Lehrstuhl für
Software Engineering
RWTH Aachen
Seite 33
UML: Verteilungsdiagramm
engl.: deployment diagram
zeigt die physische Verteilung von Systemen
<<network>> local network
<<processor>>Client
<<processor>>Server 1
<<processor>>Server 2
A B
Stereotypen kennzeichnen die Arten von Knoten
Komponenten könnenzugeordnet werden
Node (Knoten)
Prof. Dr. B. Rumpe
Lehrstuhl für
Software Engineering
RWTH Aachen
Seite 34
PhysikalischeKonfiguration
Blockdiagramm
PC1 ... PCn PDA1 PDAm
Termin-Server
Anzeigetafel-Steuerung
PC Client PDA Client
PDA Sync
Termin-ManagerDaten-Export
Termin-Datenbank
Beispiel Terminverwaltung
6. Software- & Systementwurf 6.3. Taktiken im Softwareentwurf
Prof. Dr. Bernhard Rumpe
Lehrstuhl für Software Engineering
RWTH Aachen
http://www.se-rwth.de/
Literatur:
• Sommerville 10
• Balzert Band I LE 23
• Balzert Band II LE 17
Analyse Entwurf Implemen-tierung
Test,Integration
Wartung
Grobentwurf Feinentwurf
Prof. Dr. B. Rumpe
Lehrstuhl für
Software Engineering
RWTH Aachen
Seite 36
Taktiken
Taktik
• Technik die Stufe eines Qualitätsattributs in einem System zu
verändern
• kann durch spezifischere Taktiken verfeinert werden
• wird typischerweise durch Muster realisiert
Sammlung von Taktiken für einzelne Qualitätsattribute möglich
Bieten Vokabular für die Auswirkungen des Einsatzes von Mustern
auf das Systemverhalten
[BCK03] enthält Sammlung von Taktiken für
• Verfügbarkeit
• Modifizierbarkeit
• Performance
• Security
• Testbarkeit
• Usability
Prof. Dr. B. Rumpe
Lehrstuhl für
Software Engineering
RWTH Aachen
Seite 37
Verfügbarkeit, Begriffsbildung:
Failure
• Von außen beobachtbarer Fehler eines Systems
• ggf. mehrere Faults resultieren in einem Failure
Fault
• Intern aufgetretener Fehler
• Kann korrigiert werden oder wird zum Failure
Mean Time to Failure (MTF) =Durchschnittliche Zeit zwischenzwei Failures (Ohne Down-Zeiten)
Mean Time to Repair (MTR) =Durchschnittliche Zeit zurReparatur eines Failures
Verfügbarkeit = MTF/(MTF+MTR)
Geplante Wartungsarbeiten werden nicht gerechnet.
Failure n Failure n+1
MTR MTF
Prof. Dr. B. Rumpe
Lehrstuhl für
Software Engineering
RWTH Aachen
Seite 38
Taktiken für Verfügbarkeit (1/4)
Fehlererkennung (Fault)
• Ping/Echo
• Eine Komponente pingt alle anderen in regelmäßigen Abständen an
und kontrolliert die Antworten
• Heartbeat
• Komponenten müssen sich regelmäßig melden
• Vorteilhaft falls bereits regelmäßige Kommunikation stattfindet
• Exceptions
• Delegation der Fehlerbehandlung an eine
Fehlerbehandlungskomponente
Prof. Dr. B. Rumpe
Lehrstuhl für
Software Engineering
RWTH Aachen
Seite 39
Taktiken für Verfügbarkeit (2/4)
Fehlerbehandlung (Fault)
• Abstimmen
• Möglich bei redundanten Systemen
• Aktive Redundanz
• Redundante Komponenten laufen parallel und agieren mit der
Umgebung
• Bei Ausfall einer Komponente bleibt das System lauffähig
• Passive Redundanz
• Nur eine Komponente interagiert mit der Umgebung
• Die übrigen werden fortlaufend auf den neusten Stand gebracht
• Bei Ausfall übernimmt eine passive Komponente die aktive Rolle
• Spare
• Redundantes System, das mehrere Komponenten übernimmt
• Kann eine Rolle dynamisch übernehmen
Prof. Dr. B. Rumpe
Lehrstuhl für
Software Engineering
RWTH Aachen
Seite 40
Beispiel: Heartbeat + Redundanz
Monitor und Auswahl haben zusätzlich eine einfache
Steuerungsfunktion
Beispiel: Motorsteuerung
Motorsteuerung
Sensoren
Monitor
Komplexe
Steuerung
Einfache
Steuerung
AuswahlAktoren
Reset
Heartbeat
Failure-
Mode
Prof. Dr. B. Rumpe
Lehrstuhl für
Software Engineering
RWTH Aachen
Seite 41
Taktiken für Verfügbarkeit (3/4)
Komponente wiedereinführen (nach Abschaltung durch Failure)
• Schattenoperation
• Komponente mit Failure beobachtet nur das System
• vergleicht Verhalten mit redundanten Komponenten
• kehrt nach kurzer Zeit in den Betrieb zurück
• Zustands-Resynchronisation der redundanten Komponenten
• System in den aktuellen Zustand zurückversetzen
• Kopie von redundanten Systemen
• kann sehr aufwändig sein, wenn das Synchronisationsprotokoll
komplex ist
• Checkpoint/Rollback.
• Periodisch wird ein Checkpoint erstellt
• In diesen Zustand kann das System wieder ersetzt werden
(Rollback)
Prof. Dr. B. Rumpe
Lehrstuhl für
Software Engineering
RWTH Aachen
Seite 42
Taktiken für Verfügbarkeit (4/4)
Fehlervermeidung
• Entfernen aus dem System
• Automatische oder manuelle Entfernung einer Komponente um
Failures zu verhindern
• Transaktionen
• Bündelung sequentieller Schritte
• Auswirkungen können bei Fehlschlag eines Schritts rückgängig
gemacht werden können
• Prozess Monitor
• Ein Prozess Monitor beobachtet das System
• Entfernt nicht funktionierende Komponenten
Prof. Dr. B. Rumpe
Lehrstuhl für
Software Engineering
RWTH Aachen
Seite 43
Modifizierbarkeit
Modifizierbarkeit
• Messbar durch Zeit bzw. Kosten für
• die Implementierung
• das Testen
• Ausliefern von Änderungen
• wird erschwert durch
• die Abhängigkeit von Komponenten untereinander
• fehlende Lokalisierung von Funktionalität
• statische Abhängigkeiten zwischen Komponenten
„Ripple-Effekt“
• Änderungen an anderen Modulen, die indirekt notwendig
werden, weil ein Modul anzupassen ist.
Prof. Dr. B. Rumpe
Lehrstuhl für
Software Engineering
RWTH Aachen
Seite 44
Abhängigkeiten von Modulen untereinander (1/2)
Datenformat (Syntax)
• Ausgetauschte Daten haben ein bestimmtes Format
• Dienste haben eine Signatur
Daten-Bedeutung (Semantik)
• Ausgetauschte Daten haben eine festgelegte Bedeutung
• Dienste haben eine festgelegte Auswirkung
Reihenfolge
• Protokolle, Timing
Namen der Schnittstellen
• Eine Komponente kann mehrere Schnittstellen bieten
• Zum Nutzen muss der Name bekannt sein
Prof. Dr. B. Rumpe
Lehrstuhl für
Software Engineering
RWTH Aachen
Seite 45
Abhängigkeiten von Modulen untereinander (2/2)
Physischer/Logischer Ort der Komponenten
• z.B. verschiedene Steuergeräte
• Adressierung
Quality of Service (Dienstgüte)
• Komponenten erwarten eine gewisse Dienstgüte
Existenz
• Dynamische Erzeugung
• Statische Abhängigkeit
• benötigte Laufzeitbibliotheken
Ressourcenverhalten
• Speicher / Rechenzeit / Kommunikation
• Blockierung gemeinsamer Ressourcen
Prof. Dr. B. Rumpe
Lehrstuhl für
Software Engineering
RWTH Aachen
Seite 46
Taktiken für Modifizierbarkeit:
Reduktion der betroffenen Module
Kapselung (hohe Kohärenz)
• Möglichst wenig öffentliche Schnittstellen
• Private Methoden können leicht geändert werden (d.h. sind ohne Auswirkung auf andere Module)
Verbindungen reduzieren (geringe Kopplung)
• Weniger Module werden beeinflusst
Vorhandene Schnittstellen erhalten
• Neue Schnittstellen nur zusätzlich einführen
• Gefahr:
• Komplexes System
• Spätere Änderungen aufwändiger (vgl. Agile Methoden)
Vermittler
• Je nach Verbindungstyp, z.B.
• Bus statt direkter Verbindung
• Ort der Komponenten: Namensdienste
• Entwurfsmuster Fassade, Adapter, Mediator
Prof. Dr. B. Rumpe
Lehrstuhl für
Software Engineering
RWTH Aachen
Seite 47
Taktiken für Modifizierbarkeit:
Reduktion der Änderungen
Semantische Kohärenz erhalten; gut sind:
• Eine Aufgabe wird durch genau eine Komponente erfüllt
• Die Realisierung eines Dienst ist nicht über das System verteilt
Änderungen antizipieren
• Mögliche Änderungen gedanklich durchspielen(nicht implementieren! vgl. XP-Grundsätze)
• Fragen:
• Betreffen fundamental unterschiedliche Änderungen dasselbe System?
• Betrifft eine Änderung mehrere Module?
• Falls ja, deutet das auf mangelnde semantische Kohärenz hin
Module generalisieren
• Je allgemeiner ein Modul programmiert ist, desto wahrscheinlicher ist es, dass es die neue Aufgabe bereits erfüllt
• Aber XP-Grundsatz: Man kann Änderungen oft nicht vorausahnen, daher ist ein einfacher Entwurf zu bevorzugen
Prof. Dr. B. Rumpe
Lehrstuhl für
Software Engineering
RWTH Aachen
Seite 48
Taktiken für Modifizierbarkeit:
Verzögern des Bindungs-Zeitpunkts
Registrierung zur Laufzeit
• Plug-and-Play-Fähigkeit von Komponenten
Konfigurationsdateien
• Rekonfiguration bei Auslieferung oder zur Laufzeit
Polymorphie
• Erlaubt das Ersetzen durch abgeleitete Klassen/Komponenten
zur Laufzeit
Komponentenersetzung
• Dynamisches Zusammenstellen der Anwendung bei
Auslieferung
Standardisierte Protokolle
• Erlauben die Kooperation unabhängiger Prozesse
Prof. Dr. B. Rumpe
Lehrstuhl für
Software Engineering
RWTH Aachen
Seite 49
The Dependency Inversion Principle
Robert C. Martin:
A) High-Level-Module sollen nicht von Low-level-Modulen abhängen.
Beide sollen nur von Abstraktionen (Interfaces) abhängig sein.
B) Abstraktionen sollen nicht von Details abhängen, sondern die
Details von den Abstraktionen
Vorteile:
• Anpassungen unten beeinflussen obere Ebenen nicht!
• leichtere Modifizierbarkeit und Testbarkeit
<<interface>>
<<interface>>
nicht so
sondern so
6. Software- & Systementwurf 6.4. Objektorientierter Feinentwurf mit
Klassendiagrammen
Prof. Dr. Bernhard Rumpe
Lehrstuhl für Software Engineering
RWTH Aachen
http://www.se-rwth.de/
Analyse Entwurf Implemen-tierung
Test,Integration
Wartung
Grobentwurf Feinentwurf
Prof. Dr. B. Rumpe
Lehrstuhl für
Software Engineering
RWTH Aachen
Seite 51
Objektorientierter Feinentwurf
Ausgangspunkt:
• Grobdefinition der Architektur:
• Zerlegung in Subsysteme
(evtl. unter Verwendung von Standardarchitekturen)
• Verteilungskonzept
• Ablaufmodell
Ergebnis:
• OO-Modell für jedes Subsystem der Architektur
• OO-Modell für unterstützende Subsysteme
• unter Berücksichtigung gewählter Technologien
• Spezifikationen der Klassen
• Spezifikationen von externen Schnittstellen
Prof. Dr. B. Rumpe
Lehrstuhl für
Software Engineering
RWTH Aachen
Seite 52
Verfeinerung des Analysemodells
Fachlicher Kern: Mehr Details als im Analysemodell
• Listen der Attribute und Operationen: vollständig
• Attribute und Operationen: Datentypen, Sichtbarkeit
• Operationen: Spezifikation (z.B. Vor- und Nachbedingungen)
• Assoziationen/Aggregationen:
Navigationsrichtung, Ordnung, Qualifikation
Zusätzliche Klassen/Pakete:
• Einbindung in Infrastruktur, Altsysteme etc.
• Anpassungs- und Entkopplungsschichten für gewählte
Technologien
(z.B. Datenzugriffsschicht, CORBA-Schnittstellen, XML-
Anschluss...)
Prof. Dr. B. Rumpe
Lehrstuhl für
Software Engineering
RWTH Aachen
Seite 53
Verfeinerung des Analysemodells
Grobskizze:
K
abrakadabra
abcxyz
K
abra (x:T1) T2kadabra (y: T2): T1
abc: T1xyz: T2
Prof. Dr. B. Rumpe
Lehrstuhl für
Software Engineering
RWTH Aachen
Seite 54
UML im Entwurf
generell: Analysemodelle werden im Entwurf umgebaut
Insbesondere Klassendiagramme erhalten dazu eine neue
Bedeutung:
• In der Analyse repräsentieren Klassen meist Einheiten der realen
Welt
• Im Entwurf stellen Klassen einen Teil des Softwaresystems dar
• Es findet eine Detaillierung und Präzisierung statt
Statecharts werden (soweit nicht direkt in Einzelspezifikationen von
Methoden zerlegt) ebenfalls detailliert
Andere UML-Diagramme werden im Feinentwurf vor allem als
Vorlagen (Aktivitäts-, Sequenzdiagramme, Use Cases) oder zur
Strukturierung im Grobentwurf (Komponentendiagramme)
eingesetzt, selbst aber nicht detailliert.
Prof. Dr. B. Rumpe
Lehrstuhl für
Software Engineering
RWTH Aachen
Seite 55
UML zum logischen Detailentwurf
Analyse-Modell Entwurfs-Modell
Notation: UML
Objekte: Fachgegenstände
Klassen: Fachbegriffe
Vererbung: Begriffsstruktur
Annahme perfekterTechnologie
Funktionale Essenz
Völlig projektspezifisch
Grobe Strukturskizze
Notation: UML
Objekte: Softwareeinheiten
Klassen: Schemata
Vererbung: Programmableitung
Erfüllung konkreterRahmenbedingungen
Gesamtstruktur des Systems
Ähnlichkeiten zwischenverwandten Projekten
Genaue Strukturdefinition
Mehr Struktur & mehr Details
Prof. Dr. B. Rumpe
Lehrstuhl für
Software Engineering
RWTH Aachen
Seite 56
Pakete und Subsysteme
• UML:– Pakete als "Ordner"– "Subsystem": Paket zur Realisierung
einer Einheit der Architektur• Java-Sprachkonstrukt: package
Benutzungs-Schnittstelle
Daten-Verwaltung
Teambesprechung
Termin
Persönlicher Termin
Terminkalender
Teammitglied
Besprechungsraum
FachlichesModell
<<use>>
<<use>>
Aufruf- & Nutzungs-Beziehung
Prof. Dr. B. Rumpe
Lehrstuhl für
Software Engineering
RWTH Aachen
Seite 57
Sichtbarkeit
Sichtbarkeits-Symbol
UMLJava
Sichtbar für:
Gleiche Klasse
Andere Klasse, gleiches Paket
Andere Klasse, anderes Paket
Unterklasse, gleiches Paket
Unterklasse, anderes Paket
+public
#protected
–private (default)
ja
ja
ja
ja
ja
ja
ja
ja
ja ja
ja
ja
nein
nein
nein
nein
nein
nein
nein
neinja / *
* In UML und C++ “nein”, in Java “ja”.
Prof. Dr. B. Rumpe
Lehrstuhl für
Software Engineering
RWTH Aachen
Seite 58
Qualifizierte Assoziation
Definition: Eine Qualifikation (Qualifier) ist ein Attribut für eine Assoziation
zwischen Klassen K1 und K2, durch das die Menge der zu einem K1-Objekt
assoziierten K2-Objekte partitioniert wird.
Zweck der Qualifikation ist direkter Zugriff unter Vermeidung von Suche.
Notation:
K1 K20..*
0..1aK1 K2
als Detaillierung von:
Bedeutung vor allem im Zusammenhang mit Datenbanken (Indizes), aber auch mit geeigneten Datenstrukturen nach Java abbildbar.
Prof. Dr. B. Rumpe
Lehrstuhl für
Software Engineering
RWTH Aachen
Seite 59
Qualifizierte Assoziation: Beispiel (1)
Raum12.istFrei(start=04.05.02 10:00, dauer=60min);
führt zu einer Suche über alle assoziierten Teambesprechungen !
Teambesprechung
themen
Termin
titelbeginndauer
verschieben() {abstract}
raumFestlegen()einladen()absagen()verschieben()
{abstract}
Veranstal-tungsort
0..10..*
Besprechungsraum
raumNrkapazitätreservieren()freigeben()freienRaumSuchen()istFrei()
Prof. Dr. B. Rumpe
Lehrstuhl für
Software Engineering
RWTH Aachen
Seite 60
Qualifizierte Assoziation: Beispiel (2)
Raum12.istFrei(start=04.05.02 10:00, dauer=60min);
kann direkt nach Datum abfragen, ob eine Assoziation besteht
Teambesprechung
themen
Termin
titelbeginndauer
verschieben() {abstract}
raumFestlegen()einladen()absagen()verschieben()
{abstract}
Veranstal-tungsort
0..10..1
Besprechungsraum
raumNrkapazitätreservieren()freigeben()freienRaumSuchen()istFrei()
beginn
wie bisher
kleinereMultiplizität
Indizierter Zugriff(Qualifikation)
Prof. Dr. B. Rumpe
Lehrstuhl für
Software Engineering
RWTH Aachen
Seite 61
Realisierung einer qualifizierten Assoziation
r12: Besprechungsraum
raumNr = "r12"kapazität = 20
04.05.02 09:0010.05.02 10:0010.05.02 11:0010.05.02 12:0011.05.02 09:0012.05.02 15:0012.05.02 17:00
Teambesprechungs-Objekte
Direktzugriff erfolgt z.B. durch:
Hashfunktion (Berechnung des Indexwerts ausgegebenem Datum)
Sortierte Baumstruktur
Prof. Dr. B. Rumpe
Lehrstuhl für
Software Engineering
RWTH Aachen
Seite 62
Geordnete und sortierte Assoziation
{ordered} an einem Assoziationsende:
• Es besteht eine feste Reihenfolge, in der die assoziierten Objekte durchlaufen werden können Oft ist Zugriff über Listen, Iteratoren möglich
• Mehrfachvorkommen eines Objekts sind verboten
Default: die assoziierten Objekte sind als Menge strukturiert.
Weitere Einschränkungen möglich,z.B. die Forderung nach Sortierung gemäß bestimmter Attribute:
Teammitglied Teambesprechung0..*0..* Teilnahme
{ordered}
Teammitglied Teambesprechung0..*0..*
Teilnehmer{sorted}
{key=name}{order=ascending}
Besprechungen{sorted}
{key=beginn}{order = ascending}
Prof. Dr. B. Rumpe
Lehrstuhl für
Software Engineering
RWTH Aachen
Seite 63
Verwaltungsklassen
Teambesprechung
themen
Termin
titelbeginndauer
verschieben() {abstract}
raumFestlegen()einladen()absagen()verschieben()
Besprechungsraum
raumNrkapazität
reservieren()freigeben()
istFrei()
Veranstal-tungsort
0..1
{abstract}
beginn0..1
freienRaumSuchen()
Raumverwaltung
– einzigeInstanz
*
1
freienRaumSuchen()
Bestand{sorted} {key= kapazität}
Prof. Dr. B. Rumpe
Lehrstuhl für
Software Engineering
RWTH Aachen
Seite 64
Abgeleitete (redundante) Elemente
Definition Ein abgeleitetes Modellelement (z.B. Attribut,
Assoziation) ist ein Modell-Element, das jederzeit aus anderen
(nicht abgeleiteten) Elementen rekonstruiert werden kann.
Notation
/ Modellelement oder
Modellelement {derived}
Beispiele:
Ableitung kann formuliert werden mit der Object ConstraintLanguage OCL, ein weiterer Teil der UML.
TeambesprechungTeammitglied
Leitung
Teilnahme
1
*
2..*...
*name
/ teilnehmeranzahl/ leiter
{leiter = Leitung.name}{teilnehmeranzahl = Teilnahme->size}
Prof. Dr. B. Rumpe
Lehrstuhl für
Software Engineering
RWTH Aachen
Seite 65
Parameter und Datentypen für Operationen
Analysephase:
• oft Operationsname ausreichend
• ggf. Parameternamen ohne weitere Information
Entwurfsphase:
• Parameter und Datentypen der Operationen genau festlegen !
Beispiele (Klasse Besprechungsraum):
+ freienRaumSuchen
(plaetze: int, start: Date, dauer: int=60, wunschraum:
Besprechungsraum): Besprechungsraum
– istFrei(beginn: Date, dauer: int):boolean
+ reservieren (für: Termin):boolean;
Prof. Dr. B. Rumpe
Lehrstuhl für
Software Engineering
RWTH Aachen
Seite 66
Spezifikation von Operationen
Definition Die Spezifikation einer Operation legt das Verhalten der Operation fest,
ohne einen Algorithmus festzuschreiben. Grundprinzip:
Es wird das "Was" beschrieben und noch nicht das "Wie".
Häufigste Formen von Spezifikationen:
• Text in natürlicher Sprache (oft mit speziellen Konventionen)
• Oft in Programmcode eingebettet (Kommentare)
• Werkzeugunterstützung zur Dokumentationsgenerierung,
z.B. "javadoc"
• Vor- und Nachbedingungen
• Tabellen, spezielle Notationen
• "Pseudocode" (Programmiersprachenartiger Text)• nur mit Vorsicht zu verwenden - oft zu viele Details festgelegt !
Prof. Dr. B. Rumpe
Lehrstuhl für
Software Engineering
RWTH Aachen
Seite 67
Navigationsrichtung von Assoziationen
Assoziationen werden verwendet, um im Objektgeflecht zu
navigieren.
Assoziationen sind im Normalfall in beiden Richtungen navigierbar
(d.h. werden auf beiden Seiten wie ein Attribut behandelt).
Spezialfall: einseitige Navigationsrichtung (d.h. nur auf einer Seite
wie Attribut behandelt).
Beispiel:
1
Teambesprechung
themen
raumFestlegen()einladen()absagen()verschieben()
Teammitgliedleitet
Teilnahme
*
* 2..*
NameAbteilung
terminBestätigen()
Prof. Dr. B. Rumpe
Lehrstuhl für
Software Engineering
RWTH Aachen
Seite 68
Schnittstellen
Guter Software-Entwurf sichert Homogenität und Ergonomie.
• Gleichartige Funktionalität soll in gleicher Weise aufrufbar sein.
• Schnittstelle (interface) ist ein Sprachkonstrukt von UML und Java.
Definition: Eine Schnittstelle ist eine abstrakte Klasse, die keine Attribute und keine Operationsrümpfe (Implementierungen) enthält.
• Sammlung von Operations-Signaturen
UML:
<<interface>>XY
f (x: int): int
XYImpl
f (x: int): int
"implementiert"
Java:
interface XY {
int f (int x);
}
class XYImpl implements XY {
public int f (int x) {
... hier Rumpf von f ...
}
...
}
Prof. Dr. B. Rumpe
Lehrstuhl für
Software Engineering
RWTH Aachen
Seite 69
Einfache Vererbung durch Schnittstellen
Hinweis: “lollipop”-Notation für Schnittstellen ist weitverbreitet und in UML ebenfalls zulässig (und gleichwertig):
Team-besprechung
Termin
Vortrag
Hausveranstaltung<<interface>>
einladen()absagen()
Team-besprechung
Haus-veranstaltung
einladen()absagen()
einladen()absagen()
Prof. Dr. B. Rumpe
Lehrstuhl für
Software Engineering
RWTH Aachen
Seite 70
Schnittstellen und abstrakte Klassen
Abstrakte Klasse Schnittstelle
Enthält Attribute und Operationen
Kann Default-Verhaltenfestlegen
Default-Verhalten kann inUnterklassen redefiniert
werden
Java: Unterklasse kann nurvon einer Klasse erben
Enthält nur Operationen(und ggf. Konstante)
Kann kein Default-Verhaltenfestlegen
Unterklassen müssen Verhalten definieren
Java: Eine Klasse kannmehrere Schnittstellen
implementieren
Schnittstelle ist eine spezielleSicht auf eine Klasse
Prof. Dr. B. Rumpe
Lehrstuhl für
Software Engineering
RWTH Aachen
Seite 71
Zusammenfassung:
UML-Klassenmodelle in Analyse und Entwurf
Analyse-Modell Entwurfs-Modell
Skizze: Teilweise unvollständigin Attributen und Operationen
Datentypen und Parameterkönnen noch fehlen
Noch kaum Bezug zurRealisierungssprache
Keine Überlegungen zurRealisierung von Assoziationen
Vollständige Angabe allerAttribute und Operationen
Vollständige Angabe vonDatentypen und Parametern
Auf Umsetzung in gewählterProgrammiersprache bezogen
Navigationsangaben, Qualifikation,Ordnung, Verwaltungsklassen
Entscheidung über Datenstrukturen
Vorbereitung zur Anbindung vonBenutzungsoberfläche und
Datenhaltung an fachlichen Kern