16 Wiederverwendung von Software 16.0 Einführung Lernziele Vorteile der Wiederverwendung Nachteile der Wiederverwendung 16.1 Die Wiederverwendungslandschaft Wiederverwendungstechniken Auswahlkriterien 16.2 Anwendungsframeworks Definition Typen von Frameworks Frameworks und Entwurfsmuster

16 Wiederverwendung von Software (2) 16.3 Software-Produktlinien Anwendungsframeworks und Software-Produktlinien Spezialisierung in Produktlinien Architektur und Konfiguration 16.4 Wiederverwendung von COTS-Produkten Vorteile von COTS COTS-Lösungen COTS-Integration

16.0 Lernziele die Vorteile und Probleme der Wiederverwendung von Software bei der Entwicklung neuer Systeme kennen das Konzept von Frameworks für Anwendungen verstehen eine Vorstellung von Software-Produktlinien haben wissen, wie Systeme durch Konfigurieren und Zusammenstellen kommerzieller Anwendungen entwickelt werden können

16.0 Wiederverwendung Verwendung eines Artefakts in einem anderen Kontext in den Ingenieurswissenschaften üblich in der Softwaretechnik zunächst nicht im Fokus Fokus zunächst auf Entwicklung erste Überlegungen zur Wiederverwendung um 1985 im Fokus seit etwa 2000

16.0 Wiederverwendung von Software Wiederverwendung von Anwendungssystemen Wiederverwendung von Komponenten  Kapitel 17/19 Wiederverwendung von Objekten und Funktionen Wiederverwendung von Konzepten

16.0 Vorteile der Wiederverwendung Höhere Zuverlässigkeit Geringeres Risiko im Projekt Effektiver Einsatz von Spezialisten Übereinstimmung mit Standards Beschleunigte Entwicklung

16.0 Probleme der Wiederverwendung Höhere Wartungskosten Mangel an Werkzeugunterstützung Not-invented-here Syndrom Aufwand für Aufbau und Wartung einer Komponentenbibliothek Aufwand zum Suchen, Verstehen und Anpassen von wiederverwendbaren Komponenten

16.1 Wiederverwendungslandschaft

16.1 Wiederverwendungstechniken Architekturmuster Entwurfsmuster Komponentenbasierte Entwicklung Anwendungsframeworks Umhüllen von Altsystemen Serviceorientierte Systeme Softwareproduktlinien Wiederverwendung von COTS-Produkten ERP-Systeme Konfigurierbare vertikale Anwendungen Programmbibliotheken Modellgetriebene Entwicklung Programmgeneratoren Aspektorientierte Softwareentwicklung

16.1 Auswahlkriterien Entwicklungszeitplan Voraussichtliche Lebensdauer der Software Fähigkeiten, Hintergrund und Erfahrung der Entwickler Kritische nichtfunktionale Anforderungen Anwendungsbereich Einsatzplattform

16.2 Anwendungsframeworks Framework may refer to: Computers Enterprise Architecture Framework Architecture framework Software framework, a reusable set of libraries or classes for a software system (or subsystem) JavaScript and Ajax frameworks, Rich Internet application frameworks Application framework, used to implement the standard structure of an application for a specific operating system. Content management framework, reusable components of a Content management system used to manage web content Web application framework, for development of dynamic websites, web applications, and web services Multimedia framework, handles media on a computer and through a network

16.2 Anwendungsframeworks Framework-oriented design, a programming paradigm that uses existing frameworks as the basis for application design Framework (office suite), a DOS office application suite launched in 1984 to run on the original IBM PC. Framework III an integrated software package; its spreadsheet program. Government ... Education Other Uses (Wikipedia englisch, 27.03.2013)

16.2 Anwendungsframeworks In computer programming, a software framework is an abstraction in which software providing generic functionality can be selectively changed by additional user written code, thus providing application specific software. A software framework is a universal, reusable software platform used to develop applications, products and solutions. Software frameworks include support programs, compilers, code libraries, an application programming interface (API) and tool sets that bring together all the different components to enable development of a project or solution. (Wikipedia englisch, 27.03.2013)

16.2 Anwendungsframeworks Ein Framework (englisch für Rahmenstruktur) ist ein Programmiergerüst, das in der Softwaretechnik, insbesondere im Rahmen der objektorientierten Softwareentwicklung sowie bei komponentenbasierten Entwicklungsansätzen, verwendet wird. Im allgemeineren Sinne und nicht als dezidiertes Softwareprodukt verstanden, bezeichnet man mit Framework auch einen Ordnungsrahmen. (Wikipedia deutsch, 27.03.2013)

16.2 Anwendungsframeworks ... ein integrierter Satz an Softwareartefakten (wie Klassen, Objekte und Komponenten), die zusammenwirken, um eine wiederverwendbare Architektur für eine Familie von verwandten Anwendungen bereitzustellen. (Schmidt et al., 2004)

16.2 Anwendungsframeworks Größenmäßig zwischen Komponente und System Konkrete und abstrakte Klassen und deren Interaktionen sprachspezifisch Generische Struktur mit generischen Funktionen jeweils für bestimmte Typen von Anwendungen Implementierung einer bestimmten Anwendung Konkretisierung (Schnittstellen, abstrakte Klassen) Erweiterung (Vererbung)

16.2 Klassen von Frameworks Einteilung nach Sommerville Frameworks für Systeminfrastruktur Entwicklung von Systeminfrastrukturen wie Kommunikation, Benutzungsschnittstellen, Compiler Frameworks zur Integration von Middleware Standards und Objektklassen zur Unterstützung von Komponentenkommunikation und Informationsaustausch Unterstützung standardisierter Komponentenmodelle (EJB, .NET) Frameworks für Unternehmensanwendungen domänenspezifisch, z.B. Telekommunikationssysteme oder Finanzsysteme Webanwendungsframeworks

16.2 Typen von Frameworks Application Frameworks Domain Frameworks Einteilung nach Wikipedia deutsch, 27.03.2013 Application Frameworks bilden das Programmiergerüst für eine bestimmte Klasse von Anwendungen (horizontal slice), die Funktionen und Programmstrukturen bereitstellen, die bei allen Anwendungen dieser Klasse von Bedeutung sind. Domain Frameworks hingegen bilden das Programmiergerüst für einen bestimmten Problembereich (vertical slice), also Funktionen und Strukturen, die zur Lösung dieses Problembereichs typischerweise benötigt werden. Class Frameworks fassen Klassen und Methoden zusammen, die Unterstützung auf einer bestimmten Abstraktionsebene für ein breites Anwendungsfeld bieten.

16.2 Typen von Frameworks Komponenten-Frameworks Wikipedia Fortsetzung (1) Komponenten-Frameworks abstrahieren von der objektorientierten Ebene und bieten eine Umgebung zur Entwicklung und Integration von Software-Komponenten an. Software-Komponenten werden dabei meist als Bündel von Klassen mit eindeutig definierten Schnittstellen betrachtet. Coordination-Frameworks (wie z. B. Jini und UPnP) stellen Formen und Einrichtungen der Geräte-Interaktion zur Verfügung und dienen so in erster Linie deren nahtloser und skalierbarer Interoperabilität. Wenn beispielsweise ein „Jini-fähiger“ Drucker an ein Netzwerk angeschlossen wird, welches Jini verwendet, so kann er selbstständig anderen Geräten mitteilen, was für eine Art von Drucker dazugekommen ist – so dass andere Geräte sich jetzt dieser neuen Möglichkeit „bewusst“ sind.

16.2 Typen von Frameworks Tests Frameworks Webframeworks Wikipedia Fortsetzung (2) Tests Frameworks dienen zur Ausführung von (automatisierten) Softwaretests, besonders im Rahmen der testgetriebenen Entwicklung. Populäre Beispiele sind JUnit für Modultests oder Selenium zum Testen von Webanwendungen. Webframeworks sind ausgelegt für die Entwicklung von dynamischen Webseiten, Webanwendungen oder Webservices.

16.2 Abgrenzung der Frameworks kein fertiges Programm mehr als eine Klassenbibliothek Vorgabe einer Architektur / Anwendungsstruktur Wesentliche Merkmale Umkehrung der Steuerung (IOC, Inversion of Control) Standardverhalten (Default Behaviour) Erweiterbarkeit (Extensibility) Unveränderbarer Code (Non-modifiable Framework Code) (Wikipedia englisch, 27.03.2013)

16.2 Umkehrung der Steuerung Das Framework legt den Kontrollfluss fest Programmierer registriert konkrete Implementierungen Framework ruft diese auf Beispiel bei GUI Listener für Ereignisse Observer-Pattern Unterschied zu Bibliotheken Aufruf von Methoden durch das Programm Sonderfall Dependency Injection Registrierung nicht im Code, sondern „von außen“ „Hollywood-Prinzip“ Don't call us, we'll call you.

16.2 Webanwendungsframeworks (WAF) Erstellung von dynamischen Websites Frontends für Webanwendungen verfügbar in gängigen Web-Programmiersprachen Java, Python, Ruby etc. Architektur basiert auf MVC-Muster Benutzereingaben Steuerungszustand Steuerungsmethoden Modellzustand Modellmethoden Präsentationszustand Präsentationsmethoden Nachrichten zu Präsentationsänderungen Modellbearbeitungen Modellanfragen und Aktualisierungen

16.2 Model – View – Controller Architekturmuster für GUI Entwurf Verschiedene Präsentationen eines Objektes und getrennte Interaktionen mit diesen Präsentationen MVC-Muster kann als Framework betrachtet werden Implementierung verschiedener Entwurfsmuster, z.B. Observer Pattern Composite Pattern Strategy Pattern Funktionalität über Einschubmethoden (Hooks)

16.2 WAF-Funktionalitäten Sicherheit Benutzerauthentifizierung und Zugriffssteuerung Dynamische Webseiten Definition von Schablonen (Templates) und deren Füllung aus einer Datenbank Datenbankunterstützung abstrakte Schnittstelle zu verschiedenen Datenbanken Sitzungsverwaltung Verwaltung von Sitzungen als Zusammenfassung mehrerer Interaktionen des Benutzers mit dem System Benutzerinteraktion z.B. Verwendung von AJAX zur Validierung von Eingaben

16.2 Anwendungserstellung mit Frameworks Generisches Framework wird erweitert zu anwendungsspezifischem (Sub-)System Hinzufügen konkreter Klassen erben von abstrakten Klassen erben von konkreten Klassen Hinzufügen von Rückrufmethoden (callback) reagieren auf Ereignisse, die das Framework erkennt Probleme Komplexität der Frameworks Komplexität der Werkzeuge lange Einarbeitungszeit

16.2 Offenheit von Frameworks Black-Box-Framework definierte Schnittstelle des Frameworks Implementierung dahinter unbekannt White-Box-Framework Implementation des Frameworks ist vollständig sichtbar Implementation des Frameworks kann geändert werden Glass-Box-Framework Implementation ist gegen Änderungen gesichert

16.3 Software-Produktlinien Ausgangspunkt vorhandene Anwendung ähnlicher Anforderungsbereich Erzeugung einer neuen Anwendung durch Anpassung Folge: strukturelle Probleme Strategie generische Produktlinie Architektur mit unterschiedlichen Subsystemen, die geändert werden können

16.3 Software-Produktlinien Anwendungsfamilien gemeinsame Architektur gemeinsame Komponenten generische Funktionalität Anpassung an unterschiedliche Anforderungsprofile Konfiguration des Systems und der Komponenten Hinzufügen neuer Komponenten Auswahl von Komponenten aus einer Bibliothek Ändern von Komponenten

16.3 Frameworks und Software-Produktlinien Objektorientierung Frameworks stützen sich auf objektorientierte Konzepte Framework-Code bleibt in der Regel unverändert Anwendungsfamilien müssen nicht objektorientiert sein Komponenten-Code wird geändert, gelöscht, neu geschrieben Unterstützter Bereich Frameworks eher technisch Produktlinien eher domänen- und plattformspezifisch Hauptanwendungen Produktlinien häufig hardware-orientiert (z.B. Druckertreiber) Frameworks eher software-orientiert Ausgangspunkt der Entwicklung bei Produktlinien meist das ähnlichste Mitglied der Familie bei Frameworks in der Regel das Framework

16.3 Spezialisierung bei Software-Produktlinien Phase 1: Kern der Produktlinie erzeugen häufig aus einem Framework Erweiterung insbesondere durch fachliche Komponenten Phase 2: Spezialisierte Familienmitglieder erzeugen Plattformspezialisierung Betriebssystem, Hardware Umgebungsspezialisierung Einsatzumgebung (z.B. Kommunikationsmittel), Peripheriegeräte Funktionale Spezialisierung unterschiedliche Kundenanforderungen (z.B. Groß- / Einzelhandel) Prozessspezialisierung unterschiedliche Geschäftsprozesse (z.B. zentral / dezentral)

16.3 Vorgehen für eine neue Anwendung Anforderungen der Beteiligten ermitteln Wahl der am besten passenden Systeminstanz ggf. Anforderungen nachverhandeln vorhandene Instanz anpassen neue Instanz ausliefern

16.3 Konfiguration bei Produktlinien Konfiguration zur Entwurfszeit Veränderungen im Kern der Produktlinie Einbringung kundenspezifischer Komponenten Konfiguration zum Bereitstellungszeitpunkt keine Veränderungen am Code Konfiguration durch Berater oder Kunden Konfigurationsdateien

16.3 Konfigurationswerkzeug Komponentenauswahl Module mit erforderlicher Funktionalität Ablauf- und Regeldefinition Workflow für Information Validierung von Information Parameterdefinition von Systemparametern (z.B. Kenndaten der Hardware) bis zu Oberflächenparametern (z.B. Feldlänge in Formularen)

16.4 Wiederverwendung von COTS-Produkten COTS = commercial of the shelf im Handel erhältliche Software-Produkte Anpassung für Kunden ohne Änderung am Quellcode Quellcode in der Regel nicht einsehbar (Ausnahme Open Source) umfangreiche generische Funktionalität einsetzbar in verschiedenen Umgebungen eingebaute Konfigurationsmechanismen Anpassung an spezielle Kundenbedürfnisse

16.4 Vorteile bei COTS-Wiederverwendung kürzere Entwicklungszeit für ein zuverlässiges System nur Konfigurierung, nicht Programmierung leichtere Beurteilung der Funktionalität Referenzinstallationen weniger Ressourcen für IT im Unternehmen nötig Konzentration auf das Kerngeschäft Updates in Verantwortung des Anbieters z.B. bei Weiterentwicklung der Betriebsplattform

16.4 Probleme bei COTS-Wiederverwendung Anpassung der Anforderungen an die Funktionalität was nicht vorhanden ist, kann nicht genutzt werden Vorgabe von Geschäftsprozessen durch die Software Software basiert auf Annahmen über Aktivitäten Schwierige Auswahl des passenden COTS-Produkts oft nicht ausreichende Dokumentation Fehlendes fachliches Wissen vor Ort Abhängigkeit von Kundenservice oder externen Beratern Abhängigkeit vom COTS-Anbieter z.B. Einstellung des Produkts, Übernahme, Konkurs

16.4 Arten der COTS-Wiederverwendung COTS-Lösung COTS-Integration einzelnes Produkt mit vom Kunden benötigter Funktionalität Integration mehrerer heterogene Systemprodukte zur Erreichung der benötigten Funktionalität basierend auf generischer Lösung und standardisierten Prozessen flexible Lösungen für Kundenprozesse Entwicklung hauptsächlich Konfiguration Entwicklung hauptsächlich Integration Systemanbieter verantwortlich für die Wartung Systembesitzer verantwortlich für die Wartung Systemanbieter liefert die Plattform für das System Systembesitzer liefert die Plattform für das System

16.4 COTS-Lösungen Generische Anwendungssysteme zur Unterstützung von Geschäftsaktivität Geschäftstyp Geschäftsunternehmen -> ERP Fachbereichsspezifische Funktionalität Nutzung durch möglichst viele potentielle Benutzer Annahmen über Arbeitsweise Konfiguration Einstellungen statt Programmierung schwierig zu testen

16.4 ERP-Systeme Enterprise Resource Planning Systeme große integrierte Systeme generische Unterstützung für Geschäftsaktivitäten Auftragserteilung Rechnungswesen Lagerhaltung Produktionsplanung wohl häufigste Form der Software-Wiederverwendung Anpassung an Kundenbedürfnisse Auswahl benötigter Module Konfiguration der Module Definition von Geschäftsprozessen und –regeln Struktur der Systemdatenbank

16.4 Architektur eines ERP-Systems Einkauf Lieferkette Logistik Kundenpflege Systemdatenbank Geschäftsregeln Prozesse

16.4 Architekturmerkmale von ERP-Systemen Module zur Unterstützung von Geschäftsfunktionen große Module für komplette Geschäftsbereiche Festgelegter Satz von Geschäftsprozessen für jedes Modul Festlegung der Aktivitäten und Rollen Gemeinsame Datenbank Daten für alle Geschäftsfunktionen ohne Replizierung Festgelegte Menge von Geschäftsregeln Validierung und Konsistenz der Datenbank

16.4 Konfiguration von ERP-Systemen Auswahl der erforderlichen Funktionalität Erstellung des Datenmodells der Systemdatenbank Definition von Geschäftsregeln für die Daten Definition der Interaktionen zu externen Systemen Entwurf der Eingabe- und Berichtsformulare Entwurf neuer passender Geschäftsprozesse Festlegung der Parameter für die Einsatzplattform

16.4 COTS-Integration Anwendungen aus zwei oder mehr COTS-Produkten oder Altanwendungen wenn kein einzelnes COTS-System alle Anforderungen erfüllt wenn neue Funktionalität in vorhandene Umgebung integriert werden soll Integration über Dienstschnittstellen oder APIs Verbindung von Ausgabe zu Eingabe Aktualisierungen der jeweiligen Datenbanken

16.4 COTS-Integration: Entwurfsentscheidungen Welche COTS-Produkte eignen sich am besten? Funktionalität in mehreren Produkten häufig mehrere Kombinationsmöglichkeiten Wie werden Daten ausgetauscht? oft proprietäre Datenstrukturen und –formate Adapter zur Umwandlung erforderlich Welche Funktionen werden tatsächlich verwendet? häufig mehr Funktionalität als nötig oft gleiche Funktionalität redundant in mehreren Produkten nicht benötigte Funktionen als mögliche Fehlerquellen

16.4 Szenario zur COTS-Integration Beschaffungen in einem Unternehmen Stand zentraler Einkauf nach Anforderung aus der Abteilung Nutzung eines Bestell- und Fakturiersystems Ziel Abwicklung der Bestellungen vor Ort dezentral über das Web Vorgehen Anbindung eines E-Commerce-Systems via Adapter Anbindung eines E-Mail-Systems via Adapter Client mit Browser und Mail als COTS-System

16.4 Szenario zur COTS-Integration Client Webbrowser E-Mail-System Server E-Commerce-System E-Mail-System Bestell- und Fakturiersystem Adapter

16.4 Serviceorientierte COTS Integration Einfachere Integration durch Dienstschittstellen Standarddienstschnittstelle für Funktionalität jeweils ein Dienst für jede Funktionalitätseinheit Implementation einer Dienstschnittstelle Wrapper verbirgt Anwendung und stellt Dienste bereit insbesondere bei Altsystemen sinnvoll Dienste-Wrapper Anwendungssystem Dienst

16.4 Probleme der COTS-Integration Mangel an Kontrolle über Funktionalität und Leistung Diskrepanz zwischen Beschreibung und Programmierung Probleme mit der Interoperabilität von COTS-Systemen unterschiedliche Modelle, fehlende Standards Keine Kontrolle über die Evolution des Systems neue Versionen nicht immer kompatibel Unsichere Unterstützung durch die Anbieter Einstellung oder Übernahme des Produkts