Februar 2001München1 Wie baut man Informationssysteme? Überlegungen zur Standardarchitektur...

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