2. Analysis
2.2. Further analysis
2.2.3. Defining the various uses of the system
Taking a good look at the requirements, we can find that most use cases are similar, but not exactly the same. The fact that most use cases are similar means we can quickly design and implement the system, as the same design philosophy that is used for one use case can be used for the others. In this case, there are two groups of use cases.
Figure 2.17. Use case diagram group 2
2.2.3.1. HotspotVisitor use cases
The tables below describe the CreateNewAccount use case, the Login use case and the UseSystem use case in detail. The CreateNewAccount use case describes how one retrieves an activation code and uses this code to create a new account. The Login use case describes how one logs in into the system to be able to use the system. The UseSystem use case, finally, describes how one uses the system. For CreateNewAccount a translation into a sequence diagram is provided too.
Use case name CreateNewAccount
Participating actor(s)
Initiated by HotspotVisitor
Entry condition
1. The HotspotVisitor starts his laptop and runs his favorite web browser, trying to vis- it a website.
Flow of events
2. The AP contacts the AAA server on the central Mobidot system to find out whether the user has logged in successfully. 3. The AAA server returns a false value and
the AP redirects the HotspotVisitor to the central Mobidot system login website. 4. The HotspotVisitor activates the "Create a
new HotspotVisitor account" function of the central Mobidot system login website. 5. The HotspotVisitor is asked to use a phone/
activation code.
6. [The HotspotVisitor uses the external pay- ment system, which generates and stores an activation code and announces this code to the HotspotVisitor. The activation code (including some extra information, such as the amount that was paid for) is stored in the Mobidot database by the external pay- ment system.]
7. The HotspotVisitor enters personal inform- ation (name, postal address and email ad- dress), a new user name and password, and the activation code into the input form on the "create new account" web page and hits the "Create Account" button.
8. The central Mobidot system checks in the Mobidot database whether this user name is available.
9. The central Mobidot system receives the re- quest, checks whether the activation code is correct by contacting the Mobidot database. When it is, the central Mobidot system re- trieves some additional information from the same table in the Mobidot database (i.e. the amount that was paid for).
Exit condition
10. The HotspotVisitor's account is created in the Mobidot database. The HotspotVisitor receives a message confirming the success- ful creation of the account.
Table 2.2. Use case CreateNewAccount
Figure 2.19. Sequence diagram for use case: CreateNewAccount (part 2)
Use case name Login
Participating actor(s)
Initiated by HotspotVisitor
Entry condition
1. The HotspotVisitor starts his laptop and runs his web browser, in order to visit the central Mobidot system login website.
Flow of events
2. The HotspotVisitor enters his login creden- tials in the input form that is presented, and hits the Login button.
3. The AP intercepts the request, interprets the query and queries the AAA server on the central Mobidot system with the provided information.
4. The central Mobidot system AAA server checks whether the login credentials are correct, and if so returns a success message to the AP, else it sends a failure message. It records several details about the login (login status, login time) in the Mobidot database.
5. The AP forwards the response detailing success or failure to the HotspotVisitor. The AP adjusts its firewall tables such that net- work traffic from the HotspotVisitor is al- lowed.
Exit condition
6. The HotspotVisitor receives either a failure or success message. In case of a success message, the HotspotVisitor is then authen- ticated and can then initiate the UseSystem and Logout use cases.
Table 2.3. Use case Login
Use case name UseSystem
Participating actor(s)
Initiated by HotspotVisitor
Entry condition
1. The HotspotVisitor was successfully au- thenticated as described in the Login use case and starts his web browser to visit a website.
Flow of events
2. The HotspotVisitor's laptop sends the web- site request to the nearest AP.
3. The AP checks whether this user is authen- ticated (by checking with the AAA server in the central Mobidot system), if so, it allows the query to pass.
4. The central Mobidot system forwards the website request to the intended server and the central Mobidot system returns its re- sponse to the AP.
5. The AP forwards the response to the Hot- spotVisitor's laptop.
Exit condition
6. The HotspotVisitor receives the website that was requested. The use case keeps re- peating from step 2, unless the HotspotVis- itor logs out from the system.
Table 2.4. Use case UseSystem
2.2.3.2. MobidotNetworkManager use cases
In this section we will look at various management use cases. These use cases basically describe how one manages a certain type of information. Management of information (in this system) in- volves four basic actions: add, view, edit and delete. Each of these actions are described in the tables below, followed by a translation into sequence diagrams. We will discuss the add action of the Man- ageFirmware use case, the view action of the ManageHotspotsAndAPs use case, the edit action of the ManageConfigurations use case and the delete action of the ManageAccounts use case. Further-
more, we will look at the use case descriptions of the use cases PutHotspotDownForMaintenance and SendNetworkAnnouncement.
Use case name ManageFirmware (add)
Participating actor(s)
Initiated by MobidotNetworkManager
Entry condition
1. The MobidotNetworkManager activates the "Firmware Management" function of the central Mobidot system management web- site.
Flow of events
2. The central Mobidot system queries the file system and shows a list of all previously uploaded firmware images to the Mobidot- NetworkManager.
3. The MobidotNetworkManager clicks the Add button and browses to and selects the firmware on his PC he wants to upload. He hits the Submit button.
4. The central Mobidot system then stores the firmware image in a previously configured location in the file system of the central Mobidot system.
Exit condition
5. The firmware image is added to the file sys- tem of the central Mobidot system. APs will notice the new firmware within the next hour and update themselves.
Table 2.5. Use case ManageFirmware (add)
Figure 2.21. Sequence diagram for use case: ManageFirmware (add, part 2)
Use case name ManageHotspotsAndAPs (view)
Participating actor(s)
Initiated by MobidotNetworkManager
Entry condition
1. The MobidotNetworkManager activates the "Manage Hotspots" function of the central Mobidot system.
Flow of events
2. The central Mobidot system queries the Mobidot database and shows a list with all hotspots to the MobidotNetworkManager. 3. The MobidotNetworkManager clicks on a
hotspot he wants to view.
4. The central Mobidot system then fetches all related hotspot information of the selected hotspot from the Mobidot database and shows it to the MobidotNetworkManager.
Exit condition
5. The MobidotNetworkManager gets an over- view of all information related to the selec- ted Hotspot, including the collection of APs which are located at that hotspot.
Figure 2.22. Sequence diagram for use case: ManageHotspotsAndAPs (view)
Figure 2.23. Sequence diagram for use case: ManageHotspotsAndAPs (view,
part 2)
Use case name ManageConfigurations (edit)
Participating actor(s)
Initiated by MobidotNetworkManager
Entry condition
1. The MobidotNetworkManager activates the "Manage Configurations" function of the central Mobidot system.
Flow of events
2. The central Mobidot system queries the Mobidot database and shows a list with all configurations to the MobidotNetworkMan- ager.
3. The MobidotNetworkManager selects some configurations he wants to edit, he then hits the Edit button.
4. The MobidotNetworkManager changes the preferred firewall and traffic shaping con- figurations of the selected hotspot configur- ation and hits the Save button.
Exit condition
5. The hotspot configuration is updated with the new information.
Table 2.7. Use case ManageConfigurations (edit)
Figure 2.24. Sequence diagram for use case: ManageConfigurations (edit)
Figure 2.25. Sequence diagram for use case: ManageConfigurations (edit, part
2)
Use case name ManageAccounts (delete)
Participating actor(s)
Initiated by MobidotNetworkManager
Entry condition
"Account Management" function of the central Mobidot system management web- site.
Flow of events
2. The central Mobidot system queries the Mobidot database and shows a list with all users to the MobidotNetworkManager. 3. The MobidotNetworkManager selects some
users to delete and hits the Delete button. 4. The central Mobidot system asks the Mo-
bidotNetworkManager whether he is sure, the MobidotNetworkManager hits the Yes button.
5. The central Mobidot system then instructs the Mobidot database to delete the selected accounts.
Exit condition
6. The selected accounts are deleted from the Mobidot database.
Table 2.8. Use case ManageAccounts (delete)
Figure 2.27. Sequence diagram for use case: ManageAccounts (delete, part 2)
Use case name PutHotspotDownForMaintenance
Participating actor(s)
Initiated by MobidotNetworkManager
Entry condition
1. The MobidotNetworkManager uploads a new firmware according to the Manage- Firmware (add) use case.
Flow of events
2. The AP checks in with the central Mobidot system once every hour in order to check for updated packages and new firmware. It finds a new version of the firmware. 3. The AP puts itself in offline mode in order
to prepare for the firmware upgrade.
Exit condition
4. All APs are put offline for maintenance.
Table 2.9. Use case PutHotspotDownForMaintenance
Use case name SendNetworkAnnouncement
Participating actor(s)
Initiated by MobidotNetworkManager Communicates to/with HotspotVisitor
Entry condition
1. The MobidotNetworkManager uploads a new firmware according to the Manage- Firmware (add) use case.
Flow of events
2. The central Mobidot system stores a general message concerning downtime of the sys- tem in the Mobidot database, for each user separately.
3. The browser on the laptop of the Hot- spotVisitor regularly polls the AP for new info. In this case it will find a NetworkAn- nouncement is available, at which point it will download and delete the message and show it to the HotspotVisitor.
Exit condition
4. The network announcement is broadcast to all HotspotVisitors.
Table 2.10. Use case SendNetworkAnnouncement
2.2.3.3. HotspotLocationManager use cases
The table below describes the SetupAP use case in detail. It describes the actions the HotspotLoca- tionManager performs in order to get his Mobidot hotspot working.
Use case name SetupAP
Participating actor(s)
Initiated by HotspotLocationManager
Entry condition
1. The HotspotLocationManager has invested in AP hardware from Mobidot.
Flow of events
2. The HotspotLocationManager receives the AP hardware and places it in a strategic loc- ation.
3. The HotspotLocationManager intends to connect the AP to the Internet. He turns on the AP, which immediately starts installing itself.
4. The AP checks whether it can get an IP ad- dress by DHCP (automatic configuration). 5. The previous step failed and the AP brings an Internet connection configuration web-
site online.
6. The HotspotLocationManager connects his laptop to the Mobidot AP and starts his web browser to visit this configuration website. 7. The HotspotLocationManager enters his
user credentials, which he received from his ISP, which are needed to get an Internet connection.
8. The HotspotLocationManager presses the Save button to store the user credentials. 9. The AP then checks, using the new inform-
ation, whether it can get an Internet connec- tion.
10. The AP can successfully connect to the In- ternet. It connects to the central Mobidot system in order to download an installation/ configuration script.
11. The AP runs this script, which then starts installing several needed packages. After the installation phase has finished, the AP starts configuring itself according to set- tings which are stored in the central Mo- bidot system.
Exit condition
12. The AP is setup and ready for servicing Wi- Fi users.
Table 2.11. Use case SetupAP
2.2.3.4. RoamingPartner use cases
The table below describes the RetrieveUsageStatistics use case in detail. It describes how a roaming partner retrieves the usage statistics of its users, who have roamed onto the networks of other Wi-Fi providers.
Use case name RetrieveUsageStatistics
Participating actor(s)
Entry condition
1. The RoamingPartner activates the "Retrieve Usage Statistics" function of the central Mobidot system.
Flow of events
2. The central Mobidot system queries the Mobidot database for usage statistics for all users which belong to the RoamingPartner.
Exit condition
3. The central Mobidot system returns the us- age information to the RoamingPartner.