5. Design: Architektur-Grundlagen Softwaretechnik (CNAM)€¦ · Neue CORBA-Version Fachliche...

1 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

Softwaretechnik

(CNAM)

5. Design:

Architektur-Grundlagen

Wintersemester 2011 / 2012

Prof. Dr. Bernhard Humm

Hochschule Darmstadt, FB Informatik


Einordnung in den gesamten Kurs

1. Einführung

2. Analyse: Anforderungen und Anwendungsfälle

3. Analyse: Datenmodell

4. Analyse: Dialoge

5. Design: Architektur-Grundlagen

6. Design: Referenzarchitektur betriebliche Informationssysteme

7. Design: Querschnittsthemen und Muster

8. Programmierung

9. Test, Einführung, Qualitätsmanagement

10. Projektmanagement

11. Vorgehensmodelle

Motivation

Architektur-Sichten

Software-Kategorien

Komponenten & Schnittstellen

Regeln für den Komponentenschnitt

Spezifikation von Schnittstellen

Literatur, Kontrollfragen

Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

Motivation

Agenda


Design: Die Königsdisziplin des Software Engineering

Analyse WAS?

Design WIE?


Architektur: Verteidigen

Quelle: www.musoft.org


Architektur: Beeindrucken



Architektur: Verkehrsfluss



Architektur: Erweitern



Architektur: Mobilität



Architektur: Grundriss


Architektur: Aufriss


Architektur: Elektriker-Sicht


Architektur: Sanitär-Installateur-Sicht


Softwaresysteme gehören zu den komplexesten

Dingen, die Menschen je gemacht haben…


… und brauchen daher eine gute Architektur

Wo ist hier die Architektur?

Übersicht

Quelle: Erich Gamma, "100 OO Frameworks, Pitfalls and Lessons Learned", 1997

Übersicht


Wichtigste Aufgaben der Design-Phase

Fachliches (Anwendungs-)Design

– Zerlegung (Dekomposition) des Systems in Komponenten (z.B. in Vertragsverwaltung, Kundenverwaltung …)

– Festlegung der Schnittstellen (Operationen)

Technisches Design (parallel zur Analysephase durchführbar)

– Festlegung der technischen Infrastruktur (GUI-Toolkit, Datenbanksystem, App. Server, Frameworks, Hardware, …)

– Festlegung der Entwicklungsumgebung (SEU) (Programmiersprache, Umgebung, Build-Tool, Bugtracker, …)

– Festlegung der Grobstruktur des Systems (Schichten, Tiers, Standard-Architektur, …)

– Festlegung der (Programmier-)richtlinien (Coding Conventions, Verzeichnisstruktur, Nutzungskonzepte für Tools, …)

Übersicht

Motivation

Architektur-Sichten

Software-Kategorien






Architektur-Sichten

Agenda


TI-Architektur (Architektur der

technischen Infrastruktur)

beschreibt die

physischen Geräte

(Rechner, Netzleitung,

etc.), die darauf

installierte

Systemsoftware

(Betriebssystem,

Application-Server, etc.),

das Zusammenspiel von

Hardware und

Systemsoftware sowie

die verwendeten

Programmiersprachen.

Architektur-

Sichten

T-Architektur (Technikarchitektur)

verbindet A- und TI-

Architektur;

beschreibt die „virtuelle

Maschine“, auf der die

mit der A-Architektur

entworfene Software

läuft.

A-Architektur

(fachliche

Anwendungsarchitektur)

frei von technischen,

produktbezogenen

Sachzwängen

wird für jedes Projekt

neu entwickelt

strukturiert die Software

aus der Sicht der

Anwendung

enthält fachliche Klassen

wie „Mitarbeiter“ oder

„Konto“.


Beispiel-Projekt für Logistik-Dienstleister

Kunde: großer Logistik-Dienstleister

Projekt: Auftragsmanagement

Volumen Stufe 1: > 30 BJ

Zeit: April 2003 – Januar 2004


Beispiel für A-Architektur

ESI-Frontend

SA-Backend

SA-

Front-

end

T&T-Verwaltung

ESi-Backend

Disposition

Auftragsverwalter

Auftragsüberwachung

Auftragsverwalter

Benutzerverwaltung

Stammdatenverwaltung

Auftragsabrechnung

NVE-

Drucker

SA-

Batch-

Scanner

SA-

Online-

Scanner

Auftragsüberwachung Disposition

Frontend

Backend

Nummerverwaltung

Konvertierung

Annahme/Importer

Auftragsverwaltung

Informationsanforderung

Master Applikation

Internes Informations-

service und Clearing

Portal

Benutzerverwaltung

Informationsservice und Clearing

Benutzerverwaltung


Benutzerverwaltung


Produktions-

auftragsverwaltung

Clients

Inform.service u. Clearing

Informationsservice und Clearing

NVE-

Drucker

NVE-

Drucker

Nummernverwaltung Stammdatenverwaltung

Querschnitt

Auftragsverwaltung Produktion Entgeltsicherung Tracking & Tracing


Beispiel für

T-Architektur

Clients nutzen Services zur

Kommunikation mit den

Applikationen

Die publizierten und genutzten

Services werden mit Hilfe von

Adaptern und Proxies von den

Use-Cases entkoppelt

Strikte Trennung von fachlichen

und technischen Programmteilen

Anwendungskern kann

wiederverwendet werden (z.B. im

Offline-Client)


Beispiel für TI-Architektur

PC

z/OS

DB2

USS

CICS/TSO

Web-Browser

IBM-Webserver

Java-Applet

http

Anwendungskern

Bridge (GWAPI)

EXCI

Nachbarsysteme

MQSeries

IDMS

Nachbarsysteme

AKS-Shell

CICS

Nachbarsysteme

CICS-DPL

CICS/UNIX

Nachbarsysteme

TCP/IP


A-Architektur

A-Architektur grob

Anforderungen

Teilsysteme

Nachbarsysteme

Spezifikation

Anwendungsfälle

Entitätenmodell

Dialogspezifikation

etc.

Teilsysteme,

Komponenten,

Schnittstellen,

Klassen/Module

Pakete, DLLs,

Programmiersprachendateien

Programmierung

der Anwendung

T-Architektur

Schichten

Komponenten

Klassen/Module

Pakete, DLLs,

Programmiersprachendateien

Programmierung von

Basiskomponenten

(0/T-Software)

TI-Architektur

Auswahl einer geeigneten

Technologie

logische Rechner,

Netze, Trägersysteme

technische Produkte

Ze

it

Referenzarchitektur

Entwicklung der Architektur-Sichten im Projekt-Ablauf

Motivation

Architektur-Sichten

Software-Kategorien






Software-Kategorien

Agenda


Idee der Softwarekategorien

Software, die sich unterschiedlich schnell ändert, wird in unterschiedliche Module aufgeteilt.

David Parnas, 1972


Beispiel Gehaltssoftware

IBM AS/400

Neues Entwicklungspfade-

und Entlohnungsmodell

Neue Beitragssätze zur

Sozialvericherung

Neue CORBA-Version

Fachliche Änderungen technische Änderungen


Softwarekategorien:

Trenne Zuständigkeiten

Kategorien Das heißt…

unabhängig von Anwendung und Technik;

ideal wiederverwendbar;

Beispiel: Klassenbibliothek für Strings und Behälter

bestimmt durch die fachliche Anwendung;

unabhängig von Technik;

Meist der größte Teil des Systems;

Beispiel: „Mitarbeiter“, „Buchung“

unabhängig von der fachlichen Anwendung;

wiederverwendbar bei Einsatz derselben technischen

Komponente; Beispiel: Zugriffsschicht auf Datenbank

reine Transformation;

Beispiel: Bildschirmformat in XML

befasst sich mit Technik und Anwendung;

schwer zu warten;

widersetzt sich Änderungen;

Wiederverwendung = 6er im Lotto!

0-Software

A-Software

T-Software

R-Software

AT-Software

C-Software Konfiguration:

Bringt die verschiedenen Kategorien zusammen (main)

Kombinationen A + 0 = A

T + 0 = T A + T = AT

Quelle: J. Siedersleben: „Moderne Softwarearchitektur“


Software-Kategorien als Maß für Softwarequalität

... Der Anteil an AT-Software ist antiproportional zu der Qualität eines Software-

Systems!

• Wiederverwend-

barkeit der

technischen

Komponenten

• Wartbarkeit

• Fehlerfreiheit

• Stabile

Komponenten

Anteil von

AT-Software

Motivation

Architektur-Sichten

Software-Kategorien







Agenda


Komponenten-Orientierung am Beispiel Auto

Außensicht

(Schnittstelle)

des Fahrers:

möglichst einfach

Außensicht

(Schnittstelle)

der

Werkstatt:

möglichst einfach

Innensicht: komplex


Komponenten-Orientierung in der Software

Beispiel: Berechtigungskomponente

Berechtigungs-

kernB

Admin-

Schnittstelle

A

operative

Schnittstelle

SR‘

RACF-

AdapterDB-Zugriff

RACF

Berechtigung

GUI

Oracle

JDBCR

Berechtigungskomponente

Außensicht

(Nutzungssicht):

operative

Schnittstelle des

Anwendungs-

programmierers

(möglichst einfach)

Außensicht

(Nutzungssicht):

Schnittstelle des

Administrators

(möglichst einfach)

Innensicht: komplex


UML-Notation

cmp Komponenten & Schnittstellen

Class

Interface

Class

«interface»

Interface

Component

ProvidedInterface1 ProvidedInterface2

RequiredInterface

Schnittstelle ist Stereotyp

von Klasse. Enthält nur

Operationen, keine

Attribute

Komponente als

Stereotyp von Klasse mit

Komponentensymbol

Alternative Darstellung

der Schnittstelle als Ball

(„Lollypop“)

Angebotene Schnittstellen

Angeforderte

Schnittstelle

(Socket-

Symbol, neu

in UML 2)


Definition Komponente:

6 Merkmale

Eine Komponente

definiert ihre angebotenen Dienste. Dazu gehört insbesondere die genaue Semantik der Schnittstellen.

definiert die Abhängigkeiten von angeforderten Diensten anderer Komponenten.

versteckt die Implementierung und kann daher durch eine andere Komponente ersetzt werden, die dieselbe Schnittstelle exportiert.

ist geeignet als Einheit der Wiederverwendung.

kann andere Komponenten enthalten.

ist neben der Schnittstelle die wesentliche Einheit des Entwurfs, der Implementierung und der Planung.

Komponente k

K Impl

s1

s2

t2

t1

k importiert (benutzt)

s1 und s2

Austauschbare

Implementierung von k

k exportiert (implementiert)

t1 und t2

Was ist eine Komponente

Johannes Siedersleben


Komponente

Sichten auf eine Komponente

Nutzer

(Anwendungsentwickler

Client oder Nachbarkomponente):

operative Außensicht

Entwickler

(Anwendungsentwickler

Komponente):

Innensicht

Integrator:

Integrationssicht

(technische Konfiguration)

Betreiber (Rechenzentrum):

Außensicht Betrieb

Administrator:

Administrationssicht

(fachliche Konfiguration)


Client Komponente:

GUI,

Nachbar-Komponente,

Test-Treiber

<<uses>>

Ordering

<<uses>>

OrderingFactory

Ordering

(Anwendungsentwickler Client oder Nachbarkomponente)

gets reference to

OrderingFactory

Außensicht:

So einfach und stabil wie möglich

interface Ordering {

OrderRecord placeOrder(

String customerId, String articleId);

}

interface OrderingFactory {

Ordering getOrderingUseCase();

}

Außensicht

Application components


(Anwendungsentwickler der Komponente)

Ordering

FactoryImpl

<<creates>>

Ordering

OrderingFactory

Order

Customer

OrderManager

CustomerManager

public interface Order {

String getId();

…

}

public interface OrderManager {

Order newOrder (Customer customer

Article article);

}

OrderingImpl

public interface Customer {

String getName();

…

}

public interface CustomerManager {

Customer newCustomer (String name,

String address);

Customer findCustomerById (String id);

}

Innensicht


Innensicht: die Komponente

implementieren

Ordering


<<creates>>

<<creates>>

OrderingFactory

Ordering

Komponente Client-

Komponente

OrderingFactory orderingFactory = getOrderingFactory();

Ordering orderingUseCase = orderingFactory.getOrderingUseCase():

ClientComponent c = new ClientComponent(orderingUseCase);

Entscheidung für eine

konkrete Implementierung

und Zusammenbringen von

Schnittstelle und

Implementierung

SAP

Adapter

Ordering

Integrationssicht

OrderingFactory

Ordering



Administrationssicht

Ordering

Komponente

OrderingFactory

Ordering

Administration

setTaxValues,

configurePrices,

configureReductions,

…


Betriebssicht

Ordering

Komponente

OrderingFactory

Ordering

SystemsManagement

Systems

Management

(z.B. Tivoli)

Komponente hoch- und

herunterfahren,

Gesundheitszustand

abfragen


Schnittstellen (Interfaces) beschreiben Eigenschaften von

Komponenten aus Sicht der Benutzer

Katze

Haustier

Patient

Quelle: Roger King

class Katze implements Patient, Haustier {…}

Rückblick Grundlagen der Programmierung I


Analogie Mensch

Jeder Mensch hat viele Eigenschaften. Aber

für bestimmte Personengruppen sind nur

bestimmte Eigenschaften wichtig:

– Verkehrspolizist: Führerschein

– Arbeitgeber: Lebenslauf, Aufgaben,

Einkommen

– Bibliothek: Leihausweis

– Familie: jede Menge anderer

Eigenschaften

Eine Klasse, zum Beispiel Customer, kann

viele Eigenschaften haben. Aber für

bestimmte Collaborations sind nur

bestimmte Eigenschaften wichtig:

– Kundenverwaltung: fachliche Attribute

und Funktionen

– SortedSet: Comparable

– Client-Server Kommunikation:

Serializable


Definition Schnittstelle und Operation

Eine Schnittstelle (Interface) fasst Operationen zusammen. Sie wird spezifiziert durch:

– (1) Einen eindeutigen Namen,

– (2) Die Menge der zugehörigen Operationen

– (3) Ein Schnittstellen-Protokoll im Sinne von Reihenfolgen und Restriktionen beim Aufruf

der Operationen.

Operationen (Operations) beschreiben das Verhalten von Komponenten. Sie werden

spezifiziert durch:

– (1) Signatur: Name der Operation, Parameter und Rückgabewerte und deren Typen,

Ausnahmen

– (2) Semantik: Verhalten der Operation

– (3) Nichtfunktionale Eigenschaften: z.B. Performanz, Verfügbarkeit, Kosten etc.


Authorization

kernel B

administration

interface

A

Operational

interface

S

R'

RACF-Adapter DB Access

RACF

Authorization

GUI

Datenbank

R

Verschiedene Sichten / Schnittstellen

für unterschiedliche Nutzer

A-GUI

Komponenten und Schnittstellen

Anwendungs-

programmierer

(viele)

Administrator

Admin-Client

Entwickler

RACF-Experte RACF-Experte DB-Experte

Entwickler des

Admin-Clients


Nutzer Anbieter S

Standard-Schnittstelle

S‘ Adapter

angeforderte Schnittstelle

Wer definiert Schnittstellen?

Nutzer Anbieter S

angebotene Schnittstelle

Anbieter S

angeforderte Schnittstelle

Nutzer

z.B. JDBC

Call-back SS, z.B. Observer

z.B. SAP Adapter

Konvention für diese Vorlesung:

Verwendung des Socket-Symbols nur für angeforderte

Schnittstellen, die von der Komponente selbst definiert und

exportiert werden

Anbieter

S

angebotene Schnittstelle

Nutzer z.B. Oracle Call Interface


Beispiel: Observer Muster

Anbieter

(Observable) Nutzer

(Observer)

Observer

Observable

<<uses>>

<<implements>>

addObserver,

deleteObserver, …

Update (call-back)

Prinzip Inversion of Control (Umkehr der Abhängigkeit)

Der Anbieter (Observable) exportiert sowohl die angebotene als auch das angeforderte Schnittstelle

Obwohl Aufrufe in beide Richtungen erfolgen, ist die Abhängigkeit unidirektional und damit zyklenfrei (Observer

Observable)


Angeforderte Schnittstellen: Komponenten entkoppeln

Komponente k definiert die erwarteten Dienste mit Hilfe von Schnittstellen s1 und s2

Diese Schnittstellen, auch angeforderte Schnittstellen genannt, gehören der importierenden Komponente

Die Dienstanbieter-Komponenten h1, h2 exportieren die Schnittstellen s1‘ bzw. s2‘, welche i.d.R. nicht identisch zu s1 und s2 sind

Adapter a1, a2 bilden die angeforderten Schnittstellen auf die konkreten Schnittstellen von h1, h2 ab.

Das Komponenten-Binding erfolgt über die Konfiguration

k

s1

h1

Konfiguration

s2 h2

a1

a2

s1´

s2´ t2

t1

Das alles gehört k und das h2

und das h1

Komponenten und Schnittstellen

Motivation

Architektur-Sichten

Software-Kategorien







Agenda


Regel 1: Zusammengehörige Fachlichkeit

Kriterien:

– Geschäftslogik für unterschiedliche (Haupt-)Geschäftsprozesse soll getrennt

werden

– Geschäftslogik für unterschiedliche (Haupt-)Geschäftsobjekte soll getrennt

werden, insbesondere sollen Stamm- von Bewegungsdaten getrennt werden (

Partitionierung des Datenmodells)

– Geschäftslogik, die sich unterschiedlich häufig ändert, soll getrennt werden

Beispiele:

– Hauptbuchhaltung, Nebenbuchhaltung

– Kundenverwaltung, Auftragsverwaltung

– Vertrieb, Produktion

Komponenten sollen zusammengehörige Fachlichkeit zusammenfassen

• Gegenbeispiele:

– Host-Anwendungen,

Java-Anwendungen


Regel 2: Kategorienreine Komponenten

Beispiele A-Komponenten:

Kundenverwaltung

Buchhaltung

Auftragsverwaltung

Komponenten sollen eindeutig einer Software-Kategorie zugeordnet

werden können:

A-Komponenten: implementieren nur Fachlichkeit

T-Komponenten: stellen technische Dienste bereit

Möglichst keine AT-Software auf Komponentenebene

Beispiele T-Komponenten:

• Datenbank

• O/R Mapper

• Middleware


Regel 3: Datenabstraktion

Der Zugriff auf Anwendungsdaten soll ausschließlich über

Komponentenschnittstellen erfolgen.

Schreibende Zugriffe über create- / modify-Methoden

Lesende Zugriffe über find-Methoden

Direktzugriff auf Datenbank nur in Ausnahmefällen (Performance)

und nur für lesende Zugriffe erlaubt

Auftrags-

verwaltung

Kunden-

verwaltung

Kunden-DB


Regel 4: Enger Zusammenhalt,

geringe Kopplung

Komponenten sollen so geschnitten sein, dass sie

intern einen engen Zusammenhang haben und

untereinander gering gekoppelt sind.


Regel 5: Azyklische Abhängigkeiten

Komponenten sollen so geschnitten sein, dass sie

keine zyklischen Abhängigkeiten haben

d.h. Abhängigkeitsgraph = DAG (Directed Acyclic Graph)


Regel 6: Handhabbare Komponentengröße

Weder 100 Klassen noch 1 Klasse, weder 1.000.000 noch 10 Zeilen Code

Komponenten sollen eine handhabbare Größe haben


Zuordnung der Regeln zu Qualitätszielen nach ISO/IEC 9126

Angemessenheit

(Funktionalität)

Benutzbarkeit

Änderbarkeit,

Austauschbarkeit

R1:

zusammengehörige

Fachlichkeit

R2: kategorienrein

R4: enger

Zusammenhalt, geringe

Kopplung

R5: zyklenfrei

R6: handhabbare

Größe

R3: Datenabstraktion

Motivation

Architektur-Sichten

Software-Kategorien







Agenda


Schnittstelle


Operationen

Name

Protokoll

Signatur

Semantik

Nicht-funktionale Eigenschaften

public interface OrderManager {

Order placeOrder (Customer customer, Article article)

throws NotAvailableException;

}

Rückgabetyp Operationsname Eingabeparameter und -typ

Ausnahme

Prosa, Vorbedingungen, Nachbedingungen, etc.

Prosa

Prosa, Sequenzdiagramme etc.

Schnittstellenname


Vorbedingungen und Nachbedingungen

Vorbedingungen (pre-conditions)

– Bedingungen, die vor Ausführung der Operation erfüllt sein müssen, z.B. Eigenschaften der

Parameter

– muss der Nutzer der Operation zusichern

– der Anbieter darf die Arbeit einstellen, wenn die Vorbedingung verletzt ist (Zusätzliche

Prüfung erhöht die Sicherheit: bei Verletzung Abbruch mit Ausnahme)

– Beispiel: Artikel muss verfügbar sein, wenn er bestellt wird

Nachbedingungen (post-conditions)

– Bedingungen, die nach Ausführung der Operation erfüllt sein müssen, z.B. Eigenschaften

des Ergebnisses

– Muss der Anbieter der Operation zusichern

– Nutzer der Operation kann davon ausgehen (Zusätzliche Prüfung erhöht die Sicherheit: bei

Verletzung Abbruch mit Ausnahme)

– Beispiel: Nach erfolgreicher Bestellung ist Rechnung erzeugt

Motivation

Architektur-Sichten

Software-Kategorien







Agenda


Literatur

Johannes Siedersleben: Moderne Softwarearchitektur. dpunkt-

Verlag 2004

Johannes Siederlseben (Hrsg.): Quasar: Die sd&m

Standardarchitektur (Download von meiner Hompage)

Martin Haft, Bernhard Humm, Johannes Siedersleben: The

Architect’s Dilemma – Will Reference Architectures Help?

(Download von meiner Hompage)


Kontrollfragen

Was sind die wichtigsten Aufgaben der Disziplin Design?

Welche Architektursichten unterscheiden wir? Was bedeuten die einzelnen Sichten?

Wie werden die einzelnen Sichten im Projektablauf entworfen?

Erklären Sie die Software-Kategorien

Was sind Komponenten? Nennen Sie Beispiele

Welche Sichten auf Komponenten existieren?

Nennen Sie wichtige Regeln für den Komponentenschnitt

Was sind Schnittstellen? Nennen Sie Beispiele

Wie werden Schnittstellen spezifiziert?

5. Design: Architektur-Grundlagen Softwaretechnik (CNAM)€¦ · Neue CORBA-Version Fachliche...

Documents

Transcript of 5. Design: Architektur-Grundlagen Softwaretechnik (CNAM)€¦ · Neue CORBA-Version Fachliche...