Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added two use cases #130

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
104 changes: 104 additions & 0 deletions use-cases/BuildingManagement.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,104 @@
# Building Management

**Contributed by:** hylkevds - Fraunhofer IOSB

## Typical user scenario:

A campus of a large organisation has multiple buildings.
The campus has sensors measuring all sorts of observed properties in rooms, hallways and elevators, on doors and windows.
To enable complex querying it would be best to have the relations between those Things/Locations fully exposed in the data model.

An example domain data model:

![Building data model](images/Datamodel-Building-Base.drawio.png)



### Option 1

Squeeze everything into things.

Advantage:
- 100% SensorThings API.

Disadvantages:
- Makes linking between different items difficult.
- Everything is in Things, not ideal for domain clients.

### Option 2

Expose the model, mirroring each entity as a Thing:

Advantage:
- 100% SensorThings API.
- Domain clients get the full querying flexibility.

Disadvantages:
- All domain entities are duplicated, need to be maintained twice.
- There is a Thing between domain entities and their Datastreams.

![Model next to Thing](images/Datamodel-Building-SensorThings-1.drawio.png)

### Option 3

Replace Things with entities from the model:

Advantage:
- Perfect model for domain clients.
- Domain clients get the full querying flexibility.

Disadvantages:
- Breaks SensorThings API clients.

![Model Instead of Things](images/Datamodel-Building-SensorThings-2.drawio.png)

### Option 4

Mirror Things from domain entities, using a database view with unions.

Advantage:
- 100% SensorThings API.
- Domain clients get the full querying flexibility.
- No data duplication.

![Model Instead of Things and Locations](images/Datamodel-Building-SensorThings-3.drawio.png)



## Actors:
List of actors that participate in the use case
1. First Actor
2. Second Actor

## Preconditions:
List of conditions required to make the use case possible
1. First precondition
2. Second precondition
3. Third precondition

## Process:
List of steps taken in completing the use case
1. First step in process
2. Second step in process
3. Third step in process


## Required input:
List of inputs required to satisfy the use case
1. First input
2. Second input
3. Third input

## Output:
The list of outputs from the use case
1. output one
2. output two

## Extensions:
List of extensions of the use case
1. First extention option
2. Second extension option




54 changes: 54 additions & 0 deletions use-cases/ChargingStations.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,54 @@
# Smart City Charging Stations

**Contributed by:** HylkeVDS - Fraunhofer IOSB

## Typical user scenario:

A city has many different sensors on-line. One sensor type measures the
availability of charging stations for electic vehicles. A user looking for a
parking spot with charging capabilities would like to find a suitable spot
near his destination, and if none are available, set a subscription so that
he is notified when a spot becomes available in the geospatial area near his
destination.

* In v1.1 the user needs to set an individual subscription for each Datastream
(parking spot) in the area he is interested in.


## Actors:
List of actors that participate in the use case
1. First Actor
2. Second Actor

## Preconditions:
List of conditions required to make the use case possible
1. First precondition
2. Second precondition
3. Third precondition

## Process:
List of steps taken in completing the use case
1. First step in process
2. Second step in process
3. Third step in process


## Required input:
List of inputs required to satisfy the use case
1. First input
2. Second input
3. Third input

## Output:
The list of outputs from the use case
1. output one
2. output two

## Extensions:
List of extensions of the use case
1. First extention option
2. Second extension option




2 changes: 1 addition & 1 deletion use-cases/LeadInLiverInFishInRiver.md
Original file line number Diff line number Diff line change
@@ -1,4 +1,4 @@
# Use Case title
# Lead in Liver in Fish in River

**Contributed by:** hylkevds - Fraunhofer IOSB

Expand Down
2 changes: 1 addition & 1 deletion use-cases/SensorsInRooms.md
Original file line number Diff line number Diff line change
@@ -1,4 +1,4 @@
# Use Case title
# Sensors in Rooms

**Contributed by:** hylkevds - Fraunhofer IOSB

Expand Down
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.