Technologieraum übergreifende Programmierung

Technologieraum-übergreifende Softwareentwicklung im Umfeld intelligenter Geräte

Falk Hartmann, ubigrate GmbH

Agenda

ubigrate – Business Activity Monitoring Von der Plattform zur Architektur Entwicklungsaspekte: Objektmodell, Fehlercodes Laufzeitaspekte: Kommunikation, Datenbankzugriff Organisatorisches Fazit

Agenda


UNTERNEHMENSPROFIL UBIGRATE GMBH

4

• Spin-Off von SAP Research• gegründet 2008• 15 Mitarbeiter• Hauptsitz Dresden• Vertriebsbüros in Dortmund und

Karlsruhe

• ubigrate = ubiquitous integration

Software on Business Level (ERP, MES, WMS, etc.)

DAS GRUNDPROBLEM

5

Geschäftsprozesse (Planung und Überwachung)

?

?

Informationen über die phyischen Prozesse sind oft... verspätet, fehlerhaft, unvollständig, nicht vorhanden.

Probleme: Langsame Reaktion, manueller Aufwand, suboptimale Entscheidungen!

Physische Prozesse (Ausführung)

IT und intelligente Geräte (RFID, Sensors, Controls, …) auf Prozessebene

Software auf der Geschäftsebene (ERP, MES, WMS, etc.)

DER LÖSUNGSANSATZ

6

Vorteile: Schnellere Reaktion, automatische Erfassung, bessere Entscheidungen

Business Activity Monitoring in Produktion und LogistikEffiziente Erfassung und Analyse aktueller, vollständiger, fehlerfreier und exakter

Daten über die physischen Prozesse.

7

GEQOO BOXES: BEHÄLTERMANAGEMENT

Reinigung/Reparatur Produktion Versand

Erfassung des Eingangs in die Reinigung/Reparatur

Erfassung der Nutzung in der

Produktion

Erfassung des Versandes an Kunden

Kundenvorteile Schwund verringern Produktionsausfälle vermeiden Unnötige Reinigung/Reparatur

verhindern Behälterüber/-unterbestand

vermeiden Automatisierte Abrechnung

8

GEQOO COOLCHAIN: KÜHLKETTENÜBERWACHUNG

+!

Erfassung des Transportbeginns

Erfassung von Übergaben zwischen

Transporteuren

Erfassung des Wareneingangs

Kundenvorteile Lückenlose Erfassung der

Transport- bzw. Lagerbedingungen

Vereinfachte Dokumentation Erkennung von Problemstellen

während Transport/Lagerung Verbesserung der

Abrechenbarkeit

8

9

ADSTEC

Industrietaugliches Terminal

Touchscreen 8“...15“

CPU: Intel Atom

RAM: bis zu 2GB

HD oder SSD möglich

OS: Windows XP, 7 oder Embedded

10

NORDIC ID MERLIN

Mobiles Terminal

RFID (UHF/HF) möglich

Barcodescanner

CPU: ARM, 532 MHz

RAM: 256 MB

Flash: 288 MB

OS: Windows CE 6.0

11

MITSUBISHI C CONTROLLER

Automatisierungshardware

(immer in Kombination mit SPS)

CPU: Renesas SH4, 400 MHz

RAM: 256 MB

Flash: ≤ 4 GB CF

OS: VxWorks 6.x

12

CLOUD SERVER

Standard-HW bei Cloud-Anbieter

CPU: AMD Opteron Quadcore, 1.7 GHz

RAM: 4 GB

HDD: 2x250GB

OS: Ubuntu 8.4 LTS

CLIENT PCS

“Büro-PCs”

Jeder Typ von PCs, der in den letzten 10 Jahren produziert wurde

CPU: x86 (Intel, AMD, …)

RAM: 512 MB…4 GB

HDD: > 25GB

OS: Windows (in allen Versionen)

13

ANFORDERUNGEN AN DIE ARCHITEKTUR

Nr. Anforderung

A1 Einfache Bedienung, insbesondere Unterstützung für Touchscreens

A2 Unabhängigkeit vom installierten Browser auf Büro-PCs (IE 6…IE 9, Firefox, Chrome, Opera)

A3 Robustheit auch bei intermittierenden Verbindungen zwischen Terminals und Cloud Server

A4 Persistenz in verschiedenen relationalen Datenbanken

A5 Import und Export von Stamm- und Bewegungsdaten per HTTP/XML

14

Agenda


16

PLATTFORM

Definition nach dem Linux Information Project [The Linux Information Project, 2011]

The term platform as used in a computer context can refer to (1) the type of processor and/or other hardware on which a given operating system or application program runs, (2) the type of operating system on a computer or (3) the combination of the type of hardware and the type of operating system running on it.

Teilweise auch Einbeziehung eines Applikations-Frameworks

Hier: Kombination von Hardware und Betriebssystem

Begriff auch in anderen Industrien üblich, z.B. Automobilbau, Pharmaindustrie

Beispiele

Windows auf x86

Windows CE auf ARM

Android auf SnapDragon

VxWorks auf Renesas SHx

17

PLATTFORM-ÜBERGREIFENDE PROGRAMMIERUNG

Ziel: Einsparung von Entwicklungskosten

Wiederverwendung möglichst unveränderter Artefakte (Code)

Cross-platform Development

vgl. Portierbarkeit (z.B. ANSI-C)

Beispiele

Java („Write once, run anywhere“)

.NET

Flash

Perl

18

TECHNOLOGIERAUM

Definition nach Ivan Kurtev [Kurtev et al., 2002]

A technological space is a working context with a set of associated concepts, body of knowledge, tools, required skills, and possibilities. It is often associated to a given user community with shared know-how, educational support, common literature and even conference meetings.

Ergänzung des Plattform-Begriffs

Fokus stark auf Beziehung zwischen Modell und Metamodell

Kaum Betrachtung der Werkzeuge

Verwendung des Begriffs im Folgenden

Definition ist sinnvoll

anderer Fokus: weg vom Metamodell/Modell-Beziehung, hin zu Programmiersprache, Applikationsframework, Werkzeuge

19

TECHNOLOGIERAUM (KURTEV)

nach [Kurtev et al., 2002]

ÜBERSICHT TECHNOLOGIERÄUME

20

PLATTFORM VS. TECHNOLOGIERAUM

21

ARCHITEKTUR

22

A1

A2A3 A5

A4

23

TECHNOLOGIERAUM-ÜBERGREIFENDE PROGRAMMIERUNG

Fazit

Keiner der vorgestellten Technologieräume erstreckt sich über alle gewünschten Plattformen

Wahl mehrerer Technologieräume → „Technologieraum-übergreifende Programmierung“

Probleme

Wiederverwendung von Code Objektmodell

Reimplementierung von Features in mehreren Technologieräumen

Überbrückung Technologieraumgrenzen

Spezialisierung der Teammitglieder auf einen/mehrere Technologieräume

Agenda


Problematik 1: Objektmodell

26

OBJEKTMODELL

Objektmodell

Eigentliches Modell der Domäne (hier: Behälterverwaltung)

Objektmodell sehr agil, Änderungen in jeder Iteration

Beispiel: ContainerDescription – Beschreibung eines Behältertypens

Name, Beschreibung

Identifizierbarkeit einzelner Instanzen

Zustandsmodelle

27

INSTANZEN IN DEN TECHNOLOGIERÄUMEN

ContainerDescription-Instanzen existieren in allen Technologieräumen

Änderung des Objektmodells muss in allen Technologieräumen nachvollzogen werden

1.

3.

2.

5b.

5a. 4.

28

ZENTRALES MODELL: XML SCHEMATA

Zentrales Modell zur Generierung des Objektmodells

Mögliche Modellierungstechniken: UML, textuell, XML Schema

ubigrate benutzt XML Schemata zur Beschreibung des Objektmodells

Ableitung von Artefakten in Java, C#, ActionScript, MXML, OR-Mapping, Ruby

XML SCHEMA CONTAINERDESCRIPTION.XSD

Verhältnis zwischen XML Schema und UML siehe [Carlson, 2001]

29

30

XMLSCHEMA → JAVA (1)

JAXB – Java-XML Binding [Reinhold, 1999]

Intra-level transformation (siehe [Kurtev, 2005])


31


32

33

XMLSCHEMA → C# (1)

Existierende Lösungen

MS bietet Compiler (“xsd.exe”) Compiler hat Einschränkungen (xsd:union und xsd:import)

Diverse andere Lösungen, eher weniger aktiv entwickelt

Plugin-Mechanismus in XJC

Plugins haben Zugriff auf XML Schema

AST der generierten Java-Klassen

Zusatzinformationen (Binding)

→ Plugin zur Generierung von C#-Klassen Generierung des C#-Codes über AST und selbstentwickelte Bibliothek zur Serialisierung

XMLSCHEMA → C# (2)

34

XMLSCHEMA → ACTIONSCRIPT

XJC-Plugin

Generierung des ActionScript-Codes über AST-Bibliothek meta-as

http://www.badgers-in-foil.co.uk/projects/metaas/

Kein XML-Binding-Framework in ActionScript → keine Binding-Information im Code

35

36

ZWISCHENFAZIT

Generierung des Objektmodells

Vorteile Verringerung des Entwicklungsaufwandes

bei richtiger Anwendung und in Abhängigkeit von der Sprache Fehlerprüfung durch Compiler

Nachteile Unterschiede der Sprachen: kovariante Rückgabewerte, Enumerationen

Ansatz erfordert Strukturgleichheit der Objektmodelle

XML Schema zur Beschreibung des Objektmodells

Vorteile Schnelle Erfolge bei der Generierung

UML immer noch zur Beschreibung der XML Schemata möglich

Nachteile Keine grafische Ansicht

Problematik 2: Fehlercodes

38

FEHLERCODES (1)

Löschen einer ContainerDescription-Instanz kann aus verschieden Gründen fehlschlagen

Existierende Behälter dieses Typs

Fehlende Benutzerrechte

Typischerweise Kommunikation per Rückgabewert/Exception

39

FEHLERCODES (2)

public int deleteContainerDescription(String uuid)

In Java implementiert, von ActionScript aus gerufen

Interpretation des Fehlercodes

Generierung der Fehlercodes aus gemeinsamen “Modell”

40

ZWISCHENFAZIT

Generierung von Enumerationen von Fehlercodes

Vorteile Refactoring der Fehlercodes möglich

Pflegeaufwand für Fehlercodes bleibt bei einem Entwickler

Kommunikation zwischen Entwicklern nicht mehr nötig

Automatische Auswertbarkeit des Fehlercodes

Nachteile Keine

Agenda


Problematik 3: Kommunikation

43

KOMMUNIKATION

Übertragen der Instanzen des Objektmodells zwischen Technologieräumen

Diverse Standard-Technologien: CORBA, Webservices...

44

JAVA → FLASH/FLEX UND ZURÜCK

Webservice

Kein Problem in Java

Overhead für UI fraglich

XML über HTTP

Kein Problem in Java

Marshalling/Unmarshalling in Flash/Flex nicht verfügbar

AMF

Binäres Austauschformat, optimierter Resourcenbedarf

Funktioniert über JavaBeans und dazu passende ActionScript-Klassen

In Java verfügbar über BlazeDS oder LCDS

Probleme Enumerationen

Wrappertypen

45

JAVA → C# UND ZURÜCK

JMS für die Kommunikation zwischen Terminal und Server

Technologieraum Java->Java: unproblematisch

Versand der Nachrichten serialisiert oder als XML-Botschaften möglich

Technologieraum C#->Java bzw. Java->C#:

Versand der Nachrichten nur als XML-Botschaft möglich

JMS-Anbindung im .NET-Bereich (speziell .NET CF) fehlt

Nachimplementierung basierend auf REST

Zuverlässige Zustellung über Ablage im Dateisystem

46

ZWISCHENFAZIT

Übertragung von Instanzen über Technologieraumgrenzen hinweg

XML-Serialisierbarkeit ist hilfreich, aber nicht in jedem Technologieraum

u.U. Einsatz alternativer Serialisierungsformate notwendig

Asynchrone Kommunikationsmechanismen wie JMS sind in der Regel stark technologieraum-gebunden

Problematik 4: Datenbankzugriff

48

DATENBANKZUGRIFF

OR-Mapper benötigt Zusatzinformationen

Primary Keys

Verwaltung von Assoziationen (Sortierung, Kaskadierung von Operationen)

49

KONFIGURATION OR-MAPPER

Existierende Lösungen

Existierendes XJC-Plugin HyperJAXB für JPAIdee gut, Umsetzung fragwürdig

Eigenentwicklung XJC-Plugin

Generierung von Hibernate-Mappings(Hibernate-Mappings sind XML-Files, daher Generierung per JAXB)

Zusatzinformation für den OR-Mapper wird in Binding-Files hinterlegt

GENERIERUNG DER OR-MAPPER-KONFIGURATION

50

51

GEMEINSAME DATENBANKNUTZUNG

ubigrate Express

Einfache Zusammenstellung von Integrationslösungen durch Endkunde im Web

Sofortige Erstellung

Nicht kommerzialisiert

Gemeinsame Datenbanknutzung

Beschreiben der Datenbank mittels Java

Lesen/Schreiben der Datenbank mittels Ruby

Datenbankschema durch unseren gewählten Ansatz bereits vordefiniert

Adaption von ActiveRecord zur Parametrisierung durch Hibernate-Mappings

Convention-over-Configuration verursacht größere Probleme bei gemeinsamer Datenbanknutzung

Besonderes Problem: Abbildung der Vererbung

siehe [Grünberg, 2011]

52

ZWISCHENFAZIT

Generierung von OR-Mapper-Konfigurationen

Vorteile Zeitersparnis

Verringerung von Fehlern in den Mappings

Zentrale Vorgaben leichter durchsetzbar

Nachteile Strukturgleichheit von Persistenz- und Serialisierungsobjekten

Gemeinsame Datenbanknutzung

Machbar

Aufwand hängt von Technologieräumen ab, kann u.U. höher als erwartet sein

Agenda


54

BUILD- UND RELEASE-MANAGEMENT

Grundfrage

Build jeweils durch “native” Mittel der Technologieräume oderdurch Mittel eines ausgewählten Raumes

Unser Ansatz

Auswahl eines Technologieraums für zentrales Build-Management Zusammenfassung der Ergebnisse (gemeinsames Setup)

Java mit ANT und Jenkins Naheliegend wegen XJC-Einsatz

Build-Target Flash/Flex unproblematisch (ANT-Tasks verfügbar)

Build-Target C# erfordert u.U. Nacharbeiten an existierenden ANT-Tasks

55

TEAM-SETUP

Gesichtspunkte

Effizienz

Ausfallsicherheit

Geringe Einstiegshürde

Ansätze

Paare von Spezialisten

Alles-Könner

Mischung

Unser Ziel

Jedes Team-Mitglied in zwei Technologieräumen unterwegs.

Jeder Technologieraum wird von zwei Team-Mitgliedern beherrscht.

Agenda


57

FAZIT

Technologieraum-übergreifende Programmierung

u.U. einzige Möglichkeit, mehrere Plattformen zu bedienen

Erhöhter Aufwand gegenüber plattformübergreifender Programmierung

Minimieren der Anzahl der Technologieräume

Reduktion des Aufwands über Codegenerierung

58

LITERATUR

59

ABKÜRZUNGEN (1)

AIR Adobe Integrated Runtime

AMF Action Message Format

AST Abstract Syntax Tree

CORBA Common Object Request Broker Architecture

CST Concrete Syntax Tree

DBMS/RDBMS Database Management System (Relational ~)

DOM Document Object Model

JAXB Java Architecture for XML Binding

JAXP Java API for XML Processing

JMS Java Message Service

JSON JavaScript Object Notation

MDA Model Driven Architecture

OSGi Open Services Gateway Initiative

ABKÜRZUNGEN (2)

ORM Object-Relational Mapper

REST Representational State Transfer

RFID Radio-Frequency Identification

SAX Simple API for XML

StAX Streaming API for XML

SPS Speicherprogrammierbare Steuerung

WPF Windows Presentation Foundation

YAML YAML Ain't Markup Language

60

IN EIGENER SACHE

Java User Group Sachsen

www.jugsaxony.org

www.facebook.com/jugsaxony

@jugsaxony

19. Januar 2012

Einführung in Android und Androids Open ADK-ImplementierungRainer Fritzsche, Noser Engineering AG

01. März 2012

RAP wird mobil Jochen Krause, EclipseSource

61

KONTAKT

62

Falk HartmannLeiter Softwareentwicklung

Tel.: +49 (351) 21187-27Fax: +49 (351) 21187-28Email: [email protected]

ubigrate GmbH

Schnorrstr. 7601069 DresdenGermanyWeb: www.ubigrate.com

mailto:[email protected]

http://www.ubigrate.com/

Technology

Technologieraum übergreifende Programmierung