【正文】 rmation they need quickly. Not to mention the CPU cycles wasted searching through all the tables for that data. Local Data StructuresTemporary variables which hold the data from the form objects while they are validated and then converted for use in appropriate stored procedures. Performance IssuesSearching through potentially tens of thousands of fields in a database can not only be problematic for the user – who has to wait for the results – but also for the machine itself that hosts the database. The machine has other processes and daemons running on it so the search on the database needs to take care not to hog all the available CPU cycles. Design ConstraintsNone at this time. Description for Component Display Results Component Display Results PSPECMany of the ponents listed above (View Schedules, Search Schedules, View Audit Trail) require that data be displayed on the screen to give the user feedback and information needed in order to successfully plete their task at hand. This ponent allows for data retrieved from the database to be displayed on the screen in an organized way so that it bees useful data to the user. Component Display Results Processing Detail Interface DescriptionInputs to this system will be entries retrieved from the database. These entries are returned based on the queries formed from the Read In Data ponent, described in section . The input can be vary greatly: one inspection scheduled with only an address and date to months worth of inspection schedules.The output this ponent will deliver is data formatted in such a way that provides information to the user. For instance, returning just an address and building type means nothing but when organized in a manner that is consistent with the rest of the system – placement of correct labels – then the data bees information. Algorithmic Modelponent DisplayResults。 Restrictions/LimitationsThis ponent needs to be able to work in multiple junctions within our system. Thus, making it’s interfaces and inner functions too specific will slow down the team when implementing it in multiple places throughout our system. Local Data StructuresA temporary string object may be instantiated to store entries which cannot be processed on the screen at the moment. Performance IssuesNone at this time. Design ConstraintsThis ponent will be used by many different ponents but for input and output. Therefore, the level of abstraction needs to be high enough that we are able to interface properly with specific ponents or functions while still maintaining a highlevel view allowing it to be replaced by another ponent without much hassle or used in another system altogether. Description for Component Read In Data Component Read In Data PSPECIn order for the system to function prope。 display that data。 use searchData in stored procedure。end ViewSchedules。 Restrictions/LimitationsThe ponent should not allow two entries to exist within the database that have exactly the same traits. While their IDs given to them by the database may be different, searches and modifications are performed by searching strings. If more than one entry pops up, the administrator may not know which one to edit. Local Data StructuresTemporary variables, which will be stored from the form data, will hold the data that needs to be stored into the database. Performance IssuesNone at this time. Design ConstraintsNone at this time. Description for Component View Schedules Component View Schedules PSPECThis ponent is responsible for the main functionality of the system. Here both the readonly users and administrators are able to see inspection schedules for any given day. If the user is readonly, they should be able to view just their inspection schedule, not anyone else’s, and should not be able to edit it in anyway. Component View Schedules Processing Detail Interface DescriptionOne input needed here will be the user’s privileges, decided by the User Verification ponent. As of deployment of this system, there should only be readonly, administrator, and super administrator defined as privilege levels.Another will be the date which to view inspection schedules. The user may do this by navigating through a small calendar on their screen. Clicking an appropriate day will submit that day, as an output, to the database to query. Algorithmic ModelComponent ViewSchedules。 set modData to whatever is passed from ReadInData。delete entry in database using standard query。 Restrictions/LimitationsNone at this time. Local Data StructuresData will be taken from local form objects and stored in temporary variables before they are mitted to a stored procedure. Performance IssuesA potential performance issue would be related to the time it takes an administrator to input the data. There may be upwards of 15 schedules requested per day. If the administrator cannot input data into the system, and receive confirmation that it was stored properly, faster than they could using their paper system, we may have a problem with the interface which should then be analyzed again. Design ConstraintsNone at this time. Description for Component Delete Inspection Component Delete Inspection PSPECWithin a day’s schedule, there are many different inspections listed for many different addresses. Suppose someone who already has an inspection needs to cancel it. The administrator can then scroll to find the date specified, look for the address, and delete it’s entry. The rest of the schedules for that day will be left untouched. Component Delete Inspection Processing Detail Interface DescriptionThe input to this ponent should e from the Read In Data ponent. The information passed here should include which address needs to be deleted along with the date that the inspection was schedule