Allgemein

Im Zeitalter des digitalen Wandels und des zunehmenden Vorstoßes mobiler Technologien ergeben sich laufend neue Anwendungsfelder bei denen ganze Geschäftsprozesse von mobilen Applikationen abgewickelt werden. Auch im Einsatzwesen, wo ein rascher Datenaustausch von besonders hoher Wichtigkeit ist, können mobile Dienste zu einer entscheidenden Wertsteigerung führen, indem Koordination und Kommunikation verbessert werden.

Meine Diplomarbeit befasst sich mit der Fragestellung, inwieweit mobile Anwendungen im Einsatzwesen, speziell im Anwendungsbereich von Feuerwehren, einen Nutzen bringen können. Dabei konzentriert sich die Forschung vorwiegend auf das Atemschutzwesen.

Die Bedeutung des Atemschutzes im Feuerwehrwesen

Dem Atemschutzwesen wird in der Feuerwehr künftig eine immer wichtiger werdende Bedeutung beigemessen. Zudem wird der Einsatz von schwerem Atemschutzgerät auch immer unabdingbarer, da bei fast allen Brandeinsätzen hochgiftige Brandfolgeprodukte, wie Gase, Dämpfe oder Ruß entstehen. Ganz allgemein zählt das Atemschutzwesen zu den gefährlichsten Tätigkeiten während eines Einsatzes. Aus diesem Grund unterliegt der Einsatz von Atemschutzkräften auch besonders strengen Sicherheitsvorkehrungen. Dazu gehört unter anderem eine kontinuierliche Atemschutzüberwachung (kurz: ASÜ), die einen klareren Überblick sowie eine genaue Koordination der eingesetzten Kräfte und ihrer vorhandene Atemluft ermöglicht. Konkret versteht man darunter die zeitliche Überwachung der eingesetzten Kräfte während eines Atemschutzeinsatzes.

In den vergangenen Jahrzehnten hat sich in Österreich eine Vielzahl an unterschiedlichen Systemen hinsichtlich der ASÜ etabliert. So reicht heute die Produktpalette von der simplen Methode mittels Stift und Papier bis hin zu modernen Softwarelösungen.

Der klassische Vorgang der Atemschutzüberwachung findet in Österreich meist noch immer analog, also mit Stift und Papier, oder anhand einfacher elektronischer Hilfsmittel statt (siehe Abbildung oberhalb). Dabei werden zu Einsatzbeginn alle notwendigen Einsatzparameter wie die Flaschenfülldrücke oder die Einsatzzeiten handschriftlich erfasst. Häufig wird auch eine Stoppuhr gestellt, um jederzeit einen Überblick über die restliche Einsatzzeit zu haben. Diese Vorgehensweise ist meist mit sehr viel Schreibarbeit verbunden und daher nicht nur zeitraubend, sondern auch sehr fehleranfällig, vor allem bei der Überwachung mehrerer Trupps.
Es gibt derzeit nur wenige elektronische Überwachungssysteme bei denen bestimmte Daten automatisch berechnet, aktualisiert und dementsprechend visualisiert werden.
Nach dem bis zum jetzigen Zeitpunkt, zumindest im deutschsprachigem Raum, noch keine mobile Smartphone-App für die Atemschutzüberwachung existiert, hab ich mir das Ziel gesetzt, eine zu entwickeln, um diese Lücke zu schließen.

Methodik

Recherche

Um vorerst einen genaueren Einblick über den aktuellen Stand der Technik zu erlangen, und gleichzeitig eine weitere Grundlage für den empirischen Teil dieser Diplomarbeit zu schaffen, wurde eine Recherche getätigt um Einsicht darüber zu erlangen, welche unterschiedlichen Geräte und Methoden für die ASÜ bereits existieren.
Wie schon erwähnt, gibt es eine Vielzahl an derartigen Systemen. Die Grundfunktionalität jedoch, ist bei allen Systemen die gleiche.

Ein ASÜ-System besteht somit aus folgender Grundfunktionalität

• Vor- und Nachname der eingesetzten Atemschutzträger müssen festgehalten werden können.
• Die aktuelle Uhrzeit muss ablesbar sein. Bei den meisten Systemen ist für diesen Zweck eine kleine digitale Uhr integriert.
• Flaschendruck zu Einsatzbeginn: Zu Beginn des Einsatzes wird der niedrigste Flaschendruck der drei Atemschutzträger notiert.
• Messung der Einsatzzeit pro eingesetzten Trupp: Zu Einsatzbeginn wird begonnen, die Einsatzzeit zu stoppen. Auf diese Weise soll in Echtzeit ein grober Überblick darüber entstehen, wie viel Restzeit dem jeweiligen Trupp noch zur Verfügung steht.
• Festhalten der Bezeichnung bzw. des Funkrufnamens (= eindeutige Bezeichnung für einen Trupp) des jeweiligen Trupps: Jeder eingesetzte Atemschutztrupp muss mit einem eindeutigem Namen versehen werden.

Anforderungsanalyse

Die anhand der Recherche gewonnenen Erkenntnisse in Bezug auf die Grundfunktionalität waren mir im Vorfeld der technischen Implementierung noch nicht ausreichend, sodass ich mich entschied eine Anforderungsanalyse in der Form von Expertengesprächen durchzuführen.

Das Ziel dieser Experteninterviews war die Verfassung eines möglichst umfangreichen Anforderungsdokumentes als fundamentale Grundlage für die nachfolgende technische Umsetzung der mobilen Anwendung.
Konkret ergaben sich so eine Reihe funktionaler Anforderungen sowie unterschiedliche Bedarfe an die Usability.

Technische Implementation

Im Anschluss wurde eine native Android-App konzipiert und technisch umgesetzt. Die wichtigsten Funktionen werden nachfolgend erläutert.

In der Listenansicht kann die Benutzerin/ der Benutzer die bereits angelegten Atemschutzträger samt allen gespeicherten Parametern. Das “Personen-Symbol” soll in einer künftigeren Version durch ein Profilbild ersetzt werden.

Am unteren Bildschirmrand befindet sich ein Plus-Symbol. Klickt man darauf, so gelangt man auf eine neue Ansicht, in der man schließlich ein neues Profil anlegen kann.

Natürlich kann man auch Trupps anlegen und diesem die Atemschutzträger zuordnen, wie die nachstehenden beiden Abbildungen veranschaulichen.

Das eigentliche „Herzstück“ der App ist die Truppdetailansicht. Hier wird die aktuell verfügbare Atemluft anhand eines Balkendiagrammes visualisierst.

Drückt die Benutzerin/ der Benutzer nun auf die Schaltfläche „Einsatz starten“, so wird die Einsatzzeit anhand der zuvor eingegebenen Atemluftmenge berechnet und in Echtzeit aktualisiert, wie der blaue Balken auch.        
Die Einsatzzeit wird dabei wie folgt berechnet:                   
Der Luftverbrauch bei körperlich mittelmäßig anstrengender Arbeit in einem Feuerwehreinsatz wird vom österreichischen Bundesfeuerwehrverband mit 50 Liter Atemluft pro Minute kalkuliert – das entspricht exakt 6,25 Bar pro Minute.
Sinkt die Menge der Atemluft unter 60 Bar, so gibt die App einen Alarmton aus (Restdruckwarnung). 
Selbstverständlich kann der Flaschenfülldruck auch während einem laufendem Einsatz nachkorrigiert werden.

Usability Tests

Um die Einsatztauglichkeit der App zu testen, wurden zehn Usabilitytest mit Vertretern unterschiedlicher Feuerwehren durchgeführt. Dabei wurden einige Optimierungspotentiale für eine künftige Weiterentwicklung gefunden. Außerdem ergab sich ein SUS-Score von 82 Punkten (maximal 100) und eine durchschnittlicher Task-Success von 1,36 (Wertungsskala von 1 bis 4, 1 = beste Note).

Fazit

Der Einsatz von mobilen Endgeräten wird in Wirtschaft und Industrie immer alltäglicher. So ist es auch denkbar, dass sich auch Feuerwehren künftig immer häufiger mit Tablets und Smartphones ausstatten, um Einsätze besser bewältigen zu können. In diesem Zusammenhang ist es auch sehr naheliegend, dass die Atemschutzüberwachung künftig über eine mobile Anwendung erfolgt. Der wesentliche Teil der App konnte bereits im Rahmen dieser Arbeit realisiert werden, sodass diese Version bereits einsatzfähig ist. Unabhängig davon lässt sie aber zum jetzigen Zeitpunkt noch einen großen Spielraum für mögliche Erweiterungen.

The post Diplomarbeit: Atemschutzmanagement appeared first on Mobile USTP MKL.

Eine gut gelungene REST-API zeichnet sich durch unterschiedliche Qualitätsmerkmale aus. Hierzu gehören: Konsistenz, einfache Benutzbarkeit und geeignete Abstraktion. Aber auch eine ordentliche Dokumentation darf dabei nicht fehlen. Schließlich soll die API ja auch für andere Entwickler verständlich und benutzbar sein.

Bevor man mit der Implementierung einer App beginnt, ist es also ratsam, sich über den Aufbau der API Gedanken zu machen. Nur so lassen sich Schwachstellen frühzeitig erkennen und beheben.

Mittlerweile gibt es diesbezüglich eine ganze Reihe verschiedener Formate und Tools, die das Planen, Entwerfen und Dokumentieren von Tools erleichtern bzw. unterstützen. Die bekanntesten sind: RESTful API Modeling language (kurz: RAML), API Blueprint, Open API (auch bekannt als Swagger) und APIDOC.

Dieser Blogbeitrag widmet sich dem Open-Source-Framework „Swagger“. Nach einer kurzen theoretischen Einführung und einen Einblick in die Entstehungsgeschichte, werden wir anhand einer Demospezifikation schrittweise erörtern, wie Swagger in der Praxis funktioniert.

Allgemein

Swagger (http://swagger.io) gehört neben RAML und API-Blueprint zu den meist verwendeten Formate zur Spezifikation von REST-APIs. Swagger bietet ein sprachneutrales und maschinenlesbares Format und wird von vielen Tools erkannt und unterstützt. Das Toolset von Swagger bietet einige praktische Features wie beispielsweise: automatisiertes Dokumentieren, Code-Generierung und Testfallgenerierung. Als Auszeichnungssprache können sowohl YAML aus auch JSON verwendet werden.

YAML

YAML ist eine Auszeichnungssprache zur Serialisierung großer Mengen von JSON-Daten. Das Akronym YAML steht für „YAML Ain’t Markup Language“. YAML ist leichter von Menschen zu lesen und zu schreiben als beispielsweise JSON oder XML.

Geschichte

Das Swagger-API-Projekt wurde 2011 von Tony Tam in’s Leben gerufen. Im Rahmen seiner Tätigkeit als Software-Architekt erkannte er die Notwendigkeit einer automatisierten API-Dokumentation. Denn eine reine Sammlung von URLs reichte als Dokumentation nicht aus und ein einfaches, unkompliziertes Beschreibungsformat existierte bis dato noch nicht. Vor allem aber die Verwendung unterschiedlicher Technologien und Programmiersprachen in Kombination mit WSDL (Web Service Descriotion Language) und WADL (Web Application Description Language) erwies sich als äußerst schwierig.  Daraufhin wurde Swagger entwickelt: eine IDL (Interface Definition Language) für REST-APIs und als Open Source Projekt veröffentlicht.              

Die Demospezifikation „Petstore“

Eine fertige Demonstration einer API-Dokumentation ist der sogenannte Petstore. Diesen finden wir unter: http://petstore.swagger.io/#/

Noch besser ist allerdings die Verwendung des Online Editors. Unter http://editor.swagger.io können APIs mithilfe eines „Live-Editors“ entworfen werden. Der Vorteil dieses Editors ist, dass parallel zum YAML-Code eine interaktive Swagger-HTML-Dokumentation entsteht, wie in folgender Abbildung ersichtlich.

Eine Swagger-Spezifikation beginnt immer mit Metainformationen wie: Spezifikationsversion, gefolgt von generellen Informationen zur API im Abschnitt Info. Host, Pfad und das URL-Schema werden in eigenen Variablen darunter angegeben.

swagger: "2.0"
info:
  description: "This is a sample server Petstore server.  You can find out more about     Swagger at [http://swagger.io](http://swagger.io) or on [irc.freenode.net, #swagger](http://swagger.io/irc/).      For this sample, you can use the api key `special-key` to test the authorization     filters."
  version: "1.0.0"
  title: "Swagger Petstore"
  termsOfService: "http://swagger.io/terms/"
  contact:
    email: "apiteam@swagger.io"
  license:
    name: "Apache 2.0"
    url: "http://www.apache.org/licenses/LICENSE-2.0.html"
host: "petstore.swagger.io"
basePath: "/v2"
tags:
- name: "pet"
  description: "Everything about your Pets"
  externalDocs:
    description: "Find out more"
    url: "http://swagger.io"
- name: "store"
  description: "Access to Petstore orders"
- name: "user"
  description: "Operations about user"
  externalDocs:
    description: "Find out more about our store"
    url: "http://swagger.io"
schemes:
- "https"
- "http"

Ebenso hier zu finden ist auch die Sektion „Tags“. Damit können wir eine Liste mit allen implementierten Ressourcen und dazugehörigen Operationen erstellen. In unserem Fall beginnt diese Sektion mit der Ressource „pet“. Ein kurzer Blick darauf verät uns, was mit dieser Ressource alles geschehen kann: Sie kann gespeichert (POST), aktualisiert (PUT), abgerufen (GET) und natürlich auch gelöscht werden (DELTE).

Der eigentliche Teil der Dokumentation beginnt jedoch erst mit dem Abschnitt ,,paths“. Hier werden die eigentlichen Inhalte dargestellt: Pfade, Operationen, Parameter sowie die dazugehörigen Antworten einschließlich ihrer Beschreibung. Datentypen werden wiederverwendbar in einem Abschnitt definitions verwaltet. Ebenso wird für die gesamte API der Mediatyp (produces/consumers) festgelegt.

paths:
  /pet:
    post:
      tags:
      - "pet"
      summary: "Add a new pet to the store"
      description: "Here we can add a pet"
      operationId: "addPet"
      consumes:
      - "application/json"
      - "application/xml"
      produces:
      - "application/xml"
      - "application/json"
      parameters:
      - in: "body"
        name: "body"
        description: "Pet object that needs to be added to the store"
        required: true
        schema:
          $ref: "#/definitions/Pet"
      responses:
        405:
          description: "Invalid input"
      security:
      - petstore_auth:
        - "write:pets"
        - "read:pets"

Sehen wir uns nun obigen Code, also den Pfad „pet“ mit der Operation „post“ etwas genauer an, um zu verstehen, was die einzelnen Elemente bedeuten. Schon am ersten Blick sehen wir sehr gut die hierarchische Abbildung durch die Einrückungen.

• Das Snippet beginnt mit der „post–Deklaration“ also jener http-Operation die zum Speichern, Erstellen und Weiterverarbeiten von Daten verwendet wird. Der gesamte folgende Code der sich durch die Einrückung hierarchisch darunter gliedert, betrifft logischerweise diesen Befehl.
• Danach wird diese Operation dem Tag „pet“ zugeordnet. Durch diese Zuweisung werden wir den nachfolgenden Code auch in unseren Tags (wir vorhin erläutert) finden.
• Danach finden wir eine Zusammenfassung (summary) und eine Beschreibung (description) über jene Operation vor.
• Die operationId dient zur eindeutigen Adressierung und als mögliche Referenz für lokale Links.
• consumes und produces dienen zum Festlegen sogenannter MIME-Types. Eine API kann Daten in verschiedenen Formaten annehmen und zurückgeben. Die häufigsten sind JSON und XML, wie auch in diesem Fall.
• Parameter: Das Parameterobjekt beschreibt die einzelnen Parameter, die in einer Operation gesendet werden sollen, und bildet somit das Operationsobjekt ab.
• Responses: Hier werden die Rückgabewerte nebst Fehlercode festgelegt.
• Im Abschnitt security werden Berechtigungen definiert.

Das sind jetzt nur einige wichtige Funktionen von Swagger. Natürlich umfasst die Swagger-Spezifikation noch viel mehr Funktionen, auf die aber hier nicht bis ins Detail eingegangen werden soll. Dafür bietet sich die Dokumentation an: https://swagger.io/docs/specification/about/

API-Endpunkte

Wer künftig seine APIs mit Swagger dokumentieren will, benötigt ein Verständnis dafür wie man sogenannte Endpunkte definiert. Sie bilden schließlich das Herzstück einer Dokumentation. Ein Endpunkt ist eigentlich nichts anderes als eine Operation die von einem Benutzer ausgeführt wird.

Auch in unserem Petstore finden wir eine Reihe verschiedener Benutzeroperationen in Form von Pfaden.

Dazu einige Beispiele:

Innerhalb dieser Endpunkte werden mögliche Antwortnachrichten spezifiziert. Die Antwortnachricht mit einem Statuscode von beispielsweise 404 referenziert die globale Definition für das Pet-Datenmodell das die Fehlermeldung „Pet not found“ zurückliefert. Eine Antwortnachricht mit dem Code 200 hingegen, referenziert die die globale Definition, die ein bestimmtes Pet zurückliefert. (siehe nachfolgendes Listing)

paths:
  /pets/{petId}:
    get:
      tags:
        - pet
      summary: Find pet by ID
      description: Returns a pet
      produces:
        - application/json
      parameters:
        - in: path
          name: petId
          description: ID of pet that needs to be fetched
          required: true
          type: integer
          format: int64
      responses:
        "200":
          description: successful operation
          schema:
            $ref: "#/definitions/Pet"
        "400":
          description: Invalid ID supplied
        "404":
          description: Pet not found

So lassen sich mit Swagger httpbasierte APIs sehr gut abbilden.

Die interaktive Swagger-HTML-Dokumentation

Der nachfolgende Screenshot zeigt einen Ausschnitt der interaktiven Swagger-HTML-Dokumentation. Was auf den ersten Blick sehr übersichtlich und anschaulich aussieht, birgt noch große Verbesserungspotentiale. So liegt beispielsweise der Schwerpunkt dieser Visualisierung auf den API-Endpoints, nicht aber auf einer Funktionsbeschreibung, die jedoch von großem Nutzen wär. Wenn nun also ein Benutzer die API noch nicht kennt, und nach einer bestimmten Funktion sucht, wie bspw. deletePetById(), würde er nicht nach dem passendem Endpoint suchen, sondern nach der gewünschten Funktionalität.

Ein weiteres Manko ist der fehlende PDF-Export. In vielen Fällen wird man die Doku auch im PDF-Format benötigen – beispielsweise bei Projektabnahme oder für den Fall dass bei einer Ausschreibung auch eine Doku mitgeliefert wird.

Nichtsdestotrotz: Swagger ist noch immer ein relativ junges Framework, das laufend weiterentwickelt wird. Swagger UI und alle anderen Swagger-Tools sind kostenfrei und Open Source. Zudem hat sich Swagger auch sicher nicht zufällig zu einem der Marktführer gekämpft. Ich bin zuversichtlich, dass Swagger auch in den kommenden Jahren eine wichtige Rolle im Bereich der Software-Dokumentation spielen wird.

The post REST APIs dokumentieren – Einführung in Swagger appeared first on Mobile USTP MKL.

Dieser Blogbeitrag ist der vierte Teil einer JMeter-Serie und setzt grundlegende JMeter-Kenntnisse voraus. Neueinsteigern empfehle ich, vorerst die drei vorangegangenen Blogartikel zu lesen oder noch besser: durchzuarbeiten. Am Ende dieses Beitrages wird darauf verlinkt.

Realistischer Usertest

In unserem vierten Tutorial wollen wir nun einen realistischen Usertest erstellen. Wie es der Name schon sagt, kommt ein realistischer Usertest dem tatsächlichen Surf-Verhalten der Benutzer sehr nahe. Zunächst muss aber geklärt sein, was genau ein realistischer User-Test überhaupt ist bzw. welche Kriterien er zu erfüllen hat, um als ein solch einer zu gelten.

Das wichtigste Kriterium  in diesem Kontext ist die sog. Think-Time. In der Praxis liegt zwischen den einzelnen Requests immer ein kleiner Delay vor – nämlich jene Zeit, in der der Benutzer auf der Seite verweilt. Diese Zeit nennt man Think-Time. Sie ist natürlich nicht immer konstant, sondern unterliegt mehr oder weniger starken Schwankungen. Dafür werden wir den sogenannten Random-Timer verwenden. Dieser bestimmt die Random-Time per Zufallsgenerator, durch die Eingabe eines Minimal- und Maximalwertes.

Wozu eine Stepping Thread-Group?

Eine Stepping Thread-Group ist ein hervorragendes Feature zum detaillierten Konfigurieren von Threads. Mit einer herkömmlichen Thread-Group konnten wir die Dauer der Ramp-up- und Ramp-down-Time lediglich linear definieren, und damit nur sicherstellen, dass beispielsweise nach 20 Sekunden eine Auslastung von 200 Usern besteht. Mit einer Stepping Thread-Group haben wir nun die Möglichkeit, die Userlast portionsweise zu steigern, wie wir in der nachstehenden Grafik erkennen:

Abb. 1: Stepping Thread-Group mit eingezeichneten Kenngrößen

Mit einer Stepping Thread-Group können folgende Parameter definiert werden:

• Start-Delay: Jene Zeit, die verstreicht, bis der Test startet.
• Anzahl der Start-Threads (auch: Target-Load): Der Test startet mit xy User
• Ramp-up-Period: alle x Sekunden kommen weitere y User hinzu
• Ramp-down-Period: alle x Sekunden kommen  y User weg
• Load-Time: Jene Zeitspanne, in der die Plattform mit dem Maximum an Threads belastet wird

Download und Installation

Zunächst benötigen den Plug-In-Manager, um später das Plugin-Stepping-Thread-Group installieren zu können. Diesen gibt es hier zum Download.

Ist der Download abgeschlossen, legen wir das Jar-File in den Ordner „lib/ext“ und starten JMeter neu. Nun gib es im Menüpunkt „Options“ ganz unten den Punkt „Plugins Manager“, den wir nun verwenden. Im Reiter „Availables Plugins“ suchen wir nach dem Eintrag „jpgc-Standard Set“ und werden relativ weit unten fündig. Hier setzen wir das Häckchen und klicken rechts unten auf „Apply…“.

Nun können wir  die Stepping Thread-Group unserem Testplan hinzufügen: Rechtsklick / Hinzufügen / Threads / Stepping Thread-Group

In der nachstehenden Eingabemaske können wir nun die Parameter von Abbildung 1 definieren.

Abb. 2: Stepping Thread Group in JMeter

Testplan erstellen

Wurde die Stepping-Thread-Group erfolgreich installiert und konfiguriert, solle der Rest eigentlich kein Problem mehr darstellen. Nun können wir die Stepping Thread-Group mit HTTP-Request befüllen und dazwischen jeweils die Random-Timer (Hinzufügen / Zeitgeber / Uniform Random Timer) einfügen. Unser Testplan sollte nun in etwa so aussehen:

Abb. 3: Testplan mit integrierter Stepping Thread-Group

Vorteile in der Praxis

Was die Auswertung des Tests betrifft, ergibt sich für uns in der Praxis nun ein wesentlicher Vorteil: Wir können leichter herausfinden, wo die Belastungsgrenze des zu testendem Systems liegt. Denn durch das schrittweise hinzufügen von virtuellen Benutzern, kennen wir die genaue Anzahl zu jedem Zeitpunkt, anders als bei einer normalen Thread-Group.

Weitere Tutorials

JMeter Tutorial 1: Grundlagen, Listeners und Assertions

JMeter Tutorial 2: DB, Web-Services und FTP

JMeter Tutorial 3: Test Script Recording

The post JMeter Tutorial 4: Stepping Thread Group appeared first on Mobile USTP MKL.

Proxy-Server-Architektur

Vorbereiten des Testplans

Aufnahme starten

Weitere Tutorials

The post JMeter Tutorial 3: Test Script Recording appeared first on Mobile USTP MKL.

Mobile Applikationen sind als verlässliche Frühwarnsysteme oder zusätzliche Kommunikationsmittel von großer Bedeutung. Dank der zahlreichen Funktionen über die sie heute verfügen (GPS, Mobilfunk, Kamera, Bluetooth, interner Datenspeicher,…) sind sie in der Lage, eine Hilfestellung zu bieten. Sei es bei einer Suchaktion nach einem Erdbeben, als Wetter- und Gefahrenwarndienste, zur Anleitungen von Erste-Hilfe-Maßnahmen oder auch nur für rein organisatorische Zwecke.
Die Forschung in diesem Bereich konzentriert sich stets auf die Mensch-Maschinen-Interaktion zwischen den Betroffenen und den helfenden Akteuren.      
Je nach Kontext der Krise oder Katastrophe ergeben sich unterschiedliche Ziele an die Kommunikation. Das Grundprinzip ist jedoch immer das Gleiche: die Unsicherheit der Betroffenen zu reduzieren.
In diesem Blogartikel wird ein grober Einblick in die Nutzung mobiler Anwendungen in gefährlichen Situationen gegeben.

Warnung vor Naturkatastrophen und anderen Gefahren

Es existiert eine Reihe unterschiedlicher Apps, um die Bevölkerung rechtzeitig vor drohenden Gefahren warnen. Die App „Katwarn“ beispielsweise, informiert Menschen bei Krisen- und Katastrophenfällen sowie über Großeinsätze von Blaulichtorganisationen. Oberstes Ziel ist, dass relevante Informationen treffsicher an die Bevölkerung gebracht werden. Die User erhalten die Informationen entweder über einen von ihnen definierten Standort oder jenen Ort der per GPS getrackt wird. Die Daten werden von behördlicher Seite eingespeist und sind demnach auf eine zertifizierte Quelle zurückzuführen. Es gibt auch noch andere Sicherheits-Apps die vor Terrorgefahr, Bombenentschärfungen usw. warnen – und auch jene, mit denen man den Aufenthaltsort von Angehörigen überprüfen kann. Letzteres findet vor allem in Regionen mit akuter Terrorgefahr Anwendung.

Crisis Mapping

Ein Begriff der in diesem Zusammenhäng auch häufig vorkommt, ist „Crisis Mapping“ (auch: Disaster Mapping genannt). Hierbei werden während einer Naturkatstrophe Daten gesammelt, ausgewertet und schließlich der Öffentlichkeit zur Verfügung gestellt. Nach einer Naturkatastrophe können beispielsweise Einsatzkräfte dieses kartographische Material als Hilfestellung verwenden und dadurch schneller und effizienter humanitäre Hilfe leisten.
Auf sozialen Netzwerken wie Facebook und Twitter posten User während bzw. nach einer Katastrophe häufe Beiträge mit persönlichen Erlebnissen und Bildern. Dieses Material kann sowohl für andere Betroffene, als auch für die Helfer von enormer Wichtigkeit sein. Die App Clickers von Micro Mappers hilf dabei, diese Informationen logisch zu kategorisieren, um den Hilfsorganisationen die Arbeit zu erleichtern.

Das Smartphone als Kommunikationsmittel am Beispiel „smarter“

In Zusammenarbeit mit der TU Darmstadt und der Uni Kassel wurde die App „smarter“ entwickelt. Diese kann eine Ad-hoc-Verbindung ohne Internet und ohne Mobilfunk herstellen. So soll der Hilferuf bzw. das Lebenszeichen des Betroffenen auch dann weitergeleitet werden, wenn das Strom- und Mobilfunknetz lahmgelegt sind. Über einen W-LAN-Chip verbindet die App das Telefon mit einem andern Smartphone, auf dem die App installiert ist und sich in der Umgebung befindet. Dieses Gerät stellt wiederum weitere Verbindungen her. So entsteht ein Ad-hoc-Netz über welches die User miteinander kommunizieren, aber auch Statusmeldungen und Hilferufe weiterleiten können. Die mobilen Endgeräte funktionieren faktisch wie Funkgeräte.
Die App implementiert auch eine Karte, auf der angezeigt wird, wo Hilfe benötigt und angeboten wird.

Mobiles Crowdsourcing und VGI

Bei mobilen Crowdsourcing werden mobile Endgeräte zum Sammeln von Daten eingesetzt. Das Grundkonzept dahinter ist, dass sich Freiwillige beteiligen und dadurch auch keine Koste anfallen. Meist tragen die Beteiligten damit auch zu ihrem eigenen Nutzen bei. Die gesammelten sogenannten VGI-Daten (Voluntered Geographic Information) sind meist orts- und raumbezogen, häufig aber auch zeitbezogen. Es sind zahlreiche mobile Crowdsourcing-Anwendungen bekannt, insbesondere im Natur-, Umwelt- und Katastrophenschutz. So werden beispielsweise während eines Erdbebens die Bevölkerung und die Einsatzkräfte mit wichtigen Informationen versorgt. Nach einem Einsatz dient die App dazu, um vorhandene Schäden zu bewerten, dokumentieren und analysieren.

Bei einem VGI-basierten Prognosesystem sind zwei Bestandteile unerlässlich: Mobile Tasking und Mobile Sensing.

Unter Mobile Tasking versteht man das Rekrutieren von Freiwilligen zum Sammeln von Daten. Häufig bestimmen sie selbst über ihren Anonymitätsgrad und werden von einer zentralen Komponente gebeten, hydrologische Messungen durchzuführen. Dem Nutzer steht es natürlich frei, ob er die Aufgabe ablehnt oder annimmt. Mobile Sensing ist der eigentliche Vorgang des Datensammelns und des zur Verfügung Stellens der Daten auf diversen Plattformen. 

Quellen

Titelbild: Quelle: dpa
(https://www.rhein-zeitung.de/nachrichten/netzwelt/news_artikel,-kommunikation-im-krisenfall-smarterapp-funktioniert-ohne-netz-_arid,1763985.html)

The post Mobile Apps als Helfer in sicherheitskritischen Situationen appeared first on Mobile USTP MKL.

Dropsource punktet vor allem in Sachen Effizienz und Geschwindigkeit. Einzelpersonen und Unternehmen, die in kurzer Zeit innovativ sein müssen profitieren vor allem von der relativ einfachen Handhabe und der schnellen Erlernbarkeit. So wird Dropsource gerne dazu verwendet, einen Prototyp zu bauen und zu testen.

Prototyping und Build

Mit Dropsource lässt sich mit vertretbaren Zeitaufwand ein funktionaler Prototyp, sowohl für iOS als auch für Android entwickeln – und das schneller, als je zuvor. Mit einem Drag-and-Drop-Builder, also einem visuellen Interface, lassen sich UI-Elemente platzieren und so ganze Apps „zusammenklicken“. Der entscheidende Vorteil liegt darin, dass der Auftraggeber schon relativ bald ein vorläufiges Ergebnis betrachten kann.

Die manuelle Programmierung wird hierbei völlig überflüssig. Dennoch bietet Dropsource Zugriff auf den nativen Code, der beim „Zusammenbauen“ im Hintergrund entsteht. Selbstverständlich ist dieser auch editierbar. Dadurch ist es möglich, eigene Features und Elemente zu entwickeln und das User-Interface nach individuellen Wünschen anzupassen.

Drag and Drop Builder (Quelle: https://www.dropsource.com)

Externe Datenquellen

Die Resultate sind dabei vollständig nativ und können auch mit einer REST-API verbunden werden. So können problemlos datengesteuerte Anwendungen erstellt werden.  Auch externe Datenquellen von öffentlich zugänglichen APIs wie Facbeook, Google und dgl. können problemlos integriert werden.

Testing und Deployment

Ist die App einmal testbereit, so kann sie dafür direkt auf ein Gerät gesandt und im Browser geöffnet werden. Das Browsertesting läuft dabei über das Tool Appetize.io

Der Code, den die Entwicklungsplattform generiert, ist bei iOS-Apps in Swift, und bei Android-Apps in Java geschrieben. Daher lässt sich die fertige App ganz einfach herunterladen. Der Code kann natürlich anderswertig weiterverarbeitet und angepasst werden. Auch ein Veröffentlichungsdienst für AppStore und Playstore steht bei Dropsource zur Verfügung.

Derzeit ist Dropsource noch kostenlos. Um jedoch in den Genuss einer Reihe praktischer Zusatzfeatures zu kommen, bezahlt man 39$ pro Monat und Projekt.

Mehr Infos siehe: https://www.dropsource.com/pricing/

Weiterführende Links

https://www.dropsource.com/

The post Dropsource – der erste visuelle Ansatz für mobile App-Entwicklung appeared first on Mobile USTP MKL.

Dies ist keine Lektion für Anfänger. Um diesem Tutorial folgen zu können, ist es notwendig, die grundlegenden Kenntnisse von JMeter zu beherrschen, welche in diesem Beitrag behandelt werden. Auch grundlegende SQL-Kenntnisse sowie Erfahrungen mit phpMyAdmin sind von Vorteil.

Datenbank – Testing mit JMeter

Vorbereitungen

Im ersten Abschnitt dieses Tutorials werden wir einen Testplan zum Testen eines Datenbankservers erstellen, wiederum mehrere User simulieren, die parallel viele Datenbank-Requests an den Server senden.

Zu Beginn benötigen wir eine SQL-Datenbank mit einer Tabelle. Dafür verwende ich den lokalen Testserver XAMPP und phpMyAdmin als Admin-Panel. Natürlich kannst Du auch gerne ein anderes Datenbanksystem verwenden.

Nun erstelle ich eine kleine Tabelle mit ein paar Testdatensätzen. (siehe Abbildung) Der Name meiner Datenbank lautet: Personen.

Datenbanktabelle mit Testdaten

Im nächsten Schritt müssen wir JMeter mit der Datenbank verbinden. Dazu benötigen wir den sogenannten MySQL-Connector, also einen Treiber, der uns über die ODBC-Programmschnittstelle einen Datenbankzugriff ermöglicht.

Dazu gehen wir in den Downloadbereich der Seite: dev.mysql.com

Etwas weiter unten gibt es den MySQL-Connector als Zip-File zum Download. Den Zip-Folder entpacken wir und suchen uns das darin enthaltene JAR-File heraus. Bei mir lautet der Dateiname: mysql-connector-java-5.1.46. Bei Verwendung einer anderen (aktuelleren) Version wird die Datei logischerweise mit einer anderen Versionsnummer gekennzeichnet sein.

Diese Datei kopieren wir nun in den Ordner „lib“ unseres JMeter-Verzeichnisses.

Testplan

Wie wir es bereits aus dem letzten Tutorial kennen, beginnen wir auch hier unseren Testplan wieder mit der Erstellung einer Thread-Group. Um es einfach zu halten, simulieren wir 10 User zu je 10 Wiederholungen.

Thread-Gruppe

Als nächstes fügen wir ein JDBC-Connection-Configuration-Element ein der Thread-Group ein. (Rechtsklick auf Thread-Group / Hinzufügen / Konfigurationselement / JDBC-Connection-Configuration).

Hier können wir nun im Abschnitt „Database Connection Configuration“ eine Verbindung zur Datenbank herstellen. In der Datenbank-URL geben wir den Link zur Datenbank an, und am Ende (Nach dem Schrägstrich) den Namen der Datenbank. Gleich darunter geben wir den Namen des Treibers, welchen wir vorhin installiert haben, an. (com.mysql.jdbc.Driver)

Wichtig ist hier auch das Feld „Variable Name for created pool“. Damit geben wir der Datenbankverbindung den Namen „test“. Wozu wir das brauchen, sehen wir später.

JDBC-Connection Configuration

Nun können wir uns endlich dem Wesentlichen widmen. Wir erstellen einen JDBC-Request (Rechtsklick auf Thread-Group / Hinzufügen / Sampler / JDBC Request).

Mit diesem Sampler können wir nun einen SQL-Request an die Datenbank senden. Ich gebe nun einen SQL-Befehl zur Auswahl aller Datensätze der Tabelle Personen im Feld Query ein:

select * from personen

Im Feld Query Type wählen wir „Select Statement“ aus. Auch hier gibt es wieder ein Feld in dem ein Variable-Name zu vergeben ist. Auch hier geben wir wieder den Namen „test“ an, um JMeter zu sagen, auf welche Datenbankverbindung es sich beziehen soll. Jeder JDBC-Request benötigt also einen klaren Bezug zu einer Datenbank. Selbstverständlich können sich auch mehrere Requests auf dieselbe Datenbank beziehen.

JDBC-Request

Damit wir unser Ergebnis auch betrachten können, benötigen wir noch einen Listener. Was ein Listener ist, haben wir bereits im vorherigen Kurs kennen gelernt. Ich füge einen Results-Tree und eine Ergebnistabelle hinzu.

Mein Testplan sieht nun so aus:

Testplan mit JDBC-Connection

Ergebnis

Nun können wir den Test ausführen, und die Ergebnisse im Results Tree betrachten. Wie wir hier sehen, haben alle Requets funktioniert. Im Reiter „Response data“ sehen wir auch die zurückgelieferten Daten.

View Results Tree mit Ergebnissen der JDBC-Requests

Web-Services (API)

Was ist ein Web-Service?

Ein Web-Service ist ein Dienst zur Kommunikation zwischen Client und Server auf Basis von HTTP oder HTTPS über ein Netzwerk. Dabei werden meist Daten ausgetauscht und Funktionen ausgeführt. Jeder Web-Service besitzt eine URI (Uniform Resource Identifier) über die wer eindeutig identifizierbar ist.
Wenn Du beispielsweise über eine Online-Plattform einen Flug buchst oder eine Bestellung abwickelst, kommen dabei Webservices zum Einsatz.

Webservice Schnittstellen: REST und SOAP

Bei REST (Representational State Transfer) wird versucht, die Schnittstelle auf eine Reihe vordefinierter Standartoperationen (GET, PUT, POST, DELETE,…) zu beschränken. Der Schwerpunkt von REST liegt auf der Maschine-zu-Maschine-Kommunikation und der Interaktion von zustandslosen Ressourcen. Welches Datenformat die Serverantwort liefert, wird durch REST nicht spezifiziert!

Rest-Prinzipien

• Adressierbarkeit: Jeder Dienst bzw. jede Ressource hat einen eindeutigen URI (Uniform Resource Identifier)
• Unterschiedliche Repräsentationen: Je nach Anwendung kann ein REST Server unterschiedliche Repräsentationen der Daten ausliefern (JSON, XML, HTML,…)
• Zustandslosigkeit (stateless)

Jede Anfrage enthält sämtliche Informationen die zur Abarbeitung nötig sind

SOAP (Simple Object Access Protokoll) ist ein vom World Wide Web Consortium (W3C) unterstützter Standard für den Nachrichtenaustausch zwischen verteilten Systemen. Zur Repräsentation von Daten stützt sich SOAP meist auf XML und zu deren Übertragung auf Internetprotokolle.

Testen eines REST-Web-Services

Wie gewohnt, beginnen wir auch hier wieder mit einer Thread-Group und fügen dieser einen http-Request hinzu. (Hinzufügen / Sampler / http-Request)

Als nächstes benötigen wir eine frei verfügbare REST-API, die wir später auch testen können.
Die Website https://openweathermap.org/  stellt globale Wetterdaten kostenlos zur Verfügung und liefert diese über eine API aus.

Die API kann nur mit gültigem API-Key genutzt werden, dessen Verfügbarkeit eine Registrierung voraussetzt. Diese Registrierung ersparen wir uns aber, und verwenden stattdessen einen frei verfügbaren Test-API-Call, der zwar keine Verbindung zum echten API-Dienst hat, aber dennoch Daten zurückliefert.

Auf folgenden Unterseiten können wir nochmals genau nachlesen, wie auf die API zugegriffen werden kann und wie ein API-Call aufgebaut wird:

https://openweathermap.org/appid
https://openweathermap.org/current

Im zweiten Link finden wir unter anderem auch ein Beispiel für einen API-Call der uns Wetterdaten über London liefert:

api.openweathermap.org/data/2.5/weather?q=London

Wenn wir den Call nun im Browser aufrufen erhalten baut sich die nachstehende URL zusammen, und liefert und ein JSON-Objekt retour.

http://samples.openweathermap.org/data/2.5/weather?q=London,uk&appid=b6907d289e10d714a6e88b30761fae22

Soweit so gut! Bevor wir aber jetzt wieder mit JMeter weiterarbeiten, wollen wir noch genauer verstehen, woraus sie der API-Call zusammensetzt und was die einzelnen Fragmente darstellen. Die nachstehende Liste soll dabei Aufschluss geben:

• samples.openweathermap.org = Webserver und/oder API-Name
• /data/2.5/weather = Pfad
• q=London,uk = 1. Parameter “q”: Stadt und Länderkürzel
• appid=b6907d289e10d714a6e88b30761fae22 = 2. Parameter: appid

Jetzt müssen wir den Call nur noch dem Testplan hinzufügen. Den Servername und den Pfad kopieren wir einfach in das entsprechende Feld. Die beiden Parameter fügen wir als Key-Value-Pairs der Tabelle hinzu. Am Ende sollte es dann so aussehen:

HTTP-Request

Wenn wir dem Testplan nun einen Listener hinzufügen und dann ausführen, werden wir sehen, dass der Request das JSON-Objekt zurückliefert.

Response Data

FTP-Requests

Im unserem dritten und letzten Abschnitt lernen wir, wie man eine FTP-Site mit JMeter testet. Auch hier erstellen wir wieder eine Thread-Gruppe, mit der wir später einen Benutzer simulieren werden. Dieser soll beim Ausführen unseres Tests eine Datei vom Server herunterladen.

Dazu fügen wir nun einen FTP-Request der Thread-Group hinzu. (Rechtsklick auf die Thread-Group / Hinzufügen / Sampler / FTP-Anfrage)

Nun benötigen wir noch einen Webserver mit FTP-Zugang. Ich verwende dafür einen meiner privaten Webspaces und gebe deren Verbindungsdaten in der Detailansicht der FTP-Anfrage ein (Servername, Username, Passwort).

FTP Request

Als nächstes stelle ich über den FTP-Client eine Verbindung zum Server her und lade via Drag and Drop eine Datei (folder.php) in das Root-Verzeichnis. Es bleibt dir selbst überlassen, welche Datei du hierfür verwendest. Wichtig ist nur, dass sie nicht zu groß ist.

Dateiverzeichnis

Als nächstes wollen wir mit JMeter diese Datei vom Server wieder runterladen. Dafür ergänzen wir die Details der FTP-Anfrage wie folgt:

Wir geben den Namen der Datei an (folder.php), sowie den lokalen Speicherort an. Wichtig ist außerdem auch, dass wir die Get-Methode auswählen.

FTP-Request mit Dateipfaden

Nun können wir noch einen Listener hinzufügen und den Test starten. Wenn Du alles richtig gemacht hast, sollte nun die angegebene Datei vom Webserver in das angegebene Verzeichnis transferiert werden.

In diesem Tutorium haben wir uns fortgeschrittenes JMeter-Wissen angeeignet und dabei gelernt, wie man die Verfügbarkeit von Daten in einer Datenbank, die Funktion eines Web-Services, sowie den Datentransfer via FTP prüft. Damit sind wir nun in der Lage, umfassende Benutzerinteraktionen zu simulieren und interaktive Systeme zu testen.

The post JMeter Tutorial 2: DB, Web-Services und FTP appeared first on Mobile USTP MKL.