Project topics and materials
Get Complete Project Material File(s) Now! »
Multiobjective Mathematical Programming
The problems we consider in this work have more than one objective, as we will see in the next sections. They belong to the class of multiobjective problems. In order to provide a taxonomy of multiobjective decision making approaches, we introduce some specifications. A first important distinction is between the following two scenarios. In the first case, the possible choices are explicitly known from the beginning, and the decision maker has to choose among them. In the second scenario the set of possible choices is not immediately available since they are expressed implicitly as the solutions of a mathematical model. A second distinction is based on the number of possible choices, which can be finite or (potentially) infinite. These two features are often coupled, thus we have two main contexts:
• Scenario 1: a finite set of explicitly known choices
• Scenario 2: a (potentially) infinite set of implicitly known choices. In the first case the focus is on choice selection, and in the second one it is on choice identification. These two tasks attracted different communities of researchers and there is by now a quite clear separation between those who focus on finding the set of possible solutions and those who focus on aiding to make the choice among all possible ones.
Multi Criteria Decision Analysis (MCDA) and Multi Objective Mathematical Programming (MOMP) are used respectively for the finite-explicit scenario and for the infinite-implicit one. Multi Criteria Decision Making (MCDM) is a most general term, which refers to both of them.
From goals to objective functions
One of the hypothesis of our work is the adoption of an iterative system design process, represented, for example by the spiral-model introduced in Section 1.3.3. We figure out a scenario in which we want to design a system with this kind of approach. This includes the production of several prototypes, with different abstraction level; at least, one for each iteration. In particular we focus on the first “turn”, which aims to produce the first prototype of the system-to-be, considering only high-level requirements.
As mentioned in the previous sections, often, high-level requirements, are stated as soft ones. Moreover, agreements and oppositions among goals are assumed on a hypothetical basis. Designers suppose that some goals could contrast some others. Nevertheless, it is only during the following steps, when formal models are deployed, that these assumptions can be verified. Thus, new trade-offs can be necessary and supposed ones can reveal themselves as apparent. In others words, potential tradeoffs are commonly analyzed in details only when the design process reaches the constructional level.
Evolution of an information system architecture
From time to time, an information system may evolve in its entirety due to the replacement of an existing software technology by a new one (e.g. passing from several independent/legacy software packages to an integrated one, migrating from an existing IT technology to a new one, and so on). These evolutions (or transitions) invariably have a strong impact at the IT layer level, where the existing IT modules UE = {M1, . . . ,Mn} are replaced by new ones in a set UN = {N1, . . . ,Nn′} (in the sequel, we assume U = UE ∪ UN). This translates to a replacement of existing services (sometimes denoted as ES) in V by new services (sometimes denoted as NS) in W ensuring that the impact on the whole enterprise is kept low in order to avoid business discontinuity. This also induces a relation B ⊆ W ×UN expressing reliance of new services on IT modules. Note also that in this context, at the business level, there exists a relation (in V ×W) between existing services and new services which expresses the fact that a given existing service shall be replaced by a subset of new business services. We note in passing that this relation also induces another relation in UE × UN expressing the business covering of an existing IT module to a subset of new IT modules (see Fig. 2.3).
Table of contents :
I Theory
1 Introduction
1.1 Overview
1.2 Mathematical Programming
1.2.1 Multiobjective Mathematical Programming
1.2.2 The meaning of “minimization” in MOMP
1.2.3 Solution methods
1.2.4 Computational complexity
1.3 Systems Engineering
1.3.1 Requirements engineering
1.3.2 Goals
1.3.2.1 Tropos
1.3.3 Systems design and management process
1.3.4 From goals to objective functions
1.4 Structure of the work
II Applications
2 The information system architecture evolution problem
2.1 Introduction
2.2 Operational model of an evolving information system
2.2.1 Elements of information system architecture
2.2.2 Global Goal
2.2.3 Evolution of an information system architecture
2.2.4 Management of IT system architecture evolutions
2.2.5 The IT system architecture evolution management
2.3 Mathematical Programming based approach
2.3.1 Introducing the MP formulation
2.3.2 Sets, variables, objectives, constraints
2.3.3 Valid cuts from implied properties
2.4 Formulation properties and trade-off
2.4.1 Decomposability
2.4.2 Trade-off
2.5 Computational results
2.5.1 CPU time
2.5.2 Optimality Gap
2.5.3 Cuts effectiveness
2.5.4 Trade-off in realistic instances
3 The recommendation problem
3.1 Introduction
3.1.1 Recommendation problem
3.1.2 Recommendation methods
3.2 Operational model of a recommender system
3.2.1 Global Goal
3.3 Recommender system 1: TMW
3.3.1 Formal model
3.3.2 Identification of maximum confidence paths
3.3.3 Exploiting the ratings
3.4 Recommender system 2: BMC
3.4.1 Bipartite networks and modularity
3.4.2 RS by means of bipartite modularity based clustering
3.5 Recommender system 3: LSPR
3.5.1 Model
3.6 Evaluating the recommender systems
3.6.1 Dataset
3.6.2 Evaluating effectiveness
3.6.2.1 Accuracy
3.6.2.2 Audacity
3.6.3 Evaluating efficiency
3.7 Recommender systems design problem
3.8 Evaluation TMW using a small dataset
4 The equitable hazmat transportation problem
4.1 Introduction
4.2 Related works
4.3 Operational model of a transportation system
4.3.1 Global Goal
4.4 Mathematical programming formulation
4.4.1 Sets, variables, objectives, constraints
4.4.2 Reformulation of the model
4.4.2.1 ǫ-constraint method
4.5 Computational results
4.5.1 Preliminary tests
4.5.2 Comparison
4.6 A heuristic for large-scale instances
4.6.1 Graph reduction through centrality erosion
III Meta-theory
5 Some epistemological and historical remarks
5.1 Philosophy of Engineering
5.1.1 Epistemic vs non-epistemic values
5.2 Models
5.2.1 Model validation
5.3 Experimental approach to scientific knowledge
5.4 Collaborative approach to scientific knowledge
5.5 Ethical approach to scientific knowledge
5.6 Computational approach to scientific knowledge
5.7 Teleological approach to scientific knowledge
IV Conclusions
6 Conclusions
V Bibliography and appendices
Bibliography
