%%% ejemplos.tex --- 

%% Author: Giménez, Christian
%% Version: $Id: ejemplos.tex,v 0.0 2016/09/14 16:32:13 christian Exp$

% Copyright 2016 Giménez, Christian
  
% This program is free software: you can redistribute it and/or modify
% it under the terms of the GNU General Public License as published by
% the Free Software Foundation, either version 3 of the License, or
% (at your option) any later version.

% This program is distributed in the hope that it will be useful,
% but WITHOUT ANY WARRANTY; without even the implied warranty of
% MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
% GNU General Public License for more details.

% You should have received a copy of the GNU General Public License
% along with this program.  If not, see <http://www.gnu.org/licenses/>.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%% Cualquier duda ejecutar texdoctk.

%\chapter{Ejemplos de Uso}
\section{Ejemplo de Funcionamiento de Prototipo de \emph{crowd}}
\label{sec:ejemplos}
%% \germanin{18-1-2017}{Quizas dejemos el ejemplo grande. Mirar paper de ICOM.}

% A continuación se mostrará un ejemplo de la interfaz de \crowd{} que ayudará a comprender su funcionamiento y la forma en que el usuario interactúa. Aunque estos ejemplos sean muy reducidos, cabe aclarar que la herramienta puede soportar diagramas más grandes, sin embargo para el propósito de esta sección nos avocaremos a usar apenas tres clases y herencia.\chris{01-01-2017}{¿Armo un ejemplo mucho más grande?}

% \section{Ejemplo Consistente}

% En la Figura \ref{fig:ej_satis} se puede observar un diagrama de clases UML dibujado directamente sobre una interfaz web, el cual la herramienta provee de todos los elementos necesarios para crear y editar éste modelo en conjunto con un panel denominado ``Detalles'' para poder ver los detalles avanzados de los resultados de la traducción y el proceso de razonamiento.

% \begin{figure}[h]
%   \centering

%   \includegraphics[width=5.5cm]{ejemplo-satisfacible.png}
  
%   \caption[Ejemplo de diagrama satisfacible.]{Interfaz mostrando un ejemplo de un diagrama UML satisfacible.}
%   \label{fig:ej_satis}
% \end{figure}

% La interfaz mantiene en el explorador el modelo conceptual diseñado en forma de clases Javascript que luego, al momento en que el usuario solicite el chequeo de satisfacibilidad o una traducción, serán procesadas en un string de sintaxis JSON fácil de interpretar por un usuario y por el servidor. Para el caso de nuestro ejemplo, la Figura \ref{fig:json_ejemplo} muesta su traducción en esta sintaxis, la cual posee tres claves: ``classes'' que enumera las clases del modelo y sus detalles; ``links'' que enumera las relaciones entre estas clases y sus detalles, pueden ser de tipo Is-A (``generalization'') o asociaciones ``association'' y ``owllink'' posee el código OWLlink ingresado por el usuario en el panel de detalles. 

% \begin{figure}[h]
%   \centering
%   \footnotesize
% \begin{verbatim}
% {"classes":[
%     {"name":"A", "attrs":[], "methods":[]},
%     {"name":"B", "attrs":[], "methods":[]},
%     {"name":"C", "attrs":[], "methods":[]}],
%  "links":[
%      {"name":"r1", "classes":["B","C"], "multiplicity":null,
%       "type":"generalization", "parent":"A", "constraint":[]},
%      {"name":"r2", "classes":["C"], "multiplicity":null,
%       "type":"generalization", "parent":"B", "constraint":[]}],
%  "owllink":""}
% \end{verbatim}
  
%   \caption{Código JSON generado por la interafaz a partir del diagrama de la Figura \ref{fig:ej_satis}.}
%   \label{fig:json_ejemplo}
% \end{figure}

% El usuario puede, por consecuencia, realizar dicho modelo y posteriormente chequear su consistencia por medio de un boton en la esquina superior izquierda el cual simula un semáforo con tres luces de color roja, amarilla y verde, el cual cambiará de estado dependiendo de los resultados del proceso previamente explicado en la sección \ref{sec:chequeo_satis}. Actualmente, en el momento de escribir éste texto, asignamos el color rojo para cuando el diagrama proveído es insatisfacible, verde para cuando lo es y todos los colores encendidos para cuando aún no se ha solicitado un chequeo de consistencia.

% Al hacer clic en este botón, el servidor recibe una petición HTTP POST con la representación del modelo en sintaxis JSON , ésta es traducida según la estrategia definida en \cite{DBLP:journals/ai/BerardiCG05} (véase la sección \ref{sec:UML-a-DL} para detalles acerca de la representación de diagramas UML a \DL{} y \ref{sec:mod_trad} para detalles del módulo traductor). Éste módulo genera un documento OWLlink listo para ser enviado al razonador con las consultas incluídas, el resultado para nuestro ejemplo se puede observar en la Figura \ref{fig:owllink_ejemplo}. Éste archivo en sintaxis XML posee la sección \TELL{} con la traducción del modelo conceptual a \DL{} en OWL 2 y luego las consultas necesarias para poder chequear la satisfacibilidad de la KB y cada una de las clases.

% \begin{figure}[h]
%   \centering
%   \footnotesize
% \begin{verbatim}
% <?xml version="1.0" encoding="UTF-8"?>
% <RequestMessage xmlns="http://www.owllink.org/owllink#" xmlns:owl="http://www.w3.org/2002/07/owl#"
% 		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
% 		xsi:schemaLocation="http://www.owllink.org/owllink# http://www.owllink.org/owllink-20091116.xsd">
%   <CreateKB kb="http://localhost/kb1"/>
%   <Tell kb="http://localhost/kb1">
%     <owl:SubClassOf>
%       <owl:Class IRI="A"/><owl:Class abbreviatedIRI="owl:Thing"/>
%     </owl:SubClassOf>
%     <owl:SubClassOf>
%       <owl:Class IRI="B"/><owl:Class abbreviatedIRI="owl:Thing"/>
%     </owl:SubClassOf>
%     <owl:SubClassOf>
%       <owl:Class IRI="C"/><owl:Class abbreviatedIRI="owl:Thing"/>
%     </owl:SubClassOf>
%     <owl:SubClassOf>
%       <owl:Class IRI="B"/><owl:Class IRI="A"/>
%     </owl:SubClassOf>
%     <owl:SubClassOf>
%       <owl:Class IRI="C"/><owl:Class IRI="A"/>
%     </owl:SubClassOf>
%     <owl:SubClassOf>
%       <owl:Class IRI="C"/><owl:Class IRI="B"/>
%     </owl:SubClassOf>
%   </Tell>
%   <IsKBSatisfiable kb="http://localhost/kb1"/>
%   <IsClassSatisfiable kb="http://localhost/kb1">
%     <owl:Class IRI="A"/>
%   </IsClassSatisfiable>
%   <IsClassSatisfiable kb="http://localhost/kb1">
%     <owl:Class IRI="B"/>
%   </IsClassSatisfiable>
%   <IsClassSatisfiable kb="http://localhost/kb1">
%     <owl:Class IRI="C"/>
%   </IsClassSatisfiable>
% </RequestMessage>
% \end{verbatim}
%   \caption{Código OWLlink generado a partir del diagrama de la Figura \ref{fig:ej_satis}.}
%   \label{fig:owllink_ejemplo}
% \end{figure}

% Luego de que el razonador procese la entrada, emite una respuesta en formato OWLlink la cual consiste en un elemento ``KB'' indicando que la base de conocimiento fue creada, un ``OK'' afirmando que la declaración \TELL{} y el OWL 2 enviado ha sido incorporado a esta base de conocimiento exitosamente, y una serie de elementos XML ``BooleanResponse'' indicando los resultados de las consultas realizadas respectivamente. La Figura \ref{fig:owllink_res_ejemplo} muestra la respuesta del razonador para nuestro ejemplo, indentanda apropiadamente para su legibilidad.

% \begin{figure}[h]
%   \centering
%   \footnotesize
% \begin{verbatim}
% <?xml version="1.0" encoding="UTF-8"?>
% <ResponseMessage xmlns="http://www.owllink.org/owllink#"
%                  xmlns:owl="http://www.w3.org/2002/07/owl#">
%   <KB kb="http://localhost/kb1"></KB>
%   <OK></OK>
%   <BooleanResponse result="true"></BooleanResponse>
%   <BooleanResponse result="true"></BooleanResponse>
%   <BooleanResponse result="true"></BooleanResponse>
%   <BooleanResponse result="true"></BooleanResponse>
% </ResponseMessage>
% \end{verbatim}
%   \caption{Respuesta del razonador ante la entrada de OWLlink del ejemplo dado en \ref{fig:ej_satis}.}
%   \label{fig:owllink_res_ejemplo}
% \end{figure}

% Éste XML es analizado por el módulo Analizador de Respuesta para obtener los resultados de las consultas deseados y procesar un JSON que sea útil para la interfaz. Actualmente, el resultado del módulo provee sólo información de satisfacibilidad y la entrada y salida del rasonador (expuestas en las Figuras mencionadas anteriormente). La Figura \ref{fig:res_server_ejemplo} muestra el resultado de éste procesado y posterior respuesta de la petición HTTP POST de parte del servidor.

% \begin{figure}
%   \centering
%   \footnotesize
% \begin{verbatim}
% {"satisfiable":
%  {"kb":true,
%   "classes":["Test Class","B","C"]},
%  "unsatisfiable":{"classes":[]},
%  "suggestions":{"links":[]},
%  "reasoner":{
%      "input":"<?xml version=\"1.0\" encoding=\"UTF-8\"?> [...] ",
%      "output":"<?xml version=\"1.0\" encoding=\"UTF-8\"?> [...] "}}
% \end{verbatim}
%   \caption[Respuesta del servidor ante la consulta de satisfacibilidad.]{Respuesta del servidor ante la consulta de satisfacibilidad. Las entradas ``input'' y ``output'' fueron recortadas.}
%   \label{fig:res_server_ejemplo}
% \end{figure}

% \section{Ejemplo Inconsistente}
% \germanin{18-1-2017}{Lo hace crowd esto directamente?}

% Para mostrar el comportamiento de la interfaz ante un caso inconsistente, se propone a Figura \ref{fig:ej_insatis} la cual provee de un diagrama de clases UML con una herencia de tipo disjunta y completa, en otras palabras, cuyas instancias de \texttt{A} no pueden pertenecer a ambos hijos \texttt{B} y \texttt{C} y además, \texttt{A} por sí misma no posee instancias si no son de \texttt{B} o de \texttt{C} respectivamente. Claramente, si la clase \texttt{C} posee una instancia, ésta debe ser también de la clase de \texttt{B} por la herencia que relaciona a estas dos, y por consecuencia falla la disjunción propuesta por la herencia entre \texttt{A} y \texttt{B} y \texttt{C}.

% \begin{figure}
%   \centering

%   \includegraphics[width=5.5cm]{ejemplo-insatisfacible.png}
  
%   \caption[Ejemplo de diagrama satisfacible.]{Interfaz mostrando un ejemplo de un diagrama UML insatisfacible.}
%   \label{fig:ej_insatis}
% \end{figure}

% \begin{figure}
%   \centering\footnotesize
% \begin{verbatim}
% <?xml version="1.0" encoding="UTF-8"?>
% <RequestMessage xmlns="http://www.owllink.org/owllink#" xmlns:owl="http://www.w3.org/2002/07/owl#"
% 		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
% 		xsi:schemaLocation="http://www.owllink.org/owllink# http://www.owllink.org/owllink-20091116.xsd">
%   <CreateKB kb="http://localhost/kb1"/>
%   <Tell kb="http://localhost/kb1">
%     <owl:SubClassOf>
%       <owl:Class IRI="A"/><owl:Class abbreviatedIRI="owl:Thing"/>
%     </owl:SubClassOf>
%     <owl:SubClassOf>
%       <owl:Class IRI="B"/><owl:Class abbreviatedIRI="owl:Thing"/>
%     </owl:SubClassOf>
%     <owl:SubClassOf>
%       <owl:Class IRI="C"/><owl:Class abbreviatedIRI="owl:Thing"/>
%     </owl:SubClassOf>
%     <owl:SubClassOf>
%       <owl:Class IRI="B"/><owl:Class IRI="A"/>
%     </owl:SubClassOf>
%     <owl:SubClassOf>
%       <owl:Class IRI="C"/><owl:Class IRI="A"/>
%     </owl:SubClassOf>
%     <owl:SubClassOf>
%       <owl:Class IRI="B"/>
%       <owl:ObjectComplementOf>
% 	<owl:Class IRI="C"/>
%       </owl:ObjectComplementOf>
%     </owl:SubClassOf>
%     <owl:SubClassOf>
%       <owl:Class IRI="A"/>
%       <owl:ObjectUnionOf>
% 	<owl:Class IRI="B"/><owl:Class IRI="C"/>
%       </owl:ObjectUnionOf>
%     </owl:SubClassOf>
%     <owl:SubClassOf>
%       <owl:Class IRI="C"/><owl:Class IRI="B"/>
%     </owl:SubClassOf>
%   </Tell>
%   <IsKBSatisfiable kb="http://localhost/kb1"/>
%   <IsClassSatisfiable kb="http://localhost/kb1">
%     <owl:Class IRI="A"/>
%   </IsClassSatisfiable>
%   <IsClassSatisfiable kb="http://localhost/kb1">
%     <owl:Class IRI="B"/>
%   </IsClassSatisfiable>
%   <IsClassSatisfiable kb="http://localhost/kb1">
%     <owl:Class IRI="C"/>
%   </IsClassSatisfiable>
% </RequestMessage>
% \end{verbatim}
%   \caption{Representación OWLlink del diagrama insatisfacible de la Figura \ref{fig:ej_insatis}.}
%   \label{fig:owllink_ej_insatis}
% \end{figure}

% \begin{figure}
%   \centering\footnotesize
% \begin{verbatim}
% {"classes": [
%     {"name":"A","attrs":[],"methods":[]},
%     {"name":"B","attrs":[],"methods":[]},
%     {"name":"C","attrs":[],"methods":[]}],
%  "links":[
%      {"name":"r1", "classes":["B","C"], "multiplicity":null,
%       "type":"generalization", "parent":"A",
%       "constraint":["disjoint","covering"]},
%      {"name":"r2", "classes":["C"], "multiplicity":null,
%       "type":"generalization", "parent":"B",
%       "constraint":[]}],
%  "owllink":""}
% \end{verbatim}
%   \caption{Representación JSON generada por la interfaz a partir del diagrama de la Figura \ref{fig:ej_insatis}.}
%   \label{fig:json_ej_insatis}
% \end{figure}

% \begin{figure}
%   \centering
% \begin{verbatim}
% {"satisfiable": {"kb":true, "classes":["A","B"]},
%  "unsatisfiable":{"classes":["C"]},
%  "suggestions":{"links":[]},
%  "reasoner":{
%      "input":"<?xml version=\"1.0\" encoding=\"UTF-8\"?> [...]",
%      "output":"<?xml version=\"1.0\" encoding=\"UTF-8\"?> [...]"}}
% \end{verbatim}
%   \caption[Respuesta del servidor ante la consulta de satisfacibilidad de la Figura \ref{fig:ej_insatis}.]{Respuesta del servidor ante la consulta de satisfacibilidad de la Figura \ref{fig:ej_insatis}. Las entradas ``input'' y ``output'' fueron recortadas.}
%   \label{fig:resp_ej_insatis}
% \end{figure}

% \begin{figure}
%   \centering\footnotesize
% \begin{verbatim}
% <?xml version="1.0" encoding="UTF-8"?>
% <ResponseMessage xmlns="http://www.owllink.org/owllink#"
% 		 xmlns:owl="http://www.w3.org/2002/07/owl#">
%   <KB kb="http://localhost/kb1"></KB>
%   <OK></OK>
%   <BooleanResponse result="true" warning="Unsatisfiable classes: (*BOTTOM* BOTTOM
% file:///var/www/html/wicom/run/input-file.owllinkC)"></BooleanResponse>
%   <BooleanResponse result="true"></BooleanResponse>
%   <BooleanResponse result="true"></BooleanResponse>
%   <BooleanResponse result="false"></BooleanResponse>
% </ResponseMessage>
% \end{verbatim}
%   \caption{Respuesta del razonador ante la entrada de OWLlink del ejemplo dado en \ref{fig:ej_insatis}.}
%   \label{fig:resp_raz_ej_insatis}
% \end{figure}

% \todo[inline]{Escribir pasos intermedios y códigos XML y JSON que se intercambian.}

% \chapter{Ejemplos}
%% \germanin{18-1-2017}{Unir con el cap de arriba} % DONE
En esta sección se mostrará la arquitectura en funcionamiento utilizando el prototipo explicado previamente. Se explicarán dos casos, uno satisfacible y el otro insatisfacible, para comparar la reacción del programa.

En la sección \ref{sec:mod_con_sat} se podrá visualizar la interfaz y se explicará el proceso interno que el prototipo realiza. El modelo conceptual, en este caso, será consistente y por ende, el prototipo deberá responder de la misma manera, por lo que se aprovechará a explicar las respuestas descriptas en la interfaz gráfica.

Luego, se presentará el mismo modelo conceptual, pero con unas leves modificaciones para que resulte inconsistente, con la intención de mostrar cómo se comporta la interfaz gráfica ante esta situación y las diferencias en el funcionamiento interno del prototipo. Es interesante y de importancia para el usuario obtener cómo se representa esta inconsistencia en la interfaz, además de cómo analizar los datos proveídos por el prototipo, para poder comprender qué sucede y corregir su modelo rápidamente.

Con la intención de facilitar la lectura, los códigos completos a los que se hará referencia podrán observarse en el Apéndice \ref{sec:apendice secuencias},
% \chris{24-11}{Agus: preguntar}
ordenados según como se van generando en el proceso de traducción y verificación de satisfacibilidad. 

\subsection{Modelo Conceptual Satisfacible}
\label{sec:mod_con_sat}
En \cite{DBLP:journals/ai/BerardiCG05} se presenta un modelo conceptual sencillo que es consistente y una posible traducción a \ALCQI{} del mismo. Dicho modelo se muestra en la Figura \ref{fig:mod_con_con}.

El usuario puede desarrollar este mismo modelo. Primeramente, por medio de un panel de herramientas se puede crear todas las clases del mismo.
Para facilitar el modelado, las relaciones se crean utilizando un menú contextual que se activa sobre la clase creada, en él se puede brindar el nombre, seleccionar la multiplicidad y determinar las clases relacionadas. Actualmente, se soportan las multiplicidades de cero a muchos ($0 \ldots *$), de uno a muchos ($1 \ldots *$), de uno a uno ($1 \ldots 1$) y de cero a uno ($0 \ldots 1$). La herencia también puede ser dibujada por medio del mismo menú, activando el tipo de restricción (disjunto y/o completa) y seleccionando las clases hijas.

Al diseñar el modelo, por cada acción del usuario se modifica una representación de éste en el motor Javascript del explorador web, el cual no sólo controla y responde las acciones del usuario, sino también almacena la información para luego ser traducida en una sintaxis transportable al servidor.

%% \germanin{18-1-2017}{No estoy seguro si capturar la tool o hacerlo UML dibujado en latex. Despues podemos mostrar la tool o describirla.}

\begin{figure}[h]
  \centering
  \includegraphics[width=\textwidth]{captura-ejemplo-satisfacible.png}
  \caption{Modelo conceptual consistente extraído de \cite{DBLP:journals/ai/BerardiCG05}.}
  \label{fig:mod_con_con}
  \label{fig:ej_satis}
\end{figure}

Una vez finalizada la creación del modelo de la Figura \ref{fig:ej_satis}, el usuario puede solicitar al prototipo su evaluación por consistencia. Al hacerlo, el modelo Javascript genera una representación en JSON para ser enviada al servidor y posteriormente traducido a lógica descriptiva. El explorador web queda a la espera de la respuesta a su petición HTTP para procesarla y mostrar los resultados. En el apéndice en la Figura \ref{fig:ej_mod_json} puede verse la representación en JSON generada y enviada al servidor.

En el servidor, se recibe esta petición y el modelo se traduce a \DL{} generando una sintaxis OWL 2 como la que se muestra en la Figura \ref{fig:ej_mod_owl}. A este texto se le incorpora una serie de consultas para determinar la consistencia del modelo, las cuales son anexadas al final cuando se genera el documento OWLlink. La Figura \ref{fig:ej_mod_queries} y la Figura \ref{fig:ej_mod_owllink_final} presentan las consulta para el ejemplo dado y un template donde puede visualizarse el lugar donde aparecen las distintas secciones presentadas. 

Una vez generado el documento OWLlink completo, éste es enviado al razonador para que sea procesado y genere una respuesta, que poseerá el formato que se describe en el estándar OWLlink\footnote{\url{https://www.w3.org/Submission/2010/SUBM-owllink-structural-specification-20100701/}} y en \cite{conicet:Liebig_owllink:dig}. Se presenta una posible respuesta del razonador RACER usado para este ejemplo en la Figura \ref{fig:ej_mod_resp}.

Esta respuesta es analizada para determinar qué clases son las inconsistentes y producir un texto en formato JSON para el cliente. La respuesta, presentada en la Figura \ref{fig:ej_mod_json_resp}, posee los datos que requiere la interfaz: qué clases son inconsistentes, cuáles no lo son, y los textos en formato XML de entrada y salida del razonador.

Finalmente, la interfaz recibe la respuesta del servidor y la procesa mostrando al usuario los resultados: colorea una tonalidad rojiza las clases que figuran en el campo ``unsatisfiable'', restaura el color a las clases que se nombran en ``satisfiable'', agrega la entrada y salida del razonador en las áreas de textos que corresponden. Por último, carga la imagen de un semáforo con el color correspondiente que indica la consistencia del modelo. Actualmente hemos decidido que el color verde será utilizado cuando todo el modelo es consistente y rojo cuando alguna clase sea inconsistente.

\subsection{Modelo Conceptual Insatisfacible}
\label{sec:mod_con_ins}
Para mostrar el funcionamiento del prototipo sobre un modelo insatisfacible, partiremos del modelo presentado en la sección anterior con unas ligeras modificaciones que lo harán inconsistente, ambos fueron extraídos de \cite{DBLP:journals/ai/BerardiCG05}.

%% \chrisin{24-11}{Agus: Incluir captura de crowd}

\begin{figure}[h]
  \centering
  \includegraphics[width=\textwidth]{captura-ejemplo-insatisfacible.png}
  \caption{Modificación de la Figura \ref{fig:ej_satis} para que el modelo sea insatisfacible.}
  \label{fig:ej_insatisfacible}
\end{figure}

A partir de la Figura \ref{fig:ej_satis}, se le incorpora una asociación de herencia entre la clase ``FixedPhone'' y la clase ``CellPhone'' para hacer inconsistente al modelo, debido a que la restricción de completa y disjunta no puede permitir que una clase hija tenga relación Is-A de otra clase hija. El resultado se muestra en la Figura \ref{fig:ej_insatisfacible}.

Al realizar el dibujo, el JSON que representa al modelo y que será enviado al servidor, incluirá dentro del campo ``links'' una relación más al final. La Figura \ref{fig:ej_insatisfacible_json} muestra una porción del código agregado junto con unas líneas del código anterior para poder determinar el contexto donde fue modificado. Esto, por consecuencia, será traducido por el servidor junto con el resto del modelo utilizado en la sección anterior, pero agregando lo necesario para respetar la semántica de la nueva generalización. Puede observar en la Figura \ref{fig:ej_insatisfacible_xml_in} la representación OWL 2 de la nueva asociación agregada al resto de la traducción de la Figura \ref{fig:ej_mod_owl}.

En cuanto a las consultas generadas por el módulo respectivo no sufren ninguna modificación pues no hay nuevas clases en el modelo. Por ello, el OWLlink resultante es similar al anterior siguiendo el mismo formato presentado en la Figura \ref{fig:ej_mod_owllink_final} con el texto OWL 2 modificado y las mismas consultas de la Figura \ref{fig:ej_mod_queries}.

El razonador, al recibir este texto, emitirá una respuesta diferente. Si observamos las últimas líneas de la representación OWL 2 nos encontramos con los siguiente predicados \ALCQI{}:\\ \obeycr

$CellPhone \sqsubseteq Phone$
$FixedPhone \sqsubseteq Phone$
$CellPhone \sqsubseteq ( \lnot FixedPhone )$
$Phone \sqsubseteq (CellPhone \sqcup FixedPhone)$
$CellPhone \sqsubseteq FixedPhone$ (Sentencia agregada)
\restorecr

El absurdo se encuentra al intentar indicar que las instancias de CellPhone están en el complemento de FixedPhone por la tercer sentencia, y también se encuentran dentro de FixedPhone por la última sentencia agregada. Esto no puede ser posible, una instancia es un FixedPhone o es su complemento, no es posible ambas.

Esto lleva a que el razonador responda lo expresado en la Figura \ref{fig:ej_insatisfacible_out}. Obsérvese que la anteúltima respuesta booleana, que corresponde con la consulta si CellPhone es satisfacible (véase las consultas en la Figura \ref{fig:ej_mod_queries}), indica que la clase no es consistente.

Luego, el módulo \texttt{Analizador de Respuestas} producirá el texto en formato JSON de la Figura \ref{fig:ej_insatisfacible_json_resp}  para ser enviado a la interfaz, la que podrá indicarle al usuario los resultados del razonador.

La Figura \ref{fig:ej_insatisfacible}, posee la clase CellPhone coloreado de una tonalidad rojiza y un reborde más grueso, indicando que no puede poseer instancias puesto que es inconsistente bajo el modelo conceptual dado por el usuario. De esta manera, el usuario deberá enfocar su atención a las clases señaladas por la interfaz para corregir su diseño.


%%% Local Variables: 
%%% mode: latex
%%% TeX-master: "../tesis"
%%% TeX-PDF-mode: t
%%% coding: utf-8-unix
%%% End: 
