Technologieraum-übergreifendeSoftwareentwicklungimUmfeldintelligenterGeräteFalk Hartmann, ubigrate GmbH
Agenda   ubigrate – Business ActivityMonitoring   Von der Plattform zur Architektur   Entwicklungsaspekte: Objektmodell...
Agenda   ubigrate – Business ActivityMonitoring   Von der Plattform zur Architektur   Entwicklungsaspekte: Objektmodell...
U NTERNEHMENSPROFIL UBIGRATE G MB H•   Spin-Off von SAP Research•   gegründet 2008•   15 Mitarbeiter•   Hauptsitz Dresden•...
D AS G RUNDPROBLEM                        Geschäftsprozesse (Planung und Überwachung)                       Software on Bu...
D ER L ÖSUNGSANSATZ            Software auf der Geschäftsebene (ERP, MES, WMS, etc.)             Business Activity Monitor...
G EQOO B OXES : B EHÄLTERMANAGEMENT                      Reinigung/Reparatur              Produktion                   Ver...
G EQOO C OOL C HAIN : K ÜHLKETTENÜBERWACHUNG                                                                          +   ...
A DS T ECIndustrietaugliches TerminalTouchscreen 8“...15“CPU: Intel AtomRAM: bis zu 2GBHD oder SSD möglichOS: Windows XP, ...
N ORDIC ID M ERLINMobiles TerminalRFID (UHF/HF) möglichBarcodescannerCPU: ARM, 532 MHzRAM: 256 MBFlash: 288 MBOS: Windows ...
M ITSUBISHI C C ONTROLLERAutomatisierungshardware(immer in Kombination mit SPS)CPU: Renesas SH4, 400 MHzRAM: 256 MBFlash: ...
C LOUD S ERVERStandard-HW bei Cloud-AnbieterCPU: AMD OpteronQuadcore, 1.7 GHzRAM: 4 GBHDD: 2x250GBOS: Ubuntu 8.4 LTS      ...
C LIENT PC S“Büro-PCs”JederTyp von PCs, der in den letzten 10 JahrenproduziertwurdeCPU: x86 (Intel, AMD, …)RAM: 512 MB…4 G...
A NFORDERUNGEN AN DIE A RCHITEKTURNr.      AnforderungA1       EinfacheBedienung, insbesondereUnterstützungfürTouchscreens...
Agenda   ubigrate – Business ActivityMonitoring   Von der Plattform zur Architektur   Entwicklungsaspekte: Objektmodell...
PL ATTFORMDefinition nach dem Linux Information Project [The Linux Information Project, 2011]The term platform as used in ...
P LATTFORM - ÜBERGREIFENDE P ROGRAMMIERUNGZiel: Einsparung von Entwicklungskosten Wiederverwendung möglichst unveränderte...
T ECHNOLOGIERAUMDefinition nach Ivan Kurtev[Kurtev et al., 2002]A technological space is a working context with a set of a...
T ECHNOLOGIERAUM (K URTEV )                   nach [Kurtev et al., 2002]                                                19
Ü BERSICHT T ECHNOLOGIERÄUME                               20
P LATTFORM VS . T ECHNOLOGIERAUM                                   21
A RCHITEKTUR          A1               A3                         A5   A2                    A4                           ...
T ECHNOLOGIERAUM - ÜBERGREIFENDEP ROGRAMMIERUNGFazit Keiner der vorgestellten Technologieräume erstreckt sich über alle g...
Agenda   ubigrate – Business ActivityMonitoring   Von der Plattform zur Architektur   Entwicklungsaspekte: Objektmodell...
Problematik 1: Objektmodell
O BJEKTMODELLObjektmodell Eigentliches Modell der Domäne (hier: Behälterverwaltung) Objektmodell sehr agil, Änderungen i...
I NSTANZEN IN DEN T ECHNOLOGIERÄUMEN                                     5a.        4.                                    ...
Z ENTRALES M ODELL : XML S CHEMATAZentrales Modell zur Generierung des Objektmodells Mögliche Modellierungstechniken: UML...
XML S CHEMA C ONTAINER D ESCRIPTION . XSDVerhältniszwischen XML Schema und UML siehe [Carlson, 2001]                      ...
XMLS CHEMA → J AVA (1)JAXB – Java-XML Binding [Reinhold, 1999] Intra-level transformation (siehe [Kurtev, 2005])         ...
XMLS CHEMA → J AVA (2)                         31
XMLS CHEMA → J AVA (3)                         32
XMLS CHEMA → C# (1)ExistierendeLösungen MS bietet Compiler (“xsd.exe”)  Compiler hat Einschränkungen (xsd:union und xsd:...
XMLS CHEMA → C# (2)                      34
XMLS CHEMA → A CTION S CRIPTXJC-Plugin Generierung des ActionScript-Codes über AST-Bibliothek meta-as http://www.badgers...
Z WISCHENFAZITGenerierung des Objektmodells Vorteile   Verringerung des Entwicklungsaufwandes   bei richtiger Anwendung...
Problematik 2: Fehlercodes
F EHLERCODES (1)Löschen einer ContainerDescription-Instanz kann aus verschieden Gründenfehlschlagen Existierende Behälter...
F EHLERCODES (2)public intdeleteContainerDescription(Stringuuid) In Java implementiert, von ActionScriptausgerufen Inter...
Z WISCHENFAZITGenerierung von Enumerationen von Fehlercodes Vorteile   Refactoring der Fehlercodes möglich   Pflegeaufw...
Agenda   ubigrate – Business ActivityMonitoring   Von der Plattform zur Architektur   Entwicklungsaspekte: Objektmodell...
Problematik 3: Kommunikation
K OMMUNIKATIONÜbertragen der Instanzen des Objektmodells zwischen Technologieräumen Diverse Standard-Technologien: CORBA,...
J AVA → F LASH /F LEX UND ZURÜCKWebservice Kein Problem in Java Overhead für UI fraglichXML über HTTP Kein Problem in J...
J AVA → C# UND ZURÜCKJMS für die Kommunikation zwischen Terminal und ServerTechnologieraum Java->Java: unproblematisch Ve...
Z WISCHENFAZITÜbertragung von Instanzen über Technologieraumgrenzen hinweg XML-Serialisierbarkeit ist hilfreich, aber nic...
Problematik 4: Datenbankzugriff
D ATENBANKZUGRIFFOR-MapperbenötigtZusatzinformationen Primary Keys Verwaltung von Assoziationen (Sortierung, Kaskadierun...
K ONFIGURATION OR-M APPERExistierendeLösungen Existierendes XJC-PluginHyperJAXBfür JPA  Idee gut, UmsetzungfragwürdigEige...
G ENERIERUNGDER OR-M APPER -K ONFIGURATION                                             50
G EMEINSAME D ATENBANKNUTZUNGubigrate Express Einfache Zusammenstellung von Integrationslösungen durch Endkunde im Web S...
Z WISCHENFAZITGenerierung von OR-Mapper-Konfigurationen Vorteile   Zeitersparnis   Verringerung von Fehlern in den Mapp...
Agenda   ubigrate – Business ActivityMonitoring   Von der Plattform zur Architektur   Entwicklungsaspekte: Objektmodell...
B UILD - UND R ELEASE -M ANAGEMENTGrundfrage Build jeweils durch “native” Mittel der Technologieräume oder  durch Mittel ...
T EAM -S ETUPGesichtspunkte Effizienz Ausfallsicherheit Geringe EinstiegshürdeAnsätze Paare von Spezialisten Alles-Kö...
Agenda   ubigrate – Business ActivityMonitoring   Von der Plattform zur Architektur   Entwicklungsaspekte: Objektmodell...
FAZITTechnologieraum-übergreifendeProgrammierung u.U. einzigeMöglichkeit, mehrerePlattformenzubedienen ErhöhterAufwandge...
L ITERATUR             58
A BKÜRZUNGEN (1)AIR          Adobe Integrated RuntimeAMF          Action Message FormatAST          Abstract Syntax TreeCO...
A BKÜRZUNGEN (2)ORM       Object-Relational MapperREST      Representational State TransferRFID      Radio-Frequency Ident...
I N EIGENER S ACHEJava User Group Sachsenwww.jugsaxony.orgwww.facebook.com/jugsaxony         @jugsaxony19. Januar 2012Einf...
K ONTAKTFalk Hartmann                       ubigrate GmbHLeiter Softwareentwicklung          Schnorrstr. 76Tel.:  +49 (351...
Nächste SlideShare
Wird geladen in …5
×

Technologieraum übergreifende Programmierung

510 Aufrufe

Veröffentlicht am

Ein Vortrag im Rahmen der Ringvorlesung "Industrielle Softwareentwicklung", gehalten am 18. Januar 2012.

Veröffentlicht in: Technologie
0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
510
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
3
Aktionen
Geteilt
0
Downloads
1
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie
  • - Intelligente Geräte eher einführen -> in der Agenda rausnehmen!
  • - Steuerungsmöglichkeiten des XJC (Customizations)
  • - Typischer Fall fürDiplomarbeit
  • - Typischer Fall fürDiplomarbeit
  • Technologieraum übergreifende Programmierung

    1. 1. Technologieraum-übergreifendeSoftwareentwicklungimUmfeldintelligenterGeräteFalk Hartmann, ubigrate GmbH
    2. 2. Agenda ubigrate – Business ActivityMonitoring Von der Plattform zur Architektur Entwicklungsaspekte: Objektmodell, Fehlercodes Laufzeitaspekte: Kommunikation, Datenbankzugriff Organisatorisches Fazit
    3. 3. Agenda ubigrate – Business ActivityMonitoring Von der Plattform zur Architektur Entwicklungsaspekte: Objektmodell, Fehlercodes Laufzeitaspekte: Kommunikation, Datenbankzugriff Organisatorisches Fazit
    4. 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. 5. D AS G RUNDPROBLEM Geschäftsprozesse (Planung und Überwachung) Software on Business Level (ERP, MES, WMS, etc.)Informationen überdie phyischen verspätet, fehlerhaft, ? unvollständig, nicht vorhanden.Prozesse sind oft... ? Physische Prozesse (Ausführung) Probleme: Langsame Reaktion, manueller Aufwand, suboptimale Entscheidungen! 5
    6. 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. 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 KundenKundenvorteile Schwund verringern Produktionsausfälle vermeiden Unnötige Reinigung/Reparatur verhindern Behälterüber/-unterbestand vermeiden Automatisierte Abrechnung 7
    8. 8. G EQOO C OOL C HAIN : K ÜHLKETTENÜBERWACHUNG + ! Erfassung von Übergaben zwischen Transporteuren Erfassung des Erfassung des Transportbeginns WareneingangsKundenvorteile Lückenlose Erfassung der Transport- bzw. Lagerbedingungen Vereinfachte Dokumentation Erkennung von Problemstellen während Transport/Lagerung Verbesserung der Abrechenbarkeit 88
    9. 9. A DS T ECIndustrietaugliches TerminalTouchscreen 8“...15“CPU: Intel AtomRAM: bis zu 2GBHD oder SSD möglichOS: Windows XP, 7 oder Embedded 9
    10. 10. N ORDIC ID M ERLINMobiles TerminalRFID (UHF/HF) möglichBarcodescannerCPU: ARM, 532 MHzRAM: 256 MBFlash: 288 MBOS: Windows CE 6.0 10
    11. 11. M ITSUBISHI C C ONTROLLERAutomatisierungshardware(immer in Kombination mit SPS)CPU: Renesas SH4, 400 MHzRAM: 256 MBFlash: ≤ 4 GB CFOS: VxWorks 6.x 11
    12. 12. C LOUD S ERVERStandard-HW bei Cloud-AnbieterCPU: AMD OpteronQuadcore, 1.7 GHzRAM: 4 GBHDD: 2x250GBOS: Ubuntu 8.4 LTS 12
    13. 13. C LIENT PC S“Büro-PCs”JederTyp von PCs, der in den letzten 10 JahrenproduziertwurdeCPU: x86 (Intel, AMD, …)RAM: 512 MB…4 GBHDD: > 25GBOS: Windows (in allenVersionen) 13
    14. 14. A NFORDERUNGEN AN DIE A RCHITEKTURNr. AnforderungA1 EinfacheBedienung, insbesondereUnterstützungfürTouchscreensA2 Unabhängigkeitvominstallierten Browser auf Büro-PCs (IE 6…IE 9, Firefox, Chrome, Opera)A3 RobustheitauchbeiintermittierendenVerbindungenzwischen Terminals und Cloud ServerA4 Persistenz in verschiedenenrelationalenDatenbankenA5 Import und Export von Stamm- und Bewegungsdaten per HTTP/XML 14
    15. 15. Agenda ubigrate – Business ActivityMonitoring Von der Plattform zur Architektur Entwicklungsaspekte: Objektmodell, Fehlercodes Laufzeitaspekte: Kommunikation, Datenbankzugriff Organisatorisches Fazit
    16. 16. PL ATTFORMDefinition 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, PharmaindustrieBeispiele Windows auf x86 Windows CE auf ARM Android auf SnapDragon VxWorks auf RenesasSHx 16
    17. 17. P LATTFORM - ÜBERGREIFENDE P ROGRAMMIERUNGZiel: 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. 18. T ECHNOLOGIERAUMDefinition 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 KaumBetrachtungderWerkzeugeVerwendung des BegriffsimFolgenden Definition istsinnvoll andererFokus: wegvomMetamodell/Modell-Beziehung, hinzuProgrammiersprache, Applikationsframework, Werkzeuge 18
    19. 19. T ECHNOLOGIERAUM (K URTEV ) nach [Kurtev et al., 2002] 19
    20. 20. Ü BERSICHT T ECHNOLOGIERÄUME 20
    21. 21. P LATTFORM VS . T ECHNOLOGIERAUM 21
    22. 22. A RCHITEKTUR A1 A3 A5 A2 A4 22
    23. 23. T ECHNOLOGIERAUM - ÜBERGREIFENDEP ROGRAMMIERUNGFazit 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. 24. Agenda ubigrate – Business ActivityMonitoring Von der Plattform zur Architektur Entwicklungsaspekte: Objektmodell, Fehlercodes Laufzeitaspekte: Kommunikation, Datenbankzugriff Organisatorisches Fazit
    25. 25. Problematik 1: Objektmodell
    26. 26. O BJEKTMODELLObjektmodell Eigentliches Modell der Domäne (hier: Behälterverwaltung) Objektmodell sehr agil, Änderungen in jeder IterationBeispiel: ContainerDescription – Beschreibung eines Behältertypens Name, Beschreibung Identifizierbarkeit einzelner Instanzen Zustandsmodelle 26
    27. 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. 28. Z ENTRALES M ODELL : XML S CHEMATAZentrales 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. 29. XML S CHEMA C ONTAINER D ESCRIPTION . XSDVerhältniszwischen XML Schema und UML siehe [Carlson, 2001] 29
    30. 30. XMLS CHEMA → J AVA (1)JAXB – Java-XML Binding [Reinhold, 1999] Intra-level transformation (siehe [Kurtev, 2005]) 30
    31. 31. XMLS CHEMA → J AVA (2) 31
    32. 32. XMLS CHEMA → J AVA (3) 32
    33. 33. XMLS CHEMA → C# (1)ExistierendeLösungen MS bietet Compiler (“xsd.exe”)  Compiler hat Einschränkungen (xsd:union und xsd:import) Diverse andereLösungen, eherwenigeraktiventwickeltPlugin-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. 34. XMLS CHEMA → C# (2) 34
    35. 35. XMLS CHEMA → A CTION S CRIPTXJC-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. 36. Z WISCHENFAZITGenerierung 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 ObjektmodelleXML 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. 37. Problematik 2: Fehlercodes
    38. 38. F EHLERCODES (1)Löschen einer ContainerDescription-Instanz kann aus verschieden Gründenfehlschlagen Existierende Behälter dieses Typs Fehlende BenutzerrechteTypischerweise Kommunikation per Rückgabewert/Exception 38
    39. 39. F EHLERCODES (2)public intdeleteContainerDescription(Stringuuid) In Java implementiert, von ActionScriptausgerufen Interpretation des Fehlercodes GenerierungderFehlercodesausgemeinsamen “Modell” 39
    40. 40. Z WISCHENFAZITGenerierung 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. 41. Agenda ubigrate – Business ActivityMonitoring Von der Plattform zur Architektur Entwicklungsaspekte: Objektmodell, Fehlercodes Laufzeitaspekte: Kommunikation, Datenbankzugriff Organisatorisches Fazit
    42. 42. Problematik 3: Kommunikation
    43. 43. K OMMUNIKATIONÜbertragen der Instanzen des Objektmodells zwischen Technologieräumen Diverse Standard-Technologien: CORBA, Webservices... 43
    44. 44. J AVA → F LASH /F LEX UND ZURÜCKWebservice Kein Problem in Java Overhead für UI fraglichXML über HTTP Kein Problem in Java Marshalling/Unmarshalling in Flash/Flex nicht verfügbarAMF 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. 45. J AVA → C# UND ZURÜCKJMS für die Kommunikation zwischen Terminal und ServerTechnologieraum Java->Java: unproblematisch Versand der Nachrichten serialisiert oder als XML-Botschaften möglichTechnologieraum 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. 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. 47. Problematik 4: Datenbankzugriff
    48. 48. D ATENBANKZUGRIFFOR-MapperbenötigtZusatzinformationen Primary Keys Verwaltung von Assoziationen (Sortierung, Kaskadierung von Operationen) 48
    49. 49. K ONFIGURATION OR-M APPERExistierendeLösungen Existierendes XJC-PluginHyperJAXBfür JPA Idee gut, UmsetzungfragwürdigEigenentwicklung 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. 50. G ENERIERUNGDER OR-M APPER -K ONFIGURATION 50
    51. 51. G EMEINSAME D ATENBANKNUTZUNGubigrate Express Einfache Zusammenstellung von Integrationslösungen durch Endkunde im Web Sofortige Erstellung Nicht kommerzialisiertGemeinsame 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. 52. Z WISCHENFAZITGenerierung von OR-Mapper-Konfigurationen Vorteile  Zeitersparnis  Verringerung von Fehlern in den Mappings  Zentrale Vorgaben leichter durchsetzbar Nachteile  Strukturgleichheit von Persistenz- und SerialisierungsobjektenGemeinsame Datenbanknutzung Machbar Aufwand hängt von Technologieräumen ab, kann u.U. höher als erwartet sein 52
    53. 53. Agenda ubigrate – Business ActivityMonitoring Von der Plattform zur Architektur Entwicklungsaspekte: Objektmodell, Fehlercodes Laufzeitaspekte: Kommunikation, Datenbankzugriff Organisatorisches Fazit
    54. 54. B UILD - UND R ELEASE -M ANAGEMENTGrundfrage Build jeweils durch “native” Mittel der Technologieräume oder durch Mittel eines ausgewählten RaumesUnser 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. 55. T EAM -S ETUPGesichtspunkte Effizienz Ausfallsicherheit Geringe EinstiegshürdeAnsätze Paare von Spezialisten Alles-Könner MischungUnser Ziel Jedes Team-Mitglied in zwei Technologieräumen unterwegs. Jeder Technologieraum wird von zwei Team-Mitgliedern beherrscht. 55
    56. 56. Agenda ubigrate – Business ActivityMonitoring Von der Plattform zur Architektur Entwicklungsaspekte: Objektmodell, Fehlercodes Laufzeitaspekte: Kommunikation, Datenbankzugriff Organisatorisches Fazit
    57. 57. FAZITTechnologieraum-übergreifendeProgrammierung u.U. einzigeMöglichkeit, mehrerePlattformenzubedienen ErhöhterAufwandgegenüberplattformübergreifenderProgrammierung MinimierenderAnzahlderTechnologieräume Reduktion des AufwandsüberCodegenerierung 57
    58. 58. L ITERATUR 58
    59. 59. A BKÜRZUNGEN (1)AIR Adobe Integrated RuntimeAMF Action Message FormatAST Abstract Syntax TreeCORBA Common Object Request Broker ArchitectureCST Concrete Syntax TreeDBMS/RDBMS Database Management System (Relational ~)DOM Document Object ModelJAXB Java Architecture for XML BindingJAXP Java API for XML ProcessingJMS Java Message ServiceJSON JavaScript Object NotationMDA Model Driven ArchitectureOSGi Open Services Gateway Initiative 59
    60. 60. A BKÜRZUNGEN (2)ORM Object-Relational MapperREST Representational State TransferRFID Radio-Frequency IdentificationSAX Simple API for XMLStAX Streaming API for XMLSPS SpeicherprogrammierbareSteuerungWPF Windows Presentation FoundationYAML YAML Aint Markup Language 60
    61. 61. I N EIGENER S ACHEJava User Group Sachsenwww.jugsaxony.orgwww.facebook.com/jugsaxony @jugsaxony19. Januar 2012Einführung in Android und Androids Open ADK-Implementierung
 Rainer Fritzsche, Noser Engineering AG01. März 2012RAP wirdmobil
 Jochen Krause, EclipseSource 61
    62. 62. K ONTAKTFalk Hartmann ubigrate GmbHLeiter Softwareentwicklung Schnorrstr. 76Tel.: +49 (351) 21187-27 01069 DresdenFax: +49 (351) 21187-28 GermanyEmail: falk.hartmann@ubigrate.com Web: www.ubigrate.com 62

    ×