1. Technician Table Editor Company: DVTel Academic advisor: Professor Ehud Gudes Technical advisor: Menny Even Danan Team: Olga Peled Doron Avinoam

2. DVTel DVTel is a pioneer and dominant market player in the creation, development, and delivery of Multi-source Intelligence Systems over IP networks.

3. One Of DVTel’s Systems

4.  Latitude 5.X is a platform which enables its users to manage cameras, sensors, microphones, relay motors etc’.  Its applications are diverse and include security, command and control, transportation management and business intelligence gathering. Background

5. Platform Latitude Platform

6. The Problem Domain  Today the information of all the devices is encapsulated in what is referred to as “Technician tables” which are written manually in an XML files.  Every manufacturer has its own XML file with information about the different models that he produces.

7. The Problem Domain (cont’d)  Different models have many features in common and as a consequence the information is encapsulated in inheritance hierarchy in the XML files.  Searching, editing or changing every XML file is carried out by hand and this process produces many bugs and requires a lot of maintenance.

8. Example OF XML File

9. Example OF XML File (cont’d)

10. Smart, semi-automatic editor to replace today’s method which will include: Graphical User Interface which enables the user to view, edit and create the metadata. Query engine.

11. Automatic table creator which enables the automatic creation of tables for the various cameras.

12. System Diagram

13. Physical Structure

14. Software Package Diagram (conceptual perspective)

15.  Software developers responsible of editing/changing the "technician tables".  Software developers of 3rd party pluggable components which must comfort to a well defined interface.  Both types have an established understanding of the system and the knowledge of operating it correctly. Stakeholders

16. Main Functional Requirements  Graphical User Interface which enables the user to view, edit and create the metadata of each device in a user-friendly environment. The GUI should be dynamic to adapt to new metadata properties required by Latitude.

17.  Query engine which enables retrieving Information about cameras and comparing between different models. Main Functional Requirements (cont’d)

18.  Development of components only for the following vendors: Verint and Axis.  Automatic table creator which enables connecting to a unit, querying the unit for its capabilities and automatically creates and updates technician tables.

19. Speed Capacity & Throughput: The number of users that can access the system simultaneously is only one. Safety & Security: The technician tables may be encrypted. Both encryption and decryption algorithms are provided by the latitude system (which implies a single key is stored in the latitude system). Portability: Supported operating systems: Microsoft windows XP, Microsoft Vista.

20. Reliability: The system is not required to withstand certain hardware or software failures, only write an informative message describing the erroneous to a log file. Platform: The system is developed under.NET platform using C# and the development environment will be Visual Studio 2005.

21. Extendibility: There are number of aspects, with respect to the system, that must be open to extension and closed to modification. These include the following:  Additional cameras must be added in a pluggable manner.  The abstract concept of technician table may have multiple implementations (the current and only implementation is with XML files).

24. ApplicationScope: User levelLevel: nonePre-condition: A new file was created with the name and location set by the programmer and is now open. Post-condition: 1. The programmer asks the system to create a new technician table. 2. The system displays to the user a list of available vendors. 3. The programmer selects the vendor he wishes creating a new technician table. 4. The system displays the connection information to be set by the programmer. 5. The programmer then sets the connection information of the vendor's camera and confirms. 6. The system establishes a connection to the camera of the given vendor and retrieves the features of the model. 7. The system queries the latitude system for the set of supported properties. 8. The system creates a technician table for the given vendor based on the information retrieved from the camera and the latitude system and notifies the user of the successfulness of the operation. Main success scenario: 4.1 The system fails establishing a connection to the given vendor. 4.2 It then notifies the user of the fault and logs this information to a file. 4.3 Finally, the system returns to the previous screen. Extensions (Alternative flows): Use case UC1: Create new technician table for a selected vendor.

26. ApplicationScope: User levelLevel: The technician table of the vendor is open.Pre-condition: The model is added to the technician table.Post-condition: 1. The programmer asks the system to create a new model. 2. The system presents the editable properties of the technician table. 3. The programmer sets the various properties and confirms. 4. The system adds the model entry to the technician table and notifies the user of the successfulness of the operation. Main success scenario: modelentry Use case UC2: Create new model entry for an existing vendor.

28. ApplicationScope: User levelLevel: A technician table is open.Pre-condition: none.Post-condition: 1. The programmer selects a model from the technician table. 2. He then selects an f/w entry of the selected model. 3. Next, she selects a profile to edit from the list of profiles. 4. He asks the system to edit the selected profile. 5. The system presents the editable properties of the selected profile. 6. The programmer edits the properties of the profile. Main success scenario: Use case UC9: Edit for each a set of profiles.

30. ApplicationScope: User levelLevel: The technician table is openPre-condition: The properties of the model are being displayed to the programmer Post-condition: 1. The programmer selects a model (or f/w of that model). 2. He then asks the system to display the information of the selected model(f/w). 3. The system displays the properties of the model(f/w) to the programmer. Main success scenario: Use case UC13: Display information of a specific model (optional f/w).

32. ApplicationScope: User levelLevel: the technician table is openPre-condition: A list of models supporting these properties are being displayed to the programmer. Post-condition: 1. The programmer asks the system to present model with specific properties. 2. The system presents the programmer a screen and asks the programmer to select the properties of interest. 3. The programmer selected the specific properties and confirms. 4. The system displays all the models supporting the specified properties. Main success scenario: Use case UC15: Display models which supports specific capabilities.

34. We might interact with different versions of the latitude system, which implies changes in the Latitude interface.

35. For more information please visit : www.cs.bgu.ac.il/~peledowww.cs.bgu.ac.il/~peledo