Technologische Besonderheiten in langlebigen Softwareprojektenst.inf.tu-dresden.de/files/teaching/ss08/ring/Vorlesungcsc.pdf · Design-Prinzipien 2 KISS-Prinzip („keep it small

Technologische Besonderheiten in langlebigen Softwareprojekten

Fakultät Informatik, Ringvorlesung im Studium generale„Softwareentwicklung in der industriellen Praxis“Dresden, 2.6.2008, Dr. Jörg Hutschenreiter

Summary:Software, die im Kerngeschäft eines Unternehmens unmittelbar zum Einsatz kommt, ist niemals "fertig". Sie muss und soll so, wie sich das Unternehmen selbst am Markt und in seinen Geschäftsprozessen weiterentwickelt, dieser Entwicklung folgen bzw. diese sogar mit befördern. Im Dresdner Kompetenzzentrum Logistik der CSC Deutschland Solutions GmbH werden seit 15 Jahren erfolgreich Software-Projekte im Bereich der schienengebundenen Transportlogistik realisiert, betreut und weiterentwickelt. Dies umfasst den gesamten Software-Lebenszyklus von den Projekt-Ideen bis hin zur 7x24h-Betreuung der Produktivsysteme. Dabei verändern sich auch die für den Hersteller der Software wesentlichen Randbedingungen (Hardware, Betriebssysteme, Programiersprachen, Werkzeuge, Infrastrukturen), so dass die Frage entsteht, was denn dann die Fixpunkte einer Software-Architektur sein können, um über geradezu historische Zeiträume ein Software-Projekt am Leben zu halten, ohne dies mit teuren Redesign-Prozessen oder fortlaufend instabiler Software bezahlen zu müssen.Dabei sind ständig auch nicht einfache Entscheidungen für oder gegen eine Technologie, für oder gegen den Einsatz eines Werkzeuges zu treffen. Auch das "Wie" einer Integration einer neuen Technologie-Komponente ist genau abzuwägen. Dabei gibt es, wie zu vermuten, kein Universalrezept, wohl aber durchaus objektivierbare Kriterien. Im Vortrag werden solche Kriterien vorgeschlagen und mit den praktischen Erfahrungen des Autors motiviert.

Technologische Besonderheiten in langlebigen Softwareprojekten

● Vorstellung, Charakterisierung der Projekte

● Die Herausforderung - das Problem des (über-)lebensfähigen Designs

● Die Randbedingungen

● Chancen zur Nachhaltigkeit von Design und Tool-Einsatz

● Momentaufnahmen aus der eigenen Praxis

● Resümee

Jörg Hutschenreiter, Technologische Besonderheiten in langlebigen Softwareprojekten, 2.6.2008

● 1975-1980 Mathematikstudium TU Dresden (WB MKR)

● 1980-1993 Wiss. Assistent,

– Forschungsgruppe „Programmierungssprachen und höhere Programmierungstechnik“,

– Fachsprachensystem DEPOT,

– Promotion bei N.J.Lehmann („Zur Pragmatik von Fachsprachen“),

● seit 1994 bei CSC Deutschland, heute in der Rolle „Solution Architect“,

● Dr. Jörg Hutschenreiter, CSC Deutschland Solutions GmbH, Bergstraße 2, 01069 Dresden, [email protected]

Vita


CSC in Deutschland(http://de.country.csc.com/de)

Die Branche Transportation ... (http://de.country.csc.com/de -> Branchen -> Transportation – Link „Transportation Management CP BIS)

http://de.country.csc.com/de

... das Kompetenzzentrum Logistik der CSC Deutschland Solutions GmbH in Dresden

● 1991 gegründet mit wenigen Mitarbeitern der damaligen Hochschule für Verkehrswesen

● heute ca. 30 Mitarbeiter (Consulting und Software-Entwicklung)

● spezialisiert auf Leitstellensoftware für den schienengebundenen Verkehr (private Eisenbahnen, Werksverkehr, mehr und mehr auch Eisenbahnverkehr einschl. SPNV, einige Projekte im ÖPNV)

● Bergstraße 2, 01069 Dresden, Tel. 0351.477710

● Mit einem durchgängigen Leistungsportfolio:


Plan Run

Geschäfts- vision

und-strategie

Geschäfts-prozesse

IT- Strategie

und-Architektur

Anwen-dungs-

planung

System-entwick-

lung

System-manage-

ment

Build

Referenzkunden für Leitsysteme

VOEST ALPINE Chemiepark Linz

Ludwigshafen Antwerpen Schwarzheide

Ingolstadt Neckarsulm Győr

Wolfsburg Mosel Bratislava Braunschweig Hannover Emden Kassel Salzgitter

Dresden Augsburg

Osnabrück

Schwedt

Peine Salzgitter Ilsenburg

Dortmund Bochum Dillenburg Benrath

Dortmunder Eisenbahn

Neuss-Düsseldorfer Häfen

Neuss

Gütersloh Eisenhüttenstadt

Marl Bern

Linz

Ballungsraum Oberes Elbtal

Dresden

Bremen


Einordnung der Software-Projekte● je nach Projektphase 2 – 8 Mitarbeiter

● ca. 0,5 – 5 Mio LoC, Datenbankenvolumen 1-20 GB, 5-30 Arbeitsplätze,

● große Zahl von Fachmoduln mit kundenspezifischen Anpassungen

● mit vielen Schnittstellen zu Umsystemen (in Summe >150)

● ausgefeilte graphische Nutzeroberflächen

● langjährige Zusammenarbeit mit dem Kunden

● in unterschiedlichen Hard- und Software-Umgebungen lauffähig

● Plan-Build-Run bis 7x24h-Rufbereitschaft ist abzudecken

● Individual-Entwicklung mit ganz spezifischen Anforderungen

● Es handelt sich um Fachapplikationsentwicklung (in gewisser Abgrenzung von der Entwicklung z.B. von System-, Unterhaltungs- oder Standard-Software)


Kennzeichen für Fachapplikationsentwicklung

● Der Fokus liegt auf der Lösung fachlicher Probleme und Aufgaben einer bestimmten Branche.

● Es ist ein tiefes Verständnis der Geschäftsprozesse des Kunden, der Verwaltung seiner Daten, erforderlich.

● Software ist in zentrale Geschäftsprozesse des Kunden einzubinden. Es ist Individualsoftware aufgrund der Individualität der Geschäftsprozesse des Kunden.

● Es gibt weder einfache noch abgeschlossene vollständige Modelle.

● Es gibt eine große Zahl von Schnittstellen zu Umsystemen.

● Software ist in eine gewachsene IT-Landschaft zu integrieren.

● Software unterliegt ständiger Weiterentwicklung, Design muss zukunftssicher sein.

● Solche Software ist relativ teuer, muss aber auch im Wettbewerb bestehen.


Fachliche Vielfalt 1 - RBL DVB – Funktionsmodule Leitstellensoftware

Fahrplanung und GIS

Funk und Fahrzeuge

Betriebshofdisposition

Taxi-Leitsystem

zu anderen Leitsystemen nach VDV-Standard 453 und 454

Dynamische Haltestellenanzeiger

Anzeige von Fahrten anderer VU und mehrere Haltestellenbereiche

Datenbereitstellung nach VDV 454 für SMS-Verbindungsauskunft

Datenverwaltung Fahrzeugüberwachung Schnittstellen

24-Stunden-Hotline inkl. Monitoring/Anwenderberatung

DV-Betriebsführung (Server, DBMS, Datenmodell)

Wartung/Pflege/Anpassungen

Ereignisbearbeitung Daten-/Sprechfunk Routeneditor Maßnahmenkatalog Umleiten / L/K-Mutationen

Stammdatenverwaltung

Fahrplandaten

Fahrzeugdaten

Betriebsdaten

Standortverfolgung Fahrplan Soll-/Ist-Vergleich Netzdarstellung / Bildfahrplan Linienband / Fahrzeugtabelle Verfrühungsüberwachung

Fahrplanübersichten

Betriebstagebuch

Statistikanwendung zur Auswer- tung verkehrlicher Kenngrößen

RBL-Leitstelle

Disposition / Störungsbearb.Übersichten und Statistiken

Anschlussmanagement Steuerung Fahrgastinformation Service-Organisation

interne Anschlusssicherung VU-übergreifende

Anschlusssicherung Kommunikationsschnittstelle

nach VDV 453

Fachliche Vielfalt 2 - Module für Leitsysteme in der schienen-gebundenen Logistik

Stammdaten-verwaltung

Schnittstellen-management

AuswertungenStatistik

Auftrags-management

Kondi-tionen-

verwaltung

Kunden-daten-

verwaltung

Rahmen-verträge

TPABahn-

Logistik

TPAEVU Offerten

Ressourcen-planung

undÜber-

wachung

Trassen-mana-

gement

Leistungsauf-träge Werks-rangierdienste

Rangier-fahrten

Ladestellen-bedienung

Eingangs-/Ausgangs-

Zugbehandlung

Leistungsauf-trägeEVU-Verkehre

Zugbildung/-auflösung

Zug-fahrten

Neben-leistungen

AbrechnungLeistungs-aufträgebewerten

Verkaufs-leistungenabrechnen

Einkaufs-leistungenabrechnen

Vorkontierungdurchführen

Rechnungerstellen

Die Herausforderung für den Software-Architekten

● Alle wichtigen Designentscheidungen müssen nachhaltig sein, d.h. so, dass eine kontinuierliche Weiterentwicklung der Software ohne teure Redesign-Phasen jederzeit gewährleistet werden kann.

● Die eingesetzten software-technischen Mittel müssen „einfach“ handhabbar, robust und ausfallsicher sein, software-technische Finessen sind grundsätzlich sekundär.

● Das Design muss aber trotzdem offen sein für künftige Weiterentwicklungen.

Der Faktor Zeit birgt latent die Gefahr der „technologischen Sackgasse“.


Randbedingungen dieser ProjekteMitte der 90-er Jahre

● Ein typischer PC: Windows 3.11, Pentium 200 MHz, Grafik 800x600, 80MB Festplatte

● kommerzielle Unixe (HP UX, AIX, Digital Unix, ...) als teure Server-BS

● Linux war etwas für Insider, SCO Unix verfügbar

● Schon 64-Bit-Unix-Workstation (DEC 3000)

● Kaum Alternativen zu C/C++, aber C++-Compiler z.T. noch mit schwerwiegenden Bugs (Mehrfachvererbung, Templates)

● Java wird erst geboren

● Kaum entwickelte Frameworks: X11, OSF-Motif, ESQL; für Unix keine preiswerte IDE


Randbedingungen dieser Projekteab 2000

● von der Leistungsfähigkeit her gesehen stehen die ehemaligen Server nun als PC unter dem Schreibtisch

● Linux beginnt, praxisreif zu werden

● Unix-Workstations werden zu teuer, im PC-Bereich dominiert Intel-Architektur,

● Java etabliert sich

● C++ stagniert

● Windows wird ein Betriebssystem, auch auf dem Server

● komplexe Frameworks und Werkzeuge entstehen, vor allem im Java-und C#-Umfeld


Entwicklungsumgebung, der Arbeitsplatz des Entwicklers – eigenes Erleben

● Anforderung: Entwicklung für verschiedene Plattformen muss möglich sein, optimal aber Plattformunabhängigkeit der IDE selbst (z.B. für Debugging)

● SNiFF+ (1995 (Fa. TakeFive) - ca. 2001, heute leider tot), kommerzielle, werkzeug-offene IDE mit klar modellierten Grundbegriffen des Entwickler-Alltags:

– Projekt (einschl. Projekt-Hierarchien),

– Plattform,

– Workspace, Working Environment,

– File Type;

– Komfortable Quellcode-Verwaltung auf Basis RCS

● Eclipse (Java: top, C/C++: flop), Subversion

● Alternativen, Entwicklungen?Jörg Hutschenreiter, Technologische Besonderheiten in langlebigen Softwareprojekten, 2.6.2008

Die rasante Entwicklung der Technik befördert einen enormen Ausstoß an neuen Ideen, Ansätzen, Technologien für die schon lang bekannten Probleme der Software-Technologie.


OODMDA

Web-Services

SOA

CASE

XP

SA

UML

DSM

J2EE

SaaS

ASP

AOP

SOAPCorba

OOPOO DB

komplex schnelllebig

durch verschiedenste Interessen vorangetrieben

Das Universum der Software-Technologie

DSM

So viele Lösungen, wo ist denn da noch das Problem?

Persönlicher Eindruck

● Es sind oft Tendenzen der Vereinnahmung des gesamten Software-Entwicklungsprozess zu beobachten, verbunden mit der mangelnden Integrationsfähigkeit der Werkzeuge und Laufzeitumgebungen.

● Die unterschiedlichen kommerzielle Interessen der Werkzeughersteller und der Werkzeuganwender bieten ein dauerhaftes Spannungsfeld. Manch vielversprechendes Produkt/manche Ansätze und Ideen bleiben aus kommerziellen Gründen auf der Strecke.

● Plumpe PR (Versprechen wie „Softwareentwicklung ohne Kenntnis einer Programmiersprache“) verbirgt manchmal den wahren Kern und potienziellen Nutzen.

● Die Überstrapazierung diverser Ansätze birgt die Gefahr, in technologische Sackgassen zu geraten.

● Der Regenschirm wird ziemlich oft wiedererfunden und dabei nicht unbedingt immer besser - manchmal aber doch.


Eine gesunde Skepsis ist manchmal angebracht.

Sei misstrauisch,

● wenn Dir die eierlegende Wollmilchsau versprochen wird;

● wenn Dir versprochen wird, Du musst nicht programmieren können;

● wenn Dir versprochen wird, dass Du mit dem Tool keine Fehler mehr machen kannst;

● wenn früher ganz einfache Dinge auf einmal furchtbar kompliziert werden.


Zwischenresümee

● Die Entwicklung des IT-Umfeldes ist so rasant, dass die Hoffnung auf eine immer nur kontinuierliche Entwicklung ohne größere Brüche illusionär bleibt.

● Eine Orientierung in der kaum überschaubaren Vielfalt der Entwicklung bietet im Grunde genommen nur das eigene Grundlagenwissen, die Frage nach dem „Ding an sich“.

● Aber: IT ist keine Zauberkunst, es wird immer nur mit Wasser gekocht. Alles Geniale ist einfach!


Was hat sich als „einigermaßen“ nachhaltige Grundlage erwiesen?

● die etablierten, auf allen Plattformen verfügbaren, universellen Programmiersprachen (C/C++, Java) einschließlich verfügbarer APIs

● relationale Datenbank-Management-Systeme (die einzigen dauerhaft beherrschbaren Persistenz-Backends)

● wenige ziemlich abstrakte Design-Prinzipien

– objektbasierte/-orientierte Modellierung und Programmierung

– modulare Programmierung (zu unrecht fast in Vergessenheit geraten oder mit Verweis auf Klassen abgetan)

● das Wissen des Software-Ingenieurs, die Grundlagen seines Fachgebiets


Bemerkung zur Objektorientierung● persönliche Einschätzung: heute eines der am meist

missverstandenen Paradigmen

● OO-Sprachmittel werden oft auf Hilfsmittel zur Realisierung Software-technischer Lösungen reduziert, vergessen wird der Grundgedanke, dass es sich bei OO um eine Denkweise handelt, um das Abbilden eines Abstraktionsprozesses im Rechner. Die Bildung der richtigen Abstraktionen ist die Chance, spätere Widersprüche im Design zu vermeiden.

● Beispiel: Eclipse – eine „Fachapplikation“ für das Anwendungsgebiet Software-Entwicklung:

– Alles ist ein Plugin. Programm-technisch hochentwickeltes Framework, saubere und zweckmäßige Anwendung diverser Pattern. Plugin-APIs und RCP-Framework zu empfehlen für das Studium der Anwendung von OO-Techniken.

– ABER: keine adäquat entwickelten, programmiersprach-übergreifenden Modellbildungen für die Realität, der in der IDE abgebildet wird („Projekt“, „Workspace“, „Plattform“).

– Folge: Probleme bei mehrsprachlichen Projekten.Jörg Hutschenreiter, Technologische Besonderheiten in langlebigen Softwareprojekten, 2.6.2008

Bemerkung zu modularer Programmierung – veraltet oder alte Weisheit?

● Vorweggenommen: Die Ideen der modularen Programmierung stellen wie vor ein modernes, universelles Strukturierungsprinzip für Software da.

● Java und C++ bieten die Möglichkeiten, modular zu programmieren, ohne aber unmittelbare Sprachmittel zur Verfügung zu stellen. Klassen sind keine Moduln.

● Modularisierung und Objektorientierung beinhalten teilweise gegensätzliche Tendenzen! (Kapselung versus Vererbung)

● Das Prinzip der Modularisierung ist verallgemeinerbar auf verschiedene Ebenen anwendbar

– starke Kopplung auf der Ebene des Kodes in einer Programmiersprache, in der Praxis oft zu eng

– schwächere Formen der Kopplung (Services)

● „Die Zerlegung eines Problems ist die Lösung des Problems.“


Design-Prinzipien 1

● Fachlich orientierte OO-Modellierung.

● Hoher Eigenanteil an POJOs/POCOs.

● Einfachstmögliche Schnittstellen zur Lösung technischer Probleme nutzen; Klarheit und Robustheit haben das Primat.

● Sollbruchstellen schaffen für preiswerten Ersatz und/oder ggf. notwendigen Eingriffe zur Behebung technischer Probleme (Performance, Bugs, Releasewechsel), die (Murphy!) immer und überall auftreten können.


Design-Prinzipien 2

● KISS-Prinzip („keep it small and simple“)

● Strukturen schaffen auf jeder Ebene („Teile und herrsche“), Auswirkungen von Kode-Änderungen begrenzen („Lokalitätseigenschaft“ für Quelltexte)

● Integration von Fremdsoftware immer über eine Schnittstelle

● Fehler werden passieren, daher

– testfähigen Kode schreiben

– so zeitig wie möglich im Entwicklungsprozess testen

– Teststrategie planen, insbesondere auch Komplextests

– die Entwicklungsetappen so planen, das immer mehr lauffähige, aufeinander aufbauende Moduln entstehen.

● Prinzip des defensiven Programmierens, Vermeiden von „sophisticated techniques“ .


Kriterien für den Einsatz einer (toolbasierten) Technologie

● Besteht sie eine Aufwand-Nutzen-Analyse (Beschaffungs- und laufende Kosten, z.B. auch für Qualifikation) versus absehbare Rationalisierungseffekte

● Muss ich mich mit dem Tool verheiraten? Was passiert, wenn das Tool ausfällt?

● Ist sie allgemein im Team verwendbar oder brauche ich einen Guru?

● Wie passt sie in die vorhandene Landschaft – besteht Integrationsfähigkeit?


Anforderungen an brauchbare Tools

● Der interessierende technologische Ansatz muss in einem Tool auch handwerklich praktikabel umgesetzt sein.

● Das Tool muss eine konkretes Problem lösen, dies sichert seinen dauerhaften Einsatz. Es darf darüber hinaus auch noch mehr bieten.

● Es muss die Sicherheit bestehen, dass auftretende Probleme mit dem Tool (trotz vielleicht auftretender Bugs und funktionaler Einschränkungen) auch gelöst werden können.


Praxis 1 – zurück zu 19941994: Client-Server-

Architektur, Unix, X11, OSF/Motif,

Entwicklung vollständig in C, C++-Kenntnisse noch nicht so weit verbreitet

in X11 elementar aus-programmierte Grafik,

ausreichende Usability nur mit einigen Tricks erreicht

Datenbankzugriff über natives Protokoll, ESQL

Basis für weitere Projekte


Praxis 2 – Auswertung der ersten Erfahrungen

Ab 1997 neues Projekt mit erheblich größeren Anforderungen an die GUI-Performance


Einsatz von C++ und einer kommerziellen Grafik-Bibliothek (Ilog Views)

ausgefeilte oo-Präsen-tationslogik

Einführung abstrakter Schnittstellen zu Daten-bank und GUI

Komponenten-basiertes Systemdesign

einheitlicher Kommunikations-mechanismus zwischen den Funtkionsmoduln

Praxis 3 – neue Anforderungengleichzeitiges Projekt mit der Anforderung, zum „Rich Client“ noch ein

Browser-GUI zu liefern – neues Problem: Wohin mit der Fach-Logik?


Einsatz von WebObjects (Apple),

Entscheidung, Stored Procedures zu verwenden (PL/SQL)

kommerziell erfolgreiches Projekt

software-technologisch strategisch proble-matisches Design (DBMS-Abhängigkeit, Programmieren unmittelbar auf relationalen Daten)

Praxis 4 – ein neues globales Design● im Jahr 2001: Ansatz für eine Drei-Schichten-Architektur mit einer in

Java geschriebenen Logikebene, zwei Aufgaben:

– Framework für Logikebene finden,

– Kommunikation Rich Client – Logikebene klären.

● bewusste Entscheidung gegen J2EE, aber Notwendigkeit einer Standard-Laufzeit-Umgebung (Application-Server)

● Ergebnis: Mittelschicht als WebService mit genau einer Funktion: byte[] call(byte[]),

– SOAP als Träger eines eigenen Request-Response-Protokolls auf der Basis einer selbst entwickelten Serialisierung einfacher Datencontainer,

– eigenes DB-Zugriffs-Framework für Mittelschicht (auf der Basis JDBC, weitestgehend DBMS-unabhängig),

– die 3,5-te Schicht kann nunmehr konfliktfrei bei Bedarf ergänzt werden.

● Applikation als Standard-WebService unter beliebigen WAS deployfähig Jörg Hutschenreiter, Technologische Besonderheiten in langlebigen Softwareprojekten, 2.6.2008

Praxis 5 - ToDoaktuelle Aufgaben

● Weiterentwicklung der Mittelschicht in Hinblick auf projektspezifische Anforderungen

● Verbesserung der Performance bei Datenbank-lastigen Teilaufgaben (große Datenmengen)

● Erhöhung der Flexibilität bei CPU-lastigen Teilaufgaben durch Einführung entsprechender Pattern

● Gefahr eines prinzipiell notwendigen Architektur-Bruchs nicht in Sicht, in vielen Projekten bereits bewährt

Daueraufgabe

● Pflege dieser Architektur


Praxis 6 – offene FragenTechnisch:

● Wann erreichen die Java-Laufzeitumgebungen (JVM + Application-Server) die gleiche Robustheit die die der C/C++-Software (das Betriebssystem)?

● Wann wird Java reif für den Client? Wie sieht ein technisch befriedigendes Web-GUI-Toolkit aus?

ungelöste technologische Aufgaben

● Suche nach Tools, die die Kluft zum Fachdienst schließen und die in der Anforderungsanalyse und/oder Pflichtenheft-Erarbeitung entstehenden Ergebnisse unmittelbar in den Software-Entwicklungsprozess integrieren können.

● Alle Versuche sind bisher gescheitert wegen der ungenügenden Rückkoppelfähigkeit bei in späteren Projektphasen entstehenden Änderungen.

● Persönliche Hoffnung: Domain Specific Modelling


Resümee auf den Weg● Software-Entwicklung in der Praxis ist ein vielschichtiger,

von den verschiedensten äußeren Einflüssen getriebener, alles andere als glatt verlaufender Prozess - das ahnst Du vielleicht schon.

● Software-Entwicklung ist trotzdem eine spannende Sache.

● Software-Entwicklung ist keine Zauberkunst.

● Stell alles in Frage, solange Du es nicht verstanden hast. Wenn etwas unklar erscheint, muss es nicht an Dir liegen. Glauben ersetzt kein Wissen.

● Erfahrung heißt, genügend Fehler selbst gemacht und verstanden zu haben, nimm Dir die Zeit!

● Nutze alle Chancen, Neues und Dich auszuprobieren.

Viel Erfolg!Jörg Hutschenreiter, Technologische Besonderheiten in langlebigen Softwareprojekten, 2.6.2008

Documents

Technologische Besonderheiten in langlebigen Softwareprojektenst.inf.tu-dresden.de/files/teaching/ss08/ring/Vorlesungcsc.pdf · Design-Prinzipien 2 KISS-Prinzip („keep it small