CS406 Software Engineering II

CS406/CS407 Software Engineering I/II

Project Sherlock

Sponsored by Tellabs

Preliminary Design Report

Version 1.0.3

February 15, 1999

Group Members

Douglas Clark

Shahman Baluch

Cengiz Bayazit

Rajiv Talwar

Tobey Pasheilich

List of Figures__________________________________________________________ 3

List of Tables___________________________________________________________ 3

Section 1 – Introduction___________________________________________________ 4

Section 2 – Architecture of Sherlock________________________________________ 6

2.1 Maps in Sherlock___________________________________________________ 7

2.2 Administration Interface______________________________________________ 8

2.3 Data Navigation____________________________________________________ 10

Section 3 – System Behavior: Use Case Related_____________________________ 13

3.1 Browsing Directory Information_______________________________________ 13

3.2 Modifying User Data________________________________________________ 15

3.3 Changing Data Templates____________________________________________ 18

3.4 Viewing Maps_____________________________________________________ 19

Section 4 – System Behavior______________________________________________ 20

4.1 Importing User and Map Data________________________________________ 20

4.2 LDAP Directory Maintenance________________________________________ 21

Section 5 – Test Plan____________________________________________________ 23

5.1 Basic Testing Units_________________________________________________ 23

5.2 Features to be Tested_______________________________________________ 23

5.3 Test Deliverables__________________________________________________ 23

Section 6 Design Evolution_______________________________________________ 24

Section 7 – Summary____________________________________________________ 25

Section 8 – Acknowledgements____________________________________________ 26

Section 9 – Bibliography_________________________________________________ 27

Appendix A – Use Cases_________________________________________________ 29

Kiosk Use Cases______________________________________________________ 29

Employee / Administrator Use Cases______________________________________ 31

Appendix B – Test Case Specifications_____________________________________ 34

Test Cases for Modify Login Procedure___________________________________ 34

Test Cases for Search Procedure_________________________________________ 34

Test Cases for Modifying Data___________________________________________ 35

Test Cases for Map Navigation__________________________________________ 35

Appendix C – Team Member Responsibilities_______________________________ 36

List of Figures

Fig 1.1 Overall System Component Diagram_____________________________________7

Fig 2.1 Sample Browser Interface______________________________________________11

Fig 2.2 Intranet vs Internet Use of Sherlock _____________________________________12

Fig 3.1 Search/Browse Behavior_______________________________________________13

Fig 3.2 Behavior of the Administration Component_______________________________16

Fig 3.3 Map Requests _______________________________________________________19

Fig A.1 Use Case Diagram ___________________________________________________29

List of Tables

Table 1. Sherlock Component Responsibilities___________________________________36

The purpose of this document is to present the design of the Sherlock system. Sherlock is a System and Human Resources Locator, intended for use at Tellabs to find information about people, facilities, and equipment. To aid in the design of Sherlock we used the Software Requirements Specification document, video conferencing sessions with Tellabs, group meetings, and the problem statement provided by Tellabs.

LDAP is a directory access protocol that enables the organizing of the information, and requires some sort of database to actually store the information. The storing of the information is completely transparent to Sherlock, and many different data store methods can be used. Sherlock will make information requests with LDAP, and LDAP will in turn communicate with the underlying data store method.

LDAP is a directory service that allows hierarchical organization of information. This makes it easy to classify information along departmental lines over the entire corporation. LDAP can run on a wide range of hardware and operating systems. In fact, LDAP is designed to be run on several computers at the same time, each serving clients individually. In addition, at some defined time, all the LDAP servers will synchronize with each other. This is important for geographically distributed corporations like Tellabs, where an LDAP server may be desired at each locale.

The design of Sherlock is derived starting from the use cases available from the requirements phase. With the use case diagram as a reference, Sherlock was divided into the components necessary to implement the functionality implied by each use case. The emphasis within our design is on simplicity and the use of existing technology to satisfy the project requirements.

This document describes the design and behavior of Sherlock. Section 2 describes the components within Sherlock and their interactions. In Section 3, we use sequence diagrams to give samples of Sherlock’s internal behavior as it implements the use cases. Section 4 uses sequence diagrams to describe the actions that describe Sherlock’s behavior as it interacts with LDAP. The plan for component and system testing Sherlock is detailed in Section 5. The remaining three sections contain the summary, acknowledgements, and bibliography. Appendix A contains a description of the use cases and how they break down Sherlock’s requirements. Several sample test cases are provided in Appendix B. Finally, Appendix C lays out team member responsibilities.

Section 2 – Architecture of Sherlock

Fig 1. Overall System Component Diagram

The system architecture above implements the use cases. The various components interact with with each other to serve their tasks. The various components have dependencies on each other, and through these dependencies, they allow for exchange of data.

The Web Browser component represents the three types of users identified in the use case for Sherlock i.e. kiosk, employee, and the system administrator. Each user is identified by the IP address, and depending on those attributes, their identity is established, thus identifying their access privilidges.

The Search/Browse component allows users to form queries on employees, resources, and facilities. The Web Browser and the Map CGI send their queries to Search/Browse, which in turns forwards the query to the Directory Server. The Search/Browse component is also responsible for formatting the data for the Browser.

The Simple Admin CGI component allows employees, and system administrators to modify data. The extent to which they are allowed to modify data depends on their ACL which is retrieved from the Directory Server.

The Map CGI component is responsible for the retrieval of vector information from the Directory Server and create maps on the fly at some level N. The variable N can be modified to allow for zooming in/out of the maps. The creation of the map at level N is done using the functionalities of the Map Generator.

The Directory Server component stores employee data, resource data, facility information, and ACLs. The component will serve the queries that the CGI components request. It is also used to enforce security restrictions through the use of ACLs.

2.1 Maps in Sherlock

2.1.1 Maps: Sherlock’s point-of-view

At the initial search, the coordinate information will be returned by the Directory Server to the client. Upon a zoom request, the Map Generator takes over the zoom process. In a nutshell, Generator works as follows:

Receives a request from a Web server.
Pulls in a Flash 3 Generator template (SWT).
Pulls in the appropriate data from a text file or text stream.
Performs any actions on the template, such as inserting additional graphics.
Sends a new SWF (Shockwave Flash) movie or GIF image back to the Web server.

When browsing, the client will send the information it had previously retrieved from the Directory Server back to the web server. Unauthorized users will not be able to see details they are prohibited from seeing, as this information will not be returned to them in their initial search.

2.1.2 Maps: User’s point-of-view:

The user will get an initial map of the Tellabs facility within the country the searched attribute is located. Upon each subsequent zoom request, the user will see a more detailed map with additional attributes added at each level of zoom (e.g.: The user will see a red dot showing the location of the searched attribute at each level, but the amount of information on the background will increase gradually as zoom requests occur). In the finest detail level, the user will be able to see the office of the attribute with a list of equipment, where each piece of equipment will be a clickable button which allows the user to request more information about that particular piece of equipment.

2.2 Administration Interface

The administrative component of Sherlock will provide simple data modification functionality to the Tellabs employee. The executables for this component reside on the same host as the web server, and communicate with the end user through the CGI interface. They also have the ability to perform LDAP requests to the LDAP server, which may or may not reside on this host. This component, while not designed for high-level administration tasks such as change to the LDAP schema, simplifies the task for ordinary users to change or update their information. Such users will be able to access this component either directly from a published URL or from the navigational component of Sherlock.

The goal of the admin interface is to provide simple, easy-to-use data modification access to the Tellabs employee base and simple administration functionality to the LDAP administrators who do not want to access the database directly. It allows only for changing attributes, and the addition/deletion of objects. More advanced directory updates, such as multiple object updates or widespread changes, must (and should) be done through direct manipulation of the directory with hand-written scripts or other directory maintenance tools like Netscape SuiteSpot.

2.2.1 The Interface

When employees wish to modify attributes in the system, they log in through this administrative script with their user name and password. If authentication is successful, they are then presented with a complete list of attributes associated with their ObjectClass (Person), with links beside each attribute that they are allowed to modify (please refer to section 3.2 for an illustration). Changes take place immediately within the Directory Server and are propagated to the other server(s) depending on the directory setup. Some users also have special privileges in LDAP to modify a broader range of ObjectClasses. When authenticated as an adiministrator, the user is presented with a search form and hierarchical browsing links along with the object's attributes. A link for modifying attribute values is present for those attributes they have permission to change. This allows for directory maintainers to perform simple modifications on a Person's sensitive attributes and other resources.

Administrative users may also use this component to add and delete new instances of an ObjectClass if they are allowed to do so. The Admin CGI presents these options depending on whether the adminstrator has these permissions.

2.2.2 Security

The user does not need to log out, but should be careful not to leave their browser unattended. All transactions to the web server are done with SSL, as well as all transactions between the script and the LDAP server.

2.2.3 Implementation

This component is being considered for implementation with PERL as an easy

and fast interface to the Admin CGI. There is a PERL library called PerLDAP that allows access to LDAP through PERL, and supports both SSL and the LDAP LDIF for communication with the directory.

There is, however, another possible implementation for this particular component. Netscape Directory Server allows for “plug-ins” that allow changes to the way the server handles requests. There are both pre- and post- processing plug-ins. Using a UNIX library API, a plug-in could be written to provide this sort of interface directly to the LDAP directory itself. This could add speed to the process, though it might limit Sherlock’s customizability.

2.3 Data Navigation

The main Sherlock interface consists of a Web Browser window with multiple frames. There is a small frame on the upper portion containing a search form and links to other functionalities of Sherlock, and a larger lower frame where data is displayed and heirarchical navigation takes place.

When the Search/Browse CGI receives a search request, it furnishes an appropriate query to the Directory Server. In turn, the directory returns zero, one, or many resultant objects. Therefore the Search/Browse CGI has different ways of presenting the data to the user. For cases where a single result is returned, the user is simply provided with the information in the lower portion of the frame, formatted using HTML templates with tags for the names of each attribute of the object returned. However, in instances where multiple objects come back, the Search/Browse CGI will display the results in a summarized list, with each entry a link to it’s page.

Fig. 2.1 Sample Browser Interface

2.3.1 Error Handling

The client has the ability to detect and inform the user in the event of an error. Once the Search/Browse CGI detects an error in the client request, the user is notified of this error and the possible reasons for it. For example, a search that returns no objects will result in a page informing the user of a fruitless search. As the search form is always present in the upper frame, the interface will allow the user to attempt another search.

2.3.2 Intranet vs. Internet Access

One requirement of Sherlock is to cater to requests from users within Tellabs as well as those from outside the Tellabs Intranet. This can be done by using a separate Search/Browse CGI for users outside the Intranet and those inside the Intranet. We enforce this restriction for several reasons. First and foremost, we want to distribute the load so that we do not bog the server down. Further, by having a distinct CGI application for Extranet users, we have the ability to add more security features. In order for us to distinguish where the users are from, we make use of the HTTP header. A more secure method would be to have a Sherlock setup outside the Tellabs firewall, running this special extranet Search/Browse script, but still with access to the Directory Server. For example, when a user makes a request from outside the Tellabs intranet, the IP address of the user is specified. This information will allow the Search/Browse CGI to discriminate between outside users and Tellabs employees.

Fig 2.2 Intranet vs. Internet Use of Sherlock

Section 3 – System Behavior: Use Case Related

3.1 Browsing Directory Information

Fig 3.1 Search/Browse Behavior

A Sherlock user wanting to look up some resource within Tellabs will form a query on the main Sherlock page, and click on the submit button. This information is redirected to the search/browse component. This component then checks for the correctness of the query. If the query is not acceptable, this component will generate an error message and display this on the web browser. On the other hand, queries that are “acceptable” will be redirected again to the directory server.

The directory server processes this query, and generates the results of the query. This result(s) is then sent back to the search/browse component. Depending on the result(s), the search/browse component then formats the result to be displayed on the lower portion of the web browser. In the case when no results ware generated by the directory server, an error message is displayed on the lower frame of the web browser.

3.2 Modifying User Data

Figure 3.2. Behavior of the Administration Component

When a CGI script is accessed, the web server it is associated with executes the script on the user’s behalf, passing to it the key/value pairs of the form data and any cookie information the browser has sent. As the script runs, the web server redirects all output from the script to the user’s browser. Because interactions between the web server and the CGI always behave like this (unless one or both are misconfigured), we will assume them to be the same functional component for this discussion.

A Tellabs employee, interacting with a web browser, can access this administration component either directly, through a known URL that points to Admin CGI, or indirectly through links from a Sherlock resources page or one of the other Sherlock components. The first request to the Admin CGI will contain no form data, and the CGI recognizes this by returning a friendly HTML file that contains a form for entering a username and password. The contents of this HTML file are stored statically with the script, so that Sherlock administrators may customize the look and feel of the page. The script may also check for SSL at this point, redirecting them to a URL that begins with “https” instead of “http” if SSL is not being used.

The user then enters their username and password. These should be configured to mirror (or access directly) the user’s usual login ID and password at Tellabs. Before authentication, the Admin CGI checks to ensure that the user is using SSL, by looking at the port number they used to connect to the web server. If an SSL connection is not detected, the user gets an error message, with some instructions for how to enable SSL. Otherwise, the Admin CGI uses LDAP to authenticate the user. A failed authentication will also abort this operation and cause the Admin CGI to return an error page.

Successful authentication prompts the Admin CGI to perform a basic LDAP search for the Person object associated with the user who logged in. Using the Access Control List of this object, the Admin CGI can determine which attributes this user can modify, and formats the attributes in a list, with name, value, and the possible option to modify as a link. For advanced users, the Admin CGI will also include a search form and hierarchical directory browsing links at this point, giving them the option to move to different objects. Most importantly, returned with this page is a “cookie”, which is a key/value that the browser retains for the duration of the session, and includes it on all subsequent requests. This saves the “state” of the session, and allows the Admin CGI to recognize the user as already logged in.

The user may then choose to modify one of the attributes by clicking on the “modify” link beside its key/value. The Admin CGI responds with a small form showing the attribute’s name and former value, along with a text box to enter a new value. The user makes these changes in the form, and submits them back to the Admin CGI once again. This time, the Admin CGI checks the user’s permission one more time. If it seems feasible, the CGI generates the change request as an LDIF file, the LDAP standard for directory modifications of any complexity. Then it sends the LDIF request to LDAP, and receives the results. Remember that, though the Admin CGI performs some security checks, the final line of defense is the LDAP server itself. If the server determines that the modification is not allowed for any reason, it will reject the request, and the CGI script will inform the user of this reason. Otherwise, the user is notified of success. In either case, the user is presented again with the list of attributes of the object they are examining. Because the script can determine the success or failure of the request, it does not need to do a new search for the object’s attributes, but instead simply updates it’s copy with any changes successfully made.

3.3 Changing Data Templates

One of the features of Sherlock is a mechanism for formatting any LDAP object’s attributes in a way that is pleasing to the eye. This is done in Sherlock by the use of templates. Using an HTML template, Sherlock’s look and feel can be customized for every type of object. The templates look, for the most part, like a normal HTML file. There is an HTML template associated with every ObjectClass that Sherlock can display, as well as a small template for displaying the object in a search results summary. The file can contain any standard HTML tag, including images, applets, and tables. Frames should not be used, because the Sherlock interface already uses them. For the places where an object’s attribute should appear, a “tag” is used, with the name of the attribute, and formatting characters that allow the tag to be recognized by the script that parses the template. Tags may have more advanced features, such as limiting the size of a attribute, or describing what to do with multiple values of an attribute. Knowing the format specification for an attribute, a little HTML, and the attributes in an object, a system administrator can customize every aspect of Sherlock, using a simple text editor. If multiple instances of Sherlock are in use, each one should have common access to the templates, or else they should be distributed among the instances, with some form of version control. Sample templates will be installed when Sherlock is first implemented.

3.4 Viewing Maps

Fig 3.3. Map requests

After a user gets the requested information about the searched attribute, they also get a link to view a map of where that attribute is. Once they make a request to view the map, the Map CGI component makes a call to the directory server to retrieve the map data at level n. After the directory server returns the data, the Map CGI will then make a request to the Map Generator, by passing the retrieved data to the generator. The Map Generator will pull in a map template, insert the map data retrieved from the request, compose the map, and return the map to the web browser window of the user.

Section 4 – System Behavior

LDAP is already deployed at Tellabs. This deployment consists of installing the Netscape Directory Server and the Netscape SuiteSpot Server. The Netscape Directory Server is synonymous with an LDAP Directory Server. This Directory Server has already been populated with Tellabs' directory information. Sherlock will require some modifications to the pre-existing installation.

The security of the LDAP server has received a lot of attention, and through the combination of several technologies, a secure system will be delivered. All transactions with the LDAP server will be conducted over an SSL encrypted connection. This encryption prevents the possibility of decrypting information intercepted during transit. Once the information reaches the server, LDAP's built in Access Control Lists will be used to determine access privileges. For any administrative actions to take place, the user will have to be authenticated. Provided that the LDAP server is configured correctly, the security provided should be excellent.

There are two final advantages to LDAP. First, it's very fast at retrieving data. Second, it allows a schema that is easily extensible to allow for new kinds of information to be stored in the directory.

4.1 Importing User and Map Data

Sherlock may require minor additions to Tellabs' directory schema. If this is the case, the modifications can be effected by the execution of a script to enable the Sherlock-specific directory information. After the schema is configured, any required data can be loaded with an additional script. Most likely, most of the updates will be made to allow for Sherlock’s mapping functionality. Access Control Lists (ACLs) can also be installed once the schema is updated. Once these ACLs are in place, the server will be secure and ready for action.

We prefer to not store the entire map in the database because the map image might be quite large. Instead, Sherlock stores the map data in the database in a format like the one used by Flash, which is vector based and much smaller. It also has built in zoom features. The Flash plug-in now ships with Netscape and IE so it's a fairly common plug-in. The idea is that we can store x & y coordinates in the directory for each attribute we wish to put in the map.

We do not plan to provide finer detail than the level of an office. This is because of the impracticality of this implementation. The resources in an employee’s office change often.

We will enter all of the vector data from the images into the directory first, and organize it by zoom level. For each level map requested, there will be a search for the vector data for that level. For initial map generation, we will need Macromedia Flash, and for generating the images on the fly, we will need Macromedia Generator.

4.2 LDAP Directory Maintenance

As with any software development, future maintenance has been considered

in the design of the Sherlock System. Minor maintenance functionality will be

available through the administration CGI interface. However, more advanced maintenance of the Directory server will be facilitated through the use of the

Netscape SuiteSpot Server.

SuiteSpot offers nearly all the functionality that will be necessary to perform maintenance on the Directory server. SuiteSpot provides a web based interface to easily configure the Directory server. As examples, SuiteSpot provides interfaces to Server Preferences, Access Control, Database Management, Replication and Schema.

Section 5 – Test Plan

The bottom-up approach to testing will be used. Testing will start with unit testing the individual aspects of each component, and proceed into testing higher-level functionality, and then elevating to a system-wide test.

At each level, functional testing will take place. Functional testing will consist of testing whether, for a given input, a unit’s actual output matches the expected output.

5.1 Basic Testing Units

The initial test units will be the individual components. Each developer will be responsible for testing their individual component. The test units will then be integrated incrementally. The last steps of the integration tests will be to perform load and concurrency tests, to ensure that Sherlock meets the non-functional requirements.

5.2 Features to be Tested

All features to be included in Sherlock will be tested. These features are grouped into two categories: user features and administration features. The user features include searching for data and navigating maps. The administration features include adding, deleting, and modifying user and resource data, and security functions, such as enforcing data access permissions.

5.3 Test Deliverables

The test deliverables consist of a test case specification report (Appendix B of this document), a test design, and a test summary report.

Section 6 Design Evolution

The Sherlock system model has been simplified to make use of the features of LDAP and the flexibility of CGI scripting languages. In previous designs, a master “Sherlock server” implemented nearly all of Sherlock’s requirements; however, it was discovered that this was unnecessary overhead, and most of these requirements could be solved by LDAP services. The core requirements of Sherlock that are not provided by LDAP directly are an easy-to-use and aesthetically pleasing navigation interface, simplified personal data modification, and facility map navigation. Therefore, the “Sherlock server” has been removed and replaced it with three small, efficient server-side CGI based programs to handle those tasks. Correct understanding and implementation of an LDAP directory will fulfill the rest of Sherlock’s requirements, including distributed storage, security, and speed.

Section 7 – Summary

The original design for the Sherlock system in CS 406 was constructed using the UML with Rational Rose as a modeling tool. The process of Object Oriented System Design is a complex and nebulous task that takes years to master. Making the transition from Function Oriented thinking to Object Oriented thinking presented a significant challenge to all members of the Tellabs Groups. In CS 407, simplifying this process has become a fundamental aspect to our approach.

This design document contains all diagrams associated with the most current version of our System Model.

Section 8 – Acknowledgements

The Sherlock Project would not have been possible without the hard work and time of the many students of CS 406 who graduated in December, 1998. We would first like to thank the following alumnus CS 406 for their contributions:

Group A	Group B
Eric Bowman	Fauzia Aslam
William Craver	Valisha Bradford
Gregory Ebert	Mohammad Jawad Butt
Benjamin Foster	Evan S. Ho
Scott Freeman	Usman Latif
Eric Laabs	Larry Lewis
Drew Michaels	Andre Young

We would like to acknowledge the following people for their assistance and instruction:

· Professor Aditya Mathur for his instruction in the CS 406 and 407 Software Engineering course.

· Suresh Murthy of Tivoli Systems for his instruction in the use of UML.

· Eric Wiegman, Mike Connoly, and everyone at Tellabs for their time and the opportunity to learn and work on this project.

Section 9 – Bibliography

1. H.E. Eriksson and M. Penker. UML Toolkit. Chapters 2-5. Wiley Computer Publishing, 1998.

This text served as a reference for UML and aided in the specification of use cases and various diagrams.

2. Quatrani, Terry. Visual Modeling With Rational Rose And UML. Chapters 3 and 6. Addison Wesley Longman Inc., 1998.

This text was referenced to learn Rational Rose to create various diagrams and to more clearly visualize the functionality and design of our project.

3. http://www.umich.edu/~dirsvcs/ldap/doc/

Website used as a reference to learn the fundamentals of LDAP and as a souce for

LDAP documentation.

4. http://www.cs.purdue.edu/homes/apm/cs406-fall98/projects/tellabs-project/sherlock.pdf

This website contains the Software Requirements Specification by Mike Connolloy of Tellabs. This was used as the basis for our own SRS document

and to gain an initial understanding of the Sherlock project.

5. http://www.multimedia.com

This website was our source to gain knowledge about using Flash for the map f eature of Sherlock.

Appendix A – Use Cases

Fig A.1 Use Case Diagram

Kiosk Use Cases

Search

The initial function, which most users will employ, is search. This function allows the user to locate specific information about various types of objects. Examples of objects include the following: people, printers, offices, conference rooms, jacks, ports, and computers. After the user specifies the type of object, a set of search criteria is presented. This set of criteria will be modifiable by each user according to personal preference. The user will also be able to specify what information about the matching objects that will be displayed in the results. This might be useful if a person is only interested in a particular piece of information such as date of birth. The information a user chooses to be displayed on the results page, as well as the search criteria, will be stored in the user’s preference file. The next time an object of this type is searched for, the saved settings will be used. After the user determines the criteria by which to search, he or she will fill in the form with the information he knows, and click search. Within ten seconds, the user will be presented with a screen of results showing all objects that meet the search criteria. Each object listed will refer to a page showing relevant information about that object. The map location of the object will link to the map navigation view where the user will be able to view the physical location of the object. This leads the user to the next use case: the navigation interface to Sherlock.

Navigate

If the user elects to enter into the map navigation function of Sherlock directly, he or she will initially be asked to choose which of the Tellabs campuses they want to view. Mouse-over data should be supported for the campuses themselves. When the user selects a campus, he/she will be presented with all the buildings at that campus. Once a building is selected, the user will get to a building/floor view and be able to choose a floor. Further zooming will be allowed, and the user will be able to browse the map as desired. All devices in the area will support mouse-over data, and if the user clicks on an object, the object’s information screen will appear with detailed information. This will display the same screen as that which would be shown if the user had found the object using the search use case. He or she will be able to choose any devices to appear on the map. This might be useful when one is looking for relatively small objects that could be covered by others.

Notify

Another functionality available to the user is the ability to send notifications. This functionality is fairly simple from the user’s standpoint. He or she simply clicks on someone's email address and an email form will appear for them to write a message. Users will also be able to directly reserve a conference room. Likewise, clicking on a pager number will allow the user to send a message. If the pager being accessed is alphanumeric, the user should be presented with a form similar to the email form to type a message to be sent.

Employee / Administrator Use Cases

Login

The Login use case simply provides for the authentication that some functions of Sherlock will need to ensure that the user requesting a service has permission. Logins, as most users are already familiar with, consist of providing user identification and password information to the system, using secure transmission, and being informed of the success or failure of the login attempt. Once logged in successfully, the user may then proceed to use the desired resource.

Modify Data

The Modify Data use case is the simplest, being integrated directly into the data display. As Sherlock interacts with a user browsing through the database, it will give the user the option to change any piece of data that the he/she has permission to modify. In the most common case, this will be for a regular employee to modify personal data such as contact information. Access permissions, as administrated in the Security use case, can range from prohibiting any data modification, as with a kiosk user, up to a master login which would allow modify access to any piece of data in the system. Information updates are done via the same general interface as the browser, but the option to modify something is presented alongside the data if the user is allowed to do so. Any person choosing to modify data will be changing roles from information viewer to administrator when doing so.

Modify View/Format

An important feature of Sherlock is the ability to customize its look and feel. There are two issues associated with this feature: the layout and organization of the GUI components and data display, and the settings of personal preferences for each user. Sherlock will give administrators the ability to customize screen layouts for every screen it presents, with the option of uniquely specifying the layout for each user community. A user community is a template defined within Sherlock that holds screen layouts, default preferences, and restrictions on all users belonging to that group. Screen layouts include search forms and dynamically generated search results screens. The general look and feel of these screens can be customized. Screen layouts also include the data display screens for an object and an object class, such as the layout of a person's page, a printer information screen, a building/facility summary, and the home page for a department. These layouts will be easy to modify, with an intuitive interface that uses the names of object fields to represent their positions on a page. Sherlock preferences allow each user to tailor the Sherlock interface to an individual’s needs. Depending on the preference restrictions for a user's group, a user could elect to hide certain information fields from view, default search criteria and result set for each object, and which devices should be labeled on maps.

Modify Security

Only Sherlock administrators will use the Security use case. Sherlock will allow administrators to define and manage the user groups of the system. They will be able to change the default preferences for new users in a user group, and enforce restrictions on which preferences a user in a group will be allowed to modify. For example, if a user group is defined for all employees of the HR department, Sherlock could prevent them from electing to have their e-mail address hidden from view in normal data display. For each user group, it is possible to customize what types of data they may see at all, and what data they are allowed to change. For example, a kiosk user will have a very restricted range of data he or she can see, and will not be able to modify anything. Administrators can add, delete, and modify accounts. As a user group defines most properties of a user, there will be very little additional data here. Modifications of this type include changing passwords, granting privileges, and setting restrictions. At the lowest level, Sherlock administrators will be able to customize the security level structure itself. Sherlock will provide a security level system that is flexible and intuitive, giving Tellabs the ability to specify permissions for as many user groups as are needed to fully implement the system.

Appendix B – Test Case Specifications

Test Cases for Modify Login Procedure

Correct login/password	MainPage with user options will be displayed in browser
Incorrect login/password	User will receive login screen

Test Cases for Search Procedure

Request for non-existent data	No objects shown in browser, and an error message displayed
Request for one item of data (i.e., one employee, one conference room)	Information of object shown in browser
Request for multiple items of data (i.e., all employees with office on fifth floor)	Information of all object matching request shown in browser with each object separated

Test Cases for Modifying Data

Valid new value (i.e., new phone number)	Information updated in the Directory Server, and a response in browser stating successful completion of modification
Invalid new value (does not satisfy constraints)	Information is not updated, and response reports why update is not done

Test Cases for Map Navigation

Requesting a specific map	Correct map displays in browser
Correct object placement on map	Ports, printers, etc. should be located in the expected location on the map displayed in the browser
Mouse over data	The correct information should be displayed when the mouse is held over an item (i.e. when mouse is held over printer, phone information should not be displayed)
Links to LDAP hierarchy	An object’s associated map comes up correctly when requested; an object’s page comes up when it is requested from the map.

Appendix C – Team Member Responsibilities

Component	Responsible Members
Administrate CGI	Doug Clark
Search / Browse CGI	Shahman Baluch
Map generation and display	Cengiz Bayazit & Tobey Pasheilich
Directory Server	Cengiz Bayazit & Tobey Pasheilich

Table 1. Sherlock Component Responsibilities

Tasks	Responsible Members
Group Leader	Doug Clark
User Interface and Formatting	Shahman Baluch
LDAP research and information	Cengiz Bayazit & Tobey Pasheilich
Maps	Cengiz Bayazit & Tobey Pasheilich
Documentation maintenance and web page	Raj Talwar

Table 2. Team Organization