4 Database and application development
4.3 Application development
4.3.4 Construction phase
During this phase the focus is on the design and implementation of the complete system software. The phase output consists of a fully functional "beta-version" of the system software. Also included in this section are the various activity diagrams for the root and component modules of the system. Each of the system components is implemented in Embarcadero Delphi™ for Microsoft® Windows™ operating system. The Delphi™ integrated development environment (IDE) and IDEs in general are covered in section 2.5. In this section each of the system modules and the activity diagrams are covered. Figure 4-16 shows the key for activity diagrams.
65
Figure 4-16: Activity diagram key.
4.3.4.1 Root module design and implementation
The root module acts as the "hub" of the system. It includes the following functionalities:
Establishes database connection which can be carried over to component modules. Allows user to select desired project.
Includes profile data manager and plant data import tools. Calls component modules.
Exports results generated by component modules to Excel.
The root module allows the user to select the desired IP address where the required database is hosted. The correct username and password are required. The database connection is created as a Delphi™ TMySQLConnection object, which allows for easy passing to component modules. Once the connection is established the project can be selected and component modules can be called. The calling of component modules by the root module is illustrated in Figure 4-17.
The root module also consists of a plant manager system that allows for the viewing, importing and manipulation of plant data, including plant, unit and profile data, as mentioned in section 4.2.
66
Figure 4-17: Activity diagram for root module showing component module calls.
4.3.4.2 Efficiency analysis module design and implementation
The efficiency analysis module allows the user to evaluate the efficiency of power plants using historical data. A single plant's efficiency can be tracked over time, or multiple plants can be evaluated comparatively. The functionalities of this module are shown below:
Select project (if not selected in root module). Select plant(s).
Select time window over which to perform the analysis.
Select the efficiency evaluation method to use in analysis (heat rate, actual efficiency, technical efficiency or scale efficiency).
67
The DMU scale can be selected for each analysis. Plants can thus be evaluated on a daily, monthly or yearly scale. The overall average efficiency is evaluated for each plant, as well as the efficiency of each DMU. The module queries the relational database for all required data. A full activity diagram is shown for the efficiency analysis module in Figure 4-18.
Figure 4-18: Activity diagram for efficiency analysis module.
68
The DEA engine module allows the user to perform DEA analyses on plant data. This may consist of only a single plant's data, in which case a time-based tracking analysis is performed, or multiple plants' data, in which case a comparative analysis is performed between plants. The functionalities of the DEA engine module are shown below:
Select project (if not selected in root module). Select plant(s).
Select time window over which to perform the analysis. Select the various DEA methodologies to use in analysis.
o Select envelopment or multiplier model.
o Select constant, variable, non-increasing or non-decreasing return-to-scale model. o Select input- or output-orientation.
Select which inputs and outputs are used in analysis.
In case of a time-based tracking analysis, the DMU scale is selected. Results can be exported to Excel.
When a single plant is selected, the plant data is evaluated over a time window, with time period serving as the individual DMUs. Thus, the individual months, weeks or days can be monitored comparatively. The DEA methodology is selected for the analysis. This includes both the envelopment or multiplier model, the return-to-scale mode and the option of output orientation. The necessary data is acquired from the relational database via the database connector using dynamic queries. The constraints associated with each individual DEA model are formulated by Delphi™ and passed to the Lp_Solve51 DLL. Once all constraints are passed, the solve command is given. The linear programming results are read and stored by Delphi™. These interactions are shown in Figure 4-19.
69
Each DMU is solved as a separate LP problem. Constraints are formulated according to the DEA model and orientations selected, based on the mathematical basis of each methodology. The various structures of the constraints are described below. The Lp_Solve51 DLL requires constraints to be passed as strings with the inequality specified afterwards. Variables are identified by parsing these strings. For the envelopment model, all constraint strings take the form of Equation ( 4.1) , i.e. an overall efficiency variable plus one λ variable per DMU.
𝛳1 𝜆1 𝜆2… 𝜆𝑁 (4.1)
where
𝛳i denotes the efficiency of ith DMU,
and
𝜆 N denotes the weight associated with the Nth DMU,
The variables shown in 4.3.4.1.2.1.1 are the ones identified by the Lp_Solve51 DLL. The objective function for the envelopment model involves the minimising of the 𝛳 value, so the objective function takes the form of Equation ( 4.2).
𝑀𝑖𝑛𝑖𝑚𝑖𝑠𝑒 ∶ 𝛳1 0 0 … (4.2)
For each DMU a constraint needs to be added per input category and per output category, as covered in section 3.3.6. For DMU o these take the form of Equation ( 4.3 ) to ( 4.8 ).
−𝑥𝑜1 𝑥11 𝑥21… 𝑥𝑁1 ≤ 0 (4.3) −𝑥𝑜2 𝑥12 𝑥22… 𝑥𝑁2 ≤ 0 (4.4) ⋮ −𝑥𝑜𝑁 𝑥1𝑁 𝑥2𝑁… 𝑥𝑁𝑁 ≤ 0 (4.5) 0 𝑦11 𝑦21… 𝑦𝑁1 ≥ 𝑦11 (4.6) 0 𝑦12 𝑦22… 𝑦𝑁2 ≥ 𝑦12 (4.7) ⋮ 0 𝑦1𝑁 𝑦2𝑁… 𝑦𝑁𝑁 ≥ 𝑦1𝑁 (4.8)
These constraints are repeated for each DMU as a separate LP problem. Further constraints are required in the following forms.
1 0 0 … 0 ≥ 0 (4.9)
0 1 0 … 0 ≥ 0 (4.10)
⋮
0 0 0 … 1 ≥ 0 (4.11)
1 0 0 … 0 ≤ 1 (4.12)
Equations ( 4.9 ) to ( 4.11 ) ensure that all variables are non-negative, while Equation ( 4.12 ) ensures that the efficiency value is always less than one, and therefore always a value between zero and one.
The Return to Scale (RTS) orientation is determined by the addition of a separate constraint, as shown in Equation ( 4.13 ). The inequality assigned to this term dictates the RTS orientation, as
70
shown in Equation ( 4.14 ) to ( 4.16 ) and as described in section 3.3.6.4. If Equation ( 4.13 ) is unbound the RTS is constant.
0 1 1 … 1 (4.13)
𝑉𝑎𝑟𝑖𝑎𝑏𝑙𝑒 ∶ 0 1 1 … 1 = 1 (4.14)
𝑁𝑜𝑛 𝑖𝑛𝑐𝑟𝑒𝑎𝑠𝑖𝑛𝑔: 0 1 1 … 1 ≤ 1 (4.15)
𝑁𝑜𝑛 𝑑𝑒𝑐𝑟𝑒𝑎𝑠𝑖𝑛𝑔: ∶ 0 1 1 … 1 ≥ 1 (4.16)
The multiplier model mathematical formulation is covered in section 3.3.5. For this model, constraints are still passed as strings however in a slightly different format, as shown in Equation ( 4.17 ) for a specific DMU with i inputs and N outputs. A v variable is added for each input category and a u variable is added for each output category.
𝑣1 𝑣2… 𝑣𝑖 𝑢1 𝑢2… 𝑢𝑁 (4.17)
where
vi denotes the weight associated with the ith input category,
and
𝑢N denotes the weight associated with the Nth output category.
The objective functions for the input and output orientated multiplier models are shown in Equation ( 4.18 ) and ( 4.19 ) respectively. For the input orientated form Equation ( 4.19 ) must hold true, so as to keep outputs constant, while for the output orientated form Equation ( 4.21 ) must hold true, so as to keep inputs constant.
𝑚𝑎𝑥𝑖𝑚𝑖𝑠𝑒: 0 0 … 0 𝑦1 𝑦2… 𝑦𝑁 (4.18)
𝑚𝑖𝑛𝑖𝑚𝑖𝑠𝑒: 𝑥1 𝑥2… 𝑥𝑖 0 0 … 0 (4.19)
𝑥1 𝑥2… 𝑥𝑖 0 0 … 0 = 1 (4.20)
0 0 … 0 𝑦1 𝑦2… 𝑦𝑁 = 1 (4.21)
For the input orientated form constraints take the form of Equations ( 4.22 ) to ( 4.24 ). For each DMU n constraints need to be added, where n is the total number of DMUs in the analysis. A DMU with i inputs and N outputs is considered.
−𝑣11 −𝑣12… −𝑣1𝑖 𝑢11 𝑢12… 𝑢1𝑁 ≤ 0 (4.22)
−𝑣21 −𝑣22… −𝑣2𝑖 𝑢21 𝑢22… 𝑢2𝑁 ≤ 0 (4.23)
⋮
−𝑣𝑛1 −𝑣𝑛2… −𝑣𝑛𝑖 𝑢𝑛1 𝑢𝑛2… 𝑢𝑛𝑁 ≤ 0 (4.24)
For the output-orientated form, constraints are formulated as in Equation ( 4.25 )to ( 4.27 ).
𝑣11 𝑣12… 𝑣1𝑖−𝑢11−𝑢12… −𝑢1𝑁 ≤ 0 (4.25)
𝑣21 𝑣22… 𝑣2𝑖 −𝑢21 −𝑢22… −𝑢2𝑁 ≤ 0 (4.26) ⋮
71
Once the constraints are passed to the Lp_Solve51 DLL the solve command is given. Results are stored in temporary tables on the database for use in Excel™ exporting or by baseline formulator module. These temporary tables are destroyed on termination of the application. Exported results include the following:
Name of plant being analysed. Current date and time.
Start and end time of selected time window. Names of each DMU being analysed.
Number of iterations in linear programming optimisation. Number of variables identified.
Calculated overall efficiency.
Name and value of each calculated weight (depends on model selected). A full activity diagram for the DEA engine module is show in Figure 4-20.
72
Figure 4-20: Activity diagram for DEA engine module.
4.3.4.4 Application testing
Rigorous testing of each module is necessary to ensure correct working and stability. As specified by the Unified Process, testing is iterative in nature i.e. bugs are identified and rectified before the next
73
round of testing commences. This process is repeated until the implemented application meets all its requirements.
The implemented application and all included modules are tested using model data. This data is stored in a test database, constructed as described in section 4.2 as a test project. Multiple test plants are included, each consisting of number of units and profiles. A model timeline is also created. The complete database is hosted using WAMPserver. To test the validity of the application's temporary database tables, an external application is employed. Temporary tables are manually viewed using MySQL Query Browser.
The root module's primary functions consist of establishing a database connection to be passed to component modules and to call these component modules. The database connection feature is tested by establishing a connection to the test database. By successfully calling each individual component module, the root module is further tested.
The efficiency analysis component module must retrieve the relevant historical plant data from the relational database as selected by the user. Efficiency is evaluated using this data. Results are calculated manually in Excel and compared to the applications results, thus testing their accuracy.
The DEA engine component module must query the database and retrieve the necessary data for the selected analysis. This data is used to construct constraints which are passed to an external linear programming DLL. This DLL is given the solve command and the results are retrieved. These results are saved in temporary database tables and potentially exported to Excel.
By querying and extracting data from the database the module's connection is tested. Constraints are formulated and printed to a dedicated debug window to test their structure. The DLL receives these constraints and returns results, confirming the module's ability to communicate with the DLL. The results are again printed to the debug window. The linear programming problem used for testing is purposely selected to be simple in nature so that the results' accuracy can be confirmed by calculation in Excel. Temporary tables are viewed and their accuracy confirmed in MySQL Query
Browser. Results are exported to Excel™ and viewed again, confirming the correct structure and
validity of results.