CS406 Software Engineering I
Project Sherlock
Sponsored by Tellabs
Design Report
Version
1.0.1
December
11, 1998
Group A
Team 1 Team
2
Scott Freeman (Team 1 Leader) Tobey Pasheilich (Team 2 Leader)
Eric Laabs Benjamin
Foster (Group A Leader)
Eric Bowman Gregory
Ebert
William
Craver Rajiv
Talwar
List
of Figures__________________________________________________________ 4
List of Tables___________________________________________________________ 4
Section 1 – Introduction___________________________________________________ 5
Section 2 – Classes and
Objects____________________________________________ 6
2.1 SessionManager____________________________________________________ 6
2.2 Session____________________________________________________________ 7
2.3 User______________________________________________________________ 7
2.4 Request (and derived
classes)_________________________________________ 7
2.5 Interface (base and
derived classes)____________________________________ 9
Section 3 – System
Behavior I____________________________________________ 10
3.1 Logging Into
Sherlock______________________________________________ 11
3.2 Logging Out of
Sherlock_____________________________________________ 12
3.3 Invoking a Search
Request Using Sherlock______________________________ 13
3.4 User Removal in
Sherlock___________________________________________ 14
3.5 Setting User
Preferences with Sherlock_________________________________ 15
Section 4 – System Behavior II____________________________________________ 16
4.1 Overview of Session
Management_____________________________________ 16
4.2 Overview of a Search
Request________________________________________ 18
Section 5 – Test Plan____________________________________________________ 18
5.1 Test Unit
Specification______________________________________________ 18
5.2 Features to be
Tested_______________________________________________ 19
5.3 Approach For Testing_______________________________________________ 19
5.4 Test Deliverables__________________________________________________ 19
5.5 Testing Schedule___________________________________________________ 19
5.6 Personnel Allocation________________________________________________ 20
Section 6 – Summary____________________________________________________ 20
Section 7 – Acknowledgements____________________________________________ 20
Section 9 – Bibliography_________________________________________________ 21
Appendix A – Use Cases_________________________________________________ 22
Browser Use Cases____________________________________________________ 22
Administrative Use Cases______________________________________________ 24
Appendix B – Test Case
Specifications_____________________________________ 26
Test Cases for Login
Procedure__________________________________________ 26
Test Cases for Search
Procedure_________________________________________ 26
Test Cases for Modifying
Data___________________________________________ 27
Test Cases for Map
Navigation__________________________________________ 27
Appendix C – Team Member
Responsibilities_______________________________ 28
Figure 1. Overall Class
Diagram____________________________________________ 6
Figure 2. Login Sequence Diagram_________________________________________ 10
Figure 3. Logout Sequence Diagram________________________________________ 11
Figure 4. Search Request Sequence Diagram__________________________________ 12
Figure 5. Remove User Sequence Diagram___________________________________ 14
Figure 6. Set Preferences Sequence Diagram_________________________________ 15
Figure 7. High-Level Activity Diagram______________________________________ 16
Figure 8. Search Activity Diagram__________________________________________ 17
Figure 9. Use Case Diagram______________________________________________ 22
Table 1. Team Member
Responsibilities______________________________________ 28
Table 2. Code Complexity________________________________________________ 28
The purpose of this document is to present our design of the Sherlock system. Sherlock is a System and Human Resources Locator, which will be used at Tellabs to find information about people and equipment. To aid in the design of Sherlock, the Software Requirements Specification document, video conferencing sessions with Tellabs, group meetings, and the problem statement provided by Tellabs were all used.
This document contains the component diagram, class diagram, sequence diagrams, activity diagrams, and descriptions of the behavior of Sherlock. Section 2 contains descriptions of the classes and components that comprise Sherlock. In Section 3, system behavior for each use case is described with the help of sequence diagrams. Section 4 uses activity diagrams to describe the actions that take place in specific scenarios. The plan for testing Sherlock is described in Section 6. The remaining three sections contain the summary, acknowledgements, and bibliography. Appendix A contains a summary of the use cases. Several sample test cases are provided in Appendix B. Finally, Appendix C covers team member responsibilities.
The design of Sherlock was formulated in terms of the use cases from the Requirements Phase. Using the Use Case Diagram as a reference, the project was broken into the components that would be necessary to implement the functionality for each use case. Examining this data, attributes and related operations were packaged into classes. Finally, the relationships among classes were identified, resulting in the Class Diagram.
Figure 1.
Overall Class Diagram
Figure 1. shows the overall class
diagram for main Sherlock system component, including inherited classes and
dependencies among the classes. Below
is an explanation of each of the classes shown.
The SessionManager Class is the main persistent interface to the Sherlock server. The Run() method listens for connections from the Web server, via sherlock.cgi component, and processes requests. This class also contains methods to handle login and logout procedures. SessionManager maintains a list of active sessions, and periodically polls each session using AutoTimeoutPoll() to see if it has timed out to ensure users are logged out properly for security purposes.
The Session class contains the data
associated with a single user’s session in Sherlock. It manages the object for the particular user, the time of last
activity, and the state of the session.
The state will specify the type of request being processed. There is
also a method, UpdateUserInformation(),
for updating the user object in memory from the database.
Each user of the Sherlock system has a corresponding object that contains his or her individual permissions and preferences. The object’s methods GetPermissions() and GetPreferences() allow outside objects to check information on what the user is allowed to do. This object is stored in the LDAP data store when the user is not logged in, and it is stored in the Session object while the user is logged in. This object also provides means for the user to change his or her preferences. Examples of preferences include hiding certain personal data, setting a default start page, a default map level, and filtering the results of a search.
The Request class is an abstract class, from which the specific request classes are derived. When the SessionManager creates a request object, the Request validates itself based on the user’s permissions, to ensure that the user has permissions to execute the request. It then handles the request by retrieving the proper information from the LDAP data store and sending it back to the client. The individual request classes, LoginRequest, MainPageRequest, UserDataRequest, AdminRequest, SearchRequest, and MapRequest, handle the information received from the sherlock.cgi component to retrieve the information from the LDAP Directory Server and format the response and return it to the client.
The LoginRequest class provides the methods necessary for handling and controlling user logins and logouts.
The MainPageRequest provides the methods necessary for dynamically generating the Sherlock main functionality page. This page will vary depending on the three base user types (i.e. Kiosk, Admin, and Admin).
The UserDataRequest class provides the methods for manipulating the users’ personnel data within LDAP Directory Server. These methods include the ability for adding, deleting, modifying, and hiding individual object attributes.
The AdminRequest class handles security administration for the Sherlock system. This class provides methods for setting system security levels, managing user accounts (i.e. adding and deleting of individual users), and modifying individual user security levels.
The SearchRequest provides methods for the user to do textual based queries on the data. These textual queries are based on the user’s selection of object type, and using boolean relations to provide a more specific search criteria. The object type selection is provided through the use of pull down menus, which present the various object types current in the LDAP Directory Server.
The MapRequest provides an interactive interface to the user, which allows for navigation based on Tellabs facility map data. This allows users unfamiliar with the Tellabs facilities to navigate to the desired location, and receive specific information pertaining to the said location.
The Interface class is an abstract class that defines the transaction methods and transaction logging. These transaction methods are further defined through the specific FileInterface and LDAPInterface class definitions. The FileInterface class provides data structures for interpreting the data used by stand-alone Sherlock client. The stand-alone data will be in a read-only format. The LDAPInterface provides means for data transaction with the LDAP server through using the standard LDAP API. This API referencing is further simplified through the use abstract Interface class methods. The Interface class methods provide a translation layer between the LDAP API and the client’s submitted form data.
In this section, a series of Sequence Diagrams are presented to illustrate the collaboration of various objects in specific scenarios of system behavior.
Figure 2. Login
Sequence Diagram
The Sherlock login process is described in the sequence diagram in Figure 2. The SessionManager object’s Run() method is the only entry point for requests into Sherlock. The request is identified as a login request in this sequence, so SessionManager creates an instance of LoginRequest(), which creates a SearchRequest to find the user in the database. This object talks to the data store through the LDAPInterface to find the user, which is an abstraction layer above the actual storage of Sherlock data, so that either a LDAP Directory Server or a file if using the standalone version.
If the user is not found, the SearchRequest fails and this information is conveyed back to the user. If the user is found, SessionManager creates a new Session object with this user object and reports success. It then presents the user with the main menu of the system.
Figure 3.
Logout Sequence Diagram
The Sherlock logout process is described in the sequence
diagram in Figure 3. As stated in
Section 3.1, all Sherlock processes begin with the SessionManager’s run() method. When logout is requested, the user’s active session is removed
and the transaction logged.
Figure 4.
Search Request Sequence Diagram
The Sherlock SearchRequest process is described in figure 4. In this case, the SessionManager invokes the FindSession() method. This searches the active sessions to determine if the user is logged in. In the event of the user being timed-out or a system failure, an error message will presented stating the nature of the given error. Next, the SearchRequest object attempts to validate the user’s query using his or her permissions. If the user does not have permission to process the request, an error message is displayed. Otherwise, SearchRequest will process the query normally, calling on the LDAPInterface to find the specified object(s) in the database.
Figure 5.
Remove User Sequence Diagram
A user with administrative permissions can remove another active user from the Sherlock system. The SessionManager invokes the FindSession() method to determine if the session exists. The SessionManager creates a Request object of type AdminRequest to handle this request. The user to be deleted is first queried using the given form, if the user isn’t found an error will be displayed stating the nature of the error. Upon locating the said user, the administrator can then continue to delete the user.
Figure 6. Set
Preferences Sequence Diagram
Once the requesting user’s session is validated, the SessionManager
creates a UserDataRequest object.
If no modifications are made, this method provides the user with a
screen displaying his or her current preferences and the controls to change
them. If changes were made, the UserDataRequest
object calls the LDAPInterface object to commit changes to the database. Next, the SessionManager
synchronizes the User object in memory with the database using the UpdateUserInformation() method on the Session
object.
In this section are activity diagrams that illustrate activities that take place between objects and components during the execution of Sherlock.
Figure 7.
High-Level Activity Diagram
The main interface to Sherlock is the SessionManager object, which is continually running as a process on the host on which Sherlock is installed through the SessinManager’s Run() method. Requests are generated from a CGI program that defines the web interface to Sherlock. All such requests call the Run() method of the SessionManager, making this a good choice to investigate general Sherlock behavior.
The SessionManager’s primary function is to manage the active user sessions. When a request comes in, the SessionManager first determines if the request is a login request. If it is a login request, a new session is created, the user is authenticated, and then receives a menu with the functions that he or she has permissions for. If the request is not a login request, the SessionManager determines if the session referenced in the request is still active. If not, the request is a not valid and an error response is generated and sent to the user. If the session is active, the RequestStruct is passed to the Session for processing.
Figure 8.
Search Activity Diagram
The Session uses the incoming request data to determine what kind of request it is. Next, it instantiates a Request object based on the type of request, and calls the object’s Handle() method to complete handling of the request, passing the form data and user preferences. The SearchRequest is a fundamental request type to the primary functionality of Sherlock, and is therefore suitable for depiction in an activity diagram. Searches can be defined to be for a particular object, retrieving just that object from the database based on constraints, or they can be a general search returning a list of objects.
Since Session has not fully decoded the form data from the client, SearchRequest must first finish parsing this information and determine the exact nature of the search to be performed. The Request object will then invoke methods from the LDAPInterface object to find the data, if any. If data is found, the user preferences are used to generate an output listing of the objects found. Otherwise, a “no objects found” error message is returned to the user.
The initial test units will be the individual classes. Each developer will be responsible for testing is or her individual class. The test units will then be integrated incrementally for testing. The last steps of the integration tests will be to include each individual request class. Then, the system will be tested for all request types to ensure that previously included functionality is working as expected.
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 login and logout, searching for text data, and requesting maps. The administration features include adding, deleting and modifying user and resource data, and security functions, such as enforcing data access permissions.
The bottom-up approach to testing will be used. The current implementation methodology is bottom-up, so the testing methodology will be similar. Testing will start with unit testing the individual methods within each class, and move into testing higher-level functionality.
At each level, functional testing will take place. Functional testing will consist of testing whether, for a given input, the unit’s actual output matches the expected output.
The test deliverables are a test case specification report (Appendix B of this document), and a test summary report.
Unit Development and Testing |
11/4 through 11/17 |
Pre-presentation System Test |
11/18 through 11/19 |
Integration Testing |
11/20 through 12/3 |
Full System Testing |
12/3 through 12/8 |
Prototype Component |
Responsible Members |
SessionManager Class |
Scott Freeman, Greg Ebert, Raj Talwar |
Session Class |
Eric Bowman, Bill Craver, Ben Foster, Raj Talwar |
User Class |
Eric Bowman, Bill Craver, Ben Foster, Raj Talwar |
Request Classes |
Doug Clark, Drew Michaels, Tobey Pasheilich, Scott Freeman, Eric Laabs |
LDAP Classes and Server |
Drew Michaels, Tobey Pasheilich, Doug Clark |
CGI program |
Doug Clark, Greg Ebert, Bill Craver |
SSL/Web Server |
Ben Foster, Eric Laabs, Tobey Pasheilich |
The design for the Sherlock system was constructed using UML and Rational Rose. 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 Tellabs Group A.
This design document contains all diagrams associated with the most current version of our System Model. The Sherlock project has provided a unique opportunity for learning and personal growth.
We would like to acknowledge the following people for their assistance
and instruction:
Professor Aditya Mathur for his instruction in the
CS 406 Software Engineering course.
Suresh Murthy of Tivoli Systems for his instruction
in the use of UML.
Eric Wiegman, Mike Connolley, and everyone at
Tellabs for their time and the opportunity to learn and work on this project.
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.
Figure 9. Use
Case Diagram
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 will be displayed in the
results. This might be useful if a person is only interested in a certain piece
of information that could easily be viewed from the result screen, such as the
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
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
will initially be asked to choose which of the Tellabs campuses he wants to
view. Mouse-over data should be supported for the campuses themselves. When the
user selects a campus, he 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 show the same screen as
that which would be shown if the user had found the object using the search use
case. He 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 simply clicks on
someone's email address and an email form will appear for him 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.
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 user 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 be 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 through 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 at hand: 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 though the general look and feel 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 what
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 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.
Correct login/password |
MainPage with user options will be displayed in browser |
Incorrect login/password |
User will receive login screen |
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 |
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 |
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) |
Table
1. Team
Member Responsibilities
Document Category
|
Contributing Members
|
1: Introduction |
Eric Bowman |
2: Classes and Objects |
Scott Freeman |
3: System Behavior I |
Doug Clark and Drew Michaels |
4: System Behavior II |
Doug Clark and Drew Michaels |
5: Class Packaging |
Drew Michaels |
6: Test Plan |
Ben Foster, Eric Laabs, Scott Freeman, Greg Ebert |
7: Summary |
Ben Foster |
8: Acknowledgements |
Rajiv Talwar |
9: Bibliography |
Rajiv Talwar |
Appendix A |
Eric Bowman |
Appendix B |
Eric Laabs |
Appendix C |
Ben Foster |
Diagrams |
All Members |
Integration |
Tobey Pasheilich |
Revisions |
All Members |
Table
2. Code
Complexity
Class |
LOC |
Coders |
Tester |
SessionManager |
140 |
Ben,
Tobey |
Tobey |
SessionList |
110 |
Doug,
Raj |
Doug |
Session |
130 |
Drew,
Doug |
Laabs |
Request
(all) |
250 |
Drew,
Tobey |
Tobey |
Response |
160 |
Doug,
Scott |
Doug |
Socket |
120 |
Ben,
Doug |
Ben |
Message |
280 |
Doug,
Tobey |
Drew |
Connection |
140 |
Ben,
Greg |
Drew |
User |
50 |
Greg,
Drew |
Laabs |
Interface
(all) |
230 |
Drew,
Tobey |
William |
CGI
module |
100 |
Ben,
Doug |
Greg |
TOTAL |
1700 |
|
|