betr. diese Präsentation zur Software-Architektur Manchmal aber funktioniert das Einblenden nicht so recht. [ Zurück … und Wiederholen! ] Das kann nur an PowerPoint liegen … Man müßte sich bei Microsoft beschweren. Sie können sich die Präsentation auch – mit zusätzlichen Erläuterungen – als NOTIZBLATT ausdrucken lassen. Damit Sie diese Darstellung tatsächlich Schritt für Schritt – na hoffentlich: – »genießen« können, wird von Ihnen erwartet, daß Sie für den Bildwechsel oder manchmal zwischendurch die Maus drücken: So werden die einzelnen Seiten häufig nur portionsweise aufgeblendet. Einige Texte erscheinen nur zeilenweise, um Ihnen die Konzentration zu erleichtern. Zum Schluß jeder Seite erscheint automatisch der Rückkehr-Schalter … … wenn Sie jetzt mausklicken, auch hier. Danach können Sie entweder mit ihm (drücken!) zur vorigen Seite zurück (hier gibt´s natürlich keine) oder durch Klick außerhalb der Schaltfläche zur nächsten. *** (Unten links erscheint außerdem die übliche PowerPoint-Schaltfläche, wenn die Maus bewegt wird.) Bitte ändern Sie nichts in unserer Präsentation, aber Sie dürfen sie natürlich ohne Bedenken weitergeben. H. Dreßler • Vorschlag: einmal durchlaufen lassen und beim zweiten Mal gründlich lesen und bedenken • Software-Architektur Helmut Dressler Lauteschlägerstr. 19 64289 Darmstadt Tel. 49.6151.715945 Fax 49.6151.788538 eMail: helmut.dressler@t-online.de Uwe Wagner Alsbacher Str. 45 64342 Seeheim-Jugenheim Tel. 49.6257.903348 Fax 49. 6257.903347 eMail: uwe.wagner@t-online.de

Die Gratwanderung vom Problem zum System Helmut Dressler Die Gratwanderung vom Problem zum System (apropos Gratwanderung: Bei den Theoretikern gelten wir als Praktiker, bei den Praktikern als Theoretiker. – Bedeutet das den »Ehrenplatz zwischen den Stühlen«?)

Helmut Dressler<<<< »Problemlösen mit Entscheidungstabellen«, München, 1975 »Play Net« – das Spiel im Petri-Netz, Darmstadt, 1985 »Kleines Testhandbuch«, für E. Merck, Darmstadt, 1990 »Datenstrukturentwurf«, München, 1995 Einige Stichworte über Projekte oder Schwerpunkte der Vergangenheit: Didaktische Programmierung (Lehrprogramme) • Entscheidungstabellen-Technik • Schulungsleiter für viele Themen aus dem Bereich EDV • »Normierte Programmierung« • Software-Methodik • Programm-Montage in Assembler (Makrotechnik) • MTRX: Assembler-Verfahren zur Bearbeitung von beliebig großen dünnbesetzten Matrizen …& …Implementierung mit automatisiertem Test • Matrix-Algorithmus zur Kostenverteilung • Modularisierungsverfahren (View Manager) • System-Analyse & -Entwurf (Implementierung mehrerer Großsysteme) • Projektmodell • Projektleitung von großen Projekten • Petri-Netz-Anwendungen • Datenbankentwurf • Qualitätssicherung • Produktivitäts-Kontrolle • Software-Metriken • Verantwortliche Beratung • Analyse & Redesign bestehender Systeme • Konzepte • … * 1941, Dresden Dipl. Ing (Regelungs-technik • TH Darmstadt 1969) Viele Jahre bei Software Partner GmbH, Darmstadt (Leiter Kommerzieller Großprojekte) Seit 1990 Freiberufler: »Systemanalytische Beratung«, seit 1996 in Kooperation mit Uwe Wagner Heutige Beratungsangebote u.a.: + Produkt »UVMT«: Umfassendes (Re-) Design der Software-Architektur + Managementberatung: Software-Produktentwicklung + Analyse & Beratung: Design und Redesign von Großanwendungen + Schrittweise Einführung nach dem Prinzip »ABC« : Konstruktive und analytische Qualitätssicherung (…also: »mit den geringsten Maßnahmen den größten Nutzen erzielen«) + Evolutionäre Software-Entwicklung (langfristige Strategie) + Beratung: Software-Produktionsmanagement & Einführung eines Projektmodells + Datenbankentwurf … mit neuem Data Dictionary System »D&W-DaDic« + P-&-Q-Checkup: dreiteiliges Firmenseminar zur Verbesserung von Produktivität und Qualität (Analyse, Zielbestimmung, Maßnahmen) quasi- »OO« (1981) u.a. Dressler & Wagner H. Dreßler Software-Architektur

ein SYSTEM: so oder so … Man hat es bei »Y2K« gesehen: Manche Software-Systeme werden unbeherrschbar. Aufwand »Konventionelle« Architektur der Software In der Theorie werden modulare Schichtensysteme verlangt. »Nachhaltige« Architektur der Software Der Anfangsaufwand für nachhaltige Systemarchitektur ist größer als der für »Spontane Programmierung«; es gibt Regeln, Frames (Schablonen), Muster und Ideologien, auch Verbote und QS-Verfahren. Der Nutzen stellt sich rasch ein: Spaghetti ist out. Die Sourcecodemenge ist minimiert, das System wird – zumindest in seinen komplizierten Passagen – redundanzfrei, es gewinnt an Qualität, sowohl aus Sicht der Entwickler als auch aus der von Anwendern (s.u.), und kann sich sehen lassen … mausklick! Komplexität mit 5 Schichten! H. Dreßler Software-Architektur

Problem & Konzept, allgemein Das Dreieck Aufwand Komplexität Nachhaltiges Vorgehen Konventionelles Anlaß fürs Redesign Fürs Design sind vier Aspekte zu bedenken, wie sie in unserem Konzept-Dreieck bezeichnet werden. In einem guten Konzept werden auf alle vier Fragen ordentliche Antworten formuliert: mausklick! A ZIELE (Defizite) Unser Konzept-Dreieck ist ein allgemeingültiges Symbol als graphisches Rezept für eine systematische Vorgehensweise in jeder rational orientierten Disziplin. (Wenn Sie es – zur Erläuterung ihrer eigenen Vorstellungen für systematische Arbeit – benutzen, verweisen Sie auf uns als die Autoren!), A) Ziele: Welchen Nutzen wollen wir erreichen? B) Wege & Maßnahmen: Was müssen wir dafür tun? C) Welche Mittel & Methoden stehen uns zur Verfügung? D) Nach welchen Prinzipien wird die Qualität der drei Aspekte gemessen? D C B Prinzipien Qualitäten MITTEL (Methoden) WEGE (Maßnahmen) H. Dreßler Software-Architektur

betr. D) Prinzipien & Qualitäten Zweckmäßig zu unterscheiden sind: QA = Qualität aus Sicht der Anwender Korrektheit, Funktionsumfang, Robustheit, Zuverlässigkeit, A-Dokumentation, Benutzerfreundlichkeit, Zeitverhalten, Leistung/Durchsatz, Stabilität der Entwicklung, »Vorzeigbarkeit«, Anpassungsfähigkeit QE = Qualität aus Sicht der Entwickler E-Dokumentation, Verständlichkeit, Einfachheit, Einheitlichkeit (nach Standards), Modularität (ADT, oo), Redundanzfreiheit der »Erfindungen«, Wiederverwendbarkeit. (Wieder-) Testbarkeit, Änderbarkeit, Erweiterungsfähigkeit, Portabilität betr. D) Prinzipien & Qualitäten Die Trennung in Anwender- und Entwickler-Qualität ist durchaus zweckmäßig, wobei selbstverständlich diese auf jene Auswirkungen hat: Wenn die Änder- und Erweiterbarkeit (QE) gut ist, freut sich der Anwender, daß ein System sich leicht an neue Anforderungen anpassen läßt H. Dreßler Software-Architektur

konventionell  nachhaltig – so, wie es alle immer gemacht haben (ja auch: mit zweistelligen Jahreszahlen) – jeder ist Seines Textes Verfasser – Dokumentation: Nebensache – immer alles wieder neu erfunden: (das sei »kreativ«, ist aber tatsächlich bloß redundant) – Modularisierung: frommer Wunsch – Steuerlogik, Algorithmen und Datenzugriffe als vermischte Schriften: unauflösbarer Wirrwarr – nur der Autor kann es ändern – Fernwirkung nicht zu kontrollieren – Wiedertestbarkeit: Fehlanzeige – gewaltige Kostensteigerung erst später + zugegeben:»nachhaltig« (sustainable) ist ein Modewort, aber es weist darauf hin, daß die Effekte von Investitionen langfristig bedacht werden müssen. + jedes »Stück Logik« wird im gesamten System nur einmal implementiert; jeder kann es benutzen. + Einarbeitungs-Investitionen amortisieren sich in Kürze. + im Vergleich: Die Menge des Sourcecodes gegenüber k. ist drastisch vermindert. + die Teile des Systems sind dokumentiert, durchschaubar, einheitlich, testbar und kontrolliert zu ändern. + Kostenersparnis: kurz- mittel- langfristig + das Know How bleibt verfügbar. Die beiden Kurven im Koordinatensystem zwischen Komplexität und Aufwand beschreiben Risiko und Chancen. Schon kurzfristig lohnt sich die nachhaltige Architektur wegen besserer Testbarkeit, Systematik und dem meist schon bald geringeren Implementierungsaufwand. Aber langfristig ist die Erweiterbarkeit des Systems gesichert, sein Know How wird gewahrt, es hat eine viel größere Lebenszeit und läßt sich kontinuierlich ablösen, wenn seine Zeit gekommen ist. H. Dreßler Software-Architektur

View Manager & »Sicht-Knechte« innen=DB-nah außen=Anwender-nah evtl. mehrere Schichten Vollkommene Abschottung der Datenbank durch Broker Eine strenge und kompromißlose Abschottung ist auch heute nicht üblich. Dabei wurde sie bereits um 1980 durch die Propagierung der Abstrakten Datentypen (ADT) gefordert. H. Dreßler Software-Architektur

… nach Software-Architektur-Prinzipien Ultimative View Manager Technik … natürlich Sprachen- und Betriebssystem-unabhängig Stichwörter für Kenner & Experten, auf daß Sie uns nichts als zustimmen: + Evolutionäre Software - sie ist beliebig(!) weiterzuentwickeln, weil sie keine unverrückbaren Barrieren schafft + (also) 5-Schichten und strenge Modularisierung - damit Programm-Montage stattfinden kann + (also) redundanzfreie, aber wiederverwendbare Bausteine - so daß Sourcetexte und Irrtümer minimiert werden + (also) Information Hiding - damit niemand die obligatorischen Schnittstellen umgehen/mißbrauchen kann + Datenstruktur-Entwurf nach allen Regeln der »Kunst« + Strenge Trennung von Präsentation, Anwenderlogik und DB-Zugriffslogik + Qualitätsmaßstäbe aus Sicht der Anwender - Korrektheit, Funktionsumfang, Robustheit, Zuverlässigkeit, Anwender-Dokumentation, Benutzerfreundlichkeit, Zeitverhalten, Leistung/Durchsatz, Stabilität der Entwicklung, »Vorzeigbarkeit«, Anpassungsfähigkeit + zusätzliche Qualitätsmaßstäbe aus Sicht der Entwickler - Entwickler-Dokumentation, Verständlichkeit, Einfachheit, Einheitlichkeit (nach Standards), Modularität (ADT, oo), (Wieder-) Testbarkeit, Änderbarkeit, Erweiterungsfähigkeit, Portabilität + Entwurf & Implementierung der Programmstrukturen aus einem Guß (keine Umstrukturierung!) + Testbarkeit optimal: Schrittweise integrierbare Bausteine: topdown & bottomup  Einige Ergänzungen der Eigenschaften stehen auf späteren Seiten. Ganz wesentlich ist die Tatsache, daß durch Aufrufprozeduren – kompiliert, benutzbar, versteckt (»Information Hiding«) – die UVMT-Modularisierung in Anwenderprogrammen extrem einfach gestaltet ist. Konventionen jeder Programm-Montage sind leicht zu implementieren, die Programmstrukturen werden einheitlich, und der bekannte »Batch-Wust« abgelöst durch ein universelles Schema. Fast alle diese Kriterien werden unterstützt von der Ultimativen View Manager Technik H. Dreßler Software-Architektur

Einschub: oo-Entwurf, UML, UseCases Sind alle SW-A-Prinzipien gewährleistet? Gibt es eine vorher definierte Datenstruktur? »Persistenz« ist beinahe ein Sonderfall. Frühere Redeweise: »…Operationen auf die Datenstruktur« Wie wird ein UML-Entwurf in eine (bitte sehr: nichttriviale) Programm- und Systemstruktur umgesetzt? »oo-Dynamik« (Methoden) auf Kosten der DB-Statik (Views) Vernachlässigung von Schichten oder gar Massendaten-Verarbeitung »Gruppenwechsel-Batch« ist sowieso meist unbekannt… … oder völlig unterschätzt! • … glaube ich nicht • ist in UML und USE CASES nicht vorgesehen • … ein eher ärgerlicher, kriegen wir später • Ist sie denn nun mit UML und rein objektorientiertem Entwurf falsch geworden? • keine Ahnung • Rückfall in das operationale Programmieren, bei dem daten – „ach ja, gewiß auch“ – zugunsten der Algorithmik nur als notwendiges, unumgehbares Übel angesehen wurden • Ein Lücke im oo-Entwurfskonzept, die aber auch nicht nachträglich zu schließen ist, denn man denkt von den „Methoden“ aus • GRUPPENWECHSEL – wenden Sie sich an uns! H. Dreßler Software-Architektur

5 Schichten und strenge Modularisierung… …in der Theorie & etwas idealisiert … die wäre auch wichtig (1) Individuelle graphische Oberfläche (GUI) evtl. auch im I…Net 3. Präsentation und Eingabe } Anwender-Dialoge (2) E/A - »logische Masken« / Client 2. GUI-neutrale Aufbereitung der DIALOG-Schnittstelle Data Container (3) Funktionen: E/A-Steuerung, (Batch?), Dienste, Ablauflogik, Algorithmen 1. Programm ist aktiv Verarbeitungen … eigentlich die wichtigste Trennlinie (4) Broker • View Manager • »Sicht-Knechte« 4. Logische Datenzugriffe } Drei Schichten, wie bis vor einiger Zeit üblich, reichen nicht aus. Die Benutzeroberfläche muß in »Graphik & Logik« aufgetrennt werden, die Datenbank-Zugriffe in »Objekte & Navigation. Nicht nur die übliche Client-Server-Architektur erzwingt eine solche Trennung, sondern auch moderne Vorstellungen von strikter Modularität und Wiederverwendbarkeit. Zwischen den Schichten muß es vier standardisierte (allgemein:) »Verständigungsbereiche« geben, und man will nur noch »Komponenten-Module« schaffen, die – etwa über Corba – miteinander problemlos kommunizieren. Dieses ist ein großes Unterfangen angesichts der üblichen Praxis. Da findet selbst die notwendige Trennung zwischen Anwenderlogik und DB-Zugriffen nicht statt. Jedes Programm hat seine eigenen SQL-Statements (oder FINDs in Natural), und dasselbe(?) Statement findet sich – redundant/ widersprüchlich – in allen möglichen Programmen wieder, quer durch die Instanzen. Komplizierte Zugriffe – etwa zeitbezogen – sind gänzlich unmöglich, wenn jeder Programmierer dafür seine eigene Zugriffslogik erfinden soll. Wenn die Datenbank geändert werden muß, ist anzupassen: überall und doch zum Stichtermin, ohweh!. Objekt-Funktionen (5) DB-Zugriffe / Server / Batch 5. Physische Datenzugriffe H. Dreßler Software-Architektur

in der PRAXIS aber Algorithmen Dialoge Ablauf- Steuerung Daten- Aufbereitung DB- Zugriffe Batch- Verarbeitung egal, ob … … oder frei (Spaghetti-) Schnauze Innerhalb der … Also: Prinzip »Einfachheit« ver……sus »Prinzip »Fach-(Simpel)« Je größer das System desto schlimmer. … oo-orientierterEntwurf … findet die … … statt! H. Dreßler Software-Architektur

Also: „neues“ SW-Architekturkonzept (1) MODUL VB = Standard- Verbindungs-Bereich für alle Module (vereinfacht:) für: AM = Algorithmen-Modul VM = View Manager (Broker) DM = Dienstmodul (Batch.GW) AB = Individueller Anwender-Bereich je Modul (beliebiger Struktur) Sender-Einträge • Sender • Empfänger • Selektor (»Methode« – unterteilt) • Betrachtungs-Datum • Sprachcode • Autorisierung • zum Dienstmodul A (Anfang) • zum Dienstmodul H (Haupt *) • zum Dienstmodul E (Ende) • TraceLevel • Sendezeitpunkt Empfänger-Einträge • Empfänger-Zeitpunkt • Returncode (nach Standardtabelle) • Fehler-Information • zum Fehlermodul (hochzureichen) AM: beliebiger Modul, auch Objekt, der irgendwelche Leistungen vollbringt, als Sammlung beliebiger Methoden zu einem »Thema«, aber ohne Zugriff auf eine persistente Datenstruktur; er kann VMs benutzen. VM = View Manager, Broker, Maklermodul: verwaltet einen definierten Teil der Datenstruktur, empfängt einzelne Views (von oben) für die Ausgabe und liefert sie einzeln (nach oben) an die aufrufende Instanz … & ruft für die Batch-Verarbeitung (mindestens) einen DM auf, dessen Name und Selektor von der rufenden Instanz zur Objektzeit bestimmt wird – bei Bedarf, also fast immer, mit GW-Analysator. … beispielsweise noch: • standardisierter Modulprüfstand • Systematik für Datennamen (universelles Rezept bei D&W) • Trennung von View Managern (DB-nah) und »Sicht-Knechten« (Anwender-nah) als Realisierung von konsequent objektorientierter Architektur – aber mit konventionellen Mittel, ohne Smalltalk oder C++ usw. • Verwaltung von Varianten (anwenderbezogen) und Versionen/Releases (entwicklungsbezogen): Kofigurations-Management • Programmierstandards • Realisierung von zeitbezogenen Datenstrukturen – geht nur mit UVMT o.ä. • Gruppenwechselsteuerung (fast ein Fremdwort für alle Informatiker von Hochschulen und Universitäten der neueren Zeit) • Systematische Ausnahmebehandlung bei Zugriffsfehlern • Einschaltbarer Online-Trace im Echtbetrieb, wenn »rätselhafte Fehler« auftauchen • Standardisierter Verständigungsbereich zwischen den beiden obersten Schichten • … DM: mit maximal 98 Gruppenstufen (reicht garantiert) hat jeder Dienstmodul dieselbe Gruppenwechsel-Ablauflogik (GW), und der Programmierer hat einzig und allein – welches die Kunst ausmacht – Unterprogramme für Anfangs- und Enderoutinen auf den Hierarchiestufen und die Einzelverarbeitung zu schreiben. H. Dreßler Software-Architektur

Software-Architektur Beispiel eSQL SELECT …FROM …WHERE … ( immer wieder dieselben oder nur ganz ähnliche Formulierungen überall ) Und nun hier mitten drin jeweils viele Zeilen individueller, eingebetteter Verarbeitung der gerade aktivierten View-Menge (Set) bis zum END SELECT Ja, Himmel, Zwirn & Wolkenbruch, da kann doch nicht jeder mit seinen SELECTs (FINDs) in der Datenbank herum- fuhrwerken !!! Das ist anti- objekt- orientiert. betr. C) Mittel & Methoden Für alle Systeme, in denen Zugriffskommandos »embedded« sind, also SELECT (SQL) oder FIND u.a. (Natural) oder andere, läßt sich die UVMT in derselben Weise implementieren. Da kann es keine Beschränkung geben. Der Mechanismus ist überall derselbe. Es gibt dabei explizit keine Klassen (aus der reinen OO-Lehre) und keine Vererbung, sondern ihre Inverse: die Delegation. Der Effekt ist derselbe. : H. Dreßler Software-Architektur

Einschub zur Erläuterung: eine einfache Struktur View Manager ! Anwender-Logik Broker-Logik Anwender- Programm 1) Anwenderprogramm will auf Datenbank zugreifen View Manager ! blau: Datenfluß akuter Dienstmodul 3) Einer der möglichen Dienstmodule wird ausgewählt und verarbeitet eine Datenmenge (batch) View Manager 2) View Manager vermittelt mögliche Dienstmodule View Manager ! Kommentar: Es ist doch geradezu absurd, daß alle gebildete DV-Welt von »Objektorientierung« schwärmt und schwätzt, sie feierlich verkündet, aber, der Not gehorchend, für die eigentlich dicksten und größten Objekte sie eben gerade nicht beachtet: Jedes Stück Datenstruktur, das als Einheit zu verstehen ist, müßte doch als Objekt gelten, als Objekt mit »seinen« zugelassenen Methoden. Stattdessen navigieren alle Anwendungsprogrammierer, meistens mit SQL, in der Datenbank, »erfinden«, (besser:) beschreiben die jeweilige Teilstruktur immer wieder neu und verfassen undurchschaubar-gewaltige individuelle SELECT-Statements, die zu ändern kaum die Autoren in der Lage sind. Und wenn sich die Datenbank geändert hat, müssen sie alle diese Anweisungen in allen Programmen nachführen. Die Steinzeit läßt grüßen, auch der heilige St. Hollerithius winkt von ferne. – Es müßte doch möglich sein, dieses Dilemma grußlos zu verlassen und eine eigene Modularisierung zu erschaffen, die solche Beschränktheiten nicht mehr kennt. View Manager ! Teil der Datenbank H. Dreßler Software-Architektur

Neues SW-Architekturkonzept (2) … mausklick … AM.17 Die Dienstmodule stammen aus der Schicht-3, aber werden (zwangsläufig) in der Schicht-5 (SERVER!) eingesetzt. … ist aufgerufen … ruft auf: Die warten auf Beschäftigung AM.91 DM.65 … ruft auf: … ruft nun auf: DM.66 DM.67 VM.08 … SELECT und dynamische Bindung (…“greift sich einen“) VM.03 DM.68 DM.68 DM.69 DM.69 betr. B) Wege & Maßnahmen Module, Abstrakte Datentypen und schließlich Objekte dienen nur dann der Wiederverwendbarkeit, wenn man sie von vornherein daraufhin entwirft. Systemnentwurf sollte sich an solchen Vorstellungen orientieren. Wenn das geschehen ist, können die Schnittstellen bestimmt werden und die Dienste & Leistungen,, die ein Modul einem Aufrufer anbieten kann. In der Praxis ist ein Modul durch neue Methoden – in seiner bisher definierten »logischen Umgebung«– zu erweitern. Auch sind Versionen (zeitliche Weiterentwicklung) und Varianten (wenig verschiedene Dienste) für unterschiedliche Nutzer einfach und übersichtlich zu implementieren. … greift auf View zu, z.B. WRITE Zwischen SELECT und END SELECT Viele Zugriffe und Aufrufe …druckt Listen H. Dreßler Software-Architektur

Neues SW-Architekturkonzept (3) anderes Beispiel AM.92 … ruft nun auf: Diese Technik ist nicht selbstverständlich. … mausklick … … SELECT und dynamische Bindung VM.05 DM.67 …druckt „View-für-View“ Listen nach dem GRUPPENWECHSEL-Schema Zwischen SELECT und END SELECT Viele Zugriffe und Aufrufe … ruft auf: betr. A) Ziele & Defizite Ziele sind positive Nutzenkategorien, aber negativ ausgedrückt ist Nutzen auch vermiedener Schaden; den sollte man mit bedenken. Und durch erkannte Defizite, die ausdrücklich formuliert gehören, entstehen mögliche neue Nutzenarten. Alle zusammen ergeben das Potential für mögliche Ziele. Die tatsächlich anzustrebenden Ziele sollten – mit Begründung – ausgewählt werden. Und dafür gilt der Grundsatz: Mit dem geringsten Aufwand den größten Nutzen zu erzielen. Das ist ja geradezu selbstverständlich, wird aber oft nicht so gehandhabt VM.07 … greift auf einzelne Views zu, z.B. WRITE …und bucht o.ä. H. Dreßler Software-Architektur

UVMT . Datenstrukturentwurf ist ein EXTRA-Kapitel. – Fragen Sie uns! Dynamische Bindung … … der Dienstmodule, u.a. für GW-Batchverarbeitung im Server Diese Technik ist nicht selbstverständlich. Helmut Dreßler: Datenstrukturentwurf Vom Faktenchaos zur Anwenderdatenbank R. Oldenbourg Verlag München Wien 1995 288 Seiten DM/ sFr 98,- öS 765,- ISBN 3-486-21808-5 Restauflage: DM 48,– bei uns zu bestellen (inkl. Versand) Inhaltsverzeichnis Vorwort 1. Übersicht über die Begriffswelt 2. Objekttypen 3. Beziehungstypen 4. Das Entity-Relationship-Diagramm (ERD) 5. Relationen und Relationenalgebra 6. Datenstrukturen in Datenbanken und Dateisystemen 7. Leistungen eines modernen DBMS 8. Entwurfsziele: Anzustrebende Produkte & Ergebnisse 9. Ein kleines Beispiel (Chargen) 10. Beziehungskombinatorik 11. Entwurfsprinzipien und Modellbildung 12. Einzelne spezielle Aspekte 13. Ein großes Beispiel 14. View Manager und »Sicht-Knechte« 15. Navigation in Datenstrukturen 16. Implementierung einer Datenstruktur 17. Abschließende Überlegungen Literaturverzeichnis Index MODUL H. Dreßler Datenstrukturentwurf ist ein EXTRA-Kapitel. – Fragen Sie uns! Software-Architektur

Ultimative View Manager Technik …wenn sie einfach einzusetzen ist… Was ist das? Ultimative View Manager Technik Einige Ergänzungen der Eigenschaften stehen auf späteren Seiten. Ganz wesentlich ist die Tatsache, daß durch Aufrufprozeduren – kompiliert, benutzbar, versteckt (»Information Hiding«) – die UVMT-Modularisierung in Anwenderprogrammen extrem einfach gestaltet ist. Konventionen jeder Programm-Montage sind leicht zu implementieren, die Programmstrukturen werden einheitlich, und der bekannte »Batch-Wust« abgelöst durch ein universelles Schema. …wenn sie einfach einzusetzen ist… H. Dreßler Software-Architektur

  Client-/SERVER-Technik • UVMT = der Stein der Weisen!   Client-/SERVER-Technik • UVMT = der Stein der Weisen! Clients mit Proxies CORBA läßt grüßen VM.03-Stub VM.08-Stub Object Request Broker im Netz: Übergabe der VB + AB SERVER VM.08 VM.03 DM.68 Alle Welt stellt um, oder hat es vor, die alten Anwendungen auf Client-Server-Technik umzustellen, etwa R2  R3. Für die drei untersten Schichten bietet die UVMT die ideale Technik: Man braucht keinen künstlichen Stub, sondern hat dafür die UVMT-Schnittstelle mit simpler Stub-Erweiterung. Der SERVER führt die Zugriffe aus … und: Man kann ihn beauftragen, jedwede (auch Batch-) Verarbeitung auf Rechnung des Client durchzuführen … standardisiert, einfach und exakt in derselben Weise wie bei unvernetztem Rechner. Das wiederum hat gute Konsequenzen für die Umstellungs-Strategie. Die neue Architektur kann auf dem alten Rechner implementiert und getestet werden, und dann wird auf C/S umgestellt … und erneut getestet! Ultimative View Manager Technik H. Dreßler Software-Architektur

betr. C) Mittel und Methoden Die umfaßt: Broschüre: UVMT – Theorie und Praxis (Manual) UVMT-Einführungsseminar Definition der Standardschnittstelle mit Erläuterung UVMT-Montage-Prozeduren = simpler Aufruf, starke Leistung Standard- und Muster-Module (Listen und Sourcetextdatei) in einer Host-Sprache (Natural, Cobol, C, Java, …) Ablauffähiges Musterbau-System in der Host-Sprache Einführungsberatung (Entwurf und Betreuung beim Pilotprojekt) Review und Erfahrungs-Auswertung nach dem Pilotprojekt Ultimative View Manager Technik Copyright © by H. Dressler C unsere 8 Leistungen Wir gehen Kooperationen ein mit denjenigen, die in irgendeiner Systemumgebung nach unseren Rezepten das Verfahren implementieren, testen und es uns für den Vertrieb zur Verfügung stellen. H. Dreßler Software-Architektur

Lassen Sie sich ein Angebot unterbreiten! Ein Angebot umfaßt unsere 8 Leistungen: ◊ Handbuch ◊ Seminar ◊ Standard-Schnittstellen ◊ Montageprozeduren ◊ Mustermodule (frames) ◊ Musterbau-System ◊ Einführungsberatung ◊ Review ◊ … und/oder haben Sie Fragen ? Angaben zum System: Hardware Betriebssystem Programmiersprachen (Anwendungen) Programmiersprachen (DB-Zugriffe) Angaben zu • TP-Monitor • Client/Server • … Programmierumgebung Besonderheiten Wünsche Angaben zu Ihrer Firma: Name und Adresse Ansprechpartner Branche Erfahrungen mit Standards, CASE, Methodologien, Ideologie, Werkzeugunterstützung usw. Die Reihenfolge unserer Leistungen: • Einführungsseminar: Standardschnittstellen, Montagetechnik, View Manager, Dienstmodule, Darstellung »Musterbau« • … für die Teilnehmer: begleitendes Handbuch – allgemeiner Teil • Übergabe / Anpassung / Implementierung der Montageprozeduren in der Ziel-Programmiersprache (Zielumgebung) • Montage-Rezept = begleitendes Handbuch – spezieller Teil • Frames: Übernahme in die Musterbibliothek • Implementierung und Test »Musterbau« (individuell zu erweitern) • Beratung (Entwurfs-Unterstützung) bei einem Pilotprojekt • … • Review nach angemessener Zeit (Erfahrungen, Wünsche, Konsolidierung der Methode, evtl. individueller Ausbau, usw.) H. Dreßler Software-Architektur

Ende der © Präsentation • Danke! wenden Sie sich an: Dressler & Wagner Software Engineering Competence Ihr Beraterteam für die wesentlichen Aufgaben moderner Software-Entwicklung Helmut Dressler Lauteschlägerstr. 19 64289 Darmstadt Tel. 49.6151.715945 Fax 49.6151.788538 eMail: helmut.dressler@t-online.de Uwe Wagner Alsbacher Str. 45 64342 Seeheim-Jugenheim Tel. 49.6257.903348 Fax 49. 6257.903347 eMail: uwe.wagner@t-online.de  Geben Sie doch diese Präsentation weiter, bitte unverändert! Sie können sie auch für eigene Darstellungen verwenden oder gar »ausschlachten«, aber es wäre doch nur fair, wenn Sie Ihre Adressaten auf unsere ©Arbeit verwiesen. Version-1 Darmstadt, im Juni 1999 Version-2 Darmstadt, im Oktober 2000 Version-3 Darmstadt, im Juni 2001 Version-3.1 Darmstadt, im Juli 2001 Ende der © Präsentation • Danke! H. Dreßler Software-Architektur