Diferencias

Muestra las diferencias entre dos versiones de la página.

--- simo:documentos:tecnicos:arquitectura [2017/10/12 04:34]
lgomez
+++ simo:documentos:tecnicos:arquitectura [2019/06/13 21:30] (actual)
caardila [ARQUITECTURA DE SISTEMA SIMO]
@@ Línea 1: / Línea 1: @@
 __false__
+===== INTRODUCCIÓN =====
+Esta página contiene la descripción arquitectónica del sistema SIMO.  Esta arquitectura fue diseñada de acuerdo a los criterios presentados a continuación y naturalmente sufrió un proceso evolutivo a medida que se fue construyendo el sistema.
+Dadas estas premisas, la argumentación aqui presentada inicia con el  análisis de los criterios y paulatinamente profundiza hasta llegar a las  definiciones que constituyen la arquitectura en cuestión.
+===== CRITERIOS Y BASE LÓGICA =====
+En general, la arquitectura de software busca dar respuesta a una  cuestión principal: Dar alcance a una serie de cualidades o atributos de  calidad, predominantemente no funcionales, que se han identificado como  las más relevantes para el sistema y a su vez minimizar los riesgos  identificados como los más peligrosos potencialmente.
+Los atributos de calidad resultan ser comunes a todos los sistemas de  software y por tanto han sido identificados y estandarizados (Ver [[:ea:tobe:aplicaciones:sigeca:rnf|gestion.cnsc.gov.co/cnscwiki/doku.php]]), a continuación listamos los más relevantes en el marco del proyecto.
+    * Mantenibilidad
+    * Modularidad
+    * Rendimiento y escalabilidad
+    * Seguridad
+    * Portabilidad y compatibilidad
+    * Usabilidad
+    * Acceso a la información
+Adicionalmente, existen también otros criterios que resultan importantes  pero  que no pueden ser clasificados estrictamente como atributos de  calidad, entre estos criterios encontramos:
+    * Experiencia y habilidades del equipo de trabajo
+    * Metodología de desarrollo
+A continuación se analizan cada uno de estos criterios a la luz del sistema:
+==== Mantenibilidad ====
+Esta cualidad indica que tan fácil es hacer mantenimiento y soporte a un  sistema y por supuesto es una cualidad deseable y necesaria en  cualquier software, cualitativamente, la mantenibilidad de un sistema se  ve beneficiada por aspectos como la calidad de la documentación y la  simplicidad del código. La calidad de la documentación depende más de la  metodología de desarrollo y de la gestión del proyecto, por el  contrario, la simplicidad en el código si puede ser influenciada por la  arquitectura de software que se escoja, en este sentido, se debe  procurar entonces  utilizar una arquitectura que favorezca la  simplicidad en el código.
+==== Modularidad ====
+Esta propiedad afecta directamente la mantenibilidad y está orientada a  que el software se construya mediante la interacción de módulos o  componentes independientes que pueden ser reemplazados o modificados sin  que se afecte radicalmente el funcionamiento de los otros módulos. De  esta forma es posible hacer mantemiento focalizados en el módulo  afectado por el problema o susceptible de mejora. En general la  modularidad es favorecida al seguir los principios de bajo acoplamiento y  alta cohesión, los cuales son maximizados al utilizar una arquitectura  orientada a componentes y/o a servicios. En consecuencia la arquitectura  a escoger utilizará un framework que favorezca estos paradigmas de  programación, en concordancia con la arquitectura SOA propuesta (Poner  referencia).
+==== Rendimiento y escalabilidad ====
+El rendimiento resulta de vital importancia en el sistema, puesto que se  espera una alta demanda por parte de los usuarios ciudadanos, (existe  un número de usuarios potenciales correspondiente a la fuerza laboral  del país). Adicionalmente se espera que haya picos de demanda sobre el  aplicativo en momentos claves de la convocatoria como los cierres de los  períodos de inscripciones.
+La escalabilidad está altamente relacionada con el rendimiento puesto  que si un sistema es áltamente escalable, entonces podrá soportar  demandas de servicios progresivamente más altas sin alterar el  rendimiento. Cláramente se debe favorecer una arquitectura que favorezca  el escalamiento y minimize el consumo de recursos, claro está,  procurando mantener un equilibrio con los demás factores de decisión de  la arquitectura.
+==== Seguridad ====
+Dada la naturaleza de la información manejada en el sistema, que incluye  datos personales y laborales de los usuarios y que atañe directamente  al empleo que obviamente es de vital importancia para los usuarios, se  hace necesario contar con un nivel de seguridad que garantice la  privacidad, confidencialidad, integridad, autenticidad  y no repudio de  la información. Existe un extenso trabajo en seguridad a nivel de  sistemas de información y la arquitectura es solo una parte de la  solución.
+Si bien, pueden implementarse controles de seguridad áltamente  sofisticados, estos controles pueden ir en detrimento de otros aspectos  como la usabilidad del sistema, en consecuencia, la arquitectura  propuesta debe incluir o facilitar la implementación de los controles de  seguridad más ampliamente difundidos.
+La naturaleza Web del sistema, implica que muchos de los controles  puedan ser implementados a nivel de infraestructura (por ejemplo la  implementación de https/ssl o de sistemas cortafuegos y proxys), otros  controles pueden ser implementados a nivel de middleware, como pueden  ser los repositorios de la información de autenticación o los servicios  de encripción de datos, en este caso, la arquitectura a implementar  debería basarse o ser capaz de utilizar plataformas que proporcionen de  antemano los servicios necesarios.
+Adicionalmente, también es necesario implementar controles tendientes a  evitar la exposición y uso de vulnerabilidades, estos controles son  aplicados muchas veces a nivel del sistema operativo sin embargo, muchos  de ellos aplican específicamente al paradigma Web (por ejemplo,  cross-site scripting, falsificación de sesiones, almacenamiento de  contraseñas en el navegador), por tanto, la arquitectura a usar debería  en lo posible  implementar por defecto este tipo de controles.
+Por último, pero no menos importante, la arquitectura debe permitir la  especificación diáfana de roles y usuarios que permita implementar los  requisitos de autorización sobre las operaciones y datos del sistema, al  respecto, el framework utilizado debería permitir la especificación  abstracta (si es posible declarativa) de estos roles y permisos.
+==== Portabilidad y compatibilidad ====
+Estos atributos de calidad resultan relevantes en dos situaciones específicas:
+La primera obedece a que se viene desarrollando en la entidad, una  iniciativa de mejoramiento de la infraestructura tecnológica, esto  plantea la necesidad de contar con aplicaciones que puedan ser portables  fácilmente a nuevos tipos de infraestructura. Para empezar, se debe  utilizar una arquitectura que utilice un lenguaje de programación  portable, pero además de eso, es importante minimizar la dependencia de  fabricantes de software específicos y se debe favorecer la aplicación de  estándares y especificaciones de la forma más simple que sea posible.
+El segundo escenario surge de la necesidad de soporta clientes móviles  sobretodo para los usuarios ciudadanos, en este sentido, la arquitectura  debería permitir el desarrollo de interfaces de usuario optimizadas  para ese tipo de clientes o en su defecto, las interfaces deberían poder  indistintamente en navegadores tipo escritorio o clientes móviles. De  cualquier forma la arquitectura debe proporcionar medios para desplegar  la interfaz de usuarios en dispositivos móviles.
+==== Usabilidad ====
+Este atributo es de suma importancia dado que se espera una constante  interacción del usuario ciudadano con el sistema, y además a que no es  posible delinear un perfil específico para los usuarios ya que los  empleos ofrecidos en las convocatorias son extremadamente diversos y no  es posible caracterizar al usuario que va a aplicar.
+Es por esta razón que las interfaces de usuario deben ser diseñadas de  forma que puedan ser entendidas y usadas por cualquier persona, si bien  esto es bastante difícil, puede ser un punto en el cual se puede obtener  una mejora sustancial sobre el conglomerado de aplicaciones que  conforman el sistema actual.
+El tema de la usabilidad es difícil de abordar desde el punto de vista  de la arquitectura de software, sin embargo, como lineamiento general,  se debería escoger una que favoreciera medios flexibles de interacción  con el usuario, muy al estilo Web 2.0.  Este tipo de interacciones se  caracterizan por dar alcance a las características modernas de la Web  que incluyen, pero no se limitan a peticiones asincrónicas y a  aprovechar al máximo las prestaciones de los navegadores recientes. En  particular, las interfaces de usuario deberían no solo ser compatibles  con HTML5 sino también tratar de utilizar inteligentemente las nuevas  características que este estándar ofrece.
+==== Acceso a la información ====
+Este atributo era de particular importancia para el sistema, dado que una de las principales funciones del sistema es permitir al ciudadano encontrar empleos potenciales cuyas características se alineen apropiadamente a su experiencia laboral, habilidades y gustos.
+En este sentido, el sistema debía contar con un sistema de búsqueda más avanzado que permitiera encontrar empleos por criterios definidos (como rango salarial, nivel académico, convocatoria, entre otras) pero también por palabras clave y por aproximación de forma que la búsqueda no dependa de que los textos contengan exactamente una palabra.
+En general este tipo de búsquedas incorpora tecnologías relacionadas con el indexamiento de texto completo (Full Text Index) y pueden incorporar algoritmos como búsquedas fonéticas, raíces lexicográficas, n-gramas, entre otros
+En resumen, la arquitectura del sistema fue planeada para incorporar librerías que proporcionen estas capacidades de manera genérica
+===== ARQUITECTURA =====
+La arquitectura del sistema se describe en el siguiente diagrama:
+{{:ea:tobe:aplicaciones:sigeca:sigeca1.png?426x606}}
+El diagrama ilustra una arquitectura tipo SOA, basada en servicios Web  Restful alojados en un servidor liviano construido con base en el  framework de desarrollo Spring que se ejecuta sobre un contenedor Web  Java.
+En naranja  se pintan los componentes de la capa de adaptación que  permiten el acceso a la persistencia (base de datos), en verde están los  componentes de la capa de servicio, en azul se encuentran los  componentes de la capa Web y en amarillo los de la capa de presentación o  interfaz de usuario. En gris se pintan los componentes del framework  que proporcionan los servicios middleware pero que no tienen que ser  escritos por el desarrollados sino sólamente configurados. A  continuación se explica cada uno:
+    - **[[:ea:tobe:aplicaciones:sigeca:framework|FrameWork]] Spring + J2EE:** Este framework junto con los servicios J2EE del contenedor Web que  aloja la aplicación, es el encargado de proveer todos los servicios de  integración, seguridad, acceso a datos, transacciones, aspectos,  inyección de dependencias e inversión de control, junto a varios más que  dan soporte a la arquitectura del lado del servidor. Si bien Spring  puede ser utilizado de muchas formas, en esta propuesta se utiliza para  inplementar una arquitectura de tipo servidor liviano, donde se delega  gran parte de la responsabilidad de renderización de la interfaz gráfica  al navegador, permitiendo una reducción en el consumo de recursos del  lado del servidor y facilitando su escalamiento. Del entorno J2EE se  utilizan los componentes de la especificación Web (principalmente  Servlets) por lo cual es posible desplegar la aplicación en un  contenedor Web Java liviano como Apache Tomcat o Jetty.
+    - **Entidad JPA:**    Este componente representa un  objeto de dominio (Referencia) y a su vez contiene la información que  permite mapear los objetos de dominio a las tablas en el sistema de  persistencia.  Esta información sigue la especificación JPA de Java. El modelo de dominio puede ser consultado en la siguiente página [[:simo:documentos:tecnicos:dominio|Modelo de dominio]]
+    - **Hibernate + Hibernate Search:**      Este componente se encarga de realizar el mapeo relacional a objeto y manejar el ciclo de vida de las entidades JPA, también integra el motor de indexamiento Full Text de Lucene para indexar los datos de la base de datos. Una descripción más detallada puede ser encontrada acá [[:simo:documentos:tecnicos:hibernate|Hibernate y Hibernate Search]]
+    - **Repositorio Spring JPA:**    Este componente es  una interfaz que al ser implementada por Spring proporciona las  operaciones CRUD y los métodos de búsqueda definidos por el  desarrollador. Solo basta definir las firmas de los métodos de búsqueda y  Spring se encarga de proporcionar todo el código, idealmente, debe existir un repositorio por  Entidad principal (Objeto de dominio). Estos repositorios han sido aumentados mediante una implementación base genérica que soportar métodos de búsqueda de aplicación general. Ver [[:simo:documentos:tecnicos:repositorios|Capa de Repositorios Spring Data]]
+    - **Servicio Spring: **    Este componente  implementa los métodos de negocio de cada módulo, lo ideal es crear un  servicio por repositorio Spring, a través de los mecanismos de inyección  de dependencias de Spring, el componente obtiene referencias al  repositorio Spring y a cualquier otro servicio que se requiera. Si no se  requieren métodos de negocio distintos a las operaciones CRUD  tradicionales, este componente puede ser obviado. Ver [[:simo:documentos:tecnicos:servicio|Capa de Servicios]]
+    - **Controlador REST:**      Este componente se encarga  de exponer los servicios del repositorio Spring y del Servicio Spring  utilizando el estándar REST, también mediante inyección de dependencias,  el controlador puede acceder a los métodos CRUD del repositorio Spring o  a los métodos de negocio del Servicio Spring.. El estándar REST indica  que las operaciones de inserción se debe realizar usando el método HTTP  Post, las de consulta Get, las de modificación PUT y las de eliminación  DELETE.  Este componente se encarga de crear manejadores para cada uno  de estos métodos HTTP y enlazarlos a los métodos en los otros  componentes. La principal diferencia con los controladores tradicionales  (Por ejemplo JSF) es que en este caso no se está generando HTML sino  que se producen cadenas JSON que son intercambiadas con el navegador,  estas cadenas son inherentemente más livianas y simples que HTML y  proporcionan una mayor flexibilidad y una mejor separación de  responsabilidades puesto que ofrecen una representación uniforme,  simplificada y libre de información de formateo. Ver [[:simo:documentos:tecnicos:controlador|Capa de Controladores REST]]
+    - **Página HTML + Componentes DOJO: **     La interfaz  de usuario se crea y ejecuta enteramente en el servidor y consiste de  páginas HTML y componentes DOJO que son componentes [[:simo:documentos:tecnicos:javascript|JavaScript]] modularizados bajo el estándar AMD.  Se propone el uso de dos tipos de  componentes DOJO que colaboran entre sí, por un lado los Widgets  proporcionan los componentes gráficos y por otro, los store se encargan  de acceder a los recursos REST en el servidor y adaptar esta información  para los Widget, de esta forma se logra una interfaz de usuario ríca en  funcionalidades, modular, simple y limpia. Ver [[:simo:documentos:tecnicos:ui|Capa UI Javascript]]

Herramientas de usuario

Herramientas del sitio

Diferencias

Herramientas de la página