Software Design Specification：软件设计规范.doc

Software Design SpecificationElectronic Inspection SchedulerJim CoanJoe WolfordChris LesnieskiCIS 495 Senior DesignDr. MaximNovember 10, 2005Page: 1You need a table of contents1.0 IntroductionThis software is being created to replace the paper version of the building inspection schedule for the Building and Safety department at the City of Dearborn. The program is going to store past inspections, and future inspections. In addition to the storage of information for the scheduling it will also have some added functionality. The additional criterion for the program is the followingPage: 2These need to be made more specific and the requirements (user visibale behavior) and constraints need to be separarated: Each inspector will have limited inspections during a specific day, will be flexible each day and controlled by the application. Each inspector will have inspections in the East and /or west end in each day Program will identify and skip holidays, days off and inactive inspector. Data entry clerks will have the ability to enter vacation, sick, training time or other reasons for blocking dates and times Program must allow complete audit trail of all transaction dates, time, users, and workstation ID Program will print inspection reports by one day, multiple dates, specific inspector, and specific inspector by date range A calendar on the forms screen to allow user the pick a date, if available, text range on screen is acceptable also Allow the user to schedule an inspection for the first available date Allow the user to schedule an inspection for the first available date after a specific date Allow the user to schedule an inspection for the first available date by specific inspector All tables will allow adding, searching, modifying and deleting records from the same screen Drop down menu for selection of records All drop down menus must allow data entry to add more items without exiting the screen1.1 Goals and ObjectivesThe goals of this project is to replace the current antiquated system that is being used to schedule building inspections. Our objective is to allow scheduling to be done in a more orderly, and simple fashion with future scheduling being a simple thing to do. The current system that is in place does not allow for inspections to be scheduled to far in advance. We hope to make finding available dates for inspections and specific inspectors an easy thing to do.1.2 Statement of ScopePage: 3 By this time, the input screens and reports should be well defined and mock ups should appear in the documentOur software is a scheduling tool that will allow the clerks in the department to schedule appointments for the building inspectors. The major inputs for the software will be the date for the inspection if requested on a specific date, otherwise first available will be used. The inspector requested if any, or the first available inspector will be used. An additional input will be for when reports are being generated. The software will ask for the day, or inspector, for which to generate and inspection report. The clerk will also be able to enter when the inspectors will have holidays, sick days, or other sorts of time off so that when the scheduling is done it will automatically block those dates from being scheduled. The inspectors will also be able to access their schedules via the internet/intranet where ever they are.The outputs that will be available from the software will be reports. They will be able to choose from a daily report to a report by inspector. There will be many different reports that will be available for many different situations that the clerk would need reports for. 1.3 Software ContextThis software is intended to be used for scheduling building inspections by the clerks in the Building and Safety department at the City of Dearborn. The inspectors will also use it to view their schedules. Depending on what the customer wants to do schedules will also be available for the people receiving the inspections.1.4 Major ConstraintsPage: 3Quantify constraints to allow for objective assessment of when they are met to client satisfaction Anyone using the software must have their PC connected to the internal network. Since it runs off of a server the computer must be able to connect to it. The people doing the data entry will have to be trained before using the software. Throwing them into using it without any training would leave them wondering how things work. Audit Trails may become large if there is a single record that is edited frequently. This should not happen as once it is entered it should be left alone. The most that should happen is a reschedule being done on it once or twice. Holidays will have to be checked for validity. Since some of them fluctuate every year the program may be incorrect. Also since some holidays may fall on a weekend, the preceding Friday, or following Monday may be given off as compensation so they will need to be added in as holidays. When an inspector retires from the City the people monitoring the data base will have to go into the system and manually set his/her status to inactive so that they are not scheduled on any more inspections. Only one data entry person may be working on a specific file at a time. If two people are trying to enter the same inspection at the same time it will cause errors to occur. The software will only be available for use on the internal network for the time being. This can be remedied by the City should they decide to open it up to the public, but as of now it will only be available internally. Communication of ideas between the Technical contact and the group. Time is a major constraint that we have on this project. Arranging times to meet up with the business.2.0 Data DesignA description of all data structures including internal, global, and temporary data structures.2.1 Internal Software Data StructurePage: 5You do not just write definitions here, you actually list your data dictionary as it has evolved since the requirements objects were specified (the design objects usually require implementation) This section describes data structures that are passed among components the software.2.1.1 ClassesEach form in the interface has a backend class file, which stores all of the interface functions, stored procedure calls, and variables. 2.1.2 Form ObjectsWithin each of the forms there are form objects. There consist of data grids, dropdown menus, text boxes, labels, list boxes, calendar controls and several other form objects.2.1.3 Stored ProceduresAll functionalities in the system are performed using a stored procedure. These stored procedures contain transact SQL that manipulate the data in the database. The procedures are called in the classes.2.2 Global Data StructureThis section describes data structures that are available to major portions of the architecture are described.2.2.1 ASP.NET FormsThe interface consists of three different forms. Each of these forms has an html backend, form objects, along with a class. There is a schedule (main) form, user form, and administration form. In addition there is a menu control that is similar to a form and has the same information incorporated.2.3 Temporary Data Structure This section describes data structures in the system that are for temporary use. 2.3.1 Temporary VariablesThere will be many places in the system where we will need to use temporary variables. This exists in most programs for many different uses such as counters, global variables, temporary strings, etc. 2.3.2 Temporary Form ObjectsThere will also be many places in the system in which we will need to use form objects temporarily.For example, in the case of working with data grids and template columns, in order to make changes to the objects in the column, we must create a temporary form object and set it equal to the object on the form. You then use the temporary object to make your changes. Temporary form objects will also be used within functions to simply store information for the duration of the function call.2.3.3 Session objects and variablesIn the system we will be using sessions to temporarily store information. This information includes login information, form objects, and variables. For example, to prevent having to go back to the database repeatedly every time a grid is loaded, we can store the grid containing the information into a session object. Once we load the grid again, we can simply take the grid out of the session instead of re-querying the database.2.4 Database DescriptionPage: 6this seems about rightThis section describes each data object, relationships between objects, a complete data model, as well as a data dictionary.2.4.1 Data Objects Action TypeThe action_type table stores information about the types of actions that are performed in the audit trail. These actions may include “update” and “delete”. Audit TrailThe audit_trail table stores information for an action involving an “update” or “delete”. This information involves the users id that performed the action, the users workstation id, the action performed, the date, the time, and a constructed string of the previous record before action was performed. HolidayThe holiday table stores dates and names for holidays. It is when scheduling inspections so that the system ignores any holidays. Home TypeThe home_type table stores information about the different home types used in the system. This table is used specifically for the inspections table. The current home types are “single”, “duplex”, and “multi”. Each home type has a weight, which is used in determining how many homes an inspector is inspecting in a day. Inspection Date DefaultThe inspection_date_default table is used to store the default number of homes an inspector may expect on any given day. If there isnt a specific amount for the current date in the inspection_date_specific table, then the num_allowed_per_day value in the inspection_date_default table is used as a maximum amount before an admin is prompted. Inspection Date SpecificThe inspection_date_specific table is used to store the number of homes an inspector may expect on a specific date. The num_allowed_per_day value is used as a maximum amount before an admin is prompted. Inspection TimeThe inspection_time table is used to store the different times of the day that inspections can take place. Currently the only times are “AM” and “PM”. However, in the future they may change to having three or four times a day in which inspections will take place. This gives them flexibility. Inspection LocationThe inspection location table is used to store the different locations in which sections can take place. Currently the only locations are “East” and “West”. However, in the future they may divide the city into a more defined breakdown of city locations. This would allow them extra flexibility. Inspection ScheduleThe inspection schedule table is used to store information about inspections. It acts as the primary table in the system in terms of scheduling and each record in the table represents an appointment. All information pertaining to an appointment is recorded in or related to this table.0 Inspection StatusThe inspection_status table stores information for the different inspection statuses. Currently the only statuses are “Open” and “Closed”. 1 Inspection TypeThe inspection_type table stores information for the different types of inspections. Currently the inspection types in the system are “first”, “second”, and “final”. 2 InspectorThe inspector table is used to store information about inspectors. It saves their id, name, and status. 3 Inspector Days OffThe inspector_days_off table is used to store the days off for each inspector. Each record stores the id of the inspector, the date that they will have off, and the reason for the day off of work.4 Inspector StatusThe inspector_status table stores information for each of the types of inspector statuses. The current status types in the system are “active” and “inactive”.5 UserThe user table stores information about the users of the system. The user id, user name, password, name, and role are stored in the user table.6 User RoleThe user_role table stores information for the different roles in the system. Currently the only roles in the system are “viewer”, “administrator”, and “super administrator”.3.0 Architectural and Component-Level Design3.1 Program StructureArchitecture is not the operation software. Rather, it is a representation that enables a software engineer to 1) analyze the effectiveness of the design in meeting its stated requirements, 2) consider architectural alternatives at a stage when making design changes is still relatively easy, and 3) reduce the risks associated with the construction of the software. Architectural design focuses on the representation of the structure of the software components, their properties, and interactions.3.1.1 Architectural DiagramPlease see the appendix for the architectural diagram of the overall systemPage: 12Does not seem to be present in the appendix (as either an ACD or UML equivalents).3.1.2 AlternativesThe main architecture for this project is a data-centered architecture. Our requirements stated we need to develop a program that will not only store data but also allow multiple users to retrieve and modify that data. As the integrity of that data is very important, some sort of data store would be ideal. This way, different users from all over the department could have access to the same data at the same time compared to the old paper system, in which there was only one clipboard which held the data.Two other minor architectures exist within this system. A data-flow architecture is present, despite that data may not pass through more any more than two filters before reaching its destination. This is mostly automated by the suite of programs we are using (ASP.NET and MSSQL). Most of the data manipulation happens with ASP.NET and formatting it to the next components expected form.The other minor, and last, design architecture was a layered architecture. There are components which handles interactions with the user. Components within the next inner level (ASP.NET) handle transform data from the user interface to the database interface or from the database interface to the user interface. Lastly, at the core we have the database itself and its components in the form of stored procedures.The two other main architectures call and return and object-oriented we have decided not to implement as they dont quite fit our needs. In a call and return architecture, one main program or function is able to call other program components which can either finish their processing and return to the main program or call other components creating a vertical hierarchy of control within one larger overall component. In our system data is more or less passed along a horizontal route between larger components a user interface, ASP.NET, and MSSQL.In looking at our data model, choosing to implement our system in an object-oriented architecture would mean that objects (and the available behavior of objects) are the primary components within the system. For our system, tables appeared to be better geared for describing, storing, and organizing the dataPage: 13This level of detail seems about right for this point in the project.3.2 Description for Component View Audit Trail3.2.1 Component View Audit Trail PSPECThe Audit Trail is a separate table within the database which holds all of the edited and deleted inspection schedules for the past six months. No inspectors or administrators are allowed access to this listing, only super administrators.3.2.2 Component View Audit Trail Processing Detail Interface DescriptionThis component has no input. As the user has already been validated earlier, no username or password needs to be checked. Also, there is no range of dates specified.The output will be sent to the ASP.NET page to be displayed in a list format. Algorithmic Modelcomponent View Audit Trail;call generic query in a stored procedure from ASP.NET;receive data from database;if dataReceived spaceAvailableOnScreenpartition up dataReceiveddisplay dataReceived;end View Audit Trail; Restrictions/LimitationsNone at this time. Local Data StructuresA set of strings which hold enqueued entries from the Audit Trail when there is too much information to display on screen at one time. Performance IssuesDe to the large amount of entries, retrieving and displaying all of them, which may number into the thousands for the past six months, may take a bit longer than a normal query on the database.The format of the data will not be displayed in a polished manner as it normally would if an administrator or inspector were looking at a current schedule. This may present a problem for the ASP.NET page if the data is not broken into easily displayable chunks. Design ConstraintsNone at this time.3.3 Description for Component Create New Inspection3.3.1 Component Create New Inspection PSPECWhen a person requests a new inspection, where an inspection is one inspector inspecting one building, this should be the component tha