C ONTROL Y TRAZABILIDAD ACCIONES DEL PESV

The first part of service specification is the design of the mathematical model building service. The idea behind building a mathematical model is to inform optimisation experts working on different parts of a complex model on the motivation that links these components to the over all picture of the mathematical procedures so that it is clear what the procedures lead to (Castillo et al., 2002). The mathematical model service consists of quantitative and qualitative interfaces. These interfaces increase the usability of the system as designers have a user friendly GUI to enter design

parameters. The mathematical model builder guides the user to enter design variables that will be used to build the model. Figure 5.4 is the use case diagram for mathematical model creation. Actors include user, expert, Globus Toolkit and client interface.

Figure 5.4: Mathematical model building use case diagram

The actions (use case) describe what the prototype is expected to deliver and allow the different users (actors) to perform certain mathematical model building tasks. For example, the user can define design parameters (DPs), constraints, criteria and select inputs. Good and bad design practices can be obtained from the ISO (International Organisation for Standardisation) 9241-11 which defines design usability as the extent to which a product can be used by specified users to achieve specified goals through efficient and effective use of good design standards (Jokela et al., 2002). This use case diagram is used to provide a mathematical model building specification document as shown in Figure 5.5. This specification is the document provided for the programmer. It is the normal specification document as outlined in Globus, FIPER, SORCER and Geodise. An improvement over this will be described in section 5.5 where service specifications will include specifications for high level users of MODO services, not just for programmers. This is to provide emphasise on the issue of grid services as utility.

Figure 5.5: Specifications of quantitative mathematical model building service

The same quantitative mathematical model building specification document described in Figure 5.5 as a class diagram is described together with the different actions required at each stage in a sequence diagram. Figures 5.6 and 5.7 show the sequence diagrams that this research used to implement the mathematical model building service. Because the process of the sequence diagram is too large, the diagram is divided into part 1 (Figure 5.6) and part 2 (Figure 5.7).

In describing Figures 5.6 and 5.7, it is important to mention that in coming up with the sequence for building the mathematical model, information obtained from literature was used (Cross and Moscardini, 1995; Castillo et al., 2002). The first stage is the main domain definition. A domain is an area of specialisation that the problem falls under. For example, a problem that is to perform a finite element analysis (FEA) means that the user should select FEA domain and that of cost modelling means cost modelling domain. In this research, the main domain areas are the three case studies. For a given domain, the procedure to build the model is the same. The next step is to

define the criteria. The criteria specify what to optimise and the expected outputs of the optimisation. In the second case study of this research-the welded beam problem, the criteria are to minimise the cost of fabrication and to maximise the end deflection (Deb, 2001). In real practice, customer requirements and designer expertise play a great role in coming up with design criteria (Chen and Lee, 2009). The criteria will determine if the problem requires a quantitative approach or a qualitative one or both. In the design of manufacturing plant layout/floor planning case study, quantitative and qualitative objectives were used. The design parameters which are the inputs are defined using appropriate units of measurements and by applying the boundary conditions that have been identified at the criteria definition stage. The selection of inputs is obtained from a template which defines variables, constants, universe of discourse and design parameters.

: Input Selection Interface : User : Problem Domain_Interface : Criteria Definition

Interface

: Model Functionality Interface

: Design Parameters

Interface : Good and Bad DesignExamples Interface

: Constraints Definition Interface Domain: FEA, CFD, Cost

Modelling, etc 1: selectProblemDomain() 2: getCustomerRequirements() 3: getRegulations() 4: captureDesignExpertise() 5: defineOutputs() 6: defineFunctionality() 7: defineUnits() 8: setBounds() _{9: getDPs()} 10: defineUnits() 11: defineEffectsOfDPs() 12: defineSearchMethods() 13: listParameters() 14: getInputs() 15: defineUnits() 16: getDPs() 17: setUniverseOfDiscourse() 18: defineEffectsofDPs() 19: defineGoodDesigns() 20: defineBadDesigns() 21: defineConstraints()

Figure 5.6: Mathematical model building sequence diagram (Part 1)

The constraints are then defined based on the selected variables, constants and criteria. A decision interface is provided at this stage to either continue or repeat the process if the defined variables, constants and criteria are not sufficient for constraints definition (Sundaresan et al., 1993). The system then links the criteria (outputs) and variables. This linking creates the equations and relations for constraints and objectives. The model is validated through sensitivity analysis and realistic results

obtained using case studies in literature. The mathematical model is finally obtained which consists of equations, constraints and boundary conditions.

: Math Model Generation Interface : Constraints Definition Interface : Decision Interface

: Interface for Linking Criteria and Variables

: Creation of Equations and Relations Interface : Model Validation Interface Continuation of Math Model Creation 1: makeDecisions() 2: getMainDomain() 3: getInputs() 4: defineUnits() 5: setBoundaryConditions() 6: doCalculations() 7: performLinking() 8: createEquations() 9: createRelations() 10: doSensitivityAnalysis() 11: doRealisticResultTest() 12: doContinuityTest() 13: doSufficiencyTest() 14: compareOutputs() 15: generateEquations() 16: generateConstraints() 17: generateBoundaryConditions() 18: buildMathModel()

Figure 5.7: Mathematical model building sequence diagram (Part 2)

There were steps that were followed to create the use case and sequence diagrams (Figures 5.4 to 5.7) for the mathematical model building process. These steps were obtained from experts in the academia and industry. The steps consists of (1) capturing the process of mathematical model development (2) capturing the users’ requirements that make the tool helpful in mathematical model building and (3) validation of the diagrams. The validation of the diagrams is done as the system is being implemented and tested with users that participated in the validation process.

5.3.2 Design of qualitative mathematical model building