Advisors Prof Shlomi Dolev Dr Guy Leshem Team Members Raviv Arania Noam Arad

Use cases

Use Case UC1 Run algorithm – Build Hierarchy Primary Actor: User Stakeholders and Interests: User that wants to run algorithm and build the network hierarchy. Preconditions: None (since the algorithm is self stabilizing). Post Conditions: The hierarchy will be stabilized after O(logn) rounds given that there are no topology changes in the time of the building. n – bound on number of sensonrs. Main Success Scenario: The user chooses to run the algorithm. The system then starts to run the algorithm on all sensors that are participating. After O(logn) rounds the hierarchy is built and stabilized. Extensions (Alternatives): 3a) A topology change happens during the algorithm run. The algorithm will stabilize in at most O(logn) rounds from the last topology change.

Use Case UC2 Add/Revive Sensor Primary Actor: User Stakeholders and Interests: User that wants to add a sensor to the topology. Preconditions: The sensor id that is given exists. Post Conditions: The hierarchy will be stabilized after O(logn) rounds given that there are no topology changes in the time of the building. n – bound on number of sensonrs. Main Success Scenario: The user chooses to add a sensor. (activate a non active sensor). The system activates the specified sensor. After O(logn) rounds the hierarchy is stabilized. Extensions (Alternatives): 3a) A topology change happens during the algorithm run. The algorithm will stabilize in at most O(logn) rounds from the last topology change.

Data Model Since we are implementing a distributed algorithm our data model is very simple and consists of one simple class (No databases and no data object relations).

Behavioral Analysis

Object-Oriented Analysis

Unit Testing This is not so much applicable since we have 2 classes to implement, most of work will focus on implementing one algorithm that cannot be tested as a single class because it is a distributed algorithm.

System Architecture Sensor – each sensor has an exact copy of the full program code. UI – This system part sits on a PC and controls, through the gateway computer in Lubek, the sensors. In addition to our system we are using the WISELIB library that was developed in the FRONTS organization and its general architecture is relevant to understanding the implementation of our project.

System Architecture cont’d

User Interface Draft Our UI is textual and will have the following operations: Start_simulation – the command will run the simulation on all sensors. Kill_sensor idnum – orders the sensor with id [idnum] to stop working. Revive_sensor idnum – orders the sensor with [idnum] to start working. Snapshot – gets and prints the information of the sensory input received from the snapshot algorithm.

Testing Recently a new demand from the FRONTS organization has been made to collaborate the system testing with parallel projects in the organization. Due to this demand we are now in the process of designing system tests with the Spanish team. ADD Document will be updated when relevant.

Task List

THE END