Communication Networks in Distributed Systems

AdvisorsProf Shlomi Dolev

Dr Guy Leshem

Team MembersRaviv AraniaNoam 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 UC2Add/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 ModelSince 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 TestingThis 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 ArchitectureSensor – 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.

TestingRecently 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