technologieraum übergreifende programmierung
Post on 08-Dec-2014
331 Views
Preview:
DESCRIPTION
TRANSCRIPT
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
ubigrate – Business Activity Monitoring Von der Plattform zur Architektur Entwicklungsaspekte: Objektmodell, Fehlercodes Laufzeitaspekte: Kommunikation, Datenbankzugriff Organisatorisches Fazit
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
ubigrate – Business Activity Monitoring Von der Plattform zur Architektur Entwicklungsaspekte: Objektmodell, Fehlercodes Laufzeitaspekte: Kommunikation, Datenbankzugriff Organisatorisches Fazit
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
ubigrate – Business Activity Monitoring Von der Plattform zur Architektur Entwicklungsaspekte: Objektmodell, Fehlercodes Laufzeitaspekte: Kommunikation, Datenbankzugriff Organisatorisches Fazit
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])
XMLSCHEMA → JAVA (2)
31
XMLSCHEMA → JAVA (3)
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
ubigrate – Business Activity Monitoring Von der Plattform zur Architektur Entwicklungsaspekte: Objektmodell, Fehlercodes Laufzeitaspekte: Kommunikation, Datenbankzugriff Organisatorisches Fazit
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
ubigrate – Business Activity Monitoring Von der Plattform zur Architektur Entwicklungsaspekte: Objektmodell, Fehlercodes Laufzeitaspekte: Kommunikation, Datenbankzugriff Organisatorisches Fazit
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
ubigrate – Business Activity Monitoring Von der Plattform zur Architektur Entwicklungsaspekte: Objektmodell, Fehlercodes Laufzeitaspekte: Kommunikation, Datenbankzugriff Organisatorisches Fazit
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: falk.hartmann@ubigrate.com
ubigrate GmbH
Schnorrstr. 7601069 DresdenGermanyWeb: www.ubigrate.com
top related