Project Book Table of Content Requirements




Дата канвертавання20.04.2016
Памер71.25 Kb.

TrackMe



Project Book

Table of Content



Requirements

Product constraints 5

Purpose of the product 5

Target audience 6

Requirements & limitations 6

Software requirements 6

Implementation environment 6

Additional information 6

Functional Requirements 7

Non Functional Requirements 8

Look and feel Requirements 8

Usability requirements 8

Ease of use 8

Language 8

Modularity 8

Performance requirements 9

Operational requirements 9

Partner applications 9

Productization requirements 9

Project Issues 10

Development phases 10

Costs 10

Documentation 10

Waiting Room 11

Create a building's map 12

View all maps of your friends 14

View a friend’s location 15

View friends' distance 16

High Level View 20

Semi-High Level View 21

Track Me Plug in Classes overview 22

Model 22

View 22


Controller 22

Track Me Plug in Static Diagram 24

24

TrackMe Map Editor Classes Overview 25



TrackMe Map Editor Classes Static Diagram 26

Sequence Diagrams 27

Google Desktop API Overview 30

Introduction 30

Registering Google Gadget Components 30

Displaying and Interacting with Google Gadgets 30

Details View 31

Notifier 32

Google Talk API Overview 33

Introduction 33

Finding Friends and Sending Data 33

Friend Objects 34

Receiving Data 35

Definitions



  • TrackMe – our project

  • AP – Access point

  • GD- Google Desktop application

  • GT – Google Talk application

  • Location - a logically location which is based on the used map (e.g. room313, printer2).

  • Friends – online friends from GT's friends list which are using WLAN.

  • LBC- location based content.

Requirements

Product constraints

Purpose of the product


Location based applications allow different users to share details regarding their present location, E.g. room #313, printer1 etc. These applications enable users to increase office productivity, and allow sending different content, depending on one's location.

Google’s latest development – Google Desktop, has revolutionized the way people use their desktops, allowing for many useful small applications (called gadgets) to reside in the same convenient and compact side bar. Sadly, no location based gadget for the Google Desktop is available these days.

The TrackMe application will combine the better of the two worlds: Riding on the new popularity of the Google Desktop and gadgets, TrackMe will be developed, and shared by the millions (and counting) users of Google Desktop gadgets.

The TrackMe system will be completely generic, enabling users to create and share their building's map, viewing and sharing their friends' locations, and send location based content to different users. This location based content (LBC) can be sent in real-time, and can be attached to a location until removed.




Target audience


  • Users of Google Desktop with desktops\laptops who are connected through WLAN.

Requirements & limitations

Software requirements


  • Google desktop must be installed on the computer, hence the supported O.S. are Windows XP, Windows 2000, and Windows NT.

  • Google talk must be installed on the computer.

Implementation environment


  • The gadget(s) will be implemented using C# on .NET.

Additional information


  • Some code for triangulation calculation may be taken from previous projects.

  • Hopefully, Google will release a GD for pocket pc's and other hand held devices. Then, with minor modification, this system will work on PDA's as well.


Functional Requirements




  1. The system will enable users to create building's floor maps to be used by TrackMe location based features.

  2. The system will enable users to share their maps among their friends.

  3. The system will allow users to change the current map that is used by the application.

  4. The system will display the user's list of friends.

  5. The system will display the user's friends location at real-time.

  6. The system will display the user's friend’s distance from him.

  7. The system will enable sending users non-prolonging LBC's.

  8. The system will enable adding prolonging LBC's to a specific location.

  9. The system will enable removing prolonging LBC's from a specific location.

  10. The system will enable users to view all the prolonging LBC's they defined.


Non Functional Requirements



Look and feel Requirements


  • The application will be created as a gadget for the GD.

  • The application will follow gadget creation conventions, as defined by Google.

  • The application will preserve the look & feel attributes of other gadgets and the Google side-bar itself.

  • Users will have the option to dock the gadget into the GD side-bar, or undock it, and use it independently.

  • Users will have the option to minimize the application into the taskbar tray.


Usability requirements

Ease of use


  • The system will be easy to used and friendly to all spectrums of ages. The system will follow GD development guidelines.

Language


  • The product will have an English interface.

Modularity


  • The system will allow loading additional modules dynamically and by that extend the system's capabilities.


Performance requirements


  • The system will be robust enough in order to accommodate hundreds of multiple users.

Operational requirements

Partner applications


  • Google Desktop

  • Google talk.


Productization requirements


  • Create an installer package for the gadgets. In addition we plan to contact Google and negotiate with them the uploading of our gadget to their online gadget store. This will enable users all around the world installing and using our TrackMe system.


Project Issues



Development phases


  • Requirements definition.

  • Environmental experiencing.

  • Design.

  • Implementation.

  • Finalization and presentation.

Costs


  • Every week we will invest a working day on the project. At an hourly fee of 57 NIS we're talking about: 14*10*57 *2 = 15,960 NIS.

Documentation


  • Our website will contain all the documents and other project related material.

  • General documentation will include:

  • Requirements definition (this document).

  • Use case definition.

  • Design (may be more than one document).

  • User manual for the final product.

  • Our final presentation.

Waiting Room


  • Desktop locations – when creating the TrackMe map using the map creator, users will have the option to define the known location of static desktop computers. With this data, the desktop user will be able to enjoy the same functionality of the laptop user.

  • Automatic file sharing – using Google talk to transfer data.

Use Cases

Create a building's map


Pre-conditions

  • The build map module must be installed on the client's computer.

Description

  • The client will be able to build maps describing a building's floor schematics.

  • First, the user will define the dimensions of the floor (width & length) and the name of the map.

  • A floor wrapper will be created for the user.

  • The user will then have the possibility to draw straight lines which can describe walls, and general building schematics.

  • The user will have the option to place on the map "logic locations". Each "logic location" is described by an ID and an area of influence (an area on the map that is attached to the logical location, when a client enters this area of influence, he is considered to be adjacent to the logical location).

  • The user will have to add at least 3 access points with their real unique ID's.

  • The user will be able to save the created map, and edit existing maps.



Post-conditions

  • A map file will be created or updated (in case of an existing file). This map will be used by all the TrackMe location based applications.

Exceptions

  • It is the user's responsibility to make sure no areas of influence overlap.

  • In case of a client entering on conflicted area of influence, the application will display one of the logical locations.

Choose a map from maps' list.

Pre-conditions

  • A map file should exist in the list of maps.

Description

  • The client will be able to choose the map from the list of maps which exist in the TrackMe maps folder.

Post-conditions

  • The map that was chosen will be used by the TrackMe application.

Exceptions

  • In case TrackMe will identify 2 AP's or less, an error will be displayed.


View all maps of your friends


Post-conditions

  • The client is logged in to Google Talk

Description

  • The client will receive a list of all map files that of all of his friends.

Post-condition

  • The user will receive a list of all map files found. By clicking on a listed map – the map will be automatically downloaded to his computer.

Exceptions

  • The client has no friends – No list will appear.

  • No maps were found – No list will appear.

Download map files from friends

Post-conditions

  • The client is logged in to Google Talk

Description

  • The client will have the option to download and share TrackMe map files. By selecting a map from the map files that were found – the map will be automatically be downloaded to the client's TrackMe map folder.

Exceptions

  • The client's computer does not have enough free space – An error message will appear and no map will be downloaded.

  • During the file transfer, the source friend becomes offline – An error message will appear.


View a friend’s location


Pre-conditions

  • The client is logged in to Google Talk

Description

  • The client will be able to see the location of his friends.

Exceptions

  • In case of a friend that is not connected via WLAN, the application will mark him as "static".


View friends' distance


Pre-conditions

  • The client is logged in to Google Talk

Description

  • The client will be able to see the distance of his friends.

Exceptions

  • In case of a friend that is not connected via WLAN, the application will show distance as unknown.

Send location based non prolonging IM

Pre-conditions

Description

  • The client will be able to send a message to all of his friends which are in a specific location at the moment.

Post-conditions

  • All friends that are at the location will receive the sent message.

Exceptions

  • In case none of the friends are at the desired location no message will be sent.

Add a prolonging IM

Pre-conditions

  • The client is logged into Google Talk

  • There is at least one location defined in the system.

Description

  • The client will be able to add a message to a specific location.

Post-conditions

  • Every time one of his friends will enter that location, he will get the message.

Remove a prolonging IM

Pre-conditions

  • The client is logged into Google Talk

  • There is at least one location defined in the system.

  • There is a prolonging IM previously added by the client.

Description

  • The client will be able to remove the message he previously added.

Post-conditions

  • The message will not be sent ever again.

View previously added prolonging IM.

Pre-conditions

  • The client is logged into Google Talk

  • There is at least one location defined in the system.

Description

  • The client will be able to view all the added prolonging IM added by him.

Post-conditions

  • A list of the prolonging IM (and the attached locations) added by the client will be displayed to him.

Exception

Design

High Level View


As described, the TrackMe applications (except the Map Editor – will be discussed later on) sit on top of the GD and communicate with it via its API. Now, In order to transfer any kind of data (E.g. messages, maps, locations, etc) between users the TrackMe applications use the Google talk and communicate with it via its API.


Semi-High Level View


The Track Me project uses the Model-View-Controller design pattern as described at the figure bellow:



Track Me Plug in Classes overview


It can be easily seen that the classes are divided into three according the Model-View-Controller design pattern.

Model


  • UserContext – Will contain all the information on the client. (logic location, x.y location, chosen map, etc)

  • FriendsContext – Will contain all the information on the client’s friends ( Logic location, x-y location, status, etc)

  • MessageContext- Will contain all the information on prolonging messages that have been sent.

View


  • TrackMePlugIn – will display all the relevant information as described in the functional requirements section.

Controller


  • WirelessProcessor – will use the OpenNETCF’s frameworks and will be in charge of acquiring the location of the client by using triangulation algorithms.

  • MapHandler – will control all map features as described in the functional requirements section.

  • FriendInformationHandler – will handle changes in friends’ information.

  • LBCHandler – will be sending Location Based Content to other clients.

  • NonProlongingLBCHandler – will be sending Non Prolonging LBC messages

  • ProlongingLBCHandler – will be responsible of adding, removing and viewing Prolonging LBC messages.



Track Me Plug in Static Diagram




TrackMe Map Editor Classes Overview


The TrackMe Map Editor is a utility which enables users to create and edit maps of their buildings and floors. Among its features: create rooms, place routers, define logical locations, add labels and text for descriptive purposes and more!

DrawingSurface – This is the main windows form behind the application.

Shape – The shape class is the basis for all objects that can be placed on the map. Other objects inherit from it. This is an abstract class, meaning you cannot create in instance of it, but must inherit from it.

ShapeCollection – This is a container for multiple shapes. We use it to invoke methods that should operate on many shapes. This also enables us to store all the shapes in one collection with iteration options, etc.

LabelShape – Inherits from the shape class. This class allows the user to add text labels for his design for explanation purposes.

RectangleShape - Inherits from the shape class. This class allows the user to add rooms for his map. The rooms are resizable, color changeable, etc.

LogicLocationShape - Inherits from the shape class. This class allows the user to define multiple logical locations on the map. These logical locations enable the user to define confined spaces such as rooms, as well as logical locations such as printers, elevators, etc. The logical locations each have a customizable area of influence, are resizable, and color changeable.

RouterShape - Inherits from the shape class. This class allows the user to define the access point’s locations on the map.


TrackMe Map Editor Classes Static Diagram




Sequence Diagrams


Here are our 4 main scenarios described as sequence diagrams:







Google Desktop API Overview

Introduction


Google Desktop can host gadgets that provide useful visual information to the user. GD can display content from these gadgets in the Google Desktop Sidebar and the Notifier window.

Registering Google Gadget Components


A GD (Google Desktop) gadget must register itself in the GD. Google Desktop does not accept unregistered components. Google Gadget component registration is a one-time process done using the IGoogleDesktopRegistrar interface, and should be done during gadget installation. As part of the registration process, the gadget must provide its GUID as well as information about itself that will be added to the GD preferences UI.As part of its own uninstallation process, a gadget should unregister itself with Google Desktop.

We will not review the registration interface in great detail.


Displaying and Interacting with Google Gadgets


The Google Gadgets API defines the following interfaces:

  1. IGoogleDesktopDisplaySite: This is the interface exposed by GD most useful to its Google Gadgets.

  2. IGoogleDesktopDisplayPlugin: All Google Gadgets aware of GD must implement this interface.

  3. IGoogleDesktopDisplayPluginHelper: A helper interface. This interface implements a complete Google Gadget and can display and manage data given by the gadget. Google Gadget developers are recommended to use this component (through COM aggregation) to maintain a standard look and feel to the Sidebar.

  4. IGoogleDesktopDisplayContentItem: Google Gadgets create objects implementing this interface and pass them the Google Gadget Helper functions to display and manage their content.

  5. IGoogleDesktopDisplayContentItemHandler: Google Gadgets which aggregate and use the above helper object implement this to receive callbacks about user interaction with the displayed content.

  6. IGoogleDesktopDisplayDetailsViewHelper: A Display component that can be instantiated and used by gadgets to show more details about a particular content item.

  7. IGoogleDesktopDisplayDetailsViewHandler: Google Gadgets using the above helper object implement this interface to receive callbacks about user interaction with the displayed content details.

For more information see: http://desktop.google.com/dev/api.html

In addition the GD API defines two additional interfaces:


Details View


The Details View is a UI feature that allows a gadget to display additional information in a separate window/gadget outside the Sidebar. Google Gadgets taking advantage of this feature can also receive notifications and events from the details view. The Detail View is exposed through the interface IGoogleDesktopDisplayDetailsViewHelper.

interface IGoogleDesktopDisplayDetailsViewHelper: IDispatch

interface IGoogleDesktopDisplayDetailsViewHandler: IUnknown

Notifier


The Google Desktop Sidebar offers a visual notification mechanism. Content items can be displayed in a special UI gadget that slides from the Sidebar. These are known as "notifiers" or "alerts."

interface IGoogleDesktopDisplayNotifier: IDispatch



Google Talk API Overview

Introduction


Sidebar gadgets can now communicate with Sidebar gadgets running on other machines.

Google Talk serves as the communication medium for Sidebar gadgets. If a user is logged into Google Talk, a gadget can get a list of which of the user's Google Talk friends are currently online. Once it has the list of online friends, a gadget can send and receive data from the same gadget running on an online friend's machine. If a friend doesn't have Sidebar installed, a gadget can instead send a text message to that friend.

The Communication API is available for both native and script-based gadgets. This document only covers how to use the Communication API to add communication capabilities as part of a Sidebar gadget. It assumes that you are familiar with the concepts and requirements for writing a Sidebar gadget as described in either the Google Gadgets API or Script API documents, depending on which you use to write your Sidebar gadgets.

Finding Friends and Sending Data


Your communication API starting point is the IGoogleDesktopPluginTalkService interface. Its methods get the list of the user's online Google Talk friends and send data to other gadgets. The first step in getting a pointer to IGoogleDesktopPluginTalkService is to get the client site.

The API implements the following objects and interfaces:

1. CComQIPtr ole_obj(plugin_helper_);

2. CComPtr client_site;

3. ole_obj->GetClientSite(&client_site);

4. CComQIPtr service_provider(client_site);

5. CComPtr talk_service;

6. service_provider->QueryService(IID_IGoogleDesktopPluginTalkService, 7. IID_IGoogleDesktopPluginTalkService, &talk_service);

8. interface IGoogleDesktopPluginTalkService: IDispatch

For more information on these interfaces see: http://desktop.google.com/dev/gadget-googletalk_apiref.html


Friend Objects


When your gadget gets the list of friends, each friend is represented by a IGoogleDesktopTalkFriend object.

This object has the following main methods:

get_name: Gets the friend's user visible name.

get_user_id: Gets the friend's userid, which you will pass to SendTalkText and SendTalkData.

get_has_sidebar: Does the friend have Sidebar installed?.

get_status: The friend's Google Talk status


Receiving Data


Now that you know how to find out who's available and how to send data to them, the next step is to add code to your gadget that notifies it when data arrives.

The following interfaces are implemented to assist with this operation:

1. interface IGoogleDesktopPluginTalkHandler: IUnknown

2. interface IGoogleDesktopDisplayPluginHandler2: IUnknown



For more information on these interfaces see: http://desktop.google.com/dev/gadget-googletalk_apiref.html


Created By Ron Rais & Ron Shalev



База данных защищена авторским правом ©shkola.of.by 2016
звярнуцца да адміністрацыі

    Галоўная старонка