# data[].attributes.body
Positive:
-Used a bus
-Used more artifacts than us
-Use of more specific names

Negative:
-Too complex architecture
- Could add notes
-Don't have controller

# data[].attributes.body
+More detail
+Color
+Not hand drawn
-More assumptions
-To much implementation detail, splitting up into several assumed artifacts
-We believe sensors should have a deploy connection

# data[].attributes.body
Better:
- Water gate in the diagram
- Not arrows on the communication lines
- Shows the idea clearly

Worse:
- You don't need the webapp, its not clear from the text
- You miss <<>> on the connections
- picture is the wrong way

# data[].attributes.body
Pros:
1. Used execution environments
2. Used a bus to connect sensors
3. Demonstrated used of a note

Cons:
1.No connection from app to sluice control
2. No stereotype on artifact on server
3. Could have used instance specification instead of a not to describe the KBox

# data[].attributes.body
Things they did better:
* They added notes to explain further.
* Better visualization of the devices.
* Followed the UML-notation syntax better than us.

Things we did better:
* We split up servers between cloud and application
* We included the IoT-gateway
* We have better distinction between the roles of the individual devices.

# data[].attributes.body
They did better
-They used << >> around the connections
-Good allocation of space, so very easy to read the words
-Less elements so might be easier to understand

We did better
-Better use of prototype names (like device, artifact etc.)
-Giving the floodgates a possibility to open/close
-More descriptive

# data[].attributes.body
Positive:
+ Clean and simple sketch
+ Good for explaining the idea in general
+ Consistent in semantics/notation

Negative:
- Missing gate controls
- Wrong protocol between Cloud and PC/Smartphone (uses TCP/IP?)
- Arrows on the communication lines

# data[].attributes.body
+ More sensors shown
+ Good use of notes
+ Nicely structured

- Sensors shown as part of the K-Box, which seems inaccurate
- Weird semicolons
- Smartphone vs. computer split seems unnecessary

# data[].attributes.body
Better:
- Have included all the sensors
- Differ between one-way and two-way communication
- Good structure
Worse:
- Connected the smartphone to wrong device
- Missing components (water gate, software)
- Used wrong communication between pc<--server (should be MQTT)

# data[].attributes.body
+ They added sluice for opening/closing water gates
+ Useful to add an AppServer
+ Specification in Kbox
- Specification of sensors
- Better organized
- Direction of arrow connection PC is missing

# data[].attributes.body
That they did better:
- More details on the flood gate/sensors
- More accurate artifact name on the server
- They worked quite fast

What we did better:
- We showed the bus architecture
- We connected the phones correctly
- We show multiplicity

# data[].attributes.body
+ They were better at covering the different technologies
+ They had more descriptive names for the deployed artifacts
+ They used more buzzwords

- We did not include unnecessary nodes like SSD and Trusted Platform Module
- We were more specific in the naming of communication protocols
- We followed the UML standards a bit more

# data[].attributes.body
Better
* Added the floodgate
* Added all the different physical connections.
* Computer-made design

Room for improvement
* Lacks a systematic approach to the model layout
* Physical connections are not written in an ideal place
* Has redundant information as artifacts

# data[].attributes.body
Deployment diagram

# data[].attributes.body
Group 3 Deployment Diagram

# data[].attributes.body
10:30 to 11:00 Read
11:00 to 11:30 Develop Diagram in Team
11:30 to 12:00 Evaluate and compare other diagram