userguide now contains all changes to the mm aswell as the changes made by Simon Spinner

chapters/performance_model/chapter_applicationlevel_resourcelandscape.tex

@@ -647,7 +647,7 @@ Figure~\ref{fig:m-example_deployment} shows an exemplary deployment of the runni
 	\label{fig:m-example_deployment}
 \end{figure}
 
-There is a datacenter that consists of two \model{ComputingInfrastructure}s, namely an \instance{ApplicationServer} and a \instance{DatabaseServer}. The servers' CPUs are modeled as active resources. The CPU of the \instance{ApplicationServer} consists of two processing units at a processing rate of 2.66~GHz. The \instance{DatabaseServer} CPU has eight processing units at a processing rate of 2.8~GHz. 
+There is a datacenter that consists of two \model{ComputeNodes}s, namely an \instance{ApplicationServer} and a \instance{DatabaseServer}. The servers' CPUs are modeled as active resources. The CPU of the \instance{ApplicationServer} consists of two processing units at a processing rate of 2.66~GHz. The \instance{DatabaseServer} CPU has eight processing units at a processing rate of 2.8~GHz. 
 The \instance{WebShop} instance is deployed on the \instance{ApplicationServer} node, a \instance{SQLDB} instance is deployed on to the \instance{DatabaseServer} node.
 
 %##################################################

chapters/performance_model/resource_landscape_model.tex

@@ -20,15 +20,15 @@ and the performance influences of the different resource layers.
 
 \Cref{fig:mm-resourcelandscape-diagram} depicts an overview of the structure of the resource landscape meta-model as a UML class diagram. 
 The root entity comprising all other model elements is the \model{DistributedDataCenter}, which consists of one or more \model{DataCenters}. 
-\model{DataCenters} contain \model{HardwareInfrastructures} which are either one of the three hardware infrastructure types \model{ComputingInfrastructure}, \model{NetworkInfrastructure}, and \model{StorageInfrastructure}, or \model{CompositeHardwareInfrastructure}. 
-A \model{CompositeHardwareInfrastructure} is a structuring element to group further \model{HardwareInfrastructures}.
+\model{DataCenters} contain \model{ComputeNodes}, \model{StorageNodes}, and \model{CompositeHardwareInfrastructure}. 
+A \model{CompositeHardwareInfrastructure} is a structuring element to group further \model{Compute-} and \model{StorageNodes}.
 For example, it can be used to combine servers to a cluster or to group them in a server rack. 
 Current architecture-level performance models usually abstract from these details and do not provide constructs to model the resource hierarchy and containment relationships explicitly. 
 However, for resource management at run-time, the description of the resource landscape and hierarchy of resources is crucial to improve reasoning about suitable adaptation operations, e.g., to decide if a VM can be migrated and where it should be migrated to.
 Here, the novel aspect of our meta-model is that it allows to model the distribution of resources within and across data centers as well as their individual configuration.
 
-When designing the resource landscape meta-model, we aimed at a generic approach to cover all types of infrastructure with the focus on \model{ComputingInfrastructure}. 
-More details on modeling storage and network infrastructures (i.e., the \model{StorageInfrastructure} and \model{NetworkInfrastructure} entities in the meta-model) can be found in the work of \cite{noorshams2013a,noorshams2013b,noorshams2013c} and \cite{RyKoZs2013-ThroughputPrediction,RyZsKo2013-DNI-meta-model}, respectively.
+When designing the resource landscape meta-model, we aimed at a generic approach to cover all types of infrastructure with the focus on \model{ComputeNode}. 
+More details on modeling storage and network infrastructures (i.e., the \model{StorageNodes} entities in the meta-model) can be found in the work of \cite{noorshams2013a,noorshams2013b,noorshams2013c}.
 
 \subsubsection{Containers and Containment Relationships}
 \label{ssec:mm-containers}
@@ -37,8 +37,8 @@ A common reappearing pattern in modern distributed IT service infrastructures is
 This leads to a tree of nested system entities that may change during runtime because of virtual machine migration, hardware or software failures, etc.
 % Because of this flexibility one single execution environment consisting of similar, reoccurring elements can have multiple different configuration states at run-time. 
 The central element of our resource landscape meta-model to model these nested layers of resources is the abstract entity \model{Container}, depicted in \Cref{fig:mm-resourcelandscape-diagram}.
-We distinguish between two major concrete container entities: the \model{ComputingInfrastructure} and the \model{RuntimeEnvironment}. 
-The \model{ComputingInfrastructure} forms the root element in our hierarchy of containers and corresponds to a physical machine within a data center. 
+We distinguish between two major concrete container entities: the \model{ComputeNode} and the \model{RuntimeEnvironment}. 
+The \model{ComputeNode} forms the root element in our hierarchy of containers and corresponds to a physical machine within a data center. 
 This entity cannot be contained in another container, but it may have nested containers (\model{RuntimeEnvironments}). 
 The \model{RuntimeEnvironment} is the second type of container.
 It can contain further \model{RuntimeEnvironments}.
@@ -88,7 +88,7 @@ Also, we can assume that model instances can be built automatically or with tool
 \label{ssec:mm-resource_configuration_specification}
 
 Each \model{Container} has its own specific resource configurations that describe the container's influence on the system performance. 
-In our meta-model, we distinguish between three different types of configuration specifications: \model{ActiveResourceSpecification}, \model{PassiveResourceSpecification}, and \model{CustomConfigurationSpecification}, depicted in \Cref{fig:mm-resource_configuration_diagram}.
+In our meta-model, we distinguish between three different types of configuration specifications: \model{ProcessingResourceSpecification}, \model{LinkingResourceSpecification}, \model{PassiveResourceSpecification}, and \model{CustomConfigurationSpecification}, depicted in \Cref{fig:mm-resource_configuration_diagram}.
 
 \begin{figure}[ht]
    \centering
@@ -208,7 +208,7 @@ showing the hierarchy of the different resources as well as their configuration
    \label{fig:resource_landscape_example}
 \end{figure}
 
-The root element is the local \model{DataCenter} in our computer science department at KIT, which contains a \model{CompositeHardwareInfrastructure} (a cluster environment called \instance{AcamarCluster}), and a separate \model{ComputingInfrastructure}, the \instance{DatabaseServer}.
+The root element is the local \model{DataCenter} in our computer science department at KIT, which contains a \model{CompositeHardwareInfrastructure} (a cluster environment called \instance{AcamarCluster}), and a separate \model{ComputeNode}, the \instance{DatabaseServer}.
 % Other infrastructure of the data center that is not part of our experiments is omitted in the figure.
 The cluster in this example consists of five \instance{ComputeNodes}, connected by a 1~Gbit Ethernet LAN. 
 Each compute node runs XenServer~5.5 as a hypervisor. 
@@ -219,11 +219,11 @@ To ease the resource configuration specification of the other containers, we use
 
 The resource configuration specification templates for the different container types are stored in the \instance{ExperimentEnvironmentContainerSpecs} container repository. 
 The \instance{Compute\-NodeTemplate} specifies the hardware resource configuration of the cluster compute nodes.
-A compute node has two \model{ActiveResourceSpecifications} modeling its two CPUs.
+A compute node has two \model{ProcessingResourceSpecifications} modeling its two CPUs.
 Each has four cores with 2.66~GHz and \model{PROCESSOR\_SHARING} as scheduling policy.
 The \instance{XenServer5.5Template} is a template for a \model{RuntimeEnvironment} of class \model{HYPERVISOR}. 
 It refers to a \model{CustomConfigurationSpecification}, which refers to a \model{CustomResourceConfigurationModel} for the XenServer~5.5 hypervisor.
 Further details of this custom model have been presented in \cite{HuQuHaKo2011-CLOSER-ModelVirtOverhead}.
 Finally, the \instance{VMTemplate} specifies the configuration of the VMs hosted by the XenServer.
-This \model{RuntimeEnvironment} is of class \model{OS\_VM} and has only one \model{ActiveResourceSpecification} for its VCPU.
+This \model{RuntimeEnvironment} is of class \model{OS\_VM} and has only one \model{ProcessingResourceSpecification} for its VCPU.
 It has two cores with 2.66~GHz and \model{PROCESSOR\_SHARING} as scheduling policy.
\ No newline at end of file

chapters/titlepage.aux

+\relax 
+\providecommand\hyper@newdestlabel[2]{}
+\@setckpt{chapters/titlepage}{
+\setcounter{page}{2}
+\setcounter{equation}{0}
+\setcounter{enumi}{0}
+\setcounter{enumii}{0}
+\setcounter{enumiii}{0}
+\setcounter{enumiv}{0}
+\setcounter{footnote}{0}
+\setcounter{mpfootnote}{0}
+\setcounter{part}{0}
+\setcounter{chapter}{0}
+\setcounter{section}{0}
+\setcounter{subsection}{0}
+\setcounter{subsubsection}{0}
+\setcounter{paragraph}{0}
+\setcounter{subparagraph}{0}
+\setcounter{figure}{0}
+\setcounter{table}{0}
+\setcounter{parentequation}{0}
+\setcounter{Item}{0}
+\setcounter{Hfootnote}{0}
+\setcounter{bookmark@seq@number}{0}
+\setcounter{ContinuedFloat}{0}
+\setcounter{subfigure}{0}
+\setcounter{subtable}{0}
+\setcounter{example}{0}
+\setcounter{lstnumber}{1}
+\setcounter{su@anzahl}{0}
+\setcounter{LT@tables}{0}
+\setcounter{LT@chunks}{0}
+\setcounter{ecnt}{0}
+\setcounter{section@level}{0}
+\setcounter{lstlisting}{0}
+}