【正文】 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。 Restrictions/LimitationsThere will be a ceiling put into place on the number of results which can be returned. If the search is too intensive or has too broad of a scope, the user might not be able to get the information 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。 use searchData in stored procedure。 store ReadInData returned into searchData。end ViewSchedules。receive data from database。 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。send modData to a stored procedure which will allow the database to change entries。 set modData to whatever is passed from ReadInData。end DeleteInspection。delete entry in database using standard query。 confirm deletion with a warning from DisplayMessages。 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 need