Second Life on a Mobile Phone Nii Annan September 2011 Dissertation submitted in partial fulfilment for the degree of Master of Science in Information Technology Department of Computing Science and Mathematics University of Stirling
Early Stages of Development Requirement Phase
Download 191.8 Kb.
|
- Navigate this page:
- Use Case Diagrams for the System
- Use Case for Component 1: Login and Avatar Details
- Use Case for Component 2: Communication Support
- Class Diagrams for the System
- Class Diagram for Component 1
- Class Diagram for Component 2: Communication Support
3Early Stages of DevelopmentRequirement PhaseThe project required devising a means to enable users view avatars in-world on the InterLife Island by using a mobile device. This was to be done by developing an application on a mobile device running Windows Phone. The application would have a sign in page for authenticating the user before any other functionality could be accessed. A map page was needed within the app for displaying the Inter-life map. On this map, the exact location of the avatars in-world would be plotted. To top that all up, a twitter client would be needed for sending messages to avatars in-world. An important part of the requirement phase was the ability to have a strong command over programming in C#. With the general concept in mind further analysis could be made. These analyses included, developing use case and class diagrams. These diagrams made it possible in identifying the necessary components needed to be assembled to make the application fully functional. Use case and class diagrams offer a high-level understanding of the various functions of the application. The components for the system were split into 2 major parts:
Use Case Diagrams for the SystemUse case diagrams describe the functionality of a system and users of the system. The diagrams contain the following elements:
Use Case for Component 1: Login and Avatar DetailsIllustrated in figure 5 is a high-level use case diagram for the project. It involves interactions between the user, the app, InterLife and Second Life servers. The user interacts with the InterLife app to login. The InterLife app communicates with the InterLife server by sending logged in details to verify the user’s credentials. After successful verification, the map page is accessible to the user who then proceeds to interact with the map page to view avatars in-world. Before avatars on the map are revealed, the InterLife app contacts the InterLife server again, this time requesting the details of avatars in-world. The InterLife server in-turn puts in a request to the Second Life server to retrieve the number of avatars in-world, their names and location coordinates. This information is sent back and finally reaches the application. 
High-Level Use Case Diagram for Component 1 Use Case for Component 2: Communication SupportThe user might also want to send an avatar a message. The InterLife server uses a fixed Twitter account (@interlife.user2) which is used to receive Twitter messages from the built-in Twitter client for the InterLife app. The server checks for Twitter messages from this account and relays any messages to the Second Life server which will then convert these messages to in-world messages. The use case diagram in figure 6 breaks down the possible scenario for sending messages. Before any messages can be sent from the in-built twitter client, the user needs to authorize the app to use their twitter credentials. After the authorization process is completed, secure messages can be sent from the application. There is an in-depth coverage of this process in section 4.2.7.6. 
High-Level Use Case Diagram for Component 2 Class Diagrams for the SystemClass diagrams describe the static structure of a system, or how it is structured rather than how it behaves. These diagrams contain the following elements:
Having generated the use cases for the project, further drilling could be done in determining the key classes needed. The next sub-sections cover the classes developed for components 1 and 2. Class Diagram for Component 1The classes for component 1 of the Inter-life app included the following:
Figure 7 illustrates a high- level class diagram showing the associations between these main classes. The StartupControl is associated with the SignInPage class on a 1 to 1 basis. The SignInPage contains only 1 instance of the StartupControl class at runtime. The StartupControl class is needed for controlling the behaviour of the application when it is first activated which involves the popping up of a splash screen. The SignInPage class handles the details logged in by the user. It has a 1 to 0...1 association with the SocketClient class. Meaning, it either has no instance or 1 instance of the socket client when the user attempts the log in procedure. The SocketClient class handles the TCP socket connection established between the InterLife app and InterLife server for data transfer. The LoadingControl class is responsible for the behaviour of the application after the login procedure is complete. It handles a similar popup to that of the StartupControl class. It has a 1 to 1 relationship with the MapPage class which contains an instance of the LoadingControl class. Similar to the SignInPage class, the MapPage class either has no instance of the SocketClient or 1 instance of it when the command is given to retrieve avatar details. Therefore their association is a 1 to 0…1 relationship in this case. AvatarStuff class handles the storage of avatar information. The MapPage class has a 1 to 0…* relationship with it because it either has no instance of AvatarStuff or multiple instances. Evaluating the nature of this architecture, clearly the StartupControl and LoadingControl classes do not play any major role in the core functionality of the app. The splash screens they generate were only introduced to enhance the ‘beauty’ of the app. Nonetheless they still contribute in making the app look more realistic. A more serious look at the SignInPage, SocketClient, MapPage and AvatarStuff classes is covered in section 4.2.
Class Diagram for Component 1 Class Diagram for Component 2: Communication SupportThe structure of the communication support system rather looks complex. This is shown in figure 8. This component has a total of 9 classes but only 7 are shown here, the other 2, the AuthConstants and UrlConstants classes hold static constant variables and these values do not change. The OAuthClient class serves as the main gateway for external connectivity with the Twitter API. It contains methods for sending and receiving http web requests and responses. It has a 1 to 1 relationship with the IsoStoreHelper, UserTwitterStuff, TweetPage and BannedParams classes. The AuthPage class has a 1 to 1 relationship with the OAuthClient, StringHelper and UserTwitterStuff classes. A look at the most important classes within this component is covered in section 4.2.7 
High-level Class diagram for Communication Support System of the app The IsoStoreHelper class stores the users twitter credential into memory and it is the most important link between Component 1 and Component 2. This is shown in the final assembly of the classes as seen in figure 9 on the next page. It is linked to the MapPage class. The important point to note about the class design of the system is that, even though the general layout of the class seems frightening, majority of the classes generated from the project could have been embedded in other classes. Some of these classes held only variables. The reason for separating them out was to avoid code clutter, as well as making them publicly available to other classes. 
General Assembly of Classes Directory: courses courses -> Algorithms for Register Allocation Andrew Pardoe courses -> Ieor 4600 Mixed-Integer Rounding Inequalities courses -> San José State University Social Science/Psychology Psych 175, Management Psychology, Section 1, Spring 2014 courses -> Kennan's Telegram (Excerpt) courses -> The university of british columbia courses -> A hurricane track density function and empirical orthogonal function approach to predicting seasonal hurricane activity in the Atlantic Basin Elinor Keith April 17, 2007 Abstract courses -> Cover page need figure & title by Proposed Table of Contents courses -> Objectives courses -> Dr. Jeff Masters' WunderBlog Download 191.8 Kb. Share with your friends:
|
