Februar 2001München1 Wie baut man Informationssysteme? Überlegungen zur Standardarchitektur Definierte Abhängigkeiten Denken in Komponenten Variabilitätsanalyse.

Präsentation zum Thema: "Februar 2001München1 Wie baut man Informationssysteme? Überlegungen zur Standardarchitektur Definierte Abhängigkeiten Denken in Komponenten Variabilitätsanalyse."—  Präsentation transkript:

1 Februar 2001München1 Wie baut man Informationssysteme? Überlegungen zur Standardarchitektur Definierte Abhängigkeiten Denken in Komponenten Variabilitätsanalyse Schnittstellen Generische Programmierung Entwicklungsprozeß Fehler und Ausnahmen J. Siedersleben Februar 2001 sd&m Münchem

2 Februar 2001München2 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

3 Februar 2001München3 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

4 Februar 2001München4 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)

5 Februar 2001München5 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!

6 Februar 2001München6 Definierte Abhängigkeiten Software kann sein 0bestimmt von gar nichts (Behälter, Strings) Abestimmt von der Anwendung (Kunde, Konto, Buchung) Tbestimmt von mindestens einem technischen API (z.B. Datenverwaltung) ATbestimmt von der Anwendung und mindestens einem technischen API. R Trafo-Software (milde Art von AT) BlutgruppenA + 0 = A; T + 0 = T; A + T = AT Bewertung 0ideal wiederverwendbar, für sich alleine nutzlos Adafür werden wir bezahlt Tmuß sein ATzu vermeiden (bis auf R); notfalls sorgfältig abgrenzen! Rkann meist generiert werden

7 Februar 2001München7 RPC BO-Transformation Cache Gui-Framework Host Client Application (Client) Application (Host) T-Software 0-Software R-Software Denken in Komponenten: Client-Host-Connection A-Software

8 Februar 2001München8 Schichtenmodell Anwendungskern Arbeitsbereich Datenspeicher UI-Trafos DB-Trafos Fehlerbehandlung, Ausnahmen Geschäftsvorfälle Layout View/Controller Dialog DB-Experte T-Software 0-Software R-Software A-Software Intelligente Datentypen

9 Februar 2001München9 AK- Objekt Interface Implement. IDatastore Geschäfts- vorfall Query Work space IWorkspace_MT IWorkspace_Q DataStore IQ IQStorable DB-API Klassen & Objekte IQStorable SQL & Tabellen IQuery API-Expert QDI Überblick StatementMgr Statements IQRepository (IQFieldDef, IQEntryDef, IQRecordDef) IQStatementMgr IQState,emtFactpry Repository Implementierung (oder XML) A-Software T-Software 0-Software R-Software

10 Februar 2001München10 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)

11 Februar 2001München11 Intelligente Datentypen Fallbeispiel: 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ünftiges end if; So sollte es sein if versart.ist_pflichtversichert( v_art ) then -- tu was vernünftiges end if;

12 Februar 2001München12 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 Systems Unsinn: STRING10, STRING20,..

13 Februar 2001München13 Denken in Komponenten: Billing System Customer Switch/ CDR Source Tariff Call Data Record Invoice getDatafindCDRs Data feed requires Generate Invoice compute price get CDRData

14 Februar 2001München14 Billing System: Komponenten Customer Interface Tariff CDR Tariff BTariff A Invoice Generator Invoice Customer Manager CDR Manager Tariff Manager find Customer getData findCDRs findTariff compute price getData Aufruf abgeleitet von getCDRData implementiert Switch/ CDR Source Abstract Tariff

15 Februar 2001München15 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-Forms Client Corba- Wrapper COM- Wrapper VB- Client calls

16 Februar 2001München16 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 AB

17 Februar 2001München17 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?

18 Februar 2001München18 sd&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(); }

19 Februar 2001München19 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

20 Februar 2001München20 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)

21 Februar 2001München21 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 AMetamodell B input/output liest aus ist beschrieben in

22 Februar 2001München22 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?

23 Februar 2001München23 Application = dialogs + application kernel Quasar- Windmühle GUI (e.g. MFC) Communicating System Olap- System Oracle OCI MFC-Expert OLAP-Expert OCI-Expert ComSy-Expert A-Software T-Software 0-Software R-Software QUI QDA

24 Februar 2001München24 Quasar: Development Process Dialog Business Objects IQUI IQDA IOthers Dialog Business Objects IQUI IQDA IOthers QUIImp QDAImp Others Imp any method analysed system implemented system designed system 1:1

25 Februar 2001München25 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

26 Februar 2001München26 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" );

27 Februar 2001München27 Ein Entwurf ist nicht dann fertig, wenn Du nichts mehr hinzufügen kannst, sondern dann, wenn Du nichts mehr weglassen kannst. Antoine de Saint-Exupery