[Pfc-prolog-cvs] prolix-doc/pfc-es/diseno dia-secuencia-web.tex,1.3,1.4 dia-secuencia.tex,1.5,1.6 di
Status: Beta
Brought to you by:
ivanfrade
Menu
▾
▴
[Pfc-prolog-cvs] prolix-doc/pfc-es/diseno dia-secuencia-web.tex,1.3,1.4 dia-secuencia.tex,1.5,1.6 diseno.tex,1.8,1.9 general.tex,1.1,1.2 interprete.tex,1.4,1.5 j2ee-uml.tex,1.1,1.2 secuenciac1-web.tex,1.2,1.3 secuenciac1.tex,1.3,1.4 secuenciac2-web.tex,1.2,1.3 secuenciac2.tex,1.4,1.5 secuenciac4.tex,1.2,1.3
|
From: <iva...@us...> - 2003-09-04 20:31:12
|
Update of /cvsroot/pfc-prolog/prolix-doc/pfc-es/diseno
In directory sc8-pr-cvs1:/tmp/cvs-serv26004/pfc-es/diseno
Modified Files:
dia-secuencia-web.tex dia-secuencia.tex diseno.tex general.tex
interprete.tex j2ee-uml.tex secuenciac1-web.tex
secuenciac1.tex secuenciac2-web.tex secuenciac2.tex
secuenciac4.tex
Log Message:
Pasada revision ortografica
Index: dia-secuencia-web.tex
===================================================================
RCS file: /cvsroot/pfc-prolog/prolix-doc/pfc-es/diseno/dia-secuencia-web.tex,v
retrieving revision 1.3
retrieving revision 1.4
diff -C2 -d -r1.3 -r1.4
*** dia-secuencia-web.tex 3 Sep 2003 16:22:12 -0000 1.3
--- dia-secuencia-web.tex 4 Sep 2003 20:31:02 -0000 1.4
***************
*** 1,4 ****
%
! % Coordinacion de diagramas por Escenarios
%
% secuencia del cliente web
--- 1,4 ----
%
! % Coordinación de diagramas por Escenarios
%
% secuencia del cliente web
Index: dia-secuencia.tex
===================================================================
RCS file: /cvsroot/pfc-prolog/prolix-doc/pfc-es/diseno/dia-secuencia.tex,v
retrieving revision 1.5
retrieving revision 1.6
diff -C2 -d -r1.5 -r1.6
*** dia-secuencia.tex 31 Aug 2003 22:24:07 -0000 1.5
--- dia-secuencia.tex 4 Sep 2003 20:31:02 -0000 1.6
***************
*** 1,4 ****
%
! % Coordinacion de diagramas por Escenarios
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
--- 1,4 ----
%
! % Coordinación de diagramas por Escenarios
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Index: diseno.tex
===================================================================
RCS file: /cvsroot/pfc-prolog/prolix-doc/pfc-es/diseno/diseno.tex,v
retrieving revision 1.8
retrieving revision 1.9
diff -C2 -d -r1.8 -r1.9
*** diseno.tex 4 Sep 2003 17:43:52 -0000 1.8
--- diseno.tex 4 Sep 2003 20:31:02 -0000 1.9
***************
*** 1,4 ****
%
! % Coordinación de la parte diseno de la documentación
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
--- 1,4 ----
%
! % Coordinación de la parte diseño de la documentación
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Index: general.tex
===================================================================
RCS file: /cvsroot/pfc-prolog/prolix-doc/pfc-es/diseno/general.tex,v
retrieving revision 1.1
retrieving revision 1.2
diff -C2 -d -r1.1 -r1.2
*** general.tex 26 Aug 2003 22:38:25 -0000 1.1
--- general.tex 4 Sep 2003 20:31:02 -0000 1.2
***************
*** 6,10 ****
\section{Representación general de la aplicación}
! En esta sección mostramos una visión a muy alto nivel de la aplicación, a traves de diagramas con sucesivos niveles de detalle. Se estudian con más profundidad algunos de los escenarios de la fase de análisis, como ejemplos de interacción de los elementos de la arquitectura presentada, y se explica el diseño de datos de la apicación.
\subsection{Vista general de la aplicación}
--- 6,10 ----
\section{Representación general de la aplicación}
! En esta sección mostramos una visión a muy alto nivel de la aplicación, a través de diagramas con sucesivos niveles de detalle. Se estudian con más profundidad algunos de los escenarios de la fase de análisis, como ejemplos de interacción de los elementos de la arquitectura presentada, y se explica el diseño de datos de la aplicación.
\subsection{Vista general de la aplicación}
***************
*** 19,23 ****
\end{figure}
! En el siguiente nivel de detalle, especificamos la forma de colocar los elementos anteriores en su entorno (servidor web o de aplicaciones) y la comunicación entre ellos (protocolos web o TreeXML). Añadimos la representación de múltiples usuarios accediendo simultaneamente a la aplicación.
\begin{figure}[ht]
--- 19,23 ----
\end{figure}
! En el siguiente nivel de detalle, especificamos la forma de colocar los elementos anteriores en su entorno (servidor web o de aplicaciones) y la comunicación entre ellos (protocolos web o TreeXml). Añadimos la representación de múltiples usuarios accediendo simultáneamente a la aplicación.
\begin{figure}[ht]
***************
*** 28,32 ****
\end{figure}
! Y para plasmar esta arquitectura en software real, mostramos un último esquema donde detallamos las tecnologias utilizadas en cada una de las partes.
\begin{figure}[ht]
--- 28,32 ----
\end{figure}
! Y para plasmar esta arquitectura en software real, mostramos un último esquema donde detallamos las tecnologías utilizadas en cada una de las partes.
\begin{figure}[ht]
***************
*** 72,77 ****
\ncline{->}{2,1}{2,2}\naput*{Solicita avanzar un paso}
\ncline{->}{3,2}{3,3}\naput*{Avanzar un paso en la resolución}
! \ncline{<-}{4,2}{4,3}\naput*{Resultado en TreeXML}
! \ncEVW[offsetA=0,offsetB=0]{->}{reflecta}{reflectb}\ncput*[npos=1.5]{Transformación TreeXML -> SVG}
\ncline{<-}{7,1}{7,2}\naput*{HTML + SVG}
\end{psmatrix}
--- 72,77 ----
\ncline{->}{2,1}{2,2}\naput*{Solicita avanzar un paso}
\ncline{->}{3,2}{3,3}\naput*{Avanzar un paso en la resolución}
! \ncline{<-}{4,2}{4,3}\naput*{Resultado en TreeXml}
! \ncEVW[offsetA=0,offsetB=0]{->}{reflecta}{reflectb}\ncput*[npos=1.5]{Transformación TreeXml -> SVG}
\ncline{<-}{7,1}{7,2}\naput*{HTML + SVG}
\end{psmatrix}
***************
*** 112,117 ****
\ncline{->}{2,1}{2,2}\naput*{Solicita avanzar un paso}
\ncline{->}{3,2}{3,3}\naput*{Avanzar un paso en la resolución}
! \ncline{<-}{4,2}{4,3}\naput*{Resultado en TreeXML}
! \ncEVW[offsetA=0,offsetB=0]{->}{reflecta}{reflectb}\ncput*[npos=1.5]{Transformación TreeXML -> SVG}
\ncEVW[offsetA=0,offsetB=0]{->}{reflectc}{reflectd}\ncput*[npos=1.5]{Transformación SVG -> JPEG}
\ncline{<-}{9,1}{9,2}\naput*{HTML + JPEG}
--- 112,117 ----
\ncline{->}{2,1}{2,2}\naput*{Solicita avanzar un paso}
\ncline{->}{3,2}{3,3}\naput*{Avanzar un paso en la resolución}
! \ncline{<-}{4,2}{4,3}\naput*{Resultado en TreeXml}
! \ncEVW[offsetA=0,offsetB=0]{->}{reflecta}{reflectb}\ncput*[npos=1.5]{Transformación TreeXml -> SVG}
\ncEVW[offsetA=0,offsetB=0]{->}{reflectc}{reflectd}\ncput*[npos=1.5]{Transformación SVG -> JPEG}
\ncline{<-}{9,1}{9,2}\naput*{HTML + JPEG}
***************
*** 154,158 ****
\ncEVW[offsetA=0,offsetB=0]{->}{reflecta}{reflectb}\ncput*[npos=1.5]{Avanzar hasta solución}
\ncline{<-}{6,2}{6,3}\naput*{Resultado en TreeXML}
! \ncEVW[offsetA=0,offsetB=0]{->}{reflectc}{reflectd}\ncput*[npos=1.5]{Transformación XSLT: TreeXML - HTML}
\ncline{<-}{9,1}{9,2}\naput*{HTML}
\end{psmatrix}
--- 154,158 ----
\ncEVW[offsetA=0,offsetB=0]{->}{reflecta}{reflectb}\ncput*[npos=1.5]{Avanzar hasta solución}
\ncline{<-}{6,2}{6,3}\naput*{Resultado en TreeXML}
! \ncEVW[offsetA=0,offsetB=0]{->}{reflectc}{reflectd}\ncput*[npos=1.5]{Transformación XSLT: TreeXml - HTML}
\ncline{<-}{9,1}{9,2}\naput*{HTML}
\end{psmatrix}
***************
*** 167,179 ****
\subsubsection{Comunicación Navegador Web - Cliente Web}
! Esta se realiza utilizando el protocolo habitual de internet, HTTP. Uno de los requisitos de la aplicación era evitar la instalación de software por parte del cliente, y librarle de todo el trabajo posible. Por ello todo el trabajo de elaboración de realiza en el servidor web, comunicandose con el cliente a traves de formatos estandar web, como el HTML, SVG o JPEG.
! SVG (Scalable Vector Graphics)\cite{svg-w3c-web} es un formato del consorcio de estandares web w3c\cite{w3c-web}, que ofrece mayores prestaciones que los formátos gráficos habituales: auna las ventajas de estar definido como un lenguaje XML, con la de los gráficos escalares, que permiten por ejemplo ampliar la imagen con una perdida de resolución muchisimo menor.
! Un ejemplo de imagen en SVG y su codigo:
\begin{figure}[h]
\begin{center}
\includegraphics[height=20mm,keepaspectratio=true]{img/ejemploSvg}
! \caption{Grafico SVG.}
\end{center}
\end{figure}
--- 167,179 ----
\subsubsection{Comunicación Navegador Web - Cliente Web}
! Esta se realiza utilizando el protocolo habitual de Internet, HTTP. Uno de los requisitos de la aplicación era evitar la instalación de software por parte del cliente, y librarle de todo el trabajo posible. Por ello todo el trabajo de elaboración de realiza en el servidor web, comunicándose con el cliente a través de formatos estándar web, como el HTML, SVG o JPEG.
! SVG (Scalable Vector Graphics)\cite{svg-w3c-web} es un formato del consorcio de estándares web w3c\cite{w3c-web}, que ofrece mayores prestaciones que los formatos gráficos habituales: auna las ventajas de estar definido como un lenguaje XML, con la de los gráficos escalares, que permiten por ejemplo ampliar la imagen con una perdida de resolución muchísimo menor.
! Un ejemplo de imagen en SVG y su código:
\begin{figure}[h]
\begin{center}
\includegraphics[height=20mm,keepaspectratio=true]{img/ejemploSvg}
! \caption{Gráfico SVG.}
\end{center}
\end{figure}
***************
*** 215,224 ****
Actualmente los navegadores soportan de forma simbólica este formato: solo gráficos independientes (no formando parte de una página), y sin color. Se espera que pronto se solucionen estos problemas, y en las versiones en desarrollo de los navegadores (p.j. Mozilla) parece que se esta trabajando en el tema.
! Por lo tanto este formato no puede ser utilizado todavia, pero disponemos de herramientas para trabajar con el, y transformarlo en otros formatos. En nuestro caso se utiliza la herramienta Batik\cite{batik-web} para transformarlo en JPEG. Un formato propietario, pero estandar de facto en internet, y ampliamente soportado por todos los navegadores.
\subsubsection{Comunicación Cliente Web - Aplicación}
! En este caso tratamos de la comunicación entre elementos software escritos en java. Disponemos del protocolo RMI (Remote Method Invocation), para la interacción entre objetos a traves de la red. Y sobre ese protocolo intercambiamos información en el lenguaje definido para esta aplicación: TreeXML.
El DTD del lenguaje no resulta demasiado complicado:
--- 215,224 ----
Actualmente los navegadores soportan de forma simbólica este formato: solo gráficos independientes (no formando parte de una página), y sin color. Se espera que pronto se solucionen estos problemas, y en las versiones en desarrollo de los navegadores (p.j. Mozilla) parece que se esta trabajando en el tema.
! Por lo tanto este formato no puede ser utilizado todavía, pero disponemos de herramientas para trabajar con el, y transformarlo en otros formatos. En nuestro caso se utiliza la herramienta Batik\cite{batik-web} para transformarlo en JPEG. Un formato propietario, pero estándar de facto en Internet, y ampliamente soportado por todos los navegadores.
\subsubsection{Comunicación Cliente Web - Aplicación}
! En este caso tratamos de la comunicación entre elementos software escritos en java. Disponemos del protocolo RMI (Remote Method Invocation), para la interacción entre objetos a través de la red. Y sobre ese protocolo intercambiamos información en el lenguaje definido para esta aplicación: TreeXml.
El DTD del lenguaje no resulta demasiado complicado:
***************
*** 246,260 ****
El elemento padre de todo el documento es el elemento \textit{tree}, que puede tener como hijos elementos \textit{node}, \textit{solution} o \textit{transition} en cualquier numero cada uno de ellos (esto es lo que explica la primera linea <<ELEMENT>> del DTD. Estos elementos hijo no tiene a su vez mas hijos, excepto \textit{solution}, que puede tener cualquier numero de elementos \textit{substitution}.
! Despues estan enumerados los atributos de cada elemento definido, siguiendo el patrón << < !ATTLIST {nombre-elemento} {nombre-atributo} {tipo} {otros-parametros} >>. En <<otros parametros>> agrupamos el valor por defecto o si es requerido el parámetro.
! De esta forma un arbol de resolución como:
\begin{figure}[h]
\begin{center}
\includegraphics[height=70mm,keepaspectratio=true]{img/arbol-2-soluciones}
! \caption{Arbol de resolución.}
\end{center}
\end{figure}
! Esta representado en TreeXML como:
\begin{verbatim}
--- 246,260 ----
El elemento padre de todo el documento es el elemento \textit{tree}, que puede tener como hijos elementos \textit{node}, \textit{solution} o \textit{transition} en cualquier numero cada uno de ellos (esto es lo que explica la primera linea <<ELEMENT>> del DTD. Estos elementos hijo no tiene a su vez mas hijos, excepto \textit{solution}, que puede tener cualquier numero de elementos \textit{substitution}.
! Después están enumerados los atributos de cada elemento definido, siguiendo el patrón << < !ATTLIST {nombre-elemento} {nombre-atributo} {tipo} {otros-parámetros} >>. En <<otros parámetros>> agrupamos el valor por defecto o si es requerido el parámetro.
! De esta forma un árbol de resolución como:
\begin{figure}[h]
\begin{center}
\includegraphics[height=70mm,keepaspectratio=true]{img/arbol-2-soluciones}
! \caption{Árbol de resolución.}
\end{center}
\end{figure}
! Esta representado en TreeXml como:
\begin{verbatim}
***************
*** 279,283 ****
! Usando TreeXML garantizamos la posibilidad de comunicar cualquier cliente con la aplicación: es texto plano, que el cliente puede interpretar como mejor le convenga, convirtiendolo a una representación en modo texto, a un formato gráfico adecuando (como el caso de \texttt{Prolix}) u otras combinaciones.
\subsection{Vista detallada de la aplicación}
--- 279,283 ----
! Usando TreeXml garantizamos la posibilidad de comunicar cualquier cliente con la aplicación: es texto plano, que el cliente puede interpretar como mejor le convenga, convirtiéndolo a una representación en modo texto, a un formato gráfico adecuando (como el caso de \texttt{Prolix}) u otras combinaciones.
\subsection{Vista detallada de la aplicación}
Index: interprete.tex
===================================================================
RCS file: /cvsroot/pfc-prolog/prolix-doc/pfc-es/diseno/interprete.tex,v
retrieving revision 1.4
retrieving revision 1.5
diff -C2 -d -r1.4 -r1.5
*** interprete.tex 4 Sep 2003 17:43:52 -0000 1.4
--- interprete.tex 4 Sep 2003 20:31:02 -0000 1.5
***************
*** 20,24 ****
\begin{center}
\includegraphics[width=120mm,keepaspectratio=true]{img/enganche-interprete-prolix.eps}
! \caption{\label{general}Representación del enganche a traves de interfaces de aplicación - intérprete.}
\end{center}
\end{figure}
--- 20,24 ----
\begin{center}
\includegraphics[width=120mm,keepaspectratio=true]{img/enganche-interprete-prolix.eps}
! \caption{\label{general}Representación del enganche a través de interfaces de aplicación - intérprete.}
\end{center}
\end{figure}
***************
*** 41,45 ****
\end{figure}
! El diagrama de secuencia sobre como interactuan estas clases esta representado en la figura \ref{secuenciaInterpreter}, y para completar el modelado de su comportamiento, mostramos en la figura \ref{estadosContext} el diagrama de estados de \texttt{PrologContext}.
\begin{figure}[ht]
--- 41,45 ----
\end{figure}
! El diagrama de secuencia sobre como interactúan estas clases esta representado en la figura \ref{secuenciaInterpreter}, y para completar el modelado de su comportamiento, mostramos en la figura \ref{estadosContext} el diagrama de estados de \texttt{PrologContext}.
\begin{figure}[ht]
***************
*** 160,168 ****
! El método \texttt{isCompletlyExplored()} devuelve si todos sus posibles hijos estan explorados. En caso de que lo estén, puede ser porque tiene hijos y están explorados, o porque es un nodo final, dato que podemos consultar con \texttt{isFinal()}. Si es final, puede ser solución. Si su query (\texttt{getQuery()}) es la clausula vacia, es una solución, aunque encapsulamos esta operación en el método \texttt{isSolution()}.
! Para navegar por el arbol se utilizan los métodos \texttt{getParent()} que devuelve una referencia al TreeElement padre del nodo actual. Y \texttt{getNextLevelElements()} para obtener los nodos hijos.
! En cada nodo deberiamos encontrar las substituticiones que se hicieron para llegar a el. Las solicitamos con el método \texttt{getSubstitutions()}, que devuelve de cero a varias referencias a \texttt{Substitution}, una clase que almacena el valor anterior y nuevo de una variable.
Por último el interfaz de \texttt{TreeElement} incluye el método que le permite aceptar clases <<visitor>>, que hereden de la clase \texttt{TreeElementVisitor} cuyo diagrama mostramos en la figura \ref{visitor}. Su implementación no depende del programador del intérprete pues su código es:
--- 160,168 ----
! El método \texttt{isCompletlyExplored()} devuelve si todos sus posibles hijos están explorados. En caso de que lo estén, puede ser porque tiene hijos y están explorados, o porque es un nodo final, dato que podemos consultar con \texttt{isFinal()}. Si es final, puede ser solución. Si su query (\texttt{getQuery()}) es la clausula vacía, es una solución, aunque encapsulamos esta operación en el método \texttt{isSolution()}.
! Para navegar por el árbol se utilizan los métodos \texttt{getParent()} que devuelve una referencia al TreeElement padre del nodo actual. Y \texttt{getNextLevelElements()} para obtener los nodos hijos.
! En cada nodo deberíamos encontrar las substituticiones que se hicieron para llegar a el. Las solicitamos con el método \texttt{getSubstitutions()}, que devuelve de cero a varias referencias a \texttt{Substitution}, una clase que almacena el valor anterior y nuevo de una variable.
Por último el interfaz de \texttt{TreeElement} incluye el método que le permite aceptar clases <<visitor>>, que hereden de la clase \texttt{TreeElementVisitor} cuyo diagrama mostramos en la figura \ref{visitor}. Su implementación no depende del programador del intérprete pues su código es:
***************
*** 175,179 ****
\end{verbatim}
! De esta forma, con el patrón <<visitor>> podemos implemetar operaciones diferentes sobre la estructura del arbol.
\begin{figure}[ht]
--- 175,179 ----
\end{verbatim}
! De esta forma, con el patrón <<visitor>> podemos implementar operaciones diferentes sobre la estructura del árbol.
\begin{figure}[ht]
***************
*** 197,201 ****
%\subsection{Resultados del intérprete (vista dinámica)}
%
! % En el apartado anterior comentamos la clase \texttt{TreeElement} que retorna el interprete cuando se le solicitan resultados. En este apartado explicamos como se representa el arbol de soluciones en esa estructura y como crece en cada consulta, usando un ejemplo.
%
% Sea el programa:
--- 197,201 ----
%\subsection{Resultados del intérprete (vista dinámica)}
%
! % En el apartado anterior comentamos la clase \texttt{TreeElement} que retorna el interprete cuando se le solicitan resultados. En este apartado explicamos como se representa el árbol de soluciones en esa estructura y como crece en cada consulta, usando un ejemplo.
%
% Sea el programa:
Index: j2ee-uml.tex
===================================================================
RCS file: /cvsroot/pfc-prolog/prolix-doc/pfc-es/diseno/j2ee-uml.tex,v
retrieving revision 1.1
retrieving revision 1.2
diff -C2 -d -r1.1 -r1.2
*** j2ee-uml.tex 25 Aug 2003 20:56:02 -0000 1.1
--- j2ee-uml.tex 4 Sep 2003 20:31:02 -0000 1.2
***************
*** 1,4 ****
%
! % Diseño::problematica j2ee-uml
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
--- 1,4 ----
%
! % Diseño::problemática j2ee-uml
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
***************
*** 10,22 ****
\textit{El Lenguaje Unificado de Modelado (UML) es un lenguaje para especificar, visualizar, construir y documentar los artefactos de los sistemas software, así como para el modelado del negocio y otros sistemas no software}\cite{omg-web}
! Actualmente UML es la notación de modelado estandard en la industria informática. Su elaboración comenzó en 1994 cuando Grady Booch y Jim Rumsbaugh decidieron unir las notaciones que habian desarrollado para sus propios métodos (el de Booch y el \textit{OMT: Object Modeling Technique}). Posteriormente se unió a ellos Ivar Jacobson, y entre otros colaboladores, se desataca el papel de Cris Kobryn. En 1997 fue reconocido como estandard por el \textit{Object Management Group}, el consorcio de empresas cuyo objetivo es promover las especificaciones necesarias para obtener software standard y de calidad.
! La plataforma J2EE nació en 1999 cuando Sun decidió redefinir java. Por su filosofia multiplataforma (en el sentido de no estar atado a un sistema operativo) java comenzó a utilizarse en multitud de aplicaciones, desde electrodomésticos hasta sistemas de empresa. Originalmente java estaba estructurado como un SDK (Kit de desarrollo) básico, con librerias para las diferentes utilidades, lo cual empezó a resultar ineficiente, por lo que Sun reorganizó el entorno en 3 versiones: J2ME (Micro Edition, para aplicaciones de dispositivos <<pequeños>>), j2SE (Standard Edition, para aplicaciones convencionales) y J2EE (Entreprise Edition, para aplicaciones a gran escala, web y distribuidas).
En esencia la plataforma J2EE consiste en un conjunto de interfaces y clases auxiliares en el lenguaje Java (por tanto totalmente orientadas a objetos), que las aplicaciones pueden o deben utilizar para beneficiarse de una serie de servicios implementados en lo que se conoce como el <<contenedor>> de aplicaciones.
! Uno de los objetos (de forma coloquial) mas importantes de esta arquitectura es el EJB: Enterprise Java Bean. Cumpliendo unos requisitos claramente especificados, el programador puede concentrarse en crear EJBs con la lógica de negocio. Esto libera al desarrollador de una serie de problemas de diseño, implementación y prueba, como la persistencia o la localización de un elemento o el mantener la sessión del usuario. Estas tareas, comunes a todas las aplicaciones, quedan en manos del <<contenedor>>, lo que aumenta su fiabilidad, reduce el numero de pruebas necesarias a la aplicación, y agiliza el desarrollo de código util.
! A nivel práctico, escribir un EJB consiste en implementar unos determinados interfaces respetando ciertas normas sobre los nombres de métodos y variables. Hacerlo <<a mano>> no es dificil si se trata de poco código, pero según crecen el número de EJBs, y los cambios se suceden, es más dificil mantener coherentes todos los ficheros. Sin embargo es posible el uso de herramientas (como en el caso de \texttt{Prolix} con \texttt{XDoclet}), mediante las cuales es posible escribir un único fichero y generar automáticamente todos los demás, con la seguridad de coherencia que ello conlleva.
! Hay disponibles herramientas como \texttt{WithClass}\cite{microgold-web} o \texttt{Oracle9i jDeveloper}\cite{oracle-jdev-web}, que permiten diseñar los EJB en UML y generar su codigo. Sin embargo parece ser que aún no hay una forma <<oficial>> de Sun para representar de forma simplificada estos elementos\cite{uml-ejb-jcp}, por lo que suponemos que o bien el diseño se realiza completo para poder generar el código (escribiendo todos los interfaces y relaciones) o la notación utilizada es propia de la herramienta. En ambos casos son herramientas de pago.
\ No newline at end of file
--- 10,22 ----
\textit{El Lenguaje Unificado de Modelado (UML) es un lenguaje para especificar, visualizar, construir y documentar los artefactos de los sistemas software, así como para el modelado del negocio y otros sistemas no software}\cite{omg-web}
! Actualmente UML es la notación de modelado estándar en la industria informática. Su elaboración comenzó en 1994 cuando Grady Booch y Jim Rumsbaugh decidieron unir las notaciones que habían desarrollado para sus propios métodos (el de Booch y el \textit{OMT: Object Modeling Technique}). Posteriormente se unió a ellos Ivar Jacobson, y entre otros colaboradores, se desataca el papel de Cris Kobryn. En 1997 fue reconocido como estándar por el \textit{Object Management Group}, el consorcio de empresas cuyo objetivo es promover las especificaciones necesarias para obtener software estándar y de calidad.
! La plataforma J2EE nació en 1999 cuando Sun decidió redefinir java. Por su filosofía multiplataforma (en el sentido de no estar atado a un sistema operativo) java comenzó a utilizarse en multitud de aplicaciones, desde electrodomésticos hasta sistemas de empresa. Originalmente java estaba estructurado como un SDK (Kit de desarrollo) básico, con librerías para las diferentes utilidades, lo cual empezó a resultar ineficiente, por lo que Sun reorganizó el entorno en 3 versiones: J2ME (Micro Edition, para aplicaciones de dispositivos <<pequeños>>), j2SE (Standard Edition, para aplicaciones convencionales) y J2EE (Entreprise Edition, para aplicaciones a gran escala, web y distribuidas).
En esencia la plataforma J2EE consiste en un conjunto de interfaces y clases auxiliares en el lenguaje Java (por tanto totalmente orientadas a objetos), que las aplicaciones pueden o deben utilizar para beneficiarse de una serie de servicios implementados en lo que se conoce como el <<contenedor>> de aplicaciones.
! Uno de los objetos (de forma coloquial) mas importantes de esta arquitectura es el EJB: Enterprise Java Bean. Cumpliendo unos requisitos claramente especificados, el programador puede concentrarse en crear EJBs con la lógica de negocio. Esto libera al desarrollador de una serie de problemas de diseño, implementación y prueba, como la persistencia o la localización de un elemento o el mantener la sesión del usuario. Estas tareas, comunes a todas las aplicaciones, quedan en manos del <<contenedor>>, lo que aumenta su fiabilidad, reduce el numero de pruebas necesarias a la aplicación, y agiliza el desarrollo de código útil.
! A nivel práctico, escribir un EJB consiste en implementar unos determinados interfaces respetando ciertas normas sobre los nombres de métodos y variables. Hacerlo <<a mano>> no es difícil si se trata de poco código, pero según crecen el número de EJBs, y los cambios se suceden, es más difícil mantener coherentes todos los ficheros. Sin embargo es posible el uso de herramientas (como en el caso de \texttt{Prolix} con \texttt{XDoclet}), mediante las cuales es posible escribir un único fichero y generar automáticamente todos los demás, con la seguridad de coherencia que ello conlleva.
! Hay disponibles herramientas como \texttt{WithClass}\cite{microgold-web} o \texttt{Oracle9i jDeveloper}\cite{oracle-jdev-web}, que permiten diseñar los EJB en UML y generar su código. Sin embargo parece ser que aún no hay una forma <<oficial>> de Sun para representar de forma simplificada estos elementos\cite{uml-ejb-jcp}, por lo que suponemos que o bien el diseño se realiza completo para poder generar el código (escribiendo todos los interfaces y relaciones) o la notación utilizada es propia de la herramienta. En ambos casos son herramientas de pago.
\ No newline at end of file
Index: secuenciac1-web.tex
===================================================================
RCS file: /cvsroot/pfc-prolog/prolix-doc/pfc-es/diseno/secuenciac1-web.tex,v
retrieving revision 1.2
retrieving revision 1.3
diff -C2 -d -r1.2 -r1.3
*** secuenciac1-web.tex 1 Sep 2003 20:26:04 -0000 1.2
--- secuenciac1-web.tex 4 Sep 2003 20:31:02 -0000 1.3
***************
*** 5,9 ****
\paragraph{Alumno carga programa}
! Representado en la figura \ref{DSE11W}. Las operaciones relativas al servidor estan en la figura \ref{DSE11}, en la página \pageref{DSE11}.
\begin{sidewaysfigure}[hpb]
--- 5,9 ----
\paragraph{Alumno carga programa}
! Representado en la figura \ref{DSE11W}. Las operaciones relativas al servidor están en la figura \ref{DSE11}, en la página \pageref{DSE11}.
\begin{sidewaysfigure}[hpb]
Index: secuenciac1.tex
===================================================================
RCS file: /cvsroot/pfc-prolog/prolix-doc/pfc-es/diseno/secuenciac1.tex,v
retrieving revision 1.3
retrieving revision 1.4
diff -C2 -d -r1.3 -r1.4
*** secuenciac1.tex 31 Aug 2003 22:24:07 -0000 1.3
--- secuenciac1.tex 4 Sep 2003 20:31:02 -0000 1.4
***************
*** 5,9 ****
\paragraph{Alumno carga programa}
! En la figura \ref{DSE11} mostramos el diagrama de secuencia del escenario <<Alumno carga programa>>. El segundo caso de uso (<<cargar programa desde biblioteca>>) desde el punto de vista del servidor es igual que este, diferenciandose solo en la parte del cliente web.
\begin{sidewaysfigure}[hpb]
--- 5,9 ----
\paragraph{Alumno carga programa}
! En la figura \ref{DSE11} mostramos el diagrama de secuencia del escenario <<Alumno carga programa>>. El segundo caso de uso (<<cargar programa desde biblioteca>>) desde el punto de vista del servidor es igual que este, diferenciándose solo en la parte del cliente web.
\begin{sidewaysfigure}[hpb]
Index: secuenciac2-web.tex
===================================================================
RCS file: /cvsroot/pfc-prolog/prolix-doc/pfc-es/diseno/secuenciac2-web.tex,v
retrieving revision 1.2
retrieving revision 1.3
diff -C2 -d -r1.2 -r1.3
*** secuenciac2-web.tex 3 Sep 2003 16:22:12 -0000 1.2
--- secuenciac2-web.tex 4 Sep 2003 20:31:02 -0000 1.3
***************
*** 81,85 ****
\paragraph{Alumno avanza hasta siguiente solución}
! Representado el diagrama de secuencia en la figura \ref{DSE22W}. La operación de tranformación \texttt{transform} de la clase \texttt{SvgGenerator} muestra completa en la figura \ref{transf-svg}.
--- 81,85 ----
\paragraph{Alumno avanza hasta siguiente solución}
! Representado el diagrama de secuencia en la figura \ref{DSE22W}. La operación de transformación \texttt{transform} de la clase \texttt{SvgGenerator} muestra completa en la figura \ref{transf-svg}.
***************
*** 263,267 ****
\paragraph{Alumno visualiza soluciones}
! Este escenario se desarrolla integramente en la parte de visualización de la aplicación, extrayendo los datos del modelo (JavaBean). Se representa su secuencia en la figura \ref{DSE24W}.
\begin{figure}
--- 263,267 ----
\paragraph{Alumno visualiza soluciones}
! Este escenario se desarrolla íntegramente en la parte de visualización de la aplicación, extrayendo los datos del modelo (JavaBean). Se representa su secuencia en la figura \ref{DSE24W}.
\begin{figure}
***************
*** 295,299 ****
%% Escenario 2.5
! \paragraph{Alumno visualiza arbol de representación de soluciones}
Al igual que en el escenario anterior, toda la labor de este escenario se realiza en el lado del cliente web, aunque en este caso se requieren más operaciones para transformar el SVG en JPEG.
--- 295,299 ----
%% Escenario 2.5
! \paragraph{Alumno visualiza árbol de representación de soluciones}
Al igual que en el escenario anterior, toda la labor de este escenario se realiza en el lado del cliente web, aunque en este caso se requieren más operaciones para transformar el SVG en JPEG.
Index: secuenciac2.tex
===================================================================
RCS file: /cvsroot/pfc-prolog/prolix-doc/pfc-es/diseno/secuenciac2.tex,v
retrieving revision 1.4
retrieving revision 1.5
diff -C2 -d -r1.4 -r1.5
*** secuenciac2.tex 3 Sep 2003 16:22:12 -0000 1.4
--- secuenciac2.tex 4 Sep 2003 20:31:02 -0000 1.5
***************
*** 47,51 ****
\paragraph{Alumno avanza hasta siguiente solución}
! Se ha optado por representar las operaciónes \texttt{isSolution()} y \texttt{getCompletlyExplored()} de la clase \texttt{TreeOperations} y \texttt{transformToTreeXML()} de la clase \texttt{TransformationControl} en diagramas diferentes (figuras \ref{isSolution}, \ref{isCE} y \ref{transformToTreeXml} respectivamente), para obtener un diagrama de secuencia principal(figura \ref{DSE22}) más claro.
\begin{sidewaysfigure}[hpb]
--- 47,51 ----
\paragraph{Alumno avanza hasta siguiente solución}
! Se ha optado por representar las operaciones \texttt{isSolution()} y \texttt{getCompletlyExplored()} de la clase \texttt{TreeOperations} y \texttt{transformToTreeXML()} de la clase \texttt{TransformationControl} en diagramas diferentes (figuras \ref{isSolution}, \ref{isCE} y \ref{transformToTreeXml} respectivamente), para obtener un diagrama de secuencia principal(figura \ref{DSE22}) más claro.
\begin{sidewaysfigure}[hpb]
Index: secuenciac4.tex
===================================================================
RCS file: /cvsroot/pfc-prolog/prolix-doc/pfc-es/diseno/secuenciac4.tex,v
retrieving revision 1.2
retrieving revision 1.3
diff -C2 -d -r1.2 -r1.3
*** secuenciac4.tex 31 Aug 2003 22:24:07 -0000 1.2
--- secuenciac4.tex 4 Sep 2003 20:31:02 -0000 1.3
***************
*** 4,8 ****
\paragraph{Usuario hace login en el sistema}
! El sistema comprueba si el usuario que pretende hacer login es el administrador. Si es así se asegura de que haya un administrador creado (figura \ref{yaHayAdmin}) o crea uno si todavia o existe (figura \ref{noHayAdmin}). En cualquier caso (sea administrador o no), el sistema cierra la sesión anterior si la hubiese, y comienza una nueva con ese usuario y password solicitado, como representamos en la figura \ref{DSE41}, la secuencia principal.
%%%% login
--- 4,8 ----
\paragraph{Usuario hace login en el sistema}
! El sistema comprueba si el usuario que pretende hacer login es el administrador. Si es así se asegura de que haya un administrador creado (figura \ref{yaHayAdmin}) o crea uno si todavía o existe (figura \ref{noHayAdmin}). En cualquier caso (sea administrador o no), el sistema cierra la sesión anterior si la hubiese, y comienza una nueva con ese usuario y password solicitado, como representamos en la figura \ref{DSE41}, la secuencia principal.
%%%% login
|
