Het SensorBucket project is voortgekomen uit de noodzaak om diverse data van verschillende sensoren beschikbaar te stellen in de interne systemen van de Provincie Zeeland. Het probleem hierbij lag bij de manier waarop verschillende sensoren de data beschikbaar stellen, dit is vrijwel altijd via een specifieke bron in een specifiek formaat. Het SensorBucket project doelt erop om data op een generieke wijze te ontvangen en te generaliseren conform een set standaarden. De ontsluiting van deze generieke kan vervolgens op verschillende wijze plaatsvinden, maar de meest voor de hand liggende is via een standaard gespecificeerd door het Open Geospatial Consortium (OGC).

De volgende richtlijnen zijn van toepassing op het systeem:

• Het systeem dient verschillende ondersteunde dataformaten uit verschillende ondersteunde databronnen te kunnen generaliseren;

• Nieuwe databronnen en dataformaten dienen gemakkelijk toegevoegd te kunnen worden;

• Het systeem moet grote hoeveelheden data kunnen verwerken zonder sterke vertraging.

Planning

Het systeem wordt ontwikkeld in twee fases. Fase 1 heeft als doel het mogelijk maken van het gebruik intern bij de provincie, hierbij is functionaliteit vooral belangrijk en veiligheid minder. Aan het eind van fase 2 moet het systeem geschikt zijn voor openbaar gebruik. Er zal dan ook een werkwijze voor de Open-Source community opgesteld moeten zijn.

Opbouw

Het project wordt ontworpen met gebruikers functionaliteit in het midden. Vanuit deze gewenste functionaliteiten zullen meer specifieke eisen voortkomen die gebruikt worden voor het systeem ontwerp en uiteindelijke implementatie.

Om op de juiste lijn te blijven tijdens het ontwerpen en ontwikkelen van het systeem is een duidelijke context vereist. Er wordt een probleemstelling en een gewenste situatie in beschreven waaruit vervolgens meer informatie geëxtrapoleerd kan worden, zoals: use-cases.

Door middel van C4-Diagrammen wordt het systeem in beeld gebracht. De C4-Diagrammen zijn hieronder kort toegelicht.

Via een context-diagram word het gebruik van het systeem in beeld gebracht en de communicatie met andere systemen.

Met een container-diagram worden de verschillende applicaties weergegeven. Elke applicatie heeft een eigen verantwoordelijkheid.

De applicaties worden vervolgens opgedeeld in componenten met bepaalde functionaliteiten.

Elk component kan vervolgens volledig in beeld worden gebracht met behulp van een klassen-diagram.

Open

 

Contextueel

Met de opkomst van het Internet-of-Things en de toegankelijkheid van embedded systems (denk aan Arduino) is het steeds makkelijker voor mensen om zelf apparatuur te maken dat aan het internet zit verbonden. Door de combinatie van goedkope sensoren en de mogelijkheid zelf apparatuur te maken komen er steeds meer meetinstrumenten op de markt. Het nadeel is dat er weinig structuur in zit en data van diverse bronnen en in verschillende formaten verzonden wordt.

Om het meeste uit deze gefragmenteerde data te krijgen is het van belang dat deze metingen ontvangen kunnen worden en vervolgens als gestandaardiseerde data ontsluit wordt. Deze situatie is zichtbaar in het context diagram hieronder.

Open

Containers

Het systeem bestaat uit verschillende applicaties (containers) met ieder een eigen verantwoordelijkheid. Deze applicaties bevinden zich in een business-domein. De meest up-to-date versie van het domein-model en de container diagram kan gevonden worden op de pagina https://multiflexmeter.atlassian.net/wiki/spaces/SEN/pages/255131651 .

Componenten & Klassen

Een applicatie bestaat uit één of meerde componenten die samenwerken om functionaliteiten te realiseren. Deze componenten bestaan vervolgens uit klassen waar de code zich in bevind.

Onder https://multiflexmeter.atlassian.net/wiki/spaces/SEN/pages/255131651 zijn alle applicaties zichtbaar met een link naar een bijhorende pagina. Deze pagina bevat het ontwerp van de applicatie, hierin zullen ook component- en klassen-diagrammen in voorkomen.