Wie baut man Informationssysteme? Überlegungen zur Standardarchitektur Definierte Abhängigkeiten

1. 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 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 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 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) 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! München

6. Definierte Abhängigkeiten • Software 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 München

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

8. Schichtenmodell Layout View/Controller Dialog UI-Trafos A-Software 0-Software Geschäftsvorfälle T-Software R-Software IntelligenteDatentypen Anwendungskern Fehlerbehandlung, Ausnahmen DB-Trafos Arbeitsbereich Datenspeicher DB-Experte München

9. A-Software T-Software 0-Software R-Software IQRepository (IQFieldDef, IQEntryDef, IQRecordDef) IQState,emtFactpry IWorkspace_MT IDatastore IQStatementMgr IQIQStorable IWorkspace_Q IQuery Klassen & Objekte Interface QDI Überblick Implement. Repository Implementierung (oder XML) Geschäfts-vorfall Workspace DB-API DataStore StatementMgr Statements API-Expert AK-Objekt Query SQL & Tabellen IQStorable 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) München

11. 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; 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 Systems Unsinn: STRING10, STRING20, .. München

13. Switch/ CDRSource Call Data Record Customer Invoice Tariff Denken in Komponenten: Billing System Data feed getData findCDRs get CDRData Generate Invoice computeprice requires München

14. Switch/ CDRSource Aufruf abgeleitet von Billing System: Komponenten CDRManager CustomerManager implementiert CDR Customer findCDRs getData getData getCDRData find Customer TariffManager AbstractTariff Invoice Generator findTariff InterfaceTariff compute price Tariff A Tariff B Invoice 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). Oracle-FormsClient Java-Client VB-Client Corba-Wrapper COM-Wrapper Versicherten-auskunft(PL/SQL) Druck-Manager(Java) calls München

16. A B Komponenten und Entitäten • 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. 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? München

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(); } München sd&m18

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) Vision Wohldefinierte Schnittstellen als berechenbare, belastbare Träger von Software-Architektur 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) 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. Transformator Object x|A Object x|B Metamodell A Metamodell B Trafo-regeln input/output liest aus ist beschrieben in 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? München

23. Quasar-Windmühle GUI(e.g. MFC) A-Software 0-Software T-Software MFC-Expert R-Software QUI Olap-System Communicating System Application=dialogs +applicationkernel OLAP-Expert ComSy-Expert QDA OCI-Expert OracleOCI München

24. Quasar: Development Process QUIImp IQUI IQUI Dialog Dialog 1:1 anymethod BusinessObjects BusinessObjects OthersImp IOthers IOthers IQDA IQDA QDAImp implementedsystem analysed system designed system 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 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" ); 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 München