# Combinatorial Optimization Problems and Metaheuristics: Review, Challenges, Design, and Development
## 4 Results: Standardization, Methodology, and Framework for COP and Metaheuristics
### Metaheuristics General Specification  
Defining a software design pattern is crucial to develop more robust metaheuristics in a standard way. A software standard permits that a metaheuristic can be more easily implement and reused. It also opens a new page to enable a top-notch system of cooperation among metaheuristics. Consequently, this section aims to answer _RQ-5: How can we define a standard design for metaheuristics and completely without coding links with the problems?_ The answer to this question must be accompanied by a foundational pillar, a COP standard. Therefore, the proposal of this metaheuristic software design pattern follows all the definitions supplied in Section 4.2, Problem Representation: Formulation and Standards. It is considered that metaheuristics can be seen as a master heuristic that orchestrates a set of subordinated heuristics in an iterative cycle until certain conditions are achieved. Suppose the \"content\" of subordinated heuristics is removed. In that case, a metaheuristic is just a higher-level cycle that calls subordinated heuristics in a specific order according to their \"roles\" in the search process. A \"role\" can be seen as an activity that must be performed and contribute to the metaheuristic's strategy to navigate the search space. Therefore, this higher-level cycle determines what a metaheuristic algorithm is. Additionally, the same metaheuristic algorithm can present a vast number of variations, and it will depend on the SH variation that will be used in each role. Each variation of a subordinated heuristic can change the behavior of metaheuristics by implementing a different mechanism of navigation in the search space. Additionally, the metaheuristic behavior can be changed by its parametrization that regulates some decisions during the search. Moreover, by considering these variation necessities, a metaheuristic design pattern must also provide a system that enables an interoperability software structure with the capacity to exchange subordinated heuristics (algorithms)--in other words, the ability to  
Figure 7: Problem building blocks and their relationships. replace SHs transparently in design and run time. Consequently, to make this possible, metaheuristics also must be defined as two levels of abstraction: (1) a conceptual level and (2) a concrete level. The conceptual level defines an abstract metaheuristic algorithm by specifying a higher-level cycle (meta-algorithm), the roles required by SHs in the strategy, MH parameters needs, and metadata behaviors. **Definition 15**. : _Therefore, an abstract metaheuristic can be defined in the following way:_  
\[M=(\sigma,\ C,\Delta,\mathrm{K})\rightarrow\{m_{1},m_{2},\ \ldots,\ m_{n}\} \tag{15}\]  
_where:_  
* \(M\) _represents an abstract metaheuristic algorithm and it can originate several possible variations of this metaheuristic algorithm_ \(\{m_{1},m_{2},\ \ldots,\ m_{n}\}\)_;_
* \(\sigma\) _represents the metadata that describe some aspects of the metaheuristic behaviors that can be interpreted by the framework (e.g., solution encoding rules);_
* \(C\) _defines the higher-level cycles that arranges the SH calls;_
* \(\Delta\) _is a list of \"search role requested\"_ \(\{\delta_{1},\ \delta_{2},\ \ldots,\ \delta_{1n}\}\) _by higher-level cycle and it will be performed by SHs; and_
* \(K\) _defines the set of parameters' specifications_ \(K=\{k_{1},\ k_{2},\ \ldots,\ k_{n}\}\) _necessary to regulate the metaheuristics' decisions during the search._  
After an intensive review and analyzing various subordinated heuristics, we concluded that they can be organized into categories according to their functioning in the search process.