All Combined Lectures - Software Design | CMSC 435, Study Guides, Projects, Research of Software Engineering

Download All Combined Lectures - Software Design | CMSC 435 and more Study Guides, Projects, Research Software Engineering in PDF only on Docsity! Warehouse Inventory Tracking System Design Specifications CMSC435 Fall 2006 Collapse Team Version 1.0 Rev. 10/26/2006 CMSC 435 Fall 2006 Collapse Team Preface The Collapse Team at the University of Maryland has worked to engineer software for the Maryland Task Force One Team (MDTF-1). There are currently two projects developed for MDTF-1. The first project is the National Emergency Deployment System (NEDS). NEDS pioneered to solve the team member organization problems of MDTF-1. With the help of NEDS, MDTF-1 is able to organize members by skill sets, group placement and availability for deployment. The software’s user interface provides easy control in setting up and retrieving data from a central database, which is hard coded for only MDTF-1’s access. The second project is the Member Organization and Deployment System (MODS). MODS built upon the initial goals of NEDS but for a more general client base which includes anyone who needs web-based software for organizing teams or groups. The features presented by MODS removes some of the limitations of the NEDS software. MODS gave the user the ability to set up databases without hard coding a central database as well as many other additional features. The Fall 2006 Collapse Team at the University of Maryland is starting a project for the Maryland Task Force One Team to address an issue concerning the management and distribution of warehouse equipment. The new project is called the Warehouse Inventory Tracking System (WITS). Warehouse Inventory Tracking System – Design Specifications 1 CMSC 435 Fall 2006 Collapse Team 5.3 Detailed Implementation..........................................................................................49 5.3.1 Barcode scanner interface.................................................................................49 5.3.2 Barcode Labels..................................................................................................49 5.3.3 Barcode Printers................................................................................................49 6.1 Introduction..............................................................................................................50 6.2 Design Consideration...............................................................................................50 6.3 Detailed Implementation..........................................................................................50 6.3.1 User Access Level.............................................................................................50 6.3.2 Interface with Server.........................................................................................50 6.3.3 Login.................................................................................................................51 6.3.4 Graphical User Interface...................................................................................51 5. Integration......................................................................................................................52 7.1 Introduction..............................................................................................................52 6. Application Data Models...............................................................................................53 8.1 Introduction..............................................................................................................53 8.2 Design Considerations.............................................................................................53 8.3 Detailed Implementation..........................................................................................53 7. Packaging and Deployment...........................................................................................54 9.1 Introduction..............................................................................................................54 9.2 User Manual.............................................................................................................54 9.2.1 Description........................................................................................................54 9.2.2 Design Considerations......................................................................................54 9.3 Quick Start Guide....................................................................................................54 9.3.1 Description........................................................................................................54 9.3.2 Design Considerations......................................................................................55 9.4 Help Documents.......................................................................................................55 9.4.1 Description........................................................................................................55 9.4.2 Design Considerations......................................................................................55 9.5 Customer Service.....................................................................................................55 9.5.1 Description........................................................................................................55 9.5.2 Design Considerations......................................................................................55 9.6 License.....................................................................................................................55 9.6.1 Description........................................................................................................55 9.6.2 Technical Considerations..................................................................................61 Bibliography......................................................................................................................62 Warehouse Inventory Tracking System – Design Specifications 4 CMSC 435 Fall 2006 Collapse Team 1.Introduction 1.1 Purpose The purpose of this document is to provide a detailed design for the Maryland Task Force One Team’s (MDTF-1) Inventory System, entitled Warehouse Inventory Tracking System (WITS). This inventory system will be comprised of a Standalone Application, Website and Hardware. This document is primarily intended for developers of the system, which are the Collapse Team members. The WITS design specification will provide the design for requirements expressed in the requirement specification. 1.2 Scope The scope of this document entails a design for a solution (WITS) to address the needs expressed by MDTF-1. These needs were specified in the software requirement specification document, while this current document contains a design for the said requirement specification document. This document serves as a technical design of WITS that will be developed by students in the Software Engineering Collapse Team at the University of Maryland in fall 2006. This design specification will name and describe the design of the various parts that make up the Standalone Application Component. In addition, it will also describe the hardware (barcode scanner, printer, and label) component that will be used, and the website component and its various components. In addition, this document will describe how these various components fit together. 1.3 Audience The primary audiences for this document are members of the Collapse Team, all of whom will be involved in developing WITS at some stage. The secondary audience will be end users of the WITS solution and future developers of this solution, who might be involved in maintaining or extending this solution. Warehouse Inventory Tracking System – Design Specifications 5 CMSC 435 Fall 2006 Collapse Team 2.System Architecture Overview 2.1 Architecture WITS solution will be comprised of three components - Standalone Application, Web Server, and Barcode Hardware. The Standalone Application is a three- tiered client-server architecture, consisting of a presentation tier (GUI, Access Level Authentication Component), an application tier (Data Manipulation Logic Module, Data Communication Module), and a data tier (Data Synchronization Controller, Database Server). The server, which will host the data source for the Standalone Application and the website, will conform to the model-view-controller (MVC) architecture. A user of WITS will interact with GUI and first authenticate himself. GUI will send the authentication request to Access Level Authentication Component. Once the user has authenticated, GUI will call action methods directly from Data Manipulation Logic Module and retrieve processed data from it. Data Manipulation Logic Module will process requests from GUI and send responses to GUI. Data Communication Module stores and receives data in an organized form from Data Synchronization Controller. Data Synchronization Controller passes requests through to multiple Database Servers, ensuring that they are all updated. Database Server will hold raw data about inventory system. Warehouse Inventory Tracking System – Design Specifications 6 Graphical User Interface Data Manipulation Logic Module Data Communication Module Access Level Authentication Component Data Synchronization Controller Database Server Presentation Tier Application Tier Data Tier CMSC 435 Fall 2006 Collapse Team Data Repository: The data repository is a MySql database with several tables describing the data and the relationships. The database will be centralized in that there will be a server which will maintain a master set of all the data. To ensure clients has the most up to date data, clients can make request to central database requesting all changes to central database since the client last updated. In short, there will be replication of data in client and server. This is to ensure client can function in an offline mode. Constraint: Replication between server and clients (all changes with conflict resolution). Security Requirements: Access to standalone application and website will be limited (by password) by the rights levels of the users. Capacity Limitations: The amount of data that can be stored in the inventory can be particularly large. On a 32-bit system with MyISAM type tables in MySQL the limit is 4 GB of addressable space, which would essentially be a few million rows in database. WITS central database will contain at most a few million rows of data. Network Communications: The transmission in-between the client/server will get larger and larger if the client application requests a large number of items from central database. There might be a need to scale some queries to ensure that only the data needed for that current display is returned. There will be a few delays between action and display across network communication. 2.3.5 Development Method The approach used for this software design was transaction analysis1 within the framework of object-oriented design. This decision arose from the critical requirements specified by the customer. The key functionality that the customer desires is the ability to perform transactions such as check in and check out on inventory data. Data flow analysis did not provide many insights into the proper design, as the data flow for this application is simple. Most functionality involves only retrieving data from a data source, manipulating it, and committing it. Our data modeling approaches successfully captured the relationships within the data that this application uses, but these data relationships only revealed how each user transaction should manipulate the data, not how the software should be structured to process each transaction. Because of the transaction-centered nature of this application and the object-oriented language choice of C#, object- oriented design focusing on transaction analysis proved the most useful in developing the design for the application. 1 Schach, Stephen R., “Transaction Analysis,” Object-Oriented & Classical Software Engineering, Seventh Edition, McGraw-Hill, 2007 Warehouse Inventory Tracking System – Design Specifications 9 CMSC 435 Fall 2006 Collapse Team 3.Standalone Application 3.1 Introduction The standalone application is the center of the Warehouse Inventory Tracking System (WITS) project. It will provide all the features that WITS is capable of given a database. The standalone project is designed with six components, which are as follows: the access level authentication, the graphical user interface, the data manipulation logic, the data source interface, the synchronization control and the server interface. 3.2 Design Consideration The user requires shared database manipulation on a server with multiple clients. Clients will access the remote server via direct connection or the internet. Since the standalone application is required to work without a sustained connection to the remote server, a duplicate database will have to be a part of the client standalone application. As a result of having duplicate databases stored in the same format on both the client and server sides, the client and server will use the same application interface for each database. The application interface on both the client and server will be the same with differences only within the configuration, which will allow the client version to send data to a port and for a server to version to listen to a port. 3.3 Detailed Implementation 3.3.1 Graphical User Interface This section satisfies section 3.1 of the requirements specification with the exception of: 3.1.3 GUI does not support drag and drop feature. This section also satisfies section 3.5 with the exception of a flag for service. 3.3.1.1 Description The graphical user interface of the WITS standalone application will allow the user the following abilities:  Viewing Items: Main page allows for inventory and search  Add/Edit Items: Items can be added or edited through the GUI  Delete Items: Managers will have the ability to delete items from the inventory view  Checkout items to a personnel: A checkout panel will be available  Check-in items returned by a personnel: A check-in panel will be available  View to generate reports: A reports panel will be available Warehouse Inventory Tracking System – Design Specifications 10 CMSC 435 Fall 2006 Collapse Team  Views to amend the list of users of GUI and their capabilities: A Management Panel will allow users to be added, edited, or removed. 3.3.1.3 Components  Login: First screen accessible to user for logging into the WITS standalone application. o Username Box – There will be a text box to allow keyboard entry of the user’s login name o Password Box – There will be a text box that will hide input characters with uniform characters with no meaning so the user can login and keep the password private. o Forgot Password Button – Calls the function ForgotPass from the Data Manipulation Logic module to perform the password retrieving procedures. o Exit Button – Calls the Exit procedure for the dialog and Data Manipulation Logic module o Login Button – Calls the AuthUser function from the Data Manipulation Logic module passing in username and password and waits for a Boolean response  Main Screen/Inventory: First screen after successful login accessible to user. All program functions provided are accessible through the o Inventory list – The list will be populated by the Data Manipulation Logic module function PopulateList, who’s parameters come from the sort dropdown menu and search text box. By default, this returns the entire list sorted by name. o Sort field – Dropdown menu specifies which category to sort on, in ascending order. o Search field – Text box to enter in search criteria, a blank entry means to view all. o Search button – Refreshes the Inventory list view by calling PopulateList with new values in sort and search. The inventory will only be refreshed when the search button is clicked. o Management button – Opens the management dialog, and is only visible to managers and administrators Warehouse Inventory Tracking System – Design Specifications 11 CMSC 435 Fall 2006 Collapse Team o Add User button – Places a new (user) element in the User list, AddUser is called from the Action/Logic layer. o Go Back button – This button commits changes, using ModUser in the Action/Logic layer for all changed users.  Change/Reset Password: Located on the Login Page and Management Page. This view allows users and administrators to change user passwords. o Username box – Automatically filled with the username of the user to have a new password. o New Password box – Hidden text only appears in this box and allows entry for the new password. o Retype Password box - Hidden text only appears in this box and re- allows entry for the new password.  Add/Edit Items Panel: Located on the Main Page. Allows users to enter items or edit items in the inventory. This common view will allow entry for kits, bar-coded items, and items that are not tracked. o Name box – Allows viewing and editing of item names using the keyboard. When the value in the Name box changes, the item is Warehouse Inventory Tracking System – Design Specifications 14 CMSC 435 Fall 2006 Collapse Team retrieved from the Action/Logic layer using GetItem if it already exists o Type field – Allows users to view or choose existing types from a list or enter a new item using the keyboard. This list is the return of the function call to getTypes(). o Class field – Allows users to choose if items are normal items, untracked items, or containers. o Barcode box – Allows users to enter an item barcode via keyboard or barcode scanner o Container box –Shows the container the item is already in and does not allow the user to change it. o Location box –Shows where the item is and does not allow the user to change it o Code box – Allows users to enter a code for the item, the client already had codes in effect and this allows for a nice transition o Qty box – Allows for users to view or edit item quantity o Par Lvl box – Allows for users to view or edit par level amounts o Thumbnail – Shows the current stored picture for an item, this is stored with the item type in a field called Image o Browse button – Opens a dialog to search a computer system for image files o Load button – Loads the file specified in the File box to the item container, a LoadImage function is called from Action/Logic layer to perform this action. The thumbnail will be updated for the specific item that is being added using this panel. o File box – A text box that is filled from the browse button and dialog or manually from the keyboard to specify an image location o Contents list – again using the PopulateList function from the action logic layer, it is specified that the container must be of the current one in view. o Add Item button – opens a new Add/Edit dialog and specifies the current container as the container of the new item. o Finish button – Commits all changes using either the AddItem or ModItem function from the Data Manipulation Logic module depending if the item already existed. Warehouse Inventory Tracking System – Design Specifications 15 CMSC 435 Fall 2006 Collapse Team Warehouse Inventory Tracking System – Design Specifications 16 CMSC 435 Fall 2006 Collapse Team  Load Truck: Located on the Main Page. Loading the truck can only be done at a warehouse, telling the system that the truck now has that item. It is also set, that each laptop has an identifier, and is in charge of each truck outside of the warehouse. o Truck name box – Allows keyboard entry of the truck identifier to be used for tracking. o Item List – The list is populated by entering barcode items and building an array. o Barcode Box – Allows entry from the keyboard or barcode scanner for the next item to enter. o Add Item button –The item is retrieved from the Data Manipulation Logic module using GetItem with the barcode as a parameter and adding it to the Item List array. o Finish button – Commits changes using ModItem to all the items in the Item List changing the location to the truck. Warehouse Inventory Tracking System – Design Specifications 19 CMSC 435 Fall 2006 Collapse Team  Unload Truck: Located on the Main Page. Much like check-in, this dialog will allow a truck’s contents to be placed back into the warehouse. o Item List – The list is populated by entering barcode items and building an array. o Barcode box – Allows entry from the keyboard or barcode scanner for the next item to enter o Add Item button –The item is retrieved from the Action/Logic layer using GetItem using the barcode as a parameter and adding it to the Item List array. o Finish button – Commits changes using ModItem to all the items in the Item List changing the location to the warehouse. Warehouse Inventory Tracking System – Design Specifications 20 CMSC 435 Fall 2006 Collapse Team  Reports: Located on the Main Page. As specified in the requirements; the client wants to be able to generate reports for FEMA at any time, before or after returning to the warehouse. The application will generate web pages to be printed out as FEMA forms. The following forms will be generated: Total Equipment Inventory Report, Out of Service List, Preventative Maintenance Due List, Kit List with Inventory, Overdue list, Equipment Deployment List. Each of the reports will have options that will be on the generated web page to give different views. A popup window will ask what to name the report file and where on disk the file will be stored. o Total Equipment Inventory Report button – Calls the GenerateReport function from the Data Manipulation Logic module passing in a parameter specifying the type of report. o Out of Service List button – Calls the GenerateReport function from the Action/Logic layer passing in a parameter specifying the type of report. o Preventative Maintenance Due List button – Calls the GenerateReport function from the Action/Logic layer passing in a parameter specifying the type of report. o Kit List with Inventory button – Calls the GenerateReport function from the Action/Logic layer passing in a parameter specifying the type of report. o Overdue list button – Calls the GenerateReport function from the Action/Logic layer passing in a parameter specifying the type of report. o Equipment Deployment List button – Calls the GenerateReport function from the Action/Logic layer passing in a parameter specifying the type of report. o Close button – Closes the dialog and returns to the main screen. Warehouse Inventory Tracking System – Design Specifications 21 CMSC 435 Fall 2006 Collapse Team stored by the GUI to the rest of the application. The GUI Module should not contain any business logic, the interface is designed for the GUI to collect data into a few encapsulating GUI objects to transmit to the DML module. The DML module then performs data integrity and semantic integrity error checks on the received data. Should the data fail the checks, the DML module notifies the GUI appropriately. Should the checks pass, the DML module translates the raw data from the GUI into the appropriate application data model objects, which are data objects specifically used by the application for further processing (see Application Data Model Diagrams), and passes the data along to the DataComm Module. The DML module will handle the returned data from the DataComm Module. The DML module will expect the returned data be in the form of the application data model. Except for any logic required for converting between the raw data from the database to the application data models, the DataComm Module should not contain any business logic. As a result, the DML module will have to perform data integrity and semantic integrity error checks on the received data as it had done for the GUI’s raw data. Should the data fail the checks, this module notifies the GUI appropriately. Should the checks pass, this module translates the data from the application data model to the GUI objects for ready display. 3.3.3.2 Components I. GUI Adapter i. Description The GUI Adapter minimizes the Data Manipulation Logic Module’s (DML) dependencies on the GUI Module. The dependences that the DML will normally have connecting directly to the GUI Module are carried into the GUI Adapter. The GUI Adapter consists of a data mapping between the raw data stored in GUI data objects and the application data models. When the GUI sends data stored in GUI objects to this adapter via the exposed interface, the GUI Adapter immediately converts the GUI objects into objects defined by the application data model and forwards them along to the Data Translation Layer. The GUI Adapter will also be able to convert these objects back into GUI objects ready for display without any further involvement of business logic. ii. Input  Source: GUI Module  Format: GUI Objects  Association: Each GUI request will call the GUI Adapter. iii. Output  Destination: GUI Module  Format: GUI Objects  Association: Each GUI Request will in turn require the GUI Adapter to return GUI Objects. iv. Dependencies Warehouse Inventory Tracking System – Design Specifications 24 CMSC 435 Fall 2006 Collapse Team  Data Translation Module  GUI Data Model  Application Data Model v. Error Handling  Returns exceptions from the Data Translation Layer to GUI. vi. Exposed Interface Please see the section Application Data Models for descriptions of custom data types. List<Item> populateList(string sort, string search, string searchField, ulong page, ulong itemsPerPage, out ulong maxpage) Returns a paged List of Items, starting from the specified page and containing up to itemsPerPage elements. Stores the number of pages of results into maxpage. If search is not null or empty, only items that contain information matching the search string are included in the list. If sort is not null or empty, the list is sorted in ascending order by the field named in sort. List<User> userList() Returns a List containing all users. bool authUser(string username, string password) Returns true if authentication succeeds, false otherwise. bool forgotPassword(string username, string barcode, string firstName, string lastName) Returns true if all information provided matches an existing user, false otherwise. bool setPassword(string username, string newPassword) Returns true if the password for the user identified by username is successfully set to newPassword, false otherwise. Item getItem(ulong id, ulong installationID) Returns the Item with the given id and installationID. If no item exists with the given id, then return null. List<Item> getItemsInKit(ulong id, ulong installation_id) Returns a List of Items inside the kit with the given id and installation_id. An empty kit would cause an empty list to be returned. If no kit exists with the given id, then return null. bool addItem(Item item) Returns true if the item is successfully added, false otherwise. bool editItem(Item item) Returns true if item is updated, false otherwise. bool deleteItem(Item item) Returns true if item is successfully removed from the data source. User getUser(string username) Returns the User with the given username, or null if no User exists with the given username. bool addUser(User user) Returns true if the newUser is successfully added, false otherwise. bool modUser(User changedUser) Returns true if the changedUser is updated, false otherwise. Warehouse Inventory Tracking System – Design Specifications 25 CMSC 435 Fall 2006 Collapse Team bool deleteUser(string username) Returns true if the User with the given username is successfully deleted, false otherwise. List<BarcodedItemType> getTypes() Returns a List of item types (e.g. air conditioning units, generators) bool addType(BarcodedItemType type) Returns true if the type is successfully added, false otherwise. bool editType(BarcodedItemType type) Returns true if the type is successfully updated, false otherwise. bool deleteType(BarcodedItemType type) Returns true if the type is successfully deleted, false otherwise. PermissionLevel getPermissionLevel(string userLevel) Returns a PermissionLevel object containing the permission flags for the given userLevel. List<Item> getAllItems (string searchField, string search) Returns an unpaged List of Items. If search is not null or empty, only items that contain information in searchField matching the search string are included in the list. bool LoadTruck(string TruckName, List<Item> Items) Updates all given Items to having been loaded onto TruckName. bool UnloadTruck(List<Item> Items) Updates all given Items to having been unloaded from a truck back into the warehouse. bool CheckOutItems (string UserBarcode, List<Item> Items) Updates all given Items to having been checked out to the given UserBarcode. bool CheckInItems (List<Item> Items) Updates all given Items to having been checked back in and onto a truck. bool GenerateReport (string ReportType, FileStream outputFile) Returns true if the report is successfully written to outputFile, false otherwise. If false, no guarantees are made regarding the integrity of outputFile after execution. BarcodedItem getItem(string barcode) Returns the Item with the given barcode, or null if no Item exists with the given barcode. User resolveUser(string LastName, string FirstName, string Barcode) Returns the User matching all of the given information. All parameters are optional – a null parameter means no information is provided for that field. If no users match all of the given information, or multiple users match all of the given information, then the resolution failed and return false. II. Data Translation Layer i. Description Warehouse Inventory Tracking System – Design Specifications 26 CMSC 435 Fall 2006 Collapse Team DataCommAdapter.editItem(item) Function: bool deleteItem( Item item) Process: Verify that the currently logged in user has permission to delete items. DataCommAdapter.deleteItem(item) Function: User getUser( string username) Process: DataCommAdapter.getUser(username) Function: bool addUser( User user) Process: Verify that the currently logged in user has permission to add users. DataCommAdapter.addUser(user) Function: bool modUser( User changedUser) Process: Verify that the currently logged in user has permission to edit users, or the changedUser is the currently logged in user. DataCommAdapter.modifyUser(changedUser) Function: bool deleteUser( string username) Process: Verify that the currently logged in user has permission to delete users. DataCommAdapter.getUser(username) If a user with the specified username cannot be found, then return false. DataCommAdapter.deleteUser(user) Function: List < BarcodedItemType > getTypes() Process: DataCommAdapter.getTypes() Function: bool addType( BarcodedItemType type) Process: Verify that the currently logged in user has permission to add items. DataCommAdapter.addType(type) Function: bool editType( BarcodedItemType type) Process: Verify that the currently logged in user has permission to edit items. DataCommAdapter.editType(type) Function: bool deleteType( BarcodedItemType type) Process: Verify that the currently logged in user has permission to delete items. DataCommAdapter.deleteType(type) Warehouse Inventory Tracking System – Design Specifications 29 CMSC 435 Fall 2006 Collapse Team Function: PermissionLevel getPermissionLevel( string userLevel) Process: DataCommAdapter.getPermissionLevels() Search through PermissionLevels for one with title = userLevel. If one is found, return it, otherwise, return null. Function: List < Item > getAllItems ( string searchField, string search) Process: DataCommAdapter.listAllItems(search, searchField) Function: bool LoadTruck( string TruckName, ref List < Item > Items) Process: Verify that the currently logged in user has permission to check in/check out items. For each item in Items: DataCommAdapter.getItem(id, installationID) Check to make sure the item is currently in the warehouse. Change the item location to TruckName. DataCommAdapter.editItem(item) If all items are successfully edited, then return true, otherwise return false along with the items that failed. Function: bool UnloadTruck(ref List < Item > Items) Process: Verify that the currently logged in user has permission to check in/check out items. For each item in Items: DataCommAdapter.getItem(id, installationID) Check to make sure item is currently on a truck. Change the item location to warehouse. DataCommAdapter.editItem(item) If all items are successfully edited, then return true, otherwise return false along with the items that failed. Function: bool CheckOutItems ( string UserBarcode, List < Item > Items) Process: Verify that the currently logged in user has permission to check in/check out items. For each item in Items: DataCommAdapter.getItem(id, installationID) Check to make sure item is not already checked out. Record the checkout to UserBarcode. DataCommAdapter.editItem(item) If all items are successfully edited, then return true, otherwise return false along with the items that failed. Function: bool CheckInItems ( List < Item > Items) Process: Verify that the currently logged in user has permission to check in/check out items. For each item in Items: DataCommAdapter.getItem(id, installationID) Check to make sure item is currently checked out. Record the check in. DataCommAdapter.editItem(item) Warehouse Inventory Tracking System – Design Specifications 30 CMSC 435 Fall 2006 Collapse Team If all items are successfully edited, then return true, otherwise return false along with the items that failed. Function: bool GenerateReport ( string ReportType, FileStream outputFile) Process: TBD: Client has not provided specific details about types, contents, or formats of reports. Will require calls to DataCommAdapter.listAllItems(search, searchField) Function : BarcodedItem getItem( string barcode) Process: DataCommAdapter.listAllItems(barcode, “barcode”) Function: User resolveUser( string LastName, string FirstName, string Barcode) Process: Determine which parameters have information provided and have the data source search based on one of those parameters. Locally search through the results for a match that fits all provided information. If exactly one User is found that matches all provided information, then return it, otherwise, return null. III. DataComm Adapter i. Description The DataComm Adapter exists to minimize the Data Manipulation Logic module’s dependencies on the specific DataComm Module. The DataComm Adapter consists of a process mapping between processes in the Data Translation Layer (DTL) to the DataComm interface. When a DTL process (e.g. add an item, check-out an item, delete a user) runs and requires communication with the server, the DataComm Adapter expects to be given all relevant data in objects defined by the application data model. This adapter reduces the business process down to the atomic transactions that need to occur, and initiates them with the DataComm Module. If the DataComm Module requires data along with a transaction request, this adapter provides the relevant data in objects defined by the application data model to the DataComm Module. If a DTL process expects return data from the server, the DataComm Adapter expects the data also in objects defined by the application data model from the DataComm Module. ii. Input  Source: Data Translation Module  Format: Application Data Model Objects  Association: Each Data Translation Layer process with error free data is passed through to the DataComm Adapter. iii. Output  Destination: Data Translation Module  Format: Application Data Model Objects Warehouse Inventory Tracking System – Design Specifications 31 CMSC 435 Fall 2006 Collapse Team application can identify the error using the internal error code in case the error is non-fatal vi. Error Checks and Error Codes Function: List < Item > populateList( string sort, string search, string searchField, ulong page, ulong itemsPerPage, out ulong maxpage) Error Checks: sort must contain a sortable field. If search is supplied, searchField must also be supplied. If searchField is supplied, it must contain a searchable field. page must be a positive integer. itemsPerPage must be a positive integer. Function: bool authUser( string username, string password) Error Checks: username cannot be null or empty. password cannot be null or empty. Function: bool forgotPassword( string username, string barcode, string firstName, string lastName) Error Checks: All fields must be supplied. Function: bool setPassword( string username, string newPassword) Error Checks: username cannot be null or empty. password cannot be null or empty. TBD: Client has not provided details on password security requirements Function: List < Item > getItemsInKit( ulong id, ulong installation_id) Error Checks: The item defined by id must exist and must be a kit. Function: bool addItem( Item item) Error Checks: name cannot be empty. If item is a BarcodedItem: barcode cannot be empty. status cannot be empty. At least one of location or equipmentManager must be provided. isKit must be provided. If item is an AggregateItem: parLevel must be a non-negative integer. amount must be a non-negative integer. Function: bool editItem( Item item) Error Checks: SQL IDs must be provided (non-zero). name cannot be empty. Warehouse Inventory Tracking System – Design Specifications 34 CMSC 435 Fall 2006 Collapse Team If item is a BarcodedItem: barcode cannot be empty. status cannot be empty. At least one of location or equipmentManager must be provided. isKit must be provided. If item is an AggregateItem: parLevel must be a non-negative integer. amount must be a non-negative integer. Function: bool deleteItem( Item item) Error Checks: SQL IDs must be provided (non-zero). Function: User getUser( string username) Error Checks: username cannot be null or empty. Function: bool addUser( User user) Error Checks: All member variables must be provided and non-empty except for SQL IDs. Function: bool modUser( User changedUser) Error Checks: SQL IDs must be provided (non-zero). All member variables must be provided and non-empty. Function: bool addType( BarcodedItemType type) Error Checks: name cannot be empty. parLevel must be a non-negative integer. amount must be a non-negative integer. Function: bool editType( BarcodedItemType type) Error Checks: SQL IDs must be provided (non-zero). name cannot be empty. parLevel must be a non-negative integer. amount must be a non-negative integer. Function: bool deleteType( BarcodedItemType type) Process: SQL IDs must be provided (non-zero). Function: PermissionLevel getPermissionLevel( string userLevel) Error Checks: userLevel cannot be null or empty. Function: List < Item > getAllItems ( string searchField, string search) Error Checks: Warehouse Inventory Tracking System – Design Specifications 35 CMSC 435 Fall 2006 Collapse Team If search is supplied, searchField must also be supplied. If searchField is supplied, it must contain a searchable field. Function: bool LoadTruck( string TruckName, ref List < Item > Items) Error Checks: TruckName must be registered as a location. All items in Items must currently be in the warehouse. Function: bool UnloadTruck(ref List < Item > Items) Error Checks: All items in Items must currently be on a truck. Function: bool CheckOutItems ( string UserBarcode, List < Item > Items) Error Checks: All items in Items must not be already checked out. Function: bool CheckInItems ( List < Item > Items) Error Checks: All items in Items must currently be checked out. Function: bool GenerateReport ( string ReportType, FileStream outputFile) Error Checks: TBD: Client has not provided specific details about types, contents, or formats of reports. Function : BarcodedItem getItem( string barcode) Error Checks: barcode cannot be null or empty. 3.3.3.3 Data Manipulation Logic Components Diagram Warehouse Inventory Tracking System – Design Specifications 36 GUI Adapter To GUI Module Data Translation Layer DataComm Adapter Error Checking Layer To DataComm Module CMSC 435 Fall 2006 Collapse Team 3.3.5.4 Dependencies  Data Communications Module  Database Server  Remote Data Synchronization Controller 3.3.5.5 Error Handling Grouping queries by add, edit, and delete, and then executing them in that order, chronologically, resolve all conflicts from transactions. This takes account for the situation where two offline users make changes, a delete before an edit, and then commit both to the remote server. If done in chronological order only, the second request would try to edit the deleted item, and would fail. 3.3.5.6 Exposed Interface  The following document type definition will be the format for the XML Queries that are transmitted between the local machine and the remote server. The interface will be listening on port 4444 and will only execute queries formatted according to the DTD. This is the DTD format: <!ELEMENT WITSCOMM(SERVERRECIEVE|LOCALRECIEVE|TRANSMIT)> <!ELEMENT SERVERRECIEVE(SERVERRESULT+)> <!ELEMENT WITSCOMM (TRANSMIT|RECEIVE)> <!ELEMENT TRANSMIT (QUERYLIST)> <!ELEMENT RECIEVE (RESULTLIST)> <!ELEMENT RESULTLIST (RESULT+)> <!ELEMENT QUERYLIST (QUERY+)> <!ELEMENT QUERY (REQUESTID,(LOGINREQUEST|RETRIEVEITEM|RETRIEVEITEMLIST| RETRIEVEUSER|RETRIEVEUSERLIST<!--|GETLOCATIONS-->))> <!ELEMENT RESULT (REQUESTID,(USER|USERLIST|ITEM|ITEMLIST))> <!ELEMENT LOGINREQUEST (USERNAME,PASSWORD)> <!ELEMENT RETRIEVEITEM (ITEMID?,BARCODE?)> <!ELEMENT RETRIEVEITEMLIST (TYPEID?,USERID?,IDLIST?,LOCATION?,KITID?,NAME?)> <!ELEMENT RETRIEVEUSER (ID?,FIRSTNAME?,LASTNAME?,BARCODE?)> <!ELEMENT RETRIEVEUSERLIST (FIRSTNAME?,LASTNAME?,IDLIST?,BARCODE?)> <!ELEMENT LOCATION (LOCATIONID|NAME),(LOCATIONID|NAME)?)> <!ELEMENT TYPEID (DUALID)> <!ELEMENT USERID (DUALID)> <!ELEMENT ITEMID (DUALID)> <!ELEMENT LOCATIONID (DUALID)> <!ELEMENT KITID (ITEMID)> <!ELEMENT NAME (#PCDATA)> <!ELEMENT LOGINRESULT (SUCCESS,RIGHTS?)> <!ELEMENT USERLIST (USER+)> Warehouse Inventory Tracking System – Design Specifications 39 CMSC 435 Fall 2006 Collapse Team <!ELEMENT USER (USERID?,USERNAME?,FIRSTNAME?,LASTNAME?,PASSWORD?,BARCODE?,RIGHTS?)> <!ELEMENT USERNAME (#PCDATA)> <!ELEMENT FIRSTNAME (#PCDATA)> <!ELEMENT LASTNAME (#PCDATA)> <!ELEMENT PASSWORD (#PCDATA)> <!ELEMENT RIGHTS (ADDDATA,EDITDATA,ADDUSER,EDITUSER,CHECK)> <!ELEMENT ADDDATA (BOOLEAN)> <!ELEMENT EDITDATA (BOOLEAN)> <!ELEMENT ADDUSER (BOOLEAN)> <!ELEMENT EDITUSER (BOOLEAN)> <!ELEMENT CHECK (BOOLEAN)> <!ELEMENT IDLIST (DUALID+)> <!ELEMENT DUALID (INSTID,ID)> <!ELEMENT INSTID (#PCDATA)> <!ELEMENT ID (#PCDATA)> <!ELEMENT BARCODE (#PCDATA)> <!ELEMENT USERNAME (#PCDATA)> <!ELEMENT PASSWORD (#PCDATA)> <!ELEMENT SUCCESS (BOOLEAN)> <!ENTITY % BOOLEAN "(TRUE|FALSE)"> <!ELEMENT ITEM (ITEMID?, BARCODE?, NAME?, TYPEID?, KITID?, THUMBNAIL?, AMOUNT?, PAR?, CHECKLOCATION?, CHECKUSER?)> <!ELEMENT CHECKLOCATION (LOCATION,TIME)> <!ELEMENT CHECKUSER (USER,TIME)> <!ELEMENT THUMBNAIL (#PCDATA)> <!ELEMENT AMOUNT (#PCDATA)> <!ELEMENT PAR (#PCDATA)> <!ELEMENT NAME (#PCDATA)> <!-------------------------------- <!ELEMENT WITSCOMM(SERVERRECIEVE|LOCALRECIEVE|TRANSMIT)> <!ELEMENT SERVERRECIEVE(SERVERRESULT+)> <!ELEMENT SERVERRESULT(NUMBER,TRUE|FALSE)> <!ELEMENT LOCALRECIEVE(LOCALRESULT+)> <!ELEMENT LOCALRESULT(NUMBER,TRUE|FALSE|ID|USERLIST|ITEMLIST)> <!ELEMENT TRANSMIT (USERNAME?,PASSWORD?,INSTID,TASKLIST)> <!ELEMENT TASKLIT (TASK*,QUERY*)> <!ELEMENT TASK (TIMESTAMP?,TYPE,NUMBER,ITEM|USER|KIT)> <!ELEMENT TYPE (ADD|EDIT|DELETE)> <!ELEMENT QUERY (NUMBER,SQL)> <!ELEMENT SQL (#PCDATA)> <!ELEMENT KIT (ITEM, ITEMLIST)> <!ELEMENT ITEMLIST (ITEM*)> <!ELEMENT USERLIST (USER*)> <!ELEMENT USER (ID?, USERNAME?, FIRSTNAME?, LASTNAME?, BARCODE?, PASSWORD?,PERMISSIONS?)> <!ELEMENT USERNAME (#PCDATA)> Warehouse Inventory Tracking System – Design Specifications 40 CMSC 435 Fall 2006 Collapse Team <!ELEMENT FIRSTNAME (#PCDATA)> <!ELEMENT LASTNAME (#PCDATA)> <!ELEMENT PASSWORD (#PCDATA)> <!ELEMENT PERMISSIONS (PERMISSIONLIST)> <!ELEMENT PERMISSIONLIST (ADDDATA,EDITDATA,ADDUSER,EDITUSER,CHECK)> <!ELEMENT ADDDATA (BOOLEAN)> <!ELEMENT EDITDATA (BOOLEAN)> <!ELEMENT ADDUSER (BOOLEAN)> <!ELEMENT EDITUSER (BOOLEAN)> <!ELEMENT CHECK (BOOLEAN)> <!ELEMENT ITEM (ID?, BARCODE?, NAME?, TYPEID?, KITID?, CATEGORYID?, THUMBNAIL?, AMOUNT?, PAR?)> <!ELEMENT ID (#PCDATA)> <!ELEMENT BARCODE (#PCDATA)> <!ELEMENT NAME (#PCDATA)> <!ELEMENT TYPEID (#PCDATA)> <!ELEMENT KITID (#PCDATA)> <!ELEMENT CATEGORYID (#PCDATA)> <!ELEMENT THUMBNAIL (#PCDATA)> <!ELEMENT AMOUNT (#PCDATA)> <!ELEMENT PAR (#PCDATA)> This is an example add item query: <WITSCOMM> <TRANSMIT> <QUERYLIST> <QUERY> <REQUESTID>1</REQUESTID> <ADDITEM> <ITEM> <ITEMID> <DUALID> <INSTID>1</INSTID> </DUALID> </ITEMID> <NAME>newonehaha</NAME> </ITEM> </ADDITEM> </QUERY> </QUERYLIST> </TRANSMIT> </WITSCOMM> This is an example list items query which gets all items in kit with id 2,2: <WITSCOMM> <TRANSMIT> <QUERYLIST> <QUERY> <REQUESTID>1</REQUESTID> Warehouse Inventory Tracking System – Design Specifications 41 CMSC 435 Fall 2006 Collapse Team 4.2 Design Considerations Making duplicate databases should be easy. Design should allow for efficient synching with multiple versions of the database. Data access/edit/deletion within the database should be accurate and efficient. The database will have to maintain a universally consistent basis of tracking changes. 4.3 Detailed Implementation 4.3.1 Database Type The database used by the WITS standalone application will be stored as a MySQL database. Each client will have unique machine identification numbers on installation to provide the remote database a way to incorporate MySQL data with identical MySQL identification numbers assigned to the data by the client application. 4.3.2 Transaction Logs Both the local and remote databases will maintain a transaction log with timestamps of each query/transaction that was made with the database. The timestamps used within the transaction database will be maintained by a universally consistent outside source. If timestamps varied due to multiple sources, transaction logs will have inconsistencies depending on where the timestamps were taken from. For the timestamp issue, it is suggested that an outside source be used, however it may not be possible because of connectivity issues. Add, edit, and delete transactions are recorded with a timestamp and saved as the log. That timestamp will be the cut off point for what to update the database with. 4.3.3 Database Schema This section satisfies the requirements specification section 3.2. Below is a list of the MySQL database entities along with their corresponding attributes. inst_id ( inst_id int PRIMARY KEY (inst_id) ) type ( inst_id int type_id int name varchar par_lvl int PRIMARY KEY (type_id), FOREIGN KEY (inst_id) REFERENCES inst_id(inst_id) ) Warehouse Inventory Tracking System – Design Specifications 44 CMSC 435 Fall 2006 Collapse Team rights ( rights_id int name varchar add_data enum (‘true’, ‘false’) edit_data enum (‘true’, ‘false’) add_user enum (‘true’, ‘false’) edit_user enum (‘true’, ‘false’) check_in_out ENUM (‘true’, ‘false’) PRIMARY KEY (rights_id) ) user( inst_id int user_id int barcode varchar username varchar password varchar f_name varchar l_name varchar rights_id int PRIMARY KEY (user_id,inst_id), FOREIGN KEY (inst_id) REFERENCES inst_id(inst_id) FOREIGN KEY (rights_id) REFERENCES rights(rights_id) ) item ( inst_id int item_id int type_inst_id int type_id int name varchar barcode varchar par_lvl int in_serv_date date service_intr int status ENUM('AVAILABLE','LOST','BROKEN'), FOREIGN KEY (inst_id) REFERENCES inst_id(inst_id) FOREIGN KEY (type_inst_id,type_id) REFERENCES type(inst_id,type_id) PRIMARY KEY (item_id,inst_id) ) in_kit ( item_inst_id int item_id int kit_inst_id int kit_id int amount int par_lvl int Warehouse Inventory Tracking System – Design Specifications 45 CMSC 435 Fall 2006 Collapse Team PRIMARY KEY (item_inst_id,item_id,kit_inst_id,kit_id) FOREIGN KEY (kit_inst_id, kit_id) REFERENCES item(inst_id,item_id) FOREIGN KEY (item_inst_id,item_id) REFERENCES item(inst_id,item_id) ) in_warehouse_nb_nk ( inst_id int item_id int amount int PRIMARY KEY (inst_id,item_id), FOREIGN KEY (inst_id,item_id) REFERENCES item(inst_id,item_id) ) is_kit( inst_id int item_id int PRIMARY KEY (inst_id,item_id) FOREIGN KEY (inst_id,item_id) REFERENCES item(inst_id,item_id) ) location( inst_id int location_id int name varchar PRIMARY KEY (location_id,inst_id) FOREIGN KEY (inst_id) REFERENCES inst_id(inst_id) ) location_check( item_inst_id int item_id int location_inst_id int location_id int timestamp timestamp NOT NULL, in_out enum('IN','OUT') PRIMARY KEY (item_inst_id,item_id,location_inst_id,location_id,timestamp,in_out) FOREIGN KEY (location_inst_id,location_id) REFERENCES location (inst_id,location_id) FOREIGN KEY (item_inst_id,item_id) REFERENCES item (inst_id,item_id) ) user_check( item_inst_id int item_id int user_inst_id int user_id int timestamp timestamp in_out enum('IN','OUT') PRIMARY KEY (item_inst_id,item_id,user_inst_id,user_id,timestamp,in_out), Warehouse Inventory Tracking System – Design Specifications 46 CMSC 435 Fall 2006 Collapse Team 4.Hardware 5.1 Introduction The barcode scanner is connected to the computer. After scanning a barcode which holds reference data for the item or employee, the information is transferred to the computer as ASCII text. 5.2 Design Consideration The barcode label must be long enough to contain all information needed for the database. The barcode printer has to be portable in order to be moved from the warehouse to the site. The barcode scanner has to transmit the information received from the barcode to the computer such that it can be interpreted as ASCII text. 5.3 Detailed Implementation This section satisfies the requirements specification section 4. 5.3.1 Barcode scanner interface The scanner will be used to retrieve the information stored on the barcode. This data is ASCII text, and like keyboard input appears where the cursor is located. The program will process the information and the appropriate values will be fed into the database. Current model: Symbol DS3478-SF 5.3.2 Barcode Labels Barcode labels will be encoded with PDF-417 symbology. This enables up to 1800 ASCII characters to be stored on a single label. The labels will store a unique id for employees and items (example: AIR_CONDITION_UNIT). When a label is scanned, this id is used to find the corresponding item in the database. (see section 3.3.2.3). 5.3.3 Barcode Printers Using the software provided, the printer should print new labels or reprint old or damaged labels. Warehouse Inventory Tracking System – Design Specifications 49 CMSC 435 Fall 2006 Collapse Team Current model: Datamax E-4203 Printer Website 6.1 Introduction The website will serve as a view of the current database. A proper username/password combination is needed in order to login. Authentication of login will be checked against the current user records, stored in a MySQL database. The main page will show a view of the current database, similar to the standalone application (see section 3). The user will be allowed to do simple sorting and searching. Clicking on kits will open a pop-up window showing its contents. 6.2 Design Consideration The views of the website and allowable functions have to correspond to the proper user access level. The website must contain the most updated version of the inventory. The website will only read from the database. 6.3 Detailed Implementation This section satisfies requirements specification section 5 with the exception of: The client has changed their specifications for the website. 6.3.1 User Access Level All users able to access the website will have the same access level. The website will only allow users with a user name and password to view the database. Users with a name and password are General Users, Managers, and Administrators. Non-Users will not be able to use the website. 6.3.2 Interface with Server The Website will be hosted on the server machine with the master database (the remote server database for all clients). It will interact directly with the database without any dependence on the standalone application. All interactions with the database will be read only; the website will not be able to modify the data stored in the database. Warehouse Inventory Tracking System – Design Specifications 50 CMSC 435 Fall 2006 Collapse Team 6.3.3 Login The user login system will have local access to the master database, where all the user names and passwords are stored. The login process will just check if the user name and password used for login exists within the database. 6.3.4 Graphical User Interface  TBD: Website development in the near future. ETA: 10/31/06. The website will be written in PHP and will be hosting on the remote master server. It will be hosted in IIS on the Windows server. Include screenshots and describe them from the low-fi model Warehouse Inventory Tracking System – Design Specifications 51 CMSC 435 Fall 2006 Collapse Team 7.Packaging and Deployment 9.1 Introduction Standalone application will be put on a CD in addition to all the software required to run the standalone (MySQL database,.NET framework and JRE if needed) and a version of the online database. A version of database will be included to ensure that the user does not idle while the local cache is being created. Upon installation user will be able to select either a client or server install. Client install will install the standalone application, the request/synch service which will only listen for requests from the local machine, and the MySQL database (,.NET framework and JRE if needed). A server install will work like a client install but listen for requests on the local machine as well as the external world. The WITS installation CD along with documentation that will be delivered with this product will include a user manual, quick start guide and a license. 9.2 User Manual 9.2.1 Description To provide end user with technical support, the development team will include a printed manual. The manual will include a table of contents, index, an explanation of the WITS solution and how to use it, and a troubleshooting section. To ensure ease of understanding the manual should include visual representations where appropriate. Lastly the manual should be easily understood by users who will simply use the system. 9.2.2 Design Considerations Manual will be printed in black and white, when appropriate provide color for visual representation. 9.3 Quick Start Guide 9.3.1 Description Quick-Start Guide will be targeted for an end user who wants a quick overview of how to install and run standalone application. Warehouse Inventory Tracking System – Design Specifications 54 CMSC 435 Fall 2006 Collapse Team 9.3.2 Design Considerations Quick-Start Guide will be printed in black and white, when appropriate provide color for visual representation. 9.4 Help Documents 9.4.1 Description Provide a help section for every interaction of the GUI. 9.4.2 Design Considerations Help section for each GUI screen be described in language which can be understood by novice users of the interface. 9.5 Customer Service 9.5.1 Description Customer service will be provided for the client via telephone and e-mail. 9.5.2 Design Considerations E-mail addresses will be included in the help manual, allowing for the client to contact any team member with questions about WITS. 9.6 License 9.6.1 Description Please find below a description of WITS license: This software is distributed under the GNU General Public License, provided below (from http://www.gnu.org/licenses/licenses.html). GNU GENERAL PUBLIC LICENSE Version 2, June 1991 Warehouse Inventory Tracking System – Design Specifications 55 CMSC 435 Fall 2006 Collapse Team Copyright (C) 1989, 1991 Free Software Foundation, Inc. 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. Preamble The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. This General Public License applies to most of the Free Software Foundation's software and to any other program whose authors commit to using it. (Some other Free Software Foundation software is covered by the GNU Library General Public License instead.) You can apply it to your programs, too. When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things. To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights. These restrictions translate to certain responsibilities for you if you distribute copies of the software, or if you modify it. For example, if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights. We protect your rights with two steps: (1) copyright the software, and (2) offer you this license which gives you legal permission to copy, distribute and/or modify the software. Also, for each author's protection and ours, we want to make certain that everyone understands that there is no warranty for this free software. If the software is modified by someone else and passed on, we want its recipients to know that what they have is not the original, so that any problems introduced by others will not reflect on the original authors' reputations. Finally, any free program is threatened constantly by software patents. We wish to avoid the danger that redistributors of a free program will individually obtain patent licenses, in effect making the program proprietary. To prevent this, we have made it clear that any patent must be licensed for everyone's free use or not licensed at all. Warehouse Inventory Tracking System – Design Specifications 56 CMSC 435 Fall 2006 Collapse Team code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. If distribution of executable or object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place counts as distribution of the source code, even though third parties are not compelled to copy the source along with the object code. 4). You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. 5). You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Program or works based on it. 6). Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License. 7). If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all. For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program. If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply and the section as a whole is intended to apply in other circumstances. Warehouse Inventory Tracking System – Design Specifications 59 CMSC 435 Fall 2006 Collapse Team It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system, which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice. This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License. 8). If the distribution and/or use of the Program is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Program under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License. 9). The Free Software Foundation may publish revised and/or new versions of the General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation. 10). If you wish to incorporate parts of the Program into other free programs whose distribution conditions are different, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally. NO WARRANTY 11). BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE Warehouse Inventory Tracking System – Design Specifications 60 CMSC 435 Fall 2006 Collapse Team ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. 12). IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. END OF TERMS AND CONDITIONS 9.6.2 Technical Considerations License will be printed in black and white. WITS user should be encouraged to read license before using installing and using WITS. Warehouse Inventory Tracking System – Design Specifications 61