© Prof.Dr. Andreas M. Heinecke, WHS Gelsenkirchen. Wissen. Was praktisch zählt. Stand: 08.04.13 Folie 16.1 Software-Engineering SS 2013 – Alle Master-Studiengänge

© Prof.Dr. Andreas M. Heinecke, WHS Gelsenkirchen.

Wissen. Was praktisch zählt.

Stand: 08.04.13 Folie 16.1

Software-Engineering SS 2013 – Alle Master-Studiengänge der Informatik

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



Stand: 08.04.13 Folie 16.2


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



Stand: 08.04.13 Folie 16.3


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



Stand: 08.04.13 Folie 16.4


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



Stand: 08.04.13 Folie 16.5


16.0 Wiederverwendung von Software

Wiederverwendung von Anwendungssystemen Wiederverwendung von Komponenten Kapitel

17/19 Wiederverwendung von Objekten und Funktionen Wiederverwendung von Konzepten



Stand: 08.04.13 Folie 16.6


16.0 Vorteile der Wiederverwendung

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



Stand: 08.04.13 Folie 16.7


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



Stand: 08.04.13 Folie 16.8


16.1 Wiederverwendungslandschaft



Stand: 08.04.13 Folie 16.9


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



Stand: 08.04.13 Folie 16.10


16.1 Auswahlkriterien

Entwicklungszeitplan Voraussichtliche Lebensdauer der Software Fähigkeiten, Hintergrund und Erfahrung der

Entwickler Kritische nichtfunktionale Anforderungen Anwendungsbereich Einsatzplattform



Stand: 08.04.13 Folie 16.11


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



Stand: 08.04.13 Folie 16.12


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)



Stand: 08.04.13 Folie 16.13



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.




Stand: 08.04.13 Folie 16.14



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)



Stand: 08.04.13 Folie 16.15



... 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)



Stand: 08.04.13 Folie 16.16



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)



Stand: 08.04.13 Folie 16.17


16.2 Klassen von FrameworksEinteilung 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



Stand: 08.04.13 Folie 16.18


16.2 Typen von FrameworksEinteilung 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.



Stand: 08.04.13 Folie 16.19


16.2 Typen von FrameworksWikipedia 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.



Stand: 08.04.13 Folie 16.20


16.2 Typen von FrameworksWikipedia 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.



Stand: 08.04.13 Folie 16.21


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)




Stand: 08.04.13 Folie 16.22


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.



Stand: 08.04.13 Folie 16.23


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 SteuerungszustandSteuerungsmethoden

Modellzustand

Modellmethoden

PräsentationszustandPräsentationsme

thoden

Nachrichten zu Präsentationsänderungen

Modellbearbeitungen Modellanfragenund Aktualisierungen



Stand: 08.04.13 Folie 16.24


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)



Stand: 08.04.13 Folie 16.25


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



Stand: 08.04.13 Folie 16.26


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



Stand: 08.04.13 Folie 16.27


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 des Frameworks ist vollständig sichtbar Implementation ist gegen Änderungen gesichert



Stand: 08.04.13 Folie 16.28


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



Stand: 08.04.13 Folie 16.29


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



Stand: 08.04.13 Folie 16.30


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



Stand: 08.04.13 Folie 16.31


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)



Stand: 08.04.13 Folie 16.32


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



Stand: 08.04.13 Folie 16.33


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



Stand: 08.04.13 Folie 16.34


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)



Stand: 08.04.13 Folie 16.35


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



Stand: 08.04.13 Folie 16.36


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



Stand: 08.04.13 Folie 16.37


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



Stand: 08.04.13 Folie 16.38


16.4 Arten der COTS-WiederverwendungCOTS-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



Stand: 08.04.13 Folie 16.39


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



Stand: 08.04.13 Folie 16.40


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



Stand: 08.04.13 Folie 16.41


16.4 Architektur eines ERP-Systems

EinkaufLieferketteLogistik Kundenpflege

Systemdatenbank

Geschäftsregeln

Prozesse Prozesse Prozesse Prozesse



Stand: 08.04.13 Folie 16.42


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



Stand: 08.04.13 Folie 16.43


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



Stand: 08.04.13 Folie 16.44


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



Stand: 08.04.13 Folie 16.45


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



Stand: 08.04.13 Folie 16.46


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



Stand: 08.04.13 Folie 16.47


16.4 Szenario zur COTS-Integration

Client

Webbrowser E-Mail-System

Server

E-Commerce-System

E-Mail-System

Bestell- und Fakturiersyste

m

Adapter

Adapter



Stand: 08.04.13 Folie 16.48


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

Dienst

Dienst

Dienst

Dienst

Dienst



Stand: 08.04.13 Folie 16.49


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

Documents

© Prof.Dr. Andreas M. Heinecke, WHS Gelsenkirchen. Wissen. Was praktisch zählt. Stand: 08.04.13 Folie 16.1 Software-Engineering SS 2013 – Alle Master-Studiengänge