Download
1 / 15
150 likes | 280 Vues
Communication Networks in Distributed Systems. 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
E N D
Advisors Prof Shlomi Dolev Dr Guy Leshem Team MembersRaviv Arania Noam Arad
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).
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.
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_sensoridnum – orders the sensor with id [idnum] to stop working. • Revive_sensoridnum – 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.
