Das Dokument beschreibt die Softwareentwicklung im Bereich intelligenter Geräte und die Rolle von Ubigrate, einem Spin-off von SAP Research, in der effizienten Erfassung und Analyse von Daten in Produktions- und Logistikprozessen. Es werden verschiedene Ansätze und Technologien vorgestellt, darunter Business Activity Monitoring, die Bedeutung eines einheitlichen Objektmodells sowie Herausforderungen beim Datenbankzugriff und der Kommunikation zwischen unterschiedlichen Technologieräumen. Abschließend wird die Notwendigkeit einer technologieraum-übergreifenden Programmierung zur Optimierung der Softwareentwicklung betont.

1. Technologieraum-
übergreifendeSoftwareentwicklungimUmfeldintelligent
erGeräte
Falk Hartmann, ubigrate GmbH

2. Agenda
 ubigrate – Business ActivityMonitoring
 Von der Plattform zur Architektur
 Entwicklungsaspekte: Objektmodell, Fehlercodes
 Laufzeitaspekte: Kommunikation, Datenbankzugriff
 Organisatorisches
 Fazit

3. Agenda
 ubigrate – Business ActivityMonitoring
 Von der Plattform zur Architektur
 Entwicklungsaspekte: Objektmodell, Fehlercodes
 Laufzeitaspekte: Kommunikation, Datenbankzugriff
 Organisatorisches
 Fazit

4. U NTERNEHMENSPROFIL UBIGRATE G MB H
• Spin-Off von SAP Research
• gegründet 2008
• 15 Mitarbeiter
• Hauptsitz Dresden
• Vertriebsbüros in Dortmund und
Karlsruhe
• ubigrate = ubiquitousintegration
4

5. D AS G RUNDPROBLEM
Geschäftsprozesse (Planung und Überwachung)
Software on Business Level (ERP, MES, WMS, etc.)
Informationen über
die phyischen
verspätet, fehlerhaft,
? unvollständig, nicht vorhanden.
Prozesse sind oft...
?
Physische Prozesse (Ausführung)
Probleme: Langsame Reaktion, manueller Aufwand, suboptimale Entscheidungen!
5

6. D ER L ÖSUNGSANSATZ
Software auf der Geschäftsebene (ERP, MES, WMS, etc.)
Business Activity Monitoring in Produktion und Logistik
Effiziente Erfassung und Analyse aktueller, vollständiger, fehlerfreier und exakter
Daten über die physischen Prozesse.
IT und intelligente Geräte (RFID, Sensors, Controls, …) auf Prozessebene
Vorteile: Schnellere Reaktion, automatische Erfassung, bessere Entscheidungen
6

7. G EQOO B OXES : B EHÄLTERMANAGEMENT
Reinigung/Reparatur Produktion Versand
Erfassung der
Nutzung in der
Produktion
Erfassung des Eingangs in Erfassung des Versandes
die Reinigung/Reparatur an Kunden
Kundenvorteile
 Schwund verringern
 Produktionsausfälle vermeiden
 Unnötige Reinigung/Reparatur
verhindern
 Behälterüber/-unterbestand
vermeiden
 Automatisierte Abrechnung
7

8. G EQOO C OOL C HAIN : K ÜHLKETTENÜBERWACHUNG
+
!
Erfassung von
Übergaben zwischen
Transporteuren
Erfassung des Erfassung des
Transportbeginns Wareneingangs
Kundenvorteile
 Lückenlose Erfassung der
Transport- bzw.
Lagerbedingungen
 Vereinfachte Dokumentation
 Erkennung von Problemstellen
während Transport/Lagerung
 Verbesserung der
Abrechenbarkeit
88

9. A DS T EC
Industrietaugliches Terminal
Touchscreen 8“...15“
CPU: Intel Atom
RAM: bis zu 2GB
HD oder SSD möglich
OS: Windows XP, 7 oder Embedded
9

10. N ORDIC ID M ERLIN
Mobiles Terminal
RFID (UHF/HF) möglich
Barcodescanner
CPU: ARM, 532 MHz
RAM: 256 MB
Flash: 288 MB
OS: Windows CE 6.0
10

11. M ITSUBISHI C C ONTROLLER
Automatisierungshardware
(immer in Kombination mit SPS)
CPU: Renesas SH4, 400 MHz
RAM: 256 MB
Flash: ≤ 4 GB CF
OS: VxWorks 6.x
11

12. C LOUD S ERVER
Standard-HW bei Cloud-Anbieter
CPU: AMD OpteronQuadcore, 1.7 GHz
RAM: 4 GB
HDD: 2x250GB
OS: Ubuntu 8.4 LTS
12

13. C LIENT PC S
“Büro-PCs”
JederTyp von PCs, der in den letzten 10 Jahrenproduziertwurde
CPU: x86 (Intel, AMD, …)
RAM: 512 MB…4 GB
HDD: > 25GB
OS: Windows (in allenVersionen)
13

14. A NFORDERUNGEN AN DIE A RCHITEKTUR
Nr. Anforderung
A1 EinfacheBedienung, insbesondereUnterstützungfürTouchscreens
A2 Unabhängigkeitvominstallierten Browser auf Büro-PCs (IE 6…IE 9, Firefox,
Chrome, Opera)
A3 RobustheitauchbeiintermittierendenVerbindungenzwischen Terminals
und Cloud Server
A4 Persistenz in verschiedenenrelationalenDatenbanken
A5 Import und Export von Stamm- und Bewegungsdaten per HTTP/XML
14

15. Agenda
 ubigrate – Business ActivityMonitoring
 Von der Plattform zur Architektur
 Entwicklungsaspekte: Objektmodell, Fehlercodes
 Laufzeitaspekte: Kommunikation, Datenbankzugriff
 Organisatorisches
 Fazit

16. PL ATTFORM
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 RenesasSHx
16

17. P LATTFORM - ÜBERGREIFENDE P ROGRAMMIERUNG
Ziel: Einsparung von Entwicklungskosten
 Wiederverwendung möglichst unveränderter Artefakte (Code)
 Cross-platformDevelopment
 vgl. Portierbarkeit (z.B. ANSI-C)
Beispiele
 Java („Writeonce, runanywhere“)
 .NET
 Flash
 Perl
17

18. T ECHNOLOGIERAUM
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 BeziehungzwischenModell und Metamodell
 KaumBetrachtungderWerkzeuge
Verwendung des BegriffsimFolgenden
 Definition istsinnvoll
 andererFokus: wegvomMetamodell/Modell-Beziehung, hinzuProgrammiersprache,
Applikationsframework, Werkzeuge
18

19. T ECHNOLOGIERAUM (K URTEV )
nach [Kurtev et al., 2002]
19

20. Ü BERSICHT T ECHNOLOGIERÄUME
20

21. P LATTFORM VS . T ECHNOLOGIERAUM
21

22. A RCHITEKTUR
A1
A3
A5 A2
A4
22

23. T ECHNOLOGIERAUM - ÜBERGREIFENDE
P ROGRAMMIERUNG
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
23

24. Agenda
 ubigrate – Business ActivityMonitoring
 Von der Plattform zur Architektur
 Entwicklungsaspekte: Objektmodell, Fehlercodes
 Laufzeitaspekte: Kommunikation, Datenbankzugriff
 Organisatorisches
 Fazit

25. Problematik 1: Objektmodell

26. O BJEKTMODELL
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
26

27. I NSTANZEN IN DEN T ECHNOLOGIERÄUMEN
5a. 4.
2. 1.
5b.
3.
 ContainerDescription-Instanzen existieren in allen Technologieräumen
 Änderung des Objektmodells muss in allen Technologieräumen nachvollzogen werden
27

28. Z ENTRALES M ODELL : XML S CHEMATA
Zentrales Modell zur Generierung des Objektmodells
 Mögliche Modellierungstechniken: UML, textuell, XML Schema
 ubigratebenutzt XML Schemata zurBeschreibung des Objektmodells
 Ableitung von Artefakten in Java, C#, ActionScript, MXML, OR-Mapping, Ruby
28

29. XML S CHEMA C ONTAINER D ESCRIPTION . XSD
Verhältniszwischen XML Schema und UML siehe [Carlson, 2001]
29

30. XMLS CHEMA → J AVA (1)
JAXB – Java-XML Binding [Reinhold, 1999]
 Intra-level transformation (siehe [Kurtev, 2005])
30

31. XMLS CHEMA → J AVA (2)
31

32. XMLS CHEMA → J AVA (3)
32

33. XMLS CHEMA → C# (1)
ExistierendeLösungen
 MS bietet Compiler (“xsd.exe”)
 Compiler hat Einschränkungen (xsd:union und xsd:import)
 Diverse andereLösungen, eherwenigeraktiventwickelt
Plugin-Mechanismus in XJC
 PluginshabenZugriff auf
 XML Schema
 AST dergenerierten Java-Klassen
 Zusatzinformationen (Binding)
→ PluginzurGenerierung von C#-Klassen
 Generierung des C#-Codes über AST und selbstentwickelteBibliothekzurSerialisierung
33

34. XMLS CHEMA → C# (2)
34

35. XMLS CHEMA → A CTION S CRIPT
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. Z WISCHENFAZIT
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
36

37. Problematik 2: Fehlercodes

38. F EHLERCODES (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
38

39. F EHLERCODES (2)
public intdeleteContainerDescription(Stringuuid)
 In Java implementiert, von ActionScriptausgerufen
 Interpretation des Fehlercodes
 GenerierungderFehlercodesausgemeinsamen “Modell”
39

40. Z WISCHENFAZIT
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
40

41. Agenda
 ubigrate – Business ActivityMonitoring
 Von der Plattform zur Architektur
 Entwicklungsaspekte: Objektmodell, Fehlercodes
 Laufzeitaspekte: Kommunikation, Datenbankzugriff
 Organisatorisches
 Fazit

42. Problematik 3: Kommunikation

43. K OMMUNIKATION
Übertragen der Instanzen des Objektmodells zwischen Technologieräumen
 Diverse Standard-Technologien: CORBA, Webservices...
43

44. J AVA → F LASH /F LEX 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
44

45. J AVA → 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
45

46. Z WISCHENFAZIT
Ü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
46

47. Problematik 4: Datenbankzugriff

48. D ATENBANKZUGRIFF
OR-MapperbenötigtZusatzinformationen
 Primary Keys
 Verwaltung von Assoziationen (Sortierung, Kaskadierung von Operationen)
48

49. K ONFIGURATION OR-M APPER
ExistierendeLösungen
 Existierendes XJC-PluginHyperJAXBfür JPA
Idee gut, Umsetzungfragwürdig
Eigenentwicklung XJC-Plugin
 Generierung von Hibernate-Mappings
(Hibernate-Mappings sind XML-Files, daherGenerierung per JAXB)
 Zusatzinformationfür den OR-Mapperwird in Binding-Files hinterlegt
49

50. G ENERIERUNGDER OR-M APPER -K ONFIGURATION
50

51. G EMEINSAME D ATENBANKNUTZUNG
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]
51

52. Z WISCHENFAZIT
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
52

53. Agenda
 ubigrate – Business ActivityMonitoring
 Von der Plattform zur Architektur
 Entwicklungsaspekte: Objektmodell, Fehlercodes
 Laufzeitaspekte: Kommunikation, Datenbankzugriff
 Organisatorisches
 Fazit

54. B UILD - UND R ELEASE -M ANAGEMENT
Grundfrage
 Build jeweils durch “native” Mittel der Technologieräume oder
durch 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-TargetFlash/Flex unproblematisch (ANT-Tasks verfügbar)
 Build-Target C# erfordert u.U. Nacharbeiten an existierenden ANT-Tasks
54

55. T EAM -S ETUP
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.
55

56. Agenda
 ubigrate – Business ActivityMonitoring
 Von der Plattform zur Architektur
 Entwicklungsaspekte: Objektmodell, Fehlercodes
 Laufzeitaspekte: Kommunikation, Datenbankzugriff
 Organisatorisches
 Fazit

57. FAZIT
Technologieraum-übergreifendeProgrammierung
 u.U. einzigeMöglichkeit, mehrerePlattformenzubedienen
 ErhöhterAufwandgegenüberplattformübergreifenderProgrammierung
 MinimierenderAnzahlderTechnologieräume
 Reduktion des AufwandsüberCodegenerierung
57

58. L ITERATUR
58

59. A BKÜ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
59

60. A BKÜ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 SpeicherprogrammierbareSteuerung
WPF Windows Presentation Foundation
YAML YAML Ain't Markup Language
60

61. I N EIGENER S ACHE
Java User Group Sachsen
www.jugsaxony.org
www.facebook.com/jugsaxony
@jugsaxony
19. Januar 2012
Einführung in Android und Androids Open ADK-Implementierung
Rainer Fritzsche, Noser Engineering AG
01. März 2012
RAP wirdmobil Jochen Krause, EclipseSource
61

62. K ONTAKT
Falk Hartmann ubigrate GmbH
Leiter Softwareentwicklung Schnorrstr. 76
Tel.: +49 (351) 21187-27 01069 Dresden
Fax: +49 (351) 21187-28 Germany
Email: falk.hartmann@ubigrate.com Web: www.ubigrate.com
62