Agile Produkte durch Produktlinien-Engineering Forum Forschungsförderung / ViSEK

Größe: px

Ab Seite anzeigen:

Download "Agile Produkte durch Produktlinien-Engineering Forum Forschungsförderung / ViSEK 28.10.2002"

Katja Bergmann
vor 8 Jahren
Abrufe

1 Agile Produkte durch Produktlinien-Engineering Forum Forschungsförderung / ViEK Dr. Martin Verlage Director Online Products MARKET MAKER oftware AG Kaiserslautern Inhalt Firmenprofil MARKET MAKER oftware AG Produktlinien Engineering Komponenten-Technologien bei MARKET MAKER Architektur-Bewertung Beobachtungen und Erfahrungen Eureka 2003 ITEA Eureka 2023 ITEA ip eite 1

MARKET MAKER oftware AG Produktlinien Engineering Komponenten-Technologien bei MARKET MAKER

2 Übersicht: Zielgruppen der MARKET MAKER oftware AG Bank Vermögensverwalter Märkte Anleger 2 MARKET MAKER Das Unternehmen 50 Mitarbeiter, 30% oftware-entwicklung Umsatz 2001: EUR 5 Mio 51% der Anteile werden gehalten von Georg von Holtzbrinck Verlagsgruppe/Verlagsgruppe Handelsblatt (via ECONOMY.ONE AG); 49% Management und Gründer verkaufte Exemplare von WIO Börse Mehrere Kunden mit Abos für Nutzung der Kursdatenbank DATA-POOL Geschäftsbereich Online wurde 1999 gegründet 3 eite 2

Verlagsgruppe/Verlagsgruppe Handelsblatt (via ECONOMY.ONE AG); 49% Management und Gründer 250.

3 Merger Product Family Browser-based Information ystem for Internet / Intranet / Web-ervice 4 Beispielhafte Komponentenliste Merger Datenquellen Realtime Feed Parser MM live! MM live! Instrument Database News Databse Historical Database... COM Interface Java Wrapper COM Interface Java Wrapper Instrument DB MM98 COM Interface Java Wrapper End-of- Day Data Applikationsdienste ( Web-ervices ) Watchlist Option Tool Processor for Technical Indicators Portfolio Management Front-End,... Administration, Framework Master Apache, Web Macro, Jserv / Tomcat Master ervices HTTP ervlets HTTP... 5 eite 3

.. COM Interface Java Wrapper COM Interface Java Wrapper Instrument DB MM98 COM Interface Java Wrapper End-of- Day Data Applikationsdienste (

4 Produktlinien-Engineering 12-Pack Application Engineering ystem& Application Testing ystem Definition ystem Economical Analysis ystem Analysis/Design Application Analysis Application Design Application Implementation Derivation Activities Asset management Asset management Traceability Core Assets Configuration Management Change Management Reverse Engineering F Reverse Engineering Activities F coping F Economical Analysis Domain ystem Analysis/Design Domain Analysis Domain Design Domain Implementation Domain Engineering Domain Testing 6 Verschränkter Prozeß der oftware-entwicklung Geschäftsprozesse mit Wiederverwendung F Concurrency trategische Prozesse Für Wiederverwendung Run-time variability ystem Delivered Operation and Maintenance Building and Deployment initiate/reinitiate Activities F Marketing Analysis Planning Preparation F coping F Economical Analysis F Planning (roadmap) Business Plan Ready/Updated F Research Installation-time variability F Organisation Construction-time F ales Organisation variability Ready/Adapted 7 eite 4

Activities F coping F Economical Analysis Domain ystem Analysis/Design Domain Analysis Domain Design Domain Implementation Domain Engineering Domain Testing 6 Verschränkter Prozeß der

5 Verwendete Komponenten-Technologie bei MARKET MAKER Teile aus: PuLE & Java & extreme Programming (XP) PuLE Identifikation und Beschreibung von Variabilitäten Genealogy Charts coping (Architecting) Java 2 interfaces Asynchrone Kommunikation via RMI reflection JNI für die Anbindung von legacy Komponenten (Java an C++ Wrapper an COM (Delphi)) Zentrales Repository (CV) Build & Test: MartinFowler.com s CruiseControl für forlaufende Integration (Automatischer Build- Prozeß der JARs nach jedem commit ; Ant) Testen JUnit (Automatisierter Komponententest) Regressionstests mit Generierung des Test-Betts Proprietärer HTTP-Request Emulator Bewertung der Komponenten anhand von Qualitätsattributen und Diskussionen unter Entwicklern Konfiguration der ysteme durch Property-Dateien 8 Bewertung der Produktlinien-Architektur Die Ergebnisse des Domain-Engineering müssen besonders gut sein! Ziel: hohe Kohäsion, geringe Kopplung Kohäsion tärke der Beziehung zu Klassen / Komponenten in der semantischen Nähe einer Klasse Kopplung tärke der Beziehung zu Klassen / Komponenten in semantischer Ferne einer Klasse Kohäsion ist nicht reziprok zu Kopplung Bewertungszahlen Anzahl der Attribute pro Klasse Anzahl der Kopplungen außerhalb der Hierarchie oder des Packages Anzahl Aufrufe von geerbten Methoden Anzahl Vorkommen als Methodenparameter Anzahl definierter Methoden in einer Klasse Anzahl geerbter Methoden 9 eite 5

com s CruiseControl für forlaufende Integration (Automatischer Build- Prozeß der JARs nach jedem commit ; Ant) Testen JUnit (Automatisierter Komponententest) Regressionstests mit Generierung des

6 Beispiel: Diagramm für Komponentenbewertung 25 # of classes whose attribute are a given class's type UserDataProviderInterface HTML_JButton WPIdentifier Materlfc TimeController HTML_JLabel MergerProperty MMLiveData ervicelfc ervicemanager Log ocaec User #classes a class is coupled to 10 Architektur-Bewertung Merger-ystem Web-basiertes erver-ystem Einbindung sog. Legacy -oftware Java2 Code wurde from scratch entwickelt wachsendes Verständnis während der Entwicklung Ziele der Analyse Ziel A: Bewertung eines Zustands der Architektur Ziel B: Veränderung zwischen Releases sichtbar machen 11 eite 6

class is coupled to 10 Architektur-Bewertung Merger-ystem Web-basiertes erver-ystem Einbindung sog.

7 Architektur-Bewertung Ziel B: Vergleich Baselines von Architektur-Kennzahlen Vorher / Nachher - Betrachtung Erfolg gezielter Maßnahmen abschätzbar Unbeabsichtigte Verschlechterungen erkennbar Code geht an FhG IEE Diskussion mit allen Mitgliedern des Entwicklungsteams => Daten ohne Interpretation sind Zahlen und kein Wissen 12 Komponenten-Prozeß *.java CV Feedback Cruise Control -Build - Component Test - Regression Test - ystem Test JARs 13 eite 7

Diskussion mit allen Mitgliedern des Entwicklungsteams => Daten ohne Interpretation sind Zahlen und kein Wissen

8 Beispiel: Dynamisches Laden und Instanziieren von Java-Klassen de.marketmaker.datasources.dbaccess.mql.class de.marketmaker.datasources.dbaccess.oracle.class // create MyQL specific instances de.marketmaker.datasources.dbaccess.myql.class // Driver create d MyQL =... specific instances Driver d =... // create MyQL specific instances Driver d =... service.property use specific variant database.class= de.marketmaker.datasources.dbaccess.myql read configuration NewsDataerviceIfc theervice = null; servicelauncher.class Class c = Class.forName(props.get( database.class )); Object o = c.getinstance(); try { theervice = (NewsDataerviceIfc) o; } catch (ClassCastException e) {...} 14 tatus Für alle Produkte immer noch eine Code-Base ~1.500 Quelldateien, 250 KLoC plus Delphi (nochmals doppelte LoC) 17 generische interfaces Die meisten Komponenten erreichen einen ersten stabilen tand nach 1-3 Monaten; spätere Revisionen benötigen rund 1 Monat Jede Produktinstanz hat circa Konfigurationsparameter ~ 10 Installationen, ~ 25 Kunden Individuelle Layouts für jeden Kunden Das Aufsetzen einer neuen Web-ite dauert 1-5 Tage 15 eite 8

property use specific variant database.class= de.marketmaker.datasources.dbaccess.myql read configuration NewsDataerviceIfc theervice = null; servicelauncher.class Class c = Class.forName(props.

9 Beobachtungen Testen auf ystemebene ist drängendes Problem (Anzahl Varianten!) Antwortzeit auf einen kleinen Change-Request verlängert sich Time-to-market für neue Produkte verringert sich Wartungsaufwand wird geringer, da nur eine Code-Base verändert werden muss Variabilitäten schlagen sich auf Klassenebene und Architekturstrukturen nieder, nur lokale Alternativen auf Algorithmenebene Entwicklungsprobleme Überprüfung Typkonsistenz nicht während des Compilierens möglich (dynamic binding) Horizontale Verfolgbarkeit Dokumentation von Entscheidungen und deren Auswirkungen im Code (fehlender Formalismus) Probleme tauchen bei der Installation vor Ort auf, weil Abhängigkeiten der Konfigurationsparameter nicht vollständig geprüft werden können 16 eite 9

Variabilitäten schlagen sich auf Klassenebene und Architekturstrukturen nieder, nur lokale Alternativen auf Algorithmenebene Entwicklungsprobleme Überprüfung Typkonsistenz nicht während

Ähnliche Dokumente

Product Line Engineering (PLE)

Product Line Engineering (PLE) Produktlinienentwicklung Von Christoph Kuberczyk Christoph Kuberczyk, SE in der Wissenschaft 2015, Product Line Engineering 1 Gliederung 1. Was ist PLE? 2. Motivation 3.