Update README.md

README.md

@@ -134,7 +134,7 @@ infrastructure and historical data, available from the IEC.
 Having said that, in order to correctly run the optimization module, the following structure 
 should be added to the input DOML
 
-------------------------------------------------------------------------------------------------------------------------
+```
 optimization opt {
 	objectives {
 		
@@ -143,19 +143,19 @@ optimization opt {
 
 	}
 }
-------------------------------------------------------------------------------------------------------------------------
+```
 
 At this moment, three different objectives can be contemplated in the IOP: minimize the **cost**, 
 maximize the **availability** and maximize the **performance**. Any combination of these objectives 
 can be introduced. Here is an example of the full three objectives and how they should be introduced:
 
-------------------------------------------------------------------------------------------------------------------------
+```
 	objectives {
 		"cost" => min
 		"availability" => max
 		"performance" => max
 	}
-------------------------------------------------------------------------------------------------------------------------
+```
 
 Regarding the non funcional requirements, different kind of requirements are contemplated in 
 the current version of the IOP, such as assign a maximum cost for the overall configuration, assign a minimum 
@@ -163,7 +163,7 @@ availability for the overall configuration, assign a minimum performance for the
 restrict the region of the selected elements and restrict the providers of the elements. Here is an 
 example of the five requirements, and how they should be introduced:
 
-------------------------------------------------------------------------------------------------------------------------
+```
 	nonfunctional_requirements {
 		req1 "Cost <= 200" max 200.0 => "cost";
 		req2 "Availability >= 94.0%" min 94.0 => "availability";
@@ -171,11 +171,11 @@ example of the five requirements, and how they should be introduced:
 		req4 "Region" values "Europe" => "region";
 		req5 "Provider" values "aws" => "provider";
 	}
-------------------------------------------------------------------------------------------------------------------------
+```
 
 Thus, this could be a possible input for the IOP, represented in the input DOML.
 
-------------------------------------------------------------------------------------------------------------------------
+```
 optimization opt {
 	objectives {
 		"cost" => min
@@ -187,29 +187,29 @@ optimization opt {
 		req3 "Region" values "Europe" => "region";
 	}
 }
-------------------------------------------------------------------------------------------------------------------------
+```
 
 A special attention should be made here to the multi-element optimization. In order to contemplate the multi-element 
 optimization, the user can introduce the following structure as a new requirement:
 
-------------------------------------------------------------------------------------------------------------------------
+```
 
 nonfunctional_requirements {
 		req1 "elements" => "";
 }
 
-------------------------------------------------------------------------------------------------------------------------
+```
 
 Using this structure, the use is able to introduce the combination of elements he/she is searching for. For example, if 
 the user needs to deploy a service with 3 different virtual machines and 1 database, the element part should be:
 
-------------------------------------------------------------------------------------------------------------------------
+```
 
 nonfunctional_requirements {
 		req1 "elements" => "VM VM VM Database";
 }
 
-------------------------------------------------------------------------------------------------------------------------
+```
 
 That is, the elements requirement should be introduced as a list of Strings, being VM the acronym of Virtual Machine. In 
 order to facilitate the usage of this multi-optimization feature, several aspects should be taken into account:
@@ -219,7 +219,7 @@ order to facilitate the usage of this multi-optimization feature, several aspect
 storages, he/she can define the elements part without adapting to any established order. In other words, the following 
 three examples represent the same situation above mentioned:
 
-------------------------------------------------------------------------------------------------------------------------
+```
 
 req1 "elements" => "VM VM storage storage";
 
@@ -227,17 +227,17 @@ req1 "elements" => " storage storage VM VM";
 
 req1 "elements" => "VM storage VM storage";
 
-------------------------------------------------------------------------------------------------------------------------
+```
 
 •	The number of units per element can be equal to 0. In these cases, the elements parts should not contain the elements 
 that are not desired. For example, if the user needs the best configuration for three different virtual machines, not 
 needing any storage nor database, so the elements part should be defined as follows:
 
-------------------------------------------------------------------------------------------------------------------------
+```
 
 req1 "elements" => "VM VM VM";
 
-------------------------------------------------------------------------------------------------------------------------
+```
 
 •	The elements part of the nonfunctional_requirements is optional. In case the user does not introduce this information, 
 the IOP consider the basic problem. That is, the finding of the best configuration combining one single unit per element 
@@ -249,7 +249,7 @@ Once the IOP conduct its optimization, it returns a complete DOML. This DOML is
 as input, with the optimization results introduced. First, the IOP complements the "optimization opt" 
 part of the DOML adding the found solutions. This is an example:
 
-------------------------------------------------------------------------------------------------------------------------
+```
 optimization opt {
 	objectives {
 		"cost" => min
@@ -278,7 +278,7 @@ optimization opt {
 		decisions ["Storage4_Europe VM_1_CS"]
 	}
 }
-------------------------------------------------------------------------------------------------------------------------
+```
 In this example, the IOP returns two different solutions, composed each one of a Virtual Machine and a 
 Storage element. For each solutions, the value of each objective and the elements chosen are returned.
 
@@ -286,7 +286,7 @@ Furthermore, the IOP introduces the features of each found solution in the *conc
 the DOML. If *concretizations* part is not present in the input DOML, the IOP creates it. This is an 
 example of returning concretizations.
 
-------------------------------------------------------------------------------------------------------------------------
+```
 concrete_infrastructure con_infra {
 		provider openstack {
 			vm concrete_vm {
@@ -325,7 +325,7 @@ concrete_infrastructure con_infra {
 			}
 		}
 	}
-------------------------------------------------------------------------------------------------------------------------
+```
 
 Finally, the last aspect to highlight in this documentation is related to how the IOP ranks the solutions provided as 
 output. As mentioned, if the problem to solve has two or three different objectives to optimize, the problem converts into 
@@ -339,7 +339,7 @@ objectives part of the optimization opt section of the DOML is used, deeming the
 
 Thus, if the user inserts the following objectives as input:
 
-------------------------------------------------------------------------------------------------------------------------
+```
 
 objectives {
 		"cost" => min
@@ -347,18 +347,18 @@ objectives {
 		"performance" => max
 }
 
-------------------------------------------------------------------------------------------------------------------------
+```
 All the deployments returned by the IOP will be ranked using the cost as reference, choosing the solution with the less 
 cost the first one to appear. On the contrary, if the user introduces the following objectives:
 
-------------------------------------------------------------------------------------------------------------------------
+```
 
 objectives {
 		"performance" => max
 		"availability" => max
 }
 
-------------------------------------------------------------------------------------------------------------------------
+```
 
 The performance will be the reference to rank the returned solutions, choosing these solutions with the best performance 
 as the best ones.