Caravel

Preguntas frecuentes (FAQs)

Las personas interesadas en añadir sugerencias, comentarios o preguntas a esta sección pueden hacerlo a través de .


  1. ¿Es posible conservar el AS/400 como servidor de base de datos o de aplicaciones? En caso afirmativo, ¿es necesario ampliar el equipo?
  2. Sí, se puede conservar. Así, por ejemplo, en arquitectura cliente-servidor el AS/400 se utilizaría como servidor de datos, y con i5/OS, Linux o AIX puede ser también el servidor de aplicaciones.

    No es necesario ampliar la máquina debido a la conversión. Los parámetros varían según la configuración del hardware y de las comunicaciones, así como con las aplicaciones de cada instalación en concreto. El cambio viene dado por la evolución de una arquitectura de una sola capa a una arquitectura de dos capas (cliente-servidor).

  3. Al convertir un programa a Java, ¿la ejecución es más rápida o más lenta?
  4. Si se dispone de una plataforma adecuada el rendimiento es aún mayor, dada la gran escalabilidad que aporta Java.

  5. ¿Con qué entornos de desarrollo es compatible el código fuente resultante de la conversión con Caravel?
  6. El código resultante de la conversión con Caravel es 100% Java. Por tanto, se puede utilizar cualquier estándar del mercado. Algunos ejemplos son WebSphere, Eclipse, JBuilder, Forte, etc.

  7. ¿Cómo se implementan las áreas de datos?
  8. Las áreas de datos se implementan utilizando SQL mediante tablas.

  9. ¿Cómo se implementan las funciones avanzadas de impresión?
  10. Caravel contempla un conjunto de extensiones sobre los archivos Printer File (PRTF) que ofrecen las funcionalidades más importantes del módulo AFP/400, esto es, impresión de imágenes, texto, preformatos, códigos de barras, etc.

    Para más información consulte la documentación relativa a Caravel OS/400 Framework.

  11. ¿Las aplicaciones convertidas son utilizables sobre un servidor de aplicaciones? Más concretamente, ¿son utilizables sobre WebSphere?
  12. Sí. Caravel convierte a Java con el modelo de arquitectura estándar J2EE. Por tanto, cualquier servidor de aplicaciones que esté basado en dicho estándar, como es el caso de WebSphere, podrá ser utilizado.

  13. ¿La traducción de los programas se realiza 1 a 1, esto es, cada instrucción original RPG/COBOL se traduce a una instrucción Java, o se traducen grupos enteros?
  14. Caravel traduce una instrucción RPG/COBOL a un método que implementa la misma funcionalidad que la instrucción original. No se traducen grupos de instrucciones, sino 1 a 1.

  15. ¿Están implementados los comandos del sistema operativo (CLs)?
  16. Sí, están implementados los que desde un sistema de gestión de base de datos puedan ser invocados con este fin: CPYF, CRTPFM, ADDLIBLE, MONMSG, OVRDBF, OVRPRT, OVRDSPF, etc.

    Caravel es un servicio de conversión mediante el cual se garantiza el 100% de la funcionalidad y, por tanto, se implementarán todos los necesarios para cumplir esta garantía.

  17. ¿Qué modificaciones hardware y software son necesarias para utilizar las aplicaciones en Swing?
  18. Para utilizar las aplicaciones en Java con interfaz Swing se requiere un PC actuando como cliente en el que debe haber instalada una Máquina Virtual Java (JVM). La aplicación residirá en un servidor que también debe tener JVM. Este servidor puede ser de cualquier arquitectura, incluyendo iSeries con AIX, Linux o i5/OS. Los datos pueden estar en ese mismo servidor, un servidor OS/400 o de otro tipo.

  19. ¿Qué modificaciones hardware y software son necesarias para utilizar las aplicaciones en la Web?
  20. Se requiere un servidor con acceso a Internet / Intranet que tenga instalado un software de servidor Web o de aplicaciones. Éste puede ser WebSphere o cualquier otro que cumpla la normativa J2EE. Las estaciones de trabajo necesitarán un "browser" como MS Internet Explorer.

  21. ¿Qué hay que hacer para obtener una aplicación en tres capas si la hemos migrado vía Caravel?
  22. Al convertir una aplicación con Caravel, ésta puede utilizar 3 tipos de interfaces: el look original 5250/3270, interfaz Swing o HTML. Al utilizar la modalidad de interfaz HTML las aplicaciones quedan estructuradas en 2 capas, por un lado la capa cliente y por otro la capa de reglas de negocio y datos. La tercera capa, opcional, estaría constituida por los datos que podrían situarse en un servidor diferente. Estos datos podrían ser accesibles por medio de EJBs (Enterprise Java Beans) en el entorno de un servidor de aplicaciones. De acuerdo a la normativa J2EE, esta modalidad cumpliría con lo denominado "arquitectura de 3 capas".

  23. ¿Aparte de la personalización efectuada vía Caravel, qué herramientas se necesitan para personalizar las aplicaciones?
  24. Para personalizar la interfaz Swing se puede utilizar cualquier entorno de desarrollo estándar, como WebSphere, Eclipse, JBuilder, Forte, etc.

    Para personalizar la interfaz HTML se puede utilizar Caravel Point of View o cualquier editor HTML del mercado.

  25. ¿Es posible dejar una aplicación migrada vía Caravel en un contexto tres capas?
  26. Sí, de hecho el proceso de conversión en sí mismo ya estructura la aplicación resultante en 2 capas: cliente y reglas de negocio / acceso a datos. La separación de los datos en una tercera capa es un proceso inmediato.

    El paso a una arquitectura de 3 capas presenta múltiples posibilidades que aconsejan un proceso de diseño y evaluación coordinado con los propietarios del sistema.

  27. ¿Cuál es el nivel de complejidad de la integración con WebSphere de las aplicaciones migradas vía Caravel?
  28. La integración es sencilla debido a que el proceso de conversión ya incluye una estructuración de las aplicaciones en una arquitectura plenamente adaptada a su integración con un servidor de aplicaciones.

  29. ¿Se requiere una formación específica sobre los métodos y clases desarrollados por BASE 100 y empleados en la conversión de una aplicación vía Caravel?
  30. Las clases utilizadas por BASE 100 son 100% puro Java, fuertemente estructuradas, y no requieren para su utilización de un conocimiento diferente al de cualquier otro conjunto de clases Java. Sin embargo, por su diseño resultan muy fácilmente legibles para profesionales con experiencia en RPG y/o COBOL.

    Al mismo tiempo, en cada proyecto de conversión existe un apartado de formación en el que se resaltan las diferencias entre RPG y/o COBOL respecto a Java.

  31. ¿Qué es una clase en Java?
  32. En un lenguaje orientado a objetos, una clase es un programa que implementa la funcionalidad relativa a un tipo de objetos. Esta funcionalidad está constituida por propiedades y métodos.

  33. ¿Qué es un método en Java?
  34. Un método en un lenguaje orientado a objetos es una funcionalidad de una clase de objetos.

  35. ¿La interfaz de usuario de una aplicación traducida es generada automáticamente por Caravel o hay que configurarla manualmente?
  36. La personalización de la interfaz se realiza mediante la herramienta Caravel Point of View, cuyo funcionamiento, básicamente, es el siguiente:

    Cuando se traduce una aplicación se puede elegir entre generar la interfaz de usuario de manera automática o bien personalizar cada pantalla de acuerdo a las preferencias del cliente.

    En el primer caso, el aspecto de las pantallas está basado en ciertas reglas de transformación que Caravel provee y que permiten generar, para cada campo de la pantalla, el código HTML equivalente. El resultado obtenido será un código HTML que presenta los mismos campos, tamaños y posiciones que la pantalla 5250/3270 original. En cuanto a los atributos de color, fuentes, color de fondo, etc., que no influyen en la funcionalidad, pueden ser personalizados, aplicándose automáticamente a todas las pantallas que se generen.

    En el segundo caso, el cliente puede crear una plantilla (template) JSP para cada pantalla que desee personalizar. Esta plantilla puede tener el aspecto que se quiera y no tiene por qué parecerse a la original. Con el fin de facilitar la confección de estas plantillas, Caravel proporciona los mecanismos JSP estándares y hace uso de las "JSP TagLibs", que permiten de manera sencilla desplegar la información proveniente de la aplicación: registros, subficheros, campos, atributos (records, subfiles, fields, attributes), y proporciona así mismo las funciones JavaScript para manejar estos campos y devolver la información a la aplicación (por ejemplo, teclas de función –function keys–). Esta solución proporciona toda la flexibilidad para que el diseñador obtenga el aspecto deseado.

    Estas dos soluciones no son incompatibles, pudiendo por tanto personalizar sólo una parte de las pantallas de la aplicación si así se desea. Este proceso puede ser progresivo y a gusto del cliente. La aplicación buscará en primer lugar la solución personalizada de una pantalla y, en caso de no encontrarla, dinámicamente generará una pantalla de acuerdo a los parámetros de interfaz de usuario seleccionados.

    El proceso de personalización puede ser llevado a cabo totalmente por el cliente, o bien contratado como parte del proyecto. En este último caso el cliente puede simplemente definir las reglas, patrones y estilos que desee que sean tenidos en cuenta. Debido a que el aspecto de la aplicación está definido por el conjunto de plantillas (templates) JSP, el cliente podrá cambiar cualquier elemento gráfico una vez que la aplicación esté finalizada.

  37. ¿Qué es la normativa J2EE?
  38. La plataforma J2EE (Java 2, Enterprise Edition) define los estándares para el desarrollo de aplicaciones empresariales multi-capa basadas en componentes. Incluye un conjunto de herramientas que crean un escenario ideal para el desarrollo y despliegue de aplicaciones escalables en la Web, y que cuentan con las siguientes características:

    • Portable. Con sólo escribir la aplicación en Windows o Linux, ésta estará disponible sobre cualquier plataforma que disponga de una Máquina Virtual Java (JVM).

    • Escalable. Si crece el volumen de la empresa bastará con añadir nuevos componentes J2EE a la aplicación Web para soportar el crecimiento sin necesidad de reescribir el código.

    • Altamente Soportada. Cualquier gran empresa de software dispone de un contenedor de componentes (o servidor de aplicaciones) Web compatibles con J2EE, entre ellas IBM (WebSphere), BEA (WebLogic), Apache (Tomcat), Sun (iPlanet), Macromedia (JRun), etc.

    • Segura. Mientras que otros modelos de aplicaciones empresariales requieren medidas de seguridad específicas en cada aplicación, el entorno de seguridad de la plataforma J2EE permite que se definan unas restricciones de seguridad en el momento de despliegue de la aplicación, aislando así las aplicaciones de la complejidad de las implementaciones de seguridad. La plataforma J2EE hace portables una gran complejidad de implementaciones de seguridad.

  39. ¿Cómo podemos evitar sorpresas? ¿En qué punto exacto del proyecto podríamos saber el trabajo a realizar y el coste que representa? ¿Tendría que estar esta información disponible antes de que empiece el proyecto? ¿Debería haber algún tipo de análisis antes de firmar el contrato de migración?
  40. BASE 100 determina previamente los tiempos, costes y complejidad de cada proyecto.

  41. La seguridad de los usuarios y su identificación sobre la plataforma original ¿se migra también?
  42. El componente de seguridad no forma parte de la migración propiamente dicha. Una vez migrada la aplicación al nuevo entorno, se ejecutará bajo los Security Managers de esa plataforma (sistema operativo, sistema gestor de base de datos, etc.).

  43. ¿Es posible imprimir líneas y códigos de barras usando la opción de impresión avanzada?
  44. Sí, Caravel dispone de mecanismos que generan las mismas funcionalidades para imprimir códigos de barras, por lo que queda definida una tabla de correspondencias entre los códigos de origen (APW) y sus “fuentes” equivalentes, obteniendo así el mismo código de barras.

  45. ¿Puede Caravel convertir programas que usan ciclo?
  46. Sí, Caravel implementa todos los programas de ciclo en RPG, ofreciendo un grupo de clases y métodos en Java que permiten ver su funcionalidad de manera explícita.

  47. ¿Las aplicaciones convertidas requieren un servidor de aplicaciones específico para su ejecución?
  48. Caravel no tiene una dependencia concreta del servidor de aplicaciones. Actualmente, las aplicaciones convertidas son compatibles con distintos servidores de aplicaciones, como por ejemplo:

    • Tomcat 4.1.x / 5.0.x
    • WebSphere 5.1 / 4.0
    • WebLogic 5.1 / 5.2
  49. ¿Cuál es la versión de JVM soportada por Caravel?
  50. Caravel soporta JVM versiones 1.3.1 y 1.4.2.

  51. ¿Cuál es la versión de Servlet y JSP soportada por Caravel?
  52. Caravel implementa las especificaciones siguientes: Servlet 2.3 y JSP 1.2.

  53. ¿Cuál es el comportamiento de aplicaciones de impresión de gran cantidad de papel, así como de procesos batch de gran volumen de datos?
  54. El proceso batch de impresión más extenso realizado con Caravel fue para una nómina de 25.000 empleados. La base de datos sobre la que se ejecutaban estos procesos tenía un volumen aproximado de 24 Gbytes. El proceso ahora requiere menos tiempo para imprimir todos los documentos (listas, recibos, cheques, duplicados, etc.). En cualquier caso y bajo cualquier circunstancia, las aplicaciones migradas funcionan más rápido que las originales del AS/400.

  55. Cuando se instala la aplicación Java convertida con Caravel sobre un servidor iSeries ¿puede ejecutarse sin utilizar los recursos de la tarjeta interactiva?
  56. Sí, efectivamente puede configurarse para que todos los trabajos generados sean de tipo batch, y por tanto no consumir recursos interactivos.

  57. ¿Qué versiones de los lenguajes RPG y COBOL soporta Caravel en entorno OS/400?
  58. En entorno OS/400:

    • Lenguaje RPG: Todas las versiones: RPG II, RPG III, RPG/400 e ILE-RPG.
    • Lenguaje COBOL: COBOL/400.
    • También contempla, tanto en RPG como en COBOL, la conversión de SQL embebido.

    En entornos Mainframe de IBM las versiones de COBOL que pueden ser convertidas son:

    • ANSI COBOL 85, COBOL y COBOL II.
    • Así mismo, se contempla la conversión de COBOL CICS y SQL embebido.
  59. ¿Cómo se manejan las aplicaciones multi-idioma?
  60. Si la aplicación original es multi-idioma, Caravel la migrará con sus mismas funcionalidades. Si no lo fuera, Caravel, durante el proceso de traducción, extrae los literales propios al idioma y los exporta a un fichero externo. Este tratamiento permite una posterior edición/traducción de ese fichero a los idiomas que se deseen, para convertir la aplicación en multi-idioma.

  61. ¿Puede BASE 100 entregar un listado completo de las anomalías (como referencias no resueltas, fuentes sin objetos, objetos sin fuente, etc.) una vez que la aplicación ha sido importada?
  62. Si, en la primera fase de la conversión se genera un informe con un análisis completo y detallado.

  63. ¿Caravel puede migrar a cualquier base de datos relacional, o hay alguna restricción específica para la base de datos relacional destino?
  64. Actualmente migramos hacia las bases de datos relacionales más conocidas del mercado. Algunos ejemplos son: DB400, DB2, Oracle, MultiBase, SQL Server… El único requisito es que disponga de drivers JDBC.

  65. ¿Qué "browsers" o navegadores soportan?
  66. Internet Explorer, Mozilla Firefox, Google Chrome.

  67. ¿Cómo resuelve Caravel la conexión con otros sistemas externos (SAP, etc.)?
  68. La experiencia en este punto ha demostrado que las aplicaciones convertidas a Java no tienen limitaciones en cuanto a futuras programaciones o conectividad. Por ejemplo, en un proyecto reciente hubo que proporcionar conectividad a aplicaciones en Java anteriormente desarrolladas por el cliente. Todos los proyectos de conversión incluyen la integración con otros sistemas existentes o futuros.

  69. ¿Qué porcentaje de los programas originales es convertible a Java?
  70. Caravel convierte el 100% del código fuente, de los procesos e interacciones con el sistema operativo, de los accesos a datos y de las interfaces con el usuario, sin restricciones. No se trata de una solución parcial, sino de un proceso de migración del sistema completo, para pasar a Java, y opcionalmente a otros sistemas operativos, SGBDR o hardware, a interfaces con el usuario más modernos y versátiles, de una sola vez. El resultado final es una aplicación en Java con exactamente la misma funcionalidad que la de la aplicación original.

  71. ¿Existe una versión de prueba que se pueda descargar?
  72. La mejor prueba es realizar una demostración, como ejemplo, de alguna de sus aplicaciones.

    En la página de Cómo realizar una prueba de concepto (PdC) podrá encontrar toda la información necesaria para elaborar una muestra de su aplicación. Una vez traducida podrá evaluar el resultado obtenido.

  73. ¿Es posible adquirir una licencia de Caravel como herramienta de conversión?
  74. Caravel es un servicio de conversión, esto implica el compromiso de entregar la aplicación en Java con exactamente la misma funcionalidad.

    Por esta razón, nuestro modelo de negocio no incluye vender las herramientas de conversión a una tercera compañía. Consideramos una cuota de licencias de otras herramientas incluidas en la tecnología Caravel, como el Caravel Active WebFacing y el Caravel Insight.

  75. Una vez convertida la aplicación a Java, ¿es necesario utilizar sus herramientas en el entorno migrado?
  76. Las aplicaciones migradas son 100% Java. Nuestro servicio de conversión ofrece total libertad a nuestros clientes, y no requiere ningún pago adicional una vez finalizada la conversión en sí. En nuestra propuesta comercial previa se ofrece al cliente información detallada acerca del coste de cada ítem, plazos de ejecución, etc.

  77. ¿Cuál es el precio estimado de un proyecto de conversión con Caravel?
  78. El precio depende en cada caso de la magnitud del proyecto. Éste puede ser calculado sobre la base de la información proporcionada por el cliente a través del cuestionario de evaluación que puede encontrar en esta misma web:

    Si su compañía no conoce el número exacto de objetos, podríamos confeccionar un presupuesto estimado sobre modelos representativos.

    Nuestra política de precios permite un ROI (Retorno de Inversión) en un tiempo máximo de 12 meses. La ventaja económica de Caravel equivale a 1/7 del coste y 1/5 del tiempo necesario para un proyecto de reprogramación.

  79. ¿Qué valor añadido aporta Caravel para aquellas instalaciones en las que actualmente utilizan o contemplan utilizar soluciones tales como WebFacing, Host Publisher, HATS for iSeries y accesos para la Web?
  80. Caravel no es meramente una transformación de pantallas, ni un middleware. Nuestro servicio es un proyecto para pasar a Java de una sola vez. Las características de WebFacing o HATS no pueden ser comparadas con las particularidades de Caravel. Nuestro servicio cambia toda su aplicación a Java, analizándola, estructurándola y sugiriendo mejoras con nuestras posibilidades de reingeniería tecnológica. Nuestro enfoque de proyecto es mucho más amplio que un "maquillador" con alguna conectividad a Internet como facilitan los productos citados. En algunos casos el tiempo de implementación puede ser similar o mejor.

  81. ¿Cuáles son los requisitos necesarios para que BASE 100 aborde un proyecto de conversión de una aplicación de RPG y COBOL a Java?
  82. En general, BASE 100 requiere los programas en RPG o COBOL con el código fuente relacionado, con datos para pruebas y una correcta funcionalidad del sistema en origen. También es necesaria una descripción de la funcionalidad de las aplicaciones originales. Para ayudar al cliente en este proceso de descripción de la funcionalidad BASE 100 dispone de la herramienta Caravel Test Maker.

  83. ¿Cuál es el resultado de la conversión?
  84. BASE 100 ofrece la aplicación en Java con exactamente la misma funcionalidad, esto incluye los programas y el código fuente en Java.

    La aplicación se complementa con documentación específica acerca del proyecto y de la tecnología de BASE 100, así como con la formación necesaria en el entorno de programación en Java y en la tecnología Caravel.

  85. ¿Es posible integrar otras aplicaciones Java una vez que la conversión ha sido realizada?
  86. Sí, nuestra aplicación convertida es totalmente compatible con cualquier aplicación Java.

  87. ¿Es posible convertir solamente una parte del sistema de información? ¿Pueden coexistir los programas en RPG/COBOL y Java en el mismo AS/400?
  88. Sí, es totalmente posible convertir sólo una parte del sistema. Los programas RPG/COBOL pueden coexistir con otros en Java.

Personalización de pantallas CaravelTop

  1. Pregunta 1. ¿Es posible modificar elementos del HTML incluyendo Radio Buttons o Pull Downs?
    Si es así, ¿donde se realiza?, ¿en la definición XML de la pantalla?
    Necesitamos realizar estos cambios, pues son funcionalidades que utilizamos con frecuencia.
  2. En la aplicación Java generada con Caravel está separada la lógica del programa respecto a la representación gráfica de dicha pantalla en web.

    Por este motivo, es fácil personalizar cada elemento de pantalla mediante elementos gráficos estándares, como Radio Buttons, Pull downs, etc. sin afectar al programa traducido.

    El programa Java resultado de la conversión trata con los datos recibidos o enviados al usuario, mientras que una JSP se encarga de presentar dicha información en pantalla.

    La personalización de las pantallas se puede realizar de manera masiva (una Jsp se encarga de presentar todas las pantallas de la aplicación) o personalizada (una Jsp se encarga de presentar una sola pantalla de un programa).

    Existe además la posibilidad de configurar la aplicación para que pueda ser invocada mediante servicios REST. En este caso se puede usar, por ejemplo, un cliente HTML+Css+Javascript+AngularJs que accede mediante servicios REST a la aplicación Java convertida.

  3. Pregunta 2. Relacionado con la pregunta anterior, deseamos saber si hay alguna limitación en cuanto a funcionalidades que no se puedan utilizar en el caso de las pantallas Caravel. ¿Hay alguna restricción?.
  4. No existe en principio ninguna restricción respecto a las posibilidades de personalización de una pantalla. La única restricción viene del uso que hace el programa convertido de la información de pantalla. Por ejemplo, el programa convertido puede tener en cuenta la posición del cursor en la pantalla o la tecla de función pulsada por el usuario.

    Existe una implementación por defecto de las pantallas que se ocupa de retornar esta información.

    También hay que tener en cuenta la lógica de navegación de una pantalla a otra en la aplicación. La presentación permitirá una navegabilidad más o menos flexible dependiendo de la lógica funcional de la aplicación.

  5. Pregunta 3. Para la definición de la pantalla según observamos en el archivo de definición XML se asigna una posición de la columna con atributos Lin y Pos.
    ¿Es posible mostrar pantallas de mayor resolución de 24 x 80?
    ¿Existe alguna restricción en cuanto Lin y Pos?
    Actualmente subdividimos las pantallas en varias debido al gran número de columnas que necesitamos mostrar, pero quisiéramos integrarlas en una sola .
  6. Como se describe en el punto 1, existen diferentes niveles de personalización que van desde cambiar únicamente las hojas de estilo generadas por defecto hasta la posibilidad de modificar totalmente una pantalla para que responda a las necesidades de la aplicación.

    Existe por lo tanto la posibilidad de introducir distintos niveles de personalización. Para ilustrar este aspecto adjuntamos algunas imágenes de ejemplo al final de este documento.

    No hay problema en unir varias pantallas, pero hay que tener en cuenta si este cambio afecta a la navegabilidad de la aplicación. En caso de que sí afecte, habrá que tenerlo en cuenta para que el programa siga comportándose de manera correcta

  7. Pregunta 4. ¿Se puede utilizar JavaScript?
    Si es así, ¿cómo se debe definir en el archivo XML de definición de pantalla?
    Desearíamos añadir nueva funcionalidad, por ejemplo activar acciones al pulsar SHIFT TAB.
    Así mismo quisiéramos poder utilizar librerías de JavaScript tales como jQuery.
  8. No hay problema en utilizar Javascript y librerías como jQuery. Tanto si se emplean JSP como si la aplicación usa una presentación totalmente HTML+Javascript.

    Las implementaciones estándares Caravel ya usan código Javascript y jQuery por defecto.

  9. Pregunta 5. ¿Se pueden utilizar CSS?
    Si es así, ¿dónde se definen?, ¿cómo podemos especificar class atribute de cada Tag?
    En nuestros futuros desarrollos desearíamos utilizar CSS como parte del diseño.
  10. Sí, las CSS se usan de manera totalmente estándar. Cada Jsp o página HTML encargada de presentar la información en pantalla define las CSS necesarias.

    Las implementaciones estándares Caravel ya están usando CSS por defecto.

Imágenes

Personalización de pantallas

Pantalla original A.

Personalización de pantallas

Modificación de nivel básico de la pantalla A.

Personalización de pantallas

Pantalla original B.

Personalización de pantallas

Modificación de nivel alto de la pantalla B.

Personalización de pantallas

Pantalla original C.

Personalización de pantallas

Modificación de nivel alto de la pantalla C.

Personalización de pantallas

Pantalla original D.

Personalización de pantallas

Modificación de nivel alto de la pantalla D.