• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Swt Kap6 Softwareentwurf
 

Swt Kap6 Softwareentwurf

on

  • 2,259 views

 

Statistics

Views

Total Views
2,259
Views on SlideShare
2,259
Embed Views
0

Actions

Likes
0
Downloads
18
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Swt Kap6 Softwareentwurf Swt Kap6 Softwareentwurf Presentation Transcript

    • Farbe! Softwaretechnik Vorlesung 6. Software- und Systementwurf Prof. Dr. Bernhard Rumpe Lehrstuhl für Software Engineering RWTH Aachen http://www.se-rwth.de/
    • 6. Software- & Systementwurf 6.1. Entwurfsprinzipien Analyse Entwurf Implemen- Test, Wartung tierung Integration Grobentwurf Feinentwurf Prof. Dr. Bernhard Rumpe Literatur: Lehrstuhl für Software Engineering • Sommerville 10 RWTH Aachen • Balzert Band I LE 23 • Balzert Band II LE 17 http://www.se-rwth.de/
    • Prof. Dr. B. Rumpe Lehrstuhl für Software Engineering RWTH Aachen Software-Entwurf Seite 3  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 Gliederung des Entwurfsprozesses Seite 4  Architekturentwurf Gesamtstruktur  Subsystem-Spezifikation des Systems (Grobentwurf)  Schnittstellen-Spezifikation  Komponentenentwurf Detailstruktur  Datenstrukturentwurf des Systems (Feinentwurf)  Algorithmenentwurf  Grobentwurf: • weitgehend unabhängig von Implementierungssprache  Feinentwurf • angepasst an die Implementierungssprache und Plattform
    • Prof. Dr. B. Rumpe Lehrstuhl für Software Engineering RWTH Aachen Arbeitsteilung beim Entwurf Seite 5 Architekturentwurf Entwurf Entwurf Schnittstelle Schnittstelle 12 2... Entwurf Entwurf Entwurf Subsystem 1 Subsystem 2 Subsystem ... Entwurf der Komponenten
    • Prof. Dr. B. Rumpe Lehrstuhl für Software Engineering RWTH Aachen Kriterien für "guten" Entwurf Seite 6  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 Kohäsion Seite 7  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 Kopplung Seite 8  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 Interne Wiederverwendung Seite 9  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 Framework Seite 10  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 Referenzmodelle und -architekturen Seite 11  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 Analyse Entwurf Implemen- Test, Wartung tierung Integration Grobentwurf Feinentwurf Prof. Dr. Bernhard Rumpe Literatur: Lehrstuhl für Software Engineering • Sommerville 10 • Balzert LE 23 RWTH Aachen • Shaw/Garlan: Software Architecture, 1996 • Bass/Clements/Kazman: Software Architecture http://www.se-rwth.de/ in Practice, Addison-Wesley 1998 • P. Kruchten, The 4+1 view model of architecture, IEEE Software, Nov. 1995, 12(6)
    • Prof. Dr. B. Rumpe Lehrstuhl für Software Engineering RWTH Aachen Von der Analyse zum Entwurf Seite 13 Analyse Anforderungs- Funktionale Anforderungs- Spezifikation Spezifikation Ermittlung (Pflichtenheft) (Produktdefinition) System- Modellierung Architektur- Spezifikation Architektur- Entwurf Entwurf Detail- Entwurf Klassen- bzw. Modul- Spezifikationen
    • Prof. Dr. B. Rumpe Lehrstuhl für Software Engineering RWTH Aachen Was ist Architektur? Seite 14  „[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 Softwarearchitektur: Definitionen aus der Literatur Seite 15  “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 Softwarearchitektur: Unsere Sicht Seite 16  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 Stakeholder Seite 17  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 Einfluss der Stakeholder auf die Softwarearchitektur Seite 18 Management Wartungsteam Entwicklungsteam Kunde Niedrige Kosten, Niedrige Kosten, schnelle Programmierer Auslieferung, kaum Modifizierbarkeit Nachbesserungen gleichmäßig Erweiterbarkeit auslasten Performance, Time to Market, Features, Sicherheit,Verlässlich- ?? Abgrenzung zu Konkurrenz- produkten, keit, Nutzbarkeit Kundenspezifische Anpassbarkeit Nutzer Marketing Software- architekt Abbildung [BCK03] nachempfunden
    • Prof. Dr. B. Rumpe Lehrstuhl für Software Engineering RWTH Aachen Nutzen einer Architekturbeschreibung (1/2) Seite 19  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 Nutzen einer Architekturbeschreibung (2/2) Seite 20  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 Architektur-Beispiel Seite 21  Physikalische Architekturen Stand-alone Architecture Networked Architecture
    • Prof. Dr. B. Rumpe Lehrstuhl für Software Engineering RWTH Aachen Architektur-Beispiel Seite 22  Physikalische Architekturen: • Client • Firewall • Application Servers • Data
    • Prof. Dr. B. Rumpe Lehrstuhl für Software Engineering RWTH Aachen Architektur-Beispiel Seite 23  Schichten Architektur der Software (innerhalb eines Systems):
    • Prof. Dr. B. Rumpe Lehrstuhl für Software Engineering RWTH Aachen Architektur-Beispiel Seite 24  Kommunikationsarchitektur eines Software-Intensiven Systems mit Echtzeitanforderungen: Joint Forces Joint Forces Global Info Grid Challenge Global Info Grid is to make this possible! Goals • Detect, identify, track, & destroy time-critical Adapted from “The Future of AWACS”, targets by LtCol Joe Chapa
    • Prof. Dr. B. Rumpe Lehrstuhl für Software Engineering RWTH Aachen Analogie: Hausbau Seite 25  Ein Haus lässt sich durch verschiedene Pläne beschreiben: • Grundriss • Aufriss • Lageplan • Elektrischer Anschlussplan • Kanalisation • …  Jeder Plan • hat eine bestimmte Aufgabe • stellt einen Ausschnitt des Hauses dar • hat unterschiedliche Zielgruppen
    • Prof. Dr. B. Rumpe Lehrstuhl für Software Engineering RWTH Aachen Sicht Seite 26  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 „4+1 Sichten“-Modell der Softwarearchitektur RWTH Aachen Seite 27 (aus dem Rational Unified Process - RUP) Logische Sicht Struktursicht Szenarien Ablaufsicht Physikalische Sicht Philippe Kruchten, The 4+1 view model of architecture, IEEE Software, November 1995, 12(6), pp. 42-50
    • Prof. Dr. B. Rumpe Lehrstuhl für Software Engineering RWTH Aachen Bestandteile der 4+1 Sichten Seite 28 Logische Sicht Struktursicht • Klassenmodell • Subsysteme • Verfeinerung des • Schnittstellen Analysemodells Szenarien • Use-Cases Grobentwurf Ablaufsicht Physikalische Sicht • Prozesse • Komponenten • Koordination • Hardwaresysteme • Netze Feinentwurf
    • Prof. Dr. B. Rumpe Lehrstuhl für Software Engineering RWTH Aachen Primäre Zielgruppe/Aufgabe jeder der vier Sichten Seite 29 Logische Sicht Struktursicht • Endanwender • Programmierung • Wartung Grobentwurf Ablaufsicht Physikalische Sicht • System-Integratoren • Kommunikation (Performanz, • Verteilung Durchsatz ...) • Auslieferung, Installation Feinentwurf
    • Prof. Dr. B. Rumpe Lehrstuhl für Software Engineering RWTH Aachen Blockdiagramme Seite 30  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 Objekte bestimmter Klassen • Schnittstelle ist klar definiert (Aufrufschnittstelle, Kommunikationsprotokoll) Schnittstelle Subsystem Umfassendes Subsystem
    • Prof. Dr. B. Rumpe Lehrstuhl für Software Engineering RWTH Aachen UML: Implementierungsdiagramm Seite 31 Zusammengesetzte Komponente Komponente D A Schnittstelle B C D A analoges Blockdiagramm B C
    • Prof. Dr. B. Rumpe Lehrstuhl für Software Engineering RWTH Aachen Konfigurationsdiagramme Seite 32  Konfigurationsdiagramme sind (noch) nicht Bestandteil von UML!  Konfigurationsdiagramme sind das meistverbreitete Hilfsmittel zur Beschreibung der physikalischen Verteilung von System- Komponenten. Rechner, Knoten Datenkommunikations- Speicherndes Netz Lokales Kommunikationsnetz System
    • Prof. Dr. B. Rumpe Lehrstuhl für Software Engineering RWTH Aachen UML: Verteilungsdiagramm Seite 33  engl.: deployment diagram  zeigt die physische Verteilung von Systemen Stereotypen kennzeichnen Node die Arten von Knoten (Knoten) <<processor>> Client <<network>> local network <<processor>> <<processor>> Komponenten können Server 1 Server 2 zugeordnet werden A B
    • Prof. Dr. B. Rumpe Lehrstuhl für Software Engineering RWTH Aachen Beispiel Terminverwaltung Seite 34 PDA1 PDAm Physikalische PC1 ... PCn Konfiguration Termin- Anzeigetafel- Server Steuerung PC Client PDA Client Blockdiagramm PDA Sync Daten- Termin-Manager Export Termin-Datenbank
    • 6. Software- & Systementwurf 6.3. Taktiken im Softwareentwurf Analyse Entwurf Implemen- Test, Wartung tierung Integration Grobentwurf Feinentwurf Prof. Dr. Bernhard Rumpe Literatur: Lehrstuhl für Software Engineering • Sommerville 10 RWTH Aachen • Balzert Band I LE 23 • Balzert Band II LE 17 http://www.se-rwth.de/
    • Prof. Dr. B. Rumpe Lehrstuhl für Software Engineering RWTH Aachen Taktiken Seite 36  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 Verfügbarkeit, Begriffsbildung: Seite 37  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 zwischen Failure n Failure n+1 zwei Failures (Ohne Down-Zeiten)  Mean Time to Repair (MTR) = Durchschnittliche Zeit zur MTR MTF Reparatur eines Failures  Verfügbarkeit = MTF/(MTF+MTR)  Geplante Wartungsarbeiten werden nicht gerechnet.
    • Prof. Dr. B. Rumpe Lehrstuhl für Software Engineering RWTH Aachen Taktiken für Verfügbarkeit (1/4) Seite 38  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 Taktiken für Verfügbarkeit (2/4) 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 Software Engineering RWTH Aachen Beispiel: Heartbeat + Redundanz Seite 40  Monitor und Auswahl haben zusätzlich eine einfache Steuerungsfunktion  Beispiel: Motorsteuerung Motorsteuerung Monitor Reset Failure- Mode Heartbeat Komplexe Steuerung Aktoren Auswahl Sensoren Einfache Steuerung
    • Prof. Dr. B. Rumpe Lehrstuhl für Software Engineering RWTH Aachen Taktiken für Verfügbarkeit (3/4) 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 Software Engineering RWTH Aachen Taktiken für Verfügbarkeit (4/4) 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 Software Engineering RWTH Aachen Modifizierbarkeit Seite 43  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 Abhängigkeiten von Modulen untereinander (1/2) Seite 44  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 Abhängigkeiten von Modulen untereinander (2/2) Seite 45  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 Taktiken für Modifizierbarkeit: RWTH Aachen Seite 46 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 Taktiken für Modifizierbarkeit: 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 Software Engineering Taktiken für Modifizierbarkeit: 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 Software Engineering RWTH Aachen The Dependency Inversion Principle Seite 49 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 nicht so <<interface>> <<interface>> sondern so  Vorteile: • Anpassungen unten beeinflussen obere Ebenen nicht! • leichtere Modifizierbarkeit und Testbarkeit
    • 6. Software- & Systementwurf 6.4. Objektorientierter Feinentwurf mit Klassendiagrammen Analyse Entwurf Implemen- Test, Wartung tierung Integration Grobentwurf Feinentwurf Prof. Dr. Bernhard Rumpe Lehrstuhl für Software Engineering RWTH Aachen http://www.se-rwth.de/
    • Prof. Dr. B. Rumpe Lehrstuhl für Software Engineering RWTH Aachen Objektorientierter Feinentwurf Seite 51  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 Verfeinerung des Analysemodells Seite 52  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 Verfeinerung des Analysemodells Seite 53  Grobskizze: K K abc abc: T1 xyz xyz: T2 abra abra (x:T1) T2 kadabra kadabra (y: T2): T1
    • Prof. Dr. B. Rumpe Lehrstuhl für Software Engineering RWTH Aachen UML im Entwurf Seite 54  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 UML zum logischen Detailentwurf Seite 55 Analyse-Modell Entwurfs-Modell Notation: UML Notation: UML Objekte: Fachgegenstände Objekte: Softwareeinheiten Klassen: Fachbegriffe Klassen: Schemata Vererbung: Begriffsstruktur Vererbung: Programmableitung Annahme perfekter Erfüllung konkreter Technologie Rahmenbedingungen Funktionale Essenz Gesamtstruktur des Systems Völlig projektspezifisch Ähnlichkeiten zwischen verwandten Projekten Grobe Strukturskizze Genaue Strukturdefinition Mehr Struktur & mehr Details
    • Prof. Dr. B. Rumpe Lehrstuhl für Software Engineering RWTH Aachen Pakete und Subsysteme Seite 56 • UML: – Pakete als "Ordner" – "Subsystem": Paket zur Realisierung einer Einheit der Architektur Benutzungs- • Java-Sprachkonstrukt: package Schnittstelle Fachliches <<use>> Modell Terminkalender Termin Besprechungsraum Persönlicher Teambesprechung Teammitglied Termin <<use>> Daten- Aufruf- & Nutzungs- Verwaltung Beziehung
    • Prof. Dr. B. Rumpe Lehrstuhl für Software Engineering RWTH Aachen Sichtbarkeit Seite 57 Sichtbarkeits-Symbol UML + # – Java public protected private (default) Sichtbar für: Gleiche Klasse ja ja ja ja Andere Klasse, gleiches Paket ja ja / nein* nein ja Andere Klasse, anderes Paket ja nein nein nein Unterklasse, gleiches Paket ja ja nein ja Unterklasse, anderes Paket ja ja nein nein * In UML und C++ “nein”, in Java “ja”.
    • Prof. Dr. B. Rumpe Lehrstuhl für Software Engineering RWTH Aachen Qualifizierte Assoziation Seite 58  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: 0..1 K1 a K2 als Detaillierung von: 0..* K1 K2 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 Qualifizierte Assoziation: Beispiel (1) Seite 59 Termin {abstract} titel beginn dauer verschieben() {abstract} Besprechungsraum Teambesprechung raumNr themen 0..* 0..1 kapazität raumFestlegen() reservieren() Veranstal- freigeben() einladen() tungsort freienRaumSuchen() absagen() verschieben() istFrei() Raum12.istFrei(start=04.05.02 10:00, dauer=60min); führt zu einer Suche über alle assoziierten Teambesprechungen !
    • Prof. Dr. B. Rumpe Lehrstuhl für Software Engineering RWTH Aachen Qualifizierte Assoziation: Beispiel (2) Seite 60 Termin {abstract} titel Indizierter Zugriff beginn (Qualifikation) dauer verschieben() {abstract} kleinere Multiplizität Besprechungsraum Teambesprechung raumNr themen 0..1 0..1 kapazität raumFestlegen() beginn reservieren() Veranstal- freigeben() einladen() tungsort absagen() freienRaumSuchen() verschieben() istFrei() wie bisher Raum12.istFrei(start=04.05.02 10:00, dauer=60min); kann direkt nach Datum abfragen, ob eine Assoziation besteht
    • Prof. Dr. B. Rumpe Lehrstuhl für Software Engineering RWTH Aachen Realisierung einer qualifizierten Assoziation Seite 61 04.05.02 09:00 10.05.02 10:00 r12: Besprechungsraum 10.05.02 11:00 10.05.02 12:00 raumNr = "r12" 11.05.02 09:00 kapazität = 20 12.05.02 15:00 12.05.02 17:00 Direktzugriff erfolgt z.B. durch: Teambesprechungs- Hashfunktion Objekte (Berechnung des Indexwerts aus gegebenem Datum) Sortierte Baumstruktur
    • Prof. Dr. B. Rumpe Lehrstuhl für Software Engineering RWTH Aachen Geordnete und sortierte Assoziation Seite 62 0..* Teilnahme 0..* Teammitglied Teambesprechung {ordered}  {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: 0..* 0..* Teammitglied Teambesprechung Teilnehmer Besprechungen {sorted} {sorted} {key=name} {key=beginn} {order=ascending} {order = ascending}
    • Prof. Dr. B. Rumpe Lehrstuhl für Software Engineering RWTH Aachen Verwaltungsklassen Seite 63 Termin Raumverwaltung {abstract} titel – einzigeInstanz beginn freienRaumSuchen() dauer verschieben() {abstract} 1 Bestand * {sorted} {key= kapazität} Teambesprechung themen Besprechungsraum 0..1 0..1 raumFestlegen() beginn raumNr einladen() Veranstal- kapazität absagen() tungsort reservieren() verschieben() freigeben() istFrei() freienRaumSuchen()
    • Prof. Dr. B. Rumpe Lehrstuhl für Software Engineering RWTH Aachen Abgeleitete (redundante) Elemente Seite 64  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: Teambesprechung * Leitung 1 Teammitglied / teilnehmeranzahl / leiter name ... * Teilnahme 2..* {leiter = Leitung.name} {teilnehmeranzahl = Teilnahme->size} Ableitung kann formuliert werden mit der Object Constraint Language OCL, ein weiterer Teil der UML.
    • Prof. Dr. B. Rumpe Lehrstuhl für Software Engineering RWTH Aachen Parameter und Datentypen für Operationen Seite 65  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 Spezifikation von Operationen Seite 66  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 Navigationsrichtung von Assoziationen Seite 67  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: Teambesprechung * leitet Teammitglied themen 1 Name raumFestlegen() Abteilung einladen() Teilnahme absagen() terminBestätigen() * 2..* verschieben()
    • Prof. Dr. B. Rumpe Lehrstuhl für Software Engineering RWTH Aachen Schnittstellen Seite 68  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: Java: <<interface>> interface XY { XY int f (int x); } f (x: int): int "implementiert" class XYImpl implements XY { public int f (int x) { ... hier Rumpf von f ... XYImpl } ... f (x: int): int }
    • Prof. Dr. B. Rumpe Lehrstuhl für Software Engineering RWTH Aachen Einfache Vererbung durch Schnittstellen Seite 69 Termin <<interface>> Hausveranstaltung einladen() absagen() Team- besprechung Vortrag einladen() einladen() absagen() absagen() Hinweis: “lollipop”-Notation für Schnittstellen ist weit verbreitet und in UML ebenfalls zulässig (und gleichwertig): Team- Haus- besprechung veranstaltung
    • Prof. Dr. B. Rumpe Lehrstuhl für Software Engineering RWTH Aachen Schnittstellen und abstrakte Klassen Seite 70 Abstrakte Klasse Schnittstelle Enthält Attribute Enthält nur Operationen und Operationen (und ggf. Konstante) Kann Default-Verhalten Kann kein Default-Verhalten festlegen festlegen Default-Verhalten kann in Unterklassen müssen Unterklassen redefiniert Verhalten definieren werden Java: Unterklasse kann nur Java: Eine Klasse kann von einer Klasse erben mehrere Schnittstellen implementieren Schnittstelle ist eine spezielle Sicht auf eine Klasse
    • Prof. Dr. B. Rumpe Lehrstuhl für Software Engineering Zusammenfassung: RWTH Aachen Seite 71 UML-Klassenmodelle in Analyse und Entwurf Analyse-Modell Entwurfs-Modell Skizze: Teilweise unvollständig Vollständige Angabe aller in Attributen und Operationen Attribute und Operationen Datentypen und Parameter Vollständige Angabe von können noch fehlen Datentypen und Parametern Noch kaum Bezug zur Auf Umsetzung in gewählter Realisierungssprache Programmiersprache bezogen Keine Überlegungen zur Navigationsangaben, Qualifikation, Realisierung von Assoziationen Ordnung, Verwaltungsklassen Entscheidung über Datenstrukturen Vorbereitung zur Anbindung von Benutzungsoberfläche und Datenhaltung an fachlichen Kern