entwurf von softwaresystemen - uni-marburg.de · - jeder modul als überschaubare einheit von einer...

Entwurf von Softwaresystemen

25. November 2014

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?


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?


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


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


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


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


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


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


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


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


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


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


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?


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


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


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"


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


Beispiel: Analysiertes Datenmodell


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


Beispiel: Entwurfsmodell


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


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


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?


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


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


- 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


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)


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)


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


Komponentenidentifizierung durch Anwendungsfälle

<<include>>

<<include>>

<<include>>


Drei-Schichten-Architektur mit Komponenten

Logik

Präsentation

Datenhaltung

Logik

Präsentation

Logik

Präsentation

Lagerhaltung Kundenverwaltung Bestellungssystem


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


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.


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.


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


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

entwurf von softwaresystemen - uni-marburg.de · - jeder modul als überschaubare einheit von einer...

Documents