6. design: architektur-grundlagen softwaretechnik (cnam)€¦ · 17 prof. dr. bernhard humm,...

1 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 / 2010. 17.11.2009

Softwaretechnik (CNAM)

6. Design: Architektur-Grundlagen

Wintersemester 2009 / 2010Prof. Dr. Bernhard HummHochschule Darmstadt, FB Informatik


Einordnung in den gesamten Kurs

1. Einführung

2. Vorgehensmodelle

3. Analyse: Anforderungen und Anwendungsfälle

4. Analyse: Datenmodell

5. Analyse: Dialoge

6. Design: Architektur-Grundlagen

7. Design: Referenzarchitektur betriebliche Informationssysteme

8. Design: Querschnittsthemen und Muster

9. Programmierung, Konfigurationsmanagement

10. Modellgetriebene Entwicklung

11. Testphase, Einführung, Qualitätsmanagement

12. Projektmanagement

Motivation

Architektur-Sichten

Software-Kategorien

Komponenten & Schnittstellen

Regeln für den Komponentenschnitt

Spezifikation von Schnittstellen

Literatur, Kontrollfragen

� 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


Architekturstile

Ziele:

• Angreifer aufwärts kämpfen lassen

• parallel zu dem Burgmauern führen

• immer von 3 Seiten beschießen

Lösungen

• Versetzte Tore

• Mauern mit auskragenden Türmen

• Mehrere konzentrische Bastionen

• Innere Bastionen überblicken äußere



Softwaresysteme gehören zu den komplexesten Dingen, die Menschen je gemacht haben…


… und brauchen daher eine gute ArchitekturWo 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.

� 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.

� 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“.

� 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“.

Quasar-Architektur

Quelle: sd&m Research


Beispiel-Projekt für Logistik-Dienstleister

� Kunde: großer Logistik-Dienstleister

� Projekt: Auftragsmanagement

� Volumen Stufe 1: > 30 BJ

� Zeit: April 2003 – Januar 2004

Referenz-Projekt


Beispiel für A-Architektur

ESI-FrontendESI-Frontend

SA-BackendSA-Backend

SA-Front-end

SA-Front-end

T&T-VerwaltungT&T-Verwaltung

ESi-BackendESi-Backend

Disposition Disposition

AuftragsverwalterAuftragsverwalter

AuftragsüberwachungAuftragsüberwachung

AuftragsverwalterAuftragsverwalter

BenutzerverwaltungBenutzerverwaltung

StammdatenverwaltungStammdatenverwaltung

AuftragsabrechnungAuftragsabrechnung

NVE-DruckerNVE-Drucker

SA-Batch-Scanner

SA-Batch-Scanner

SA-Online-Scanner

SA-Online-Scanner

AuftragsüberwachungAuftragsüberwachungDispositionDisposition

Frontend

Backend

NummerverwaltungNummerverwaltung

KonvertierungKonvertierung

Annahme/ImporterAnnahme/Importer

Auftragsverwaltung

InformationsanforderungInformationsanforderung

Master Applikation Internes Informations-service und Clearing

Portal


Informationsservice und ClearingInformationsservice und Clearing


StammdatenverwaltungStammdatenverwaltungBenutzerverwaltungBenutzerverwaltung

StammdatenverwaltungStammdatenverwaltung

Produktions-auftragsverwaltung

Clients

Inform.service u. ClearingInform.service u. Clearing

Informationsservice und ClearingInformationsservice und Clearing



NummernverwaltungNummernverwaltung StammdatenverwaltungStammdatenverwaltung

Querschnitt

Auftragsverwaltung Produktion Entgeltsicherung Tracking & Tracing

Referenz-Projekt


Beispiel für T-Architektur

WebLogic

AWK

Datenbank-server

A-Komponente 2

A-VerwalterA-VerwalterA-EntitätstypA-Entitätstyp

Attributeund

Beziehungen

Attributeund

Beziehungen

A-Fall 3

(UseCase)

A-Fall 3

(UseCase)

A-Fall 4

(UseCase)

A-Fall 4

(UseCase)

A-Komponente 1

A-VerwalterA-VerwalterA-EntitätstypA-Entitätstyp

Attributeund

Beziehungen

Attributeund

Beziehungen

A-Fall 1

(Use-Case)

A-Fall 1

(Use-Case)

A-Fall 2

(Use-Case)

A-Fall 2

(Use-Case)

LegendeLegende

benutzt, ruft

Service 1Service 1 Service 2Service 2 Service 3Service 3

Rich-Client

Service-Infrastruktur / Middleware

Web-Server(Client)

Applikationin

Fremd-Domäne

Browser Browser Browser

Adapter

Proxy

� 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)

Referenz-Projekt


Beispiel für TI-Architektur

PC

z/OS

DB2

USS

CICS/TSO

Web-Browser

IBM-Webserver

Java-Applet

http

Anwendungskern

Bridge (GWAPI)

EXCI

NachbarsystemeMQSeries

IDMS

Nachbarsysteme

AKS-Shell

CICS

Nachbarsysteme

CICS-DPL

CICS/UNIX

NachbarsystemeTCP/IP

Quasar-Architektur


A-Architektur

A-Architektur grobAnforderungen

TeilsystemeNachbarsysteme

SpezifikationAnwendungsfälleEntitätenmodell

Dialogspezifikationetc.

Teilsysteme, Komponenten, Schnittstellen,

Klassen/Module

Pakete, DLLs, Programmiersprachendateien

Programmierungder Anwendung

T-Architektur

SchichtenKomponenten

Klassen/Module

Pakete, DLLs, Programmiersprachendateien

Programmierung von Basiskomponenten

(0/T-Software)

TI-Architektur

Auswahl einer geeigneten Technologie

logische Rechner, Netze, Trägersysteme

technische Produkte

Zeit

Referenzarchitektur

Entwicklung der Architektur-Sichten im Projekt-Ablauf

Quasar-Architektur

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

Quasar-Prinzipien: Software-Kategorien


Beispiel Gehaltssoftware

IBM AS/400

� Neues Entwicklungspfade-und Entlohnungsmodell

� Neue Beitragssätze zur Sozialvericherung

� Neue CORBA-Version

Fachliche ÄnderungenFachliche Änderungen technische Änderungentechnische Änderungen



Softwarekategorien:Trenne Zuständigkeiten

KategorienKategorien Das heißt…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

Maximen zum Finden und Schneiden von Komponenten

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

• Wiederverwend-barkeit der technischen Komponenten• Wartbarkeit• Fehlerfreiheit• Stabile Komponenten

Anteil von AT-Software


Motivation

Architektur-Sichten

Software-Kategorien





� Komponenten & Schnittstellen

Agenda


Komponenten-Orientierung am Beispiel Auto

Außensicht(Schnittstelle)des Fahrers:

möglichst einfach

Außensicht(Schnittstelle)

derWerkstatt:

möglichst einfachInnensicht: komplex


Komponenten-Orientierung in der SoftwareBeispiel: Berechtigungskomponente

Berechtigungs-kern

B

Admin-Schnittstelle

A

operativeSchnittstelle

SR‘

RACF-Adapter

DB-Zugriff

RACF

BerechtigungGUI

Oracle

JDBCR

Berechtigungskomponente

Außensicht(Nutzungssicht):

operative Schnittstelle des

Anwendungs-programmierers

(möglichst einfach)

Außensicht(Nutzungssicht):Schnittstelle desAdministrators

(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, diedieselbe 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

t2t1

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>>

OrderingFactoryOrdering

(Anwendungsentwickler Client oder Nachbarkomponente)

gets reference toOrderingFactory

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)

OrderingFactoryImpl

<<creates>>

Ordering

OrderingFactoryOrder

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

OrderingKomponenteClient-

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

SAPAdapter

Ordering

Integrationssicht

OrderingFactory

Ordering



Administrationssicht

OrderingKomponente

OrderingFactory

Ordering

Administration

setTaxValues,configurePrices,

configureReductions,…


Betriebssicht

OrderingKomponente

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


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.


Authorizationkernel

B

administrationinterface

A

Operationalinterface

SR'

RACF-Adapter DB Access

RACF

AuthorizationGUI

Datenbank

R

Verschiedene Sichten / Schnittstellenfür unterschiedliche Nutzer

A-GUI

Komponenten und Schnittstellen

Anwendungs-programmierer

(viele)

Administrator

Admin-ClientEntwickler

RACF-ExperteRACF-ExperteDB-Experte

Entwickler des Admin-Clients


Nutzer AnbieterS

Standard-Schnittstelle

S‘ Adapter

angeforderte Schnittstelle

Wer definiert Schnittstellen?

Nutzer AnbieterS

angebotene Schnittstelle

AnbieterS

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

AnbieterS

angebotene Schnittstelle

Nutzerz.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





� Regeln für den Komponentenschnitt

Agenda


Gestaltungsziele für Komponenten (nach ISO/IEC 9126)

Angemessenheit (Funktionalität)

Benutzbarkeit

Änderbarkeit,Austauschbarkeit


Regel 1: Komponenten sollen zusammengehörige Fachlichkeit zusammenfassen

� 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, Lohnbuchhaltung

– Kundenverwaltung, Auftragsverwaltung

– Vertrieb, Produktion

� Gegenbeispiele:

– Host-Anwendungen, Java-Anwendungen

– Daten, Funktionen


Regel 2: Kategorienreinheit: Komponenten sollen entweder A-Software oder T-Software implementieren

� A-Komponenten implementieren Geschäftslogik (A-Software), z.B.

– Hauptbuchhaltung, Nebenbuchhaltung, Lohnbuchhaltung

– Kundenverwaltung, Auftragsverwaltung

– Vertrieb, Produktion

– …

� T-Komponenten implementieren technische Dienste (T-Software), z.B.

– Persistenz

– Transaktion

– Namensdienst

– Authentifizierung / Autorisierung

– Logging / Tracing

– …


Regel 3: Hoher Zusammenhalt, geringe Kopplung (strong cohesion, loose coupling)

� Hoher Zusammenhalt (Cohesion) (innerhalb einer Komponente)

– inhaltlich zusammengehörende Elemente in einer Komponente/Modul/Subsystem

– klar definierter, präziser Zuständigkeitsbereich

� Geringe Kopplung (Coupling) (zwischen Komponenten)

– direkte Kopplung = Abhängigkeit

– inhaltlich unabhängige Einheiten möglichst stark entkoppelt

– je weniger Abhängigkeit desto besser(z. B. durch schmale Schnittstellen, wenige Imports, …)

Ed Yourdon

��


Regel 4: Vermeide zyklische Abhängigkeiten

� Abhängigkeit zwischen zwei Komponenten:

– Aufruf von Operationen

– Import von Schnittstellen

� UML-Notation: Dependency (gestrichelter Pfeil)

� �

Legende

Schnittstelle

Komponente

Abhängigkeit


Regel 5: Handhabbare Komponentengröße

� Weder 100 Entitäten noch 1 Entität in einer Komponente

� Weder 1.000.000 noch 10 Zeilen Code

��


Übersicht der Regeln zum Komponentenschnitt

Angemessenheit (Funktionalität)

Benutzbarkeit

Änderbarkeit,Austauschbarkeit

R1: zusammengehörige

Fachlichkeit

R2: kategorienrein

R3: enger Zusammenhalt, geringe

Kopplung

R4: zyklenfrei

R5: handhabbare Größe

Motivation

Architektur-Sichten

Software-Kategorien





� Spezifikation von Schnittstellen

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

AusnahmeProsa, 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




Literatur, Kontrollfragen� Literatur, Kontrollfragen

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 Design-Phase?

� 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?

6. design: architektur-grundlagen softwaretechnik (cnam)€¦ · 17 prof. dr. bernhard humm,...

Documents