This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
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
2 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 / 2010. 17.11.2009
– 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
Komponenten & Schnittstellen
Regeln für den Komponentenschnitt
Spezifikation von Schnittstellen
Literatur, Kontrollfragen
� Architektur-Sichten
Agenda
19 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 / 2010. 17.11.2009
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
20 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 / 2010. 17.11.2009
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
21 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 / 2010. 17.11.2009
38 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 / 2010. 17.11.2009
<<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
Application components
39 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 / 2010. 17.11.2009
Administrationssicht
OrderingKomponente
OrderingFactory
Ordering
Administration
setTaxValues,configurePrices,
configureReductions,…
40 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 / 2010. 17.11.2009
Betriebssicht
OrderingKomponente
OrderingFactory
Ordering
SystemsManagement
Systems Management (z.B. Tivoli)
Komponente hoch- und herunterfahren,
Gesundheitszustand abfragen
41 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 / 2010. 17.11.2009
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
42 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 / 2010. 17.11.2009
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.
43 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 / 2010. 17.11.2009
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
44 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 / 2010. 17.11.2009
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
45 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 / 2010. 17.11.2009
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)
46 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 / 2010. 17.11.2009
� 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
Komponenten & Schnittstellen
Regeln für den Komponentenschnitt
Spezifikation von Schnittstellen
Literatur, Kontrollfragen
� Regeln für den Komponentenschnitt
Agenda
48 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 / 2010. 17.11.2009
Gestaltungsziele für Komponenten (nach ISO/IEC 9126)
Angemessenheit (Funktionalität)
Benutzbarkeit
Änderbarkeit,Austauschbarkeit
49 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 / 2010. 17.11.2009
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
– inhaltlich unabhängige Einheiten möglichst stark entkoppelt
– je weniger Abhängigkeit desto besser(z. B. durch schmale Schnittstellen, wenige Imports, …)
Ed Yourdon
��
52 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 / 2010. 17.11.2009
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
53 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 / 2010. 17.11.2009
Regel 5: Handhabbare Komponentengröße
� Weder 100 Entitäten noch 1 Entität in einer Komponente
� Weder 1.000.000 noch 10 Zeilen Code
��
54 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 / 2010. 17.11.2009
Ü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
Komponenten & Schnittstellen
Regeln für den Komponentenschnitt
Spezifikation von Schnittstellen
Literatur, Kontrollfragen
� Spezifikation von Schnittstellen
Agenda
56 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 / 2010. 17.11.2009
Schnittstelle
Spezifikation von Schnittstellen
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
57 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 / 2010. 17.11.2009
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