entwurf von softwaresystemen - uni-marburg.de · - jeder modul als überschaubare einheit von einer...
Post on 06-May-2019
216 Views
Preview:
TRANSCRIPT
Taentzer Einführung in die Softwaretechnik 188
Überblick Wie entwirft man ein Softwaresystem?
Anforderungen an den Entwurf Lösungsprinzipien
Wie wird das Analysemodell weiterverwendet? Optimierung, Präzisierung und Erweiterung des Analysemodells
hinsichtlich ausgewählter Technologien Welche grundlegenden Systemarchitekturen gibt es?
Schichtenmodelle, Komponenten, Verteilung Wie entwirft man große Softwaresysteme?
Was sind Komponenten und wie identifiziert man sie? typische komponentenbasierte Systemarchitekturen
Pakete – Komponenten – Frameworks - Bibliotheken: Was ist was? Wo sind die Unterschiede?
Taentzer Einführung in die Softwaretechnik 189
Analysemodell: Fachkonzept (= Aufgabendefinition) enthält: - Klassen- bzw. Datenmodell- Verhaltensmodelle- Interaktionsszenarien- nichtfunktionale Anforderungen
Ziel:Technischer Entwurf, bestehend aus:- Analyse technischer Varianten- Entwurf der Systemarchitektur- Entwurf von Komponenten- Entwurf der Datenbasis- Entwurf der Anwendungslogik- Entwurf der Benutzerschnittstelle - Entwurf von System- und Unit-Tests
Analyse und Entwurf
Was soll konstruiert werden?
Wie soll konstruiert werden?
Taentzer Einführung in die Softwaretechnik 190
Entwurfsprinzipien
Abstraktion: Trennung von Anwendungs- und technischen Ebenen Modularität: Unterteilung der Software in mehrere weitgehend
unabhängig bearbeitbare Teile Kohäsion: Identifikation gut abgrenzbarer Problembereiche Koppelung: Entwurf der Systemteile so unabhängig wie möglich Geheimnisprinzip: Kapselung von Daten durch Zugriffsfunktionen Schrittweise Verfeinerung: Entwurf vom Groben zum Feinen: Entwurf
der Architektur, Systeme, Komponenten, Datenstrukturen und Algorithmen
Taentzer Einführung in die Softwaretechnik 191
Grundproblem: Größere Programmier-aufgaben führen zu sehr umfangreichen Programmen, die schwer überschaubar und handhabbar sind. Große und komplexe Aufgaben sollten auf mehrere Entwickler verteilt werden.
Lösungsidee: Zerlegung des gegebenen Problems in kleinere, überschaubare Teilprobleme ("Divide and conquer")
Rekursive Zerlegung eines Problems in Teilprobleme.
• Offene Frage: Was wird verfeinert?
• Mögliche Antworten:- Funktionale Verfeinerung, z.B. durch Herausziehen von (Sub-)Operationen- Daten-Verfeinerung, z.B. durch Definition von Teil-Datenstrukturen
Schrittweise Verfeinerung
Taentzer Einführung in die Softwaretechnik 192
A und B seien zwei Bausteine, mit (möglicherweise) verschiedenen Bearbeitern X und Y.
A und B haben eine Schnittstelle miteinander, d.h. sie setzen Kenntnisse über Teile des jeweils anderen Bausteins voraus.
Beispiel:
A = Modul zur AdressverwaltungB = Dienstleistungs-Modul, der u.a. ein
Sortierprogramm sort zur Verfügung stellt.A soll B benutzen, d.h. es werden Kenntnisse
über B, insb. über sort benötigt; A und B haben also eine gemeinsame Schnittstelle.
A
B
benutzt
Geheimnisprinzip und Datenabstraktion
Taentzer Einführung in die Softwaretechnik 193
Geheimnisprinzip
Das Geheimnisprinzip ("information hiding principle") besagt: Jede Schnittstellendefinition soll minimal, d.h. auf das unbedingt
Notwendige beschränkt, sein.
Im Beispiel: A ruft B auf, d.h. A benötigt Kenntnisse über . den Namen der Sortieroperation. die Parameterzahl der Sortieroperation. die Typen der Parameter . (ggf.) weitere wissenswerte Einzelheiten zu B.
A benötigt aber keine Kenntnisse über dieRealisierung von B, z.B. darüber, welches Sortierverfahren gewählt wird.
A
B
Schnitt-stelle benutzt
Taentzer Einführung in die Softwaretechnik 194
Der einzelne Entwickler wird nicht mit Detailwissen über die Module der anderen Entwickler überfrachtet.
Wissen über Baustein-interne Details kann außerhalb nicht verwendet werden. Daher bleibt die übrige Entwicklung von solchen Details unabhängig.
Bausteine können unabhängig entwickelt, getestet und ggf. später problemlos revidiert werden.
Spezifikation = sichtbarer Teil: Menge von Vereinbarungen, die für die Benutzung des Bausteines (durch andere Bausteine) notwendig sind
Konstruktion = unsichtbarer Teil: Menge der Vereinbarungen (und Anweisungen), die für die Benutzung des Bausteins (durch andere Bausteine) nicht benötigt werden.
sichtbarer Teil (Spezifikation, Schnittstelle)
unsichtbarer Teil
(Konstruktion, privat)
Vorteile des Geheimnisprinzips
Taentzer Einführung in die Softwaretechnik 195
Das Prinzip der Datenabstraktion (engl. data abstraction oder data encapsulation) setzt das Geheimnisprinzip konsequent fort.Es besagt:
Jeder Baustein ist (zunächst) unabhängig von der Datenstruktur alleindurch die Angabe seiner (Zugriffs-) Operationen zu spezifizieren. Das heißt: Datenstrukturen sind derartig in Bausteine zu verpacken (zu
"verkapseln"), dass auf sie von anderen Bausteinen nur über Operationen zugegriffen werden darf.
Datenabstraktion
Taentzer Einführung in die Softwaretechnik 196
Ein Paket ist eine Zusammenfassung von Modellelementen (meist: Klassen). Pakete können selbst andere untergeordnete Pakete und weitere Modellelemente enthalten.
Jedes Element kann nur in höchstens einem Paket enthalten sein - damit ist die Paketstruktur ein Baum.
Pakete können jedoch untereinander in Beziehung (z.B. der Art <<import>> und <<use>> (<<access>>)) stehen.
Editor
Controller
DiagramElements
GraphicsCore
DomainElements
<<import>>
<<import>>
<<import>>
<<use>>
<<use>>
Entwurfseinheiten in UML: Pakete
Paket-bezeichner
Paket-bezeichner
Paketinhalt
Taentzer Einführung in die Softwaretechnik 197
Pakete definieren Namensräume
Modellelemente außerhalb eines Pakets sehen Elemente innerhalb eines Pakets nur, wenn ihre Sichtbarkeit public ist.
Modellelemente mit der Sichtbarkeit private und package sind nicht nach außen sichtbar.
packagepublic
Taentzer Einführung in die Softwaretechnik 198
Entwurf von Komponenten
Eine Komponente ist ein Systemmodul, das eine Menge von Schnittstellen bereitstellt und diese realisiert.
Komponenten lassen sich durch Pakete beschreiben.
Typischer Aufbau einer Komponente: Komponentenpaket enthält öffentliche Schnitt-
stellen (als Klassen oder Pakete) und private Implementierungspakete
Taentzer Einführung in die Softwaretechnik 199
Analyse technischer Varianten Merkmale, die die Auswahl beeinflussen:
Verfügbarkeit von Technologien Leistungsmerkmale von verfügbaren Technologien Anpassbarkeit an das zu entwickelnde System nichtfunktionale Anforderungen der Kunden
Szenario: Auswahl einer Datenbanklösung (DB)
Nutzung einer existierenden DB:
nichtfunktionale Anforderung
Schema kann von analysiertem Datenmodell abweichen → Daten-abbildung
Erstellung einer neuen DB: Auswahl einer DB-Technologie Gestaltungsfreiheit des Schemas Daten liegen ev. in einem anderen Format vor → Datenmigration
Taentzer Einführung in die Softwaretechnik 200
Softwarearchitektur
Eine Softwarearchitektur umfasst die Beschreibung von Elementen, aus denen das System gebaut werden soll sowie Interaktionen zwischen diesen Elementen.
Zu klärende Fragen bzgl. einer Softwarearchitektur: Was gehört zur Software und was liegt außerhalb? Welche Systemarchitektur liegt zugrunde? Welches Softwarearchitekturmodell wird verwendet? Welche Teile bestehen bereits und welche werden neu
entwickelt? Wie soll die Kommunikation gestaltet sein?
Taentzer Einführung in die Softwaretechnik 201
Zwei-Schichten-Architektur
Datenhaltung: in Dateien in einer relationalen Datenbank
Applikation: Anwendungslogik und
Benutzerschnittstelle Eigenschaften:
direkter Datenzugriff nicht notwendigerweise objekt-
orientierte Sicht auf die Daten meist keine separierte
Anwendungslogik
Datenhaltung
Applikation
Taentzer Einführung in die Softwaretechnik 202
Drei-Schichten-Architektur
Anwendungslogik und Präsentation werden getrennt.
Eigenschaften: Geheimhaltungsprinzip wird
angewandt, da die Logik von der Präsentation getrennt ist.
Verschiedene Präsentationen für verschiedene Nutzer und Oberflächen sind möglich.
Logik
Präsentation
Datenhaltung
Taentzer Einführung in die Softwaretechnik 203
Beispiel: Architektur von Java-basierten Webanwendungen
Präsentationsschicht:Struts / JSF zur Definition von Webseiten
Anwendungslogik: dienstorientiert: Enterprise Java Beans/ Spring Framework zur Definition von Diensten
Datenzugriffsschicht:Hibernate zur Definition der O/R-Abbildung
Datenbankschicht:relationale Datenbank, z.B. MySQL
aus "androMDA.org – Application Architecture"
Taentzer Einführung in die Softwaretechnik 204
Optimierung und Erweiterung des Analysemodells
Identifikation von Komponenten: Entwurf einer Paketstruktur Entwurf von Schnittstellen
Datenmodell: Vervollständigung Optimierung der Navigation Optimierung der Vererbung
Verhaltensmodelle: Verwendung von definierten
Klassen und Operationen Verfeinerung von Abläufen Verwendung von Kontroll-
strukturen
Taentzer Einführung in die Softwaretechnik 206
Entwurf des DatenmodellsWeiterentwicklung des Analysemodells: Kapselung von Attributen:
Sichtbarkeit eines Attributs is „privat“ zusätzlich: zwei öffentliche Methoden, mit
denen das Attribute gelesen und geschrieben werden kann (Getter und Setter)
Herausziehen neuer Klassen z.B.: eigene Adress-Klasse
abgeleitete Attribute und Assoziationen z.B. alter lässt sich von geburtstag
ableiten weitere Generalisierung Vervollständigung der
Zugriffsoperationen: create, update, read, delete-Operationen (CRUD)
optimierte Navigation
Person
+ getName(): String+ setName(in n: String): void
-name: String-geburtstag: Date- <<derived>> alter: int
Adresse
-straße: String-plz: int-ort: String
Taentzer Einführung in die Softwaretechnik 208
Aktivitätsdiagramm zur Operation Produkt::
wareneingangBearbeiten
[alleEinträge bearbeitetoder Wartekartei leer]
[Eintrag betrifftProdukt nicht]
[aktueller Bestand < bestellte Menge]
[aktueller Bestand >= bestellte Menge]
[Eintrag betrifftProdukt]
Eintrag in Warte-kartei löschen
Teil des Analysemodells
Taentzer Einführung in die Softwaretechnik 209
Beispiel: Produkt.wareneingangBearbeiten()
Entwurf der Anwendungslogik:Verfeinerung der Verhaltens-modelle: Präzisierung der Aktionen
durch Operationsaufrufe Verfeinerung von Aktionen
durch mehrere Stärkerer Einsatz von
Kontrollstrukturen Spezifikation beteiligter
Objekte
Taentzer Einführung in die Softwaretechnik 210
Große Softwaresysteme sind sehr komplex und sollten daher in handhabbare Bausteine (Module) zerlegt werden. (schrittweise Verfeinerung)
Im technischen Entwurf wird das System in Module (z.B. Komponentenund Pakete) zerlegt und deren Schnittstellen werden spezifiziert. Dieser Vorgang heißt Modularisierung.
Je geringer die Abhängigkeiten zweier Module voneinander sind, desto leichter können sie separat entwickelt, getestet, verändert oder ausge-tauscht werden. Daher versucht man, die Kopplung (= gegenseitige Abhängigkeiten) zwischen den Modulen möglichst gering zu halten.
Um die Zugriffsmöglichkeiten der Module untereinander einzuschränken und gewissen Regeln zu unterwerfen, können Schichten gebildet werden.
Wiederverwendbare Module früherer Entwicklungen werden identifiziert und in ggf. angepasster Form in den Entwurf übernommen.
Wozu Modularisierung?
Taentzer Einführung in die Softwaretechnik 211
Modul: Software-Baustein überschaubarer Größe und Komplexität.Modularisierung: Vorgang des Zerlegens eines Softwaresystems (genauer: dessen
Problemstellung) in Module.Komponente: wiederverwendbares und ausführbares Modul mit expliziter Schnittstelle
und Abhängigkeiten, das mit anderen Komponenten verknüpft werden kann.Paket: Modul, das mehrere zusammenhängende Klassen enthält
Komponente K
Pakete X, Y
Modul: Verallgemeinerung für System-Teileinheiten: System (selbst), Komponente, Paket, Klasse
Teileinheiten eines Softwaresystems
Taentzer Einführung in die Softwaretechnik 212
Bei der Modularisierung geht es darum, eine Problemstellung für ein System so inTeilaufgaben für Bausteine (Module) zu zerlegen, dass- jeder Modul als überschaubare Einheit von einer kleinen Gruppe von Entwicklern
bearbeitet werden kann,- Module unabhängig voneinander entwickelt, getestet und geändert werden können, - Module möglichst wenige und kleine Schnittstellen miteinander haben,- logisch zusammengehörige Module zu größeren Modulen zusammengefasst werden
können, - Module soweit wie möglich wiederverwendet werden können,- Module, die Schnittstellen miteinander haben, zu Test- und Probezwecken integriert
werden können.
Ziele der Modularisierung
Taentzer Einführung in die Softwaretechnik 213
- Die gegebene Funktionalität schrittweise in immer kleinere Einheiten (Bausteine) aufgliedern,
- in einem Modul eng zusammengehörige Funktionen und Daten zusammenfassen,
- Module so bilden, dass sie möglichst schmale Schnitt-stellen miteinander haben, sich möglichst unabhängig voneinander entwickeln und testen lassen,
- Datenbestände und zugehörige Zugriffs- und Hilfsfunktionen in Modulen zusammenfassen,
- mehrfach benötigte Funktionalität auslagern und in eigenen Modulen zur Verfügung stellen,
Um die o.g. Ziele zu erreichen, bieten sich folgende Lösungsansätze an:
Top Down Entwurf
hohe Kohäsion
geringe Kopplung
Daten-Kapselung
funktionale Faktorisierung
Modularisierung: Lösungsansätze
Taentzer Einführung in die Softwaretechnik 214
Kohäsion (Innerer Zusammenhang)
stark / schwachzusammenhängender
Baustein
Ein Baustein heißt stark zusammenhängend, wenn alle seine Elemente (z. B. Daten-deklarationen, Anweisungen) in enger innerer Verbindung untereinander stehen (engl.: cohesion) .
Als Indikatoren für die Feststellung des Zusammenhangs kommen z.B. in Frage: logische Zuordnung (z. B. ähnliche Funktionalität) prozedurale Abhängigkeit (z. B. Aufruf) Kommunikationsbeziehung (etwa über die gleichen Ein- oder Ausgabedaten) sequentiell verknüpft (aufeinander folgend) funktionale Abhängigkeit (durch Funktionen miteinander verbunden) Datenabhängigkeit (auf die gleichen Daten zugreifend)
Taentzer Einführung in die Softwaretechnik 215
Mehrere Module heißen lose gekoppelt, wenn sie nur wenige (äußere) Verbindungen (z. B. Aufruf-Schnittstellen) untereinander haben (engl.: loosecoupling).
losegekoppelte
starkgekoppelte
Module
Entwurfsregel: Anzustreben sind ein möglichst starker innererZusammenhang und eine möglichst lose Kopplung der Bausteine.
Kopplung (äußerer Zusammenhang)
Taentzer Einführung in die Softwaretechnik 216
Beispiel: Notfalleinsatz-System Lösung 1: Datenbank ist stark mit den
Anwendungskomponenten Karten-verwaltung, Betriebsmittelverwaltung und Vorfallverwaltung gekoppelt. Jede Änderung an DB-Zugriffen wirkt sich auf alle Verwaltungskomponenten aus. Lösung 2: Datenbank ist durch zwi-
schengeschaltete (Wrapper-)* Komponente DB-Zugriff von den Anwendungskomponenten ent-koppelt. Änderungen bei Datenbank-Zugriffen wirken sich nur auf die neue Komponente aus. Diese stellt den anderen Komponenten eine stabile Schnittstelle zur Verfügung.
Datenbank
Karten-verwaltung
Betriebsmittel-verwaltung Vorfall-
verwaltung
Lösung 1
DB-Zugriff
Karten-verwaltung
Betriebsmittel-verwaltung Vorfall-
verwaltung
Datenbank Lösung 2* engl.: to wrap: einpacken
Beispiel zur Entkoppelung
Taentzer Einführung in die Softwaretechnik 217
Komponentenidentifizierung durch Anwendungsfälle
<<include>>
<<include>>
<<include>>
Taentzer Einführung in die Softwaretechnik 218
Drei-Schichten-Architektur mit Komponenten
Logik
Präsentation
Datenhaltung
Logik
Präsentation
Logik
Präsentation
Lagerhaltung Kundenverwaltung Bestellungssystem
Taentzer Einführung in die Softwaretechnik 219
Komponenten mit verteilter Datenhaltung
Jede Komponente verwaltet ihre Daten.
Verschiedene Komponenten können sich nicht über eine gemeinsame Datenbasis synchronisieren.
Eigenschaften: stärkere Geheimhaltung
eigener Daten eventuell redundante
Datenhaltung schwierigere Konsistenz-
haltung der Daten Komponentenidentifizierung
durch Datenzuordnung
Logik
Präsentation
Datenhaltung
Logik
Präsentation
Datenhaltungnutzt
Taentzer Einführung in die Softwaretechnik 221
Client-Server-Systeme
Ein Client/Server-System besteht aus mehreren über einem Netzwerk zusammenarbeitenden Anwendungen. Jede dieser Anwendungen arbeitet als Server oder als Client: Server: Anwendung, die ein oder mehrere Dienste bereitstellt. Sie
hat meist eine eigene Datenhaltung. Client: Anwendung, die ein oder mehrere Dienste nutzt.
Beispiele: Webanwendungen: Browser sind in der Rolle der Klienten und
nutzen Dienste von Webservern Datei-Server stellen Dienste zur Verwaltung von Dateien bereit,
die auch von entfernten Rechnern genutzt werden können.
Taentzer Einführung in die Softwaretechnik 222
Peer-to-Peer-Systeme Ein Peer-to-Peer-System besteht aus mehreren über einem Netzwerk
zusammenarbeitenden Anwendungen, die alle ähnliche Fähigkeiten und Verantwortungen haben.
Hier können Dienstanbieter auch Dienstnutzer sein und umgekehrt. Beispiele:
Telefonsysteme: Eine Telefonanwendung bietet an, angerufen werden zu können, kann selbst aber auch andere Telefonanwendungen anrufen. Entfernte Anwendungen finden sich durch die Nutzung einer zentralen Repository-Anwendung
Musiktauschbörsen: Einzelne Rechner können sowohl MP3-Dateien anbieten (Server) als auch empfangen (Client). Rechner werden nach MP3-Dateien durchsucht und Ergebnisse werden an andere Rechner weitergegeben. Einstieg in das Netzwerk durch eine vorgegebene Liste von Kontaktknoten.
Taentzer Einführung in die Softwaretechnik 223
Programmbibliotheken und Frameworks
Eine Bibliothek ist eine Sammlung von Klassen, die einen bestimmten Funktionalitätsbereich abdecken.
Anders als Komponenten sind Bibliotheken nicht aus sich heraus lauffähig.
Komponenten können mit Hilfe von Bibliotheken leichter erstellt werden, da die Bibliotheken schon grundlegende Funktionalität bereitstellen, die eventuell auch erweitert werden kann.
Erweiterungen durch Vererbung von Schnittstellen oder abstrakten Klassen
Ein Framework ist ein Programm-rahmen, der von den Entwicklern mit Komponenten gefüllt werden muss. D.h. ein Framework benutzt Komponenten.
Beispiele: Java Collection Framework:
Klassenbibliothek, um mit Mengen, Listen und Abbildungen von Objekten leichter arbeiten zu können
Swing:Framework und Klassenbibliothek zur Erstellung von graphischen Benutzeroberflächen
Taentzer Einführung in die Softwaretechnik 224
Zusammenfassung Grundlegende Entwurfsprinzipien:
Abstraktion, Modularität, Geheimnisprinzip, schrittweise Verfeinerung Entwurfsmodell:
Präzisierung und Optimierung des Analysemodells Was sind Komponenten und wie entwirft man sie?
prinzipieller Aufbau von Komponenten Identifizierung von Komponenten
Typische komponentenbasierte Systemarchitekturen: Schichtenmodelle, Client-Server-Systeme, Peer-to-Peer-Systeme Komponenten: wiederverwendbare und ausführbare Module Bibliotheken: Klassensammlungen für einen Funktionalitätsbereich Frameworks: Softwarerahmen, die durch Komponenten gefüllt werden
top related