Swt Kap6 Softwareentwurf

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



RWTH Aachen


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


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


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


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


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


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


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


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


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



RWTH Aachen


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)


Test,Integration

Wartung


Prof. Dr. B. Rumpe

Lehrstuhl für


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


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


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


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


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


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


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


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


RWTH Aachen

Seite 21

Architektur-Beispiel

Physikalische Architekturen

Networked

Architecture

Stand-alone

Architecture

Prof. Dr. B. Rumpe

Lehrstuhl für


RWTH Aachen

Seite 22


Physikalische Architekturen:

• Client

• Firewall

• Application Servers

• Data

Prof. Dr. B. Rumpe

Lehrstuhl für


RWTH Aachen

Seite 23


Schichten Architektur der Software (innerhalb eines Systems):

Prof. Dr. B. Rumpe

Lehrstuhl für


RWTH Aachen

Seite 24


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


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


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


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


RWTH Aachen

Seite 28

Bestandteile der 4+1 Sichten



Grobentwurf

Feinentwurf

Szenarien• Use-Cases

• Klassenmodell• Verfeinerung desAnalysemodells

• Prozesse• Koordination

• Subsysteme• Schnittstellen

• Komponenten• Hardwaresysteme• Netze

Prof. Dr. B. Rumpe

Lehrstuhl für


RWTH Aachen

Seite 29

Primäre Zielgruppe/Aufgabe jeder der vier Sichten



• Endanwender • Programmierung• Wartung

• System-Integratoren(Performanz, Durchsatz ...)

• Kommunikation• Verteilung• Auslieferung, Installation

Grobentwurf

Feinentwurf

Prof. Dr. B. Rumpe

Lehrstuhl für


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


RWTH Aachen

Seite 31

UML: Implementierungsdiagramm

Komponente

Schnittstelle

ZusammengesetzteKomponente

A

CB

D

CB

A

D

analogesBlockdiagramm

Prof. Dr. B. Rumpe

Lehrstuhl für


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


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


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



RWTH Aachen


Literatur:

• Sommerville 10

• Balzert Band I LE 23

• Balzert Band II LE 17


Test,Integration

Wartung


Prof. Dr. B. Rumpe

Lehrstuhl für


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


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


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


RWTH Aachen

Seite 39


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


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


RWTH Aachen

Seite 41


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


RWTH Aachen

Seite 42


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


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


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


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


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


RWTH Aachen

Seite 47


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


RWTH Aachen

Seite 48


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


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



RWTH Aachen



Test,Integration

Wartung


Prof. Dr. B. Rumpe

Lehrstuhl für


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


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


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


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


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


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


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


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


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


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



{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


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


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


RWTH Aachen

Seite 63

Verwaltungsklassen

Teambesprechung

themen

Termin

titelbeginndauer



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


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


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


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


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


Teammitgliedleitet

Teilnahme

*

* 2..*

NameAbteilung

terminBestätigen()

Prof. Dr. B. Rumpe

Lehrstuhl für


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


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


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


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

Swt Kap6 Softwareentwurf

Technology

Transcript of Swt Kap6 Softwareentwurf