februar 2001münchen1 wie baut man informationssysteme? Überlegungen zur standardarchitektur...
Post on 05-Apr-2015
105 Views
Preview:
TRANSCRIPT
Februar 2001 München 1
Wie baut man Informationssysteme?Überlegungen zur Standardarchitektur
• Definierte Abhängigkeiten• Denken in Komponenten• Variabilitätsanalyse• Schnittstellen • Generische Programmierung• Entwicklungsprozeß• Fehler und Ausnahmen
J. SiederslebenFebruar 2001sd&m Münchem
Februar 2001 München 2
Systeme, die ich meine
• Viele Benutzer, hohe Transaktionsraten, große Datenmengen
• Individualsysteme (Eisenbahn, Telekommunikation, Reiseveranstalter, ..) • Heterogene Umgebung
• Erwartete Lebensdauer 10 Jahre und länger
• Teuer in der Erstellung und im Unterhalt
• Zu viele Projektpleiten
Februar 2001 München 3
Wo ist das Problem?
• Die 2/3/4/n-Schichten-Architektur ist notorisch unterspezifiziert.
• Dieselben Entwurfsprobleme seit Jahrzehnten. Zehntausende von Software-Ingenieuren denken immer wieder über dieselben Probleme nach.
• Die schiere Menge an Neuerungen, die ungefiltert über uns hereinbricht, macht uns verrückt: Was funktioniert, worauf kann ich mich verlassen, welche offenen oder verborgenen Abhängigkeiten nehme ich in Kauf? Welche Workarounds sind notwendig? • Der Weg von der Spezifikation zur Konstruktion ist trotz UML weitgehend unklar.
Quasar: Keine Antwort, aber ein Versuch
Februar 2001 München 4
Quasar: Qualitäts-Software-Architektur
• Definition von Standardkomponenten mit Standardschnittstellen; Prototyp-Implementierungen als Nachweis der Machbarkeit => austauschbare Implementierung. Beispiele: DB-Zugriff, HTML-GUI, Swing-GUI, Nachbarsystem-Zugriff
• Kochrezepte für Standardprobleme, z.B. : Mehrsprachigkeit, Historie, 2-Phasen-Commit, ..
• Idee: Baukasten von Komponenten mit genau definierten, minimalen Abhängigkeiten. Kein Framework!
• Weiterentwicklung/Umsetzung von alten Ideen: Datenabstraktion, Trennung der Zuständigkeiten
• Entwicklung von Anwendungsmustern: Mandantenfähigkeit, Stückliste, Beziehungskiste, .. , aber wesentlich genauer als z.B. Fowler (Analysis Patterns)
Februar 2001 München 5
Killerargumente (interne sd&m-Folie)
F: Eine Zugriffsschicht sollte man kaufen! A: Ja, aber man versteckt sie hinter einer Schnittstelle.
F: Ein firmenweites Framework kann nicht funktionieren.A: Richtig, und deshalb machen wir das auch nicht. Aber jedes projektweite Framework kann von Quasar profitieren.
F: Warum sollte ich mich von Quasar abhängig machen?A: Jede Idee, jede Schnittstelle, jedes Stück Software wird Eigentum des Projekts. Daher gibt es keine Abhängigkeiten.
F: Warum sollten die Quasar-Ideen besser sein als die des Projekts XY?A: (Fast) alle Quasar-Ideen wurden in realen Projekten geboren oder
sie sind allgemein anerkannt. Quasar ist ein Ideen-Integrator.
F: Laßt 100 Blumen blühen!A: Blumen wachsen auf der Erde. Besser: Laßt 100 Äste wachsen!
Februar 2001 München 6
Definierte AbhängigkeitenSoftware kann sein
• 0 bestimmt von gar nichts (Behälter, Strings)• A bestimmt von der Anwendung (Kunde, Konto, Buchung)• T bestimmt von mindestens einem technischen API (z.B. Datenverwaltung)• AT bestimmt von der Anwendung und mindestens einem technischen API.• R Trafo-Software (milde Art von AT)
Blutgruppen A + 0 = A; T + 0 = T; A + T = AT
Bewertung
• 0 ideal wiederverwendbar, für sich alleine nutzlos• A dafür werden wir bezahlt• T muß sein• AT zu vermeiden (bis auf R); notfalls sorgfältig abgrenzen!• R kann meist generiert werden
Februar 2001 München 7
RPC
BO-Transformation
BO-TransformationCache
Gui-Framework
Host
Client
Application (Client)
Application (Host)
T-Software0-Software
R-Software
Denken in Komponenten: Client-Host-Connection
A-Software
Februar 2001 München 8
Schichtenmodell
Anwendungskern
Arbeitsbereich
Datenspeicher
UI-Trafos
DB-Trafos
Feh
lerb
eh
andlu
ng
, A
usn
ahm
en
Geschäftsvorfälle
Layout
View/Controller
Dialog
DB-Experte
T-Software0-Software
R-Software
A-Software
Inte
lligente
Date
nty
pen
Februar 2001 München 9
AK-Objekt
Interface
Implement.
IData
store
Geschäfts-vorfall
Query
WorkspaceIW
ork
space
_MT
IWorkspace_Q
Data
Sto
re
IQ IQSto
rable
DB-API
Klassen & Objekte IQStorableSQL & Tabellen
IQuery
API-
Expert
QDI Überblick
Sta
tem
entM
gr
Sta
tem
ents
IQRepository (IQFieldDef, IQEntryDef, IQRecordDef)
IQSta
tem
entM
gr
IQSta
te,e
mtF
act
pr
y
Repository Implementierung (oder XML)
A-Software
T-Software
0-Software
R-Software
Februar 2001 München 10
Variabilitätsanalyse
Klassifizierung von Änderungen
• R-Änderungen betreffen externe Repräsentation fachlicher Objekte• T-Änderungen betreffen die Technik• A-Änderungen betreffen die Anwendung.
Ziel (Quasar)
X-Änderungen betreffen nur X-Software ( X = R, T, A)
Februar 2001 München 11
Intelligente DatentypenFallbeispiel: Versichertenart
Der Software-GAU
if v_art in ( 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 401, 402, 403, 404, 406, 407, 408, 601, 602, 603)then -- Pflichtversicherung -- tu was vernünftigesend if;
So sollte es sein
if versart.ist_pflichtversichert( v_art )then -- tu was vernünftigesend if;
Februar 2001 München 12
Intelligente Datentypen: Klassifikation
• Klassiker: String, Datum, Geld, Intervall
• Minigrammatiken: Dateinamen, URLs, Prüfziffertypen, Flugfrequenz
• Enumerationen: Anrede, Wochentag, Bonität, Rating, Versicherungstarif
• erweiterbare Enumerationen: Währung, Flughafencode, Airline, Versicherungstarif
• Tabellentypen: Flughafencode+Land, Versicherungstarif+Höchstalter
• zusammengesetzte Typen: Adresse, Bankverbindung
Diese Liste ist vollständig!?10% der Datentypen beschreiben 90% der Attribute eines SystemsUnsinn: STRING10, STRING20, ..
Februar 2001 München 13
Denken in Komponenten: Billing
System Customer Switch/
CDRSource
Tariff
Call Data Record
Invoice
getData findCDRs
Data feed
requires
Generate Invoice
computeprice
get CDRData
Februar 2001 München 14
Billing System: Komponenten
Customer
InterfaceTariff
CDR
Tariff BTariff A
Invoice Generator
Invoice
CustomerManager
CDRManager
TariffManager
find Customer
getData
findCDRs
findTariff
compute price
getData
Aufruf
abgeleitet von
getCDRData
implementiert
Switch/ CDRSource
AbstractTariff
Februar 2001 München 15
Komponenten: Inhalt und Verpackung
• Inhalt = eigentliche Arbeit; dafür wurde die Komponente gebaut.
• Verpackung (Wrapper) = dünne technische Schicht, die einen bestimmten Zugriff (z.B. über Corba) ermöglicht (meist generierbar).
Versicherten-auskunft(PL/SQL)
Druck-Manager
(Java)
Java-Client
Oracle-FormsClient
Corba-Wrapper
COM-Wrapper
VB-Client
calls
Februar 2001 München 16
• Jede AW-Komponenten verwaltet eine oder mehrere Entitäten; jede Entität gehört zu genau einer AW-Komponente.
• Komponenten werden nur über Interfaces angesprochen.
• Jede AW-Komponenten hat einen Manager für die Nicht-Instanzmethoden (Anlegen und Suchen). AW-Komponenten werden zunächst gebaut als GÄBE ES KEINE DATENBANK. Die DB-Operationen stehen im Manager. AW-Komponenten kümmern sich NICHT um Transaktionskontrolle.
• Braucht-Beziehung (A requires B) = enge Koppelung
Um A zu übersetzen, braucht man das Interface von B. Um A zu testen, braucht man eine (Dummy)-Implementierung von B.
• Das Komponentendiagramm zeigt die Braucht-Beziehungen VOLLSTÄNDIG.
• Lose Koppelung z.B. zwischen Kunde und Tarif: Der Tarif ist beim Kunden als String hinterlegt. Der Kunde interpretiert diesen String nicht.
Komponenten und Entitäten
A B
Februar 2001 München 17
Wie beschreibt man Komponenten?1. Idee: Worum geht´s?
2. Außensicht: Fachliches Modell
• normaler Benutzer• Anwendungsprogrammierer• Administrator• Arbeitsvorbereitung• Semantik der Operationen
3. Innensicht: Technisches Modell (UML, DB-Entwurf)
• Entwickler • Administrationsprogrammierer • Wartungsprogrammierer• Abhängigkeiten: Unter welchen Annahmen läuft die Komponente? Wen braucht sie?
4. Variabilitätsanalyse
• Welche Änderungen/Erweiterungen sind absehbar/wahrscheinlich/ausgeschlossen?• Was ist jeweils zu tun?
Februar 2001 München 18sd&m 18
Maximale und minimale Schnittstellen
• Jedes Produkt, jede Norm bietet maximale Interfaces: die Vereinigungsmenge aller vorhersehbarer Anforderungen (z.B. Swing)
• Aus Sicht der Anwendung interessieren mich minimale Interfaces: Was muß ich MINDESTENS sagen, damit mein Partner arbeiten kann.
• Die IQModel-Interfaces sind minimal:
public interface IQModel{ String getName(); boolean isEnabled();}
public interface IQFormModel extends IQModel{ Vector getValues(); Vector getFields(); Vector getChecks();}
public interface IQFieldModel extends IQModel{ boolean isEditable(); boolean isOk( String str ); void setValue( String str ); String getValue();}
Februar 2001 München 19
Schnittstellen: Vision
1. Exakte Definition der Semantik (ev. formal soweit sinnvoll/machbar)
2. Qualitative Zertifizierung von Schnittstellen-Implementierungen gegen die Schnittstellen-Definition
3. Quantitative Zertifizierung von Schnittstellen-Implementierungen auf der Basis von Lasttests (wieviele PS hat unsere Implementierung in definierter Umgebung)
Wohldefinierte Schnittstellen als berechenbare, belastbare Träger von Software-Architektur
Vision
Februar 2001 München 20
Generische Programmierung (1)
Wie verbindet man Software verschiedener Kategorien unter Erhaltung der Kategorie miteinander?
a) Metainformation, durch 0/T-Software interpretiert
b) Neutrale Formate (HTML, XML)
Februar 2001 München 21
Generische Programmierung (2)
• Verbindung verschiedener Metamodelle (z.B. Java Reflection und SQL)• Trafo-Regeln definieren die Transformation zwischen A und B• Ähnlich wie, aber allgemeiner als Java Beans.
Object x|A Transformator Object x|B
Trafo-regeln
Metamodell A Metamodell B
input/outputliest ausist beschrieben in
Februar 2001 München 22
IQ - das universelle Interface
public interface IQ{Object get(int idx);void set(int idx, Object value);String getQName();
}
Statt int ist ebenso String als Attributindex möglich
Wer darf das sehen?
Februar 2001 München 23
Application=
dialogs +application
kernel
Quasar-Windmühle
GUI(e.g. MFC)
Communicating System
Olap-System
OracleOCI
MFC-Expert
OLA
P-E
xpert
OCI-Expert
Com
Sy-E
xpert
A-Software
T-Software0-Software
R-Software
QUI
QDA
Februar 2001 München 24
Quasar: Development Process
Dialog
BusinessObjects
IQUI
IQDA IOth
ers
Dialog
BusinessObjects
IQUI
IQDA IOth
ers
QUIImp
QDAImp
Oth
ers
Imp
anymethod
analysed system
implementedsystem
designed system
1:1
Februar 2001 München 25
Errors are no(t) Exceptions
• errors and exceptions mixed up: a frequent design flaw• error:
a situation my system must cope with• exception:
a situation where my system will deny service• our way: assertions, pre- and postconditions
Februar 2001 München 26
Assertions
abstract public class Assert{ public static void isTrue( boolean cond, String txt ) { .. } public static void isFalse( boolean cond, String txt ) { .. } public static void isNull( Object obj, String txt ) { .. } public static void isNotNull( Object obj, String txt ) { .. } ..}
Typischer Aufruf:
Object result = someMethod();Assert.isNotNull( result, "Fehler in someMethod" );
Februar 2001 München 27
Ein Entwurf ist nicht dann fertig, wenn Du nichts mehrhinzufügen kannst, sondern dann, wenn Du nichts mehrweglassen kannst.
Antoine de Saint-Exupery
top related