OOP (5dv133 VT2022): Project, group 23
André, Berg (prev. Berglund) ens10abd@cs.umu.se
Theodor, Jonsson
ens18trn@cs.umu.se
Carl Oliver Erik, Lagerblad
ens19cld@cs.umu.se
Aron, Renström
ens19arm@cs.umu.se
May 2022
1
Introduction
This assignments main goal is to create a network which is composed of a
number of wireless sensornodes which will hold events. The nodes should be
able to register events that occur in nodes in it’s vicinity, so called neighbours.
The nodes should also be able to keep track of the routes around the network,
they will firstly only know about routes to their respective neighbourhood but
will learn more through so called agent messages. These agent messages will
have a chance to be created after a event has been registered. The agents
will gather and share it’s information to each node it visits. The network will
periodically send out a Query after a specific event that has happened.
2
User guidance
Compilation and demonstration guide, Windows and Linux:
• Download the git repository from https://git.cs.umu.se/ens10abd/
oop_project
• Using CMD (Windows) or the terminal (Linux), navigate to the src folder
in the downloaded repository
• Call javac NetworkSimulation.java
• The files necessary to make it run is included in the repository and called
when the simulation starts
• Call java NetworkSimulation
The test classes have been created and tested Using JUnit5 all required files for
testing is in the git repository and will be called in the test no input from the
user is required. All the user has to do is run the tests.
1
2.1
JavaDoc
JavaDoc can be found at: https://people.cs.umu.se/ens10abd/OOP_Projekt/
JavaDoc/package-summary.html.
3
Design and interpretations
We decided to make a superclass that was Message that Query, Answer and
Agent would inherit from but later on in the process we decided that Answer
was redundant and baked in it’s responsibilities to Query instead. Almost in
the end we also decided to make Message an abstract class to make it easier for
the SensorNode to deal with these not needing to differentiate between a Query
and an Agent. One of the bigger changes was removing Neighbourhood and
Position as their own classes and baking this into SensorNode, this was made
because we noticed that only the SensorNode actually used these classes,
The first UML prototype can be seen in Figure 1, while the actual UML
diagram can be seen in Figure 2. The classes full methods and properties can
be seen in Figures 3 and 4.
2
EventTable
Knows: Where Events happened (Event,SensorNode)
RouteTable
Knows: Best Route between
nodes (Route,SensorNode)
Collaborator: Table (interface)
Collaborator: Event
Collaborator: SensorNode
Collaborator: Table (interface)
Collaborator: Route
Collaborator: SensorNode
Event
Knows: When it happened
Knows: When where happened
(SensorNode)
Knows: ID-number
Collaborator: SensorNode
Network
Knows: All sensor nodes
Can: Progress time
Can: Inform of neighbours
Can: Add nodes
Can: Create event
Collaborator: SensorNode
Collaborator: Event
<<interface>>
Table
Can: Merge tables
Can: Add to table
SensorNode
Knows: Queue of actions
Knows: Neighbourhood
Knows: Table of Events
Knows: Table of Routes
Can: Receive message
Can: Send message
Collaborator:
Collaborator:
Collaborator:
Collaborator:
RouteTable
EventTable
Event
Message
Route
Knows: Path of nodes between
two ends (SensorNode)
Knows: Distance between each
node along path
Can: Give next node towards
destination
Collaborator: SensorNode
Neighbourhood
Knows: Center position
Knows: SensorNodes within
distance (RouteTable)
Collaborator: SensorNode
Collaborator: RouteTable
<<abstract>>
Message
Knows: Travelled path (Route)
Knows: Current location (SensorNode)
Knows: Age (N.o. Moves)
Can: Kill itself
Collaborator: SensorNode
Collaborator: Route
Answer
Knows: Sender (SensorNode)
Knows: Recipient (SensorNode)
Knows: Return path (Route)
Knows: Event info (Event)
Can: Print Event info
Collaborator: Message (super)
Collaborator: Route
Collaborator: Event
Query
Agent
Knows: Sender (SensorNode)
Knows: Recipient (SensorNode)
Knows: Path travelled (Route)
Knows: Event ID of interest
Can: Spawn Answer with Event
Knows: Table of Events (EventTable)
Knows: Table of Routes
(RouteTable)
Can: Sync tables at location
Collaborator: Message (super)
Collaborator: Route
Collaborator: Answer
Collaborator: Message (super)
Collaborator: EventTable
Collaborator: RouteTable
Figure 1: The UML diagram prototype.
3
4
4.1
System description
UML diagram
<<interface>>
Table
EventTable
RouteTable
Network
Event
SensorNode
Route
<<abstract>>
Message
Agent
Query
Figure 2: Compact UML-diagram.
4.2
4.2.1
Classes
Class 1, Network
Networks has several responsibilities. Network consists of Sensornodes and
routes between those Sensornodes, networks first task is to build up it self of
with these things. This is done by the help of a given text file. This text file
describes a grid of coordinates. Networks first responsibility is to read these
coordinates and place them into the X-coordinate and Y-coordinate of all the
Sensornodes and then add a route between Sensornodes. Sensornodes that are
less than or equal to 15 units of length apart from each other is added into a set
of reachable nodes. This means that the Sensornodes that is part of each set
is neighbors and can communicate with each other. Network is also responsible
of advance the time. Each Sensornode has a 0.01 percent chance to create an
event each timestep. If an event would occur in one Sensornode this event will
be added into the individual Sensornode Routetable and the eventTable of all
events. Also the Sensornode has a 50 percent chance to spawn an agent.
4.2.2
Class 2, SensorNode
SensorNode main responsibility is to receive, handle and send Messages in form
of either a Query or an Agent. Handling is different depending on the type of
message but the handling of the messages are handled by the classes themselves
but they use the knowledge of the SensorNode to do this. Sending the Messages
4
Message
-currentNode:SensorNode
-receipientNode:SensorNode
-travelledPath:Route
+hasReachedRecipient():boolean
+getPath(SensorNode,SensorNode):Route
+getRecipientNode():SensorNode
+setRecipientNode(SensorNode)
+handleMessage(SensorNode):boolean
+sendMessage(SensorNode)
SensorNode
-x:int
-y:int
-neighbours:Set<SensorNode>
-eventTable:EventTable
-routeTable:RouteTable
-inbox:int
-outbox:int
+SensorNode()
+SensorNode(int x, int y)
+startAlgorithm()
+getNeighbours():Set<SensorNode>
+hasNeighbour(SensorNode):boolean
+addNeighbour(SensorNode)
+getX:int
+getY:int
+getDistance(SensorNode):double
+mergeTable(Table)
+startRouteTable()
+getRouteTable():RouteTable
+getRouteTableAxis():ArrayList<SensorNode>
+getRouteBetween(SensorNode,SensorNode):Route
+getNumKnownNodes():int
+getEventTable():EventTable
+getEventSensorNode(int):SensorNode
+registerEvent(Event)
+amountInOutbox():int
+amountInInbox():int
+receiveMessage(Message)
+handleMessage()
+sendMessage()
+spawnAgent()
Network
-eventChance:double
-agentSpawnChance:double
-minDist:int
-nodes:Set<SensorNode>
-timeStep:int
-id:int
-masterEventTable:EventTable
+Network(Scanner)
+connectNeighbours()
-createEvent(SensorNode)
+progressTime()
+getTimeStep():int
+getID():int
+getRandomEventID():int
+getNodes():Set<SensorNode>
+increaseID()
+increaseTimeStep()
Table
+mergeTables(Table)
+addToTable(Object)
+cloneTable():Table
Figure 3: Class Descriptions.
is also done in the classes but they same as in handling use the knowledge to
either go towards their destination or go to a random neighbour of the SensorNode. SensorNode is also responsible of knowing it’s position and knowing
it’s own neighbours. The position of the SensorNode is used when the network is formed and it’s checking whether or not it’s close enough to another
SensorNode to be neighbours. Knowings it’s own neighbours is used when it’s
sending messages to other SensorNodes. The responsibility of the and methods
of neighbours and position was first done in their own classes but later on in
the process we decided that these were only used in the SensorNode class and
could be refactored in to the that class removing said classes.
4.2.3
Class 3, Message
Message is abstract class used by Query and Agent this class is used so that the
SensorNode doesn’t need to know if the message it’s processing is a Query or
an Agent
5
EventTable
-IDAxis:ArrayList<Integer>
-eventList:ArrayList<Event>
+EventTable()
+startAlgorithm()
+getNumEvents():int
+getEvent(int):event
-getIDAxis():ArrayList<Integer>
-getEventList():ArrayList<Event>
Route
-currRoute:ArrayList<SN>
+Route(SN,SN)
+addNode(SN)
+getNextNode(SN):SN
+getStart():SN
+getDest():SN
+isStart(SN):boolean
+isDest(SN):boolean
+getLength():int
+getDistFromStart(SN):int
+isInRoute(SN):boolean
+getSubRoute(SN,SN):Route
+cloneRoute():Route
+appendRoute(Route)
+flipRoute()
RouteTable
-tableAxis:ArrayList<SN>
-currTable:Route[ ][ ]
-shorterRoutes:Queue<R>
Event
-time:int
-sn:SensorNode
-id:int
+Event()
+getTime():int
+getSensorNode():SensorNode
+getID():int
Agent
-eventTable:EventTable
-routeTable:RouteTable
-stepsLeft:int
+Agent(EventTable,RouteTable)
+syncTables(SensorNode)
-decreaseLife()
-hasLifeLeft():boolean
+getEventTable():EventTable
+getRouteTable():RouteTable
+RouteTable(SN):boolean
+processQueue()
+getRouteBetween(SN,SN):R
+getTableAxis():ArrayList<SN>
+getNumKnownNodes():int
-shortestRoute(R,R):R
-queueBetterRoutes
(R[ ][ ],ArrayList<SN>)
-insertShortcut(R,R):R
-getCurrTable():R[ ][ ]
-setAxis(ArrayList<SN>)
-setCurrTable(R[ ][ ])
Query
-requestedEventID:int
-requestedEvent:Event
-startingNode:SN
-recipientNode:SN
-knowsRequestedNode:boolean
-hasReachedRecipient:boolean
-goingBack:boolean
-stepsLeft:int
-walkedPath:Route
+Query(SN,int)
+getRequestedEventID():int
-eventToString():String
-checkIfAtRecipient(SN)
-setRecipientNode(SN)
-decreaseLife()
-hasLifeLeft():boolean
Figure 4: Class Description continuation. SN and R are short for SensorNode
and Route respectively.
4.2.4
Class 4, Agent
Agent is a subclass of Message. When an Event happens it has a predetermined
chance to be created. when created it will get the tables of the SensorNode it
was created in. The Agent will then get sent out to random neighbour then
when the Agent gets handled by the SensorNode it will merge the tables of the
SensorNode and the Agent. Then get sent out again by the SensorNode. Doing
this it will gather a bunch of information then spread this to the SensorNodes
it will come across. It will continue to go around spreading information until a
predetermined amount of steps have been reached then it will be terminated.
4.2.5
Class 5, Query
Query is also a subclass of message. After a certain interval in the time of the
network a Query will created in a random SensorNode searching for a random
eventID(in the range of 0 to current amount of created events). Then it will
6
go from SensorNode to SensorNode looking for a SensorNode that knows of the
requested event. If the query finds a SensorNode that knows of the event it will
ask that SensorNode of the direction there and start heading in that direction.
When it finds the SensorNode that was the origin of the requested event it will
gather the information of that event then start going back to it’s own origin.
When it arrives at it’s start it will print out the information about the requested
event.
4.2.6
Class 7, Table
Table is a interface used in EventTable and RouteTable. Here is only three
methods that those using this interface needs to implement which is merging
tables, adding to a table and lastly cloning tables.
4.2.7
Class 6, Event
Event is a smaller class. Its main responsibility is to create an event. When
an Event is created in a Sensornode it is given an individual ID-number and a
timestep. It is Events responsibility to know which Sensornode, ID and timestep
it was created.
4.2.8
Class 7, EventTable
EventTable is a Table containing the Events registered to it. The Network holds
one master-EventTable, registering all events, while each SensorNode will know
of its own Events and those Agents inform them of.
4.2.9
Class 8, Route
A Route is a sequence (with direction) of neighbouring SensorNodes.
4.2.10
Class 9, RouteTable
The RouteTable keeps track of the Route’s an Agent or a SensorNode have
become aware of. It is possible to ask for a Route between two nodes and it
will either return a Route between them, or null. Merging will apply some mild
optimization of the shortest known routes.
Some functionality regarding further optimization is disabled for the moment, due to a memory bug.
The implementation has an emphasis on retaining and making use of information. This comes at the price of speed. For an increase in speed, the
implementation can be changed to a table containing a trio of destination SensorNode, next SensorNode along the path, and the distance to the destination
following this knowledge. This would significantly hamper the distribution of
information though.
7
4.2.11
Class 10, NetworkSimulation
NetworkSimulation holds the main method of this program. We start by loading the network and instantiating all the SensorNodes and placing them with
their neighbours. Then we pick out 4 random SensorNodes to be the ones that
will send out Query’s. After all this it’s time to start the network. Using a
predetermined amount of time steps (in this case 10 000 steps) it will go tell the
network to progress time which will in turn tell the SensorNodes to start their
algorithm. Then after 400 time steps in this case it will tell send out a Query
from one of the 4 SensorNodes that were picked. This will continue until it has
reached the it’s maximum amount of steps.
4.3
Limitations and improvement suggestions
To the detriment of this assignment we didn’t get Query to function properly.
The problems we have are that it never finds the recipient node so it never
goes back to it’s sender. The Query will just wander around until it doesn’t
have any steps left then get. So when coming back to this project first priority
should be find where the issues stem from and fix them. Secondly in Query some
refactorization is needed to make it easier to understand. Some optimizations
of the algorithm is needed to make the program run smoother. We also had
some optimizations in the routing but weren’t able to complete because of time
restraints.
5
Testing
For testing the classes we have use JUnit5.
Testing of the SensorNode and Messages class have been done in the following. Firstly it checks when an agent spawns in a SensorNode it will be placed
in the inbox of the SensorNode. Then it checks if a SensorNode can receive a
Query as intended. Then it checked if the SensorNode can handle an agent and
place it after in it’s outbox. We then checked if two nodes that are neighbours
can send an agent back and forth between each other as intended. Lastly in
the testing of SensorNode and Query we checked if a Query that spawns in a
SensorNode that knows of the location of the requested Event, if it can move
to that SensorNode and collect the data then move back to the starting SensorNode. This last test was the test that failed and we could not fix in time see
Figure 5 for failed test.
We have also tested network in a few ways. Firstly we tried creating a basic
network. Secondly we had a file with a defined number of nodes, this test was to
compare this number to number of nodes in network. Third test was to increase
ID-counter and compare this ID-counter to the expected number. Fourth test
was pretty similar to the previous, but this was about increasing the number of
timesteps, and comparing to the expected number of timesteps. The fifth test
was about create an event in one Sensornode and then added the event to both
8
Figure 5: Image of testing using JUnit5
eventTable and the SensorNode´s routeTable and then comparing the two of
them. Sixth test was, like the previous, about comparing two tables, difference
is this time its two events and the events has an ID-counter and a time-counter.
All tests passed.
Routes and RouteTable have a few different test networks. The test testRoutesAtStart verifies that the RouteTable for each sensornode (and the
routes within) spans only the sensornode and its neighbours. It also checks
all permutations of these routes to ensure that no route is missing. The test
testRouteTableMerge tests whether merging two small RouteTables produces
the expected outcome. More tests were planned for merging, but unfortunately
time did not allow to implement them.
6
Individual contribution
• André, Berg - Total: 46.5h as of 25/05
9
– 45m - Basic Overleaf .tex, shared .git and contacting.
– 45m - CRC 02/05
– 1h - CRC 03/05
– 1h - UML diagram prototype 04/05
– 2h 20m - CRC 04/05
– 1h 35m - Pseudo-UML diagram 05/05
– 1h - CRC + Presentation 05/05
– 15m - Pseudo-UML diagram 05/05
– 40m - Arguing with Git
– 2h 45m - Poked at Table, Position, and Route 09:25 to 12:10 06/05
– 4h - Poking around at Route and RouteTable 10/05
– 1h 40m - Meeting with everyone, cooperating development
– 3h - Working on merging tables 11/05
– 2h 45m - Working on merging tables 11/05
– 2h 30m - Finished routeTable 12/05.
– 3h 20m - Minor changes to several pieces. Basic testing enabled. 5
common sense tests. 19/05
– 2h - Double checking RouteTable methods 19/05
– 3h 10m - Working together 23/05
– 1h - Finished EventTable. Added clone method to Route, Table,
EventTable, RouteTable 24/05.
– 1.5h - Refactorization. Fixing some potentially dangerous reference
passes 24/05.
– 2.5h - A network simulation. Also start at fixing query 24/05.
– 4h - UML diagram. JavaDoc + hosting 25/08.
– 4h - Bug-fixing RouteTable. Writing report. 25/08
• Theodor Jonsson - Total: 24,3h as of 05/25
– 1h 25min - CRC 03/05
– 1h - CRC + Presentation 05/05
– 1h - Poked at sensor node 05/06
– 1h 30min - Added methods to sensornode and neighbourhood 05/09
– 2h - Continued on sensornode and neighbourhood 05/10
– 1h - Continued on sensornode and worked on agent abit 05/16
– 2h - Worked on query and neighbourhood 05/19
– 1h - Worked abit on Query and agent 05/20
10
– 2h - Added tests to sensorNode and finished sensorNode 05/23
– 13:00-16:00 - Added more tests to sensorNode and fixed handling
message, wrote on testing of sensornode 05/24
– 18:00-19:30 Trying to fix handling of query and sending it out, wrote
abit more on testing and classes
– 21:00-00:00 Continued same as above
– 11:00-16:50 Still trying to fix Query and writing on report
• Aron, Renström - Total: 19h as of 25/05
– 1h CRC
– 85 min
– 1h - CRC + Presentation 05/05
– 1h, GIT and poked at network 9/5
– 2h, network 10/5
– 2h 15min, network and event 12/5
– 1h, worked on network 19/5
– 2h 40 min, network network test 23/05
– 2h 45min, worked on network and tests 24/5
– 4h, test and raport 25/5
• Carl Oliver Erik, Lagerblad
– 1h CRC 02/05
– 1h 20m CRC 03/05
– 1h 20m CRC 04/05
– 30m Rollspelslista 04/05
– 1h - CRC + Presentation 05/05
– 15m - Setting up GIT 09/05
– 2h - Worked on Message 09/05
– 1h - Setting up GIT 10/05
– 2h - Worked on classes Message and Agent 11/05
– 2h - Worked on EventTable 22/05
– 1h - Worked on EventTable 23/05
– 1h - Started writing on Introduction 24/05
7
References
Git repository can be found at: https://git.cs.umu.se/ens10abd/oop_project.
JavaDoc can be found at: https://people.cs.umu.se/ens10abd/OOP_Projekt/
JavaDoc/package-summary.html.
11