% \chapter{Arquitectura Propuesta}
\hyphenation{me-ta-mo-de-lo res-pues-ta}
\chapter{\crowd{}: Su Arquitectura}
\label{sec:arquitectura}
En el presente capítulo vamos a sintetizar los conceptos presentados anteriormente en una arquitectura Web, la cual está enmarcada en el Proceso de Visualización presentado en \cite{gbraun:ontobras:gbraun2016}, cuya finalidad es la de mejorar la calidad de los diagramas reduciendo las inconsistencias y/o anomalías.

\crowd{} es una herramienta que hemos desarrollado para implementar dicha arquitectura. La misma fue diseñada con la posibilidad de que funcione como un servicio Web de capacidades escalables y extensibles, en especial con respecto al lenguaje gráfico y a su codificación a un lenguaje formal. Por ello, la arquitectura está dividida en dos partes: el cliente y el servidor. En este capítulo, detallaremos sus estructuras, la comunicación entre ambas partes y las relaciones entre sus módulos internos.

Se utilizará las Lógicas Descriptivas como un medio para dotar a esta herramienta de una codificación de los modelos que posibilita el razonamiento automático. Esto nos permite detectar propiedades formales relevantes como las inconsistencias o las redundancias \cite{DBLP:journals/ai/BerardiCG05}. Para hacer posible esto, la arquitectura debe contemplar la codificación y el razonamiento de una serie de consultas sobre la ontología resultante a partir del modelo proveído por el usuario.

%% Asimismo, revisamos la relación entre estas lógicas y el lenguaje de ontologías OWL, enfatizando sobre su uso para la construcción de documentos Web semánticos. Finalizamos con un ejemplo dónde relacionamos los conceptos presentados, comenzando por una especificación gráfica en UML, y generando un documento OWL para luego describir el dominio utilizando la lógica \ALCQI{}.  


La organización del presente capítulo es la siguiente: primero, se presenta el Proceso de Visualización para Modelado Conceptual Ontológico y la relación con \crowd{}. Luego, en la sección \ref{sec:diseño}, se describe la arquitectura junto con los módulos que la componen, partiendo de una descripción del cliente y posteriormente del servidor, para finalmente detallar cómo se realiza el servicio de razonamiento para chequear la satisfacibilidad del modelo del usuario. 

% \chris{07-06}{Completar} % DONE

\section{\crowd{} y el Proceso de Visualización para Modelado Conceptual Ontológico}
\label{cap:arq_prop}
\label{sec:modelado asistido}

%% \germanin{15-05-2017}{Acá vamos a resumir el paper de ontobras donde justificamos la necesidad de nuestra tool. Explicar un poco el diagrama y decir qué vamos a trabajar sobre la arquirectura para implementarlo. No mucho ya que está la referencia al paper.} %% -> DONE
%% \chrisin{16-05-2017}{¿Te referís al diagrama \ref{fig:arquitectura}?}
%% \germanin{18-1-2017}{Acá retomaría la importancia de las tools con soporte lógico y para modelado. Luego hablar del diseño.} %% Creo que agregué lo más importante {24-02-2017}.


\begin{figure}[h]
  \centering
  \includegraphics[width=\linewidth]{dia/crowd-vis-flow-no-quality.png}
  \caption{Esquema del Proceso de Visualización para Modelado Conceptual Ontológico.}
  \label{fig:visprocess-example}
\end{figure}

En \cite{gbraun:ontobras:gbraun2016} hemos presentado el Proceso de Visualización de conocimiento que se concibe con la intención de mejorar la calidad de los diagramas reduciendo las inconsistencias y/o anomalías. Además, posee los siguientes objetivos: la integración entre las representaciones visuales y las capacidades de razonamientos lógicos; la definición de qué es relevante y cómo debe ser representado visualmente y el uso de las representaciones gráficas como fuente de evaluación de la calidad de los modelos y su correspondencia con el dominio que se está modelando.

Este proceso consta de una iteración cíclica que comienza por convertir hechos propios del dominio en formas visuales. Luego, se describen los hechos en un lenguaje de modelado bien definido. Estas formas visuales se mapean a una ontología, para poder posteriormente razonar sobre ella. Finalmente, se muestran los resultados asociándolos al mismo lenguaje gráfico.

Como se muestra en la Figura \ref{fig:visprocess-example}, el proceso se divide en tres niveles: nivel de datos, de conceptos y lógico. El primero, incluye los hechos ontológicos extraídos de los datos del dominio a ser representado en un modelo conceptual. El segundo, es el nivel conceptual que envuelve a los usuarios en la obtención y exploración de conceptos de las diferentes formalizaciones lógicas para representar los diagramas, siendo estos manipulados por motores gráficos. Tercero, el nivel lógico incluye el mapeo gráfico-lógico aportando un soporte formal para guiar el proceso.

El núcleo del proceso se encuentra en el mapeo gráfico-lógico, cuyo objetivo es coordinar las diferentes formas de codificar las primitivas gráficas en un formalismo lógico decidible. La función $\theta$ se define como la unión entre las representaciones lógicas que codifican cada elemento gráfico. Por medio de $\Omega$ y $\Omega{}'$, y sus respectivas ontologías $\mathcal{O}$ y $\mathcal{O}'$ a través de $\theta$ y $\theta^{-1}$, se define la integración del soporte gráfico con razonamiento mostrando los resultados de este último en la misma notación visual.
Por ejemplo, $\Omega$ podría ser una representación gráfica de una ontología en un lenguaje de modelado conceptual, supóngase UML, $\theta$ corresponde con un mapeo de la ontología UML a un lenguaje formal como Lógica Descriptiva. $\mathcal{O}$ en este caso es la traducción del modelo gráfico UML $\Omega$ en \DL{}. Una vez que se llama al razonador, éste devuelve una nueva formalización en \DL{} con posibles cambios, que denominamos $\mathcal{O}'$. En el proceso inverso, la formalización en \DL{} se traduce a su representación gráfica UML, por medio de $\theta^{-1}$, resultando en un nuevo modelo gráfico UML representado por $\Omega'$.

\crowd{} fue desarrollado teniendo como base el Proceso de Visualización incorporándolo dentro de las guías básicas propuestas para este último. Asimismo, el diseño de la arquitectura y sus diferentes módulos corresponden con sus distintas etapas, los cuales serán descriptos en las secciones sucesivas, resultando así en una implementación posible. \crowd{} es una herramienta necesaria para llevar a cabo los tres niveles planteados como receptor de los hechos, como herramienta visual para mostrar la representación de estos diagramas y como herramienta para realizar el mapeo gráfico-lógico final.

Además, el proceso describe la utilización de un metamodelo Keet-Fillottrani (KF metamodel) orientado a ontologías \cite{gbraun:metamodelling, DBLP:conf/ruleml/FillottraniK14, gbraun:metamodelling14}. Éste, está diseñado y formalizado para permitir diferentes vistas del dominio por medio de reconstrucciones lógicas y aserciones intermodelos. Su intención es la de proveer la interoperabilidad, integración y conversión de modelos de datos conceptuales representado en diferentes lenguajes. Para ello, especifica una aproximación para transformar un modelo de un lenguaje a otro de manera que semánticamente permita crear vínculos apropiados entre ellos. Actualmente, esta especificación unifica UML, EER y ORM 2, que aunque aparentan ser similares, poseen sus distinciones semánticas los cuales son contempladas por el metamodelo KF. La formalización del metamodelo se describe en Lógica de Primer Orden y/o \DL{} para unificar las entidades estructurales y sus limitaciones de los lenguajes. %% Esto permite ver el mismo modelo en diferentes representaciones y aumentar la interoperabilidad entre ellos utilizando una representación intermedia basada en una instancia del metamodelo.

\subsection{Modelado Conceptual Asistido por Razonamiento Automático}
El nivel lógico del proceso descripto nos brinda la posibilidad de realizar razonamientos cuyos resultados pueden afectar al modelo conceptual, si el usuario así lo permitiese.

Los modelos conceptuales utilizados a escala industrial pueden resultar largos y complejos de diseñar, analizar y mantener. La expresividad de los lenguajes gráficos pueden llevar a consecuencias implícitas que no son detectadas por el diseñador en diagramas complejos, causando así varias formas de inconsistencias o redundancias. Esto resulta en una degradación en la calidad del diseño y/o en el incremento del tiempo y del costo. En especial, si estos modelos son utilizados como parte de un desarrollo de tipo Model-Driven, la calidad de los modelos pueden influenciar a la de los sistemas implementados (especialmente, si se utiliza un generador de código o se usan los modelos para generar casos de tests) \cite{DBLP:journals/ai/BerardiCG05}.

No sólo la búsqueda de inconsistencias a través del razonamiento es el principal fundamento de la utilización de una formalización en el modelo, sino también, y como se expresa en \cite{Noy01:ontology_development}, la posibilidad de compartir la estructura de la información entre personas o agentes de software; reusar el dominio; hacer las asunciones del dominio explícitas; separar el conocimiento del dominio del conocimiento operacional y analizar el conocimento del dominio.

%No sólo el razonamiento en busca de inconsistencias es el principal fundamento de la utilización de una formalización del modelo. Como lo expresa en \cite{Noy01:ontology_development},
% \chris{03-07-2017}{Chequear validez de la biblio}
% una ontología, en nuestro caso como modelo formal, nos permite compartir la estructura de información entre personas o agentes de software; reusar el dominio; hacer las asunciones del dominio explícitas; separar el conocimiento del dominio del conocimiento operacional y analizar el conocimiento del dominio.
% Similares objetivos cumplen las ontologías en la Web Semántica.\chris{03-07-2017}{No sé si dejarlo acá este párrafo}

\section{Diseño de la Arquitectura}\label{sec:diseño}
Previamente se subrayó la importancia de herramientas que provean de soluciones de calidad para asistir a los desarrolladores en el diseño de ontologías a nivel conceptual. Por ello, se incorpora un soporte lógico y de razonamiento automático, el cual ayudará en el proceso de modelado, así se pueden establecer criterios de calidad claros y medibles.
En nuestro caso, explotaremos el criterio de la coherencia del modelo, generando una codificación formal del modelo gráfico proveído por el usuario a un razonador, con las consultas necesarias que representarán la calidad deseada.
%% Basados en los conceptos previos,
% Por consiguiente, se diseñó una arquitectura que luego fue implementada en nuestro prototipo.
El diseño que presentamos es expansible en varios aspectos importantes, como por ejemplo, se espera a futuro brindar soportes a varios lenguajes gráficos, distintas alternativas de razonadores, varias posibilidades de traducción a \DL{} y varias estrategias de consultas posibles.

Para el diseño se propone una arquitectura cliente-servidor presentada en la Figura \ref{fig:arquitectura}. Ésta, se realizó teniendo en consideración la posibilidad de utilizar tecnologías Web como servidores HTTP, lenguajes HTML, CSS y Javascript que serán detallados en el capítulo \ref{sec:imp}.
\chris{23-11}{Agus: pregunta cuáles. ``Los cuales nos habilita para utilizar tecnologías Web''. \bf Chequear}
Dicha arquitectura incluye una interfaz de usuario para la cual se podrán definir nuevas primitivas gráficas de modelado o se utilizarán primitivas fácilmente reconocibles por el usuario (como por ejemplo: aquellas provenientes de los diagramas de clases UML \cite{gbraun:Booch:2005:UML}, o correspondientes a EER \cite{gbraun:Gogolla:1994:EER}). 

También, se incluye un módulo de traducción a un lenguaje formal, cuyo objetivo es la representación de los modelos conceptuales a una codificación que pueda ser procesada por una herramienta razonador. Hemos optado como lenguaje formal a las Lógicas Descriptivas debido a la semántica precisa y sus diversos niveles de expresividad. La utilización de lógicas más complejas, como la Lógica de Primer Orden (\FOL{}), es excluida de este trabajo ya que las típicas formas de razonamiento usadas en representaciones basadas en estructuras pueden llevarse a cabo usando fragmentos de la expresividad de \FOL{}, reduciendo la complejidad computacional, conclusión que surge a partir de las representaciones usando Frames ó Redes Semánticas puesto que requieren fragmentos de esta lógica \cite{baader03:TDLH_C1, Brachman:1985:RKR}.

El servicio de razonamiento se lleva a cabo cargando al razonador con la representación formal del modelo, y posteriormente, realizando una serie de consultas generadas estratégicamente por su correspondiente módulo. Éste requiere del modelo original para determinar cuáles consultas generar, puesto que estas pueden depender de las primitivas usadas por el usuario y las relaciones entre ellas. Las respuestas generadas por parte del razonador deben ser procesadas dependiendo de las consultas introducidas al razonador. Por consiguiente, el módulo encargado de procesar la salida del razonador estará relacionado al módulo generador de consultas para llevar a cabo la interpretación de la estrategia utilizada al momento de crear las consultas. Por ejemplo, si nuestra intención es determinar si el modelo ofrecido por el usuario tiene una posible instancia, nuestra estrategia puede consistir en consultar al razonador si cada concepto de la representación formal en \DL{} asociado a una primitiva es consistente. Para ello, se generará una consulta de consistencia por cada primitiva y, cuando el razonador las procese, se deberá determinar si existe una respuesta negativa.

La arquitectura presentada permite definir un proceso de verificación de los modelos conceptuales creados por el usuario. Cuando el razonamiento es invocado, la traducción a lógica descriptiva de los modelos es enviada al razonador junto con un conjunto de consultas generadas por el módulo pertinente. A continuación, el sistema mostrará al usuario todas las deducciones relevantes modificando la apariencia del diagrama gráfico original y, dejando a éste, la decisión de preservar o descartar dichos cambios.

El usuario interactúa con un \emph{front-end} que es ejecutado en el explorador Web, el cual provee un ambiente gráfico con las funcionalidades necesarias para crear y editar ontologías junto con un conjunto de primitivas gráficas. Además, muestra las respuestas del razonador usando el mismo conjunto de representaciones gráficas e incluso de forma textual. El \emph{back-end} se ejecuta del lado del servidor, y se compone de módulos que traducen la representación gráfica a una ontología, que generan consultas al sistema de razonamiento, que razona sobre las especificaciones del modelo y además procesa las salidas. 

% Figure \ref{fig:architecture} shows a high level overview of the client-server architecture. Users interact with a front-end running in a Web browser, which provides a graphical environment with the necessary functionalities for creating and editing ontologies together with a set of graphical primitives. Moreover, it shows the reasoner's responses using the very same graphical representation in addition to a textual manner. The back-end running in the server side comprises modules to translate a graphical representation of an ontology, generate queries to the reasoning systems, reason over model's specifications and process its output. Both sides interact via asynchronous HTTP requests in order to allow users to visualise their ontologies while are being modelled and edited.

% El principal objetivo es permitir a los usuarios diseñar diagramas adoptando lenguajes de modelado conceptual estándares. Un modelo de razonamiento lógico completo es utilizado por la herramienta para verificar la satisfacibilidad de las especificaciones, inferir limitaciones implícitas y sugerir otras nuevas basadas en las metodologías definidas en \cite{gbraun:gbraun2015}. \Chris{No me convence, porque las sugerencias no las voy a implementar.}
La posibilidad de utilizar razonamientos automáticos es permitido por una definición semántica precisa de todos los elementos de los diagramas de clases y, por consecuencia, las limitaciones de los diagramas son internamente traducidas en un formalismo lógico basado en clases, capturando las características típicas de los modelos de datos conceptuales. %% \chris{01-01-2017}{Citar a Calvanesse aquí por la forma de traducirse. Diciendo ``por una def. sem. precisa dada según Calvanesse et. al. [tanto tanto].} %% No hace falta puesto que ya se presentó anteriormente.

Más aún, puesto que \crowd{} está basado en una noción de completa deducción para un soporte de razonamiento
%% \chris{01-01-2017}{deduction-complete notion of reasoning support}
relativo a la sintaxis de los diagramas de clases, el usuario observará la ontología original de forma gráfica y completa con todas las deducciones que tienen sentido, dado lo proveído por la ontología y lo expresado en el lenguaje de diagrama de clases gráfico mismo. Esto incluye chequear clases y relaciones por consistencias, descubrir clases implicadas y limitaciones de cardinalidad.
%% \chris{01-01-2017}{\tiny Verificar: Ojo que aquí menciona las sugerencias, cosa que no se implementan en esta tesis.}
 Otras limitaciones no gráficas pueden ser modeladas en \crowd{}, pero deben ser escritas en forma textual, por ejemplo, utilizando expresiones en OWLlink \cite{conicet:Liebig_owllink:dig} o en $\mathcal{DLR}$ \cite{gbraun:first:DLR:98}. % Por el momento, otras limitaciones no gráficas y que no sean de UML como equivalencias y disjunciones pueden ser definidas en \crowd, pero deberán ser expresadas usando expresiones OWLlink.
%% \chris{01-01-2017}{Habla de OWLlink, moverlo a la implementación, aparte es un detalle.}

Por último, \crowd{} solamente se enfoca en el modelado gráfico de un esquema ontológico, mientras que no considera a los individuos. %% \chris{01-01-2017}{¿Va esto aquí?}

%% \germanin{18-1-2017}{Está media rara la imagén no? (\ref{fig:arquitectura}).}

\begin{figure}[h]
  \centering
  
  \includegraphics[width=.75\linewidth]{dia/design_tesis.png}

  \caption{Arquitectura de \crowd{}.}
  \label{fig:arquitectura}
\end{figure}

\ \\


\subsection{Cliente}
Del lado del cliente se propone el uso de una librería gráfica que es controlada por una serie de módulos que se basan en un estilo arquitectónico denominado Modelo-Vista-Controlador. En el modelo se representa en forma estática las distintas primitivas gráficas posibles a realizarse. De esta forma, estos objetos pueden responder a diversos métodos afectando a una o a un conjunto de primitivas en el modelo e incluso puede realizarse una traducción textual para ser enviada al servidor. La vista, posee aspectos visuales de la primitiva, definiendo su color, forma, fuentes del texto, etc. El controlador, si éste existiera para la vista y el modelo dado, respondería a las acciones del usuario y a la entrada de datos del mismo, como por ejemplo, las acciones a realizarse ante un evento del usuario sobre una primitiva.

Además de esto, se debe proveer del código necesario para enviar al servidor la información que requiere para que éste determine la satisfacibilidad y luego para analizar sus respuestas.


\subsection{Servidor}

%% \chrisin{07-jun}{¿Agregar un ejemplo de \DL{} y cómo va modificándose en cáda módulo?} %% No, ya se dan en su sección aparte. Enfocarse en el diseño.

En cuanto al servidor, su funcionamiento básicamente consiste en estar a la espera de órdenes por parte del cliente. Para esto, debe proveer una API (Interfaz de Programación de Aplicaciones) que permita recibir las distintas instrucciones, en especial, recibir el modelo conceptual, determinar qué acción realizar en él y emitir la respuesta esperada, todo bajo un formato predeterminado consensuado entre ambas partes.
Consecuentemente, es preciso dividir al servidor en una serie de módulos cuyos roles en conjunto lograrán llevar a cabo las solicitudes del cliente.
% Pretendemos que se puedan realizar mínimamente una codificación a lógica descriptiva del modelo recibido y su posterior chequeo de satisfacibilidad por parte de un razonador.

A continuación, se enumeran los distintos módulos necesarios y sus respectivas funciones:

%% \chrisin{23-11}{Agus: Patrón? Strategy? Builder? cita... \bf Chequear}
\begin{description}

\item[\texttt{Traductor a \DL{}}:] Provee de la representación en Lógica Descriptiva bajo un lenguaje computable (por ejemplo, en OWL 2 \cite{gbraun:owl2:overview})  desde el modelo de entrada, que luego será enviada al módulo razonador. %Toma una representación de la ontología del usuario y genera su equivalente modelo en sintaxis \DL{}.
%% \todo[inline]{Ver de ampliar un poco. Algún esquema general?} %% DONE

%% \todo[inline]{Este módulo también permite la generación de varias representaciones OWL 2 de acuerdo a codificaciones puntuales propuestas en la bibligrafía y a los lenguajes gráficos soporados. De esta manera, la arquitectura podrá ser extendida a partir de este punto variante para la validación empírica de dichas codificaciones.} %% DONE

En nuestro relevo, nos hemos encontrado con varios métodos para formalizar el modelo conceptual de entrada a Lógica Descriptiva, incluso para un mismo lenguaje gráfico. Además, hemos considerado que existen varias representaciones textuales para un mismo lenguaje computacional que describe a la misma ontología(por ejemplo: una ontología OWL 2 puede expresarse utilizando Turtle \cite{beckett:TTRDFTL}, RDF \cite{patel:OWLWOLMPDFG, beckett04:RDFXMLSS} e incluso con una sintaxis funcional \cite{w3c:owl2:structural_spec_20080411}).

Para que la arquitectura pueda ser extendida bajo estas consideraciones, hemos realizado un diseño, basado en dos patrones denominados ``Builder'' y ``Strategy'' \cite{Gamma:Design_Patterns, Grand:Patterns_in_java},  presentado en la Figura \ref{fig:trans mod}. Cada una de las subclases de ``AbstractStrategy'' implementan un método de formalización determinado, donde su salida es una secuencia de instrucciones con la Lógica Descriptiva a generar.
Para las distintas sintaxis y protocolos, se utiliza una subclase de ``DocumentBuilder'' la cual recibe las instrucciones provenientes de la estrategia seleccionada y genera el documento apropiado. Por ejemplo, ``XMLOWLBuilder'' permite la generación de un documento de sintaxis XML con la lógica generada por una de las estrategias bajo las etiquetas definidas por el estándar OWL. El proceso completo se explica en la sección \ref{sec:mod_trad} y puede observarse su diagrama de secuencia detallado en la Figura \ref{fig:diag_flujo_traducir}.
%% \chris{23-11}{Agus: marcó la figura. Posiblemente porque está en otra sección. ``El proceso completo junto con el detalle de su implementación se explica en la sección \ref{sec:mod_trad} y en la Figura \ref{fig:diag_flujo_traducir}''. \bf Chequear}

\begin{figure}
  \centering

  \includegraphics[width=\linewidth]{dia/TranslatorUML.png}
  %% \todo{UML Class Diagram here.}
  
  \caption{Diseño del módulo traductor.}
  \label{fig:trans mod}
\end{figure}

\item[\texttt{Generador de Consultas}:] Aporta una serie de consultas que serán ejecutadas en el razonador sobre el modelo inicial. Estas consultas permiten obtener propiedades de la ontología, ya incorporados en el razonamiento. Diferentes conjuntos de consultas pueden ser configurados en este componente dependiendo de la metodología o el servicio invocado desde el \emph{front-end}. Sin embargo, sólo describiremos qué consultas deben realizase al razonador y cómo generarlas para detectar inconsistencias en las clases UML \cite{gbraun:Booch:2005:UML} del modelo ingresado.
  %% \todo[inline]{Ver de ampliar un poco. Algún ejemplo genérico?} %% DONE

  Las consultas son generadas como instrucciones que serán incorporadas a la traducción dependiendo de la subclase ``DocumentBuilder'' seleccionada por el módulo \texttt{Traductor a \DL{}}. En el diagrama de secuencia de la Figura \ref{fig:diag_flujo_es_satisfacible} se observa en qué momento se realiza la inclusión de estas consultas para que el razonador pueda recibirlas y procesarlas.

  %% Es posible expandir este módulo para soportar varias estrategias donde cada una pueda verificar una o varias propiedad del modelo conceptual del usuario. 

\item[\texttt{Razonador}:] El razonamiento basado en lógica realizado sobre el modelo, el cual está compuesto por el modelo del usuario junto con el conjunto de consultas agregados por el módulo previo, es ejecutado por un razonador, descripto en la arquitectura como el módulo \texttt{Razonador}. El resultado en conjunto con el modelo y su traducción a \DL{}, al que denominaremos como ``ontología clasificada'', son una serie de respuestas obtenidas a partir de las conclusiones realizadas por el razonador y su entrada.
%% \todo[inline]{Ver de ampliar un poco} %% DONE
Existen varios programas razonadores disponibles en la actualidad los cuales, en su mayoría, se comunican por medio de uno o varios de los protocolos estandarizados existentes como DIG \cite{gbraun:dig} y OWLlink \cite{conicet:Liebig_owllink:dig}. Ejemplos de estos razonadores son Pellet \cite{gbraun:Sirin:2007:Pellet}, RACER \cite{gbraun:racer:HaMo01a}, konclude \cite{steigmiller:KSD}, entre otros \cite{gbraun:fact++description, gbraun:tool:kaon2, DBLP:conf/owled/ShearerMH08}. %aún más que se encuentran listados por la lizadas. Segundo, para que la implementación pueda interpretar estas respuestas y generar la salida esperada por el cliente.
  %% \todo[inline]{Ver de ampliar un poco. Continuar el ejemplo anterior?}

%% \chrisin{23-11}{Agus: Varios comentarios en el siguiente párrafo que no comprendo. ¡Preguntar!}
Este módulo se encarga de activar estos programas apropiadamente y configurarlos para poder enviar y recibir los datos por cada razonador que se desee utilizar. Para ello, se diseñó una clase denominada ``Runner'' con una interfaz simplificada. Dicha clase debe ser configurada con el razonador que se desee utilizar por medio de una de las subclases de ``Connector''. Esta última es la que se encarga de inicializar el razonador y de los detalles de comunicación de interproceso necesarios para enviar y recibir información con él. La Figura \ref{fig:uml_razonador} muestra el diagrama de clases realizado para este módulo.

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

    \includegraphics[width=\linewidth]{dia/diag_flujo_es_satisfacible.png}
    
    \caption{Diagrama de secuencia que muestra el servicio de razonamiento para determinar la satisfacibilidad del modelo.}
    \label{fig:diag_flujo_es_satisfacible}
  \end{figure}
\end{landscape}

\item[\texttt{Analizador de Respuestas}:] Finalmente, la ontología clasificada es usada como entrada para el módulo \texttt{Analizador de Respuestas}, el cual procesa la salida del razonador para proveer al usuario de las conclusiones obtenidas de esta información en un formato entendible por el cliente.

  Existe una relación entre éste y el módulo \texttt{Generador de Consultas}, debido a que en la implementación se debe programar al sistema con una estrategia generadora de consultas compatible con el analizador de respuesta.
  %% \chris{23-11}{Agus: ¿Cuál de todas? ``Debido a que en el desarrollo, se debe programar al sistema con una estrategia generadora compatible con el analizador de respuesta con el cual se configure al iniciar el sistema.'' \bf Chequear}
  Además, es preciso que el analizador comprenda la salida de razonador. Primero, para buscar las respuestas y relacionarlas con cada una de las consultas realizadas. Segundo, para que la implementación pueda interpretar estas respuestas y generar la salida esperada por el cliente.
\end{description}

\begin{figure}[h]
  \centering
  \includegraphics[width=12cm]{dia/RunnerUML.png}
  \caption[Diseño del módulo Razonador.]{Diseño del módulo Razonador para soportar varios tipos de programas razonadores.}
  \label{fig:uml_razonador}
\end{figure}

\subsection{Servicios de Razonamiento}
\label{sec:chequeo_satis}
%% \germanin{18-1-2017}{Quizás acá pondria servicios de razonamiento.}
El servicio de razonamiento, para determinar la satisfacibilidad del modelo, comienza a partir de una petición del usuario desde la interfaz gráfica. Luego, el cliente traduce el modelo conceptual a una representación intermedia que pueda ser enviada al servidor para su posterior procesado. Esto se realiza por medio de la interacción entre los objetos del modelo dentro de la arquitectura modelo-vista-controlador, el cual producirá el código intermedio del diagrama, por ejemplo, recorriendo todos los elementos del modelo de las primitivas gráficas y solicitando a estos objetos su representación intermedia.

Desde el lado del servidor, el \texttt{Traductor a \DL{}} recibe esta representación y comienza su traducción a una Lógica Descriptiva por medio de una codificación determinada (por ejemplo, la codificación UML a \ALCQI{} propuesta en \cite{DBLP:journals/ai/BerardiCG05}), el cual generará reglas y axiomas de dicha lógica a partir de cada primitiva gráfica y su semántica. Esta representación debe ser conocida y computable por el \texttt{Razonador}. A continuación, el módulo \texttt{Generador de Consultas} producirá una serie de consultas entendibles por el razonador, la forma y la cantidad de éstas dependen del modelo conceptual ofrecido por el usuario y deben cumplir con el objetivo de chequear si la base de conocimiento en conjunto con las primitivas del modelo son consistentes y satisfacibles. En caso de que no lo sean, se determina dónde se encuentra el problema en el modelo.

En la Figura \ref{fig:diag_flujo_es_satisfacible}, se representa de forma parcial y por medio de un diagrama de secuencia el proceso descripto.

%% \germanin{18-1-2017}{Me gusta, hacer un diagrama de flujo!} %% Listo 23-02-2017
%% \missingfigure{Realizar un diagrama de flujo o de actividades UML para mostrar cómo se realiza el chequeo de satisfacibilidad}

%\subsection{El Usuario y la Interacción con la Interfaz Gráfica Propuesta}
%\todo[inline]{¿Escribir esto?}

%\todo[inline]{¿Escribir algo referente a técnicas de visualización y navegación desde \cite{gbraun:Ware:2004:IVP} ?}
%\germanin{18-1-2017}{No estoy seguro, me parece que lo podríamos dejar para trabajos futuros.}


% \begin{enumerate}
% \item Consistencia de Diagramas de Clases

% \item Consistencia de Clases

% \end{enumerate}


%\chapter{Implementación del Prototipo}

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